Skip to content

Autodiscover flow in an Exchange on-Premises environment | non-Active Directory environment| Part 1#3 | Part 26#36

Autodiscover client uses a different Autodiscover method for locating the Autodiscover Endpoint in an On-Premise Active Directory based environment vs. a non-Active Directory environment. The Autodiscover client verifies if he is located in an Active Directory environment or not. If he decides that he located in a non-Active Directory environment, the Autodiscover client starts to activate a verify sophisticated algorithm that created for finding and connecting the required Autodiscover Endpoint.

The current article and the two next articles dedicated to reviewing the Autodiscover process that implemented in a non-Active Directory environment.

The term Non-Active Directory environment

The term “non-Active Directory environment” describes one of the following scenarios:
1. User desktop that is not a domain joined.
2. User desktop that is not located on the internal organization’s network.

When Autodiscover client recognize that he operates in a “non-Active Directory environment,” the Autodiscover client “skip” the phase in which he addresses On-Premise Active Directory and starts to perform the Autodiscover process looking for Autodiscover Endpoint host name that considers as a derivative of the E-mail address.

Locating the Autodiscover Endpoint Host | Active Directory vs. none- Active Directory environment

Before we get into the details of the Autodiscover process that implemented in a non-Active Directory environment, it’s important to understand the significant difference of the Autodiscover method that 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 name\s of the Autodiscover Endpoint, the Autodiscover client will need to use another method.

The Autodiscover method that is utilized by the Autodiscover client based on the 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 particular host as “Autodiscover Endpoint” he assumes that the destination host is an Autodiscover Endpoint. The Autodiscover client cannot be sure of the target 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.

Locating the Autodiscover Endpoint host Active Directory versus non Active Directory environment

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 not configured as a domain member (domain joined)
  • A user’s desktop that set 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 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 situation 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!

The journey for the lost treasure - the Autodiscover information

Let’s return to the “real world” and try to understand what process each of this Imaginary figure represents.

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 ascent 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 particular host, he doesn’t know if the host (the potential Autodiscover Endpoint) replies to his communication request. In case that the host response, we cannot be sure that the particular host is the “right one”.

For this reason, we use the term “potential”. The host that 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 (keep 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 utilized 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 hostname if the Autodiscover Endpoint.

The default path of the Autodiscover URL based on the following naming convention.

<Folder name><File name>

The default path of Autodiscover services is:

/Autodiscover/autodiscover.xml

The well know parts of the Autodiscover Endpoint URL Address

In the following diagram, we can see the presentation of the “well know 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 missing part in the Autodiscover Endpoint URL address

The great mystery revealed! Generating the Autodiscover Endpoint hostname

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 of 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 exciting 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 mission - creating a new Outlook mail profile

The secret method which the Autodiscover client use based on a little trick.
As mentioned before, the URL address of the Autodiscover Endpoint rests on a predefined naming convention.
For the Autodiscover client which needs to find his Autodiscover Endpoint, the only missing part is the hostname of the Autodiscover Endpoint.

The trick that the Autodiscover client uses based on the E-mail address of the recipient. Every official E-mail address consists 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 from 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

The structure of an E-mail address

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

Generating the missing part in the Autodiscover Endpoint URL address - Scenario 1 of 2

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

In nowadays, we can “reach” most of the public website 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 a new naming convention, but this time; Outlook will try to address the Autodiscover Endpoint by using the following hostname – autodiscover.o365info.com

The hostname – 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 hostname – Autodiscover and mapped to the IP address of the Exchange CAS server who operate as Autodiscover Endpoint.

Generating the missing part in the Autodiscover Endpoint URL address - Scenario 2 of 2

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 possible scenarios are 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 based on the HTTPS protocol).

In this case, Outlook “understand” that this is not the “the last station” in his Autodiscover journey.

If 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, the 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 asks 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 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 hostname to provide a particular service with Outlook the need to know the hostname. In other words, when using the SRV query, looking for a particular service, the DNS reply with the host name\s that provides the particular 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 not supported in Office 365 and Exchange Online environment.

o365info Team

o365info Team

This article was written by our team of experienced IT architects, consultants, and engineers.

This Post Has 2 Comments

  1. Can you also specify the fall back sequences a client will do in both the scenarios(domain/non-domain joined)?

    for example: if the domain joined client is not getting response from AD, will the same client perform “https://autodiscover.domain…” or “http redirect” or the “_SRV methods” etc?

    I believe this all happens in parallel, but need a clarification too 🙂

  2. hi ,

    Is there any need to manually configure the HTTP redirect method?

    should every environment support this method, In which scenarios the HTTP redirection method is mandatory?

    Thanks in advance.

Leave a Reply

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