Autodiscover and Registry Edits for Outlook and MAPI

According to Microsoft, "Autodiscover is considered the single point of truth for configuration information and must be configured and working correctly for Outlook to be fully functional." As such, it provides a crucial step when setting up a SmarterMail account in Outlook using MAPI. And, at times, this can be easier said than done. However, the vast majority of issues relate to changes Microsoft is making to Outlook, Autodiscover, and the entire Microsoft Cloud and Microsoft 365 platform. These changes mean SmarterMail users may find it necessary to make some Registry edits in order to get Outlook and SmarterMail to work well together.

Autodiscover Timings
Autodiscover runs at the following times:

1. During initial account creation.
2. At set intervals to look for any changes to URLs that provide Exchange Web Service (EWS) features such as out of office replies, availability, etc. If this process is successful, another check occurs an hour later. If any attempt is unsuccessful, another try is made within 5 minutes.
3. In response to connectivity failures. When a connection attempt fails, Outlook starts an Autodiscover task to retrieve any new settings in an attempt to correct the connection problem.
4. When another application invokes it by using MAPI. 

Autodiscover Processing Steps

Every time that Outlook needs Autodiscover information, it uses the following steps. If Outlook successfully retrieves Autodiscover information at any point in this process, it will skip the remaining steps:

1. Check for restart scenarios. This is a shortcut that seems to only apply when configuring a new account in Outlook. To help configure the account, Outlook will retrieve and cache the needed autodiscover information. It then restarts Outlook, and will use the recently cached information instead of doing a new autodiscover lookup.
2. Check for local data preference. If the machine has the PreferLocalXml policy enabled, Outlook will search for an XML autodiscover file on the local machine. The location of that file is specified by a string value in the HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover registry key.
3. Check for Last Known Good data. If Outlook has previously loaded the account and cached the autodiscover information, it will use it for this step. However, Outlook will only do this for the primary account in a profile.
4. Check for Office 365 priority. At this stage, Outlook uses an undefined set of heuristics to determine if the account references an O365 user. If it "determines confidently" that the account refers to an O365 user, then it will utilize known O365 endpoints to get autodiscover information.
5. Check for Service Connection Point (SCP) data. If the machine is joined to a domain, Outlook will perform an LDAP query to get SCP data. If the query returns any SCP data, Outlook will attempt an autodiscover request against every provided URL.
6. Check root domain. Using the provided account information, Outlook builds a basic URL like https://<domain>/autodiscover/autodiscover.xml and attempts an autodiscover request against that URL.
7. Check autodiscover domain. Using the provided account information, Outlook builds a basic URL like https://autodiscover.<domain>/autodiscover/autodiscover.xml and attempts an autodiscover request against that URL.
8. Check for local data. If step 2 was skipped because the PreferLocalXml policy was disabled, Outlook performs that check here.
9. Check for HTTP redirects. Using the HTTP version of the URL from step 7, Outlook performs an autodiscover query, if an autodiscover response is returned, Outlook ignores it because it was retrieved in an insecure manner. If the response provides a redirect, Outlook follows the redirect to retrieve autodiscover information.
10. Check for SRV data. Outlook performs a DNS lookup for _autodiscover._tcp.<domain>. If any results are found, Outlook uses the first one that specifies HTTPS to do an autodiscover query.
11. Check for O365. Outlook uses an undefined set of relaxed heuristics to determine if there is a chance that the account might be available on O365. If it determines that the user might be on O365, it will try the same endpoints as in step 4.

• PreferLocalXML Invokes Step 2 instead of Step 8. Needs to have a string value next to it to indicate where to look. The name for that value should be the referenced domain and the data field should specify where the autodiscover XML is located.
• ExcludeLastKnownGoodURL skips step 3.
• ExcludeExplicitO365Endpoint skips steps 4 and 11.
• ExcludeScpLookup skips step 5.
• ExcludeHttpsRootDomain skips step 6.
• ExcludeHttpsAutoDiscoverDomain skips step 7.
• ExcludeHttpRedirect skips step 9.
• ExcludeSrvRecord skips step 10.

Based on what some customers have reported, and results of our internal testing, it seems that using ExcludeExplicitO365Endpoint to skip steps 4 and 11 has the most impact, though the other values may be useful depending on your specific setup.

Other registry keys, such as RedirectServers and DisableOffice365SimplifiedAccountCreation have no impact on the Autodiscover process and seem designed to alter the user's experience during account setup. The first allows you to prevent the confirmation dialog associated with accepting Autodiscover settings from specific servers, and the second reverts the account creation wizard to the format used in older versions of Outlook.

Registry Settings of Note

Key: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\AutoDiscover\RedirectServers

String (REG_SZ): <your_mail_domain>

Notes: Some users suggest adding this as a DWORD, but the above aligns with the Microsoft's documentation. Leaving the data field blank will cause any Autodiscover that is found for the domain to be used without asking the user to confirm.

Key: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\setup

DWORD DisableOffice365SimplifiedAccountCreation

Data: A value of 1 forces Outlook to use the traditional account setup wizard instead of the simplified wizard.

Optional Registry Settings

The following Registry settings are also related to setting up Outlook. While they may not improve Outlook's ability to connect to SmarterMail, they may prove useful when troubleshooting issues:

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

DWORD: EnableOffice365ConfigService

Data: A value of 1 modifies steps 4 and 11 of the autodiscover process to use the Office 365 Configuration Service instead of the standard O365 autodiscover endpoints.

Notes: This value is intended to improve the setup experience for Office 365 accounts. It is NOT recommended to use this key when connecting to SmarterMail.

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

DWORD: Timeout

Data: A value between 10 and 120, default is 25.

Notes: This specifies the timeout Outlook will use for autodiscover requests in seconds. This could be useful if it appears that the autodiscover process is failing due to delayed responses.

Key: HKEY_CURRENT_USER\Software\Microsoft\Exchange

DWORD: MapiHttpDisabled

Data: A value of 1 disables the MAPI over HTTP protocol.

Notes: Do not use this with accounts that utilize MAPI.

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

DWORD: ShowCertErrors

Data: A value of 1 causes Outlook show select certificate errors to the end user, giving them an opportunity to accept the certificate with the errors.

Notes: This may be useful for helping to diagnose certificate related issues, but is not generally a good idea. Enabling this permits users to ignore the following certificate errors:

• Problems with the date on the certificate.
• Problems with the certificate's common name.
• Problems with the certificate authority.