250 Hello

Random Musings on Exchange and Virtualization

Busting The Set-AutodiscoverVirtualDirectory Myth

Busting The Set-AutodiscoverVirtualDirectory Myth

  • Comments 27
  • Likes

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>





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.





Can You Help Us? - YES!

If you would like to have Microsoft Premier Field Engineering (PFE) visit your company and assist with the topic(s) presented in this blog post, then please contact your Microsoft Premier Technical Account Manager (TAM) for more information on scheduling and our varied offerings!

If you are not currently benefiting from Microsoft Premier support and you’d like more information about Premier, please email the appropriate contact below, and tell them you how you got introduced!



For all other areas please use the US contact point.

  • 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


  • 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.

  • Amen brother.

  • 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.......



  • Oh - Nice T-Shirt BTW Andrew :)

    I had forgotten how bad the colour was!

  • @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?

  • 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 :)



  • 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.

  • Hi Gus,

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



  • 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?


  • Well you prompted me to finish yet another draft post :)


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



  • Thank you,
    useful and clear.

    Rocco Daniele Ciaravolo

    Cle IT staff

  • 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.


    Where are your AutoD records pointing to internally and externally?

    Why do you not think this is correct?


  • 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.


Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
Post Comment Fixer