If you would like to read the other parts in this article series please go to:
Introduction
This is the third and final part of an article series looking at the priority queuing feature of Exchange 2010. So far in parts one and two we have demonstrated how enabling the priority queuing feature ensures that high priority messages are processed before normal priority messages. Although we didn’t specifically test this scenario, be aware that with priority queuing enabled, normal priority messages are processed before low priority messages.
Here in part three, we shall be taking a look at how we can control large messages in conjunction with priority queuing.
Controlling Large High Priority Messages
Back in part one of this article, I briefly mentioned that the need to send large messages around an Exchange system can sometimes result in the need to implement priority queuing as a way to ensure that urgent messages are delivered in a timely manner. However, what if the users send large messages marked as high priority? How can that be controlled? The answer to this question lies in another configuration option found in the EdgeTransport.exe.config file, namely the MaxHighPriorityMessageSize option that you can see highlighted in Figure 16.
Figure 16: The MaxHighPriorityMessageSize Parameter
The default value of this parameter is 250KB. This means that any high priority messages less than 250KB in size will be processed before any high priority message that exceeds 250KB in size. Let’s look at how we can confirm this and also how this setting requires that priority queuing is enabled. First, we can change the default value of 250KB in the EdgeTransport.exe.config file to something huge so that it effectively doesn’t matter. Let’s choose a value of 22250KB. We then disable the priority queuing feature via the PriorityQueuingEnabled parameter as we saw in part two of this article; simply set this parameter to $false and save the file. Once the change has been made, restart the Microsoft Exchange Transport service on the nghcloud.co.uk Exchange server so that the changes take effect.
Next we disable the Microsoft Exchange Transport service on the neilhobson.com Exchange server to ensure that messages queue on the nghcloud.co.uk Exchange server. Then we can send 3 separate messages from 3 separate users on the nghcloud.co.uk Exchange server to the same user on the neilhobson.com Exchange server. Here are details of the messages sent:
- User1 from the nghcloud.co.uk Exchange organization sends a high priority message that is 1166KB in size to a user in neilhobson.com
- Once this has been queued, User2 sends a small 28KB high priority message to the same neilhobson.com user and again this is queued
- Finally, User3 sends a high priority message that is 1166KB in size to the same user in neilhobson.com
The Queue Viewer utility for this scenario is shown in Figure 17. Based on the queue order, we would expect the messages to be delivered in order.
Figure 17: Queued Messages With Maximum High Priority Message Size Set to 22250KB
Rather than forcing any queues, this time we can simply restart the Microsoft Exchange Transport service on the neilhobson.com Exchange server and see how the messages are processed in their own good time by the two Exchange servers. The results of the delivery to the destination Inbox are shown in Figure 18, where it can be seen that the small message, Message 2 from User2, was actually delivered last.
Figure 18: Small High Priority Message Delivered Last
This situation is confirmed by examining the protocol log, which is shown in Figure 19. You can see here that the messages are received in the following order: User3, User1, User2. Therefore, in this test we have seen that the smallest high priority message was not processed before larger high priority messages.
Figure 19: Contents of Receive Connector Protocol Log
Testing The MaxHighPriorityMessageSize Parameter
With this test complete, let’s now change the MaxHighPriorityMessageSize setting back to its default value of 250KB but at the same time ensure that priority queuing remains disabled. Hopefully we can now prove that this particular feature requires that priority queuing is enabled. Again, restart the Microsoft Exchange Transport service on the nghcloud.co.uk Exchange server for the changes to take effect and then stop the same service on the neilhobson.com Exchange server to ensure that messages are queued on the nghcloud.co.uk Exchange server.
Once the services have been changed, we can send the same test messages as we did in the first test. Once again, the Queue Viewer is consulted on the nghcloud.co.uk Exchange server to ensure that the messages are queued in the order they were received. This is shown in Figure 20 and it can be seen that the overall queue looks essentially the same as we saw earlier in Figure 17.
Figure 20: Queued Messages With Maximum High Priority Message Size Set to 250KB
Let’s now look at how the messages were received in the destination Inbox and also the contents of the protocol log. First the received messages are shown in Figure 21 and we can see that there has been a slight change in the received order but the small message from User 2 has again been received last. The protocol log shown in Figure 22 confirms this.
Figure 21: Small High Priority Message Not Processed First
Figure 22: Contents of Receive Connector Protocol Log
We can therefore see that the small high priority message sent from User2 has not been processed before the larger high priority messages sent by User1 and User3, even though we have set the MaxHighPriorityMessageSize parameter to 250KB. This is to be expected, since we haven’t actually enabled the priority queuing feature yet. With this in mind, we can now repeat the test but this time with priority queuing enabled on the nghcloud.co.uk Exchange server. Don’t forget to restart the Microsoft Exchange Transport service after making the change.
The result of this test is shown in Figure 23 and this time we can see that the small message from User2 has indeed been received first. Therefore, with priority queuing enabled, the MaxHighPriorityMessageSize parameter does indeed ensure that high priority messages smaller than the configured size are processed before high priority messages that are larger than the configured size. Remember that this option does not alter the priority of the message as viewed by the recipient as you can also see from Figure 23.
Figure 23: Small High Priority Message Received First
To amplify the point, we can send a series of high priority test messages larger than 250KB and embed within the middle of these messages a single high priority test message that is smaller than 250KB. Again, the small message is delivered first as you can see from Figures 24 and 25.
Figure 24: Small High Priority Message Queued Amongst Large High Priority Messages
Figure 25: Confirming Small High Priority Message Received First
Summary
That completes our look at the priority queuing feature of Exchange 2010. If you have a need to ensure that Exchange 2010 processes messages based on the priority of that message, then do take the time to look at priority queuing. Don’t forget to take the time to also look at how large messages influence the processing within your system, perhaps taking the time to adjust the configuration as required.
If you would like to read the other parts in this article series please go to:
