Home » Exchange Server » Exchange Server 2016 Migration – Preparing for Coexistence

Exchange Server 2016 Migration – Preparing for Coexistence

The Exchange 2016 migration for Not Real University is getting to the stage where they can start cutting over client access and transport services to the Exchange 2016 Mailbox server. This stage is referred to as coexistence. Before any services are cut over, there’s some preparation tasks to perform.

Health Check

First, it’s advisable to perform a general health check of the existing production environment. The reason for performing a health check now is to determine if there are any existing problems that you might not already be aware of. If you start a migration, then notice the problems, troubleshooting is more complicated because you will be unsure whether the problem has been caused by the migration or not.

To perform a health check you can:

  • Run the Test-ExchangeServerHealth.ps1 script.
  • Use the Remote Connectivity Analyzer to test external access such as Outlook Anywhere and ActiveSync.
  • Verify that backups for the existing and new Exchange servers are running successfully.
  • Review your server event logs for any unusual errors.
  • Perform Outlook tests on the network including creating a new Outlook profile, scheduling a meeting and viewing free/busy information for attendees, accessing public folders, and sending/receiving internal and external email.

Outlook Anywhere

When the client access namespaces are cut over to the Exchange 2016 server, Outlook Anywhere connections for Exchange 2013 and 2010 mailbox users will be proxied from the 2016 server to the 2013 or 2010 server. For Exchange 2010 mailbox users, Outlook Anywhere authentication needs to be configured on the 2010 server to allow the proxied connections to work.

The following command will display the Outlook Anywhere configuration for Exchange 2010 servers.

If the IISAuthenticationMethods are configured for Basic only, then the following command will add NTLM authentication as well.

OWA Authentication

The default OWA authentication settings for a newly installed Exchange 2016 server are:

  • Forms-based authentication
  • DomainUsername logon format

If you have a different logon format requirement you should make those changes to the virtual directory settings now before you cut over any namespaces or move any mailboxes. For example, Not Real University uses the user principal name (UPN) as the logon format, which matches the users’ primary email addresses.


Testing Client Access

The cutover of client access namespaces to Exchange 2016 involves a DNS change. If you change the DNS record for your client access namespace, all of your users will begin making connections for some Exchange services to the Exchange 2016 server. If there’s a problem, it will impact all of the users.

To avoid an unexpected problem, it’s advisable to test the client access change before you modify the DNS record. To perform this test you can use a hosts file entry on a test workstation, to point that single client’s connections to the Exchange 2016 server. You can follow the steps outlined in this article to modify the hosts file.

Moving Arbitration Mailboxes

The final task before any production services are cut over to Exchange 2016 is to move the arbitration mailboxes. Arbitration mailboxes are responsible for things like transport moderation and audit logging, and need to be hosted on the highest version of Exchange in the organization. The mailboxes themselves are typically quite small and will move fairly quickly.

In the Exchange Management Shell, run the following command to move the mailboxes to a database on your Exchange 2016 server.

In the next article in this series, we’ll look at performing the cutover of the client access namespaces to Exchange 2016.

Paul is a Microsoft MVP for Office Servers and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul is a co-author of Office 365 for IT Pros and several other books, and is also a Pluralsight author.
Category: Exchange Server


  1. Jason says:

    If we have OWA with basic auth on 2010 and we configure 2013 also with basic auth. When a user with mailbox on 2010 access OWA on 2013 after CAS switch. He auth on 2013 and then he will be proxied to 2010. Does he need to auth with basic auth again?

  2. Jason says:

    Customer does not want fba cause Basic is wat users are used to user.
    But do users need to auth twice (once on 2013 owa & then 2010 owa) if Basic auth is used?
    And does this also apply to fba?

    • If FBA is used and coexistence is set up properly, they only need to auth once.

      If Basic is used, I’m not 100% sure because I haven’t tried it lately, but I believe they will get prompted for auth a second time.

      FBA is a better use experience. I’m not sure why they would want to stick to Basic.

Leave a Reply

Your email address will not be published. Required fields are marked *