Page 1 of 20 | Autodiscover flow in an Office 365 environment | Part 2#3 | Part 30#36

Autodiscover flow in an Office 365

environment | Part 2#3 | Part 30#36

The current article and the next article, will be dedicated for detailed review of the
Autodiscover flow, that is 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 environment | The

article series
The current article is the second article in a series of three articles.
The additional articles in the series are:

Autodiscover flow in an Office 365 environment | Part 1#3 | Part 29#36

Autodiscover flow in an Office 365 environment | Part 3#3 | Part 31#36

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 2 of 20 | Autodiscover flow in an Office 365 environment | Part 2#3 | Part 30#36

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:
1. The Autodiscover process is a very smart and intelligent mechanism, which
manages to survive in a complex and complicated environment.

2. There are many moving parts and many passable paths for the Autodiscover
journey.

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 3 of 20 | Autodiscover flow in an Office 365 environment | Part 2#3 | Part 30#36

3. 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 successfully complete the Autodiscover journey
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, lets 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 detailed way the steps that are 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
doesnt 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.

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 4 of 20 | Autodiscover flow in an Office 365 environment | Part 2#3 | Part 30#36

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.

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 5 of 20 | Autodiscover flow in an Office 365 environment | Part 2#3 | Part 30#36

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).

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 6 of 20 | Autodiscover flow in an Office 365 environment | Part 2#3 | Part 30#36

Scenario description
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 users 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

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 7 of 20 | Autodiscover flow in an Office 365 environment | Part 2#3 | Part 30#36

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.

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 8 of 20 | Autodiscover flow in an Office 365 environment | Part 2#3 | Part 30#36

In the following screenshots, we can see the results of the Outlook Autodiscover
process for bobs 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).

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 9 of 20 | Autodiscover flow in an Office 365 environment | Part 2#3 | Part 30#36

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).

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 10 of 20 | Autodiscover flow in an Office 365 environment | Part 2#3 | Part 30#36

When the Autodiscover client reaches the Office 365 elements namedAutodiscover-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

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 11 of 20 | Autodiscover flow in an Office 365 environment | Part 2#3 | Part 30#36

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 servers
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, doesnt 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.

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 12 of 20 | Autodiscover flow in an Office 365 environment | Part 2#3 | Part 30#36

(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: 104.28.12.85, 104.28.13.85

Step 2/20: Testing TCP port 443 on host o365info.com to ensure

its listening and open.
The Autodiscover client addresses the potential Autodiscover Endpoint, using the IP
address that he got in the former 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
doesnt support HTTPS communication.

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 13 of 20 | Autodiscover flow in an Office 365 environment | Part 2#3 | Part 30#36

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>

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 14 of 20 | Autodiscover flow in an Office 365 environment | Part 2#3 | Part 30#36

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 157.56.236.89,
157.56.232.9, 157.56.234.137, 157.56.244.217.
(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: 157.56.236.89,
157.56.234.137, 157.56.232.9, 157.56.244.217

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 15 of 20 | Autodiscover flow in an Office 365 environment | Part 2#3 | Part 30#36

Step 4/20: Testing TCP port 443 on host

autodiscover.o365info.com to ensure its 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.

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 16 of 20 | Autodiscover flow in an Office 365 environment | Part 2#3 | Part 30#36

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 its 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

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 17 of 20 | Autodiscover flow in an Office 365 environment | Part 2#3 | Part 30#36

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.

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 18 of 20 | Autodiscover flow in an Office 365 environment | Part 2#3 | Part 30#36

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

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 19 of 20 | Autodiscover flow in an Office 365 environment | Part 2#3 | Part 30#36

Step 6/20: Analyzing the data from the ExRCA connectivity test
On the ExRCA result page, we can see the following informationThe redirect (HTTP 301/302) response was received successfully. Redirect URL:
https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml

Additional reading

Office 365 Autodiscover Lookup Process

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
Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 20 of 20 | Autodiscover flow in an Office 365 environment | Part 2#3 | Part 30#36

Written by Eyal Doron | o365info.com | Copyright 2012-2015