In the final part of this series, we’ll begin the migration of mailboxes to Exchange Server 2016. After this completes we will decommission Exchange Server 2010.

Migrating Mailboxes to Exchange 2016

Migrating the Pilot Group

Before migrating mailboxes en-mass to Exchange 2016, it’s important to validate that you’ve had an opportunity to identify any issues that using and moving test mailboxes didn’t expose.

First we will select a pilot group of users to migrate to Exchange Server2016. They should provide feedback on any issues they encounter, and will represent a cross-section of end-users; for example users that are heavy mobile users, those that are primarily external users and those that regularly use features like shared calendars and delegation.

Many smaller organizations will find most pilot candidates within the IT department, but if you have users who are keen to be early adopters outside of IT, then you’ll get a better representation of real issues.

Migrating Mailboxes

When migrating mailboxes from Exchange 2010 to Exchange 2016, we’ve got a number of methods that can be used to migrate mailboxes in large numbers.

The first method applies if you have created equivalent databases to match your source Exchange 2010 environment. For each database, you can queue up mailboxes to be moved using the following command:

Get-Mailbox -Database <Database> | New-MoveRequest -TargetDatabase <Database_E2016> -BatchName <Database>

Figure 1: Creating new move requests

If you are using traditional backups on your Exchange 2016 server then take into account the impact of log file usage when determining the batch sizes.

When a mailbox is moved, log files consuming the same amount of space as the mailbox itself are generated. This means that you can only move as many mailboxes as log space allows in between regular backup jobs.

You can mitigate against this by either performing additional incremental backups during mailbox migrations; or temporarily turning on circular logging.

We can keep track of the migrations using the Exchange Management Shell by calling the Get-MoveRequest cmdlet, again specifying the BatchName; then piping the output to Get-MoveRequestStatistics to gain a detailed insight into our current batch of migrations:

Get-MoveRequest -BatchName “<Database>” | Get-MoveRequestStatistics

Figure 2: Monitoring move requests from PowerShell

If you’d prefer to use the Exchange Admin Center rather than PowerShell to co-ordinate the migration, then consider using the migration batches, as shown during our test mailbox moves.

Figure 3: Using the EAC interface to the New Migration Batch cmdlets

Use the New Migration Batch wizard to select mailboxes from the Global Address List, as shown below:

Figure 4: Adding mailboxes to the new migration batch

After creating and starting a migration batch via the Exchange Admin Center, we can examine the progress of those moves by selecting the migration batch from the list, and then choosing View Details:

Figure 5: Viewing the list of Migration Batches

We’ll then be presented with a list of all mailboxes within the batch, each of which can be selected and the full status available for detailed examination:

Figure 6: Monitoring progress of a Migration Batch

Either of these two methods is equally effective, and whichever you use is down to which ever method makes most sense within your organization.

After performing migrations of end users you can verify that no additional mailboxes remain on Exchange 2010, using the following command at the Exchange 2016 Management Shell:

Get-Mailbox -Server <Server>

If any mailboxes do remain, then pipe the results of the command to the New-MoveRequest cmdlet as a new migration batch, for example:

Get-Mailbox -Server <Server> | New-MoveRequest -BatchName “Remaining Mailboxes”

We’ll also need to move the system mailboxes from Exchange 2010. We’ll find these by using the Get-Mailbox cmdlet with the –Arbitration parameter:

Get-Mailbox -Server <Server> -Arbitration

You’ll expect to see a couple. Move them to Exchange 2016 using the New-MoveRequest cmdlet again:

Get-Mailbox -Server <Server> -Arbitration | New-MoveRequest

After all mailbox moves from the Exchange 2010 server are complete, remove the mailbox move requests from Exchange 2016.

To remove successfully completed move requests, use the Remove-MoveRequest cmdlet in combination with the output of Get-MoveRequest:

Get-MoveRequest -MoveStatus Completed | Remove-MoveRequest

Figure 7: Removing completed move requests

If you opted to use the Migration Batch method then you can remove it via the Exchange Admin Center by viewing the batch, and then if it is complete, hitting the Delete button:

Figure 8: Removing a completed batch

Decommissioning Exchange 2010

Getting ready to decommission Exchange 2010

By this point, we should be safe to remove Exchange 2010 from the environment. Earlier in the series we moved inbound and outbound mail flow to Exchange 2016, moved client access across; and we have just completed migrating all Mailboxes over to Exchange 2016.

Before removing the staging server, it’s important to verify that these servers are definitely no longer used. For example, if you have devices that use the Exchange 2010 server for SMTP relay, double check that all these devices have been updated to use the Exchange 2016 server.

Also double check you’ve implemented and migrated mail flow. We’ll need to verify that both Inbound and Outbound mail (via Receive and Send Connectors respectively) is configured to flow via Exchange 2016 only.

After checking that mail flow should no longer be configured to flow through the Exchange 2010 infrastructure, we should be ready to remove Exchange 2010 completely. To ensure that this is definitely the case, shut down the Exchange 2010 server and leave switched off for a reasonable period of time (for example, a week) to ensure that should anything have been missed the Exchange 2010 server can be started up and anything that wasn’t originally identified migrated.

Removing unused Offline Address Books

We’ll start off with a relatively simple task, removing the old default Offline Address Book.

As part of the installation of Exchange 2016, a new Offline Address Book was created and set as the default. This will have the suffix (Ex2013) signifying it is created by Exchange 2013 or above.

We’ll remove the old Exchange 2010 one by opening the Exchange Management Console and navigating to Organization Configuration>Mailbox and then within the Offline Address Book tab selecting the original address book, with the Generation Server specified as the old Exchange 2010 server. Simply choose Remove:

Figure 9: Removing obsolete Offline Address Books

Removing Databases

In our example organization we do not use Public Folders, therefore we only have one type of Database we need to remove from our Exchange 2010 – Mailbox Databases.

Before we press ahead and remove the databases, we’ll need to double check that all mailboxes have been moved to Exchange 2016.

To verify all mailboxes have been removed from our Exchange 2010 server, we’ll use the following commands:

Get-Mailbox -Server <ServerName> Get-Mailbox -Server <ServerName> -Arbitration Get-Mailbox -Server <ServerName> -Archive

After verifying that no mailboxes exist on the server, we’re ready to remove the databases. As part of this process Exchange 2010 will double check that no mailboxes exist. It will not allow the removal of databases that contain mailboxes.

We’ll use the following PowerShell command from our Exchange 2010 server to first get a list of the databases:

Get-MailboxDatabase –Server <ServerName>

After confirming that the command is showing the correct databases, remove the Mailbox Databases using the following command;

Get-MailboxDatabase –Server <ServerName> | Remove-MailboxDatabase

Uninstalling Exchange 2010

With Mailbox Database configuration removed we can now uninstall Exchange Server 2010.

To do this, navigate to Programs and Features, within the Control Panel and choose Uninstall after selecting Microsoft Exchange Server 2010 from the list of installed applications:

Figure 10: Uninstalling Exchange 2010

The Exchange Setup application is used for the uninstallation process, much like it was used for the original installation. When prompted, we’ll therefore unselect each Exchange Role installed, for example Client Access, Hub Transport and Mailbox.

Additionally, we’ll choose to uninstall the Management Tools – which includes the Exchange Management Console and Exchange Management Shell:

Figure 11: Uninstalling all components of Exchange 2010

After choosing Next, Exchange Server Setup will perform checks to ensure that we’re actually ready to uninstall. After moving Send Connectors earlier in this series and performing the tasks in this article, we’ll expect each readiness test to complete successfully, allowing us to choose Uninstall:

Figure 12: Verification of successful uninstallation

After choosing Uninstall we’ll expect the setup program to continue with removal of Exchange 2010. After it completes successfully the server can be decommissioned, and the server removed from the domain.

Summary

In this six-part series we’ve walked through a straightforward migration to Exchange 2016 from Exchange 2010. If you had experienced migrations between previous versions you will have seen that in comparison, the Exchange 2016 migration process is relatively straightforward.