Outlook 2016 Implementation of Autodiscover

Summary

Autodiscover is the feature that Outlook uses to obtain configuration information for servers to which it connects. In Outlook 2016 with Exchange servers, Autodiscover is considered the single point of truth for configuration information and must be configured and working correctly for Outlook to be fully functional. This article describes the implementation of Autodiscover in the current channel Click-to-Run release of Outlook 2016. For more information about the Office 365 client channel releases, see the following articles:



More Information

Autodiscover Timing

Autodiscover runs at the following times:
  1. During account creation.
  2. At set intervals to collect changes to URLs that provide Exchange Web Service features (OOF, Availability Service, and so on). If this process is successful, another try is made one hour later. If the attempt isn't successful, the next try is made 5 minutes later. Each attempt can potentially be staggered by as much as 25% because of the background task infrastructure used by all Microsoft Office applications.
  3. In response to certain connectivity failures. In various scenarios, when a connection attempt fails, Outlook starts an Autodiscover task to retrieve new settings in any attempt to correct the connection problem.
  4. When another application invokes it by using MAPI.

    For more information about MAPI, see the following MSDN article: Outlook MAPI Reference

Autodiscover Process

Every time that Outlook needs Autodiscover information, it uses a set of ordered steps to try to retrieve an XML payload that contains configuration settings. Many of these steps can be controlled by using Group Policy Objects (GPO), and the GPO value is included in the step description.

Step 1: Check for Restart scenarios
In some cases, such as when you add a second account while Outlook is running, the Autodiscover payload is cached to a local file to be used during a restart of the Outlook client. The very first Autodiscover step is to check the registry for some special “boot” information that tells Outlook that you are in the middle of one of these restart scenarios and to read the Autodiscover payload from the special local file. This is a rare case and typically not the cause of generic Autodiscover issues. For this step, if Outlook decides you are in this special boot scenario and the attempt to retrieve the Autodiscover XML data fails, the whole Autodiscover attempt fails. No additional steps are attempted.

There's no specific policy control for this step.


Step 2: Check for Local Data Preference
Outlook provides a GPO to let administrators deploy a specific Autodiscover XML file to be used for configuration. If the administrator has deployed this registry value and seeded an autodiscover.xml file, Outlook reads the Autodiscover payload from this file. This again is an uncommon case and typically not the cause of generic Autodiscover issues. If this step does not retrieve a payload, Outlook moves to step 3.

For more information about Autodiscover XML, see the following TechNet article: Plan to automatically configure user accounts in Outlook 2010
Note This article was created for Outlook 2010, however is still relevant for later versions of Outlook.

The policy control value for this step is as follows: PreferLocalXML
 
Step 3: Check for Last Known Good (LKG) Data
When Autodiscover retrieves an XML payload successfully through any step, the payload may be cached locally as the "last known good" configuration. The first commonly successfully method to get an Autodiscover payload is from this last known good file. The path of the last known good XML file comes from the Outlook profile. The LKG step is only used for discovering the primary mailbox configuration. If the Autodiscover lookup is for a non-primary mailbox (alternate, delegate, public folder, group mailbox, and so on), then the LKG step is automatically skipped. If this step does not retrieve a payload, Outlook moves to step 4.

The policy control value for this step is as follows: ExcludeLastKnownGoodURL


Step 4: Check for O365 as Priority
Outlook uses a set of heuristics to determine whether the user account provided comes from Office 365. If Outlook determines confidently that you are an O365 user, a try is made to retrieve the Autodiscover payload from the known O365 endpoints (typically https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml or https://autodiscover-s.partner.outlook.cn/autodiscover/autodiscover.xml). If this step does not retrieve a payload, Outlook moves to step 5.

The policy control value for this step is as follows: ExcludeExplicitO365Endpoint


Step 5: Check for SCP Data
If the computer is domain joined, Outlook performs an LDAP query to retrieve Service Connection Point data that returns a path of the Autodiscover XML. An attempt is then made to each URL that's returned by the SCP lookup to try to retrieve the Autodiscover payload. If this step does not retrieve a payload, Outlook moves to step 6.

For more information about SCP, see the following MSDN article: Publishing with Service Connection Points

The policy control value for this step is as follows: ExcludeScpLookup


Step 6: Check Root Domain
For this step, Outlook builds a URL from the domain name of the initial address in the format of https://<domain>/autodiscover/autodiscover.xml and tries to retrieve the payload from the resulting URL. Because many root domains aren't configured for Autodiscover, Outlook purposefully silences any certificate errors that occur during the attempted retrieval. If this step does not retrieve a payload, Outlook moves to step 7.

The policy control value for this step is as follows: ExcludeHttpsRootDomain


Step 7: Check Autodiscover Domain
For this step, Outlook builds a URL from the domain name of the initial address in the format of https://autodiscover.<domain>/autodiscover/autodiscover.xml and tries to retrieve the payload from the resulting URL. Because this is the primary URL typically for Autodiscover data, Outlook does not silence any certificate errors that occur during the attempted retrieval. If this step does not retrieve a payload, Outlook moves to step 8.

The policy control value for this step is as follows: ExcludeHttpsAutoDiscoverDomain


Step 8: Check for Local Data
In step 2, Outlook checked whether the administrator had deployed a policy to specifically check for the Autodiscover payload as a preference. If there's no policy in place, but the previous steps didn't retrieve a payload, Outlook now attempts to retrieve a payload from the local file even without the PreferLocalXML setting in place. If this step does not retrieve a payload, Outlook moves to step 9. 

There's no policy control for this step.


Step 9: Check for Http redirects
For this step, Outlook sends a request to the Autodiscover domain URL (http://autodiscover.<domain>/autodiscover/autodiscover.xml) and test for redirect responses. If an actual Autodiscover XML payload is returned and not a redirect, Outlook ignores the actual Autodiscover XML response because it was retrieved without security (http). If the response is a valid redirect URL, Outlook follows the redirect and tries to retrieve a payload XML from the new URL. Outlook will also perform certificate checks to prevent redirection to potentially harmful URLs in this step. If this step does not retrieve a payload, Outlook moves to step 10.

The policy control value for this step is as follows: ExcludeHttpRedirect


Step 10: Check for SRV Data
For this step, Outlook makes a DNS query for "_autodiscover._tcp.<domain name>" and loops through the results looking for the first record that uses https as its protocol. Outlook then tries to retrieve the payload from that URL. If this step does not retrieve a payload, Outlook moves to step 11.

The policy control value for this step is as follows: ExcludeSrvRecord


Step 11: Check for O365 as Failsafe
If all the previous steps didn't return a payload, Outlook uses a less restrictive set of heuristics to decide whether a final attempt to the O365 endpoints are potentially helpful. If outlook decides that an attempt is worthwhile, it tries the known O365 Autodiscover endpoints in case the account is an O365 account. This attempt uses the same target URLs as step 4, and differs only in the fact that it's tried as a last resort and not earlier in the Autodiscover process.

The policy control value for this step is as follows: ExcludeExplicitO365Endpoint



Redirect Handling

Step 9 in the Autodiscover Process section is an explicit step to handle nonsecure redirect data. In any of the other secure steps, for any attempt to retrieve the Autodiscover XML payload, one possible response from the endpoint is a redirection response. This response tells Outlook to redirect to a new, different URL to try to retrieve the payload. Additionally, the redirection data may contain a new, different email address to use as the target address for the Autodiscover attempt. Outlook considers three separate responses to be “redirect responses”:
  1. An HTTP status code (301, 302) with a new URL
  2. An HTTP status code of 200, but with a payload XML that tells Outlook to redirect to a different URL
  3. An HTTP status code of 200, but with a payload XML that tells Outlook to use a different smtp address as the target address.

In cases 1 and 2, Outlook will try to retrieve the autodiscover XML from the new URL, provided the protocol is https. Nonsecure (http) URLs aren't attempted. Additionally, even if the protocol in the new URL is https, Outlook will check certificate information to provide an additional measure of security.

For case 3, Outlook starts the whole autodiscover process from the beginning.  If all steps (1-11) are tried without any success using the new email address, then Outlook returns to the original email address, moves to step 5, and continues the attempt to retrieve an XML payload with the original address.


Exceptions

The steps in the Autodiscover Process section are the general rules for how Outlook tries to obtain the autodiscover payload. There are various optimizations and exceptional attempts that may change the process slightly. For example, when doing a new account creation, Outlook internally skips the step 3 (check for Last Known Good (LKG) data), because it cannot yet have a last known good entry.  Similarly, if an attempt was triggered because of an error by using the current configuration information, then Outlook purposefully wants to autodiscover again and not use the LKG information because presumably the last known good information resulted in a failure.


Policy Control

The policy values that are defined the Autodiscover Process section can be either policy based registry values or non-policy based values.  When they are deployed through GPO, or manual configuration of the policies key, the settings take precedence over the non-policy key.

Non-Policy Key: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover

Policy Key: HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\AutoDiscover

Each value is of type DWORD.

The PreferLocalXML differs from the other control values as a setting of 1 sets Outlook to turn on that step in the process. For the remaining values, a setting of 1 tells outlook to turn off or skip the associated step. For example, setting the value ExcludeHttpsRootDomain to 1 sets Outlook not to perform step 6 in the process.


Additional Registry Controls

Outlook provides several additional registry based configuration options that might affect the Autodiscover process:

HTTP Timeout Settings

Key: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
Value: Timeout
Default: 25 Seconds
Minimum: 10 Seconds
Maximum: 120 Seconds

Information: Specified timeouts are used as WinHttpSetTimeouts settings. The data specified is passed to all four parameters of the WinHttpSetTimeouts API. This potentially allows a http request that cannot be reached to time out faster, which will improve overall performance. The settings could also allow http request that take longer than the default of 25 seconds to succeed by increasing the time-out to something larger than 25 seconds.


Mapi/Http Protocol Control

Key: HKEY_CURRENT_USER\Software\Microsoft\Exchange
Value: MapiHttpDisabled
Default: 0
Data: 1 -Protocol is Disabled, 0 – Protocol is Enabled

Information: This value isn't located under the Autodiscover key. This is a general setting that controls whether Outlook can try to connect to Exchange by using the Mapi/Http protocol stack. The default in Outlook 2016 isn't to have this protocol disabled. This lets the Autodiscover process add a special header (X-MapiHttpCapability:1) to the discovery process so that the Mapi/Http protocol settings can be evaluated and processed.



Legacy Authentication Negotiation Control

Key: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\RPC
Value: AllowNegoCapabilityHeader
Default: 0
Data: 1 – Headers are added, 0 – Headers aren't added

Information: Note this value isn't under the Autodiscover key. This setting controls whether an authentication negotiation header is added to http requests. The contents of the header depend on the authentication capabilities of the client computer. An example header might be: “X-Nego-Capability: Negotiate, pku2u, Kerberos, NTLM, MSOIDSSP”. This registry value and the header that it adds are rarely used in any modern authentication stack and very unlikely to affect the tAodiscover process in either a negative or positive way.


Certificate Error Handling

Key: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
Value: ShowCertErrors
Default: 0
Data: 1 = Show certificate warnings/errors; 0 = Don't show certificate warnings

Information: This value controls how Outlook handles certificate errors and warnings that are received when it performs http tasks. Outlook may override this setting in some cases (step 6 in the Autodiscover Process section), but for the general case, if this setting is enabled, Outlook will prompt with a security dialog that displays the certificate error or warning and allow the user to OK or Cancel the Http request. There are three specific certificate errors that the user can decide to ignore and have Outlook retry the http request:
  • WINHTTP_CALLBACK_STATUS_FLAG_CERT_DATE_INVALID – There's a problem with the date in the certificate properties
  • WINHTTP_CALLBACK_STATUS_FLAG_CERT_CN_INVALID – There's a problem with the common name in the certificate properties
  • WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA – There's a problem with the certificate authority in the certificate properties

    More information on these three certificate error states can be found at https://msdn.microsoft.com/en-us/library/windows/desktop/aa383917(v=vs.85).aspx 
 

Proxy Authentication Handling

Key: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\HTTP\
Value: AllowOutlookHttpProxyAuthentication
Default: 0
Data: 1 = Allow Outlook to handle authentication challenges from proxy servers; 0 = silently fail authentication challenges from proxy servers

Information: This registry value allows the relaxation of a security configuration and is covered in detail in the following article in the Microsoft Knowledge Base:

3115474  MS16-099: Description of the security update for Outlook 2010: August 9, 2016



Autodiscover for Other Protocols

Autodiscover as a feature is also used by Outlook to discover and configure Exchange ActiveSync (EAS) accounts. The EAS Autodiscover process and decision making is separate from the steps that were described in this article. For example, the EAS implementation does not implement the O365 endpoint logic and does not have a step that checks for SCP locations. This article is scoped to describe the detailed steps that Outlook uses for Autodiscover attempts to obtain the MAPI based protocols from Exchange.



More Information

Legacy information about autodiscover can be found in the following article in the Microsoft Knowledge Base:

2212902  Unexpected Autodiscover behavior when you have registry settings under the \Autodiscover key


For more information about Autodiscover, see the following articles:



Properties

Article ID: 3211279 - Last Review: 2017 urt. 10 - Revision: 2

Oharrak