Our goal with this article is to articulate the various client 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 2010 in a multi-site architecture and show how the connectivity changes with the introduction of Exchange 2016.
As you can see from the above diagram, this environment contains three Active Directory sites:
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 ExternalURL property 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 three users.
The Autodiscover namespace, autodiscover.contoso.com, as well as, the internal SCP records resolve to the CAS2010 infrastructure located in Site1. Outlook clients and ActiveSync clients (on initial configuration) will submit Autodiscover requests to the CAS2010 infrastructure and retrieve configuration settings based on their mailbox’s location.
Note: The recommended practice is to configure the 2010 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 AutoDiscoverServiceInternalUri to a value that resolves to the load balanced VIP for the 2010 Client Access servers in your environment.
For more information on how Autodiscover requests are performed, see the whitepaper, Understanding the Exchange 2010 Autodiscover Service.
For internal Outlook clients using RPC/TCP connectivity whose mailboxes exist on Exchange 2010, they will connect to the Exchange 2010 RPC Client Access array endpoint (assuming one exists). Keep in mind the importance of configuring the RPC Client Access array endpoint correctly, as documented in Ambiguous URLs and their effect on Exchange 2010 to Exchange 2013 Migrations.
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.
For more information, see the article Upgrading Outlook Web App to Exchange 2010.
For more information, see the article Upgrading Exchange ActiveSync to Exchange 2010.
Exchange 2016 has now been deployed in Site1 following the guidance documented within the Exchange Deployment Assistant. As a result, Outlook Anywhere has been enabled on all Client Access servers within the infrastructure and the mail.contoso.com and autodiscover.contoso.com namespaces have been moved to resolve to Exchange 2016 Client Access component infrastructure.
To understand the client connectivity now that Exchange 2016 exists in the environment, let’s look at the four users.
The Autodiscover external namespace, autodiscover.contoso.com, as well as, the internal SCP records resolve to the MBX2016 infrastructure located in Site1. Outlook clients and ActiveSync clients (on initial configuration) will submit Autodiscover requests to the MBX2016 infrastructure and depending on the mailbox version, different behaviors occur:
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 2016 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 2016 mailboxes.
Important: When you introduce Exchange 2016 into a native Exchange 2010 environment, MAPI/HTTP will be enabled by default. Prior to moving any mailboxes to Exchange 2016, ensure you have configured your load balancer and/or firewall rules to allow traffic on /mapi/* via TCP443.
In Exchange 2010, the way Outlook Anywhere was implemented is that you had one namespace you could configure. In 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 Outlook Updates 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 for Outlook Anywhere, you can ensure that your internal clients can connect utilizing Kerberos authentication.
The default 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.
In environments that are native Exchange 2010, when you introduce Exchange 2016, MAPI/HTTP will be enabled by default. As long as the client supports the protocol, once a mailbox is moved to Exchange 2016, the client will reconfigure itself to use MAPI/HTTP. Upon next boot of the client, MAPI/HTTP will be utilized. It is very important to ensure that you have the correct firewall and load balancer settings in place prior to moving mailboxes, otherwise client connectivity will fail.
In order to support access for Outlook Anywhere clients whose mailboxes are on legacy versions of Exchange, you will need to make some changes to your environment which are documented in the steps within the Exchange Deployment Assistant. Specifically, you will need to enable Outlook Anywhere on your legacy Client Access servers and enable NTLM in addition to basic authentication for the IIS Authentication Method.
The Exchange 2016 Client Access component’s RPC proxy component sees 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 CAS or Exchange 2016 Mailbox server).
For Outlook on the web, the user experience will depend on the mailbox version and where the mailbox is located.
For Exchange ActiveSync clients, the user experience will depend on the mailbox version and where the mailbox is located. In addition, Exchange 2016 no longer supports the 451 redirect response – Exchange 2016 will always proxy ActiveSync requests (except in hybrid scenarios, where redirection is allowed).
Coexistence with Exchange Web Services is rather simple.
Like with Exchange Web Services, Autodiscover will provide the Offline Address Book URL.
It’s important to understand that when MBX2016 proxies to a legacy Exchange Client Access server, it constructs a URL based on the server FQDN, not a load balanced namespace or the InternalURL value. But how does MBX2016 choose which legacy Client Access server to proxy the connection?
When a MBX2016 starts up, it connects to Active Directory and enumerates a topology map to understand all the Client Access servers that exist within the environment. Every 50 seconds, MBX2016 will send a lightweight request to each protocol end point to all the Client Access servers in the topology map; these requests have a user agent string of HttpProxy.ClientAccessServer2010Ping. MBX2016 expects a response - a 200/300/400 response series indicates the target server is up for the protocol in question; a 502, 503, or 504 response indicates a failure. If a failure response occurs, MBX2016 immediately retries to determine if the error was a transient error. If this second attempt fails, MBX2016 marks the target CAS as down and excludes it from being a proxy target. At the next interval (50 seconds), MBX2016 will attempt to determine the health state of the down CAS to determine if it is available.
The IIS log on a legacy Client Access server will contain the ping events. For example:
2015-08-11 14:00:00 W3SVC1 DF-C14-02 192.168.1.76 HEAD /ecp - 443 - 192.168.1.42 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e16-1.coe.lab 302 0 0 277 170 0
2015-08-11 14:00:00 W3SVC1 DF-C14-02 192.168.1.76 HEAD /PowerShell - 443 - 192.168.1.27 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e16-1.coe.lab 401 0 0 309 177 15
2015-08-11 14:00:00 W3SVC1 DF-C14-02 192.168.1.76 HEAD /EWS - 443 - 192.168.1.134 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e16-1.coe.lab 401 0 0 245 170 0
2015-08-11 14:00:00 W3SVC1 DF-C14-02 192.168.1.76 GET /owa - 443 - 192.168.1.220 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e16-1.coe.lab 301 0 0 213 169 171
2015-08-11 14:00:01 W3SVC1 DF-C14-02 192.168.1.76 HEAD /Microsoft-Server-ActiveSync/default.eas - 443 - 192.168.1.29 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e16-1.coe.lab 401 2 5 293 194 31
2015-08-11 14:00:04 W3SVC1 DF-C14-02 192.168.1.76 HEAD /OAB - 443 - 10.166.18.213 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e16-1.coe.lab 401 2 5 261 170 171
If for some reason, you would like to ensure a particular CAS2010 is never considered a proxy endpoint (or want to remove it for maintenance activities), you can do so by executing the following cmdlet on Exchange 2010:
Set-ClientAccessServer <server> -IsOutofService $True
All this discussion about HTTP-based clients is great, but what about POP and IMAP clients? Like the HTTP-based client counterparts, IMAP and POP clients are also proxied from the Exchange 2016 Client Access component to a target server (whether that be an Exchange 2016 Mailbox server or a legacy Client Access server). However, there is one key difference, there is no health-checking on the target IMAP/POP services.
When the Exchange 2016 Client Access component receives a POP or IMAP request, it will authenticate the user and perform a service discovery.
If the target mailbox is E2010, MBX2016 will enumerate the POP or IMAP InternalConnectionSettings property value for each Exchange 2010 Client Access server within the mailbox’s site. Therefore, it is important to ensure that the InternalConnectionSettings maps to the server's FQDN, and not a load-balanced namespace.
MBX2016 will choose a server to proxy the request based on the incoming connection’s configuration. If the incoming connection is over an encrypted channel, MBX2016 will try to locate an SSL proxy target first, TLS next, plaintext lastly. If the incoming connection is over a plaintext channel, MBX2016 will try to locate a plaintext proxy target first, SSL next, TLS lastly.
Important: Exchange 2016 Mailbox servers do not validate that the POP or IMAP services are actually running on the target Client Access servers. It's important, therefore, to ensure that the services are running on every legacy Client Access server if you have POP or IMAP clients in your environment.
Hopefully this information dispels some of the myths around proxying and redirection logic for Exchange 2016 when coexisting with Exchange 2010. Please let us know if you have any questions.
Ross Smith IV
Principal Program Manager
Office 365 Customer Experience
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.