I gave Microsoft a hard time last week when news broke that Exchange 2010 SP2 RU1 contained a bug that prevented Client Access Servers (CAS) running SP2 RU1 in external-facing Active Directory sites proxying Outlook Web App (OWA) connections to CAS servers in internal sites that ran other baselevels of Exchange 2010. The problem was caused by a change in the format of the cookie used by the servers when they communicate with each other and is quickly addressed by making sure that SP2 RU1 is used on CAS servers everywhere. Even so, a lingering doubt remains that this is yet another problem that should not have crept through Microsoft’s testing process. After all, do the folks in Redmond assume that customers deploy new software everywhere at once?
In any case, even if we don’t like being forced to upgrade server software to fix a problem that should not exist, there is a benefit to be gained from deploying Exchange 2010 SP2 RU1 to CAS servers: once done, you can now prioritize mailbox move requests for processing by the Mailbox Replication Service (MRS).
As you probably know, MRS is the service that’s responsible for picking up mailbox move requests and processing them in the background until the new mailbox is fully-populated and ready to use. At that time, MRS switches the pointers to the mailbox in Active Directory and clients can connect to the new mailbox. See this EHLO article for more information on what happens behind the scenes when MRS processes mailbox move requests.
I think that MRS is one of the success stories of Exchange 2010 and is certainly a huge contributor to Microsoft’s ability to be able to move customers to either on-premises Exchange 2010 or to Exchange Online in Office 365. Given the ever-swelling size of mailboxes and the promise that mailboxes will only get larger over time, the old method used up to and including Exchange 2007 of transferring mailbox contents in real time had long passed its best-before date. Users simply won’t wait for mailboxes to be moved in an always-connected world.
But MRS is somewhat simple at the way that it picks up new move requests for processing. No move request is better than another in the eyes of MRS, so the high-profile move of the CEO’s mailbox receives no extra attention than the move of the most humble factory worker’s mailbox and short of stopping all active move requests to allow MRS to eventually select and action a high priority move request, no way existed for an administrator to control the move request queue. Some might regard this as a suspiciously communist kind of implementation!
Happily the MRS developers slipped some new code into Exchange 2010 SP2 RU1 to enable move request prioritization. It’s unusual to find new functionality appear in a roll-up update unless it is absolutely necessary to address a particular problem. Request prioritization doesn’t seem to be in this category so I assume that this work was done to help Microsoft prioritize move requests for its own purposes, probably in transferring customer mailboxes from on-premises Exchange to Office 365. I understand that the change has actually been active in the software used for Exchange Online for the last year so we can assume that the update is extremely solid at this point.
The details of the change are as follows: the default priority for mailbox move requests is “Normal”. Exchange 2010 SP2 RU1 allows an administrator to set a “High” priority for a move request when it is created with the New-MoveRequest cmdlet. Note that all mailbox move requests created with the Exchange Management Console (EMC) have normal priority. You can only create high-priority mailbox move requests with the Exchange Management Shell (EMS). For example:
New-MoveRequest -Identity 'CEO Mailbox' -Priority High -TargetDatabase 'VIP Mailboxes'
When MRS looks for new move requests that are waiting to be processed, it first sorts the requests by priority and then by LastUpdatedTimeStamp (a field indicating the last time that the move request was processed by MRS). High priority move requests are therefore selected by MRS before normal-priority move requests. The request priority is included in the msExchMailboxMoveFlags attribute.
MRS does not halt processing normal-priority move requests when a high-priority mailbox move is initiated. The only time when priority is used is when MRS selects the next move request to process.
A move request’s priority can be changed with the Set-MoveRequest cmdlet. However, MRS will not respect an altered priority unless a move request is halted with the Suspend-MoveRequest cmdlet and then resumed with the Resume-MoveRequest cmdlet. You can also filter move requests with the Get-MoveRequest cmdlet to look for high priority moves (a new –HighPriority:Boolean flag is available).
I love when simple changes make a difference. This is one such change. And while it doesn’t quite take away the pain caused by another testing snafu for an Exchange roll-up update, it does dull the ache quite significantly!
