Make Sure Your Implementation of Autodiscover Avoids Common Pitfalls

During a recent project, I encountered a situation where the Autodiscover service was set up incorrectly. The misconfiguration caused some problems with the deployment of Microsoft 365. This article revisits Autodiscover and discusses why it is important to deploy it correctly to make sure that all of Microsoft 365 works, including Exchange Online.

What is Autodiscover?

Microsoft introduced Autodiscover with Exchange Server 2007 to simplify the configuration of Outlook desktop clients. Originally limited to Outlook and Exchange, the role of Autodiscover expanded over time to take in different parts of BPOS, Office 365, and now Microsoft 365.

In nutshell, Autodiscover enables client applications to query a specific DNS record (either an SRV record or a CNAME/A record) or an on-premises Active Directory Service Connection Point (SCP) to retrieve information services available to the client. These endpoints work well in on-premises environments. In the cloud, I prefer to use DNS CNAME/A records. This method is easier to manage and works across any environment. All you need to make Autodiscover work is to create an autodiscover.<primary domain> record in your DNS zone pointing to the FQDN of your Exchange Server (running the Client Access role in Exchange 2013 or earlier). For Microsoft 365 deployments, the DNS record points to autodiscover.outlook.com.

Client applications like Outlook use DNS to locate the Autodiscover service and to query metadata including where the user’s mailbox is located and how to connect different mailbox-related services (like the address book). The client app processes the XML data returned by Autodiscover to know how to connect.

If you want to see the data returned by Autodiscover and confirm that Autodiscover is running properly, visit Microsoft’s Remote Connectivity Analyzer (RCA) and perform an Outlook Connectivity Test (Figure 1). Alternatively, on a PC, use CTRL+click on the Outlook icon in the system tray and choose Test Email Configuration. Note that RCA performs its tests from a Microsoft server and not a PC in the target environment. Both methods query Autodiscover services using methods recommended by Microsoft. One thing to note is that RCA only performs DNS-based Autodiscover, while Outlook also uses an SCP-based query.

How Client Applications Use Autodiscover

Autodiscover is used by several Microsoft 365 applications to locate a user’s mailbox and other Exchange-related services. But it is up to the client application to decide how to find the Autodiscover endpoint and consume the provided information. I have come across many administrators, students (yes, I also do Microsoft 365 training), colleagues, and clients who think Autodiscover follows a standardized process. However, that is not the case.

Let’s look at how Outlook uses Autodiscover. Refer to Microsoft’s documentation for a step-by-step guide on how to Implement Autodiscover on Outlook 2016 (and above) including the Outlook click-to-run client. The documentation also includes a discussion about registry keys that modify Outlook’s behavior, if needed. In short, Outlook locates the Autodiscover service via:

1. Local cache or Last Known Configuration. Outlook saves a copy of the data for later use.
2. Determine if the user is in Microsoft 365 via Office 365 Configuration Services.
3. Active Directory SCP query.
4. Root domain DNS query. For example, your email is user@domain.com which will query http://<domain>/autodiscover/autodiscover.xml where the domain section is the domain part of your email address.
5. Autodiscover domain like Autodiscover.<domain> where the domain section is the domain part of your email address.
6. Use Microsoft 365 as a failsafe.

If you take a closer look at the information, you will notice Outlook always queries Active Directory for SCP. However, if you use a Mac or PC that is not in the same domain as Exchange (as in the case of Exchange Online), the query will not work. This is a common issue for Outlook users who experience delays when trying to configure Outlook for Office 365 for the first time. Microsoft’s solution asks you to disable the SCP query to make the Autodiscover process more robust and faster.

The point here is that the client application is the one controlling how to interact with Autodiscover. Don’t assume that every client interacts with Autodiscover in the same way. We know that Outlook for Windows queries SCP, but Outlook for Mac/Mobile only uses DNS to locate Autodiscover. If your implementation relies on SCP, Mac/Mobile clients will experience a slow response when setting up an Outlook profile and occasionally experience error prompts when Outlook tries to check Autodiscover to update its configuration.

The Autodiscover Problem?

In this project, the client originally assumed that SCP was already implemented for Autodiscover, and nothing else needed to be done. But is that really the case?

Unfortunately, it wasn’t. When the project started, we began receiving support requests from end users saying they were experiencing some weird behavior when accessing on-premises mailboxes. Let me name a few:

1. Teams cannot find the mailbox and was unable to display the calendar.
2. OWA and Outlook for Windows are working very slowly when displaying contact card information.
3. The out-of-office message not displaying properly in Teams.
4. The Teams Add-in for Outlook did not always work.

Then we investigated and took some Fiddler traces. We noticed some errors recorded in the traces saying Autodiscover queried the Autodiscover DNS records, but failed to find the record.

You may wonder, why does the query sometimes work? It is because Microsoft did us a favor in that if a user’s Exchange cannot be found, all their first-party applications are hardcoded to search Microsoft 365 via Autodiscover.outlook-s.com. We discovered this fact by reviewing the Fiddler traces. We have a Hybrid Exchange setup so the Microsoft 365 Autodiscover can return the mailbox information even when the mailbox is hosted on an on-premises Exchange Server. But it takes time for the client to work through the steps and eventually connect to outlook.com (Figure 2). For example, users might wait 30 seconds before Outlook displays the contact card information.

The Solution: Always use DNS-based Autodiscover

A Microsoft Technical community post says that Teams is hardcoded to use Exchange Online Autodiscover and will failback to DNS-based Autodiscover. Wait! Isn’t that the cause of the problems discussed here? My client didn’t create the DNS Autodiscover record and their mailboxes are on-premises.

Is it just Teams that behaves like this? Unfortunately, it’s not the case. Many other apps, like OWA, SharePoint Online, OneDrive, and third-party apps, use DNS-based Autodiscover as well. And like Teams, I prefer to always use DNS-based Autodiscover as it is guaranteed to work regardless of what code the application uses to locate and connect to a mailbox.

I concluded that a missing DNS-based Autodiscover is one cause of the issues mentioned above. Later, we realized that other issues existed within the setup and problems still happened. Let’s save that for next time.

Conclusion: Ensure the Basics Work and Keep Things Simple.

After working through the issues over months with the client’s internal team, Microsoft Support, and my team, we finally see light at the end of the tunnel. I would like to share a few lessons I learned in the process:

1. Always ensure the basics work. In Microsoft 365 projects, make sure Autodiscover works before doing anything else.
2. Keep things simple: use DNS-based Autodiscover as it is easier to manage and works across many platforms.

For those who rely on SCP for Autodiscover, it still works but as a best practice, we always recommend removing it and relying on DNS-based Autodiscover for better performance.