If you would like to read the other parts in this article series please go to:
- Migrating a small organization from Exchange 2010 to Exchange 2013 (Part 1)
- Migrating a small organization from Exchange 2010 to Exchange 2013 (Part 2)
- Migrating a small organization from Exchange 2010 to Exchange 2013 (Part 3)
Introduction
In this series we rapidly migrate from Exchange 2010 to 2013. In the previous parts in this series we planned the server specifications, installed a new server and configured it correctly, installed Exchange 2013, performed post installation configuration and began preparation.
Preparing for Exchange 2013 Migration
Updating Inbound Mail Routing
We have tested that our Exchange 2013 server can receive mail and deliver it to Exchange 2010 users. By default, Exchange 2013 is already configured to receive email from the Internet using Anonymous permissions on the default receive connector.
If this hasn’t been changed from the defaults, update either firewall rules to direct traffic on SMTP port 25 to the Exchange 2013 server, or update your spam filter appliance.
Once this change has been applied ensure that inbound mail flow is not interrupted before moving on to migrating outbound mail flow.
Updating Outbound Mail Routing
Now that incoming mail is now flowing through Exchange 2013, our next step is to make the changes required to allow and then reconfigure Exchange Server 2013 to be responsible for outbound mail flow rather than via the Exchange 2010 server.
In our example environment our mail flow is directed to the Internet, but in your organization you might use a spam filter appliance. Therefore make sure if you use a smart host for relay, ensure the IP address of the new Exchange 2013 server is added as a server allowed to relay outbound messages.
Likewise, if you email direct to recipients then ensure the Firewall rules allow the Exchange 2013 server IP address to initiate connections to Internet hosts on TCP port 25 without tampering (such as SMTP Fixup).
After ensuring that the Exchange 2013 server is allowed to relay outbound mail, we’re ready to update the Send Connector. To perform this step, open the Exchange Admin Center and navigate to Mail Flow and then choose Send Connectors. You should see the Send Connector used for outbound mail flow within the list:
Figure 1: Navigating to the Send Connector configuration within Exchange 2013
Open the properties for the Send Connector used for outbound mail flow – in our case the Outbound Mail (New) connector created earlier in this series.
Navigate to the Scoping tab and locate the Source server section. The Exchange 2010 server should be listed. Choose Add (+) and select the Exchange 2013 server, then select the Exchange 2010 and choose Remove (-); leaving only the Exchange 2013 server within the server list:
Figure 2: Updating the source server used for outbound mail flow
After verifying both the server IP address is listed as able to relay, and that the correct Exchange 2013 server has been selected, choose Save to apply the configuration.
As with updating inbound mail routing, ensure you test outbound mail flow is unaffected before continuing.
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 using and 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 Exchange 2010 to Exchange 2013, 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 mailbox moved using the following command:
| Get-Mailbox -Database <Database> | New-MoveRequest -TargetDatabase <Database_E15> -BatchName <Database> |
Figure 3: 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” |
Figure 4: 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 |
Figure 5: 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:
Figure 6: 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:
Figure 7: 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:
Figure 8: 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 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 2013 using the New-MoveRequest cmdlet again:
| Get-Mailbox -Server <Server> -Arbitration | New-MoveRequest |
Figure 9: Moving Arbitration Mailboxes
After all mailbox moves from the Exchange 2010 server are 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 |
Figure 10: Removing Move Requests
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 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 use the Exchange 2010 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. 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 mailflow 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 2013, 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:
Figure 11: Removing an unused Offline Address Book
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 2013.
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 |
Figure 12: Verification no Mailboxes exist on Exchange 2010
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 |
Figure 13: Removing Mailbox Databases
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 14: Locating and 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 15: Uninstalling Exchange 2010 components
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 16: Verification Exchange 2010 is ready to uninstall
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 series we’ve migrated from Exchange 2010 to 2013. When considering your upgrade, ensure you also consider your backup technologies and testing the infrastructure using JetStress before moving mailboxes across. What we have shown is that a migration from Exchange 2010 to a new version of Exchange is potentially the simplest Exchange migration in recent history, and should be considered.
If you would like to read the other parts in this article series please go to:
Thanks Steve for this article. Started migrating to exchange 2013 this pas week and this has helped me a lot. I’m at the testing mailbox move stage and found an issue not mentioned. Outlook would not connect and would constantly ask for authentication. Found out that there was no OAB policy assigned to the user. Once I assigned the default OAB policy outlook was able to connect.