Most people who use Outlook will know that individual email messages can be marked with different priorities. Usually this is used solely as a way to flag the importance of the email to the recipient, and people who receive large volumes of daily email will often use filtered views to bring the highest priority emails to the surface for action.
What a lot of people don’t also realise is that the priority flag on a message can also be used by Exchange Server 2010 to deliver high priority messages before normal or low priority messages.
This capability becomes important in Exchange environments that are very large, complex, or spam geographically diverse areas. In these types of environments email latency can become noticeable, unlike smaller environments where a few hundred recipients on one or two servers see virtually no delay in sending and receiving email.
When you combine long distance with high volume it is easy to see how important emails might be delayed in an unacceptable way if they are simply processed in a “first in, first out” order.
Priority Queuing is enabled on Hub Transport servers and is performed on a server by server basis. By default it is disabled, so the administrator is able to choose which servers have priority queuing enabled and can do so only where necessary in the organization.
In addition to turning the feature on or off the administrator can also configure a size limit for email messages to be treated according to their set priority. For example, a size limit of 512Kb would mean that any emails larger than that which are flagged as High priority will be downgraded to Normal priority. This is something to be considered carefully by the administrator depending on the nature of the business – if the highest priority emails often contain attachments (eg contract bids and tenders) then a low size threshold would negate the benefit of priority queuing).
The server can also be configured with different delay notification thresholds for each priority. Obviously a high priority message that is delayed for more than 30 minutes warrants a notification, whereas a normal message can withstand a longer delay without notifying the sender.
When priority queuing has been enabled it opens up the possibility that some email users will abuse it by unnecessarily setting High priority flags on messages that do not specifically warrant it. There are two ways to control who can use priority queuing in the organization:
- Per-Mailbox – each mailbox has a setting to downgrade any High priority messages to Normal priority automatically. By default this is disabled, and so when priority queuing is enabled in Hub Transport servers anyone can make use of it. This per-mailbox setting could be turned on for all users with a script or template used at time of mailbox creation. Alternatively it could be set only on users identified as regular abusers of the feature.
- Transport Rules – another approach would be to use a Transport Rule to detect any messages set as High priority, and if they are not sent by approved users of the feature take action such as reject the message. This is probably a bit heavy handed and would deny the users the ability to use priority flags to signal the importance of a message to other users in their inboxes.
Although useful within the organization priority queuing is of no benefit once the email leaves the organization and is sent to an external party. Any delays or problems experienced outside of the organization could still impact the timely delivery of high priority emails. So while it I useful for several scenarios it is not a 100% solution to all high priority message delivery.