Planning and migrating a small organization from Exchange 2007 to 2013 (Part 16)

By / October 1, 2017

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

Introduction

We’re now ready to migrate user mailboxes to Exchange 2013. Of course, the migration of the mailboxes themselves might only be one topic within this article, but might take place over a number of days, weeks or even months as batches are created and then migrated whilst your organization coexists during migration. However it’s what our detailed preparations and setup has been leading up to, and by this point should be a fairly straightforward affair. After migration of mailboxes, we’ll begin the clean-up and removal of Exchange 2007.

Migrating Mailboxes

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

Migrating Mailboxes

When it comes to migrating mailboxes, 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 couple of methods that make this easy.

The first 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 1: Beginning mailbox migration using the Exchange Management Shell

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 2: 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 above during our test mailbox moves. Use the New Migration Batch wizard to select mailboxes from the Global Address List, as shown below:

Image
Figure 3: 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 4: 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 5: Monitoring individual move progress using the EAC

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

One additional consideration, whichever way you migrate mailboxes is how many mailboxes you can migrate in a single batch. For environments that use traditional backups, like within our example organization, logs are generated each day and then expunged after backups complete.

When a mailbox is moved, log files consuming the same amount of space as the mailbox itself are generated. These two factors mean 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.

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

Get-Mailbox -Server <Exchange 2007 Server Name>

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 E12M01 | New-MoveRequest -BatchName “Remaining Mailboxes”

Upgrading Exchange AD Objects

With all mailboxes now residing on Exchange 2013, and users happy we know there’s no going back. Therefore, it’s time to upgrade the AD objects that support Email Address Policies, Address Lists and Distribution Groups to Exchange 2013 format.

Thankfully the process to do this is fairly straightforward and is similar to the process used when migrating from Exchange 2007 to 2010. To upgrade each of the aforementioned AD objects, perform the following commands as shown below:

Get-EmailAddressPolicy | Set-EmailAddressPolicy

Get-GlobalAddressList | Set-GlobalAddressList

Get-AddressList | Set-AddressList

Get-DistributionGroup | Set-DistributionGroup

After completing these steps, perform all management of these objects from the Exchange Admin Center, or Exchange 2013 Management Shell.

Migrating Public Folders

If you’ve chosen to keep Public Folders around then now you have migrated all users to Exchange 2013, it’s now time to move those public folders across to Exchange 2013 too. To recap, the latest version of Exchange no longer uses dedicated Public Folder databases and now stores Public Folders within special Public Folder Mailboxes. This makes Public Folder management simpler, as replication is performed by making Mailbox Databases highly available rather than replicating public folders themselves.

This does mean that to migrate mailboxes to Exchange 2013, we’ll need to perform a one-time migration from Exchange 2007, which is comprised of the following steps:

  • Perform a snapshot of the current Public Folder environment.
  • Create a CSV file containing mappings from Exchange 2007 Public Folders to Exchange 2013 Public Folder Mailboxes.
  • Create new Public Folder Mailboxes on the Exchange 2013 environment.
  • Migrate Public Folder content from Exchange 2007 to Exchange 2013.
  • Lock the source Exchange 2007 environment before performing a final synchronization of the Public Folder content to Exchange 2013.
  • Test Public Folder content is accessible within the environment.
  • Compare the results of the migration to the pre-migration snapshot.

We cover the steps for this migration of Public Folder content in a dedicated two-part series, Migrating Public Folders to Exchange 2013.

Getting ready to decommission Exchange 2007

By this point, we should be safe to remove Exchange 2007 from the environment. Earlier in the series we moved inbound and outbound mail flow to Exchange 2013, moved client access across and of course migrated all Mailboxes, and where appropriate, Public Folder content, over to Exchange 2013.

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

Also double check you’ve implemented and migrated mail flow as detailed in part 12 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 2007 infrastructure, we should be ready to remove Exchange 2007 completely. To ensure that this is definitely the case, shut down the Exchange 2007 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 2007 servers can be re-started and anything that wasn’t originally identified be migrated.

Disabling coexistence

We’re now on the home run and are starting the somewhat easier job of stripping out the supporting infrastructure for Exchange 2007 before removing Exchange 2013 itself. Our first task is to remove the configuration used for coexistence during migration.

Removing TMG Rules

First, we’ll remove the TMG rules that we implemented during part 14 of this series. As we ensured that these rules were named appropriately to specify that their purpose was to support access to Exchange 2007, these should be easy to identify. In our example organization, we have the following two rules to remove:

  • Exchange 2007 EWS and OAB
  • Exchange 2007 OWA

Select both of these rules in the Forefront TMG 2010 management console, within Firewall Policy, and then right click and choose Delete.

Image
Figure 6: Removing TMG rules used for coexistence

After removing both rules, choose Apply to make the configuration live:

Image
Figure 7: Applying the updated TMG configuration

Removing Legacy DNS entries

To support client access to Exchange 2007 during coexistence, we created a legacy DNS entry used both by external clients (via the above TMG rules) and by internal clients accessing services like OWA and EWS. We no longer need this entry, therefore using DNS Manager we will remove this record from the internal DNS:

Image
Figure 8: Removing internal legacy DNS entries

We also created an external DNS entry that provided access via TMG for Exchange 2007 clients. We’ll also remove this legacy record, as it’s no longer required.

Summary

In this penultimate part of this series we’ve migrated all mailboxes from Exchange 2007 to Exchange 2013, and then upgraded AD objects, moved any public folders and removed configuration for coexistence from the environment. In the final part of this series we’ll decommission Exchange 2007 from the environment.

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

Read Next

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.

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