Please note that this article has been updated on 10/10/2012 with some corrections and additional information. Some paragraphs were rephrased to be more clear and I’ve corrected some information that was wrong (e.g. proxy behaviour for Exchange 2007).

Many thanks to Greg Taylor for helping and pointing it out!

In an earlier post, I briefly explained the proxy & redirection behavior of an Exchange 2013 Client Access Server (which I’m going to call CAS 2013 from now on).

This article will elaborate a bit more on the subject as we’re also including Exchange 2007 into the equation now.

Proxy or Redirection?

One of the more frequently asked questions is when Exchange 2013 will actually decide to proxy or redirect a request to a legacy version (being either Exchange 2007 or Exchange 2010).
The answer to that question is relatively simple, though there are some caveats to look out for. Basically, Exchange 2013 will always try to proxy a request to other CAS2013 servers or legacy versions, especially for Exchange 2010. The only exceptions are:

  • Exchange 2007 OWA
  • Exchange 2010 OWA or ECP /w ExternalURL set

If we put together this information, we could come up with something like this:

Workload Exchange 2007 Exchange 2010
OWA Redirect   to ExternalURL (legacy namespace)
  1. Proxy
  2. Redirect if ExternalURL is set
  1. Proxy
  2. Redirect if ExternalURL is set
POP/IMAP Proxy Proxy
ActiveSync Proxy Proxy
Autodiscover Proxy to Exchange 2013 MBX Proxy
Outlook   Anywhere Proxy Proxy
Exchange Web Services (EWS) Autodiscover Req. (to retrieve the EWS 2007 URL and hand that to the user) Proxy

Because Exchange 2013 cannot proxy some workloads over to Exchange 2007, a separate (legacy) namespace will be required during coexistence. This namespace will serve as endpoint where Exchange 2013 will redirect the user to. It’s thus also important that this endpoint is externally available (if you wish to make the services externally available as well).

Also, if this legacy namespace (e.g.: legacy.contoso.com) is different from the one you currently are using (e.g. owa2007.contoso.com), you’ll have to reconfigure the ExternalURL values for these workloads to match the legacy namespace.

Proxy URL

One would expect that Exchange 2013 uses the InternalURL value to decide where to proxy a request to. However, this could potentially cause routing loops as the InternalURL for a given Exchange 2010 workload might point to Exchange 2013. Let’s use Autodiscover as an example: using the InternalURL value (or AutodiscoverServiceInternalUri), you’d end up in the following situation:

  1. The user connects to autodiscover and hits CAS 2013
  2. CAS 2013 will proxy the request to CAS 2010. Normally one would expect it to use the InternalURL value.
  3. The InternalURL value resolves back to Exchange 2013
  4. Hooray! You’ve got yourself a loop…

Obviously, this is something you wouldn’t want. Therefore, to avoid this from happening, Exchange 2013 will construct an URL based on CAS 2010’s server FQDN.

For example, in case of Autodiscover, this would be: https://CAS2010.contoso.com/autodiscover/autodiscover.xml

In fact, Exchange 2013 will do this for all protocols, not just Autodiscover! For more details when CAS 2013 tries to proxy, have a look at the table above.

Note   Please note that this process is completely transparent to the end user. It’s only used in Exchange 2013’s internals.


A redirection between AD-sites for Exchange 2010 will be silent but will NOT be SSO (within the same AD site it would just proxy). This means that users will have to authenticate twice. It seems that the code for SSO isn’t ready yet. It’s to be expected that this functionality will make its way back into Exchange 2013 via an Update-Rollup; post-RTM that is.

From an end-user point-of-view I think a silent redirect without SSO is rather confusing: the user gets asked for credentials after which he’s redirected to another web page where he needs to log in again without getting additional information on what just happened. In my opinion, you should avoid ending up in this situation and make Exchange 2013 proxy requests over to Exchange 2010. Because HTTPS is used, there is minimal or no overhead and it performs rather well, even on low-bandwidth links.


Exchange 2013 is designed to better work together with previous Exchange versions. This should help transitioning to Exchange 2013 become more easy. However, a legacy namespace is still required for coexistence with Exchange 2007, so don’t forget to add it to your certificate for 2007!

In case you have any questions, leave a reply or send me an email!




All the information in this blog post is subject to change as Exchange Server 2013 is still under construction. Although it’s not very likely that big changes will occur between now an RTM, it still might.