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)||
|Autodiscover||Proxy to Exchange 2013 MBX||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.
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:
- The user connects to autodiscover and hits CAS 2013
- CAS 2013 will proxy the request to CAS 2010. Normally one would expect it to use the InternalURL value.
- The InternalURL value resolves back to Exchange 2013
- 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.
Does the Exchange 2013 OWA Re-direct to Exchange 2007 require the user to authenticate again(Non-SSO)?
Yes, unfortunately it does. Sorry it took so lang to get back to you, I’ve been away on a training for a few weeks…
I have a exchange 2010 server and an exchange 2013 server, I guess I’m either confused, or just can’t figure it out. 2010 server URL is outlook.company.com 2013 server URL is owa2013.company.com when I browse to the 2013 exchange server https://owa2013.company.com/owa 2013 OWA login comes up, I can log into a 2013 mailbox fine, if I enter credentials for a 2010 mailbox instead of a 2013 mailbox I get an error, Am I wrong in thinking I should see the 2010 OWA when I do this?
the URLs on Exchange 2010, are they defined for the ExternalURL? If so, you should be redirected to Exchange 2010, rather than having Exchange 2013 Proxy your request.
What is the error message you’re seeing?
I have them blank now, Getting the generic Something is wrong screen, only when I logon as a users who has a 2010 mailbox
Before diving in deeper:
Could you be a bit more specific, maybe? What’s the exact error you’re seeing? Also, What do you see in the application log on the Exchange 2013 CAS server(s)?
OK, here’s what i can tell you:
Before Exchange 2013:
Exchange 2010 settings; All URLs pointed to outlook.company.com, DNS A Records pointed to 192.168.40.4 ip address of the exchange 2010 server
After Exchange 2013 was installed:
Exchange 2013 server ip 192.168.40.10
Exchange 2010 server ip 192.168.40.4
URLs in 2010 exchange:
Outlookanywhere : legacy.company.com host internal and external blank
OWA and ECP : Internal legacy.company.com External blank
URLs in 2013 Exchange:
Outlookanywhere : internal and external host outlook.company.com
OWA and ECP ; Internal outlook.company.com external outlook.company.com
DNS : outlook.company.com 192.168.40.10, legacy.company.com 192.168.40.4
I get a generic “something is wrong with the unhappy face, Sorry we can’t get that information right now” when a user with a 2010 mailbox logs into owa 2013 after the information is entered, 2013 mailbox users work and 2010 mailbox users work if you go to https://legacy.company.com/owa
Authentication is identical on the two servers
Internalauthenticationmethods : Basic and FBA
BasicAuthentication : true
formsAuthentication : true
Externalauthenticationmethods ; fba
My current configuration does not have access to internet so right now i’m only attaching locally to owa, I have a similar scenario with both internal and external that i’m troubleshooting in this test environment.
Nothing in event logs of either server indicating a problem.
I currently have 2013 and 2007 running together – but haven’t swapped over the names yet (legacy.domainname.com / outlookanywhere.domainname.com). I can use either without issue (2007 mailbox setup on client or 2013) when I have tested swapping them – everything runs aside from the connection via RPC / HTTP – OWA redirects nicely (using CU2 it’s seamless) – active sync works fine to phones etc – mail continues to come in / go out as expected. But when outlook runs it can’t connect saying ‘server unavailable’ – which of the external URL’s should be blank so that 2013 proxy’s these connections? Or have I got something else wrong?
I have one question which is around the proxy connection from Exch2013 to Exch2010. In the simplified approach Microsoft say that on your certificate you can have for example mail.contoso.com and auto discover.contoso.com. If a connection from Exch2013 is made to Exch2010 using its FQDN over https internally for the proxy request. How can it make a HTTPS connection to EXCH2010 as this name will not appear in the certificate that EXCH2010 has
I did speak to Scott Schnoll at TechEd who was going to try and refer me onto someone to explain as this didn’t quite fit his understanding but i had to leave. Michael VH was also there but didn’t get a chance to ask.
Any comments would be a great help
It’s too bad we didn’t get to speak at Barcelona!
IIRC, Exchange 2013 will “construct” a URL based on the Exchange 2010 server hostname. When doing that, it will ignore the SSL warning you would otherwise expect; thus effectively creating the “SSL Tunnel”.
Hope this helps!
Thanks for your reply Michael, this makes perfect sense and what i was hoping/expecting to be the answer. We did meet at Barcelona as I did attend your Exchange Hybrid session which i have to say was brilliant! I also asked you a question at the end of the session that which you answered great too. This question came up later and i didn’t know this article was written by you till now. #embarrassing
You may remember me….I quizzed you after the hybrid session about sizing your CAS environment for Hybrid if you wanted to move all users to cloud, as the statement of pointing all users to the latest CAS version meant ALL users would hit the new CAS servers.
Thanks again for your reply and session at TechEd
Now I do remember, yes! I’m glad you liked my session and the help! That’s what events like TechEd are for.
See you next time!
Hey Michael, too bad you never go to post an answer to the problem Darren Blanchard is/was (?) facing. I am having similar problems and I seem to be close in solving it, but just don’t know how.
I think i might have created an autodiscover loop and I don’t know how to fix it. Our setup
2x 2010CAS 192.168.2.10, 192.168.2.11
2x 2010MBX 192.168.2.20, 192.168.2.21
2x 2013CAS 192.168.2.110, 192.168.2.111
2x 2013MBX 192.168.2.120, 192.168.2.121
autodiscover.ourextdomain.com for internal clients point to 192.168.2.110
webmail.ourextdomain.com for internal clients point to 192.168.2.110
On all the CAS servers (meaning both 2010 and 2013) I have set the internal and external URL for every service (EWS, ECP, OWA, OAB, ActiveSync, Autodiscover, Outlook Any Where) to point to the same external domain: webmail.ourextdomain.com and autodiscover.ourextdomain.com.
If an internal Outlook 2010 user tries to use autodiscover to connect to his mbx on 2010mbx, he gets 400, 401 errors and is unable to successfully connect. An outlook 2010 user with a mbx on 2013mbx can connect successful.
If I change autodiscover.ourextdomain.com to point to 192.168.2.10, it is the other way around. The outlook 2010 user with 2010 mbx can connect, but the outlook 2010 user with mbx on 2013 cannot.
My guess is that the configuration for the internal and external URLs is not correct, but I am not sure how to fix this. Do you have any idea?
Sorry for the belated reply. For some reason the notifications for new comments were not visible…
Before I try and make any suggestions, could you tell me what the value is for the AutodiscoverServiceInternalUri for each of your Client Access Servers?
You can find that hostname by using the following cmdlet: Get-ClientAccessServer | fl Autod*
I’ve got a question about OWA proxying. I setup 2 Exchange 2013 servers next to our Exchange 2010 servers, The idea is that we will move from 2010 to 2013 when all the users are on 2013 the namespace will be pointed to 2013 and 2010 will be removed. For this to work i need to have users with a mailbox on 2013 servers to access their mailbox trough 2010 OWA. Now i get a page saying that i need to access OWA through the following url “https://servername.domain.lan/owa” and that i should bookmark it. How do i set this up in order to keep using the Exchange 2010 CAS servers and 2010 OWA to formward proxy the users to 2013 OWA?
Out of the box the other way around does work, logging in on the 2013 OWA page with a user that has it’s mailbox on 2010 does get proxied to the 2010 OWA.
Hey Edwin. This answer is long (over)due; but I’ll keep it short. You can’t do what you want to. Exchange 2010 CAS cannot proxy to Exchange 2013 CAS/MBX. Only down-level proxying works in this case. So all your users would have to connect through 2013 (even if their mailbox is on 2010).
We have 3 exchange servers 2010 in my environment. We recently installed 2 exchange server 2016.
We want to run 2016 in coexistence with 2010.
All the 3 exchange 2010 servers have different autodiscover names, xcg12010.domain.com, xcg22010.domain.com and xcg32010.domain.com
I am a bit confused about the autodiscover names for my xcg12016 and xcg22016 servers.
Your autodiscover namespace should be e.g. autodiscover.domain.com and not the name of a single server.
The namespace should preferably point to the latest version of Exchange (it really should). For example, you configure all servers to have an AutodiscoverServiceInternalURI with a value of https://autodiscover.domain.com/autodiscover/autodiscover.xml and then you make sure there is a DNS entry for that host name which points to your 2016 server (or the array of servers).
Also, make sure that you have a certificate that is valid for the autodiscover.domain.com namespace.
Hope this helps!
Thanks for your response Michael..
If we update the SCP of our current exchange servers to autodiscover.domain.com, what would be the impact on the users?
If a user’s outlook is using xcg12010.domain.com to connect to the exchange server, on updating the SCP , will the user have to manually update to the new SCP or restarting outlook should do it automatically?