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 
Hi Tony,
Good to read that an Exchange Admin can decide to keep the ‘autosuspended’ mailbox request as long as he/she wants. One question: Is there a possibility to incremental update the ‘moving’ mailbox but leave it in the ‘autosuspend’ state if the changes are replicate?
If I read your question correctly, the answer is no. MRS will pause the move request after the originally enumerated content has been copied to the new mailbox and will auto-suspend the request until it is released by an admin. It is only then that the incremental synchronization will be performed to bring the new mailbox fully up-to-date before the mailbox pointers are switched in Active Directory. It’s a one-time operation.
TR
Hi Tony,
Thanks for your answer.
regards,
Kees
If I was to kick off a move of lets say 250 mailboxes and choose the option to suspend when completed, would MRS go ahead and copy (as it saw the mailbox at the time of kick off) the contents of all those mailboxes? I’m wondering if it only does a few of them or would it do all of them, and then we could go in and check to “resume” all of them, copying the changes on all 250 mailboxes. Thanks in advance
MRS will begin to process the 250 requests as they are queued and will process as many of the requests as it can based on the configuration file. Each MRS instance (on a CAS) will be throttled back based on the parameters in the configuration file and is limited to the number of active requests per source database, target database, and so on. As requests are processed to the 90-95% limit, they will be suspended and other requests will become active until the 250 are processed. You can resume suspended requests at any time.
TR
Tony,
Thanks for the quick response, much appreciated. Great explanation.
Regards,
Ryan
We are looking at this “suspend” feature as a migration tool, where we could kick off a move of lets say 250 or 300 mailboxes and have them all suspended before completed. Then over a weekend, actually let them all complete (mailbox sync) and “flip the switch” so to speak so that users can come in and reconnect to the new domain. Sounds like this feature will really help us in this insance.
Yes, that’s how many large organizations schedule mailbox moves to be performed. First, silently in the background to reach the suspend point during the working week and then resumption at the weekend to execute the final synchronization and flip the bits. It all works very well. Remember that a move request can be suspended for up to 30 days… more than enough time to check everything out and to prepare for the changeover.
TR
We are trying the “suspendwhenreadytomove” flag on our cross-forest mailbox move and after the mailboxes reach the “AutoSuspended” state, the users are being disabled. The users are not actually disabled in the Domain Controller, however, when the users try to login into their PC’s, it says they are disabled. Why is this happening?
Hi there,
We had mailbox move from EX2003 to EX2010 suspended because we ran out of disk space on the Log folder on EX2010 server. Everything is back to normal ever since the backup job flushed the log folder. It has been over 4 days that those mailboxes have been suspended. Would be wise to just remove the move request and start new or resume it? BTW those mailboxes are 90 GB each and currently at 85% completion.
Thanks,
Don
Can you resume the move request?
Hi,
We are moving mailboxes from exchange 2003 to exchange 2010. We suspended few mailboxes and now want to reboot the server.
Is the suspended mailbox will resume properly?
Sure. Move requests shouldn’t be affected by a reboot.
Hello just to be clear the if AutoSuspend Mailboxes extends beyond the 30day delete period, the mailbox is ONLY deleted off of the target database, correct? The user would not experience an outage as they are still pointed to the source mailbox.
Right. It’s only the now-obsolete target mailbox that is removed. The user continues to work uninterrupted.
Hi Tony, great article. Do you happen to know whether the MailboxRetention period is still valid for autosuspended mailboxes in EX10 SP3 RU10? I ran into this article by looking for something else. We are about to migrate 1 MBX server from Brazil to Europe and have initiated the moverequests January 4th, but the scheduled resume date will be February 5th (32 days and MailboxRetention is configured at 30 days). Would increasing from 30 to let’s say 45 days save us or should I redo the mailbox moves? It’s to much data to sync in one weekend (took us 6 days 24hrs/day to do the inital sync and we already have a 90 GB delta.
Thanks in advance!
Best regards,
Dennis
Do you mean the retention period on the databases?
Yes that;s what I mean. When I look at the targetdatabase with get-mailboxstatistics I can see the prepared new mailbox but the $_.Disconnectreason is empty.Usually it’s only empty when it’s an active mailbox. Could it be that in pre SP3 RU10 versions the $_.Disconnectreason value was “disconnected” in case of a staged mailbox?
I cannot find any references to this subject.
Thanks,
Dennis
I don’t honestly know. I don’t have an Exchange 2010 server to test. Maybe the best idea is to log a support call with Microsoft?
Thanks for replying anyway!
Hi Tony,
We have created migration batch of 300 users in office 365. The batch is currently is Synced State. All the move request are in Autosuspended State. We have incremental Sync running. We are planning to Resume the move request after 35 days. Will this work? I am afraid after reading this article.
It depends on the deleted mailbox retention period for the database. As the article says:
“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.”
So, if the retention period is 30 days, suspending a move for 35 days will cause the entire mailbox to be copied from scratch.