Lessons Learned and Best Practices for Autodiscover in a Hybrid Environment

Outlook uses the Autodiscover service to get real-time connection information for your mailbox and any other mailbox you connect to. Without Autodiscover you may be able to get Outlook to connect, but it won't connect correctly. For example, Exchange Web Services (EWS) connectivity in Outlook can only be made using Autodiscover.

Outlook normally performs Autodiscover requests when you setup a mail profile for the first time and from then on, periodically in the background. This is how automapped shared mailboxes get automatically added to Outlook. Outlook also runs an Autodiscover request when your mailbox moves between servers or databases, as when a failover event occurs. Autodiscover is also used whenever you check free/busy availability of another user's calendar.

Domain-joined computers in an Exchange Server or hybrid environment normally use a Service Connection Point (SCP) published in Active Directory to get the URI Outlook should use for Autodiscover requests. This is set using the Set-ClientAccessService -AutoDiscoverServiceInternalUri <value> cmdlet in the Exchange Management Shell (EMS).

There's a lot of documentation in the web that says you should set the AutoDiscoverServiceInternalUri value to $null after a hybrid migration is complete. But is that the right thing to do?

It's a long answer, so strap in. 😉  Tl;dr at the end.

First, know that Autodiscover behavior changes depending on the Outlook client and build version, as well as possible non-standard registry settings.

Microsoft 365 Apps for Enterprise always tries https://outlook.office365.com/autodiscover/autodiscover.xml first (Autodiscover-V2) regardless of your DNS settings. Microsoft's assumption is that if you’re running that version, your account is probably in the cloud. If your mailbox is indeed in EXO, that process looks like this and only takes 1-2 seconds:

Autodiscover-V2 will fail if your account is missing in EXO or not migrated yet and Outlook will then start the regular Autodiscover-V1 process. Note that the Autodiscover-V2 process can also be skipped with the following reg key. I see this often in older enterprise environments.

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover]
"ExcludeExplicitO365Endpoint"=dword:00000001

Office 2016/2019 clients normally only do the regular Autodiscover-V1 process, which is well known:

1. Check for Local Data preference (configured via GPO to use an autodiscover.xml file stored locally on the computer)
2. Check for Last Known Good (LKG) cached data
3. Some later builds use heuristics to determine if the user account comes from Azure AD and will check against https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml 
4. SCP (see *notes below)
5. DNS
• Root domain (https://contoso.com/autodiscover/autodiscover.xml, which nearly always fails)
• Autodiscover URI (https://autodiscover.contoso.com/autodiscover/autodiscover.xml)
6. HTTP redirect
• http://autodiscover.contoso.com/autodiscover/autodiscover.xml
7. SRV
• Value from _autodiscover._tcp.contoso.com 443 0 0 in DNS

*Note that the SCP process won't work in several scenarios:

• The computer is not domain-joined
• SCP is $null
• SCP is not available via LDAP because the domain-joined machine is disconnected from the DC
• Registry keys can, and most often will, override the default Autodiscover behavior

Here’s what the process looks like for an M365 mailbox user in a hybrid environment from a domain-joined computer on the LAN. The SCP is set to https://autodiscover.contoso.com/autodiscover.autodiscover.xml (the on-prem Exchange Server). This process took 52 seconds to complete. Remember, this is the same process that Outlook goes through when creating a new mail profile, too.

When the SCP is set to $null it skips the first five lines, but execution time is nearly the same. It gets there, but it's not efficient and takes a really long time.

If we set the SCP to https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml, the process only takes about 1 second.

As you can see, setting the SCP to https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml is much more efficient than setting it to $null when the migration is complete.

Tl;dr:

The Service Connection Point (SCP) is set using the Set-ClientAccessService -AutoDiscoverServiceInternalUri <value> cmdlet.

• If you're a hybrid customer and you still have mailboxes on-premises that use Outlook:
• Set your SCP to https://autodiscover.contoso.com/autodiscover/autodiscover.xml.
• Create an A record for autodiscover.contoso.com in internal and external DNS resolving to on-prem Exchange for computers that can't reach AD.

• If you're a hybrid or cloud customer and all mailboxes that use Outlook or in EXO:
• Use Microsoft 365 Apps for Enterprise, which always checks EXO first. It also provides the best experience, features, and performance for cloud mailboxes.
• If you're hybrid, set your SCP to https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml.
• Create a CNAME record for autodiscover.contoso.com in external DNS resolving to autodiscover.outlook.com. This way, older clients that don't use Autodiscover-V2 will use the HTTP redirect method to get to EXO.