Using CompleteAfter to Manage Automatic Completion of Mailbox Move Requests

When Exchange Server 2010 brought us the miracle of online mailbox moves there was much rejoicing, for it meant no longer burdening our users with lengthy outages while their mailboxes were moved. However, the online mailbox move process was not without some minor disruption, as the very last stages of processing for a move request involved a brief outage while the final cut over of mailbox data and Active Directory attributes is completed.

For migrations and general capacity management moves the standard approach for performing mailbox moves with the least disruption to end users usually went like this.

1. Start some move requests or a migration batch
2. Wait for the migration to suspend when it is ready to complete
3. Initiate the completion of the migration at a time that is least convenient for users

That last step either meant an administrator logging in late one evening or weekend to manually initiate the completion, or for more capable organizations an automated script would run, check for moves that are suspended ready to complete, and initiate the completion.

Now there’s a better way. In fact this has been available since Exchange Server 2013 CU7 (December 2014), according to an email I dug up. In CU7 (or thereabouts), a new CompleteAfter parameter was added to the New-MoveRequest cmdlet. The new parameter lets you specify a date and time that the move request will wait for until it completes. Microsoft now recommends using this parameter instead of the SuspendWhenReadyToComplete parameter that was used previously (it’s still available though).

Here’s an example of CompleteAfter in action, moving the mailbox for “Mahera Bawa”, and specifying a CompleteAfter time and date of 2:00am on February 23rd (in US date format). The CompleteAfter parameter requires UTC time and date, so the easiest approach is to convert a local time into UTC as shown below.

[PS] C:\>New-MoveRequest -Identity Mahera.Bawa -CompleteAfter (Get-Date "2/23/2017 2:00 AM").ToUniversalTime()

I left the move request to run, and checked it again the next day. The move request statistics tell the story of what happened.

[PS] C:\>Get-MoveRequest "Mahera Bawa" | Get-MoveRequestStatistics | Select *TimeStamp


QueuedTimestamp                  : 2/22/2017 2:10:33 PM
StartTimestamp                   : 2/22/2017 2:18:15 PM
LastUpdateTimestamp              : 2/23/2017 2:04:14 AM
InitialSeedingCompletedTimestamp : 2/22/2017 2:30:43 PM
FinalSyncTimestamp               : 2/23/2017 2:01:04 AM
CompletionTimestamp              : 2/23/2017 2:04:13 AM
SuspendedTimestamp               :
FailureTimestamp                 :

The move requested started at 2:18pm, completed initial seeding at 2:30pm, and then waited until 2:01am the next day before it automatically completed (which only took a few minutes).

As you can see, using CompleteAfter to control the completion of mailbox move requests is quite simple, and makes it very useful for migration scenarios or any time you’re trying to move a mailbox with the least impact on a user. The only caveat is that you need to be fairly confident that the move requests will be ready to complete at the time you specify. If the mailbox move in my example was still doing the initial seeding well into business hours the next day, it would have proceeded to completion and potentially disrupted the user for a few minutes. That’s a risk you can manage with proper planning and by understanding typical move performance in your environment.