Ambigous URL’s prevent Exchange 2013 proxy to 2010

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! 🙂

11 thoughts on “Ambigous URL’s prevent Exchange 2013 proxy to 2010

  1. Hello Shane,

    The above scenario matches our requirement and when we have executed the command “Set-OutlookProvider EXPR -OutlookProviderFlags: ServerExclusiveConnect” and “Set-OutlookProvider EXCH -OutlookProviderFlags:ServerExclusiveConnect” on Exchange 2010 server,as said the client Outlook got the additional tick mark on fast network, however after enabling this option our client’s outlook 2010 SP2 started to prompt for password every time they opens the outlook.

    But when we untick the on fast network its works charm. i don’t know what i am missing out on this to get fixed.

    Could you please help me out?


      • Hello Shane,

        Thank you for your quick response.

        Please find the command output for your reference.

        [PS] C:\>get-outlookanywhere |fl servername,*authentication*

        ServerName : HUB01
        ClientAuthenticationMethod : Basic
        IISAuthenticationMethods : {Basic}

        ServerName : HUB02
        ClientAuthenticationMethod : Basic
        IISAuthenticationMethods : {Basic}

        ServerName : DRHUB01
        ClientAuthenticationMethod : Basic
        IISAuthenticationMethods : {Basic}


  2. Hello Shane,

    Let me try that and update you the status how it was worked.

    Thank you for your valuable time for replying me to the queries.


    • Hi Shane,

      We are in the process of setting the ClientAuthenticationMethod from BASIC for NTLM on Weekend as it is our production server and we are yet to introduce the Exchange 2013 server.

      If you could share me the steps which you have performed so that it will be useful.

      As I am planning to introduce the Exchange 2013 server on Weekend to test the email flow and client connectivity.

      Need your support on this.

      Thanks in Advance.


      • Hello, facing same situation with ambiguous url’s, we are using outlook 2007 clients. After you forced all your clients at the same time to use RPC over HTTP, how many client profiles were impacted and outlook could not connect after this change ? or did it work like a charm ? thanks for a reply

      • additionally in our environment exchange 2013 is already introduced but clients are still pointing to the CAS2010 server. eventually do you know of another way around here? thanks

        • hi Deb, in my scenario I identified the problem before we cut over the client access services to Exchange 2013. Therefore, no client profiles were impacted. I was able to test and apply the changes to all Outlook clients without any impact, and then proceed with the Exchange 2013 CAS cut over. And yes, it worked like a charm.

          • Thank you for the reply, in that case I am also just in time still need to switch over servers are instaled but no cut over to 2013 CAS for the moment. One additional question than if you do not mind:
            Did you change the RPC cas array after all or did you just force the client to RPC over HTTP? thanks

Leave a Reply

Your email address will not be published. Required fields are marked *