Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 18)

By /

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

Introduction

In part 17 of this series, we completed the post installation configuration and performed some basic tests against the Exchange environment to ensure that Exchange 2013 is ready for users to access, then configured coexistence.

Migrating Mailboxes to Exchange 2013

Migrating the Pilot Group

Before migrating mailboxes en-mass to Exchange 2013, it’s important to validate that you’ve had an opportunity to identify any issues that moving test mailboxes didn’t expose. Therefore select a pilot group of users to migrate to Exchange 2013 that will 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 our Exchange 2010 staging server to Exchange 2013, we’ve got a number of methods that can be used to migrate mailboxes in large numbers. We’ll have a look here at a few methods that make this easy.

The first method applies if you aligned the mailboxes from Exchange 2003 to databases on the Exchange 2010 staging server and want to keep that layout. For each database, you can queue up mailboxes moved using the following command:

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

Image
Figure 1: Migrating mailboxes on a per-database level

If you are using traditional backups on your Exchange 2013 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.

The second method is to use Distribution Groups to co-ordinate migrations of mailboxes. This works well because you can use the Distribution Groups to communicate with users as well as use it to initiate mailbox moves.

You’ll see in the example below we use the Get-DistributionGroupMember cmdlet to get a list of mailboxes within a distribution group, then pipe it to the New-MoveRequest cmdlet, with the BatchName specified to help us identify this set of users, and leaving the Target Database blank to distribute the users randomly across databases:

Get-DistributionGroupMember “Marketing”   | New-MoveRequest   -BatchName “Marketing”

Image
Figure 2: Beginning mailbox migration using the distribution groups

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 “Marketing” |   Get-MoveRequestStatistics

Image
Figure 3: Monitoring migration status using the Exchange Management Shell

If you’d prefer to use the Exchange Admin Center rather than PowerShell to co-ordinate migration, then consider using the migration batches, as shown during our test mailbox moves. Use the New Migration Batch wizard to select mailboxes from the Global Address List, as shown below:

Image
Figure 4: Creating a Migration Batch using the EAC

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:

Image
Figure 5: Monitoring progress of a new migration batch within the EAC

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:

Image
Figure 6: Monitoring individual move progress using the EAC

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 2013 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 created when we installed Exchange 2010 on our staging server. 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 2013 using the New-MoveRequest cmdlet again:

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

Image
Figure 7: Moving Arbitration Mailboxes

After all mailbox moves from the Exchange 2010 server complete, remove the mailbox move requests from Exchange 2013. 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

Image
Figure 8: Removing Move Requests

Decommissioning Exchange 2010

The removal of our Exchange 2010 staging server from our organization is fairly straightforward, but must be approached in a logical order to ensure success and minimal issues. Therefore we’ll remove some Exchange components like unused Offline Address Books and Databases before uninstalling Exchange 2010 itself.

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 2013, moved client access across; and we have just completed migrating all Mailboxes over to Exchange 2013.

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 had to be updated from Exchange 2003 to use the Exchange 2010 staging server for SMTP relay, double check that all these devices have been updated to use the Exchange 2013 server.

Also double check you’ve implemented and migrated mail flow as detailed in part 17 of this series. We’ll need to verify that both Inbound and Outbound mail (via Receive and Send Connectors respectively) is configured to flow via Exchange 2013 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 infrastructure 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 servers can be re-started and anything that wasn’t originally identified be migrated.

Removing unused Offline Address Books

We’ll start off with a relatively simple task, removing the old Offline Address Book that came across from Exchange 2003 to Exchange 2010.

As part of the installation of Exchange 2013, you’ll remember a new Offline Address Book was created and set as the default. 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:

Image
Figure 9: Removing an unused Offline Address Book

Summary

In this article we’ve migrated our mailboxes from the Exchange 2010 staging server to Exchange 2013 successfully and after checking the Exchange 2010 staging server is no longer used, have started the removal process to ensure the staging server is correctly removed. In the final part of this series, we’ll complete the uninstallation process.

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

About The Author

Steve is a 5 times recipient of the MVP (Microsoft’s Most Valuable Professional) award from Microsoft, is a regular international conference speaker, podcast host, regular blogger, plus he is the author of a number of popular Exchange books. Steve is Head of Messaging and UC at top Office 365 partner Content and Code, responsible for their Exchange and Skype for Business offerings. Steve has worked on a vast number of Exchange and Office 365 projects across customers large and small, often with complex requirements and loves to share his expertise.

Read Next

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