If you would like to read the other parts in this article series please go to:
In messaging clients such as Outlook and Outlook Web App (OWA) a message has a priority setting of normal by default. The user is able to configure the message as either high or low priority by the click of a button and I’m sure that you have all used this feature before. Exchange 2010 introduced a feature called priority queuing where it is possible to configure a Hub Transport server to process messages based on the priority of those messages and in this article I want to take a look at this feature and cover not only how to enable it, but also how to test that it is working.
Why might an organization be interested in priority queuing? Why might an organization wish to ensure that all messages marked as high priority are delivered before messages marked with normal and low priorities? Or that messages marked as normal priority are delivered before messages marked with low priority? Such a requirement is typically driven by an organization’s Service Level Agreements (SLAs) for end-to-end message delivery times. Having high priority messages delivered before normal priority messages could be important to an organization in areas such as service downtime announcements or other business critical messages. The importance of delivering prioritized messages in a timely manner is often amplified in organizations that have connectors across WAN links that can become clogged by oversized messages.
We will start the article by covering the lab environment that I used to test the feature, before moving onto confirming how Exchange 2010 operates before priority queuing is configured. We will then enable priority queuing and see what differences occur with message processing. Later on in the article, we will be looking at how we can control the maximum size of a message that has been configured as high priority.
For this article, I constructed the simple lab environment shown in Figure 1. It consists of two separate forests, namely Fabrikam and Contoso. Both forests contain a single domain and each domain contains a single domain controller and a single Exchange 2010 SP1 server; all servers are running the Windows 2008 R2 operating system. For the purposes of processing messages in this article, the sending system is Fabrikam whilst the receiving system is Contoso and therefore a Send connector was created on the Fabrikam Exchange server to send all messages destined for the contoso.com address space directly to the Contoso Exchange server. Priority queuing works within a single Exchange organization of course, but I simply preferred to construct two separate Exchange organizations and monitor the processing between them accordingly.
Figure 1: Lab Environment
In the tests that I performed in this article, I used messages marked as normal and high priority, with the idea being that I wanted to confirm that high priority messages were processed before normal priority messages. I could have equally used messages marked as normal and low priority, or even low and high priority. Priority queuing takes effect with messages marked as low priority. For example, a message marked as normal priority will be processed before a message marked with low priority.
The first thing to understand is that priority queuing is disabled by default in Exchange 2010 so it makes sense to confirm this before enabling the feature. To do this, we can use the lab to send a series of messages between Fabrikam and Contoso. However, before we send the messages we first need to stop the Microsoft Exchange Transport service on the Contoso Exchange server. This service processes the incoming messages to Contoso and therefore by stopping this service we can ensure that messages destined for Contoso queue on the Fabrikam Exchange server; when we’re ready, we can simply restart the Microsoft Exchange Transport service on the Contoso Exchange server and see how the messages are processed.
With the Microsoft Exchange Transport service stopped, we first send a normal priority message from the user firstname.lastname@example.org to the user email@example.com and ensure that this message hits the queue first. Next, we send a high priority message from/to the same pair of users. We can then use the Queue Viewer utility to check that the messages are queued on the Fabrikam Exchange server. Here’s what to do:
- Run the Exchange Management Console.
- From the left-hand pane, select Toolbox.
- From the list of available tools, right-click Queue Viewer and choose Open Tool from the context menu. This is shown in Figure 2.
Figure 2: Opening the Queue Viewer Tool
- In the resulting Queue Viewer window, which is shown in Figure 3, we can see that there exists a queue for a Next Hop Domain of mail.contoso.com and that there are two messages queued for this domain. To examine the contents of this queue, simply double-click the queue name.
Figure 3: Queue Viewer Displaying Queues
- Double-clicking the queue name brings us to the screen shown in Figure 4, where we can now see the individual messages in the queue for mail.contoso.com.
Figure 4: Queue Viewer Displaying Individual Messages
- What you may notice from Figure 4 is that there is no column showing when each message was received. The one default column that is not shown in Figure 4, since it is off the right-hand side of the screen, is the Last Error column. Fortunately, we can add a column called Date Received by clicking View / Add Remove Columns which will present a screen such as the one shown in Figure 5. Here you can see that the Date Received column has been selected; clicking the Add button will add this column to the overall display
Figure 5: Adding the Date Received Column
- Once the Date Received column has been added, we can see the order in which the messages were received and hence determine the queue order. We can confirm from Figure 6 that the message with a normal priority was received at 17:06:45, earlier than the message with high priority since that was received at 17:07:12
Figure 6: Queue Viewer Displaying Date Received
Once the messages are queued and we have noted the queue order, we can restart the Microsoft Exchange Transport service on the Contoso Exchange server. In order to ensure that the queued messages are processed quickly, we can now highlight the queue for mail.contoso.com as shown earlier in Figure 3 and then click the Retry option in the action pane. This will force an immediate retry by the Fabrikam Exchange server, rather than waiting for the next scheduled retry attempt.
We can then log into the target mailbox and check that the messages have been received successfully, as you can see in Figure 7. Since the message received first is placed at the bottom of the Inbox, it is clear that the normal priority message was received first, in advance of the high priority message. This is expected of course, since you’ll remember that priority queuing is disabled by default in Exchange 2010.
Figure 7: Order of Messages Received
How can we be even more confident that this is the way things work by default? We could examine the message tracking logs to determine the timings. Also we can enable protocol logging on the receiving Exchange server, the Contoso Exchange server, and check what that particular log says during message transmission. We will look at both of these options in part two of this article.
So far we’ve covered what priority queuing is and why you’d implement it, followed by a description of the lab environment used within this article. We then moved on to show how messages are processed when priority queuing isn’t enabled, which is the default setting; this covered using the Queue Viewer utility found in the Exchange Management Console. In part two, we’ll look at using protocol logging to confirm our findings from part one, then go on to enable priority queuing and examine the differences in system operation.
If you would like to read the other parts in this article series please go to: