Page 1 of 16 | Seven major Autodiscover flow scenarios | Part 25#36

Seven major Autodiscover flow

scenarios | Part 25#36

In the following article, we will review seven major common Autodiscover flow in a
different environment.
The review, is a high-level review and not a detailed review that deals with each of
the specific steps and process that are involved.
The purpose in the continuation of the current series of articles, article 29 until 34,
we will get into the very specific details of Autodiscover flow by using different tools
such as ExRCA, Outlook connectivity test and more.
Before we dive into the details, its important that we will be able to get a view
from above of the different Autodiscover flows and their main characters.

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

Page 2 of 16 | Seven major Autodiscover flow scenarios | Part 25#36

The basic logic of the Autodiscover flow

Autodiscover mechanism includes three major parts:
1. Locating the Autodiscover Endpoint
2. Getting the required Autodiscover information
3. Using the Autodiscover information
In the current article, we relate to the two first parts:
1. Locating the Autodiscover Endpoint
2. Getting the Autodiscover information \ data.
The Autodiscover flow is based on the ability of the Autodiscover client to.

Locate a Potential Autodiscover Endpoint.

Address this Potential Autodiscover Endpoint.

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

Page 3 of 16 | Seven major Autodiscover flow scenarios | Part 25#36

Complete all, if the required steps that involved in the Autodiscover process
such as mutual authentication and more.
Get from the Autodiscover Endpoint the required Autodiscover information.

Autodiscover as all about the path that the Autodiscover client (Point A) need to
pass for getting to point B (Autodiscover Endpoint).

When we deal with a troubleshooting process that relates to Autodiscover, the first
thing that we need to do is get a clear understanding about the Autodiscover
path.

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

Page 4 of 16 | Seven major Autodiscover flow scenarios | Part 25#36

Additionally, we will need to know what is the role of each component that is
involved in the Autodiscover path and verify that each of the involved components
configured correctly with the require settings.

Only after we know what is the Autodiscover path that the Autodiscover client was
supposed to pass through and what are the components or the nodes that are
involved in this process, we will be able to pinpoint the specific cause of the
problem or start the elimination process of the different components that are
involved in the Autodiscover flow.

Autodiscover flow involved components and charters.

In the following section, we will review seven different scenarios of Autodiscover
flow and point the specific charters of each scenario.

Scenario 1: Active Directory environment | Single Exchange On Premise server

The Exchange On-Premise server who has the CAS role registered himself
automatically in SCP of the On-Premise Active Directory (other optional scenarios is
a scenario in which we are registering the Exchange CAS server in the Active
Directory SCP by using a different host name).
Autodiscover client that needs to find the Autodiscover Endpoint (Exchange server),
address the Active Directory using LDAP query and ask for the specific URL that he

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

Page 5 of 16 | Seven major Autodiscover flow scenarios | Part 25#36

needs to use in addressing the required Autodiscover Endpoint (the Autodiscover

URL that will lead him to the internal Exchange CAS server).
Active Directory answer the Autodiscover client query and send him the required
Autodiscover URL address.
The Autodiscover client addresses the Exchange CAS server by using the URL
address that he got.
Note technically, there is an additional component that is involved in this scenario
such as -the local DNS server.

Scenario 2: Active Directory environment | Multiple Exchange

On-Premise servers
This scenario is still related to the Autodiscover process in a local or a private
organization network.
The process of finding the required Autodiscover Endpoint is based on the ability of
the client to query the local Active Directory and get a list of available Autodiscover
Endpoint (On-Premise Exchange CAS server\s).
When the Active Directory reply with a list of available Autodiscover Endpoints, the
Autodiscover client will need to choose the Autodiscover Endpoint from the list
Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 6 of 16 | Seven major Autodiscover flow scenarios | Part 25#36

randomly or, by using a process that described as Site Affinity.

The term Site Affinity describes a process in which the Autodiscover client will
prefer to address Exchange server who has the same value of the Autodiscover site
name as he.

Scenario 3: Autodiscover client | External network access

In the following scenario, an external mail client, need access to his organization
mailbox and to get the required access he will need to locate and connect a Public
facing Exchange CAS server.
The Autodiscover client cannot use an LDAP query, because the organization Active
Directory server are not exposed to host from the public network.
For this reason, Autodiscover client will need to query a Public DNS server looking
for an optional host who provided Autodiscover services (Autodiscover Endpoint).
The basic assumption is that the required DNS record was already created and
updated in a public DNS server who is available for client located on a public
network.
Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 7 of 16 | Seven major Autodiscover flow scenarios | Part 25#36

Additional major difference is the need for public availability of the Exchange
server who supposed to serve external Exchange clients.
The Exchange server will need to be configured with public name, public IP and
public certificate.
The organization Firewall or Proxy server will need to be configured with the
required setting that will enable external clients to access to the Exchange server
who serve as an Autodiscover Endpoint for external clients.

Scenario 4: Exchange Online infrastructure | Cloud only |

External mail client
This is a classic Office 365 cloud scenario.
In this scenario, the organization mail infrastructure is not hosted internally or
On-Premise but instead, the organization mail infrastructure is based on Office 365
subscription and by using the Exchange Online infrastructure as mail services.
The access to the cloud mail infrastructure can be implemented by mail clients
that are located on the public network or client located on the private\internal
organizations network.
In the following diagram, we can see a description of the Autodiscover flow for a
mail client, that located in a public network and look for an Autodiscover Endpoint
that is located in the cloud (Exchange Online).

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

Page 8 of 16 | Seven major Autodiscover flow scenarios | Part 25#36

The Autodiscover client will try to look for information about the Autodiscover
Endpoint by addressing public DNS server and ask him about a specific
Autodiscover host name.
The basic assumption is that the required DNS record that will point the client to
the cloud Autodiscover Endpoint has already been configured.
After the Autodiscover client gets the required IP (the IP that is mapped to the cloud
Autodiscover Endpoint), that Autodiscover client will try to connect the cloud
Autodiscover Endpoint.
Note the provided diagram simplifies the real process just to enable us to get a
general understanding about the Autodiscover flow logic.
In reality, the process is a little more complicated because in the Office 365
environment, the Autodiscover client will be redirected to additional Autodiscover
Endpoint until he reaches his required destination.

Scenario 5: Exchange Online infrastructure | Cloud only |

Internal mail client
The following scenario, is similar to the former scenario, but with one main
difference- the mail client (the Autodiscover client) is located inside the
organizations network and needs to connect to his Exchange Online mailbox.

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

Page 9 of 16 | Seven major Autodiscover flow scenarios | Part 25#36

In our specific scenario, the organization doesnt use Exchange On-Premise

infrastructure.
When a users desktop is configured as domain joined and the users (and his
desktop) are located on the internal\private network, Autodiscover client such as
Outlook is programed to start the search for the required Autodiscover Endpoint
by connecting the local On-Premise Active Directory using an LDAP query.
Because there is no Exchange On-Premise infrastructure, there is no information
in the On-Premise Active Directory and the On-Premise Active Directory cannot
provide answer to the Autodiscover client.
In this case, the client will start to use the second Autodiscover method which is
based on a DNS query looking for the Autodiscover Endpoint IP address (the client
know what the name of the Autodiscover Endpoint is).
Because the Autodiscover client is located on the internal\private network,
Autodiscover client will try to connect to the local DNS server.
The basic assumption is that the local DNS the server has access to the public
network, and that he can fetch for the Autodiscover client the required IP address
of the cloud Autodiscover Endpoint.
When the internal Autodiscover client gets the required IP address, he will try to
connect the cloud Autodiscover Endpoint.

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

Page 10 of 16 | Seven major Autodiscover flow scenarios | Part 25#36

Scenario 6: Internal Network client | Exchange on-Premises

infrastructure | Exchange Online mailbox
A more complicated cloud scenario is a scenario, in which
A client has an Exchange Online mailbox
The mail client is located on an internal\private network
The organization uses Exchange On-Premise infrastructure
In our scenario, the mail client that is located on the internal organizations
network, doesnt wish to connect to the Exchange On-Premise mailbox but
instead, he wishes to connect to an Exchange Online mailbox that is located
outside of the organizations internal network.

Although the final node is located outside of the organizations network and the
logical assumption is that the Autodiscover client will directly access the cloud
Autodiscover Endpoint the reality is different.

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

Page 11 of 16 | Seven major Autodiscover flow scenarios | Part 25#36

When a users desktop is configured as domain joined and the users (and his
desktop) are located on the internal\private network, Autodiscover client such as
Outlook or programed to start the search for the required Autodiscover Endpoint
by connecting the local On-Premise Active Directory using an LDAP query.
Active Directory answer the Autodiscover client query and send him the required
Autodiscover URL address.
The Autodiscover client addresses the Exchange CAS server by using the URL
address that he got.
Because the Exchange on-Premises server are not responsible for the domain
that is registered in the cloud (Exchange Online infrastructure), the Exchange onPremises server reply with a negative response.
The Autodiscover client understand that now he needs to use additional
Autodiscover method.
In this case, the client will start to use the second Autodiscover method, which is
based on a DNS query looking for the Autodiscover Endpoint IP address (the client
know what the name of the Autodiscover Endpoint is).
Because the Autodiscover client is located on the internal\private network, the
client will try to connect to the local DNS server.
The basic assumption is that the local DNS the server has access to the public
network, and that he can fetch for the client the required IP address of the cloud
Autodiscover Endpoint
When the internal client gets the required IP address, he will try to connect the
cloud Autodiscover Endpoint

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

Page 12 of 16 | Seven major Autodiscover flow scenarios | Part 25#36

Scenario 7: Hybrid configuration

The Autodiscover process in a hybrid environment could be described as
complicated because, the way that the Autodiscover client finds his required
Autodiscover Endpoint.
In our scenario, an organizations user wishes to connect to his mailbox but his
mailbox was migrated to the cloud (Exchange Online).
The Exchange On-Premise severs see the user migrated mailbox as a remote
mailbox.
Technically, the Exchange On-Premise is the owner of the user mailbox but when
the user tries to connect to his mailbox that is physically located in the cloud
(Exchange Online), Exchange On-Premise is reasonable for redirecting the
recipient to his cloud mailbox, by providing the recipient the additional E-mail
address that he has that use the shared space domain name that is used in Hybrid
environment <organization name>.mail.onmicrosoft.com
The concept of Hybrid environment is based on a logical structure in which the
On-Premise infrastructure serves as a focal point or a starting point for
Exchange clients.
Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 13 of 16 | Seven major Autodiscover flow scenarios | Part 25#36

In case that the user mailbox is located on the Exchange On-Premise, the
Autodiscover process (and all the rest of the Autodiscover process) is implemented
exactly as any standard Exchange On-Premise client\server scenario.
In case that the client mailbox is located in the cloud (Exchange Online), the
Autodiscover process is very different.
The Autodiscover client will start the process by addressing the local Exchange OnPremise server, but the Autodiscover client will be redirected or pointed to his Email address in the cloud (Exchange Online) and from that point, the Autodiscover
process is implemented like a standard cloud Autodiscover process, in which the
Autodiscover client tries to locate and connect his cloud Autodiscover Endpoint.
To demonstrate the Autodiscover path that is implemented in a Hybrid
environment, lets use the following scenario.
The local On-Premise Active Directory domain name is o365info.local
The Public organization domain name is o365info.com
The Office 365 Hybrid domain name is mail.o365info.com
User\recipient E-mail address Bob@o365info.com
Bobs mailbox is located in the cloud (Exchange Online). The technical term is
remote mailbox.

Bobs mailbox was moved to the cloud mail infrastructure (Exchange Online) and
the Exchange On-Premise server, relate to Bobs mailbox as remote mailbox.
The object of Remote mailbox serves as a pointer to the Bob cloud mailbox.
The task- Bob would like to configure a new Outlook mail profile that will enable
him to connect to his cloud mailbox.
Step 1 Outlook connects the local Active Directory and asks for a list of potential
Autodiscover Endpoint (Exchange CAS server\s).
Step 2 Active Directory reply with a list of available Exchange server\s
(Autodiscover Endpoint).
In our example, the Active Directory provides to the client the following URL
Address:

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

Page 14 of 16 | Seven major Autodiscover flow scenarios | Part 25#36

Https://ex01.o365info.local/Autodiscover/Autodiscover.xml
Note technically there is an additional step in which the Outlook connects the
local DNS server looking for the IP address of the host ex01.o365info.local
In our example, we assume that this step complete successfully and that Outlook
know how to reach the internal Autodiscover Endpoint (ex01.o365info.local).

Step 3 the Autodiscover client (Bob) will try to communicate with

the ex01.o365info.localExchange CAS server assuming that this is his Exchange CAS
server.
Step 4 the Exchange On-Premise server looks for Bobs mailbox and see that
bobs mailbox configured as a Remote mailbox.
Exchange servers look for a value stored in a recipients property named
Routing Email address and, see that the cloud (Exchange Online) E-mail address
of Bob is Bob@o365info.mail.onmicrosoft.com
Exchange server inform Bob that he should use a new E-mail address
Bob@o365info.com

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

Page 15 of 16 | Seven major Autodiscover flow scenarios | Part 25#36

Step 5 Outlook clients access the local DNS server and ask for the IP address of
the remote Autodiscover Endpoint. Outlook will first try to get the IP address of
the Root domain name (in our example o365info.mail.onmicrosoft.com) and if the
DNS doesnt include the required IP, Outlook will try to look for the following name
convention Autodiscover.<SMTP domain name>
(in our example Autodiscover.o365info.mail.onmicrosoft.com).
Step 6 The Local DNS access his resources and find for his Autodiscover client
the required IP address.
(The Public IP address that is mapped to the Autodiscover Endpoint that resents
the Exchange Online services).

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

Page 16 of 16 | Seven major Autodiscover flow scenarios | Part 25#36

Step 7 Outlook will try to check if the remote Autodiscover Endpoint listens or
open using port 443 and if the answer is Yes, Outlook will send a requires for the
required Autodiscover.xml file.
Note and as usual, this workflow description is just a very general description.
In reality, the first cloud Autodiscover Endpoint is just a logic black box that will
reply to the Outlook request with an HTTP redirection.

Outlook client will try to request the Autodiscover.xml from the additional
Autodiscover Endpoint, will be redirected again until he reaches the final
Autodiscover Endpoint.

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