Advanced Topic: 5 Essential Cmdlets when Upgrading to Exchange 2013

When upgrading to Exchange 2013, there are some very distinct differences in the management and implementation experience.  In Exchange 2013, the management console is completely web-based, which is a substantial change from even Exchange 2010.  The new web-based utility is known as the Exchange Admin Center, or EAC.   Providing a web-based only management utility means right-clicking on objects will not provide action menus, there are screens to advance to rather than a single screen to display every object, and some screens do not automatically refresh in the background to display the changes you have made.  For instance, if you create a batch mailbox move and do not go directly to the migration screen when prompted by the move wizard, the information on the migration screen does not get updated until you refresh the screen.

The purpose of this post is to share five essential management shell cmdlets to help make the process of upgrading to Exchange 2013 easier.  There are of course many other helpful cmdlets for everyday use and some of those can be found in our "Advanced Topic - Using Exchange PowerShell aka Management Shell Commands".  The cmdlets in this post are specific to upgrading to Exchange 2013 and address issues often arising when moving large numbers of mailboxes.  Each of the cmdlets below need to be run in Exchange Management Shell, the Windows Management Shell will not run these cmdlets.

Viewing the Statistics for Mailbox Moves In Progress 

One of the first things you may notice as you move mailboxes is the migration screen will show how many mailboxes have finalized or failed, but there is no information on the progress of any mailboxes currently being moved.  This information is available in Exchange 2010 under the Move Request section.  While the progress statistic for each mailbox move is not critical, it is important when you are moving mailboxes on an in-production server and are trying to minimize downtime.  If users are relying upon their email, knowing the status of a mailbox in the move process can be very helpful.  

To view the progress statistics for every mailbox currently moving:
PS> Get-MoveRequest -MoveStatus InProgress | Get-MoveRequestStatistics

NOTE:  This command will not show successfully moved mailboxes, or mailboxes in a batch move that have not yet begun moving data.  This command is simply for displaying the current statistics of mailboxes in the process of moving.

Moving Mailboxes with a Large Number of Corrupted Items
While the mailbox wizard has a configurable number of acceptable corrupt items in any one mailbox to still move the mailbox, there is a limit on the number of corrupted items allowed regardless of the number set in the wizard.  If you try to move a mailbox and it appears to be moving fine, then fails, many times the failure is caused by corrupted items in the user's mailbox.  To view a full report of the move, see the command below, as the detailed report will clarify what caused the mailbox move failure.  If the mailbox has too many corrupted items, to successfully move the mailbox to the new database, you must move the mailbox using a management shell cmdlet allowing a larger amount of loss.

To move a mailbox with a large number of corrupted items:
PS>New-MoveRequest user@domain.com -baditemlimit 500 -AcceptLargeDataLoss -TargetDatabase “Database Target”

Note:  In this example we have accepted a bad item limit of 500, you can change this number to whatever you need for your situation.

Viewing the Full Move Request Report for a User whose Mailbox Move Failed
If you have a user whose mailbox fails to move, you can access a detailed report to see the progress of the move until it failed.  With the detailed report you can find what caused the mailbox move to fail.  If the user has too many corrupted items, you can use the cmdlet above to move the mailbox.  If the user's mailbox is corrupted, you can use the last cmdlet listed to try and repair the mailbox and then start the mailbox move again.  One important thing to note is the user move report is only available as long as the move request has not been removed either in the EAC migration section, or by using a management shell cmdlet.

To view the details of a move request for a user's mailbox:
PS>Get-MoveRequest -Identity user@domain.com | Get-MoveRequestStatistics -IncludeReport | fl

Note:  This is only the beginning and end of a user's report.  The end of this report shows a transient error, which is commonly fixed by using the mailbox repair cmdlet listed below.

Removing a Move Request Created in the Management Shell
If you create a mailbox move request in the management shell, for example to move a mailbox with many bad items, the mailbox move is not listed in the migration screen under the recipients category.  However, you can check the status of the mailbox move using the mailbox move statistics cmdlet listed above.  Also, if a mailbox move created in the management shell fails, you will need to remove the mailbox move request using the management shell.

To remove an existing mailbox move request:
PS> Remove-MoveRequest –Identity "user alias"

Running a Mailbox Repair without Dismounting the Database
There are times when mailbox moves will fail for different reasons.  If you have mailboxes showing "transient errors" when you run the mailbox move statistics cmdlet, you can try running a mailbox repair to fix the mailbox with this error.  The benefit of running this cmdlet is it runs against a mailbox without the need to dismount the mailbox database.  This means the repair will not affect any other users and reduces potential downtime.  As the repair runs, details about the repair will appear in the Application log of the event viewer on the machine the repair is running on.  Look for codes showing the repair has begun, Event ID 10047, and has successfully completed, Event ID 10048.

To run a repair on a corrupted mailbox without dismounting the database:
PS> New-MailboxRepairRequest -Mailbox user@domain.com -CorruptionType SearchFolder, AggregateCounts, ProvisionedFolder, FolderView

Note:  The example of this command is running all four of the available repairs against the mailbox.  You do not have to use all four repairs if you know cause of the errors.

Regardless of how many databases or user mailboxes exist in your organization, the new Exchange 2013 management interface requires some time to feel familiar.  For some of the things the management interface will not do, like moving mailboxes with a large amount of bad items, using cmdlets is the only way to accomplish the necessary move.   Using cmdlets often provides more options, more control, and more details about mailboxes being moved, including reporting information to help troubleshoot issues.

If you are planning to upgrade to Exchange 2013, setting aside plenty of time for testing, moving data, and familiarizing yourself with the new interface will definitely pay off.  The cmdlets listed above provide tools to deal with issues including detailed information about each issues as they arise, and they will.  As always, good luck!

Enjoy this post? Subscribe to our Blog