Client Connectivity in an Exchange 2016 Coexistence Environment with Mixed Exchange Versions

[Ross Smith IV]

Our goal with this article is to articulate the various connectivity scenarios you may encounter in your Exchange 2016 designs. To that end, this article will begin with a walk through of a deployment that consists of Exchange 2013 and Exchange 2010 in a multi-site architecture and show how the connectivity changes with the introduction of Exchange 2016.

Existing Environment

As you can see from the above diagram, this environment contains three Active Directory sites:

• Internet Facing AD Site (Site1) - This is the main AD site in the environment and has exposure to the Internet. This site has Exchange 2013 and Exchange 2010 servers. There are two namespaces associated with this location – mail.contoso.com and autodiscover.contoso.com resolve to the CAS2013 infrastructure.
• Regional Internet Facing AD Site (Site2) - This is an AD site that has exposure to the Internet. This site has Exchange 2013 servers. The primary namespace is mail-region.contoso.com and resolves to the CAS2013 infrastructure located within this AD site.
• Non-Internet Facing AD Site (Site3) - This is an AD site that does not have exposure to the Internet. This site contains Exchange 2010 infrastructure.

Note: The term, Internet Facing AD Site, simply means any Active Directory site containing Exchange servers whose virtual directories have the ExternalURL property populated. Similarly, the term, Non-Internet Facing AD Site, simply means any Active Directory site containing Exchange servers whose virtual directories do not have ExternalURLproperty populated.

To understand the client connectivity before we instantiate Exchange 2016 into the environment, let’s look at how each protocol works for each of the four users.

Autodiscover

The Autodiscover external namespace, autodiscover.contoso.com, as well as, the internal SCP records for all Client Access servers resolve to the CAS2013 infrastructure located in Site1. Outlook clients, ActiveSync clients (on initial configuration), and EWS clients will submit Autodiscover requests to the CAS2013 infrastructure and depending on the mailbox version, different behaviors occur:

1. For mailboxes that exist on Exchange 2010, CAS2013 will proxy the request to an Exchange 2010 Client Access server that exists within the mailbox’s local site. This means that for Red User, this will be a local proxy to a CAS2010 in Site1. For Blue User, this will be a cross-site proxy to a CAS2010 located in the user’s respective site. CAS2010 will then generate the Autodiscover response.
2. For mailboxes that exist on Exchange 2013 (Purple User and Orange User), CAS2013 will proxy the request to the Exchange 2013 Mailbox server that is hosting the active copy of the user’s mailbox which will generate the Autodiscover response.

Note: The recommended practice is to configure the Client Access server’s AutoDiscoverServiceInternalUri value (which is the property value you use to set the SCP record) to point to autodiscover.contoso.com, assuming split-brain DNS is in place. If split-brain DNS is not configured, then set AutoDiscoverServiceInternalUrito a value that resolves to the internal load balanced VIP for the 2013 Client Access servers in your environment.

For more information on how Autodiscover requests are performed, see the whitepaper, Understanding the Exchange 2010 Autodiscover Service.

Outlook Anywhere & MAPI/HTTP Clients

For internal Outlook clients using RPC/TCP connectivity whose mailboxes exist on Exchange 2010, they will still connect to the Exchange 2010 RPC Client Access array endpoint.

When you have an Exchange 2013 or later mailbox you are using Outlook Anywhere (RPC/HTTP) or MAPI/HTTP, either within the corporate network or outside of the corporate network; RPC/TCP connectivity no longer exists for Exchange 2013 and later mailboxes.

In Exchange 2010, the way Outlook Anywhere was implemented is that you had one namespace you could configure. In Exchange 2013 (and Exchange 2016), you have both an internal host name and an external host name. Think of it as having two sets of Outlook Anywhere settings, one for when you are connected to the corporate domain, and another for when you are not. You will see this returned to the Outlook client in the Autodiscover response via what looks like a new provider, ExHTTP. However, ExHTTP isn’t an actual provider, it is a calculated set of values from the EXCH (internal Outlook Anywhere) and EXPR (External Outlook Anywhere) settings. To correctly use these settings, the Outlook client must be patched to the appropriate levels (see the OutlookUpdates for more information). Outlook will process the ExHTTP in order – internal first and external second.

Important: In the event that you are utilizing a split-brain DNS infrastructure, then you must use different names for Outlook Anywhere inside and out. Outlook will also prefer the internal settings over the external settings and since the same namespace is used for both, regardless of whether the client is internal or external, it will utilize only the internal authentication settings. By utilizing two namespaces, you can ensure that your internal clients can connect utilizing Kerberos authentication.

The default Exchange 2013 (and Exchange 2016) internal Outlook Anywhere settings don’t require HTTPS. By not requiring SSL, the client should be able to connect and not get a certificate pop-up for the mail and directory connections. However, you will still have to deploy a certificate that is trusted by the client machine for Exchange Web Services and OAB downloads.

For Outlook Anywhere clients, an Exchange 2013 Client Access server will authenticate the user, do a service discovery, and determine that the mailbox version and where the mailbox is located. The Client Access server will then proxy the request as follows.

For MAPI/HTTP clients, an Exchange 2013 Client Access server will authenticate the user, do a service discovery, and determine that the mailbox version is 2013 and where the mailbox is located. The Client Access server will then proxy the request to the Exchange 2013 Mailbox server that is hosting the active copy of the user’s mailbox which will act on the MAPI ROPs e mbedded in the HTTP protocol and obtain the data.

1. Red User will connect to mail.contoso.com as his RPC proxy endpoint. CAS2013 in Site1 will determine the mailbox version is 2010 and that the mailbox database hosting the user’s mailbox is located in the local site. CAS2013 will proxy the request to CAS2010 in Site1. CAS2010 will de-encapsulate the RPC from the HTTP packet and obtain the data from the Exchange 2010 Mailbox server.
2. Purple User will connect to mail.contoso.com as his RPC proxy endpoint. CAS2013 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1.
3. Blue User will connect to mail.contoso.com as his RPC proxy endpoint. CAS2013 in Site1 will perform a cross-site proxy request, proxying the HTTP session to a CAS2010 server in Site3. CAS2010 in Site3 will retrieve the necessary data from the Exchange 2010 Mailbox server.
4. Orange User will continue to access his mailbox using the Exchange 2013 regional namespace, mail-region.contoso.com. CAS2013 in Site2 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2.

Note: In addition to the mail and directory connections, Outlook Anywhere clients also utilize Exchange Web Services and an Offline Address Book, url’s for which are provided via the Autodiscover response.

 

Outlook Web App

For Outlook Web App clients, an Exchange 2013 Client Access server will authenticate the user, do a service discovery, determine the mailbox version, where the mailbox is located and either proxy or redirect depending on the OWA virtual directory configuration in the mailbox’s site.

1. Red User will connect to mail.contoso.com as his namespace endpoint. CAS2013 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox version is 2010 and is located within the local AD site. CAS2013 will proxy the request to an Exchange 2010 Client Access server which will retrieve the necessary data from the Exchange 2010 Mailbox server.
2. Purple User will connect to mail.contoso.com as his endpoint. CAS2013 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1.
3. Blue User will connect to mail.contoso.com as his endpoint. CAS2013 in Site1 will determine that the mailbox is located within Site3, which does not contain any OWA ExternalURLs. CAS2013 in Site1 will proxy the HTTP session to a CAS2010 server in Site3. CAS2010 in Site3 will retrieve the necessary data from the Exchange 2010 Mailbox server.
4. For the Orange User, there are three possible scenarios depending on what namespace the users enters and how the environment is configured:
   1. Orange User will connect to mail-region.contoso.com as his namespace endpoint. CAS2013 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2.
   2. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2013 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site2, which does contain an OWA ExternalURL. CAS2013 in Site1 is configured to do a cross-site silent redirection (default behavior), therefore, CAS2013 will initiate a single sign-on silent redirect (assumes FBA is enabled on source and target) to mail-region.contoso.com. CAS2013 in Site2 will then facilitate the request and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2.
   3. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2013 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site2, which does contain an OWA ExternalURL. CAS2013 in Site1 is not configured to do a cross-site silent redirection, therefore, the user is prompted to use the correct URL to access his mailbox data.

Exchange ActiveSync

For Exchange ActiveSync clients, an Exchange 2013 Client Access server will authenticate the user, do a service discovery, determine the mailbox version and where the mailbox is located. The Client Access server will then proxy the request as follows.

Note: Exchange 2013 and later no longer supports the 451 redirect response – Exchange 2013 and later will always proxy ActiveSync requests (except in hybrid scenarios, where redirection is allowed).

1. Red User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2013 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox version is 2010 and the mailbox is located within the local AD site. CAS2013 will proxy the request to an Exchange 2010 Client Access server which will retrieve the necessary data from the Exchange 2010 Mailbox server.
2. Purple User’s ActiveSync client will connect to mail.contoso.com as his endpoint. CAS2013 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1.
3. Blue User’s ActiveSync client will connect to mail.contoso.com as his endpoint. CAS2013 in Site1 will perform a cross-site proxy request, proxying the HTTP session to a CAS2010 server in Site3. CAS2010 in Site3 will retrieve the necessary data from the Exchange 2010 Mailbox server.
4. For the Orange User, there are two possible scenarios:
   1. Orange User will connect to mail-region.contoso.com as his namespace endpoint. CAS2013 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2.
   2. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2013 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site2. CAS2013 in Site1 performs a cross-site proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2.

Exchange Web Services

For Exchange Web Services clients, an Exchange 2013 Client Access server will authenticate the user, do a service discovery, determine the mailbox version and where the mailbox is located. The Client Access server will then proxy the request as follows.

1. For the Red User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS 2013 will then proxy the request to an Exchange 2010 Client Access server within the local site.
2. For the Purple User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1.
3. For the Blue User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013 in Site1 will perform a cross-site proxy request, proxying the HTTP session to a CAS2010 server in Site3. CAS2010 in Site3 will retrieve the necessary data from the Exchange 2010 Mailbox server.
4. For the Orange User, Autodiscover will return the mail-region.contoso.com namespace for the Exchange Web Service URL. CAS2013 in Site2 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2.

Client Connectivity with Exchange 2016 in Site1

Exchange 2016 has now been deployed in Site1 following the guidance documented within the Exchange Deployment Assistant. Both Exchange 2013 Client Access servers and Exchange 2016 Mailbox servers participate in the load balanced namespace mail.contoso.com and autodiscover.contoso.com.

To understand the client connectivity now that Exchange 2016 exists in the environment, let’s look at the five users.

Autodiscover

Either CAS2013 or MBX2016 in Site1 will authenticate the user, do a service discovery, determine the mailbox version, and where the mailbox is located. CAS2013 or MBX2016 will proxy the request as follows.

1. For mailboxes that exist on Exchange 2010, CAS2013/MBX2016 will proxy the request to an Exchange 2010 Client Access server that exists within the mailbox’s local site. This means that for Red User, this will be a local proxy to a CAS2010 in Site1. For Blue User, this will be a cross-site proxy to a CAS2010 located in the user’s respective site. CAS2010 will then generate the Autodiscover response.
2. For mailboxes that exist on Exchange 2013 (Purple User and Orange User), CAS2013/MBX2016 will proxy the request to the Exchange 2013 Mailbox server that is hosting the active copy of the user’s mailbox which will generate the Autodiscover response.
3. For mailboxes that exist on Exchange 2016 (Yellow User), CAS2013/MBX2016 will proxy the request to the Exchange 2016 Mailbox server that is hosting the active copy of the user’s mailbox which will generate the Autodiscover response.

Outlook Anywhere & MAPI/HTTP Connectivity

For Outlook Anywhere’s connections, the Exchange 2013 Client Access server or Exchange 2016 Mailbox server’s RPC proxy component will receive the incoming connections, authenticate and choose which server to route the request to (regardless of version), and proxy the HTTP session to the endpoint (Exchange 2010 Client Access server, Exchange 2013 Mailbox server or Exchange 2016 Mailbox server).

For MAPI/HTTP connections, the Exchange 2013 Client Access server or Exchange 2016 Mailbox server’s MAPI virtual directory proxy component receives the incoming connections, authenticates and chooses which server to route the request to (regardless of version), proxying the HTTP session to the endpoint (Exchange 2013 or Exchange 2016 Mailbox server).

1. Red User will connect to mail.contoso.com as his RPC proxy endpoint. CAS2013/MBX2016 in Site1 will determine the mailbox version is 2010 and that the mailbox database hosting the user’s mailbox is located in the local site. CAS2013/MBX2016 will proxy the request to CAS2010 in Site1. CAS2010 will de-encapsulate the RPC from the HTTP packet and obtain the data from the Exchange 2010 Mailbox server.
2. Purple User will connect to mail.contoso.com as his RPC proxy or MAPI/HTTP endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1.
3. Yellow User will connect to mail.contoso.com as his RPC proxy or MAPI/HTTP endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1.
4. Blue User will connect to mail.contoso.com as his RPC proxy endpoint. CAS2013/MBX2016 in Site1 will determine the mailbox version is 2010 and that the mailbox database hosting the user’s mailbox is located in Site3. CAS2013/MBX2016 will proxy the request to CAS2010 in Site3. CAS2010 will de-encapsulate the RPC from the HTTP packet and obtain the data from the Exchange 2010 Mailbox server.
5. Orange User will continue to access his mailbox using the Exchange 2013 regional namespace, mail-region.contoso.com. CAS2013 in Site2 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2.

Outlook on the web

For Outlook on the web clients, either an Exchange 2013 Client Access server or an Exchange 2016 Mailbox server will authenticate the user, do a service discovery, determine the mailbox version, and where the mailbox is located and either proxy or redirect depending on the OWA virtual directory configuration in the mailbox’s site.

1. Red User will connect to mail.contoso.com as his namespace endpoint. CAS2013/MBX2016 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox version is 2010 and is located within the local AD site. MBX2016 will proxy the request to an Exchange 2010 Client Access server which will retrieve the necessary data from the Exchange 2010 Mailbox server.
2. Purple User will connect to mail.contoso.com as his endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1.
3. Yellow User will connect to mail.contoso .com as his endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1.
4. Blue User will connect to mail.contoso.com as his endpoint. CAS2013/MBX2016 in Site1 will determine that the mailbox is located within Site3, which does not contain any OWA ExternalURLs. CAS2013/MBX2016 in Site1 will proxy the request to CAS2010 in Site3. CAS2010 in Site3 will retrieve the necessary data from the Exchange 2010 Mailbox server.
5. For the Orange User, there are three possible scenarios depending on what namespace the users enters and how the environment is configured:
   1. Orange User will connect to mail-region.contoso.com as his namespace endpoint. CAS2013 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2.
   2. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2013/MBX2016 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site2, which does contain an OWA ExternalURL. CAS2013/MBX2016 in Site1 is configured to do a cross-site silent redirection (default behavior), therefore, CAS2013/MBX2016 will initiate a single sign-on silent redirect (assumes FBA is enabled on source and target) to mail-region.contoso.com. CAS2013 in Site2 will then facilitate the request and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2.
   3. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2013/MBX2016 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site2, which does contain an OWA ExternalURL. CAS2013/MBX2016 in Site1 is not configured to do a cross-site silent redirection, therefore, the user is prompted to use the correct URL to access his mailbox data.

Exchange ActiveSync

The Exchange 2013 Client Access server or Exchange 2016 Mailbox server will receives the incoming connections, authenticates and chooses which server to route the request to (regardless of version), proxying the HTTP session to the endpoint (Exchange 2010 Client Access server, Exchange 2013 Mailbox server, or Exchange 2016 Mailbox server).

1. Red User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2013/MBX2016 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox version is 2010 and the mailbox is located within the local AD site. CAS2013/MBX2016 will proxy the request to an Exchange 2010 Client Access server which will retrieve the necessary data from the Exchange 2010 Mailbox server.
2. Purple User’s ActiveSync client will connect to mail.contoso.com as his endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1.
3. Yellow User’s ActiveSync client will connect to mail.contoso.com as his endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1.
4. Blue User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2013/MBX2016 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site3. CAS2013/MBX2016 in Site1 will issue a cross-site proxy the request to CAS2010 in Site3. CAS2010 in Site3 will retrieve the necessary data from the Exchange 2010 Mailbox server.
5. For the Orange User, there are two possible scenarios:
   1. Orange User will connect to mail-region.contoso.com as his namespace endpoint. CAS2013 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2.
   2. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2013/MBX2016 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site2. CAS2013/MBX2016 in Site1 performs a cross-site proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2.

Exchange Web Services

Like with other protocols, Exchange Web Services follows the same methodology. Either an Exchange 2013 Client Access server or Exchange 2016 Mailbox server will authenticate the user, do a service discovery, determine the mailbox version or where the mailbox is located. The server will then proxy the request to the Mailbox server that is hosting the active copy of the user’s mailbox which will obtain the data.

1. For the Red User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013/MBX2016 will then proxy the request to an Exchange 2010 Client Access server within the local site.
2. For the Purple User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1.
3. For the Yellow User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1.
4. For the Blue User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013/MBX2016 in Site1 will perform a cross-site proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site3.
5. For the Orange User, Autodiscover will return the mail-region.contoso.com namespace for the Exchange Web Service URL. CAS2013 in Site2 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2.

Offline Address Book

Like with Exchange Web Services, Autodiscover will provide the Offline Address Book URL.

1. For the Red User, Autodiscover will return the mail.contoso.com namespace for the Offline Address Book URL. CAS2013/MBX2016 will then proxy the request to any Client Access server within the local site that is a web distribution point for the Offline Address Book in question.
2. For the Yellow User and Purple User, Autodiscover will return the mail.contoso.com namespace for the Offline Address Book URL. CAS2013/MBX2016 will then proxy the request to the Exchange 2013/2016 Mailbox server that is hosting the active c opy of an OABGEN mailbox that contains a copy of OAB that is closest to the user’s mailbox.
3. For the Blue User, Autodiscover will return the mail.contoso.com namespace for the Offline Address Book URL. CAS2013/MBX2016 will then proxy the request to any Client Access server within the local site that is a web distribution point for the Offline Address Book in question.
4. For the Orange User, Autodiscover will return the mail-region.contoso.com namespace for the Offline Address Book URL.

Conclusion

Hopefully this information dispels some of the myths around proxying and redirection logic for Exchange 2016 when coexisting with both Exchange 2010 and Exchange 2013. Please let us know if you have any questions.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience