Seven major Autodiscover flow scenarios | Part 25#36 5/5 (2) 15 min read

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 examination that deals with each of the specific steps and process that are involved.

Article Series Table of content | Click to expand

Exchange and Autodiscover infrastructure | Article Series

Exchange Autodiscover – Article series – INDEX

Exchange and Autodiscover infrastructure | The building blocks

Autodiscover infrastructure | FQDN and URL address

Exchange Autodiscover flow in different environments

Autodiscover infrastructure | Exchange infrastructure and namespace convention

Exchange, Autodiscover and security infrastructure

Autodiscover Troubleshooting tools

Autodiscover major flow scenarios

Autodiscover flow in an Exchange on-Premises environment | non-Active Directory environment

Autodiscover flow in an Office 365 based environment

Autodiscover flow in an Exchange Hybrid environment

Exchange Stage migration and Autodiscover infrastructure

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, it’s important that we will be able to get a “view from above” of the different Autodiscover flows and their main characters.

View from above about the different Autodiscover flows

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 based on the ability of the Autodiscover client to.

  • Locate a Potential Autodiscover Endpoint.
  • Address this Potential Autodiscover Endpoint.
  • 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.

Relate to the two first parts of the Autodiscover process

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

The Autodiscover purpose - Find your destination

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.

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

Can not find my Autodiscover Endpoint
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 particular 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 which has the CAS role registered himself automatically in SCP of the On-Premise Active Directory (other optional scenarios is a scene 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 needs to use in dealing with 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 1- Active Directory environment - Single Exchange On-Premise 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 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 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 which has the same value of the Autodiscover site name as he.

Scenario 2- Active Directory environment - Multiple Exchange On-Premise servers

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 underlying assumption is that the required DNS record was already created and updated in a public DNS server who is available for a client located on a public network.

The additional significant difference is the need for “public availability” of the Exchange server who supposed to serve external Exchange clients.

The Exchange server will need to configure 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 3 - Autodiscover client - External network access

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 located on the public network or client located on the private\internal organization’s 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).

Scenario 4 - Exchange Online infrastructure - Cloud only - External mail client

The Autodiscover client will try to look for information about the Autodiscover Endpoint by addressing public DNS server and ask him about a particular Autodiscover host name.
The underlying 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 necessary IP (the IP that 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 organization’s network and needs to connect to his Exchange Online mailbox.

In our particular scenario, the organization doesn’t use Exchange On-Premise infrastructure.

When a user’s desktop is configured as “domain joined” and the users (and his desktop) located on the internal\private network, Autodiscover client such as Outlook “programme” 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 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 located on the internal\private network, Autodiscover client will try to connect to the local DNS server.

The underlying 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 necessary IP address, he will try to connect the “cloud Autodiscover Endpoint”.

Scenario 5- Exchange Online infrastructure - Cloud only - Internal mail client

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 located on the internal organization’s network doesn’t 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 organization’s internal network.

Although the “final node” located outside of the organization’s network and the logical assumption is that the Autodiscover client will directly access the “cloud Autodiscover Endpoint” the reality is different.

When a user’s desktop is configured as “domain joined” and the users (and his desktop) 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 registered in the cloud (Exchange Online infrastructure), the Exchange on-Premises 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 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 located on the internal\private network, the client will try to connect to the local DNS server.

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

Scenario 6 - Internal Network client - Exchange on-Premises infrastructure - Exchange Online mailbox

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 organization’s user wishes to connect to his mailbox, but his mailbox 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. When the user tries to connect to his mailbox that physically located in the “cloud” (Exchange Online), Exchange On-Premise is reasonable for “redirecting” the recipient to his cloud mailbox.
The redirection implemented by providing the recipient the additional E-mail address that he has that use the shared space domain name that employed 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.

In case that the user mailbox located on the Exchange On-Premise, the Autodiscover process (and all the rest of the Autodiscover process) is implemented exactly like any standard Exchange On-Premise client\server scenario.

In case that the client mailbox located in the “cloud” (Exchange Online), the Autodiscover process is very different.

The Autodiscover client will start the process by addressing the local Exchange On-Premise server, but the Autodiscover client will be “redirected” or “pointed” to his E-mail address in the cloud (Exchange Online) and from that point, the Autodiscover process 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 implemented in a Hybrid environment, let’s 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

Bob’s mailbox is located in the “cloud” (Exchange Online). The technical term is “remote mailbox”.

Bob’s mailbox was “moved” to the cloud mail infrastructure (Exchange Online) and the Exchange On-Premise server, relate to Bob’s 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:

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

Scenario 7 - Hybrid configuration - Part 1 of 4

Step 3 – the Autodiscover client (Bob) will try to communicate with the ex01.o365info.local Exchange CAS server assuming that this is “his Exchange CAS server”.

Step 4 – the Exchange On-Premise server looks for Bob’s mailbox and “see” that bob’s mailbox configured as a “Remote mailbox”.
Exchange servers look for a value stored in a recipient’s 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

Scenario 7 - Hybrid configuration - Part 2 of 4

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 doesn’t 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 presents the Exchange Online services).

Scenario 7 - Hybrid configuration - Part 3 of 4

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

Scenario 7 - Hybrid configuration - Part 4 of 4

Now it’s Your Turn!
It is important for us to know your opinion on this article


Print Friendly, PDF & Email

Related Post

Please rate this

Eyal Doron on EmailEyal Doron on FacebookEyal Doron on GoogleEyal Doron on LinkedinEyal Doron on PinterestEyal Doron on RssEyal Doron on TwitterEyal Doron on WordpressEyal Doron on Youtube
Eyal Doron
Share your knowledge.
It’s a way to achieve immortality.
Dalai Lama

Leave a Reply

Your email address will not be published. Required fields are marked *