Exchange 2013 Local Mailbox Moves (Part 1)

by [Published on 11 April 2013 / Last Updated on 11 April 2013]

In this three-part article the author will talk about how to perform local mailbox moves in Exchange 2013 and some of the improvements made to these.

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

Introduction

Moving mailboxes between databases or between different versions of Exchange is one of those tasks that administrators might spend a couple of years without doing if they are managing an Exchange environment that is running smoothly. On the other hand, this might be a task they perform regularly if they often perform Exchange transitions or migrations.

There are many reasons to move mailboxes such as a transition between different versions of Exchange, a migration from Exchange on-premise to Office 365, troubleshooting, re-distributing mailboxes across databases so their size is similar, etc.

Moving a mailbox involves moving it from a source mailbox database to a target mailbox database which can be hosted on the same server, on a different server, in a different Active Directory [AD] site or domain, or even in another AD forest.

As with previous versions, with Exchange 2013 there are 3 main types of mailbox moves:

  • Local: moving mailboxes between different databases within a single on-premise Exchange forest;
  • Cross-Forest: moving mailboxes between two different on-premise Exchange forests;
  • Remote: moving mailboxes in a hybrid deployment between an on-premises Exchange organization and Exchange Online or vice-versa. These are usually of 3 types:
    • Cutover, where all mailboxes are moved at once;
    • Staged, where a subset of mailboxes are migrated at a time;
    • IMAP, where mailbox data is migrated using Outlook.

The process flow and architecture of mailbox moves in Exchange 2013 is similar to 2010. As such, in this article I will focus on the improvements made over Exchange 2010 and only for local (also known as on-premise) mailbox and archive moves between Exchange 2013 servers in the same AD site and domain. For more details and background information on the Mailbox Replication Service [MRS], please refer to the Moving Mailboxes in Exchange 2010 article from Neil Hobson.

In this article I will use the following terms:

  • Non-Batch Move Requests when referring to move a single mailbox at a time (using the Exchange Administration Center [EAC] or the New-MoveRequest cmdlet);
  • Batch Move Requests when referring to move more than one mailbox at a time (using the EAC or the new New-MigrationBatch cmdlet).

Improvements

Similar to Exchange 2010, Exchange 2013 has the concept of batch moves. However, unlike 2010 where these “batch moves” only allows us to group move requests together in a convenient way so we can easily process them later, in 2013 these have been greatly improved, giving us:

  • “The ability to move multiple mailboxes in large batches (true batch move);”
  • Email notification when move is complete;
  • Automatic retry and prioritization of moves;
  • Periodic incremental syncs to migrate mailbox changes (mainly used when moving mailboxes to Office 365, for example).

The first improvement is in quotes because I am not certain of what Microsoft means by “true batch move”. When we initiate a move of dozens of users simultaneously, these moves are still limited by the same values present in Exchange 2010 in the <Exchange Installation Path>\Program Files\Microsoft\Exchange Server\V14\Bin\MSExchangeMailboxReplication.exe.config file.

In Exchange 2013 the file has the same name and is located in the same folder, but now in the Mailbox server role:

Image
Figure 1.1:
MsExchangeMailboxReplication.exe Config File Location

When we open the file, we can see the default, minimum and maximum values each parameter supports:

Image
Figure 1.2:
MsExchangeMailboxReplication.exe Config File Accepted Values

And further below is what we are really interested in:

Image
Figure 1.3:
MsExchangeMailboxReplication.exe Config File Settings

These values are exactly the same ones set by default in Exchange 2010, and 2013 still follows them. For example, if you are moving 10 users from one database in one server to another database in another server, only two mailboxes will be moved at a time.

For this reason, I am still not sure what the improvement is when Microsoft talks about moving multiple mailboxes in large batches...

Large Items

However, before diving into these, I want to first talk about a setting that seems to have been modified in Exchange 2013 and that is very similar to the Bad Item Limit, the Large Item Limit.

In 2010, the AllowLargeItems parameter was said to specify “that the message size limit will not be enforced on the message item during the move operation” and that “a value does have to be specified when you use the AllowLargeItem parameter”, but nothing more.

In 2013, its description changed. The LargeItemLimit parameter specifies the number of large items to skip if the move request encounters such items in the mailbox. The default is 0 (zero) which means that the migration fails if the mailbox contains any large items. If any number above 50 is specified, the AcceptLargeDataLoss parameter must also be specified, just like with the BadItemLimit parameter. When the number of large items exceeds this value, the migration for the mailbox fails.

But how big is a large item?! In Exchange Online, items up to 35MB are migrated. For an on-premises Exchange, the size limit is, according to TechNet, “defined by the target mailbox database”. Now this is where it gets mysterious because I haven’t seen any setting like that for databases...

The only thing I can think of are the message size limits on mailboxes, Transport Config and Send/Receive Connectors. So I have ran multiple tests by:

  • Saving e-mails with big attachments (30MB+) in a mailbox;
  • Changing the MaxReceiveSize and the MaxReceiveSize for the Transport Config to 2MB;
  • Changing the MaxMessageSize for all the Receive Connectors to 2MB;
  • Changing the MaxSendSize and MaxReceiveSize for this particular mailbox to 2MB as well.

After this I used the New-MoveRequest cmdlet to move the mailbox to another database and every time it worked...

Finally I came across the description of the AllowLargeItems parameter, where it is stated that it “specifies that you can move large items only when large items are encountered. Large items are email messages with a maximum of 1,023 attachments.

So I tried to create an e-mail with more than 1023 attachments but obviously Outlook prevents this. As such, the purpose of this parameter is still unknown to me...

Non-Batch Move Request

To move a single mailbox we can continue to use the GUI, in this case the new EAC, or the New-MoveRequest cmdlet that we are used to from Exchange 2010.

To use the EAC to create a local move request, perform the following steps:

In the EAC, navigate to recipients à migration and then click the + icon:

Image
Figure 1.4:
EAC Migration Pane

In the Select the users window, add the user you want to move and then click next. Notice that the name of the window is “New Migration Batch”. This is because Exchange treats every move request issued from the EAC as a batch move, even if you are only moving a single mailbox.

Image
Figure 1.5:
Select the Users

On the Move configuration page, specify a name for the new batch. Select if you want to move the primary mailbox, the archive or both. Next select the target database(s). If you click in More options... you can also specify the bad item limit and the large item limit. Click next:

Image
Figure 1.6:
Move configuration

On the Start the batch page, you can specify to which mailbox to send a report once the move is complete. You can also specify if you want to start the move automatically or manually at any time, as well as completing the move automatically or later as well. Click new to start the move process:

Image
Figure 1.7:
Start the Batch

While the move is happening in the background, you can keep an eye on its progress through the migration pane:

Image
Figure 1.8:
Move Status

If you click in View details on the right-hand side, you can get further details on the move’s progress:

Image
Figure 1.9:
Move Status Details

Once completed, if successfully, the STATUS will change to Completed:

Image
Figure 1.10:
Move Complete

Because we configured the migration to send as a notification e-mail once it is complete, if we login to the Administrator mailbox, we will see the report sent by Exchange automatically at the end of the move. However, notice the Completed and Total mailboxes fields are none even though one mailbox was successfully moved. I wonder if this report only mentions mailboxes that failed to be moved (we will have a look at this in the second part of this article series).

Image
Figure 1.11:
Move Report

To achieve the same result through the Shell, the process is identical to Exchange 2010:

New-MoveRequest User1 -TargetDatabase DB03 -PrimaryOnly 

The only difference from using the EAC is that with the New-MoveRequest parameter we cannot generate a move report. This is only possible with the New-MigrationBatch cmdlet as we will see in the second part of this article.

In 2013, we you still have the following parameters:

  • ArchiveOnly - specifies that we are moving only the personal archive associated with the mailbox;
  • ArchiveTargetDatabase - specifies the target database to which we are moving the personal archive. If it is not specified, the archive is moved to the same database as the primary mailbox. If we specify the ArchiveOnly parameter but don't specify the ArchiveTargetDatabase, the archive is moved to the homeMDB attribute of the primary mailbox;
  • BadItemLimit - specifies the number of bad items to skip if the request encounters corruption in the mailbox. Use 0, the default, to not skip bad items. If we set the BadItemLimit parameter to more than 50, we need to use the AcceptLargeDataLoss parameter or the move will fail;
  • BatchName - specifies a descriptive name for moving a batch of mailboxes. We can then use this name as a search string when using the Get-MoveRequest cmdlet;
  • Suspend - specifies whether to suspend the request. When used, the request is queued but it will not reach the status of InProgress until we resume the request;

A useful parameter of this cmdlet is the WhatIf that allows us to check the mailbox readiness to be moved. It simulates the actions that would be taken during the move and reports any errors that will occur without adding the mailbox to the move request queue.

New in Exchange 2013 are the following paramenters:

  • PreventCompletion - specifies that this cmdlet initializes, but isn't completed. We then have to run the Resume-MoveRequest cmdlet to complete the move request;
  • CompletedRequestAgeLimit - specifies how long the request will be kept after it has completed before being automatically removed. The default is 30 days;
  • ForceOffline - forces a mailbox move to be performed in offline mode, meaning the user will have no access to email during the mailbox move;
  • LargeItemLimit – as described before, specifies the number of large items to skip if the request encounters such items in the mailbox.

To check the progress of the move request you can use the EAC or the usual Get-MoveRequestStatistics cmdlet:


Figure 1.12:
Move Status

By expanding the same cmdlet once the move is complete, we can check all sorts of details regarding this move including how long it took and the number of items moved:

Image
Figure 1.13:
Move Statistics

Note:
There is also a new New-MigrationUserStatistics cmdlet that we will have a look at in the second part of this article.

As I mentioned before, this method is identical to Exchange 2010. So using the Shell, you can also move multiple mailboxes using this same cmdlet. You can pipe multiple users:

"User1", "User2" | New-MoveRequest -TargetDatabase DB03

Use a file:

cat UsersToMove.txt | New-MoveRequest -TargetDatabase DB03

Or by using the Get-Mailbox cmdlet:

Get-Mailbox -Filter {CustomAttribute1 -eq "Student"} | New-MoveRequest -TargetDatabase DB03

Conclusion

In the first part of this article series, we had a look at how to perform a local mailbox move in Exchange 2013. In the second part we will look at how to use the new Migration Batch feature of Exchange 2013 from the Exchange Administration Center and in the third and final part we will look at the feature but using the Shell.

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

Featured Links