A discussion on this point recently took place via the Exchange MVP mailing list. It doesn’t contain anything secret and I think it’s worth documenting for the benefit of others, so here goes…
As you might know from this post or other sources, you can ask the Mailbox Replication Service (MRS) on an Exchange 2010 server to auto-suspend a mailbox after the bulk of its content has been copied over to the database that will host the new mailbox. This occurs when you pass the SuspendWhenReadyToComplete parameter to the New-MoveRequest cmdlet. Administrators often use this feature to have MRS copy mailbox content overnight and to allow them to check the move report before they release the request with the Resume-MoveRequest cmdlet to complete the mailbox move.
Essentially what happens is that MRS takes an initial enumeration of all the content in the source mailbox and copies it to the database that will hold the new mailbox. When the copy is complete, the new mailbox contains all of the data that existed in the old mailbox when the copy commences. Of course, changes might have occurred in the source mailbox after MRS enumerated the content and that’s why MRS performs an incremental synchronization to discover and copy the changed content just before it switches the Active Directory pointers for the mailbox to complete the move. The incremental synchronization (or ICS) is done using the same techniques as Outlook exploits to populate a local OST with slave copies of the folders in the server-based mailbox.
Auto-suspension happens before the final synchronization. A mailbox move request that is auto-suspended can remain in this state as long as you desire. Exchange 2010 doesn’t include any functionality to “clean up” old suspended move requests after a particular period. It’s entirely possible that you might have some move requests suspended and awaiting release for weeks at a time (see this post for more information about cleaning up move requests). However, there are two points that need to be considered:
- The longer you leave a move request suspended, the more changes are likely to occur in the source mailbox. The final incremental synchronization will therefore take longer. In reality, this shouldn’t be a major problem for intra-organization moves as MR should be able to quickly synchronize the source and new mailboxes to complete the move. Things might take a little longer with a cross-forest move.
- If a move request is suspended for more than the deleted mailbox retention period, the Store will remove the new mailbox in the target database. This is because the Store considers this mailbox to be “disconnected” as no mailbox owns it. Disconnected or deleted mailboxes are automatically removed by the Store after their retention period expires (usually 30 days). You can remove a mailbox from the Store when you delete it with the Remove-StoreMailbox cmdlet (in SP1) or by passing the Permanent switch to the Remove-Mailbox cmdlet (previous versions). Removing the new mailbox isn’t a huge disaster as MRS will recreate it if it finds that the new mailbox doesn’t exist when the move request is eventually resumed. If this happens, MRS will recreate the new mailbox from scratch and populate it as before before proceeding directly to the final synchronization.
I doubt that many people will leave move requests in a suspended state for more than a few days, except by accident or after they have forgotten that a move request was created with the SuspendWhenReadyToComplete flag. But it’s nice to know how MRS deals with the issue should it arise.
– Tony
For more information about how MRS works in Exchange 2010, you might consider reading chapter 12 of Microsoft Exchange Server 2010 Inside Out
Thoughtsofanidlemind's Blog 
Leave a comment