Seven major Autodiscover flow scenarios | Part 25#36

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

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

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, it’s important that we will be able to get a “view

from above” of the different Autodiscover flows and their main characters.

http://o365info.com/seven-major-autodiscover-flow-scenarios-part-25-of-36

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

http://o365info.com/



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.






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.






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






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






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.






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

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






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

organization’s network and needs to connect to his Exchange Online mailbox.






In our specific 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) 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”.






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 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” is 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) 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 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 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”






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






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

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

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

Exchange server “inform” Bob that he should use a “new E-mail address”

– [email protected]






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 resents

the Exchange Online services).






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




Documents

Seven major Autodiscover flow scenarios | Part 25#36