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:
- 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.
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
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.
Recently I installed Exchange Server 2019 CU10 and CU11
I always encounter this event in the eventlog corresponding with the KB article.
Unhandled Exception "Object reference not set to an instance of an object."
Stack trace: at Microsoft.Exchange.AutoDiscoverV2.FlightSettingRepository.GetHostNameFromVdir(ADObjectId serverSiteId, String protocol)
at Microsoft.Exchange.AutoDiscoverV2.AutoDiscoverV2.ExecuteOnPremEndFlow(AutoDiscoverV2Request request)
at Microsoft.Exchange.AutoDiscoverV2.AutoDiscoverV2.Execute(AutoDiscoverV2Request request, ITenantRepository tenantRepository)
at Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(Action tryDelegate, Func`2 filterDelegate, Action`1 catchDelegate)
The article states that you DO have to modify the Autodiscover External URL in order to resolve this event 1.
Could you please clarify or update this article is possible? And maybe why this is happening? 🙂 Not a lot of information can be found .. i just blindly follow the instructions accordingly but I want to understand 🙂
Those EventIDs have been present for many of the recent updates. It's not changing the behaviour, it just supresses the EventID generation.
My suspicion is that AutoD v2 changes were made causing the error to get logged, but that's just me thinking about this.
Further investigation has shown in my environment if you test using the Test-OutlookWebServices cmdlet it will always fail on the server you are testing against, however if you specify a different server in your org you should see it is successful. This leads me to believe the errors are generated when the request is made of the same server i.e. the lookup is made on server1 and server1 responds.
Will it hurt anything to enter the external URL?
It will not, and it will help with annoying Autodiscover EventID 1 entries in the application event log.
I have an issue with Autodiscover that Microsoft support is stumped on. Outlook will not connect a new profile Autodiscover throws a 503 error and we have rebuilt the virtual directory twice.... fiddled with every setting related to Autodiscover... been over the certs multiple times..... yet still they are stuck!
Rhoderick.... care to try this brain teaser on?
If that is a single user that has the issue, I'd compare their attributes Vs a working person using ADSIEdit.
Or is it everyone?