Moving Mailboxes in Exchange 2010 (Part 4)

If you would like to read the other parts in this article series please go to


This is the fourth and final part of an article series looking at the process of moving mailboxes within the same forest using the new move request feature of Exchange 2010. In part three of this article series we ended the part by showing how multiple mailboxes can be moved via a couple of different methods. Let us get straight on with this last part of the article series by focusing on the MoveMailbox.ps1 script that is supplied with Exchange 2010 and how you can use this to move both single and multiple mailboxes. We will finish the article by looking at two other miscellaneous areas related to the use of move requests in Exchange 2010.


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. Before we look at a couple of script examples, let us look at some the parameters that the script uses. It uses a few parameters that we have already discussed in this article series although a couple of these have slightly different names.

First, there is the AutoSuspend parameter that is the same as the SuspendWhenReadyToComplete parameter that you can use with the New-MoveRequest and Get-MoveRequest cmdlets. Also, the BadItemLimit parameter is also available with the MoveMailbox script. There are MailboxDatabase and TargetDatabase parameters for controlling the source and target databases respectively. One of the other main parameters that you may make use of with this script is the DatabaseMap parameter. This is a really useful parameter that allows you to map out where you would like the mailboxes to move to. We’ll have a deeper look at this parameter later here in the final part of this article series.

For now, let us take a look at the simple process of moving a single mailbox using the MoveMailbox script. To move my mailbox to a database called Mailbox Database 002, I would simply run the MoveMailbox script with the following parameters:

./MoveMailbox.ps1 –Identity neil –TargetDatabase ‘Mailbox Database 002’

Running this cmdlet produces a result similar to that shown in Figure 19. As I stated earlier, one of the nice things about this script is that it clears the move request for you.

Figure 19:
Moving a Single Mailbox With MoveMailbox.ps1

MoveMailbox.ps1 Database Maps

The DatabaseMap parameter of the MoveMailbox script is very useful when pipelining a series of mailboxes into it and moving those mailboxes to multiple target databases. It’s possible to specify multiple source/target pairings within the command line to make for efficient use. The syntax for using this parameter is as follows:

-DatabaseMap @{‘Source Database’=’Target Database’;’Source Database’=’Target Database’}

In this example syntax you can see that two source/target mappings have been made and that they are separated by a semi-colon. Therefore, to use the example where you want to move the mailboxes on Mailbox Database 001 to Mailbox Database 003 and the mailboxes on Mailbox Database 002 to Mailbox Database 004 the syntax of the DatabaseMap parameter would be:

-DatabaseMap @{‘Mailbox Database 001’=’Mailbox Database 003’;’Mailbox Database 002’=’Mailbox Database 004’}

Let’s assume that you want to move all the mailboxes belonging to users who are a member of the Consultants department to new mailbox databases as per the database mapping that we’ve just discussed. To do this you could use the following line of PowerShell code based on the assumption that the ‘department’ attribute in Active Directory is correctly populated:

Get-User | Where {$_.Department –eq ‘Consultants’} | Get-Mailbox | ./MoveMailbox.ps1 –DatabaseMap @{‘Mailbox Database 001’=’Mailbox Database 003’;’Mailbox Database 002’=’Mailbox Database 004’}

This code first gets the details of those user accounts whose Active Directory ‘department’ attribute has a value of Consultants. The results of this cmdlet are piped into the Get-Mailbox cmdlet so that the mailbox details of the users are obtained. The mailbox details are then piped into the MoveMailbox script and the mailboxes moved accordingly. As you can see from Figure 20, the cmdlet invokes the MoveMailbox script and the script is now waiting for the moves to complete. Once finished, status information is displayed as you can see in Figure 21. The result of running this cmdlet in my simple lab environment is that one mailbox is moved from Mailbox Database 001 to Mailbox Database 003 and one mailbox is moved from Mailbox Database 002 to Mailbox Database 004.

Figure 20:
Multiple Mailbox Moves in Progress

Figure 21:
Multiple Mailbox Moves Completed

Mailbox Replication Service Health

Throughout this article series 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. In a previous article series here on, I covered the various Exchange 2007 ‘test’ Exchange Management Shell cmdlets that can be used to test specific areas of Exchange 2007 functionality. 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 DAG1

In the above example, the Client Access Server is called DAG1. The result of running such a cmdlet will look similar to that shown in Figure 22.

Figure 22:
Results of the Test-MRSHealth Cmdlet

You can see from Figure 22 that the Test-MRSHealth cmdlet checks whether the Mailbox Replication Service is running, then performs an RPC ping against this service and finally checks how long it has been since the mailbox database queue was scanned.

Removing a Mailbox Database

As part of your normal administrative duties, it is sometimes required to decommission an existing Exchange 2010 server or sometimes just remove an old mailbox database. You may remember from previous parts of this article series that move requests are not cleared automatically even when the mailbox move has completed. One exception to this is the case where the MoveMailbox.ps1 script is used but if move requests have been created manually using the Exchange Management Shell or the Exchange Management Console they will need to be removed before a mailbox database can be removed. This applies even if there are no more mailboxes on that mailbox database but the move requests still exist.

Attempting to remove a mailbox database with move requests still outstanding will result in an error message that starts with the text “This mailbox database is associated with one or more move requests…”. This error can be seen in Figure 23. Therefore, you will need to use the Get-MoveRequest and Remove-MoveRequest cmdlets to find and remove the outstanding move requests.

Figure 23:
Outstanding Move Requests During Database Removal


That completes the entire four-part article series on local move requests in Exchange 2010. Note that we have not covered every single cmdlet and its associated parameters as there is scope for you to read up on these as you review the move request cmdlets in a lab environment. Hopefully this article series has given you a good grounding on how the entire mailbox move process is achieved in Exchange 2010.

If you would like to read the other parts in this article series please go to

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top