In Exchange 2010, it is still possible to move mailboxes using both the Exchange Management Console and the Exchange Management Shell although there have been quite a few changes to the whole process.
Limitations to Moving Mailboxes in Previous Versions of Exchange:
Exchange 2007 uses the Move-Mailbox cmdlet to move mailboxes between mailbox databases. There are limitations to using this cmdlet:
- Mailbox moves are offline. While you move a mailbox, which can take several hours, the user can't access the mailbox.
- Moving mailboxes is synchronous. The cmdlet does the actual move, and you can't close the Exchange Management Shell session while the move is being performed.
- The Dumpster folder isn't moved with the mailbox.
- Content indexing doesn't begin until after the move is completed. This results in a poor search experience for users until the indexing is completed.
- Move throttling is manually controlled by administrators.
- Moving mailboxes across forests requires direct access to Active Directory and the mailbox database.
Advantages of Move Requests:
Move requests are a new feature in Exchange 2010. There are multiple advantages to using move requests:
- Mailbox moves are asynchronous and are performed by the Microsoft Exchange Mailbox Replication service (MRS).
- Mailboxes are kept online during the asynchronous moves. The items in a mailbox's Recoverable Items folder are moved with the mailbox.
- As soon as the mailbox move begins, content indexing starts to scan the mailbox so that fast searching is available upon completion of the move.
- You can configure throttling for each MRS instance, each mailbox database, or each Mailbox server.
- Remote mailbox moves work over the Internet by way of the Microsoft Exchange Mailbox Replication Proxy (MRSProxy) service. You don't need to set up a direct back-end server and Active Directory access between the forests.
- Mailbox moves can be managed from any Exchange 2010 server within the organization.
- Mailbox content doesn't move through an administrative computer. For example, in Exchange 2007, when you run the Move-Mailbox cmdlet, the data move is managed by the computer on which you run the cmdlet. You can't shut down that session of Exchange until the move completes.
- The mailbox's move history is maintained in the mailbox.
A move request is created by the Exchange administrator using either the Exchange Management Console or the Exchange Management Shell. In this article, I am going to concentrate on moving mailboxes within the same forest. This type of move is referred to as a local move request. When you move mailboxes across forests, these are referred to as remote move requests. Remote move requests may be covered in a future article here on MSExchange.org.
The cmdlets that are part of the move request are executed by the Microsoft Exchange Mailbox Replication Service which is a new service in Exchange 2010 that runs on the Client Access Server role.
The Move request puts a special system message into the system mailbox on the mailbox database. The MS mailbox replication service checks the contents of the system mailbox on each mailbox database to see if any move requests are waiting and then process them accordingly.
There are many benefits to having the mailbox moves carried out by this service. Below the main three areas:
1. Now we can move Mailbox online whilst the users are logged into them. If source mailbox is running Exchange 2007 SP2 or later or Exchange 2010.
2. Now all items of the dumpster are now moved as part of the process. In previous version of the Exchange moving mailbox did not the items in the dumpster and it was therefore required that the user had to recover any deleted items prior to the mailbox move.
3. The mailbox contents are no longer processed by the computer running the move process. It was often the case in Exchange 2007 that the move-mailbox cmdlet or associated script was run on an administrative machine rather than directly on the target Exchange 2007 server. In Exchange 2010 this situation will not be encountered since the mailbox moves are performed by the Microsoft Exchange Mailbox Replication service running on the Client Access Server.
It is very interesting that MS Exchange mailbox replication service on each client access server would affect the mailbox moved.
New-MoveRequest -Identity Ayla@contoso.com -TargetDatabase "DB02"
The following steps describe the basic process for local move requests:
- The command updates Active Directory, and then places a special message in the system mailbox within that Active Directory site that a move request has been initiated and is set to a status of Queued. Information about the move request is stored in two places: the target database's system mailbox and in Active Directory. If the move is an offline move, the mailbox is locked and can't be accessed until the move reaches a status of Completed.
- All instances of MRS periodically check the system mailbox on every database in its Active Directory site to verify if there are any queued move requests. In this example, the MRS instance on CAS01 finds Ayla's mailbox in the Queued status.
- MRS begins to move the data from DB01 to DB02. MRS updates the mailbox's status in the system mailbox to In Progress.
- When the move is almost finished, Ayla's mailbox is locked for a short time while the final mailbox synchronization is completed. At this point, the move request status changes to Completion In Progress.
- When the move is complete, Ayla's new mailbox on DB02 is activated, and the old mailbox on DB01 is soft deleted. The move request status changes to Completed. Depending on Ayla's e-mail client, she may need to log off and log on again to access her mailbox.
- The administrator clears the move request information from Active Directory and on the system mailbox on DB02. Until the move request information is cleared, you can't move the mailbox again.
New-MoveRequest -Identity Ayla@contoso.com -TargetDatabase "DB02"
Microsoft Exchange Mailbox Replication Proxy Service:
In addition to MRS, the MRSProxy service is installed on every Exchange 2010 Client Access server. MRSProxy helps to facilitate cross-forest move requests and runs on the remote forest's Exchange 2010 Client Access server. However, MRSProxy is disabled by default. You need to turn on the MRSProxy service on the remote forest by modifying the web.config file for the Client Access server on which you want to enable MRSProxy. We recommend that you enable MRSProxy on all Client Access servers in the remote forest.
Remote Mailbox Moves:
- The New-MoveRequest cmdlet prompts MRS on the Client Access server in the Contoso forest. The cmdlet updates the Contoso Active Directory information and the system mailbox on the target database. At this point, the move request status is Queued.
- To initiate the move, MRS in the Contoso forest communicates through MRSProxy in the Fourth Coffee forest. MRSProxy then updates the Fourth Coffee Active Directory information and the system mailbox on the remote database. At this point, the status changes to In Progress.
- The MRS server in the Contoso forest pulls Tony's mailbox data from the Mailbox server through the MRSProxy server in Fourth Coffee to the mail-enabled user firstname.lastname@example.org. At this point, the status is In Progress.
- When the mailbox move is almost complete, MRSProxy locks Tony's mailbox at Fourth Coffee for a short time while final synchronization is completed. At this point, the status is Completion In Progress.
- In the Contoso forest, MRS converts the mail-enabled user email@example.com to the mailbox firstname.lastname@example.org. In the Fourth Coffee forest, MRSProxy converts the mailbox email@example.com to the mail-enabled user firstname.lastname@example.org, and the mailbox is soft deleted. At this point, the status is Completed. Tony can now access his mailbox in the Contoso forest. Depending on Tony's e-mail client, he may need to log off and log on again to access his mailbox.
- The administrator clears the move request information from Active Directory and from the system mailbox. Until the move request information is cleared, you can't move the mailbox again.
New-MoveRequest -Identity 'email@example.com -RemoteLegacy -RemoteTargetDatabase DB03 -RemoteGlobalCatalog 'GC01.humongousinsurance.com' -RemoteCredential $Cred -TargetDeliveryDomain 'mail.contoso.com'
Remote Legacy Mailbox Moves:
If you're moving mailboxes remotely to or from Exchange 2007 or Exchange 2003 organizations, and those organizations don't contain an Exchange 2010 Client Access server, MRS in the Exchange 2010 forest will directly access the remote legacy database and the remote organization's Active Directory server. When performing a remote legacy move request, you must supply the following information in the command:
- Identity of the mail-enabled user
- RemoteLegacy switch
- Fully qualified domain name (FQDN) of the remote global catalog server
- FQDN of the external e-mail address created in the source forest for the mail-enabled user when the move request is complete
- Target database when moving mailboxes to Exchange 2010 or the remote target database when moving mailboxes from Exchange 2010 to the remote legacy database
The following describes a remote legacy mailbox move scenario:
- The legacy forest (Humongous Insurance) doesn't contain an Exchange 2010 Client Access server. This scenario is similar to the remote move request process. However, because the remote legacy forest doesn't have an instance of MRSProxy to connect with, MRS in the Contoso forest connects directly to the Humongous Insurance Active Directory server and system mailbox on the Exchange 2003 mailbox database.
- When you move Exchange 2003 mailboxes to Exchange 2010, the mailbox move will be offline. During the move, the users won't be able to access their mailboxes. When you move Exchange 2007 SP2 to Exchange 2010 mailboxes, the move will be online, and the users can access their mailboxes during the move.
- The following command is run from the target forest, Contoso.com.
New-MoveRequest -Identity 'firstname.lastname@example.org' -RemoteLegacy
-TargetDatabase DB02 -RemoteGlobalCatalog 'GC01.humongousinsurance.com' -RemoteCredential $Cred -TargetDeliveryDomain 'mail.contoso.com'