Demystifying Autodiscover. A Deep Dive into Autodiscover.

Unlock the secrets of Autodiscover, the backbone of seamless email configuration! Join us on a journey through the intricacies of Autodiscover, exploring its role in various services, such as Exchange and Office 365.

Watch the video

If you want to learn Autodiscover step-by-step, please watch below videos on our YouTube channel.
Autodiscover in on-premises Exchange Server
Autodiscover in Office 365 and Exchange Hybrid

What is Autodiscover

Before we understand what autodiscover can do for us, let’s consider one example and let’s understand how things used to work when autodiscover service was not available.

In those days, when users had to configure their mailboxes in outlook client, they had to enter the server details manually. For example, incoming mail server and outgoing mail server that will be used to send and receive emails.

But this practise wasn’t feasible. Because for everyone this is not easy to remember these server settings. And this is a time consuming task as well.

Then in Exchange Server 2007, autodiscover service was introduced. Autodiscover service minimizes the number of steps that a user has to take to configure his profile in outlook client.

If autodiscover service is properly configured in your exchange server, users can configure their outlook by just providing the email address and the password of their mailboxes. They do not have to provide server settings manually.

As soon as user will hit Next, Autodiscover service will automatically detect the settings and will help users to configure their profiles.

Services rely on Autodiscover

Autodiscover service is used by multiple client applications. For example, outlook client, OWA, Active Sync devices, Free/Busy lookups, Offline Address Book, Out of Office. If you have exchange hybrid deployed, autodiscover will be used for cross-premises permissions, cross-premises free/busy and in mailbox migration.

Autodiscover in Exchange Server

Now let’s understand how Autodiscover works in on-premises Exchange Server.

What is Service Connection Point (SCP)

When we install Exchange Server 2016 or later, an Autodiscover virtual directory is created in IIS. And at the same time, a service connection point object is created in Active Directory. And if you are installing Exchange Server 2013 or earlier, then these objects will be created at the time of CAS (Client Access Server) role installation.

To find Service Connection Point (SCP) object in Active Directory, go to Active Directory Sites and Services > Services > Microsoft Exchange > Expand your domain name > Administrative Groups > Exchange Administrative Group > Servers > Exchange > Protocols > Autodiscover.

This Service Connection Point object contains 2 important attributes. Service Binding Information
and Keywords.

Service Binding Information attribute stores the fully qualified domain name or the FQDN of Client Access Server (in case of Exchange Server 2013 or earlier) and Mailbox Server role in case of Exchange Server 2016 or later.

The format of Service Binding Information attribute is https://autodiscover.domain.com/autodiscover/autodiscover.xml

Keywords attribute stores the name of the Active Directory site where the mailbox server is installed. In case of Exchange Server 2016 or later, this will be the mailbox server, and in case of Exchange 2013 or earlier, this will be the Client Access Server.

Note: Learn Exchange Server architecture and its roles in depth. Watch this video on our YouTube channel.

Autodiscover process in domain joined machine:

Let’s understand how Autodiscover look-ups work when a user tries to configure his mailbox in Outlook client in a domain-joined machine in on-premises Exchange Server environment.

1. When a user tries to configure his profile in Outlook client from a domain-joined machine, Outlook sends a Lightweight Directory Access Protocol query (LDAP) to Active Directory. Through this LDAP query, Outlook tries to locate all the available SCP objects within Active Directory.
2. Then Outlook locates the Keywords attribute from the SCP object. From keywords attribute, Outlook tries to find the location of the Client Access Server.
3. Once Outlook client finds the location of the client access services, it tries to connect to the autodiscover URL that is retrieved from service biding information attribute from SCP object. When you create an SSL certificate for your exchange server, you need to make sure that autodiscover.domain.com is added under Subject Alternate Names of that SSL certificate. So that the communication over this URL can be secured. Else autodiscover request will fail.
4. From this URL, outlook client will retrieve the profile information in the form of XML file that is required to connect to the user’s mailbox and to access other exchange services.
5. Then outlook client will connect to the mailbox server using HTTPS connection, and the outlook profile will be configured. If autodiscover service URL is configured for your exchange server, the autodiscover query will resolve on this step. And the outlook profile will be configured successfully.
6. But if autodiscover URL is not configured in your exchange server, the autodiscover query will be redirected to the SRV record, and autodiscover service will look for an SRV record in your Active Directory. And from SRV record, autodiscover query will be redirected to the mailbox server, and outlook client will get the XML file that is required to configure the outlook profile.
7. And if SRV record is also not configured, then autodiscover query will fail and user will not be able to configure his profile in outlook client.

Autodiscover process in non-domain joined machine

Let’s understand how Autodiscover look-ups work when a user tries to configure his mailbox in Outlook client in a non-domain-joined machine (external network) in on-premises Exchange Server environment.

1. The first lookup (SCP look up) will fail because user is using external network or a non-domain-joined machine.
2. Then Outlook will try to locate autodiscover service by using the Domain Name System or DNS.
3. Outlook will use the domain suffix from the email address of the user who is trying to configure his profile in Outlook. For example, if user’s email address is [email protected], outlook will extract office365concepts.com from the email address and will reach DNS using 2 predefined URLs. https://domain.com/autodiscover/autodiscover.xml and https://autodiscover.domain.com/autodiscover/autodiscover.xml. The first URL https://domain.com/autodiscover/autodiscover.xml will fail because we do not publish any CNAME record or autodiscover record with our domain name. So query will reach to the second URL https://autodiscover.domain.com/autodiscover/autodiscover.xml. So you need to make sure that you have a CNAME record published for autodiscover service in public DNS that is pointing to your on-premise mailbox server. In case of Exchange 2016 and later, this will be the mailbox server. And in case of earlier versions like Exchange 2013, this will be the Client Access Server.
4. With the help of CNAME record, client will be redirected to the mailbox server and client will get the xml file that is required to connect to the user’s mailbox.
5. And for any reasons if autodiscover service is not working in your exchange server, then query will be redirected to SRV record. And client will try to find the XML file using the SRV record.

Autodiscover in Office 365

Now let’s understand Autodiscover process when your mailboxes are hosted in Office 365. That means you have fully Office 365 environment.

1. Outlook will first check if provided user principal name belongs to Microsoft 365 account. If Outlook finds that this account is Microsoft 365 account, outlook will try to retrieve Autodiscover payload from Microsoft 365 endpoints which is https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml. But in case you have created a registry key ExcludeExplicitO365Endpoint on client machine, then outlook will not be able to connect to this URL.
2. The next lookup process is root domain. Outlook builds a URL from the domain name of the initial address in the format of https://domain.com/autodiscover/autodiscover.xml. Now outlook will try to retrieve the payload from the resulting URL. Because many root domains are not configured for Autodiscover, this lookup will fail.
3. Next autodiscover look up is Autodiscover.Domain.com. For this step, outlook will create a URL from the domain name of the user principal name, and will form a URL https://autodiscover.domain.com/autodiscover/autodiscover.xml. And will try to retrieve the autodiscover payload. If outlook does not retrieve XML file from this URL, it will move to the next lookup process.
4. The next autodiscover lookup is HTTP redirect. Outlook will send a request to autodiscover domain URL which is http://autodiscover.domain.com/autodiscover/autodiscover.xml. Even if outlook will find the XML file from this URL, outlook will ignore this response because the response is sent from HTTP which is a non secured URL.
5. Next autodiscover lookup is SRV lookup. In this step Outlook makes a DNS query for autodiscover.tcp.domain.com and tries to find the XML file. If outlook doesn’t find XML file on this step, it moves to next step which is Office 365 as fail safe.
6. In this step outlook will try to find XML file from https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml.

Autodiscover in Exchange hybrid

Now let’s understand how Autodiscover process works in Exchange Hybrid environment. In Exchange Hybrid environment we have few mailboxes in on-premise Exchange server and few are on Microsoft 365. Even when Autodiscover is pointing to your on-premises Exchange environment, it continues to work for Mailboxes that have been migrated to Exchange Online. This is one of the advantages of an Exchange Hybrid scenario.

Let’s assume we have a user in on-premise Exchange server and we have migrated this user to Microsoft 365. When this user will be migrated to Microsoft 365, a remote mailbox will be created in on-premise Exchange, and a remote routing address and target address will be added to the user attributes in on-premises Active Directory and in on-premises Exchange mailbox properties.

1. When this user will try to configure his profile in outlook, the first Autodiscover lookup will be https://domain.com/Autodiscover/Autodiscover.xml. Outlook will not find xml file on this URL and will move to the next lookup.
2. The next Autodiscover lookup is autodiscover.domain.com. On this URL this query will be redirected to Microsoft 365 because the on-premise remote mailbox has a remote routing address added and the query will be forwarded to domain.mail.onmicrosoft.com.
3. The next autodiscover lookup is domain.mail.onmicrosoft.com. This URL will fail because we do not add autodiscover records on mail.onmicrosoft.com domain.
4. The next autodiscover lookup is autodiscover.domain.mail.onmicrosoft.com. The XML file is not available on this URL, so the query will move to the next URL.
5. Next lookup URL is Redirect method which is initiated on a non-secured channel. So even if outlook will find the XML file, it will ignore this and will move to the next URL.
6. The next autodiscover URL is Microsoft 365 endpoint which is autodiscover-s.outlook.com, where XML file will be retrieved and outlook profile will be configured.

I hope this article was informative and helped you to understand one of the complex topics in Exchange environment.

Related articles

We welcome you to browse our other articles:
Troubleshooting Out Of Office replies. Delete Out of Office Rule with MFCMAPI
How to use MFCMAPI tool
Troubleshooting Inbound connector in Exchange Online
Troubleshooting Exchange Online Mail Flow: A Comprehensive Guide
Exchange Online Protection (EOP) interview questions and answers
Demystifying the High Risk Delivery Pool (HRDP) in Exchange Online
Exploring the Power of Public Folders in Exchange Online, Office 365 and Microsoft 365
Top 50+ Office 365 Interview questions and answers

Happy Learning!