The Autodiscover algorithm for locating the “source of information” | Part 05#36

The Autodiscover algorithm that is used by the Autodiscover client for locating his “source of information” (the Exchange CAS server), is based on a very sophisticated algorithm, that was designed to overcome and bypass many types of “obstacles’” and operate in different networking environments.

In the current article, we will review the Autodiscover algorithm that is used by the Outlook client for locating the Autodiscover Endpoint (Exchange CAS server).

The source of information

The “information” that required to Exchange clients such as Outlook is: configuration settings needed for creating the Outlook mail profile and information about the available Exchange web services.

The main question could be – who is the source that can provide this type of information to the Exchange client?

Technically, there two methods for Exchange client (such as Outlook) to get the required information:

• Local configuration file
• An Autodiscover Endpoint

1. Local configuration file

One method that Exchange client can use for “getting the required information” is – by using a local file.
The local configuration file is a pre-configured file, which should be created and placed in a particular path of the user desktop.

The method of using a Local configuration file is “removing” one of the essential characters of Autodiscover – the automation.
The method of using local file, could be described as “static method” because, the information in the local file, is not automatically updated in case that the Exchange environment changed. In addition, there is no need for the Outlook mail client to “discover” the element that will provide him the information (the Exchange CAS server).

The method of using a local file not recommended and most important doesn’t support in Office 365 and Exchange Online environment.

For this reason, we will not continue to review this option or the characters or this method.

2. Client\Server method

The Autodiscover method which can describe as “client\server method,” is based on a mechanism, in which the client locates + address a particular server (Autodiscover Endpoint) that will describe as the “information source” and will be able to provide to the client the required information.

The Autodiscover client implements the Autodiscover Client\Server method in the following way:

• Locate the source of information
  Technically, the “source of information” doesn’t have to be an Exchange CAS server, but most of the time, the Autodiscover information will be provided by the Exchange CAS server.
  The Autodiscover client has two ways of locating the “source of information” – one way that implemented by query the Active Directory and the other way, is by querying the DNS for an Autodiscover hostname provider (carried out in a non-Active Directory environment).
• Send the request for information
  Given that the Autodiscover client manages to – locate + connect the Autodiscover Endpoint, the Autodiscover sends a request for information.

3. Server’s response

The “answer” or the Autodiscover response from the server, doesn’t have to be the “final answer” that includes the configuration settings and the information about the URL address of the available Exchange services.

In some scenario, the server response could include a redirection to other or additional sources of information.

In that situation, the Autodiscover client starts the whole process over again.

When the Autodiscover process reaches to his end, the Autodiscover client will use the configuration information for:

• Creating a new Outlook mail profile
• Save the information about the Exchange web service’s URL address for later use

How does the Exchange client locate the Exchange CAS server?

As mentioned, the term “Autodiscover” has many meanings (the client side, the server-side, etc.).

From the client perspective, the Autodiscover could be described as the answer to the simple question – who is my Exchange CAS server?

The answer to the question of – who is my Exchange CAS server? Or, how to find the required Exchange CAS server, depends on the network environment and the configuration setting on the user desktop.

Method 1: Autodiscover in an Active Directory environment

The Autodiscover method which described as – “Autodiscover in an Active Directory environment”, could be only implemented in an Active Directory environment! (Yes, I know that it’s an entirely a stupid sentence).

As mention before, the Autodiscover client doesn’t know the name of the Exchange CAS server, how many Exchange CAS servers are available and so on.

In case that the user desktop is a domain member, and the Active Directory is available and accessible, the Autodiscover client will address the Active Directory asking for information about the names of existing Exchange CAS servers.

The Autodiscover client submits the query to the local Active Directory by using the LDAP protocol.

In case that the organization includes an Exchange infrastructure, and the Exchange CAS server registered at the SCP partition at the Active Directory, the On-Premise Active Directory, reply to the Autodiscover client query by providing him a list of available Exchange CAS server\s.

If we want to be more accurate, the Active Directory response includes a URL address of the local Exchange CAS server\s Autodiscover web service.

The Autodiscover client knows how to “extract” the Exchange CAS server name (the FQDN) from the URL address and how to address the required host.

In the following diagram, we can see a simplified description of the Autodiscover process in an Active Directory environment.

The Autodiscover connects the local Active Directory and gets a list of available Exchange CAS server\s.

Using one of the names which appear in the list, the Autodiscover client tries to connect the Exchange CAS server and completes the Autodiscover process.

In our scenario, the Autodiscover process was completed successfully, and the Exchange CAS server sends to the client the Autodiscover response, which includes the required information for the client (configuration setting needed for Outlook mail profile and information about existing Exchange web services).

Method 2: Using Autodiscover in a non-Active Directory environment.

In case that Exchange client is not a domain member or, if the client cannot access On-Premise Active Directory, the Exchange client will use a different Autodiscover method.
In this scenario, the Autodiscover client will need to use a different method because he cannot use the Active Directory as a “pointer” or a source of information about existing Exchange CAS server\s.

In a non-Active Directory environment, the Autodiscover client will need to “guess” the name of the Exchange CAS server (the Autodiscover Endpoint).

Because the client (such as Outlook) doesn’t really know what is the name of the Exchange CAS server, Outlook uses a method which as describe as “smart guessing.”

The “smart guessing” process that outlook use based on the E-mail address that the user provides when using the Outlook wizard for creating a new Outlook mail profile.

The first step in creating a new Outlook mail profile is the step in which we need to provide the user E-mail address.

Outlook will take the “right part” of the recipient E-mail address, the part which includes the SMTP domain name and uses this name as the host name for the Autodiscover Endpoint.

For example, in case that the recipient E-mail address is- John@o365info.com

Outlook will conclude that the Host name of the Autodiscover Endpoint is – o365info.com

In case that the Autodiscover client cannot find or, connect the Autodiscover Endpoint (the Exchange CAS server) using this domain name as a hostname (o365info.com in our scenario), the Autodiscover client will try to locate the “next Autodiscover Endpoint hostname”, by using the following naming convention – Autodiscover + SMTP domain name.

In our scenario, Outlook will look for an Autodiscover Endpoint named – autodiscover.o365info.com

In the following diagram, we can see an example to the way that the Autodiscover client use for “generating” or “guessing ” the name of the Autodiscover Endpoint.

The logic of the possible Autodiscover methods

In the following section, we will review the “logic” of the Autodiscover algorithm that is used by the Autodiscover client.

The Autodiscover journey is a quest for information.

The “information”, could be the configuration setting and the information about the Exchange web service’s URL or the “information” could be a “lead” or a “pointer” to another available source of information.

The “Source of information” | The Autodiscover service EndPoint.

In the next section, we will mention many times the term “source of information” or the term: “Autodiscover Endpoint”.

This term created for describing the “entity” or the node that the Autodiscover client search and address for getting the required information.

Technically, the Autodiscover service endpoint does not necessarily need to be an Exchange CAS server.

For example, in Office 365 and Exchange Online environment, the Autodiscover client never gets right away to “his Exchange CAS server”.
Instead, the Autodiscover client needs to “travels through” many nodes until he gets to the destination.

This is the reason for another term that used – Potential Autodiscover Endpoint.
We use the word – “Potential” because, the Autodiscover client can never be entirely sure that the “destination host” that he tries to connect is relaying an Autodiscover Endpoint, or if the “destination host” is available and so on.

Some of the “hosts” that the Autodiscover client will “meet” in his way are just a “logical router” that will point him to additional host and so on.

In the following section, we will review the “structure” or the logical of a couple of possible Autodiscover scenarios, in which the Autodiscover client tries to find “his” Exchange CAS server.

Method 1: Direct access to the information (information file)

One of the available options for Autodiscover client is to find the required information by accessing a local configuration file.

The configuration file format based on the XML format.
To enable a mail client such as Outlook, to “find” the information file, we will need to.

• Create the information file.
• Save the information file locally on the user’s desktop hard drive.
• Create and configure a register key, that will “direct” the Outlook client to the information file (by providing the file name and the path of the file).

The method of using a local configuration file, is used only in a rare scenario.
This method not recommended because it’s based on a “static information” and requires configuration setting for each of the user’s desktops.
The method of using a local configuration file not supported in Office 365 and Exchange Online environment.

Method 2: using the host name of the “information provider”

The method which I describe as – “using the host name of the information provider” is implemented in scenarios in which the mail client such as Outlook, has a “preliminary knowledge” about the name of the Exchange CAS server.

This scenario made possible in case that the “standard Autodiscover process” was implemented earlier and the Outlook client managed to get the name of the Exchange CAS server, connect the Exchange CAS server and verify his identity.

There are two possible scenarios in which Outlook addresses the Exchange CAS server using his name instead of starting a standard Autodiscover process:

Scenario 1: an existing Outlook mail profile

In case that we have already configured an Outlook mail profile, as long as the Outlook client is active, Outlook will try to access the Exchange CAS server on an on an hourly basis
(Every hour), to check with the Exchange server about available updates or changes in the information previously provided by the Exchange CAS server.

In this scenario, Outlook will use the Exchange CAS server name or the session ID (in a scene that the Exchange environment based on Exchange 2013 architecture) that saved in a cache.

This method used by the client such as Outlook for “refreshing purpose.”
After the Outlook client finds the required server and gets the required information, Outlook saves the server name (Exchange CAS server name) and periodically connects the Exchange server to ask for existing changes or updates to the information.

Scenario 2: Outlook 2013 client and the feature of Cached URL in the Outlook profile

The option of “Cached URL” in the Outlook profile is available only when using Outlook 2013 version.

The interesting thing is that there is almost no information about this Outlook 2013 feature.
To the best of my knowledge, the father of “Cached URL in the Outlook profile” enable the Outlook client to “re-use” a name of an Exchange CAS server in case that Autodiscover process fails to find the required Exchange server name.

The option of “Cached URL” can be implemented only in a scenario in which the past, Outlook succeeds to complete the Autodiscover process. The meaning is that Outlook saves the name of the Exchange CAS server or the session ID in the registry.

In case that Outlook client cannot locate the required Exchange CAS server, Outlook 2013 client will “fetch” the name of the Exchange CAS server from the registry.

Method 3: address a trusted host, for getting a list of “information providers”

This Autodiscover method implemented in an Active Directory environment.
The concept of this Autodiscover process is to address a “trusted element”, that will guide us to our required destination, is very similar to the scenario in which we are visiting a great mall, which has many stores within.

We look for a famous jeans store, but, we don’t know how to get there.
In this case, we can use a directory or ask for instructions to the mail information office for a direction for this jeans store.

Going back to our Exchange environment, this method utilized by a client such as Outlook, when the client workstation is a part of a domain and, the client can connect the local Active Directory.

To be able to get the hostnames of available Exchange CAS server\s, the mail client addresses an “element” which has information about the available Exchange CAS server\s.

This “element,” is the local On-Premises Active Directory.

The mail client submits an LDAP query to the Active Directory and requests information about the names of available Exchange CAS servers.

Method 4: Generate the NAME of the “information Provider”

In a non-Active Directory environment, the Exchange mail client such as Outlook doesn’t have any “element” that can provide him information about available Exchange CAS server\s (Autodiscover Endpoints).

For this reason, the Exchange client will need to use another method for locating available Exchange CAS server\s.

The Autodiscover process that the Exchange client use based on an interesting concept.
The Autodiscover process that Exchange client use, in non-Active Directory environment, based on a method in which the client “guess” an optional name of the Exchange CAS server (the Autodiscover Endpoint).

When a user provides his E-Mail address (when creating a new Outlook mail profile, for example), the Outlook “takes” the SMTP domain name and creates a DNS query looking for the IP address of the SMTP domain name.

In other words, the Autodiscover client doesn’t know what the name of the “information provider” is (Exchange server) until the user, provide his E-mail address.

Method 5: Redirection or pointer to another “information Provider”

As mentioned before, the Autodiscover process doesn’t always implement as a “one to one” process. In an enterprise environment or, in Office 365 and Exchange Online environment, the structure of the Exchange CAS servers is quite complicated.

In these environments, the Autodiscover client will need to “jump” between a couple of nodes, until he gets to his destination.

For example, in an Office 365 based environment, most of the “Autodiscover Journey” builds on a concept in which the Autodiscover client locates + connect to an Autodiscover Endpoint but the “answer” of this host will not include the required configuration settings but instead, a name (FQDN or URL) of additional Potential Autodiscover Endpoint.