Outlook 2016 implementation of Autodiscover

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 percent 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 cause a large number of DCs to be contacted before a result is found. After Outlook discovers the UPN for the user, the value is cached in the profile, and the lookup should not happen again for this user.

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

ITAR considerations

Microsoft Office 365 provides features that can support customers with ITARobligations. 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.

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”:

• 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.

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 time-out 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 time-outs are used as WinHttpSetTimeouts settings. The data specified is passed to all four parameters of the WinHttpSetTimeouts API. This potentially allows an HTTP request that cannot be reached to time out faster, which will improve overall performance. The settings could also allow an HTTP request that takes longer than the default of 25 seconds to succeed by increasing the time-out setting 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 WINHTTP_STATUS_CALLBACK callback function

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 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.