In Exchange 2000, 2003 and 2007 mailboxes become unavailable during movement. Exchange internally performs a MAPI copy operation using the function IMapiProp::CopyTo() and to ensure that no data is lost, it locks the mailbox.
Exchange 2010 came up with a new wonderful feature called 'Online Mailbox Move' that allows end-users to be online in their email accounts. On completing the move users just needs to reopen their Outlook clients.
Mailbox Move Requests are a new feature set of Exchange 2010 and requires running a series of Cmdlets to perform asynchronous online mailbox moves with the help of a service agent called Mailbox Replication Service (MRS). MRS is available on all Exchange 2010 Client Access Servers.
Note: Online mailbox moves are only supported in the following scenarios while moving mailboxes within the same forest or across forests.
- Between two Exchange 2010 databases
- From Exchange 2007 SP2 database to Exchange 2010 database
Let's start with a simple move request in EMC to understand the procedure performed for a mailbox move.
Move Requests in EMC
We can select one or a list of mailboxes to be moved. To execute the move, select "New Local Move Request" from the Action Pane, or from the context menu that pops-up on right-clicking the selected mailboxes.
Select the target mailbox database where you want to move the mailbox.
Once you select Move, the operation is completed in less than a second. All it does is to update the job information in AD, the System Mailbox of the target database and initiates MRS to start the movement. Later MRS performs the asynchronous mailbox moves in the background.
You can see the status of a move request in 'Recipient Configuration | Move Request'. Initially the status shows 'Queued' since we just created the move request.
When any one of the MRS instances picks up the request, the status changes to 'Moving'.
We can check the properties of the Move Request to see detailed information.
Once the move is finished, the status will be changed to 'Completed'.
When movement is completed the end user will receive a message to restart his Outlook client.
OWA is pretty simple; it just pops an Error reporting that it needs to be closed to gain mailbox access.
At last, upon completion, we need to clear the move request using 'Clear Move Request', otherwise we would not be able to initiate another move request for the same mailbox.
Configuring the Mailbox Replication Service (MRS)
MRS can be configured to throttle the move requests. All settings are stored in a configuration file named MSExchangeMailboxReplication.exe.config. This is located under:
<Exchange dir.>\bin
We can configure various properties for throttling, such as the maximum movement per source/target database, the maximum movement per source/target server and many others depending on the capacity of the server. However I would follow the default configuration that is tested and configured to give optimum performance by Microsoft.
All MRS instances in an AD site work together to ensure that throttling is being followed as per the configuration and also to make sure that a move request is not picked up by more than one MRS instance. MRS constantly searches for all move requests in its own AD site.
Move requests can handle server failures efficiently by checking the status of the target database every 5 minutes during the move operation. If a database is non-operational, MRS will take a nap of 30 seconds and retries. In case the destination changes due to a failover, MRS will detect the new database location and restarts the move.
Move Requests in EMS
Let's take a deep dive on what a move request does internally when executing cmdlets in EMS.
Scenario: I have a single Exchange Server with FQDN Ess-Exch.ExchangeShare.net and two databases Ess-Exch-DB1 and ESS-Exch-DB2. I am trying to move Amit Tank's mailbox from Ess-Exch-DB1 to Ess-Exch-DB2 using the New-MoveRequest cmdlet. Here I also include the -Verbose parameter to see what's happening internally.
Just like all other Exchange cmdlets, the following is first performed on running New-MoveRequest:
Next New-MoveRequest starts working on the actual move request:
Verify the number of move requests currently running, to make sure MRS throttling is being followed in the same AD site where the mailbox database is available
Connect to one of the MRS instances within the AD site where the destination mailbox database is available
Now it starts updating the move job information,
Updates the move job information at the System Mailbox (GUID 01613a2a-...) of the target database 'Ess-Exch-DB2' with a special message to move Amit Tank's mailbox (GUID 4bceb069-...) and update the status to 'Queued'.
Also update the same information and status in Active Directory.
So the move request information will be available from two repositories, at the target database System Mailbox and within Active Directory.
These are the AD attributes being updated during the move process.
Now we look at the background work performed by MRS. We can see the whole operation by increasing the diagnostic logging for "MSExchange Mailbox Replication\Mailbox Move" process to Highest. A series of event logs will be logged at the Application event log.
An asynchronous mailbox move will generate events with the IDs:
- Event ID 1102 - Started processing mailbox moves.
- Event ID 1104 - Started initial seeding stage.
- Event ID 1105 - Completed initial seeding stage.
- Event ID 1109 - Completed incremental synchronization cycle.
- Event ID 1106 - Initiating final (offline) synchronization stage.
- Event ID 1107 - Completed a mailbox move.
Note: By default Diagnostic Logging of "MSExchange Mailbox Replication\Mailbox Move" is set to lowest and in that case you can see 1102 & 1107 events only.
Below, we can see the event logs generated for our sample mailbox move.
When MRS searches for new move requests, it picks up the queued job and starts the mailbox move process. (Event ID: 1102)
MRS connects to the mailbox directly with Mapi.net and starts performing the initial seeding of the mailbox to the target database without interrupting user mailbox access. (Event ID: 1104)
Update the status in AD and System Mailbox to 'InProgress'
We can see the status with Get-MoveRequest.
After completing the initial seeding (Event ID: 1105), MRS starts an incremental synchronization cycle (Event ID: 1109) that moves all transactions to the target mailbox. In this manner actions performed against the source mailbox following the initial seeding are replicated at the target.
The mailbox will be locked for a short period of time upon completion of incremental synchronization (Event ID: 1106). Thus the user needs to log off and log back on the outlook client with new mailbox location.
Status will be updated with 'Completed' in AD and System Mailbox.
Now the Administrator needs to clear the move request with the Remove-MoveRequest cmdlet which will clear the information from AD and System Mailbox.
New in Exchange 2010 Move Requests
Apart for the ability to perform moves online, here are more improvements that Exchange 2010 delivers:
Move history and report information is saved into the mailbox so we can get details with the help of IncludeMoveHistory and IncludeMoveReport parameters of Get-MailboxStatistics cmdlet.
Dumpster (Deleted Items retained as per retention settings) is moved along with the mailbox when moving between Exchange 2010 databases.
Content Indexing start scanning mailboxes along with mailbox moves so fast search is available upon move mailbox completion.
Conclusion
In earlier Exchange versions, administrators had to move mailboxes during a scheduled outage window, perhaps during night time. However this was problematic when a firm is operational 24x7 and end users cannot tolerate mailbox unavailability. The new Exchange 2010 'Online Mailbox Moves' feature relieves administrators, allowing mailbox moves with near zero downtime.
References
Understanding Move Requests
Managing Move Requests
Move Requests Cmdlets