Many, many moons ago, we looked at the functionality of Autodiscover for on-premises Exchange. At the time of writing that post the focus was on Exchange 2010 and Outlook 2010. Things change...
In this post we can look at the modifications introduced in Outlook 2013, and we will also need to review the changes in Outlook 2016 which will be in a separate post.
LastKnownGood
The documented flows for the Autodiscover implementation in Outlook 2013 were very similar to Outlook 2010. The one notable introduction was LastKnownGood. The concept being that instead of having to do all the leg work to chase down the Autodiscover endpoint, it we knew one that worked then we could simply re-use that.
Interestingly enough there is a recent KB where this can cause an issue:
After migration to Office 365, Outlook doesn't connect or web services don't work
Root Domain Certificate prompts
Initially I started writing this post back in spring 2015. Back then I was seeing customers with issues where Outlook 2013 would throw a certificate error when the root domain had an invalid certificate. Yes – other work came along and I never finished that draft and published it. In case you are wondering there are currently 132 draft posts. I wanted to review the Outlook 2013 behaviour before moving onto Outlook 2016 for the sake of completeness.
Test Lab Configuration
The below images are taken from a test lab running Exchange 2013. Exchange 2013 CU18 is installed.
There is also an Outlook 2013 client running on Windows 7, so this is typical of a lot of enterprises.
Test Lab CAS Namespaces
In order to allow us to see what endpoint the client tries to access, the namespaces were deliberately set to allow them to be identified.
There is:
An A record in DNS for autodisover.wingtiptoys.ca
SCP is set to mail.wingtiptoys.ca
By separating the names used for SCP and the DNS chase down process, we can easily see which one is used.
These namespaces resolve to the Exchange 2013 CAS server as expected. Nothing fancy.
Creating Outlook 2013 Profile
The below shows the user experience when creating the first profile on the machine.
Note that the email address and name is automatically added as the Outlook client can connect to AD.
At this point the Autodiscover process fires, and the client searches for the XML configuration.
The client was able to connect to the Autodiscover endpoint and is now configured.
Running Test Autodiscover In Outlook
Now that we have the profile configured, we can run the Test Email AutoConfiguration tool to verify what we see in the UI and what traffic is actually sent by the client.
As we mentioned in the original article, the lookup process appears to be the same as before. It is looks like it is synchronous and only the SCP is used.
Is that really the case? Well, the packets don't lie so let us have a look at the network and inspect the flow.
The below packet capture was done in Network monitor at the same time. A filter was added to show only DNS traffic to make it more readable.
Note the highlighted queries. Outlook is trying to resolve the domain name along with the SCP. Now the client is doing both the DNS chase down and SCP look at the same time.
The first screenshot shows the domain name being resolved, the second show the Autodiscover endpoint.
What is interesting is that the client is attempting the DNS chase down at the same time it is doing the SCP.
What could possibly go wrong?
Que the next section....
Adding HTTPS To Domain
In most cases this did not cause an issue. Remember though that the DNS lookup process attempts to contact the domain.com first before attempting to contact autodiscover.domain.com (don't start me on why it is that way).
You can see that in the first network trace as there is a query for WingtipToys.ca - that is the domain in this example.
If nothing is listening on TCP 443 on that particular server, then there is no issue. But what happens if there actually is a HTTPS binding?
To mimic this, the below was added in IIS on the domain controller. This means that when we ping the domain name, the IP of the DC is returned and since there is now a HTTPS binding Outlook will try and do the SSL handshake.
This DC happens to also be a Certification Authourity, though in reality this could be an external DNS provider that has a secured web interface. It does not really matter too much, the fact is there something listening on TCP 443.
When we repeat the test in Outlook, the user receives the below certificate error. This is due to the fact that the certificate does not have the domain added as a Subject Alternative Name or the subject is the domain name.
There is a certificate mismatch. Not a good thing to tell users to just click and accept these errors. Nothing good will ever come of that...
Resolution
This can be remediated by using a GPO to disable the domain lookup.
Interesting, there have been other Autodiscover issues in this area - Outlook 2016 and Outlook 2013 hang when a user tries to create a profile. With this, the issue actually went the other way and Outlook went into a stall for several minutes if there was NOT an HTTPS listener on the domain. Go figure.
Bootnote
There are a couple of things to note. There are differences in the logging mechanism in Outlook 2010 and 2013/2016. While Outlook 2010 SP2 introduced ETL logging, some information was still logged to a text file. Outlook 2013 placed more emphasis on ETL files as the repository for logging. The challenge being that Microsoft support must be contacted to review the ETL file.
The differences between Outlook 2010 and 2013/2016 are discussed in the below KB which also details how to edit the registry to enable global logging and Advanced ETL logging in Outlook 2013/2016.
How to enable global and advanced logging for Microsoft Outlook
Cheers,
Rhoderick
