Busting The Set-AutodiscoverVirtualDirectory Myth


This is one of those long overdue posts (and yes there are certainly many more where it came from in my drafts folder) regarding some of the incorrect instructions about setting up Autodiscover which can be found on the Internet.

 

What am I wibbling about?  Well repeatedly over the last 5 years or so since Exchange 2007 shipped, multiple sources have claimed that one *MUST* configure the InternalURL and ExternalURL on all of your Autodiscover Virtual Directories.  It does not help that TechNet also says the same thing for Exchange 2007 & 2010.

 

Setting the InternalURL and ExternalURL on the Autodiscover Virtual Directory is not required, and has no effect on your configuration.  You can knock yourself out and change it if it makes you feel good, but it's pretty pointless!

 

Let’s look to see what Autodiscover is doing and why we do not have to set InternalURL or ExternalURL values on the Autodiscover Virtual Directory.

 

Autodiscover – Bring The Action!

 

The below screenshot shows a default Exchange 2010 installation.  Note that the InternalURL and ExternalURL parameters are not filled in by default for any of the Autodiscover virtual directories. 

 Exchange 2010 Default Autodiscover Virtual Directory URLs

 

So let us check that Autodiscover is actually working, and we will use the Test-OutlookWebServices cmdlet.  This example retrieves the information for the Administrator account (yes kids, don’t do this at home Smile ) and as you can see the relevant information is found and rendered onto the screen.

 

Testing Exchange 2010 Web Services Using Test-OutlookWebServices

 

So that is good, and the InternalURLs are not entered onto the Autodiscover Virtual Directories.  These values are obtained by directly querying Active Directory.  What about machines that cannot query AD directly to locate the Autodiscover endpoint?

 

Machines that are not domain joined or are outside of the corporate network cannot get to AD to issue any queries.  For such scenarios DNS name resolution to well known names is the only way to locate the Autodiscover endpoint.  As covered on more detail here the flow looks like this:

With this update installed the SRV query is added:

  • https://<smtpdomain>/Autodiscover/Autodiscover.xml

  • https://autodiscover.<smtpdomain>/Autodiscover/Autodiscover.xml

  • http://autodiscover.<smtpdomain>/Autodiscover/Autodiscover.xml

  • SRV record query for _autodiscover._tcp.<smtpdomain>

 

 

Sooooooooooooooooooooooooo

 

If Autodiscover is working, clients are getting the right data and we do not have the URLs filled in on the Autodiscover Virtual Directories then what gives?  How is this possible?

 

As mentioned in this post on Autodiscover, domain joined machines that are on the internal network locate the Autodiscover endpoint by directly querying AD.  They look for Service Connection Point (SCP) objects that have a well known GUID and AD returns a list to the Outlook client.  Outlook will get either an in-site list or out of site list of SCP endpoints.  It will not get both.  The SCP contains the URL that the internal domain joined Outlook client will connect to using HTTPS.  This and the AD Site coverage can be seen below.

 

 

Autodiscover Active Directory Site Coverage

 

EDIT 3-4-2013:  Please note that I am *NOT* advocating that the AutoDiscoverServiceInternalUri is left at the default.  It is here for explanation purposes, and to get into why it should be pointed to a load balancer and what issues that causes with certificates means I have to finish another one of those draft posts……

Please see the comments at the bottom of the post for full details.  Thanks for the feedback!!

 

We can tell how Outlook located the Autodiscover endpoint by running a Test E-Mail AutoConfiguration, and looking at the Log tab.  Note that the URL HTTP://Exch-1.tailspintoys.com/Autodiscover/Autodiscover.xml was located by SCP.

 

Test Email Configuration - Showing Autodiscover located via SCP

 

 

The SCP object can be found in AD at the following path:

 

CN=exchangeserver,CN=Autodiscover,CN=Protocols,CN=exchangeserver,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=org name,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com

 

 

On the SCP object there are a couple of values that interest us.  Firstly the attribute called serviceBindingInformation is where the  AutoDiscoverServiceInternalUri data is stored.  Secondly the attribute called keywords holds the AutodiscoverSitescope value.

 

 

For external domain joined machines, or those in a workgroup they both have no method to directly query AD for the SCP so they will only use DNS to locate the Autodiscover endpoint. Again this is mentioned in the previous Autodiscover post.

 

The Big Reveal

(well almost)

So as you can see everything is working fine without setting the InternalURL or ExternalURL on the Autodiscover Virtual Directory.  Now that we have established, and proved by testing, that it is not needed let’s answer the burning question about why it’s actually there.

The reason for this is pretty simple.  In the schema that defines Exchange virtual directory objects the InternalURL and ExternalURL are mandatory.  So every object of class Exchange Virtual directory must have these attributes.  Thus they are present on the Autodiscover virtual directory as they are inherited.  Exchange does not use them on the Autodiscover Virtual Directory, but they are heavily used to configure proxy and redirection for the other Virtual Directories – OWA for example.

If you look at the Exchange 2013 Set-AutodiscoverVirtualDirectory cmdlet documentation on TechNet, you will note that the InternalURL and ExternalURL attributes are not present.

 

Cheers,

Rhoderick

 

Comments (28)

  1. dstork@ogd.nl says:

    To add: if you use certificates without server names, you do have to change the autodiscover URL listed in the SCP. Otherwise Outlook clients will get a certificate name mismatch. You can change this specific autodiscover URL per server via Set-ClientAccessServer

    technet.microsoft.com/…/bb125157.aspx

  2. anonymouscommenter says:

    I agree with Dave. The current recommendation is not to include server FQDN on the certificates so setting the AutoDiscoverServiceInternalUri to the load balancer VIP name is recommended for all deployments.

  3. Hi folks,

    I totally agree that planning CAS namespaces is a critical and often overlooked aspect of an Exchange deployment.

    The SCP should indeed be pointed to a load balanced value when applicable.  The point of this post was not to dive into that, but to focus on the Autodiscover VDir aspect.   Hence I wanted to show that a vanilla configuration works, and did not want to muddy the water by changing it.  

    Which reminds me, I should go back and finish that certificate post I started a year ago…….

    Cheers,

    Rhoderick

  4. Oh – Nice T-Shirt BTW Andrew 🙂

    I had forgotten how bad the colour was!

  5. dstork@ogd.nl says:

    @Rhoderick: I understand completely that you wanted to focus on this aspect, certainly something that could be confusing for less experienced IT Pros. However, my concern was that this post would come across as if you should do nothing with the Autodiscover URL itself. But I certainly understand why you wanted to keep the certificate requirements apart, it's something that you could write books about 🙂

    Are you planning to write it also with Lync IM/UM, SharePoint and OWAS/WAC integration in mind?

  6. Hi Dave,

    I'll edit the above to highlight the best practice around changing the URL.  Its was something I was wrestling with — do I write this for the people who have load balancers, or try to include those with no LB devices?  The customers that you and I deal with will be the former, but I didn't want to exclude the latter.

    I'm engaged on the Exchange side primarily right now, but I should do some more Lync.

    I did one of the first (if not the first) OCS 2003 deployments in Canada and that taught me so many aspects of Certificates, and what NOT to do with them, that Exchange 2007 was easy 🙂

    Cheers,

    Rhoderick

  7. anonymouscommenter says:

    One more thing to note:  You said:

    If you look at the Exchange 2013 Set-AutodiscoverVirtualDirectory cmdlet you will note that the InternalURL and ExternalURL attributes are not present.

    But it actually does exist.  I'm running a pure Exchange 2013 environment and was able to put those parameters in.  Even though its not listed on the TechNet site.  Seems to be hidden.

  8. Hi Gus,

    That's correct – they are not listed on TechNet but you can still find them in the schema.

    Cheers,

    Rhoderick

  9. murraydwalker@gmail.com says:

    Hey,

    I've read in a few places that the AutodiscoverVirtualDirectory Urls are required for Lync client to integrate with EWS properly.

    Do you know if this is true?

    Thanks

  10. Well you prompted me to finish yet another draft post 🙂

    blogs.technet.com/…/exchange-autodiscover-amp-lync.aspx

    In short, no.  UC devices leverage DNS to locate Exchange AutoD.  Check out the whitepaper that is linked in the above post.

    Cheers,

    Rhoderick

  11. Rocco Daniele Ciaravolo says:

    Thank you,
    useful and clear.

    Rocco Daniele Ciaravolo

    Cle IT staff

  12. anonymouscommenter says:

    For an O365 migration all autodiscover records are set correctly. Non-domain joined machines work find inside and outside the corporate network. Domain joined PCs work correctly outside but not inside the corporate network. The AD settings are clearly
    over-riding the DNS entries.

  13. @ IDTTHISC

    Where are your AutoD records pointing to internally and externally?

    Why do you not think this is correct?

    Cheers.
    Rhoderick

  14. anonymouscommenter says:

    Rhoderick,

    I found this post when trying to solve the issue of using an external URL for my internal URL for the purpose of satisfying the certificate rules of no longer issuing .local domains on SSL. I followed the instructions at this link…https://supertekboy.com/2014/05/27/designing-a-simple-name-space-for-exchange-2010/
    I made the changes to my internal DNS as well. I have triple checked the settings. I’m still having an issue of my internal domain clients automatically using the server.domain.local url even if I do a manual set up and put in server.domain.com url it will
    switch back to the local on its own which in turn gives a certificate error. For the moment I have had to set the ssl to ignore so that my users can continue to use their mail without the annoyance. I ran the test command as you have shown and it’s successful
    up until it tests the .local and then it gives an error.

    Do you have any insight on how I can fix this. I am a super noob on exchange and this is 2010 btw.

    Thanks

  15. Hi Rob,

    Do an test outlook configuration from Outlook itself.

    Do you get the expected URLs for all services?

    Cheers,
    Rhoderick

  16. anonymouscommenter says:

    I seemingly do get the correct servers. When using the account on the domain it will show the local server and naturally give a certificate error. I can’t seem to get rid of the error without choosing ignore in IIS for autodiscover. Here are my results
    of the outllook test. It does list the local server should that part list the external url like the rest?

    Protocal: Exchange RPC
    Server: Server.domain.local
    Login Name: xxxxxx
    Availability Service URL: https://server.domain.com/EWS/Exchange.asmx
    OOF URL: https://server.domain.com/EWS/Exchange.asmx
    OAB URL: https://server.domain.com/OAB/cd493d6e-25ee-…….
    Unified Message Service URL: https://server.domain.com/EWS/UM2007Legacy.asmx
    Auth Package: Unspecified

    Protocol:Exchange HTTP
    Server: server.domain.com
    Login Name: xxxxxxx
    SSL: yes
    Mutual Authentication: yes
    Availability Service URL: https://server.domain.com/EWS/Exchange.asmx
    OOF URL: https://server.domain.com/EWS/Exchange.asmx
    OAB URL: https://server.domain.com/OAB/cd493d6e-25ee-…….
    Unified Message Service URL: https://server.domain.com/EWS/UM2007Legacy.asmx
    Auth Package: NTLM
    Certified Principal Name: msstd:server.domain.com

  17. In that – you expect to see server.domain.com — correct?

    one thing worth eliminating is Outlook using stale data. Open up the Account settings, highlight the Exchange profile and click repair.

    Does that change anything?

    Cheers,
    Rhoderick

  18. anonymouscommenter says:

    Yes that is what I expect to see. But since it still sees the server as .local then the certificate warning comes up. I did a repair and that gave the same results. Does everything look correct to you given that I am trying to use the external url as the
    internal and it is seeing the server at the .local address. Is this correct or should it be seeing it as the external? Im a bit confused. If there is a better way to do this then I am game for that. The server works for send receive except for the certificate
    error. When I ran the test – outlookwebservices I got errors when it got to all the internal url’s.

  19. anonymouscommenter says:

    hi Rob,
    to complete you setup with single name certificate you need also to create SRV record for AutoDiscover instead of A or C Name. this SRV record is must if you are using Single Name Certificate. do it for Internal And public DNS.
    good luck

  20. anonymouscommenter says:

    Hello there, I would like an advice about the issue I currently encounter. Outlook client have an accessibility problem, they cannot have free/busy information, OOO problem, etc… I’ve turned myself to the autodiscover and I’m currently trying to know
    what is going on.
    Outlook clients connects to an autodiscover URI who redirect them to the load-balancer, but they seems to receive wrong informations about one of our CAS. The wrong URL point to our CAS, and I think this is where the problem is.

    Except I cannot find where to remove this URI :

    – i’ve first had a look on the Set-ClientAccessArray and Set-ClientAccessServer, set the internalURI to the good parameters but that doesn’t change anything (like you explained). So I tried a Set-AutodiscoverVirtualDirectory and set the good URI too. but nothing
    has changed.

    – After seeking into the web, i’ve found some informations about AD Parameters, and SCP connectors. After looked at the SCP parameters for this server, they were correct too (good URI, good AD sites).

    I don’t know where to look now, and i’m a little confuse. If you can explain to me what do I’ve missed ?

    Thank you so much !

  21. What exactly have you checked ? List the PowerShell commands please.

    Cheers,
    Rhoderick

  22. anonymouscommenter says:

    Hello, first thank you to take the time to answer me,

    I’ve type those commands :
    – Set-ClientAccessServer -Identity SERVERNAME -AutoDiscoverInternalURI
    https://autodiscover.mydomain.com/Autodiscover/Autodiscover.xml
    – Set-AutodiscoverVirtualDirectory -Identity SERVERNAME -InternalURL
    https://autodiscover.mydomain.com/Autodiscover/Autodiscover.xml

    i verified the Site Scope too (The Autodiscover of those CAS is configured for 5 different sites).

    The Test-OutlookWebServices works fine for me, it says that the autodiscover works correctly (but we’ve a little latency, like 150ms)

    I’ve checked the serviceBindingInformation and it match the correct URL for the suspicious CAS
    I’ve check the Keywords value too and it’s correctly set for the used sites.

    In fact I’ve tried to check the configuration of another CAS of my DAG but I couldn’t see where I’ve failed the configuration for the incriminated server.

    I’ve check the DNS entries and it’s fine (it is working well for my Other CAS)

    I also tried to run an autoconfiguration test from a Vm who it pointing directly on my CAS and I’ve got this URL :

    https://autodiscover.SERVERNAME.com/Autodiscover/Autodiscover.xml.

  23. Autodiscover is most likely not the cause of the cert prompts.

    I don’t see you checking EWS, OAB, ECP, POP, IMAP, UM EAS…..

    Check all CAS servers for those URLs

    Cheers,
    Rhoderick

  24. anonymouscommenter says:

    Hello Rhoderick,

    Thank you for your help, there is some web services that aren’t well configurated, like EWS or ECP.

    I’ve just changed the bad values and I hope it’ll return to normal state soon.

    Thank you very much !

  25. Good stuff!

    Then send some flowers and an apology note to Autodiscover since it was innocent of all crimes 🙂

    Remove the URLS from the autodiscover virtualdirectory – set them to $NULL

    And if you don’t see the valid ones being returned do an IISRESET in a defined change window.

    Cheers,
    Rhoderick

  26. anonymouscommenter says:

    This is a post for reference purposes. The intent is to look at how Outlook will locate the correct Autodiscover

  27. anonymouscommenter says:

    This is link throw down for items that we discussed in a Exchange 2013 workshop which I delivered in