Understanding Move Requests

Applies to: Exchange Server 2010

When you move a mailbox, you're moving it 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, or in another forest.

Cautions

Here are some important things to keep in mind when 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 cmdlet in Exchange 2007 to move mailboxes from Exchange 2007 to Exchange 2010.
• When you move mailboxes, the user won't be able to view their message tracking information.

Advantages to 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 carried out 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 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 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 machine. For example, in Exchange 2007, when you ran the Move-Mailbox cmdlet, the data move was managed by the computer on which you ran the cmdlet. You couldn't shut down that session of Exchange until the move completed.

• The mailbox's move history is maintained in the mailbox.

Asynchronous Mailbox Moves

In Exchange Server 2007, when you use the Move-Mailbox cmdlet 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. 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.

Using the move request cmdlets in Exchange 2010, you can perform an asynchronous move because the cmdlets don't perform the actual move. The move is performed by the Microsoft Exchange Mailbox Replication Service (MRS), a new service that runs on all Client Access servers in your Exchange 2010 organization. Using MRS is beneficial because it allows you to manage mailbox moves from any Exchange 2010 server within your organization after the move request is started. For more information, see Microsoft Exchange Mailbox Replication Service later in this topic.

Online Mailbox Moves

In an online mailbox move, end users can still access their e-mail accounts during the move. The user is only locked out of the account for a brief time at the end of the process (when the final synchronization occurs). Online mailbox moves are supported between Exchange 2010 databases and between Exchange 2007 SP2 and Exchange 2010 databases. You can perform online mailbox moves across forests or in the same forest. The process for local mailbox moves and remote mailbox moves are different from online moves and are discussed later in this topic.

Reasons for Moving Mailboxes

Here are some scenarios in which you'd need to move mailboxes:

• Transition   When you transition an existing Exchange 2007 or Exchange Server 2003 organization to Exchange 2010, you'll 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 that's 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's closer to the new location.
• Separation of administrative roles   You may want to separate Exchange administration from Windows Server 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.

Supported Scenarios for Moving Mailboxes

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

Services Used in Move Requests

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

When you use the move request cmdlets to move mailboxes, MRS processes the move process. As stated earlier, 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 Move-Mailbox cmdlet. By using a service as the agent of the move, mailboxes can be moved while simultaneously remaining accessible to users. During the move, you can view, cancel, and manage the move request from any Exchange 2010 server in your organization.

You can start and stop MRS as you would any service. MRS constantly checks for all move requests in its own Active Directory site. In addition, there's 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 make sure that database and Client Access server throttling is respected across all instances of MRS. MRS throttling is controlled by a configuration file. By default, the configuration file is located in the same folder where Exchange is installed:

<Exchange Installation Path>\V14\Bin\MSExchangeMailboxReplication.exe.config

You can control the following MRS 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.

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'll 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.

For more information, see Start the MRSProxy Service on a Remote Client Access Server.

Basic Move Request Process

The following figure and proceeding steps describe the basic process for local move requests.

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

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

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 see 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 deleted. The move request status changes to Completed. Depending on Ayla's e-mail client, she may need to log off and log back on to access her mailbox.

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 Remove or Clear 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.

Remote Mailbox Moves

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 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 details, see Create a Remote Legacy Move Request Where One of the Forests Doesn't Have Exchange 2010.

Prerequisites for Moving Mailboxes Across Forests

The prerequisites for moving mailboxes across forests are extensive. For details, see Prepare Mailboxes for Cross-Forest Move Requests.

Using the TargetDatabase or the RemoteTargetDatabase parameters

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

TargetDatabase Parameter

This 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 you're 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.

RemoteTargetDatabase Parameter

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

The following example pushes Tony Smith's mailbox to the remote forest:

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 figure illustrates this 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 SP2 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:

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

1. The New-MoveRequest cmdlet prompts MRS on the Client Access server in the Contoso forest. The cmdlet updates Contoso's 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 FourthCoffee forest. MRSProxy then updates Fourth Coffee's 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. 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 back on to access his mailbox.

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 Remove or Clear 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 Contoso's 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 2003 or Exchange 2007 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.
• 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 the remote target database when moving mailboxes from Exchange 2010 to the remote legacy database.

The following figure illustrates this 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 Contoso's forest connects directly to Humongous Insurance's 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 'tony@humongousinsurance.com -RemoteLegacy 
  -TargetDatabase DB02  -RemoteGlobalCatalog 'GC01.humongousinsurance.com' -RemoteCredential $Cred -TargetDeliveryDomain 'mail.contoso.com'
  

Auto Complete Mailbox Moves

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.

MoveMailbox.ps1 performs the following tasks:

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

Archive Mailboxes

If a personal archive exists for a mailbox you want to move, the archive gets moved with the primary mailbox. This is because the archive mailbox and the primary mailbox must reside on the same mailbox database. Before moving mailboxes that have a personal archive, you should factor in the size of the archive, not only for database size, but for how long the move will take to complete.

If you're moving mailboxes from an Exchange 2010 server to an Exchange 2003 or Exchange 2007 server, you need to disable the personal archive before you can move the mailbox. For details, see Disable a Personal Archive for a Mailbox.

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

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

Mailbox Moves During Server Failures

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.