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.

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 ) and as you can see the relevant information is found and rendered onto the screen.

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.

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.

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