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

By /

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

Preparing for Exchange 2013 Migration

Testing base functionality

Before we can move namespaces and mailboxes across to Exchange Server 2013 we need to test that the new server works as expected. We’ll start by creating a test mailbox to use on Exchange 2013. To do this, navigate to the Exchange Admin Center and within Recipients choose Add, then User Mailbox:

Image
Figure 1: Creating a test mailbox using the Exchange Admin Center

There is no prescriptive name for a basic test account, so enter suitable unique and identifiable details:

Image
Figure 2: Example settings for a new test account

After creating our test mailbox we’ll now need to test that they are functional from a client. We’ll go to OWA via the server’s name. As a minimum, test mail flow works correctly between our new Exchange 2013 test user and existing Exchange 2010 users.

Image
Figure 3: Verifying OWA functionality

After verification that OWA works correctly we will move onto updating Exchange 2010 URLs.

Updating Exchange 2010 Virtual Directory URLs

Exchange 2013 supports acting as a proxy for Exchange 2010 services. This means that it is easy to allow Exchange 2010 and Exchange 2013 to co-exist using the same URLs.

We decided earlier in this guide that we would use the same names for both Exchange 2013 and 2010, and at this point we will move the Autodiscover and mail.lisajanedesigns.co.uk names across from Exchange 2010 to Exchange 2013. This, combined with DNS changes, will result in HTTPS client traffic for Exchange 2010 going via the Exchange 2013 server. This makes coexistence simple.

We will update our core URLs for Exchange 2010 to remove the ExternalURL value. We’ll also enable Outlook Anywhere, configuring it with the HTTPS name that will move to Exchange 2013. To do this we will login to our Exchange 2010 staging server and launch the Exchange Management Shell, then enter the following PowerShell commands:

$Server =   “Exchange2010Server”

$HTTPS_FQDN = “mail.domain.com”

Get-OWAVirtualDirectory -Server $Server | Set-OWAVirtualDirectory   -ExternalURL $null

Get-ECPVirtualDirectory -Server $Server | Set-ECPVirtualDirectory   -ExternalURL $null

Get-OABVirtualDirectory -Server $Server | Set-OABVirtualDirectory   -ExternalURL $null

Get-ActiveSyncVirtualDirectory -Server $Server | Set-ActiveSyncVirtualDirectory  -ExternalURL   $null

Get-WebServicesVirtualDirectory -Server $Server   | Set-WebServicesVirtualDirectory  -ExternalURL   $null

Enable-OutlookAnywhere -Server $Server -ClientAuthenticationMethod Basic -SSLOffloading $False -ExternalHostName   $HTTPS_FQDN -IISAuthenticationMethods   NTLM,   Basic

Image
Figure 4: Reconfiguration of Exchange 2010 virtual directories

From a client perspective this should not have any immediate effect. The Exchange 2013 server will provide External URL values via Autodiscover, but in the meantime client traffic will still be directed at the Exchange 2010 staging server.

Updating Internal DNS records and switching external HTTPS connectivity

To direct traffic internally at the Exchange 2013 server we need to change internal DNS records so that both the Autodiscover name and HTTPS namespace (in our case, mail.lisajanedesigns.co.uk) are configured with the IP address of the new Exchange 2013 server.

On a server with access to DNS Manager, such as an Active Directory domain controller, update both records from the IP address of the Exchange 2010 staging server to the Exchange 2013 server:

Image
Figure 5: Updating internal DNS records

Clients will not be immediately redirected to use the Exchange 2013 server as the proxy for client access, and instead will do so once their cached records expire. As soon as clients can access the server retry login and client access to ensure no issues exist.

If internal access works without issue, update the external HTTPS publishing – which in our example organization is mapping via the router.

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.

Before we go ahead and update the Spam Filter or Firewall to deliver mail directly to Exchange 2013 we will double check that this is indeed the case.  To do so, open the Exchange Admin Center and navigate to Mail Flow, then select Receive Connectors.

Within Receive Connectors select the Exchange 2013 server from the Select Server list and then select the Default Frontend connector; then choose Edit as shown.

Image
Figure 6: Locating the Anonymous receive connector

This is the connector that listens on port 25 for standard SMTP connections. In the Exchange Receive Connector properties, select the Security tab and then examine the section Permission Groups. Ensure Anonymous users is selected to allow inbound mail from the Internet:

Image
Figure 7: Verification that anonymous clients can deliver email to the server

After ensuring this is correctly configured, 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 our Exchange 2010 staging server.

In our example environment our mail flow is direct 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, that 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.

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 and then choose Send Connectors. You should see the Send Connector used for outbound mail flow within the list:

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

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

Summary

In this part of the series we have ensured the environment is ready for the mailbox migrations. In the next part in this series we will migrate mailboxes to Exchange 2013 and begin the clean-up of the environment.

If you would like to be notified of when Steve Goodman releases the next part in this article series please sign up to our MSExchange.org Real Time Article Update newsletter.

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