It’s time that we revisited the implementation of Autodiscover in current builds of Outlook, as there have been some changes that are worth noting.
The latest public article which discusses Outlook and Autodiscover is: Outlook 2016 implementation of Autodiscover.
You can take a look at the previous posts on the blog which feature the #Autodiscover tag. They show the "classic" Outlook 2007 implementation and how that slightly evolved in Outlook 2010 and then into Outlook 2013.
Some of the relevant articles:
Exchange & The Autodiscover Web Service
How To Read Exchange Autodiscover Response In Outlook
November 5, 2019, update for Outlook 2016 (KB4484139)
Outlook Autodiscover Quick Recap
Domain joined Outlook 2007 clients with line of sight to a DC would query for the SCP object. Only if that fails, would it them fall back to the DNS chase down used by non-domain joined clients.
The “classic” non-domain joined Outlook 2007 lookup process would be:
- https://<smtpdomain>/Autodiscover/Autodiscover.xml
- https://autodiscover.<smtpdomain>/Autodiscover/Autodiscover.xml
- http://autodiscover.<smtpdomain>/Autodiscover/Autodiscover.xml
- SRV record query for _autodiscover._tcp.<smtpdomain> (added via an update)
- Local XML (PreferXML can be set to prioritise the XML method)
Even the Outlook 2007 implementation changed, as the ability to use SRV records was not there at RTM, that was added via updates.
These posts outline how we went from the synchronous model first introduced with Outlook 2007, as shown in the diagram below, to the more asynchronous Outlook 2013 implementation where it would go and do the DNS chase down at the same time as looking up the SCP.
That led to some unfortunate issues if the domain controller had a HTTPS binding on TCP 443. Outlook 2013 would expect to see a certificate which had the domain namespace. If it did not, then one symptom would be certificate pop-up error. Other issues would be increased load on the domain’s website that was now having to deal with the additional requests for Autodiscover.xml files. That on it’s own would not be terrible; unless you have a series of web apps that then tried to process the request and got sent into a death spiral due to being unable to understand what they were meant to do with this strange Autodiscover thing. SharePoint was also impacted if that was responsible for the domain level website.
The Outlook client would generate an error such as this example, where the client asking a non-Exchange server for Autodiscover information.
So there is a history of Autodiscover changing and evolving over time, so what is updated with Outlook 2016?
Outlook 2016 Autodiscover Implementation
The ability to use Last Known Good (LKG) was added and backported to Outlook 2010 during its life cycle. Additionally the locally cached XML files can also be referenced. The AutoDetect feature from the Accompli mail app (now Outlook for iOS and Android) added a cloud check element.
With all of these changes we now end up an evolved Outlook 2016 model compared to the above.
- Check for restart
- Check if PreferLocalXML is set
- Check Last Known Good (LKG)
- Check Office 365 as Priority
- Check SCP
- Check root domain https://<smtpdomain>/Autodiscover/Autodiscover.xml
- Check Autodiscover domain https://autodiscover.<smtpdomain>/Autodiscover/Autodiscover.xml
- Local XML (can be forced to higher priority if PreferLocalXML is set)
- HTTP redirect http://autodiscover.<smtpdomain>/Autodiscover/Autodiscover.xml
- SRV record query for _autodiscover._tcp.<smtpdomain> (added via an update)
Failsafe check to Office 365
Note that EnableOffice365ConfigService policy is not used with current builds.
Some of these steps have a corresponding control that can be added to the registry either manually, via script or GPO.
Manually added values are placed here:
HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
Policy added values are located under the Software\Policy section of the registry:
Policy Key: HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\AutoDiscover
Note that if a control is added to both the policy and non-policy location, the policy setting takes precedence to resolve the conflict. The table below maps the sequence element to its corresponding control.
| Sequence | Registry Control |
| Check for restart | N/A |
| Check if PreferLocalXML is set
|
PreferLocalXML |
| Check Last Known Good (LKG) | ExcludeLastKnownGoodURL |
| Check Office 365 as Priority | ExcludeExplicitO365Endpoint |
| Check SCP | ExcludeScpLookup |
| Check root domain | ExcludeHttpsRootDomain |
| Check Autodiscover domain | ExcludeHttpsAutoDiscoverDomain |
| Local XML | N/A |
| HTTP Redirect | ExcludeHttpRedirect |
| SRV Record | ExcludeSrvRecord |
| Failsafe check to Office 365 | ExcludeExplicitO365Endpoint |
All of these controls disable/enable the particular element of the sequence apart from the PreferLocalXML. It prioritises the use of the local XML file rather than allowing or blocking it. There is no way to explicitly block local XML - this is done implicitly by not adding & configuring a local XML file.
Note that the November 2019 update for Outlook adds a PreferProvidedEmailInAutoDiscoverAuthPrompts registry key that enables Exchange administrators to specify whether users will be authenticated by using the configured account email or the user principal name (UPN) during AutoDiscover scenarios.
Registry key
Location: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
Value Type: DWORD
Value name: PreferProvidedEmailInAutoDiscoverAuthPrompts
Value data:
0: It's the default value. Outlook will use the UPN when it's available.
1: If the value is set to 1, Outlook will ignore the UPN and just use the provided account email.
Outlook Test Email AutoConfiguration
For reference, this is the Autodiscover test from an on-premises mailbox. This environment is NOT in a hybrid deployment, yet we see step #1 in the client as reaching out to Exchange Online.
The ExcludeExplicitO365Endpoint registry key is then set to block that behaviour. In the screenshot below, now we see that the client is able to retrieve the data via SCP and it is not contacting Exchange Online Autodiscover.
Update 10-1-2021: Also of note, is that when running Wireshark against Outlook 2021 do not see the parallel activity of SCP and DNS chase down.
Semi-Related Fun Stuff
With the Outlook client change to use AutoDetect, this created an issue in December 2019 / January 2020. The client expected to get a response from the tenant, however not every customer synchronises every user object. If your object was not synched that generated an error and the Outlook client generated a credential prompt. Oops.
There are two solutions to this
- Synchronise all user objects. Possibly easier said than done, depending where the customer is at on the Office 365 migration project.
- Set AutoDiscoverPartialSync in the tenant so that EXO knows that some objects are not synchronises and it will then defer to the client attempting to connect to on-premises.
See this article for more details.
The Outlook client advertises support for the MAPI/HTTP protocol by adding in a specific X header during the Autodiscover process. This is the X-MapiHttpCapability:1 header and is added automatically if MAPI/HTTP is enabled on the client. Issues with MAPI/HTTP have been resolved and the steps in this article should not be used as a standard troubleshooting step.
ActiveSync does not follow the Outlook client logic above since phone handsets are not domain joined and are unable to query SCP for example.
The Outlook Mobile client is also different in that the client behaviour differs if it doing Hybrid Modern Authentication (HMA) or Basic Authentication.
Cheers,
Rhoderick
