Outlook 2016 Implementation of Autodiscover

Applies to: Outlook 2016Outlook for Office 365Outlook 2019

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 Microsoft websites:

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 efficiency

Use User Principal Name (UPN) to expedite the Autodiscover process.
 
On a domain joined computer, Outlook needs to know the UPN for a user in order to initiate the Autodiscover process. The UPN may have been used to logon to Windows, in which case Outlook has direct access to the UPN from the logon credentials. But if a user use domain\username to log in Windows, Outlook only has the same credential for the user. In order to get the UPN, Outlook must first look the user up in the directory. Outlook will request that this lookup should chase referrals. In complex environments, this may result in a large number of DCs being contacted before a result is found. Once Outlook has discovered the UPN for the user, the value will be cached in the profile and the lookup should not happen again for this user.
 

To avoid this scenario, the user can log on with a UPN instead of domain\username.

ITAR Considerations

Microsoft Office 365 provides features that can support customers with ITAR obligations. In the context of the Autodiscover feature in Outlook, this feature set includes policy settings and behavior that ensures the service endpoints used for Autodiscover adhere to sovereign cloud requirements. Specifically, in the Office 365 specific steps that are listed in Autodiscover process ( step 4 and step 11), policy control is available to ensure that appropriate service endpoints are used during the Autodiscover process. 

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.

ITAR Consideration

By default, Outlook queries the known endpoint to retrieve the Autodiscover payload. The existing policy to bypass this step is still valid and can be used to go to step 5 without trying the endpoint. Alternatively, there's a new policy that directs Outlook to query a central Office 365 Config Service to retrieve appropriate URLs from which to retrieve the Autodiscover payload. Conceptually the process works as follows:

  1. You set the new policy.
  2. During step 4 of the Autodiscover process, Outlook queries the Office 365 Config service.
  3. The service determines which (if any) special ITAR needs are in effect for the specified user and returns the appropriate URLs for that user by using the domain information of the UPN.
  4. Outlook tries to retrieve the Autodiscover payload from the URLs provided by the service.

The policy control value for the new feature to use the Office 365 Config Service is EnableOffice365ConfigService.

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.
ITAR Considerations
If Outlook gets to this step and hasn't successfully retrieved an Autodiscover payload, two tests are performed to see whether the well-known Office 365 endpoints should be attempted. First, if the mailbox is a consumer account (for example outlook.com), the well-known endpoint is attempted. Second, if the mailbox is determined to belong to a domain that doesn't have ITAR requirements, the well-known endpoint is attempted. If the mailbox is determined to be commercial and belong to a domain that has ITAR requirements, no attempt is made to the well-known Office 365 endpoints. In future releases, step 11 may move to the same logic as step 4 and call the Office 365 Config Service. When that change is made, this article will be updated to reflect the new process step.

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:

Use the Office 365 Config Service

Key: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
Value: EnableOffice365ConfigService
Default: 0
Data: Set this DWORD data to 1 to force Outlook to call the Office 365 Config Service to retrieve appropriate Autodiscover URLs.

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 Microsoft articles: