Moving Mailboxes in Exchange 2010 (Part 1)

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


In a previous article here on I explained the Exchange 2007 approach to moving mailboxes. This mainly involves using the Move-Mailbox cmdlet in the Exchange Management Shell, although it is of course possible to move mailboxes using the Exchange Management Console. In Exchange 2010, it is still possible to move mailboxes using both the Exchange Management Console and the Exchange Management Shell although there have been quite a few changes to the whole process. In this three-part article series, I will be taking a look at how mailboxes are moved in Exchange 2010 and in particular, I will be focusing on the new Move Request feature.

Move Requests

Let us start this discussion by stating that the Move-Mailbox cmdlet is no longer available in Exchange 2010. The whole approach to moving mailboxes in Exchange 2010 revolves around the feature known as move requests. Since the Move-Mailbox cmdlet is no longer available, it follows that you cannot use the Exchange 2007 Move-Mailbox cmdlet to move mailboxes from Exchange 2007 to Exchange 2010; you have to use Exchange 2010’s move request feature.

A move request is created by the Exchange administrator using either the Exchange Management Console or the Exchange Management Shell. In this article, 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. Remote move requests may be covered in a future article here on

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. You can see this service in Figure 1.

Figure 1: The Microsoft Exchange Mailbox Replication Service

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.

When I first read that the Microsoft Exchange Mailbox Replication service on each Client Access Server was responsible for processing mailbox moves, I wondered how the presence of multiple Client Access Servers would affect the mailbox moves. For example, would two Client Access Servers attempt to move the same mailbox at the same time? Fortunately Microsoft states that it has implemented a sharing mechanism between all Client Access Servers in the same Active Directory site so that such a situation is avoided.

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 using this new feature. Let us start by looking at how a local move request is made using the Exchange Management Console.

  1. 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.
  2. 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.
  3. 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. This is shown in Figure 2.

Figure 2: Creating a New Local Move Request

  1. The New Local Move Request Wizard now starts and the Introduction screen is shown as you can see in Figure 3. 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.

Figure 3: New Local Move Request Introduction Screen

  1. On the Introduction screen, click the Browse… button which brings up the Select Mailbox Database screen as you can see in Figure 4. This particular screen will show you the databases that you have available across all the servers in your organization. In my example, I am simply going to move the mailbox from Mailbox Database 001 to Mailbox Database 002 on the same server, called DAG1. Therefore, I simply select this database and click OK.

Figure 4: Select Mailbox Database Screen

  1. Back at the Introduction screen, the target database field should now be populated with the destination database. Click Next.
  2. The next screen to be displayed is the Move Options screen as shown in Figure 5. 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. In my example screen shot, I’ve elected to skip the mailbox entirely; if any corrupted items are found, the mailbox will not be moved. I would then look to examine the database using utilities such as ISINTEG to see if the corruption can be fixed.

Figure 5: Move Options Screen

  1. 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.
  2. The local move request is then created and submitted to a Client Access Server; the wizard can be closed.

We will look at how you can determine the progress of the move request later in this article series.


That completes part one of this article series on moving mailboxes in Exchange 2010, where we have introduced the concept of move requests and gone on to look at how these are created using the Exchange Management Console. In part two, we will look at using the Exchange Management Shell to create a local move request and also how you can begin to monitor the progress of the mailbox move.

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

Leave a Comment

Your email address will not be published.

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

Scroll to Top