The Autodiscover flow in an Exchange Hybrid based environment can be considered the most complex…
Autodiscover flow in an Office 365 environment | Part 2#3 | Part 30#36
The current article and the next article will be dedicated to detailed review of the Autodiscover flow; that implemented in an Office 365 based environment by using the Microsoft web-based tool, the Microsoft Remote Connectivity Analyzer (ExRCA).
Autodiscover flow in an Office 365 based environment | The article series
- Autodiscover flow in an Office 365 environment | Part 1#3 | Part 29#36
- Autodiscover flow in an Office 365 environment | Part 2#3 | Part 30#36
- Autodiscover flow in an Office 365 environment | Part 3#3 | Part 31#36
Table of contents
- Autodiscover flow in an Office 365 based environment | The article series
- The Autodiscover Journey
- The Autodiscover long journey in Office 365 and Exchange Online environment
- Using the Microsoft remote connectivity analyzer – the prefix
- Analyzing the Autodiscover process | Steps described in details
The Autodiscover in Office 365 environment includes many steps.
I have tried to separate each of these steps and came with a result of 20 different parts.
The number “20”, is just an arbitrary number because, the “Autodiscover Journey” can be dived even to more parts or fewer parts.
The number of the “parts” depend on many variables but the important observations from the “Autodiscover journey” are:
- The Autodiscover process is a very “smart” and intelligent mechanism, which manages to survive in a complex and complicated environment.
- There are many “moving parts” and many available paths for the Autodiscover journey.
- Part of the Autodiscover process includes “built-in failures”. This “failure” are normal and expected. What matters is the “final results” meaning – did the Autodiscover client manage to complete the Autodiscover journey successfully or not.
The Autodiscover Journey
In the next sections, will dive under the “Autodiscover hood” and watch every step and process that are involved in an Autodiscover process in Office 365 and Exchange Online environment.
Before we start, let’s define the factors that are involved in the process.
1. The Autodiscover client
The client is the entity that needs the required information from the Autodiscover Endpoint. The Autodiscover client could be – mail client such as Outlook, mobile devices (ActiveSync client) and so on.
In this article, the Autodiscover client is the ExRCA (the Microsoft web diagnostic tool).
We use the excellent ability of the ExRCA, to display a very detailed report that describes in a very clear and precise way the steps that implemented in the Autodiscover process.
Note: Although the ExRCA a very detailed information, some of the “Autodiscover steps” is not mentioned in the ExRCA results report. For example, the process in which the Autodiscover client provides his credentials to the Autodiscover Endpoint doesn’t appear in the ExRCA report.
In this scenario, I added my description\explanation although we cannot see “evidence” for this Autodiscover process in the ExRCA report.
2. The Autodiscover Endpoint
The term “Autodiscover Endpoint”, relates to each of the nodes or the hosts who will be involved in the Autodiscover process.
Soon, we will see that the Autodiscover client will meet a couple of “elements”.
(The default assumption of the Autodiscover client is that each of these “elements” is the required Autodiscover Endpoint (potential Autodiscover Endpoint).
In reality, only the last node is the “truth Autodiscover Endpoint”. All the rest of the hosts who involved in the Autodiscover process in an Office 365 environment, serve as a “logical routers” that will lead and redirect the Autodiscover client to his destiny.
3. The purpose of the Journey
The only purpose of the Autodiscover Journey is very simple – to get an Autodiscover response that includes the required configuration setting for a new Outlook mail profile + infrastructure about existing Exchange web services.
The Autodiscover long journey in Office 365 and Exchange Online environment
In the next sections, we will get into the very specific details of every step that include in the Autodiscover process in the Office 365 environment.
The journey is quite long, and we will need to have some patience to be able to accompany the Autodiscover client in the journey.
Before we will get into the details, is important that we will be able to see the “big picture” or the major nodes that will participate in the Autodiscover journey in Office 365 and Exchange Online environment.
In the following diagram, we can see the Autodiscover client will have to pass through many nodes in his journey, before he is able to complete the Autodiscover journey and get to his “final destination” (number 4 in the diagram).
To be able to demonstrate the Autodiscover process in a “cloud only environment”, we use the following scenario:
An organization named – o365info.com , use Office 365 and the Exchange Online as their mail infrastructure. All the user’s mailboxes are hosted at the Exchange Online infrastructure.
In our scenario, a user named – Bob that uses the following E-mail address –Bob@o365info.com, needs to create a new Outlook mail profile.
The Autodiscover client will start his Autodiscover journey, by looking for an Autodiscover Endpoint named – o365info.com
The Autodiscover Endpoint uses this specific hostname because the Autodiscover Algorithm is based on a method in which the Autodiscover client is “taking” the SMTP domain name from the recipient E-mail addresses (o365info.com ).
Using the Microsoft remote connectivity analyzer – the prefix
To be able to illustrate each of the Autodiscover parts, we will use a combination of diagrammatic and a screenshot from the result of the Microsoft remote connectivity analyzer
In our scenario, we would like to review the Autodiscover process of a user whom his mailbox is hosted at Exchange Online. For this reason, we will choose the Office 365 tabs and then; we will choose the test option of – Outlook Autodiscover.
In the following screenshots, we can see the results of the Outlook Autodiscover process for bob’s mailbox that is hosted on the Exchange Online.
In this “high level” view of the Autodiscover test results, we can clearly see the “structure” of the Autodiscover process that is implemented in the Office 365 environment.
(The Autodiscover process is implemented in a different way than a “standard Autodiscover process” of external client that tries to access Exchange On-Premise infrastructure).
The first two steps, in which the Autodiscover client tries to access the “standard Autodiscover Endpoint” by using the host names – o365info.com and,
autodiscover.o365info.com failed (number 1 and 2 in the screenshot).
The “real Autodiscover process” in an Office 365 environment start only after the phase of the HTTP redirection that is implemented by the element named – autodiscover.o365info.com (number 3 in the screenshot).
When we look at the Autodiscover process that is implemented in the Office 365 environment, we can see that the Autodiscover client will be redirected to additional Office 365 elements named – Autodiscover-s.outlook.com (number 4 in the screenshot).
When the Autodiscover client reaches the Office 365 elements named-
Autodiscover-s.outlook.com, he will be redirected again to his “final destination” the Exchange Online CAS server who will “connect” the mail client to his mailbox, provide him the required Autodiscover information, etc.
Analyzing the Autodiscover process | Steps described in details
Step 1/20: Attempting to resolve the host name o365info.com in DNS
By default, Autodiscover client will try to locate a “potential Autodiscover Endpoint” by using a host name who was “extracted” from the recipient E-mail address.
Autodiscover client will use the “right part” of the recipient E-mail address that includes the SMTP domain name.
In our scenario, the recipient E-mail address is – Bob@o365info.com
Based on this specific E-mail address; the Autodiscover client will create a DNS query looking for an IP address of a host named – o365info.com
The “answer” of the DNS server, depend on the specific organization public server’s and services infrastructure.
For example, most of the organizations, have a public web site and, most of the time the public domain name is “mapped” to the public IP of the website.
In our scenario, the DNS server reply with a public IP address of the requested host name. The IP that was provided by the DNS server, doesn’t “belong” to an Exchange server (Autodiscover Endpoint) but instead, this public IP address is assigned to a standard web server.
Step 1/20: Analyzing the data from the ExRCA connectivity test
On the ExRCA result page, we can see the following information:
The ExRCA test results start with an error message that the connection attempt to the host name – o365info.com failed.
Attempting to test potential Autodiscover URL https://o365info.com:443/Autodiscover/Autodiscover.xml
testing of this potential Autodiscover URL failed.
(We will get more details about the reason for the failure in the next section)
Note that when we look at the details of the Autodiscover flow that was performed by the Autodiscover client, we can see that some of the steps to complete successfully.
For example, the name resolution step, in which the Autodiscover client asks for the DNS server the IP address of the host o365info.com complete successfully.
Attempting to resolve the host name o365info.com in DNS. The host name resolved successfully. IP addresses returned: 184.108.40.206, 220.127.116.11
Step 2/20: Testing TCP port 443 on host o365info.com to ensure it’s listening and open.
The Autodiscover client addresses the potential Autodiscover Endpoint, using the IP address that he got in the previous step.
The Autodiscover client, will try to verify if – the potential Autodiscover Endpoint can communicate using the HTTPS protocol (port 443).
In our scenario, the HTTPS communication test fails because the “destination host” doesn’t support HTTPS communication.
Step 2/20: Analyzing the data from the ExRCA connectivity test
In the ExRCA result page, we can see the following information about the process in which the Autodiscover client tries to verify of the destination host
(o365info.com ) can communicate using TCP port 443
The specified port is either blocked, not listening, or not producing the expected response. A network error occurred while communicating with the remote host.
Step 3/20: Attempting to resolve the host name autodiscover.o365info.com in DNS
Because the communication attempt with the potential Autodiscover Endpoint using the host name o365info.com using HTTPS fails, the Autodiscover client will pass to the next method, in which the Autodiscover client will look for a potential Autodiscover Endpoint using the following naming scheme – Autodiscover + <Recipient SMTP domain>
In our scenario, the recipient E-mail address is – Bob@o365info.com
Based on this specific E-mail address; the Autodiscover client will create a DNS query looking for an IP address of a host named – autodiscover.o365info.com
The DNS server reply includes a range of IP addresses from which the Autodiscover client can choose.
In our scenario, the public DNS includes the required CNAME record that “redirect” the Autodiscover client query to the IP address range that is mapped to the host name – Autodiscover.outlook.com
In our scenario, the DNS provides the following range of IP address – 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52.
(The “Office 365 entities “named – autodiscover.outlook.com , serve as a “logical router” that will redirect the client to “next hop” in the Autodiscover Journey).
Step 3/20: Analyzing the data from the ExRCA connectivity test
In the ExRCA result page, we can see the following information about the Attempting to resolve the host name autodiscover.o365info.com
The host name resolved successfully. IP addresses returned: 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124
Step 4/20: Testing TCP port 443 on host autodiscover.o365info.com to ensure it’s listening and open.
The Autodiscover client addresses the potential Autodiscover Endpoint and tries to verify if the potential Autodiscover Endpoint is listed on port 443 (HTTPS).
In our scenario, the HTTPS communication test fails.
Although the result of the failure appears as a “problem”, in an Office 365 environment this is the Expected result.
In our scenario, the Autodiscover client “think” that he is talking with the host named – autodiscover.o365info.com and that this host should be able to start an HTTPS session by presenting his public certificate.
In reality, the host whom the Autodiscover client address is the autodiscover.outlook.com that was created just for serving as a logical router, which will redirect the Autodiscover client to the next hop.
The purpose of this “Office 365 components” (autodiscover.outlook.com) is just to send a “routing message” to the Autodiscover client.
The Autodiscover client is “programed” to use and HTTP redirect a request in case that the Potential Autodiscover Endpoint cannot communicate using HTTPS.
In our example, because the Potential Autodiscover Endpoint cannot communicate using HTTPS, the Autodiscover client will “draw back” and try to communicate with the Autodiscover Endpoint using the HTTP protocol, trying to ask from the Autodiscover Endpoint a redirection that includes the address of “other Autodiscover Endpoint”.
Step 4/20: Analyzing the data from the ExRCA connectivity test
In the ExRCA result page, we can see that the HTTPS communication test with the “destination Autodiscover Endpoint” (autodiscover.outlook.com) fails.
Testing TCP port 443 on host autodiscover.o365info.com to ensure it’s listening and open. The specified port is either blocked, not listening, or not producing the expected response. A network error occurred while communicating with the remote host.
Step 5/20: Attempting to contact the Autodiscover service using the HTTP redirect method.
Because the destination host did not respond to the HTTPS communication request, the Autodiscover client tries additional Autodiscover query method that described as –
HTTP redirect request.
The Autodiscover client check of the destination host is listed to communication through HTTP (Port 80).
In our scenario, the destination host answers to the HTTP communication request.
The “positive” response from the destination host is “telling” to the Autodiscover client that this is probably an element that can help him by providing the name of an additional host who serves as Autodiscover Endpoint.
In the next step, we will see how the Autodiscover client will send an HTTP query that includes a request for an “alternate host name and URL” that can provide the required Autodiscover services.
Step 5/20: Analyzing the data from the ExRCA connectivity test
In the ExRCA result page, we can see the following information about the Attempting to contact the Autodiscover service using the HTTP redirect method:
The Autodiscover service was successfully contacted using the HTTP redirect method.
Step 6/20: checking the host autodiscover.o365info.com for an HTTP redirect to the Autodiscover service.
As mention before, the host – autodiscover.outlook.com serve as a “logic router” that, redirect Autodiscover clients in an Office 365 environment to the “next hop” in the Autodiscover flow.
The Autodiscover client sends an HTTP redirection request and the Autodiscover Endpoint (autodiscover.outlook.com) respond with and answer that includes the Autodiscover URL of the “destination host”.
In our scenario, the HTTP redirection response includes the following URL address – https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml
Step 6/20: Analyzing the data from the ExRCA connectivity test
On the ExRCA result page, we can see the following information
The redirect (HTTP 301/302) response was received successfully. Redirect URL: https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml
We will continue to review of the Autodiscover flow in an Office 365 based environment in the next article – Autodiscover flow in an Office 365 environment | Part 3#3 | Part 31#36
This Post Has 2 Comments
Anyone with info please answer.. Why and again why!! Did they configure the autodiscovery to always check for a autodiscovery.xml on the domain site and not first check the autodiscovery.domain.com dns post?
Amazing article, I found the explanations very useful. It allows to understand this complex mechanism of the autodiscover step by step in O365 and compare down with on-prem.