Client Connectivity in an Exchange 2013 Coexistence Environment
Published Mar 12 2014 06:00 AM 259K Views
Microsoft

This article is part 3 in a series that discusses namespace planning, load balancing principles, client connectivity, and certificate planning.

Over the last several months, we have routinely fielded questions on how various clients connect to the infrastructure once Exchange 2013 is deployed. Our goal with this article is to articulate the various connectivity scenarios you may encounter in your designs. To that end, this article will begin with a walk through of a deployment that consists of Exchange 2007 and Exchange 2010 in a multi-site architecture and show how the connectivity changes with the introduction of Exchange 2013.

Existing Environment

Pre-E15 Environment
Figure 1: Exchange 2007 & Exchange 2010 Multi-Site Architecture

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 also has a mix of Exchange 2007 and Exchange 2010 servers. There are three namespaces associated with this location – mail.contoso.com and autodiscover.contoso.com resolve to the CAS2010 infrastructure and legacy.contoso.com resolves to the CAS2007 infrastructure.
  • Regional Internet Facing AD Site (Site2) - This is an AD site that has exposure to the Internet. This site has Exchange 2010 servers. The primary namespace is mail-region.contoso.com and resolves to the CAS2010 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 Client Access servers whose virtual directories have the ExternalURL property populated. Similarly, the term, Non-Internet Facing AD Site, simply means any Active Directory site containing Client Access servers whose virtual directories do not have ExternalURL property populated.

To understand the client connectivity before we instantiate Exchange 2013 into the environment, let’s look at the four users.

Autodiscover

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. The Autodiscover service on Exchange 2010 can process Autodiscover requests for both Exchange 2007 and Exchange 2010 mailboxes.

Note: The recommended practice is to configure the 2007 and 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.

Internal Outlook Connectivity

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.

For internal Outlook clients using RPC/TCP connectivity whose mailboxes exist on Exchange 2007, they will connect directly to the Exchange 2007 Mailbox server instance hosting the mailbox.

Outlook Anywhere

  1. Red User will connect to mail.contoso.com as his RPC proxy endpoint. CAS2010 in Site1 will de-encapsulate the RPC data embedded within the HTTP packet and since the target mailbox database is located within the local site, will retrieve the necessary data from the local Exchange 2010 Mailbox server.
  2. Purple User will connect to mail.contoso.com as his RPC proxy endpoint. CAS2010 in Site1 will de-encapsulate the RPC data embedded within the HTTP packet, determine that the mailbox server is located on an Exchange 2007 server, and proxy the Outlook RPC data to the target Exchange 2007 Mailbox server.
  3. Blue User will connect to mail.contoso.com as his RPC proxy endpoint. CAS2010 in Site1 will de-encapsulate the RPC data embedded within the HTTP packet, determine that the mailbox server hosting the mailbox is located in another AD site (in this case Site3) and proxy the Outlook RPC data to the target Exchange 2010 Client Access server.
  4. Orange User will connect to mail-region.contoso.com as his RPC proxy endpoint. CAS2010 in Site2 will de-encapsulate the RPC data embedded within the HTTP packet and since the target mailbox database is located within the local site, will retrieve the necessary data from the local Exchange 2010 Mailbox server.
Note: In addition to the mail and directory connections, Outlook Anywhere clients also utilize Exchange Web Services and an Offline Address Book, which are provided via the Autodiscover response.

Outlook Web App

For more information, see the article Upgrading Outlook Web App to Exchange 2010.

  1. Red User will connect to mail.contoso.com as his namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, determine that the mailbox is located within the local AD site and retrieve the necessary data from the Exchange 2010 Mailbox server.
  2. Purple User will connect to mail.contoso.com as his namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site on an Exchange 2007 Mailbox server. CAS2010 will initiate a single sign-on silent redirect (assumes FBA is enabled on source and target) to legacy.contoso.com. CAS2007 will then process the request and retrieve the necessary data from the Exchange 2007 Mailbox server.
  3. Blue User will connect to mail.contoso.com as his namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site3, which does not contain any OWA ExternalURLs. CAS2010 in Site1 will proxy the request to CAS2010 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. CAS2010 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and retrieve the necessary data from the Exchange 2010 Mailbox server.
    2. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2010 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. CAS2010 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.
    3. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2010 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. CAS2010 in Site1 is configured to do a cross-site silent redirection, therefore, CAS2010 will initiate a single sign-on silent redirect (assumes FBA is enabled on source and target) to mail-region.contoso.com. CAS2010 in Site2 will then facilitate the request and retrieve the necessary data from the Exchange 2010 Mailbox server.

Exchange ActiveSync

For more information, see the article Upgrading Exchange ActiveSync to Exchange 2010.

  1. Red User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, determine that the mailbox is located within the local AD site and retrieve the necessary data from the Exchange 2010 Mailbox server.
  2. Purple User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site on an Exchange 2007 Mailbox server. CAS2010 proxies the request to CAS2007.
  3. Blue User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site3, which does not contain any EAS ExternalURLs. CAS2010 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.
  4. For the Orange User, there are two possible scenarios:
    1. Orange User will connect to mail-region.contoso.com as his namespace endpoint. CAS2010 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and retrieve the necessary data from the Exchange 2010 Mailbox server.
    2. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site2, which does contain an EAS ExternalURL. Assuming the device supports Autodiscover and is on a defined list of devices that supports the 451 redirect response, CAS2010 will issue a 451 response to the device, notifying the device it needs to use a new namespace, mail-region.contoso.com. CAS2010 in Site2 will then facilitate the request and retrieve the necessary data from the Exchange 2010 Mailbox server. If the device is not on the supported list, then CAS2010 in Site1 will proxy the request to CAS2010 in Site2

Exchange Web Services

  1. For the Red User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2010 in Site1 will service the request.
  2. For the Blue User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2010 will then proxy the request to an Exchange 2010 Client Access server located in Site3.
  3. For the Purple User, Autodiscover will provide back the legacy.contoso.com namespace for the Exchange Web Service URL. CAS2007 in Site1 will service the request.
  4. For the Orange User, Autodiscover will return the mail-region.contoso.com namespace for the Exchange Web Service URL. CAS2010 in Site2 will service the request.

Client Connectivity with Exchange 2013 in Site1

Exchange 2013 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 2013 Client Access server infrastructure.

E15 Site1
Figure 2: Exchange 2013 Coexistence with Exchange 2007 & Exchange 2010 in a Multi-Site Architecture

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

Autodiscover

The Autodiscover external namespace, autodiscover.contoso.com, as well as, the internal SCP records resolve to the CAS2013 infrastructure located in Site1. Outlook clients and ActiveSync clients (on initial configuration) 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 and Orange 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 2007, CAS2013 will proxy the request to an Exchange 2013 Mailbox server in the local site, which will generate the Autodiscover response. This means for Purple User, the MBX2013 server in Site1 will generate the response.
  3. For mailboxes that exist on Exchange 2013, 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.

Internal Outlook Connectivity

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.

For internal Outlook clients using RPC/TCP connectivity whose mailboxes exist on Exchange 2007, they will still connect directly to the Exchange 2007 Mailbox server instance hosting the mailbox.

When you have an Exchange 2013 mailbox you are using Outlook Anywhere, both within the corporate network and outside of the corporate network; RPC/TCP connectivity no longer exists for Exchange 2013 mailboxes.

In Exchange 2007/2010, the way Outlook Anywhere was implemented is that you had one namespace you could configure. In Exchange 2013, 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 Exchange 2013 System Requirements 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 utilize the same authentication value for both your internal and external Outlook Anywhere settings, or switch to use different names for Outlook Anywhere inside and out. Outlook gives priority to 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.

The default Exchange 2013 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.

External Outlook Connectivity

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 2013 Client Access server’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 (legacy CAS or Exchange 2013 Mailbox server).

  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 determine the mailbox version is 2007 and that the mailbox database hosting the user’s mailbox is located in the local site. CAS2013 will proxy the request to CAS2007 in Site1. CAS2007 will de-encapsulate the RPC from the HTTP packet and obtain the data from the Exchange 2007 Mailbox server.
  3. Blue 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 Site3. CAS2013 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.
  4. Orange User will continue to access his mailbox using the Exchange 2010 regional namespace, mail-region.contoso.com.

Outlook Web App

For Outlook Web App, the user experience will depend on the mailbox version and where the mailbox is located.

  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 namespace endpoint. CAS2013 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site on an Exchange 2007 Mailbox server. CAS2013 will initiate a single sign-on silent redirect (assumes FBA is enabled on source and target) to legacy.contoso.com. CAS2007 will then facilitate the request and retrieve the necessary data from the Exchange 2007 Mailbox server.
  3. Blue 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 Site3, which does not contain any OWA ExternalURLs. CAS2013 in Site1 will proxy the request to CAS2010 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. In this case, CAS2013 is not involved in any fashion.
    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 will initiate a single sign-on silent redirect (assumes FBA is enabled on source and target) to mail-region.contoso.com. CAS2010 in Site2 will then facilitate the request and retrieve the necessary data from the Exchange 2010 Mailbox server.
Note: Let’s assume that Site3 contains Exchange 2007 servers as well. In this scenario, CAS2013 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox version is 2007 and the mailbox is located in Site3. CAS2013 will issue a single sign-on silent redirect to legacy.contoso.com. CAS2007 in Site1 will authenticate the user and proxy the request to the Exchange 2007 Client Access server infrastructure in Site3.

Exchange ActiveSync

For Exchange ActiveSync clients, the user experience will depend on the mailbox version and where the mailbox is located. In addition, Exchange 2013 no longer supports the 451 redirect response – Exchange 2013 will always proxy ActiveSync requests.

  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 the namespace endpoint. CAS2013 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox version is 2007. CAS2013 will proxy the request to a local Exchange 2013 Mailbox server. The Exchange 2013 Mailbox server will send the request to an Exchange 2007 Client Access server that exists within the mailbox’s site (specifically, the InternalURL value of the Microsoft-Server-ActiveSync virtual directory on CAS2007), which will retrieve the data from the Exchange 2007 Mailbox server.
  3. Blue 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 is located within Site3. CAS2013 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.
  4. For the Orange User, there are two possible scenarios depending on how the device is configured:
    1. Orange User’s ActiveSync client is configured to connect to mail-region.contoso.com as the namespace endpoint. In this case, CAS2013 is not involved in any fashion. Note that any new device that is configured will automatically be configured to use mail-region.contoso.com.
    2. Orange User’s ActiveSync client is configured to 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 another AD site. CAS2013 will issue a cross-site proxy request to an Exchange 2010 Client Access server that resides in the same site as the mailbox.
Note: Let’s assume that Site3 contains Exchange 2007 servers as well. In this scenario, CAS2013 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox version is 2007 and the mailbox is located in Site3. CAS2013 will proxy the request to a local Exchange 2013 Mailbox server. The Exchange 2013 Mailbox server will send the request to an Exchange 2007 Client Access server that exists within the mailbox’s site, which will retrieve the data from the Exchange 2007 Mailbox server.

Exchange Web Services

Coexistence with Exchange Web Services is rather simple.

  1. For the Red User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013 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 legacy.contoso.com namespace for the Exchange Web Service URL.
  3. For the Blue User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013 will then proxy the request to an Exchange 2010 Client Access server located in Site3.
  4. For the Orange User, Autodiscover will return the mail-region.contoso.com namespace for the Exchange Web Service URL.
Note: Let’s assume that Site3 contains Exchange 2007 servers as well. In this scenario, the Autodiscover response will provide back the legacy.contoso.com namespace for the Exchange Service URL. CAS2007 in Site1 will proxy the request to an Exchange 2007 Client Access server that exists within the mailbox’s site, which will retrieve the data from the Exchange 2007 Mailbox server. This is why you cannot remove Exchange 2007 from the Internet-facing Active Directory site as long as Exchange 2007 exists in non-Internet facing Active Directory sites.

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 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 Purple User, Autodiscover will return the legacy.contoso.com namespace for the Offline Address Book URL.
  3. For the Blue User, Autodiscover will return the mail.contoso.com namespace for the Offline Address Book URL. CAS2013 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.
Note: Let’s assume that Site3 contains Exchange 2007 servers as well. In this scenario, the Autodiscover response will provide back the legacy.contoso.com namespace for the Offline Address Book URL. This is why you cannot remove Exchange 2007 from the Internet-facing Active Directory site as long as Exchange 2007 exists in non-Internet facing Active Directory sites.

How CAS2013 Picks a Target Legacy Exchange Server

It’s important to understand that when CAS2013 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 CAS2013 choose which legacy Client Access server to proxy the connection?

When a CAS2013 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, CAS2013 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 (yes, even Exchange 2007 servers are targeted with that user string). CAS2013 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, CAS2013 immediately retries to determine if the error was a transient error. If this second attempt fails, CAS2013 marks the target CAS as down and excludes it from being a proxy target. At the next interval (50 seconds), CAS2013 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:

2014-03-11 14:00:00 W3SVC1 DF-C14-02 157.54.7.76 HEAD /ecp - 443 - 192.168.1.42 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e14-1.coe.lab 302 0 0 277 170 0
2014-03-11 14:00:00 W3SVC1 DF-C14-02 157.54.7.76 HEAD /PowerShell - 443 - 192.168.1.27 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e14-1.coe.lab 401 0 0 309 177 15
2014-03-11 14:00:00 W3SVC1 DF-C14-02 157.54.7.76 HEAD /EWS - 443 - 192.168.1.134 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e14-1.coe.lab 401 0 0 245 170 0
2014-03-11 14:00:00 W3SVC1 DF-C14-02 157.54.7.76 GET /owa - 443 - 192.168.1.220 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e14-1.coe.lab 301 0 0 213 169 171
2014-03-11 14:00:01 W3SVC1 DF-C14-02 157.54.7.76 HEAD /Microsoft-Server-ActiveSync/default.eas - 443 - 192.168.1.29 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e14-1.coe.lab 401 2 5 293 194 31
2014-03-11 14:00:04 W3SVC1 DF-C14-02 157.54.7.76 HEAD /OAB - 443 - 10.166.18.213 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e14-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 (note that this feature does not exist on Exchange 2007):

Set-ClientAccessServer <server> -IsOutofService $True

IMAP & POP Coexistence

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 2013 Client Access server to a target server (whether that be an Exchange 2013 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 2013 Client Access server receives a POP or IMAP request, it will authenticate the user and perform a service discovery. 

  • If the target mailbox is E2010, CAS2013 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.
  • If the target mailbox is E2007, CAS2013 will enumerate each Exchange 2007 Client Access server’s server FQDN within the mailbox’s site.

CAS2013 will choose a server to proxy the request based on the incoming connection’s configuration. If the incoming connection is over an encrypted channel, CAS2013 will try to locate an SSL proxy target first, TLS next, plaintext lastly. If the incoming connection is over a plaintext channel, CAS2013 will try to locate a plaintext proxy target first, SSL next, TLS lastly.

Important: Exchange 2013 Client Access 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.

Conclusion

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

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience

Updates

  • 3/14/2014: Added section on IMAP/POP coexistence
  • 3/25/2014: Added detail that MBX2013 proxies to the CAS2007 MSAS InternalURL for 2007 EAS mailbox access
27 Comments
Not applicable
Nice article. Thanks for the info. Good to see that you guys are adding more content after SP1 was released.
Not applicable
Awesome explanation.... Just shared with Friends in Australia... :)
Not applicable
This mailbox database contains one or more mailboxes…
thanks
Not applicable
Great info Ross. Thank you for this post
Not applicable
Thanks Ross for your reply..
Not applicable
Very well explained proxy & redirection - Can't be better than this :)
Not applicable
Hi Ross, I am curious as to the nature of Outlook 2011 clients. I understand that they do not use RPC over HTTPS, but instead use EWS. As we have many MAC clients, we have found that EWS appPools crash and there is a lot of NetLogon issues. In fact, we have had to increase our MaxConcurrentAPI from the default of 10 (for server 2012) to 50. We are now looking to increase to 100 or 150. I am assuming that that outlook 2011 is using NTLM, which is causing the high netlogon issues. We also seem to be finding disconnects and retransmission issues for EWS. We have been on the phone with PSS many times and for long hours over the past two months sending logs and perfmon data back and forth and they cannot determine the cause. In this case, should there be any consideration for session affinity for MAC clients, or are they treated the same as RPC/HTTPS clients? Are there other considerations that we should make, such as BASIC authentication on the EWS sub-directory to reduce the NetLogon issues?
Not applicable
Hi Ross, Valuable article. It was more informative...

For Purple user in EAS - "CAS2013 will proxy the request to a local Exchange 2013 Mailbox server" - When you say is it mean CAS2013 will proxy the request to Mailbox 2013 of the same .

I hope the ans should be no since it's stateless and CAS 2013 not for site level by default as in CAS 2010...But this may not increase the bandwidth accross the MPLS link when we have multiple site having the mailbox 2013 and CAS 2013 on their respective site but performing cross communication. Considering all the CAS 2013 mapped to single VIP
Not applicable
@Exchange Queries - for the E2007 EAS request, CAS2013 will proxy to an E2013 Mailbox server in the same site as the CAS2013 server that received the request.

Ross
Not applicable
As well, there may be issues with Mac Clients in similar cases, perhaps you have some insight to these client access issues from Mac clients claims?

http://www.officeformachelp.com/2014/04/the-case-of-the-fractured-firewall-outlook-for-mac-causes-do...

Thanks again,

Shurley
Not applicable
This is an incredibly useful resource. Thanks, Ross!
Not applicable
Great article, thank you.
Not applicable
@the.ShawnMarten - The OWA timeout value is controlled by a self-expiring cookie generated by the CAS endpoint that is configured to use FBA. The default timeout value for CAS 2013 endpoints is 60 minutes (aka "private computer"). This timeout period applies irregardless of where the mailbox resides.

If you want to configure CAS 2013 to show the public/private computer settings see http://www.expta.com/2012/10/how-to-configure-public-and-private.html
Not applicable
What about the public / private option when proxying to CAS 2010 from 2013 since there is no public / private radio buttons on the OWA 2013 logon page? Do the proxied requests assume the public option with a 10 or 15 minute timeout?
Not applicable
Another Great Exchange On-Premises Article from Ross :)
Not applicable
As always very informative
especially this part which I was wondering about:
"But how does CAS2013 choose which legacy Client Access server to proxy the connection?"
also small question if you don't mind about this sentence regarding oab:
"1.For the Red User, Autodiscover will return the mail.contoso.com namespace for the Offline Address Book URL. CAS2013 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. "
I thought the "web distribution" option only decides which server the client is going to get back from autodiscovery(ex 2013) which server actually has the files in the mailbox server where its being generated on(where that arbitration mailbox is) no?

Thanks again for another informative post
Not applicable
Great article!
Not applicable
Are there no alternatives to "Set-ClientAccessServer -IsOutofService $True" for Exchange 2007 servers? I'm even considering writing firewall rules in the Windows fw to block specific 2007 CASes.
Not applicable
This is a quality article and a definite keeper. Thx for the attention to detail!
Not applicable
Exchange 2007 referenced below should be Exchange 2010. Section Exchange ActiveSync without Exchange 2013.

4.For the Orange User, there are two possible scenarios: a.Orange User will connect to mail-region.contoso.com as his namespace endpoint. CAS2010 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and retrieve the necessary data from the Exchange 2010 Mailbox server.
b.Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site2, which does contain an EAS ExternalURL. Assuming the device supports Autodiscover and is on a defined list of devices that supports the 451 redirect response, CAS2010 will issue a 451 response to the device, notifying the device it needs to use a new namespace, mail-region.contoso.com. CAS2010 in Site2 will then facilitate the request and retrieve the necessary data from the Exchange 2007 Mailbox server. If the device is not on the supported list, then CAS2010 in Site1 will proxy the request to CAS2010 in Site2
Not applicable
Hi Ross, thank you for the great write up, i have one question:
if i have four CAS2010 in site1 will CAS2013 make sure stickiness is maintained while selecting the destination CAS2010 for proxy requests of Red user? and will it maintain any sort of load distribution(so that one cas2010 is not over utilized)?

Thanks for your feedback.
Not applicable
I have two questions about how CAS2013 proxies connections to legacy CAS servers (2010 in our case).

1. The article explains that the 2013 CAS server pings the target legacy CAS server to determine if it is available. However, it is not clear what method is being used to select a target. Does it use logic similar to the Exchange Shell where it starts with the first CAS in the legacy CAS array and works its way down, or does it use some sort of load balancing algorithm?

2. How does session affinity come into play with proxied connections to legacy servers? I know CAS2013 is stateless, but CAS2010 is not. If we use a stateless load balancer configuration without session affinity, we know CAS2013 will work just fine with Exchange 2013 mailboxes. However, we are unsure of how CAS2013 handles the non-stateless CAS2010. Will using a stateless load balancer configuration cause problems with Exchange 2010 in a co-existence configuration?
Not applicable
Really useful article! Thanks!
Not applicable
Amazing Article. Any idea how public folder access would work when they are hosted on Exchange 2010 as well as Exchange 2013? I understand that Exchange 2010 user would not be able to access Exchange 2013 modern PF but would like to understand protocol flow from higher to lower versions
Not applicable
The question may be silly. But what's the meaning of "Proxy"?
I know "redirect" is: if A redirect to B, thus A won't do anything in the following session.
But proxy means: The A still need to accept the client request, then proxy it to the B, and the vise verse?
Not applicable
Great article thanks. One thing which would be nice is to have a 2013 Mailbox user in your explanation to also compare normal working mode all in one document.
Not applicable
This article cleared lot of doubts
Version history
Last update:
‎Jul 01 2019 04:18 PM
Updated by: