The obvious question could be – who or what are these “Autodiscover clients”?
Article Series Table of content | Click to expand
Exchange and Autodiscover infrastructure | Article Series
Exchange Autodiscover – Article series – INDEX
Exchange and Autodiscover infrastructure | The building blocks
- Exchange Autodiscover infrastructure – Introduction | Part 01#36
- The old Exchange environment versus “modern” Exchange environment | Part 02#36
- Who are the Exchange Autodiscover clients? | Part 03#36
- The Autodiscover information | Part 04#36
- The Autodiscover algorithm for locating the “source of information” | Part 05#36
- Exchange CAS server | Providing Exchange clients access to their mailbox | Part 06#36
- Exchange CAS server as information + Web service provider | Part 07#36
- The dual identity of the Exchange server | Part 08#36
Autodiscover infrastructure | FQDN and URL address
- The basics of Domain name, FQDN and URL address | Exchange infrastructure |Part 09#36
- Exchange Web services | Manage the Internal and external URL address | Part 10#36
Exchange Autodiscover flow in different environments
- The content of the Autodiscover server response | Part 11#36
- Outlook client protocol connectivity flow in an internal network environment | Part 12#36
- Exchange clients and their Public facing Exchange server | Part 13#36
- Outlook Autodiscover decision process | Choosing the right Autodiscover method | Part 14#36
- Autodiscover flow in Active Directory based environment | Part 15#36
- Autodiscover scenarios in enterprise environment | Part 16#36
Autodiscover infrastructure | Exchange infrastructure and namespace convention
- Should I use a single namespace for Exchange Infrastructure? | Part 1#2 | Part 17#36
- Exchange infrastructure | Implementing single domain namespace scheme | Part 2#2 | Part 18#36
- Public SAN certificate | Deprecated support in the internal server name | Part 19#36
Exchange, Autodiscover and security infrastructure
Autodiscover Troubleshooting tools
- Outlook Test E-mail AutoConfiguration | Autodiscover troubleshooting tools | Part 1#4 | Part 21#36
- Microsoft Remote Connectivity Analyzer (ExRCA) | Autodiscover troubleshooting tools | Part 2#4 | Part 22#36
- Microsoft Connectivity Analyzer (MCA) | Autodiscover troubleshooting tools | Part 3#4 | Part 23#36
- Using Fiddler for Autodiscover troubleshooting scenarios | Part 4#4 | Part 24#36
Autodiscover major flow scenarios
Autodiscover flow in an Exchange on-Premises environment | non-Active Directory environment
- Autodiscover flow in an Exchange on-Premises environment | non-Active Directory environment| Part 1#3 | Part 26#36
- Autodiscover flow in an Exchange on-Premises environment | non-Active Directory environment| Part 2#3 | Part 27#36
- Autodiscover flow in an Exchange on-Premises environment | non-Active Directory environment| Part 3#3 | Part 28#36
Autodiscover flow in an Office 365 based environment
- Autodiscover flow in an Office 365 environment | Part 1#3 | Part 29#36
- Autodiscover flow in an Office 365 environment | Part 2#3 | Part 30#36
- Autodiscover flow in an Office 365 environment | Part 3#3 | Part 31#36
Autodiscover flow in an Exchange Hybrid environment
- Autodiscover flow in an Exchange Hybrid environment | Part 1#3 | Part 32#36
- Autodiscover flow in an Exchange Hybrid environment | Part 2#3 | Part 33#36
- Autodiscover flow in an Exchange Hybrid environment | Part 3#3 | Part 34#36
Exchange Stage migration and Autodiscover infrastructure
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 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.
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.
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:
- First-time Autodiscover process
- 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.
It is important for us to know your opinion on this article