Autodiscover timingAutodiscover 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 percent 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.
To avoid this scenario, the user can log on by using a UPN instead of domain\username.
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.
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
Step 2: Check for Local Data preference
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, it 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
The policy control value for this step is as follows: ExcludeLastKnownGoodURL.
Step 4: Check for O365 as priority
The policy control value for this step is as follows: ExcludeExplicitO365Endpoint.
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:
- You set the new policy.
- During step 4 of the Autodiscover process, Outlook queries the Office 365 Config service.
- 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.
- 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.
As of build 16.0.9327.1000, the EnableOffice365ConfigService policy is no longer used.
Step 5: Check for SCP data
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
The policy control value for this step is as follows: ExcludeHttpsRootDomain.
Step 7: Check Autodiscover domain
The policy control value for this step is as follows: ExcludeHttpsAutoDiscoverDomain.
Step 8: Check for local data
There's no policy control for this step.
Step 9: Check for HTTP redirects
The policy control value for this step is as follows: ExcludeHttpRedirect.
Step 10: Check for SRV data
Step 11: Check for O365 as failsafe
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 tries to retrieve the autodiscover XML from the new URL, provided that 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: 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
Data: Set this DWORD data to 1 to force Outlook to call the Office 365 Config Service to retrieve appropriate Autodiscover URLs.
HTTP time-out settings
Default: 25 Seconds
Minimum: 10 Seconds
Maximum: 120 Seconds
Mapi/Http Protocol Control
Data: 1 = Protocol is Disabled; 0 = Protocol is Enabled
Legacy Authentication Negotiation Control
Data: 1 = Headers are added; 0 = Headers aren't added
Certificate Error Handling
Data: 1 = Show certificate warnings/errors; 0 = Don't show certificate warnings
- 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
3115474 MS16-099: Description of the security update for Outlook 2010: August 9, 2016
Autodiscover for other protocolsAutodiscover 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 are 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:
For more information about Autodiscover, see the following Microsoft articles:
Autodiscover service: https://technet.microsoft.com/en-us/library/bb124251(v=exchg.150).aspx