When moving mailboxes, consider the following:

• You can't use the Exchange System Manager or Active Directory Users and Computers to move mailboxes from Microsoft Exchange Server 2003 to Exchange Server 2010.
  
  
• You can't use the Move-Mailbox cmdlet in Exchange Server 2007 to move mailboxes from Exchange 2007 to Exchange 2010.
  
  
• When you move mailboxes, users won't be able to view their message tracking information.
  
  

Return to top

The following changes were made to move request functionality in Exchange 2010 Service Pack 1 (SP1):

• Exchange 2010 SP1 now soft deletes the mailbox on the source database, so that you can recover the mailbox in the event of a Mailbox server failover or data loss. You can restore a soft-deleted mailbox by using the MailboxRestoreRequest cmdlet set. To learn more, see Soft-Deleted Mailboxes later in this topic.
  
  

  Note:
  Soft-deleted mailboxes require that both the source Mailbox server and the Client Access server performing the request be running Exchange 2010 SP1.

• The MoveRequest cmdlet set has been updated to support moving archives to a separate database.
  
  

Return to top

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.
  
  

Return to top

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). To learn more, see Asynchronous Mailbox Moves later in this section.
  
  
• Mailboxes are kept online during the asynchronous moves. To learn more, see Online Mailbox Moves later in this section.
  
  
• The items in a mailbox's Recoverable Items folder are moved with the mailbox.
  
  

  Note:
  The Recoverable Items folder is available only in Exchange 2010. To learn more, see Understanding Recoverable Items.

• 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.
  
  

Asynchronous Mailbox Moves

Online Mailbox Moves

You may need to move mailboxes in the following scenarios:

• Transition   When you transition an existing Exchange 2007 or Exchange Server 2003 organization to Exchange 2010, you move mailboxes from the existing Exchange servers to an Exchange 2010 Mailbox server.
  
  
• Realignment   You can move mailboxes for realignment purposes. 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. The corrupted messages won't be moved.
  
  
• Physical location changes   You can move mailboxes to a server 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 closer to the new location.
  
  
• Separation of administrative roles   You may want to separate Exchange administration from Windows operating system account administration. To do this, you can move mailboxes from a single forest into a resource forest scenario. In this scenario, the Exchange mailboxes reside in one forest and their associated Windows user accounts reside in a separate forest.
  
  
• Outsourcing e-mail administration   You 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.
  
  
• Integrating e-mail and user account administration   You 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. In this scenario, the Exchange mailboxes and Windows user accounts reside in the same forest.
  
  

Return to top

The following table lists the supported scenarios for moving Exchange mailboxes and includes links to related topics.

Supported scenarios for moving mailboxes

Return to top

Move requests are processed by two services:

• Microsoft Exchange Mailbox Replication service (MRS)
  
  
• Microsoft Exchange Mailbox Replication Proxy (MRSProxy) service
  
  

Microsoft Exchange Mailbox Replication Service

Microsoft Exchange Mailbox Replication Proxy Service

The following figure illustrates the basic process for local move requests.

In this scenario, Ayla's mailbox will be moved from the source database DB01 on Mailbox server MBX02 to the target database DB02 on Mailbox server MBX01. To do this, you run the following command.

	Copy Code
New-MoveRequest -Identity Ayla@contoso.com -TargetDatabase "DB02"

The following steps describe the basic process for local move requests:

1. 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.
   
   
2. 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.
   
   

   Note:
   The New-MoveRequest cmdlet selects an instance of MRS and requests that the service process the move request immediately. If the selected instance of MRS is available, it starts the move immediately. If not, the mailbox remains in the Queued status until an MRS instance finds the move request.

3. MRS begins to move the data from DB01 to DB02. MRS updates the mailbox's status in the system mailbox to In Progress.
   
   
4. 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.
   
   
5. 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. For more information, see Client Experience later in this topic.
   
   
6. 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. For details about how to clear a move request, see Clear or Remove Move Requests.
   
   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. For more information, see View Move Request Properties.
   
   

Return to top

Remote mailbox moves are also known as cross-forest mailbox moves. Exchange 2010 supports two types of remote mailbox moves:

• 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 details, 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 SP2, Exchange 2007 SP3, or a combination of both. No Exchange 2010 Client Access server is installed in the legacy forest. You can't use the EMC to perform these mailbox moves. You must use the Shell. For details, 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 or the RemoteTargetDatabase Parameters

The New-MoveRequest cmdlet uses the TargetDatabase and the RemoteTargetDatabase parameters to identify the target database to which you're moving mailboxes.

TargetDatabase Parameter

The TargetDatabase parameter specifies the identity of the database to which you're moving the mailbox. Use this parameter to perform local and remote mailbox moves when initiating the move from the target forest. When you initiate the move from the source forest, MRS pulls the mailbox from the source forest to the target forest.

Note:

Using the TargetDatabase parameter is optional. If you don't specify this parameter, its usage is implied, and the mailbox provisioning load balancer specifies a target database. If you don't want the load balancer to select a database, either use the TargetDatabase parameter or specify the databases you want to exclude from provisioning by setting the IsExcludedFromProvisioning parameter to $true in the Set-MailboxDatabase cmdlet.

RemoteTargetDatabase Parameter

The RemoteTargetDatabase parameter specifies the identity of the target database in the remote forest. Use this parameter for remote mailbox moves only when you need to initiate the move from the source forest. For example, if you're moving a mailbox from an Exchange 2010 server to an Exchange 2007 or Exchange 2003 server, you initiate the move from the Exchange 2010 forest, which is the source forest. When you initiate a move from the source forest, MRS pushes the mailbox from the Exchange 2010 server to the Exchange 2007 or Exchange 2003 server.

This example pushes Tony Smith's mailbox to the remote forest.

	Copy Code
New-MoveRequest -Identity 'tony@humongousinsurance.com' -RemoteLegacy -RemoteTargetDatabase DB03 -RemoteGlobalCatalog 'GC01.humongousinsurance.com' -RemoteCredential $Cred -TargetDeliveryDomain 'mail.contoso.com'

Remote Mailbox Moves with Exchange 2010 in Both Forests

The following describes a remote mailbox move scenario:

• One forest is an Exchange 2010 forest and the other forest has at least one Exchange 2010 Client Access server.
  
  
• MRS and MRSProxy exist on all Exchange 2010 Client Access servers. MRS processes the cross-forest moves.
  
  
• The Fourth Coffee and Contoso forests both contain Exchange 2010 Client Access servers, but only Contoso contains Exchange 2010 Mailbox servers. Fourth Coffee contains only Exchange 2007 SP3 Mailbox servers.
  
  
• Fourth Coffee contains the mailbox for tony@fourthcoffee.com. Contoso contains a mail-enabled user for tony@fourthcoffee.com that has all the prerequisite settings configured.
  
  
• The following command is run from the target forest, Contoso.com.
  
  

  	Copy Code
  New-MoveRequest -Identity 'tony@fourthcoffee.com' -TargetDatabase DBa -RemoteHostName 'CAS01.fourthcofee.com' -RemoteCredential (Get-Credential Atlanta\Administrator) -TargetDeliveryDomain 'mail.contoso.com'

Note:
If Tony's mailbox were being moved from an Exchange 2003 server, the move would be offline, and Tony wouldn't be able to access his mailbox until the move was complete.

The following figure illustrates this remote mailbox move scenario.

1. 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.
   
   
2. 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.
   
   
3. 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 tony@fourthcoffee.com. At this point, the status is In Progress.
   
   
4. 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.
   
   
5. In the Contoso forest, MRS converts the mail-enabled user tony@fourthcoffee.com to the mailbox tony@contoso.com. In the Fourth Coffee forest, MRSProxy converts the mailbox tony@fourthcoffee.com to the mail-enabled user tony@contoso.com, 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. For more information, see Client Experience later in this topic.
   
   
6. 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. For details about how to clear a move request, see Clear or Remove Move Requests.
   
   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 must initiate the move in the Contoso forest. This is because the Contoso Mailbox server is running the latest version of Exchange (in this case, Exchange 2010). In addition, you must use the RemoteTargetDatabase parameter when you run the New-MoveRequest cmdlet.

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 SP3 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.
  
  

  	Copy Code
  New-MoveRequest -Identity 'tony@humongousinsurance.com' -RemoteLegacy -TargetDatabase DB02 -RemoteGlobalCatalog 'GC01.humongousinsurance.com' -RemoteCredential $Cred -TargetDeliveryDomain 'mail.contoso.com'

The following figure illustrates this remote legacy mailbox move scenario.

Return to top

The MoveMailbox.ps1 script in Exchange 2010 provides a synchronous mailbox move management experience similar to the Exchange 2007 Move-Mailbox cmdlet. 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:

1. Creates a local move request.
   
   
2. Waits for the mailbox move to complete.
   
   
3. Removes the move request after it's complete.
   
   

Return to top

When mailboxes are moved from an Exchange 2010 SP1 database to any other database, Exchange doesn't fully delete the mailbox from the source database immediately upon completion of the move. Instead, the mailbox in the source mailbox database is switched to a soft-deleted state. Mailbox data can be accessed during a mailbox restore operation using the MailboxRestoreRequest cmdlet set. The soft-deleted mailboxes are retained in the source database until either the deleted mailbox retention period expires or you use the Remove-StoreMailbox cmdlet to purge the mailbox.

Note:
Soft-deleted mailboxes require that both the source Mailbox server and the Client Access server performing the request be running Exchange 2010 SP1.

To view soft-deleted mailboxes, run the Get-MailboxStatistics cmdlet against a database and look for results that have a DisconnectReason property with a value of SoftDeleted.

In the release to manufacturing (RTM) version of Exchange 2010, if a personal archive exists for a mailbox that you want to move, the archive gets moved with the primary mailbox. This is because the personal archive and the primary mailbox must reside on the same mailbox database. Before moving mailboxes that have a personal archive, you should consider the size of the archive. Consider database size and how that size might impact the time the move will take to complete.

In Exchange 2010 SP1, personal archives and mailboxes can exist on separate databases. The move request cmdlets and the move request user interface (UI) in the EMC support moving mailboxes and personal archives together or separately. By default, the primary mailbox and the archive are moved together. For more information about moving an archive and primary mailbox separately, see Create a Local Move Request.

If you're moving mailboxes from an Exchange 2010 server to an Exchange 2007 or Exchange 2003 server, you must first disable the personal archive before you can move the mailbox. For details, see Disable a Personal (On-Premises) or Cloud-Based Archive for a Mailbox.

To learn more about personal archives, see Understanding Personal Archives.

Return to top

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 don't have, such as capacity.

Exchange 2003 doesn't 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 details about how to convert a shared mailbox to a resource mailbox, see Convert a Mailbox.

Return to top

Move requests can handle transient errors. MRS conducts checkpoints every 5 minutes to make sure that the database to which the mailbox being moved is still operational. If MRS finds that the target database isn't operational, MRS will pause for 30 seconds, and then retry the move. If you experience a failover, the move won't fail. Instead, MRS will detect a database failover, determine the new location of the database, and then restart the move process.

Another error that could occur is if the Client Access server on which MRS is running stops responding. If this happens, the move stops, and one of the other MRS instances will continue the process and complete the move.

For more information, see Troubleshooting Mailbox Moves.

Return to top

The following table lists the different experiences end users will have, based on the version of Exchange that their mailbox is being moved to and from, and based on which client application they're using when the move request begins.

Client experience based on Exchange version and client application

Return to top