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

http://o365info.com/autodiscover-flow-in-an-office-365-environment-part-2-of-3-part-30-of-36

https://il.linkedin.com/in/eyaldoron1

http://o365info.com/






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






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 –

[email protected], 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 – [email protected]

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 – [email protected]

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




http://blogs.technet.com/b/rmilne/archive/2015/04/29/office-365-autodiscover-lookup-process.aspx



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

Documents

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