Home » Exchange Server » Exchange Server 2016 Migration – Client Access Namespace Cutover

Exchange Server 2016 Migration – Client Access Namespace Cutover

The Exchange 2016 migration for Not Real University is at the stage where they are ready to cut over their client access namespaces to point to Exchange 2016. The cutover itself is just a DNS change for internal namespaces, and a firewall change for external namespaces, but it is a high impact change as it will result in all of your clients connecting to Exchange 2016 for HTTPS services. Any Exchange 2010 mailbox users will continue making RPC connections to the Exchange 2010 CAS array (RPCClientAccessServer). If public folders are still hosted on Exchange 2010 the Outlook clients for Exchange 2013/2016 mailbox users will be proxied to Exchange 2010 for public folder access.

As with any DNS change, rolling the change back is as simple as pointing the DNS record back to its previous value. To ensure a quick change and, if necessary, a quick rollback, you should lower the TTL of your DNS records to less than 5 minutes. A very low value of 1 minute is often recommended. When the change has been proven successful after a few days or weeks, you can increase that TTL value to something higher.

dns-ttl

For the external namespace cutover, rolling back the change is usually as simple as reversing the firewall rule changes.

If the external namespace being used, for example mail.notrealuniversity.com, is also the name used for the MX record for inbound mail flow from the internet, then any DNS or firewall changes will also impact inbound mail flow. That is unless your firewall is able to NAT the SMTP port (TCP 25) separately to the HTTPS port (TCP 443), which most firewalls can.

Before the change is made, Not Real University has the following client access flow:

  • Inbound HTTPS connections are NATed to the Exchange 2013 server. Internal HTTPS connections also resolve to the Exchange 2013 server. Exchange 2013 proxies HTTPS connections to Exchange 2010 and 2016 (there are no 2016 mailboxes at this time, but 2013 is capable of “up proxying” to 2016).
  • SMTP mail flow is unaffected by the changes planned for client access namespaces.

cas-cutover-1

After the DNS and firewall changes, the client access protocol flow for Not Real University is as follows:

  • Inbound HTTPS connections are NATed to the Exchange 2016 server. Internal HTTPS connections also resolve to the Exchange 2016 server. Exchange 2016 proxies HTTPS connections to Exchange 2010 and 2013, and public folder connections to Exchange 2010.
  • RPC connections for Exchange 2010 mailbox users resolve to the Exchange 2010 server.

cas-cutover-2

As an example, here is the Outlook connection status dialog box for an Exchange 2013 mailbox user after the client access cutover has been performed.

outlook-client-2

When the client access cutover has been completed and successfully tested, the mail flow cut over can also be performed, which is what we’ll look at next.

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

7 comments

  1. Jason says:

    Hi Paul,
    On the different VDIR (owa,ecp,ews etc) there is an Internal and an External authentication method. Can you tell more when which is used? Does Exchange somehow check where traffic comes from?

    • The recommended practice is to use the same URL for both internal and external on each vdir/service. However, in case such as Outlook Anywhere, where different auth is required for external access vs internal access (e.g. if external access comes via a reverse proxy that needs specific auth configured), then different namespaces can be configures so that Exchange and the client can tell whether the access being attempted is internal or external.

      • Jason says:

        OK but what if we use same namespace on internal & external URL and then use different authentication method for internal and external authentication, what authentication is when used and how does Exchange know of the auth is external or internal? Or are internal and external auth are used in conjunction with internal and external namespace?

  2. Steve says:

    Paul,

    If you are going to use different namespaces for 2016 (in a new AD site, new data center, don’t want the current location-centric namespaces used by 2010) that you will migrate 2010 over to (except Outlook Anywhere), can 2016 still proxy to 2010?

    I.e. current 2010 namespaces:

    OWA – abcowa.domain.com (needs to be unique as it’s sent through pre-auth before allowing in OWA)
    ECP – abcowa.domain.com
    EWS – abcmail.domain.com
    OAB – abcmail.domain.com
    AS – abcmail.domain.com
    AutoDiscover – abcmail.domain.com
    OA – exchmail.domain.com

    Desired 2016 namespaces

    OWA – owa.domain.com (needs to be unique as it’s sent through pre-auth before allowing in OWA)
    ECP – owa.domain.com
    EWS – mail.domain.com
    OAB – mail.domain.com
    AS – mail.domain.com
    AutoDiscover – mail.domain.com
    OA – exchmail.domain.com

    So, with differing namespaces like this (except keeping the same namespace for Outlook Anywhere), can the 2016 still proxy connections to the 2010 if all clients are pointed to 2016? Outlook Anywhere makes sense, since it will keep the same namespace and the DNS record would be changed to point to the 2016 side, but I’m not sure if having the other URLs as different presents an issue?

Leave a Reply

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