[
This topic's current status is: Editing.]
Applies to: Exchange Server 2010
Topic Last Modified: 2009-10-26
When moving a mailbox, you are moving a mailbox from a source mailbox database to a target mailbox database. The target mailbox database can be on the same server, on a different server, in a different domain, in a different active directory site, in another forest, or to Outlook Live.
.gif) Note: |
|---|
|
This topic does not cover moving mailboxes to or from Outlook Live.
|
Cautions and Prerequisites to Moving Mailboxes
-
You can't use the Exchange System Manager or Active Directory Users and Computers to move mailboxes from Exchange 2003 to Exchange 2010.
-
You can't use the Move-Mailbox cmdlets in Exchange 2007 to move mailboxes from Exchange 2007 to Exchange 2010.
-
When you move mailboxes, the user will lose the ability to view their message tracking information.
Advantages to move requests
Move requests are a new feature in Exchange 2010. Creating a move request consists of running a series of cmdlets that perform the move request. There are multiple advantages to using move requests to perform the move:
-
Moving the mailboxes is asynchronous and is carried out by the Mailbox Replication Service.
-
Mailboxes are kept online during the asynchronous moves.
-
The mailbox's Recoverable Items are moved with the mailbox, which is available only in Exchange 2010.
-
Fast search is available upon completion. As soon as the mailbox begins to move, 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 MSProxy. 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 anywhere within the organization.
-
Mailbox content doesn't move through an administrative machine.
-
The mailbox's move history is maintained in the mailbox.
Asynchronous Mailbox Moves
In Exchange Server 2007, when you use the Move-Mailbox to move a mailbox, the cmdlet logs into both the source database and the target database and moves the content from one mailbox to the other mailbox. While the cmdlet is running you can't close the Shell until the command completes. If you close the Shell during the move, the move will fail. The move process can take several hours to complete.
The new Move Request cmdlets can perform an asynchronous move because the cmdlets do not perform the actual move. The move is performed by the Microsoft Exchange Mailbox Replication Service (MRS), which is a new service running on all Exchange 2010 Client Access servers in your organization. The New-MoveRequest sends a request to MRS. The benefit of using the service is that it enables you to manage mailbox moves from anywhere within the organization after the move request is placed. For more information, see the Mailbox Replication Services section later in this topic.
Online Mailbox Moves
In an online mailbox move, the mailbox is moved while the end-users can still access their e-mail accounts and the account only locks out the user for a very brief time during the end of the process when the final synchronization occurs. Online mailbox moves are only supported between Exchange 2010 databases, and between Exchange 2007 SP2 and Exchange 2010 databases. You can perform an online mailbox move across forests or in the same forest. The process for a local mailbox move and a remote mailbox move differ and are outlined later in this topic.
Reasons for Moving Mailboxes
The following scenarios list the reasons for moving mailboxes:
-
Transition When you transition an existing Exchange 2007 or Exchange Server 2003 organization to Exchange 2010, you will move mailboxes from the existing Exchange servers to an Exchange 2010 server that has the Mailbox server role installed.
-
Realignment You can move mailboxes to realign based on specific values. For example, you may want to move a mailbox from one database to a database that has a larger mailbox size limit.
-
Investigating an issue If you need to investigate an issue with a mailbox, you can move that mailbox to a different server. For example, you can move all mailboxes that have high activity to another server.
-
Corrupted Mailboxes If you encounter corrupted mailboxes, you can move the mailboxes to a different server or database to leave the corruption behind. The corrupt messages will not move.
-
Physical location changes You can move mailboxes to a server that is in a different Active Directory site. For example, if a user moves to a different physical location, you can move that user's mailbox to a server that is in a site nearer to the new location.
-
Separation of administrative roles A company may want to separate the administration of Microsoft Exchange from the administration of Microsoft Windows accounts. To do this, you can move mailboxes from a single forest into a resource forest scenario. With this scenario, the Microsoft Exchange mailboxes reside in one forest and their associated Windows user accounts reside in a separate forest.
-
Outsourcing e-mail administration A company may want to outsource the administration of e-mail and retain the administration of Windows user accounts. To do this, you can move mailboxes from a single forest into a resource forest scenario. With this scenario, the Microsoft Exchange mailboxes reside in one forest and their associated Windows user accounts reside in a separate forest.
-
Integrating e-mail and user account administration A company may want to change from a separated or outsourced e-mail administration model to a model in which e-mail and user accounts can be managed from within the same forest. To do this, you can move mailboxes from a resource forest scenario to a single forest. With this scenario, the Microsoft Exchange mailboxes and Windows user accounts reside in the same forest.
Moving Mailboxes between Exchange 2010 and Previous Versions of Exchange
Depending on whether you are moving mailboxes across forest or moving the mailboxes within the same forest, there are different scenarios for the method of moving the mailboxes.
| Note: |
|---|
|
Moving mailboxes from Exchange 2000 to Exchange 2010 isn't supported.
|
For more information about moving mailboxes between Exchange 2010 and previous versions of Exchange, see the following topics:
Table 1 Supported mailbox move scenarios
|
Moving From - To
|
Supported
|
Online
|
|
Exchange 2010 to Exchange 2010
|
Yes
|
Yes
|
|
Exchange 2007 SP2 to Exchange 2010
|
Yes
|
Yes
|
|
Exchange 2007 SP1 to Exchange 2010
|
No
|
Not Supported
|
|
Exchange 2003 SP2 to Exchange 2010
|
Yes
|
No
|
|
Exchange 2010 to Exchange 2007 SP2
|
Yes
|
No
|
|
Exchange 2010 to Exchange 2003 SP2
|
Yes
|
No
|
Mailbox Replication Service
When you use the Move Request cmdlets to perform the mailbox move the move will be conducted by MRS. As stated previously, MRS resides on an Exchange 2010 Client Access server and is the service that moves mailboxes from the source database to the target database. In Exchange 2007, the mailbox move was performed by the actual Move-Mailbox cmdlet. Using a service as the agent of the move allows you to move mailboxes asynchronously while they remain accessible to the user. During the move, you maintain the ability to view, cancel, and manage the move request from any Exchange 2010 server in your organization.
You can start and stop the Microsoft Exchange Mailbox Replication service as you would any service. MRS constantly checks for all move requests in its own active directory site. In addition, there is a sharing mechanism between all instances of MRS so that no two servers will attempt to perform the same move request.
All MRS instances in an Active Directory site work together to ensure that the database and Client Access server throttling is respected across all instances of MRS. MRS throttline is controlled by a configuration file. The default location for the configuration file can be found in the same location where Exchange was installed:
<Exchange Installation Path>\V14\Bin\MSExchangeMailboxReplication.exe.config.
You can control the following properties:
-
MaxActiveMovesPerSourceMDB This property indicates the number of mailboxes that can be moved on the source mailbox database at one time. The default value is 5 concurrent moves.
-
MaxActiveMovesPerTargetMDB This property indicates the number of mailbox moves that can be moved on the target mailbox database at one time. The default value is 5 concurrent moves.
-
MaxTotalMovesPerMRS This property indicates the number of mailboxes that can be moved by a single instance of MRS. The default value is 100 concurrent moves.
-
MaxActiveMovesPerTargetServer This property indicates the total number of moves that can occur on the target server at a given time. The default value is 5 concurrent moves.
-
MaxActiveMovesPerSourceServer This property indicates the total number of moves that can occur on the source server at a given time. The default value is 5 concurrent moves.
-
MaxMoveHistoryLength This property indicates the maximum number of move histories to maintain in the mailbox. The default value is 2 move histories per mailbox.
-
FullScanMoveJobsPollingPeriod This property indicates how often each instance of MRS will scan for new move requests. The default value is 10 minutes.
MRSProxy
In addition to MRS, the Mailbox Replication Proxy service is installed on every Exchange2010 Client Access server. MRSProxy helps to facilitate cross-forest move requests and MRSProxy runs on the remote forest's Exchange 2010 client access server. However, by default, MRSProxy is disabled. You will need to turn on MRSProxy 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 CAS servers in the remote forest. The configuration file can be found in the same location where Exchange was installed:
<Exchange Installation Path>\V14\ClientAccess\ExchWeb\EWS\web.config
Open the file with a text editor, such as Notepad and locate the section MRSProxyConfiguration and edit IsEnabled to equal "true".
When MRSProxy is turned on, you can connect to the end point with a Web application, such as Internet Explorer by using the following URL:
https://<CASServerName>/ews/mrsproxy.svc
| Note: |
|---|
|
Replace CASServerName with the name of the Client Access server on which you enabled MRSProxy. If you get a "Page not found" error, MRSProxy is not enabled on that server.
|
For more information about MRSProxy and how it helps to facilitate remote move requests, see Remote Mailbox Moves with Exchange 2010 in both Forests later in this topic.
Basic Move Request Process
-
The following figure and explanatory text that follows describe the basic local move request process.
In this scenario, Ayla's mailbox is going to be moved from the source database DB01 on mailbox server MBX03 to the target database DB02 on MBX01 by running the following command:
New-MoveRequest -Identity Ayla@contoso.com -TargetDatabase "DB02"
-
The cmdlet updates active directory and then places a special message to the system mailbox within that Active directory site that a move request has been initiated and the move 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.
-
All instances of MRS periodically check the system mailbox on every database in its Active Directory site to see if there are any queued move requests. The MRS instance on CAS01 finds Ayla's mailbox in the Queued status.
| Note: |
|---|
|
The New-MoveRequest cmdlet will choose an instance of MRS and ask it to process the move request immediately. If the selected instance of MRS is available, it will pick up the move immediately. If not, the mailbox will wait in the queued status until an MRS instance finds the move request.
|
-
MRS begins to move the data from DB01 to DB02. MRS updates the mailbox's status in the system mailbox to InProgress.
-
When the move is almost finished, Ayla's mailbox will be locked for a short time while the final mailbox synchronization is completed. The status of the mailbox changes to CompletionInProgress.
-
When the move is completed, Ayla's new mailbox on DB02 is activated and the old mailbox on DB01 is deleted. The move request status changes to Completed. Ayla can now access her mailbox after she logs off and logs back on.
-
The administrator clears the move request information from Active Directory and on the system mailbox on DB02 by running the Remove-MoveRequest command, either in the Shell or in the EMC. Until the move request information is cleared, you can't move the mailbox again.
A record of the move is kept in Ayla's mailbox and can be accessed by running the Get-MailboxStatistics cmdlet with the IncludeMoveReport parameter.
Remote Mailbox Moves
Remote mailbox moves are also known as cross-forest mailbox moves. There are two types of remote mailbox moves that Exchange 2010 supports:
-
Remote mailbox moves that have Exchange 2010 in both forests
In this scenario, one forest is an Exchange 2010 forest and the other forest has at least one Exchange 2010 Client Access server. You can use the Exchange Management Console (EMC) or the Exchange Management Shell to perform these mailbox moves. For more information, see Create a Remote Move Request that has Exchange 2010 in Both Forests.
-
Remote mailbox moves with a legacy Exchange forest
In this scenario, one forest contains Exchange 2010 and the other forest contains Exchange 2003 Service Pack 2 (SP2), Exchange 2007 SP2, or a combination of both. There is no Exchange 2010 Client Access server installed in the legacy forest. You can't use the EMC to perform these mailbox moves. You must use the Shell. For more information, see Create a Remote Legacy Move Request Where One of the Forests Doesn't Have Exchange 2010.
Prerequisites for moving mailboxes across forests
Using the TargetDatabase and RemoteTargetDatabase parameters
In the New-MoveRequest cmdlet, there are two parameters that identify the target database that you are moving mailboxes to.
-
TargetDatabase This parameter specifies the identity of the database that you're moving the mailbox to. You will use this parameter to perform local and remote mailbox moves when you are initiating the move from the target forest.
| Note: |
|---|
Using the TargetDatabase parameter is optional. When this parameter is not specified, the mailbox provisioning load balancer will provide the command with a Target Database to move the mailbox into. If you want to turn off automatic selection of a mailbox database, you need to use the TargetDatabase parameter in the New-MoveRequest command or you will need to configure the databases that you want excluded from provisioning by setting the IsExcludedFromProvisioning parameter to $true in the Set-MailboxDatabase cmdlet.
|
-
RemoteTargetDatabase This parameter specifies the name of the target database in the remote forest. You will use this parameter for remote mailbox moves only when you need to initiate the move from the source forest.
When you initiate a remote mailbox move, you should do so from the target forest where Exchange 14 resides and you need to use the TargetDatabase parameter. In this case, the mailbox replication service pulls the mailbox from the source forest to the target forest.
If you are moving a mailbox from an Exchange 2010 server to a Mailbox server on Exchange 2007 or Exchange 2003, you will need to initiate the move from the Exchange 2010 forest, which is the source forest. When you initiate a move from the source forest, the mailbox replication service pushes the mailbox from the Exchange 14 server to the Exchange 2007 server.
When initiating moves from the source forest or "pushing" the mailbox, you must use the RemoteTargetDatabase parameter to specify the database that you are moving the mailbox to. For example, this command pushes Tony Smith's mailbox to the remote forest:
New-MoveRequest -Identity 'tony@humungousinsurance.com -RemoteLegacy -RemoteTargetDatabase DB03 -RemoteGlobalCatalog 'GC01.humungousinsurance.com' -RemoteCredential $Cred -TargetDeliveryDomain 'mail.contoso.com'
Remote Mailbox Moves with Exchange 2010 in both Forests
In this scenario, one forest is an Exchange 2010 forest and the other forest has at least one Exchange 2010 Client Access server. MRS drives the cross forest moves. MRS and MRSProxy exist on all Exchange 2010 Client Access servers.
In the above figure, Exchange 2010 CAS servers exist in both locations and Exchange 2010 mailbox servers are only in Contoso.com. Fourthcoffee.com only has Exchange 2007 SP2 mailbox servers. In the Contoso.com forest, a mail-enabled user exists for Tony@FourthCoffee.com. The MEU has all of the prerequisite settings configured. The following command is run from the target forest, Contoso.com.
| Note: |
|---|
|
If you are moving the mailbox from an Exchange 2003 server, the mailbox move will be offline and Tony won't be able to access his mailbox until the move has completed.
|
New-MoveRequest -Identity 'tony@fourthcoffee.com' -TargetDatabase DBa -RemoteHostName 'CAS01.fourthcofee.com' -RemoteCredential (Get-Credential Atlanta\Administrator) -TargetDeliveryDomain 'mail.contoso.com'
-
MRS on the CAS server in Contoso.com is prompted by the New-MoveRequest command. The cmdlet updates Contoso's Active Directory and the system mailbox on the target database DBa. The status is Queued.
-
Contoso's MRS will communicate through FourthCoffee's MRSProxy to initiate the move, and then MRSProxy will update FourthCoffee's Active Directory and the system mailbox on the remote database. The status changes to InProgress.
-
Mailbox data is pulled from the mailbox Tony@fourthcoffee.com by the MRS server in the Contoso forest through FourthCoffee's MRSProxy server to the mail-enabled user tony@fourthcoffee.com in the Contoso forest. The status is InProgress.
-
When the mailbox move is almost complete, MRSProxy will lock the mailbox at fourthcoffee.com for a short time while final synchronization is completed. The status is CompletionInProgress.
-
MRS converts the mail-enabled user Tony@fourthcoffee.com to the mailbox Tony@mail.contoso.com. And then MRSProxy converts the mailbox tony@fourthcoffee.com to a mail-enabled user Tony@mail.contoso.com. The status is Completed and Tony can now access his mailbox in the Contoso forest.
-
The administrator clears the move request information from Active Directory and on the system mailbox by running the Remove-MoveRequest command, either in the Shell or in the EMC. Until the move request information is cleared, you can't move the mailbox again.
A record of the move is kept in tony's mailbox and can be accessed by running the Get-MailboxStatistics cmdlet with the IncludeMoveReport parameter.
| Note: |
|---|
|
If you want to move the mailbox back to the remote forest, you will need to initiate the move in the Contoso forest because Contoso has the highest version of the mailbox server - Exchange 2010. In addition, you will need to specify the RemoteTargetDatabase parameter.
|
Remote Legacy Mailbox Moves
If there isn't an Exchange 2010 Client Access server, in one of the forests, MRS will directly access the remote legacy database and the remote organization's Active Directory. In doing a remote legacy move request, you must supply the following information in the command:
-
Identity of the mail-enabled user
-
RemoteLegacy switch
-
FQDN of the remote global catalog server
-
FQDN of the external e-mail address that's 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 remote target database when moving mailboxes from Exchange 2010 to the remote legacy database.
In this scenario, the following command is run from the target forest, Contoso.com.
New-MoveRequest -Identity 'tony@humungousinsurance.com -RemoteLegacy
-TargetDatabase DB02 -RemoteGlobalCatalog 'GC01.humungousinsurance.com' -RemoteCredential $Cred -TargetDeliveryDomain 'mail.contoso.com'
In the HumungousInsurance forest, there isn't an Exchange 2010 Client Access server. This scenario is similar to the remote move request process. However, since the remote legacy forest doesn't have an instance of MRSProxy to connect with, MRS in Contoso's forest reaches directly to the forest's active directory and the system mailbox on the Exchange 2003 or Exchange 2007 mailbox database to complete the move request.
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.
Auto Complete Mailbox Moves
MoveMailbox.ps1 provides a synchronous mailbox move management experience similar to the Move-Mailbox cmdlet provided in Exchange 2007. By default, scripts are installed at C:\Program Files\Microsoft\Exchange Server\V14\Scripts. For more information, see Move Mailboxes by Using the MoveMailbox.ps1 Script in the Shell.
| Note: |
|---|
|
You can use this script for local moves only. You can't use this script for cross-forest moves.
|
MoveMailbox.ps1 performs the following tasks:
-
Creates a new local move request
-
Waits for mailbox move to complete
-
Removes the move request after it has completed
Archive Mailboxes
If archive exists, then the archive gets moved with the primary mailbox because the archive and the primary mailbox must reside on the same mailbox database. You will need to factor in the size of the archive before moving the mailbox, not only for database size, but for how long the move will take to complete.
If you are moving from an Exchange 2010 server to Exchange 2003 or Exchange 2007 server, you will need to disable the archive before you can move the mailbox. For more information, see Disable a Personal Archive for a Mailbox.
Shared Mailboxes and Resource Mailboxes
In addition to the default user mailboxes, you can move shared mailboxes and resource mailboxes. A shared mailbox is a mailbox to which multiple users can log on. A resource mailbox is a mailbox that represents a type of resource, such as a conference room or video equipment. Resource mailboxes have additional properties in Active Directory that user mailboxes and shared mailboxes do not have, such as capacity.
Exchange 2003 does not support resource mailboxes. Instead, you must use shared mailboxes to represent resources. If you move a shared mailbox from Exchange 2003 to Exchange 2010 MRS creates the mailbox as a shared Exchange 2010 mailbox. After you move the mailbox to Exchange 2010, you can convert it to a resource mailbox. For more information about how to convert a shared mailbox to a resource mailbox, see Convert a Mailbox.
Mailbox Moves during Server Failures
Move requests can handle transient errors. MRS conducts checkpoints every 5 minutes to ensure that the database the mailbox being moved is still operational. If MRS finds that the target database is not operational, MRS will sleep for 30 seconds and then retry the move. If you have a failover, the move will not fail. MRS will detect a database failover, determine where the new database is now and restart the move process.
Another error condition that could occur is that the Client Access server where MRS instance is running goes down. If this happens, the move will stop, and then one of the other MRS instances will pickup and complete the move.
For more information, see Troubleshooting Mailbox Moves.