Who are the Exchange Autodiscover clients? | Part 03#36

Throughout the current article series, the term “Autodiscover client\s” will be mentioned dozens or even hundreds of times.
The obvious question could be – who or what are these “Autodiscover clients”?

Autodiscover Client\server model versus server to server model

Technically speaking, every Exchange client or another client that “know” how to locate Exchange CAS server, how to request Autodiscover information and what to “do” with the Autodiscover information could be considered as – Autodiscover client.

If we want to be more specific, in the Exchange based environment, the term “Autodiscover clients”, relates to the following type of Exchange clients:

• Outlook client (RPC/HTTP/S)
• Mobile mail client (ActiveSync client)
• Web-based client (HTTP/HTTPS)
• Other Exchange servers

One way that we can use to classify the different type of Autodiscover clients is by using the “client to server” or, “server to a server” classification.

1. Client to server

An example of a “standard” Exchange Autodiscover client could be:
Outlook client.

Outlook clients use the Autodiscover services for:
Locating the Exchange CAS server who will enable them to access their mailbox, for creating a new Outlook mail profile, for getting information about different Exchange services such as – Offline address Book, Free\Busy time and more.

2. Server to Server model

Fewer know the perspective of the Autodiscover services, is a relationship that could describe as: “Server to Server.”

In this scenario, the “client” is not a standard client such as Outlook but instead, the client is an Exchange server who needs information from another Exchange server.

The ability of the “client” (the source Exchange server) to find or locate the “destination Exchange server” that can provide him the required information, is based on using the Autodiscover service.

An example for the Autodiscover “Server to Server model” could be

Mail migration in Office 365 environment | Exchange server as Autodiscover client

In the Office 365 environment, migration such as – Cutover migration, Stage migration or Hybrid migration, is implemented by relying on the Exchange On-Premise Autodiscover service.

The migration batch that we create from the Office 365 admin center will use the domain name suffix in the username credentials that we provide for locating the Exchange on-Premises server.

Note – later we will review in more details this Autodiscover mechanism in which the “client” use the part of the domain name suffix for locating Autodiscover Endpoint.

Office 365 Hybrid environment | Exchange server as Autodiscover client

The term “Hybrid environment”, is a term that describes a relationship between two different Exchange organization (Exchange Online and Exchange on-Premises server) that can operate as one entity and share between them different types of information and services.

The ability to share information between the cloud infrastructure (Exchange Online) and the Exchange On-Premise infrastructure such as – Availability service (Free/Busy time), is based on the Autodiscover infrastructure of each of the environments (Cloud and On-Premise).

When a user from the “cloud” needs to view Free/Busy time of On-Premise user, the Exchange Online server will use the Autodiscover process for locating the Exchange On-Premise server.

Who are the Exchange mail clients?

Another term that will be used very often throughout the current article series is the term – “Exchange client”.

Exchange environment can serve many types of the different mail client.
The main charterer that differences one mail client from another is the protocol that the client use.

Although all the “mail protocol” has the same purpose of – enable a user to see the content of his mailbox, each of the mail protocols to behaves differently, speaks other “language” and interacts differently with Exchange infrastructure.

Exchange server supports four types of mail clients.

• Outlook mail client – Outlook mail client sometimes described as an MAPI client because this client uses a dedicated mail protocol named – MAPI
  (Mail application program interface).
  The MAPI protocol is not a transport protocol and, for this reason, Outlook mail client uses a “combination” of protocols. For example – MAPI over RPC (Remote Procedure Call) or another type of combination such as when using the Outlook Anywhere settings that use the following combination – MAPI over RPC over HTTPS.Exchange 2013 will support a new “combination” in which, the RPC protocol will be “taken out” from the equation.
• Webmail client – Mail web clients are clients that use the HTTP or the HTTPS protocol for accessing the user mailbox.
• Mobile mail clients – the access protocol for a mobile client such as a smartphone, tablets, etc., is the ActiveSync protocol.
• Internet mail client – the term “internal mail client” relates to the mail client that uses the POP3 and IMAP4 protocol for retrieving mail from the user mailbox and use the SMTP protocol for sending mail.

In the following diagram, we can see that the Exchange CAS server, provide his services for a variety of mail clients, using a variety of mail protocols such as – Outlook mail client that uses RPC protocol, or RPC/HTTPS (Outlook Anywhere) protocol, mobile devices that use the ActiveSync protocol and “web-based mail client” such as OWA.

The Exchange CAS server “know” how to adapt himself to each of these different protocols, which has different charters, communication methods, etc.

The “Exchange Autodiscover” mail clients

Versus the phrase – “All men are created equal”, the Exchange clients are not created equal and each of them has a specific charter and requirements.

Relating to our most important subject – the Exchange Autodiscover infrastructure, not all the “Exchange client” need or “consume” the Exchange Autodiscover in the same way.

For example, Autodiscover protocol enables Exchange client to locate available Exchange CAS server automatically, but some of the Exchange clients such as the OWA client specifies manually the name of the Exchange server whom they access, instead of using an “automatic process” that will reveal at the end the required Exchange CAS server name.

The most prominent Exchange Autodiscover client is the – Outlook. The Outlook client is entirely dependent on the Exchange Autodiscover infrastructure.

Another Exchange client such as – mobile client (ActiveSync) and OWA (web client) are partially reliant on the Exchange Autodiscover infrastructure.

For example, a mobile client (ActiveSync) can locate the required Exchange CAS server using Autodiscover query or instead manually type the required Exchange CAS server name.

The Exchange Autodiscover infrastructure serves for additional purposes such as: providing the essential information needed for creating a new mail profile (relevant, mainly for Outlook mail client), information about available Exchange web services, and information about the supported authentication protocol from the Exchange CAS server and so on.

For the sake of full disclosure, I must admit that I know for sure the Exchange Autodiscover is “mandatory” for Outlook client, but for the rest of the Exchange clients – Mobile (ActiveSync) client and OWA (web client) it’s not so clear how does this client interaction with the Exchange Autodiscover services.

For example, part of the Autodiscover information that is provided by the Exchange server includes a particular section of authentication protocol requirements for the Exchange web client (OWA mail client), but it’s not so clear how and if the OWA client uses this information.

The dependency of the different Exchange client in the Exchange Autodiscover services table

In the following chart, we can see “Level of use” of the “Autodiscover services,” by the different Exchange clients.

The different Exchange mail client and the process of automatically locating the Exchange CAS server

By default, Outlook client doesn’t know the name of the Exchange CAS server that will serve him. The only way for Outlook client to locate and find “their Exchange CAS server” is, by using the Autodiscover process.

These are some exceptions to this “rule” because technically, we can provide Outlook client the Exchange CAS server name manually or, by using a local configuration file, but this method is not recommended and additionally, there are many other configuration settings that we will need to provide to the Outlook client beside of the name of the Exchange CAS server.

Mobile (ActiveSync) clients will try to locate their Exchange CAS server by using the Autodiscover process and, this is the “recommended way”.

In a scenario in which the Autodiscover process failed, or the in some old mobile devices, the Mobile Client (ActiveSync) doesn’t support Autodiscover; we can manually provide the name of the Public facing Exchange CAS server who will accept the communication request of the Mobile (ActiveSync) client.

Regarding a webmail client such as OWA, the OWA mail client doesn’t use the Autodiscover protocol for “locating” the “element” that will “lead him” to his mailbox because, when using a webmail client, the underlying assumption is that the user will have to know in advance the name of the Exchange mail server that will enable him to access his mailbox.

Get information about available Exchange web services

The only way for “informing” Outlook client about the availability Exchange web services is via the Autodiscover process, in which the Exchange CAS server sends the Outlook client the URL address of the existing Exchange web services.

Regarding the “other Exchange clients” – Mobile (ActiveSync) client and OWA (web client), it’s not so clear, how does this client get the information about available Exchange web services.

As far as I know, a client such as OWA, doesn’t need to know about available Exchange web services, the OWA client just needs to apply for information, and the Exchange server is responsible for locating the required resources (Exchange web services) and fetching the required information for the OWA client.

And again, I’m not sure that this theory accurate in 100%.

Get the information required for the creation of a new mail profile.

Outlook client must configure with a “mail profile” that serves as a “logical container” for all the communication settings that required for the communication channel between the Outlook client and Exchange CAS server.

The only optional way for Outlook mail client to get the required configuration setting for the mail profile is – by using the Autodiscover services.

The Exchange CAS server will accept the Outlook client Autodiscover request for information and based on specific characters of the Exchange client such as – the Exchange Mailbox server who hosts the recipient mailbox, the geographic location of the client and more, provide a custom answer.

Other

In the “other” section, we can relate to any configuration settings or services that can provide as part of the Autodiscover process to Exchange client.

For example, as mention, part of the Autodiscover information that is provided by Exchange includes a particular section that relates to the OWA mail client.

Because I’m not sure how this information does is “used” by OWA mail client, I will classify this information in the “other” section.

Autodiscover one-time procedure or ongoing communication channel?

In the former section, we have to review the nature of the relationships that exists between the Exchange clients and their Exchange CAS server and the way that the Autodiscover infrastructure help client to find their “destination Exchange CAS server” and help the Exchange CAS server to provide the necessary information for his client.

The question that could appear now is – Does the Autodiscover can consider as a “one-time event”? Or does the Autodiscover is an “ongoing” communication channel between the Exchange CAS server and his clients?

The answer to these questions is that the Autodiscover process is not a static process!

The Autodiscover process is not a “one-time time process.”
We can classify the scenarios of Autodiscover relationships between the Exchange clients and their Exchange CAS server into two broad categories:

1. First-time Autodiscover process
2. Ongoing Autodiscover process

The Autodiscover process between the client and the server starts with a “first handshake” between the Autodiscover client and the Autodiscover Endpoint.

In this “preliminary process,” the Autodiscover Endpoint provides the information to his client, but this doesn’t mean that starting from today onwards, the Autodiscover client will use this information forever!

The more suitable term for the Autodiscover relationships that exists between the Autodiscover client and the Autodiscover Endpoint is a “dialog.”

For example, Exchange clients, such as Outlook, are accessing the Autodiscover Endpoint, on an hourly basis to check for “new information” or updates relating to the Exchange infrastructure.

Another example could be – each time that the mail client such as Outlook is “restarted,” the client will try to access the Autodiscover Endpoint, looking for new information or verifying that he has the required information.