Autodiscover flow in an exchange on premises environment non-active directory environment part 1#3 part 26#36

of 23 | Autodiscover flow in an Exchange on-Premises environment | non-Active
Directory environment| Part 1#3 | Part 26#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
Autodiscover flow in an Exchange on-
Premises environment | non-Active
Directory environment| Part 1#3 | Part
26#36
The Autodiscover protocol for discovering the Autodiscover Endpoint is a very
smart protocol, which was designed to get the required results in a different
environment such as Active Directory-based environment and a “non-Active
Directory environment”.
In a “non-Active Directory environment”, the Autodiscover client has an arsenal of
methods and tools, which can help him to find his Autodiscover Endpoint.

Autodiscover flow in an Exchange on-Premises environment |
non-Active Directory environment | The article series
The current article is the first article on a series of three articles.
The main focus of the first article is -presenting the logic and, the involved
components in the Autodiscover flow that is implemented in Exchange on-Premises
environment.
In the next two articles, we will review the Autodiscover flow that is implemented in
Exchange on-Premises environment, by using the Microsoft web-based tool, the
Microsoft Remote Connectivity Analyzer (ExRCA).
 Autodiscover flow in an Exchange on-Premises environment | non-Active
 Autodiscover flow in an Exchange on-Premises environment | non-Active

Locating the Autodiscover Endpoint host | Active
Directory versus none- Active Directory environment
Before we get into the details of the Autodiscover process that is implemented in a
non-Active Directory environment, it’s important to understand the major
difference of the Autodiscover method that is performed on each of these
environments.
In an Active Directory environment, the Autodiscover client doesn’t know the name
of the Autodiscover Endpoint and instead, relate to the Active Directory as a trusted
source of infrastructure that can provide him the “names” of available Autodiscover
Endpoints (Exchange CAS servers).
In a non-Active Directory environment, the “missing part” is the Active Directory.
Instead of addressing the Active Directory for information about the names of the
Autodiscover Endpoint, the Autodiscover client will need to use another method.
The Autodiscover method that is used by the Autodiscover client is based on a
following flow:
1. The Autodiscover Endpoint “guess” or “generate” the URL address of a potential
Autodiscover Endpoint based on the SMTP domain that he gets from the recipient
E-mail address.
2. In case that the Autodiscover client manage to locate and communicate with the
“Potential Autodiscover Endpoint” but the “destination host” cannot provide him the
required information, the Autodiscover client will ask for a redirection to another
potential Autodiscover Endpoint.
Note – we use the term “Potential Autodiscover Endpoint” because when the
Autodiscover client addresses a specific host as “Autodiscover Endpoint” he
assumes that the destination host is an Autodiscover Endpoint, but he cannot be
sure of the destination host is indeed Autodiscover Endpoint.
3. In case that the potential Autodiscover Endpoint from “step 1” could not provide
the required Autodiscover information + couldn’t provide a redirection to a

potential Autodiscover Endpoint, the Autodiscover client will try to query the DNS
looking for SRV record that will include the host name of a potential Autodiscover
Endpoint.
Pay attention to the fact the in a non-Active Directory environment, the
Autodiscover client can consider as “blind client” because, there is no “formal
source of information” that can provide him the specific host name (the URL if we
want to be more accurate”) of the potential Autodiscover Endpoint.

The possible scenario in which Autodiscover client
cannot use the Active Directory Autodiscover method.
The four possible scenarios in which client cannot use the Autodiscover method
that is based on an LDAP query and On-Premises Active Directory are:
1. The desktop is not a Domain joined
As the name implies, this scenario can relate to one of the following options:
 A user’s desktop that is not configured as a domain member (domain joined)
 A user’s desktop that is configured as a domain member (domain joined) but the
user login locally to his desktop and not to the “Domain profile”.
2. The desktop is a Domain joined but, there is no option to communicate
with Active Directory
An example could be a user whom his notebook, consider as a Domain joined, but
the organization user is working from home or a public network.

In that case, despite the fact that the desktop is a “Domain joined”, the
communication attempt to the Active Directory will fail because by default, the
Active Directory considers as protected or internal resources, and it’s not exposed
to access by the host from the public network.
3. The desktop is a Domain joined, there is an option to communicate with
Active Directory but the SMTP Domain that the client look for doesn’t
“belong” to the Exchange on-Premises server (the Exchange is not
authoritative for the specific domain name).
Whoa!! This is a very long name for a scenario title!
An example of this scenario could be a user who wants to create a new Outlook
mail profile using a recipient E-mail address.
The SMTP domain part of the recipient E-mail address doesn’t “belong” to the
organization Domains (Domain that Exchange sees himself as authoritative for
them).
In that situation, although the domain is not part of the local Exchange
infrastructure, the Autodiscover client will request a list of available Exchange CAS
server from the Active Directory and try to communicate with each of the Exchange
CAS servers in the list looking for the required Autodiscover information.
Only after the Autodiscover client exhausts all the possible “internal Autodiscover
Endpoints”, the Autodiscover client will “surrendered” and start to use an additional
Autodiscover method.
4. An Exchange on-Premises server is not available.
The charters of this scenario are:
 The user desktop is a Domain joined.
 The Autodiscover client manages to query the local Active Directory and gets a
list of potential Autodiscover Endpoints.
 The Autodiscover client tries to communicate the Autodiscover Endpoint
(Exchange CAS server) but the Exchange CAS server is not available (not
responding, etc.).

In this case, the Autodiscover client will “surrendered” and start to use an additional
Autodiscover method.
The journey for the Lost Treasure- Autodiscover.xml file
To simplify the concept of Autodiscover process, let’s use the following metaphor:
The process of Autodiscover is very similar to a “the search for the lost treasure”.
We heard from someone, about very precious treasure.
We want this treasure very much, and we know that “somewhere” there is a person
that holds this precious treasure.
All we need is a “map” that could lead us to the person that hold our precious
treasure!

Let’s return to the “real world” and try to understand what process each of this
Imaginary figure represent.
1. The “searcher”
The “searcher” could be any Autodiscover client. In our scenario, the Autodiscover
client is Outlook that needs configuration setting for creating a new Outlook mail
profile.
2. The lost treasure – Autodiscover information
The assent of “Autodiscover journey” is very simple – find the Autodiscover
information (the lost treasure).

3. The “source”
The “element” that holds our precious treasure is the Exchange CAS server or if we
want to use the formal term – potential Autodiscover Endpoint.
Technically speaking, we use the term “potential” because, in reality, when the
Autodiscover client addresses a specific host he doesn’t know if the host (the
potential Autodiscover Endpoint) replies to his communication request or, in case
that the host reply, we cannot be sure that the specific host is the “right one”.
For this reason, we use the term “potential” because the host the Autodiscover
client address has the potential to be the “right Autodiscover Endpoint” but, at the
same time, the Autodiscover client will need to know how to deal with a scenario in
which the host is not the “right Autodiscover Endpoint”.

4. The “Map”
In our story, the “map” should lead us to the person that hold our desirable
treasure.
In the Autodiscover world, the “map” is implemented as a web address (URL).
If we want to be more precise, the client (Outlook) has already most of the map, the
only missing part in the “map” is the name of the Autodiscover Endpoint who “hold”
the information (hold our precious treasure).
Autodiscover URL (the map to the lost treasure)

Continuing our metaphor, the” map” (the address) to the lost treasure, aka the
Autodiscover information is implemented by using a URL address.
Let’s look at the structure of the Autodiscover URL address, so we can understand
better the Autodiscover method that is used by the Autodiscover client in a non-
Active Directory environment.
The Autodiscover URL address, includes the following parts:
 The protocol name (HTTPS or HTTP)
 The host name of the Autodiscover Endpoint
 The path that includes the name of the folder (Autodiscover) and the name of
the required file (autodiscover.xml or autodiscover.svc)
Autodiscover client knows what is the URL address structure that he should use for
addressing the Autodiscover Endpoint.
The default communication protocol is HTTPS (another option is HTTP in a scenario
of a redirection requests).
Note that the name of the FQDN of the Autodiscover Endpoint is not known to the
Autodiscover client!
In the next section, we will learn how the Autodiscover client solves this problem,
but it’s important to emphasize that in a non-Active Directory environment the
Autodiscover client cannot know “in advance” the host name if the Autodiscover
Endpoint.
The default path of the Autodiscover URL is based on the following naming
convention.
<Folder name><File name>
The default path of Autodiscover services is:
/Autodiscover/autodiscover.xml

In the following diagram, we can see the presentation of the “well know the
Autodiscover URL address” concept.
The Autodiscover client, “knows” most of the “parts” of the Autodiscover URL
address.
The only “missing part” is the host name of the Autodiscover Endpoint.

The great mystery revealed! Generating the
Autodiscover Endpoint host name
When an Autodiscover client uses the “Active Directory Autodiscover method”, the
Autodiscover client, trust or relies on the Active Directory as a source for
information about the available Autodiscover Endpoint.
But in case that the Autodiscover client cannot use the Active Directory as a “source
for information”, how can the Autodiscover client know what the name of
Autodiscover Endpoint is? Is there more than one potential Autodiscover Endpoint?

I’m excited!
Today we are going to reveal the big secret which only a few people in the whole
world know!
The way that the Autodiscover client use for “finding” the host name of the
Autodiscover Endpoint is maybe not the “big secret which only a few people in the

whole world know!” however, it’s still an interesting process that some of us are not
familiar with.
 The mission is – creating a new Outlook mail profile.
 The agent name is – Bob
 The location – Bob is located on a public network and for this reason, he
cannot access the organization Active Directory.
 The obstacles – how to find the Exchange CAS server (the Autodiscover
Endpoint) that will enable Bob to connect to his mailbox + provides all the
required information for creating the Outlook Anywhere mail profile.

The secret method which the Autodiscover client use is based on a little trick.
As mentioned before, the URL address of the Autodiscover Endpoint is based on a
predefined naming convention.
For the Autodiscover client which needs to find his Autodiscover Endpoint, the only
missing part is the host name of the Autodiscover Endpoint.
The trick that the Autodiscover client use is based on the E-mail address of the
recipient. Every standard E-mail address is consisted of two parts:
1. The “left part” this is the recipient alias or the recipient name.
2. The “Left part”, this part represents the domain name or the SMTP domain
name of the organization of the company that the user belongs to.
Autodiscover clients know how to use the “right part” of the E-mail address by
“taking” the SMTP domain name and is it for “Fill in the missing part of the puzzle”.
In our scenario, when Bob starts the Outlook wizard, Bob will have to provide his E-
mail address – Bob@o365info.com
The Autodiscover client (Outlook), take the domain name form the E-mail address
and “put the name” in the Autodiscover URL.

In our example, Outlook will start the journey by connecting DNS server and ask for
the IP address of the host named – o365info.com
In case that the DNS server can provide an IP address, Outlook (Autodiscover client)
will relate to the host as a potential Autodiscover Endpoint.
The basic Outlook assumption is that this host – o365info.com is a potential
Autodiscover Endpoint meaning an Exchange CAS server or element that can
provide him the required Autodiscover information for creating the Outlook
Anywhere mail profile.

Most of the time, the method in which Autodiscover relates to the SMTP domain
name is the host name of the potential Autodiscover Endpoint will not yield the
required results because in a modern environment, the “root domain name” is
usefully mapped to the public company web site.
In now days, we can “reach” most of the public web site without using the formal
naming convention such as – www.<Domain name> but instead, we use only the
domain name.
Let’s assume that in our scenario, Outlook manage to find the IP address of a host
named –o365info.com, but “this host” is not the required Autodiscover Endpoint
(Exchange CAS server) but instead, just a simple website.
In that situation, the Autodiscover client uses an additional naming convention, but
this time; Outlook will try to address the Autodiscover Endpoint by using the
following hostname –autodiscover.o365info.com
The host name – Autodiscover is a preserved name.
Each organization that wants to point Autodiscover clients to their Autodiscover
Endpoint, need to create under the domain name in the DNS zone an A record, that

includes the host name – Autodiscover and mapped to the IP address of the
Exchange CAS server who operate as Autodiscover Endpoint.
Q: Is this is the end of the Autodiscover journey? Can we assume that the story has
a good end?
A: Yes and no

This could be the end of the Autodiscover journey in case that the host –
autodiscover.o365info.com is the “real deal” and this is the “right Exchange CAS
server” that can enable the Outlook to connect to user mailbox + provide all the
required configuration settings for building a new Outlook Anywhere mail profile.
Other passable scenarios is that the host the Outlook considers as a “potential
Autodiscover Endpoint”, is not the host who can “end the process”.
For example, there is an option in which Outlook finds the IP address of a host
named-autodiscover.o365info.com but the “host” doesn’t respond to the HTTPS
request that Outlook sends. (The Autodiscover process is based on the HTTPS
protocol).
In this case Outlook “understand” that this is not the “the last station” in his
Autodiscover journey.
In case that the Autodiscover Endpoint did not respond to the HTTPS
communication request, the Autodiscover client still has “some belief” that the host
can still help him in another way.
HTTP Redirection
Because of the destination, host doesn’t support HTTPS communication, the
Autodiscover client “understand” that this is not the element that can provide him
the require Autodiscover information.
Instead of “give in”, Outlook client will address that host who doesn’t support
HTTPS, and ask him if he knows about a Potential Autodiscover Endpoint.
The Autodiscover Endpoint addresses the host by using HTTP protocol instead of
HTTPS.

In case that the host responds to the HTTP request, the Autodiscover client
assumes that he can ask for help.
The Autodiscover client will try to request from the host, information about the
name if the Autodiscover Endpoint.

So… is this is the end?
The answer is not it!
In case that the host whom the Autodiscover client address doesn’t support HTTP
or cannot provide the name of a potential Autodiscover Endpoint, the Autodiscover
client will use the “last method, he carries his sack”
This Autodiscover method is based on a special DNS record named – SRV record.
The uniqueness of a DNS SRV record is that this type of record enables DNS client
to query DNS about the host name to provide a specific service with Outlook the
need to know the host name. In other words, when using the SRV query, looking for
a specific service, the DNS replay with the host names that provide the specific
service.
In case that the organization publishes in the DNS an SRV record that includes the
host name of the Exchange CAS server (Autodiscover Endpoint) that can provide
Autodiscover services, the Autodiscover client will use the name and relate to the
host as a potential Autodiscover Endpoint.

Note – it’s important to mention that the SRV Autodiscover method is not
supported in Office 365 and Exchange Online environment.

Autodiscover flow in an exchange on premises environment non-active directory environment part 1#3 part 26#36

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (14)

Similar to Autodiscover flow in an exchange on premises environment non-active directory environment part 1#3 part 26#36

Similar to Autodiscover flow in an exchange on premises environment non-active directory environment part 1#3 part 26#36 (20)

More from Eyal Doron

More from Eyal Doron (20)

Recently uploaded

Recently uploaded (20)

Autodiscover flow in an exchange on premises environment non-active directory environment part 1#3 part 26#36