Autodiscover flow in an office 365 environment part 2#3 part 30#36

of 20 | Autodiscover flow in an Office 365 environment | Part 2#3 | Part 30#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
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

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.

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, 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 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
doesn’t appear in the ExRCA report.
In this scenario, I added my descriptionexplanation 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).

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 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: 104.28.12.85, 104.28.13.85
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 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”
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 – 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).
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

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

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

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

Autodiscover flow in an office 365 environment part 2#3 part 30#36

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (16)

Más de Eyal Doron

Más de Eyal Doron (20)

Último

Último (20)

Autodiscover flow in an office 365 environment part 2#3 part 30#36