The whole approach to moving mailboxes in Exchange 2010 revolves around the feature known as move requests. A move request is created by the Exchange administrator using either the Exchange Management Console or the Exchange Management Shell. 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.
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 Microsoft Exchange Mailbox Replication service checks the contents of the system mailbox on each mailbox database to see if any move requests are waiting and then processes them accordingly. There are many benefits to having the mailbox moves carried out by this service. Here are three main areas that I typically encounter on migration projects that are addressed with move requests:
- Mailboxes can now be moved online whilst the users are logged into them. Admittedly this is only available if the source mailbox is running Exchange 2007 SP2 or later, or Exchange 2010. However, this is a welcome addition to the overall mailbox moving process as it will help negate the need to move mailboxes out of core business hours.
- Items in the dumpster are now moved as part of the process. In previous versions of Exchange, moving a mailbox did not move the items in the dumpster and it was therefore required that the user had to recover any deleted items prior to the mailbox move. It was all too easy to forget to inform the users of this fact and in some cases users who had been moved then proceeded to recover items from their dumpster only to find it completely empty.
- 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. However, in this scenario, the mailbox contents are moved from the source database to the administrative machine and then into the target database. This scenario was mitigated by running the cmdlet or script directly on the target database 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.
Creating a Local Move Request
Now that we understand a little about move requests, it is time to see how we can actually move a mailbox. Let us start by looking at how a local move request is made using the Exchange Management Console.
- With the Exchange Management Console loaded, expand Recipient Configuration in the console tree. Under Recipient Configuration, select the Mailbox object which will display a list of all mailboxes in the result pane.
- At this point you need to select the mailboxes that you want to move. You can select multiple mailboxes that will be moved at the same time.
- When you have selected the mailboxes that you wish to move, either choose the New Local Move Request… option from the Action pane, or right-click the Mailbox object and choose the same option from there.
- The New Local Move Request Wizard now starts. The selected mailboxes that you wish to move will already be shown on this screen, together with important information such as the mailbox database that these mailboxes currently reside on.
- On the Introduction screen, click the Browse… button which brings up the Select Mailbox Database screen. This particular screen will show you the databases that you have available across all the servers in your organization. Select the database and click OK.
- Back at the Introduction screen, the target database field should now be populated with the destination database. Click Next.
- The next screen to be displayed is the Move Options screen. This screen should be familiar to you if you’ve used legacy versions of Exchange. Here you can state how you’d like to handle corrupted messages if any are found in the source database. The choices are either to skip the mailbox entirely, or allow up to a specified number of corrupted items. There is no right or wrong answer to the setting that you should use here as it all depends on how your organization tolerates data loss.
- Once you have decided on the required setting for the Move Options screen, click Next. This then brings up the final screen where you can check the configuration summary before clicking the New button to create the local move request.
- The local move request is then created and submitted to a Client Access Server; the wizard can be closed.
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'.
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.
Creating a Move Request - PowerShell
To create a local move request using the Exchange Management Shell you can use the
New-MoveRequest cmdlet and its associated parameters. A very simple cmdlet to create a local move request to move a mailbox from one database to another could look like this:
New-MoveRequest –Identity neil -BadItemLimit 100 -AcceptLargeDataLoss
–TargetDatabase ‘BI Mailbox Database’
or New-MoveRequest -Identity domain\neil -BadItemLimit 50
-TargetDatabase 'BI Mailbox Database'
Here, the Identity parameter is used to identify the mailbox that is to be moved, whilst the TargetDatabase parameter obviously identifies the database that the mailbox is to be moved to.
Move requests are not automatically removed even if the mailbox has moved successfully. This also has implications for the removal of mailbox databases.
There are more ways to control move requests using the Exchange Management Shell than there are using the Exchange Management Console. A few of the more important parameters are below:
- BadItemLimit - It is possible to decide how many corrupt mailbox items you are willing to tolerate when moving a mailbox. In the Exchange Management Shell, the BadItemLimit parameter controls this setting.
- BatchName - This is a useful parameter that allows you to specify a batch name when moving a number of mailboxes. It is then possible to use this batch name to search for particular mailboxes when using the Get-MoveRequest cmdlet.
- IgnoreRuleLimitErrors - If you encounter any rule limit errors when moving a mailbox, you might decide not to move the user’s rules as part of the mailbox move. This parameter allows you to do this. You could, for example, alter the parameters of a move request after it has been submitted to ensure that rules are not processed.
- MRSServer - Ordinarily, the move request is processed by one of the Client Access Servers within the Active Directory site. To specify a particular Client Access Server, use the MRSServer parameter using the Fully Qualified Domain Name (FQDN) of the Client Access Server.
- SuspendWhenReadyToComplete - This parameter is used to suspend the move request before the mailbox is finally moved to the target database. In other words, all the actual mailbox data is moved but the final move is not completed until the administrator resumes the move request using the Resume-MoveRequest cmdlet. One application of such an approach could be to allow a final approval of a mailbox move.
Managing Move Requests
Now that the local move request has been created, you will need to track the progress. Back in the Exchange Management Console click the Move Request object found under the Recipient Configuration node in the console tree. Here you can see a list of move requests displayed.
There are many possible status settings such as InProgress, Completed, Failed and so on. This allows you to understand where in the overall process the move request currently is.
It is also possible to use the Exchange Management Shell to see how the move requests are progressing using the Get-MoveRequest cmdlet. In its default state, the Get-MoveRequest cmdlet will return all move requests that are currently available.
Whilst there are various methods of moving multiple mailboxes in Exchange 2010 via use of a few Exchange Management Shell cmdlets, be aware that Microsoft provides the MoveMailbox PowerShell script that you can find in the \Program Files\Microsoft\Exchange Server\V14\Scripts folder after you have installed Exchange 2010. This script will perform local move requests within the same Exchange organization and has the added benefit that it will remove the move request once it has completed.
To move a mailbox to a database called Mailbox Database 002, I would simply run the MoveMailbox script with the following parameters:
./MoveMailbox.ps1 –Identity neil –TargetDatabase ‘BI Mailbox Database’
One of the nice things about this script is that it clears the move request for you.
Mailbox Replication Service Health
It has become clear that the Microsoft Exchange Mailbox Replication service is vital to the overall move request process so it follows that the health of this service should be monitored accordingly. Exchange 2010 includes the Test-MRSHealth cmdlet, where MRS stands for Mailbox Replication Service. To test the health of a particular Client Access Server, you just need to use the –Identity parameter with the relevant Client Access Server name such as:
Test-MRSHealth –Identity BI1
Common Exchange 2010 Mailbox Move Errors
Insufficient Access Rights to Perform the Operation
Error: Active Directory operation failed on DC.domain.com. This error is not retriable. Additional information: Insufficient access rights to perform the operation. Active directory response: 00002098: SecErr: DSID-03150BB9,
problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
The user has insufficient access rights.
Inheritable permissions are not turned on for the user. If the user is a member of the domain admins group, this setting will be unchecked. You can turn on this permission for the mailbox move. AD will run service in the background that will uncheck the box again in a few hours. This is ok, it just has to be checked during the mailbox move. This error does not seem consistent, ie some domain admins will experience it and some won’t. I have also seen normal users have this box unchecked as well.
Check the “Allow Inheritable Permissions from this object’s parent” box on the user Account. If you don’t know where to find that, keep reading.
- Open Active Directory Users and Computers and make sure the Advanced Features is checked.
- Open the Properties of the User Account and go to the Security Tab. Once there, click on Advanced
- Check the box at the bottom left, "Include inheritable permissions from this objects's parent"
- In Exchange Management Console, try moving the mailbox again.