Optimizing the Outlook AutoDiscover process by skipping the root domain query
Updated 8/15/2014: see the bottom of this article for
additional information on changed AutoDiscover behavior of Outlook 2013.
Consider the following scenario:
- An Active Directory (AD) domain named equal to the SMTP Suffx, so the mailaddress email@example.com in the contoso.com AD domain.
- No on-premises Exchange, this means that there is no Service Connection Point (SCP) in A.
- Outlook 2013 (or lower versions from Outlook 2007 up).
- Exchange Online (or any hosted Exchange for that matter).
- Additional issue: You’ve got an external website that responds to HTTPS requests and doesn’t have a valid certificate for the root domain. This happens quite a lot, especially when the intent is to redirect to www.contoso.com
In these cases the AutoDiscover proces will detect the domain has no Exchange (because no SCP) and will at first try to connect to https://contoso.com/Autodiscover/Autodiscover.xml. However, because the domain is the same as the SMTP suffix of the primary SMTP the IP’s of the Domain Controllers are returned. That part is as expected, if you look in your domains DNS there are (pinpoint) records on the contoso.com that contain the IP addresses of each DC. It could mean that the initial setup of Outlook can take a while to complete as it waits for an AutoDiscover response. If you have quite a few DC’s, it’s possible Outlook will retry the request for each entry. And each entry will have to time-out (about 20 seconds) before skipping to the next entry.
When this process hasn’t resulted in successfully attaining configuration settings, Outlook will try other options and eventually it will be configured to be connected to the correct Exchange environment at expected speeds.
To resolve this, install the Office 2013 Administrative Templates. If you still use Office 2007 or 2010, you should install the corresponding version (and Service Pack level), however I haven’t checked whether they have the setting I wanted to show you.
After installation, create a new or edit an existing GPO and go the the following User Configuration setting:
Administrative Templates>Microsoft Outlook 2013>Account Settings>Exchange>Disable AutoDiscover.
Check the option “Exclude the root domain query based on your primary SMTP address”.
In one situation we reduced the duration of the AutoDiscover process from 45 seconds (or even failure to complete) to 12 seconds.
Skipping the root domain during the AutoDiscover process, will also resolve the issue when you have a webserver listing on the root domain and that server responds to HTTPS request without having a valid certificate for the root domain. Even if the AD root domain does not correspond to the primary SMTP domain. I’ve seen this a couple of times, were the organization site would redirect to www.contoso.com when the root domain is visited via browser. If the certificate isn’t valid, Outlook will generate a certificate mismatch warning and requires user interaction, which IMHO defeats the purpose of AutoDiscover. In cases that the certificate cannot be adjusted for whatever reason, this would be a good alternative for domain joined computers.
For non-domain joined computers the use of an GPO isn’t possible, but extracted the correct key from the registry might work. You would only need to deploy the setting via other means. Please remember that each version of Outlook requires a separate registry key (if the option is available at all).
For Outlook 2013 this would be (copy and paste to a .reg file and doubleclick on the computer/user that needs this fix. Note (and remove) the extra linefeed after "software\"):
Windows Registry Editor Version 5.00
Disclaimer: the use of this information is at you own risk, you can comprise the correct working of the computer you apply this fix on. Test this before deploying in production!
My thanks to coworker Hans for the regkey information.
Update 8/15/2014: Fellow Exchange MVP Paul Cunningham pointed
out some changed behavior of Outlook 2013, which now simultaneously queries the SCP *and* the SMTP root domain. This can result in certificate issues. Exchange MVP Andrew Higginbotham wrote about it here.