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

by [Published on 14 Jan. 2014 / Last Updated on 14 Jan. 2014]

In this part of this series we’ll update mail routing, implement our backup software, and then test migrating mailboxes to Exchange 2013.

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

Introduction

In the previous part of this series we completed configuring coexistence and clients who access Exchange 2007 via Exchange 2013. In this part of the series we’ll update inbound and outbound mail routing to ensure all mail flows through the new version of Exchange, ensure backup software is implemented then start migrating test mailboxes to Exchange 2013.

Updating Mail Routing

Our first task after implementing coexistence is to migrate inbound and outbound mail routing to flow via our Exchange 2013 infrastructure. Strictly speaking mail flow can be migrated either before or after we migrate mailboxes, but as moving mailboxes may take some time, moving mail flow now will allow for some time to ensure devices that relay through Exchange have also been updated. Performing this task now will also mean that when we come to decommission Exchange 2007, we won’t need to combine the task with moving mail flow over at the same time.

Updating Inbound Mail Routing

The steps we’ll perform here are unlikely to be identical within your environment unless you have a very similar setup, however the technicalities of the changes are common across most anti-spam or edge mail relay solutions.

In our example environment, we’re using GFI MailEssentials which uses the IIS SMTP services to route email. Therefore we’ll need to update the domain within the virtual SMTP server to ensure that the host it relays mail to is Exchange 2013 rather than Exchange 2007.

We’ll make this change by opening IIS Manager and navigating to the SMTP Virtual Server, then selecting our domain, exchangelabs.co.uk within the list of Domains:

Image
Figure 1: Selecting the inbound domain within the Spam Filter host

After opening the Properties window for the domain, we’ll update the setting Forward all mail to smart host within the Route domain section to the name of the Exchange 2013 server, E15M01.exchangelabs.co.uk as shown below:

Image
Figure 2: Updating the server name used as destination for inbound mail

After making this change, ensure that inbound mail flow is not interrupted before moving on to migrating outbound mail flow.

Updating Outbound Mail Routing

Within incoming mail now flowing through Exchange 2013, we’ll now make the changes required to allow and then reconfigure Exchange 2013 to be responsible for outbound mail flow.

We’ll demonstrate the steps required to do this using our example environment’s IIS SMTP relay server, which again is similar in concept to other spam filtering or relay solutions.

Simply put, if Exchange 2007 relays outbound mail through a smart host, we’ll need to ensure the IP address of the Exchange 2013 server is on the smart-host’s allowed list, and then ensure that the Send Connector in Exchange is reconfigured to specify that the Exchange 2013 server will be responsible for sending email.

To perform this change within our IIS SMTP Server, we’ll open the IIS Manager and right-click on the SMTP Virtual Server, then choose Properties:

Image
Figure 3: Editing the properties used for outbound relay

In the SMTP Virtual Server properties window, select the Access tab and within the Relay Restrictions section, select Relay:

Image
Figure 4: Navigating to the relay restrictions section

In the Relay Restrictions window that opens the IP address of the Exchange 2007 server should be shown. Choose Add and enter the IP address of the Exchange 2013 server, which in our example organization is 192.168.15.10, as shown below:

Image
Figure 5: Adding the IP address of the Exchange 2013 server

After ensuring that the Exchange 2013 server is allowed to relay outbound mail, we’re ready to update the Send Connector within Exchange 2013. To perform this step, open the Exchange Admin Center and navigate to Mail Flow>Send Connector. You should see the Send Connector used for outbound mail flow within the list:

Image
Figure 6: Navigating to the Send Connector configuration within Exchange 2013

Open the properties for the Send Connector used for outbound mail flow, in our case Outbound via MailEssentials and navigate to the Scoping tab.

Within the Source Server section the Exchange 2007 server should be listed. Choose Add (+) and select the Exchange 2013 server, then select the Exchange 2007 and choose Remove (-); leaving only the Exchange 2013 server within the server list:

Image
Figure 7: 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.

Implementing Backup Software

Our final task before we start migrating mailboxes is to ensure our backup software is in place – and working. Implementing and testing backup software is dependent on your particular solution, so we won’t cover the specific steps. In general, these include:

  • Updating backup server software to a version (including a possible OS upgrade) that supports Exchange 2013
  • Creating a service account with the correct permissions within Exchange to perform backup and restore jobs
  • Creating a backup client on the backup software and enabling it with an Exchange-specific license
  • Installing Backup Agents for the core OS and for Exchange Server
  • Creating a backup job and backup schedule for the new Exchange Server.

In our example environment we are using a backup product that integrates with the virtualization platform, therefore we won’t expect to install agents on the virtual machine running Exchange itself, which significantly simplifies the backup and restore process; so if you are virtualizing Exchange, take a look at the solutions available on the market.

Testing Backup and Restore

Before moving any production mailboxes to Exchange 2013, make sure you test the restore process. Often it’s easy to backup Exchange and confirm that the backup completed successfully, but the trouble may begin when you perform a restore for the first time.

After performing a number of test backups of your test mailboxes, perform test restores for, at a minimum, the following scenarios:

  • Single Item Restore – for example, a single deleted message.
  • Single Mailbox Restore – for example, an entire mailbox deleted from Exchange.
  • Complete Database Restore to the latest point in time – for example, to recover from a corrupted or lost mailbox database.
  • Complete Database Restore to a point in history – for example, to roll the entire database back to a point earlier in the day.

If you’ve recently upgraded the backup software or are new to the product make sure you record the steps to perform a restore so you can ensure that you are not needing to find the manual the first time you perform a restore of a real mailbox.

Pre-Migration Test Migrations

With everything set up and ready to go, we now need to move Mailboxes to Exchange 2013 and verify everything works as expected. We'll do this in two simple steps; firstly, base service tests to check core functionality, and then extended tests where we'll verify that clients work properly too.

Base functionality tests

To begin our base functionality tests, we'll need to migrate a test mailbox to Exchange 2013. We'll accomplish this using the EAC, so log back in and navigate to Recipients>Migration and then from the Add drop-down, select Move to a different database:

Image
Figure 8: Exchange Admin Center features for Mailbox migration

You'll immediately see that the method to move mailboxes is different from previous versions of Exchange, and in this version, we're offered the opportunity to migrate mailboxes in Batches. So, instead of selecting mailboxes from the recipients list, and then monitoring each of those individually we can migrate mailboxes as a "group" and monitor progress.

For our first batch we'll add a couple of test users. In the example below we've moved the Administrator mailbox, and we've also moved a test mailbox, which we'll use for our base tests. To select the users choose Select the users that you want to move, then choose Add to select mailboxes from a recipient picker:

Image
Figure 9: Selecting test mailboxes to migrate

When the batch is complete, we can receive a notification to a mailbox. Whilst not so useful in testing, this new feature will be useful when we migrate real users to Exchange 2013. We also have the option to just create the batch and not begin the move, or to automatically start the migration batch after pressing New. Finally we'll have the option to Automatically Complete the Migration Batch, which basically means that mailbox moves can be completed and mailboxes switched; or if left unselected, the mailbox moves can be suspended when they are ready to complete.

Image
Figure 10: Selecting options for the migration batch

After creating our migration batch, because we've chosen to automatically start and complete the batch, we'll immediately see that the Status of the batch changes to Syncing:

Image
Figure 11: Monitoring migration batch progress

After some time, which depends on the size of the test mailboxes you migrate, the batch should complete. After completion, we'll see the status changes to Completed:

Image
Figure 12: Viewing the completed migration of test mailboxes

After the move completes, we should now be ready to start testing functionality. First, log into the user via Outlook Web App and verify base functionality works, including:

  • The user can send and receive email from Exchange 2013 and Exchange 2007 recipients.
  • The user can send and receive external email.
  • The user can send and receive mail sent to distribution groups.
  • The user can set and update their options.
  • After setting both an internal and external Out of Office message, the correct message is sent to respective recipients.
  • The Exchange 2013 user can see free/busy and shared calendars for other Exchange 2007 and 2013 mailboxes.
  • Mailboxes on Exchange 2007 can see free/busy and shared calendars for the Exchange 2013 mailboxes.
  • The Exchange 2013 mailbox can open Shared Mailboxes that it has permission to access.

Image
Figure 13: Testing a mailbox migrated using Outlook Web App

Assuming the basic tests are all fine (which they should be), we'll move on and start additional tests.

Internal client functionality tests

We know Outlook Web App works, so it’s now time to ensure the Outlook client works without issue. After moving a test mailbox to Exchange 2013, expect to see the familiar “The Microsoft Exchange administrator has made a change that requires you quit and restart Outlook”:

Image
Figure 14: Testing a migrated mailbox using the Outlook client

After re-launching Outlook, confirm you are connected to Exchange 2013 by holding down the CTRL key, and right clicking the Outlook icon in the notification area of the taskbar, and then choosing Connection Status. You should see the Server Name is updated to a GUID, and that connections are via the Proxy Server with the FQDN of your Outlook Anywhere name for Exchange 2013:

Image
Figure 15: Verification of connection to Exchange 2013

As you’ll see in the example above, we still have a connection to our Exchange 2007 server, to allow continued access to Public Folders until these are migrated after moving users.

We’ll also test additional internal clients in use, for example IMAP clients and Mac EWS clients. Verify that not only can they connect to Exchange after migrating the mailbox, but they can send and receive new mail:

Image
Figure 16: Verification of a third-party client

External client functionality tests

As we’ve got a range of external clients, we’ll also need to ensure they work correctly too. External users of Outlook should see a similar experience as internal clients, shown above, but ensure you test to catch any misconfigurations with publishing rules.

We’ll also test ActiveSync clients to ensure the experience is non-disruptive. From a user perspective, nothing should change for an ActiveSync user and they should not have to make any configuration changes on their device. As with other clients, send a test email before and after to ensure that new messages are received and can be sent after the mailbox move:

Image
Figure 17: Testing an ActiveSync client

Third-party software tests

Finally, ensure you test your third-party software. As part of our preparation, we configured the BlackBerry Enterprise Server in our environment to work correctly with Exchange 2013; so use this as an opportunity to test it works correctly. Set up a test device connected to the mailbox on Exchange 2007 before migrating to Exchange 2013 so that you can verify that the before/after experience is optimal and users continue to function normally.

If you’ve upgraded any additional third-party software, such as signature management software, ensure you thoroughly test these components too – this is your last opportunity to verify everything works as it should before migrating real users.

Summary

In this part of this series we’ve updated mail routing, implemented our backup software, and then tested migrating mailboxes to Exchange 2013. In this penultimate part of this series we’ll begin our migration of mailboxes, then begin the clean-up and removal of Exchange 2007.

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

Advertisement

Featured Links