I was recently working on a project migrating a customer from MS Exchange 2010 to MS Exchange 2013. We were preparing to cutover the client access namespace to 2013 by updating DNS to point at the 2013 CAS.
However, during testing, I found that 2013 was not proxying connections to mailboxes on 2010. My outlook client would remain in a disconnected state.
My first thought was to check my Outlook Anywhere settings on both 2013 and 2013 CAS, in particular the authentication settings, as I knew these were critical to successful proxy from 2013 to 2010
All the settings looked good and matched up. As a test, I forced my internal Outlook client to use Outlook Anywhere by ticking this box
My outlook client connected successfully.
Then I found this technet article describing the scenario that in some situations proxy requests between Exchange 2013 & Exchange 2010 Sp3 with without any update rollups may not work
The Exchange 2010 servers in my case were on SP3 without any rollups. However, after installing the latest CU update for Exchange 2010 (CU8 at the time), I was still having the problem.
I finally resolved the problem after reading this technet blog explaining the effect of ambiguous URL’s in an Exchange 2010 environment when it comes to migrating to Exchange 2013.
My customer’s Exchange environment was indeed using the same FQDN for Outlook MAPI/RPC based traffic and HTTPS based traffic.
The solution was to force my internal outlook clients to always use Outlook Anywhere by configuring the following two settings from the Exchange Management Shell
- Set-OutlookProvider EXPR -OutlookProviderFlags:ServerExclusiveConnect
- Set-OutlookProvider EXCH -OutlookProviderFlags:ServerExclusiveConnect
These settings force all Outlook clients (via Autodiscover) to always use HTTP on the internal network. After applying these settings, you will notice in the Exchange Proxy settings on the Outlook clients that “On fast networks, connect using HTTP first, the connect using TCP/IP” is also ticked.
Problem solved! 🙂