Clearing out mailbox move requests

After you’ve run Exchange 2010 for a while, you’ve probably moved a few mailboxes around and have accumulated some completed mailbox move requests.

When it begins to move a mailbox, the Mailbox Replication Service (MRS) stamps the user object for the mailbox with six attributes that it uses to indicate that the mailbox is being moved and the progress of the move. To reduce the interaction with Active Directory, only one of these attributes (the status) is updated during the move. The statistics for the move such as number of items moved, bytes moved, and so on are maintained in the XML coded move request that MRS updates in the system mailbox of the target database. Data used to construct the move report is also stored in the same place.

Once a move is completed, MRS copies the move report from the system mailbox to a hidden folder in the user’s mailbox. You might assume that the attributes are also removed (or cleaned up) in Active Directory, but this doesn’t happen. I believe that the logic here is that it’s up to the administrator to decide when the move request is no longer required, at which point they can explicitly go ahead and remove the request. The logic is valid but given the fact that most administrators don’t realize that move requests are silently piling up and not being removed, the end result is an accumulation of move requests just like calcium forming in a kettle in an area that enjoys hard water.

The first time when an administrator is likely to realize that move requests are retained and not cleaned out is when they attempt to move a mailbox that was previously moved by MRS. At this point, they’ll be told that a move request already exists for the mailbox and they will have to clear the move request before they are able to proceed. The Exchange Management Console (EMC) attempts to bring the fact that a mailbox has a move request registered to the attention of administrators by displaying a different icon for the mailbox, but as you can see below, it’s all too easy to miss this subtlety.

Spot the difference in the icons

Of course, EMC provides a separate section to allow administrators to work with move requests, so you can switch over there to discover what mailbox move requests are known to Exchange. As shown below, it’s easy to select all the move requests and then click “Clear Move Request” in the action pane. EMC will then clear the AD attributes from the selected mailbox objects and you’ll be able to create new move requests for them.

Getting ready to clear mailbox move requests

Of course, you don’t have to do this with EMC as Exchange 2010 provides a comprehensive set of cmdlets to work with mailbox move requests. The Get-MoveRequest cmdlet reveals the set of known move requests and we can filter the command so that EMS only reports the set with a completed status.

Get-MoveRequest -MoveStatus Completed

The other status values you can look for include the following:

• CompletedWithWarning: Although the mailbox was moved successfully, something happened during the move that an administrator needs to check by reviewing the move report.
• CompletionInProgress: Exchange is finalizing the move by resetting the Active Directory to reflect the new location for the mailbox.
• Failed: Whoops… not a good sign. Time to check the move report to discover what happened to stop the mailbox moving. Hopefully it’s something simple such as the mailbox quota for the target database being too low to accommodate the mailbox that you want to move. Another common problem is when some “bad items” are encountered in the source mailbox. These are items that Exchange considers to be corrupt or incomplete for some reason (often a bad MAPI property). You can force MRS to continue processing and ignore the bad items by setting a reasonable value (something higher than zero and lower than 10) for the BadItemLimit parameter when you create a move request. MRS is able to resume failed moves at the last checkpoint. Note that if you state a bad item limit higher than 50, you have to specify the AcceptLargeDataLoss parameter when you create the move request with the New-MoveRequest cmdlet. This is because MRS won’t write corrupt items into the new mailbox and each bad item is therefore dropped. You may just want to know what these dropped items contained! On the upside, they may be old calendar items that the user won’t care about. On the downside, they might be items relating to the latest corporate strategic plan…
• AutoSuspended: MRS has moved the bulk of the mailbox to the target database and is now paused waiting for an administrator to release the move request and allow MRS to perform a final synchronization to bring the new mailbox completely up to date and then switch the mailbox in Active Directory. Effectively, the move request is suspended before it enters the “CompletionInProgress” phase. You can resume processing with the Resume-MoveRequest cmdlet. You can instruct MRS to auto-suspend a mailbox move by passing the SuspendWhenReadyToComplete parameter to the New-MoveRequest cmdlet.
• Queued: The move request is queued and awaiting an MRS instance in its home site to “pick up” the request and take responsibility for its processing.
• InProgress: MRS is busy moving content from the source database to the target database to build the new mailbox. MRS spends most of the time processing a mailbox move in this status.
• Suspended: The move request has been suspended for some reason with the Suspend-MoveRequest cmdlet and is waiting for an administrator to release it. A move request can only be suspended before it reaches the final completion phase as once Exchange starts to update Active Directory, it’s too late to go back.

Once we have obtained a set of mailbox move requests, we can clear them with the Remove-MoveRequest cmdlet. To be most effective (and if you’re sure that you won’t remove any request that you want to keep), we can pipe the objects found with Get-MoveRequest to Remove-MoveRequest as follows:

Get-MoveRequest -MoveStatus Completed | Remove-MoveRequest

It’s a royal pain to have to perform this kind of housekeeping that Exchange should really be able to do on an automatic basis. I fully appreciate that some administrators may want to keep some mailbox move requests for an extended period, but it should be possible to have a parameter for the New-MoveRequest cmdlet to allow administrators to state an expiry time for a successful move request. Better again, maybe a new organization-wide configuration setting that applies to all successful move request with the ability for an administrator to override the organization wide setting so that a move request can be retained for a particular mailbox. Something like this would be good.

To set a 30 day automatic expiry for successful move requests:

Set-OrganizationConfig -DefaultExpirySuccessfulMR 30.0:00:00

To define that a move request does not automatically expire:

New-MoveRequest -DoesNotExpire $True

Of course, the official health warning is that I have no idea whether these enhancements will ever appear in a future version of Exchange. Christmas is coming and you never know what the Exchange developers have up their collective sleeves. We wait in hope…

Tony

Follow Tony @12Knocksinna

For more information about the Mailbox Replication Service and how mailbox moves work in Exchange 2010, see Microsoft Exchange Server 2010 Inside Out, also available at Amazon.co.uk.