I recently did a migration from Exchange 2007 to Exchange 2010. We staged every mailbox move to use the SuspendWhenReady parameter on the New-MoveRequest to ensure that when we finally resumed the paused mailbox move everything should go as fast as possible.
Everything went OK, mailboxes started to move and when they reach 95% the suspended themselves. We did this for all approx. 5000 mailboxes and after a few days everything had been synchronized.
When time struck "migration" we started of by resuming about 100 mailboxes to see how the system responded. Whoa did we get a surprise, everything on the old Exchange 2007 server come to an almost complete freeze, it was almost unusable. We had some concerns with the old server since it was overloaded even before we started move mailboxes but we never thought it would be this bad.
Some hours of investigation and troubleshooting we discovered that when we kick of several hundreds of suspended mailbox moves the old server freeze but when we did 5 to 10 at a time everything worked as it should and with reasonable speed.
We didn't want to spend 24 hours manually resume 10 suspended mailbox moves every minute so I created a short EMS script that did it for us.
While ($True)
{
Get-Date
$nr = (Get-MoveRequest -ResultSize unlimited -MoveStatus InProgress).Count
"moverequests " + $nr
if ($nr -lt 2)
{
Get-MoveRequest -MoveStatus AutoSuspended | Select -First 10 | Resume-MoveRequest
}
Sleep 60
"-"
}
script runs in an endless loop, printing date and time to EMS window, calculate how many ongoing move-requests we have and when it is below 2 we fire of and resume 10 more. Finally a pause for 1 minute and do it all over again.
You might need to tweak this a bit by changing timeout and number of move requests to resume. In my case values in script worked fine but if you have an Exchange 2007 server that is not as squeezed then you might be fine with other values.
