Autodiscover runs at the following times:
- During account creation.
- 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.
- 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.
- When another application invokes it by using MAPI. For more information about MAPI, see the following MSDN article: Outlook MAPI Reference.
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.
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 2010Note
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.
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”:
- An HTTP status code (301, 302) with a new URL
- An HTTP status code of 200, but with a payload XML that tells Outlook to redirect to a different URL
- 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.
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.
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:
Each value is of type DWORD
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
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
Default: 25 Seconds
Minimum: 10 Seconds
Maximum: 120 Seconds
Mapi/Http Protocol Control
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.
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
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
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:
Proxy Authentication Handling
- 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
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.
Legacy information about autodiscover can be found in the following article in the Microsoft Knowledge Base:
Unexpected Autodiscover behavior when you have registry settings under the \Autodiscover key
For more information about Autodiscover, see the following Microsoft articles: