In the following article, we look “under the hood” of the Autodiscover method that implemented in Active Directory-based environment.
In the Active Directory-based environment, the process in which the Autodiscover client such as Outlook locates available Autodiscover Endpoint performed by addressing the Active Directory as a source of information for available Autodiscover Endpoints (available Exchange servers).
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
The available Autodiscover methods
Generally speaking, there are two main Autodiscover methods:
- Autodiscover in Active Directory environment
- Autodiscover methods in a non-Active Directory environment
In case that the user desktop in which the Outlook client is installed configured as a domain member, Outlook will allow start with the Autodiscover process by addressing in the query the local Active Directory.
In case that there is no option to locate the Active Directory, Outlook client will “move on” to the next Autodiscover method (in the next article – Autodiscover flow in an Exchange on-Premises environment | non-Active Directory environment| Part 1#3 | Part 26#36 , we will review in details this method).
Creating a New Outlook mail profile in a domain environment
One of the most prominent features of the Autodiscover process in the On-Premise Active Directory environment is that we can describe this process as fully automated.
In a scenario in which the user desktop configured as a domain member, the only requirement from the user who needs to create a new Outlook mail profile is – just to open Outlook.
After a very short time, all the required settings will be automatically “delivered” to the Outlook client, and the user can access his mailbox and start reading his E-mail and so on.
The only question is – how does this “magic” happen?
The answer is that the Autodiscover was designed to simplify the process of getting the required information (configuration settings) from the “Autodiscover Endpoint” and this process is getting more simplified in an On-Premise Active Directory environment.
In a non-Active Directory environment, when the user needs to create a new Outlook mail profile, the user is required to provide the following details.
- User E-mail address
- User credentials
In Active Directory environment, the user doesn’t need to provide any details because, in a domain environment, the process is based on the user cache credentials.
- Credentials (Username + Password)In an Active Directory environment, because the user has already provided his credentials when he login to the domain, these credentials are automatically sent to the Exchange On-Premise server. (The technical term is cache credentials or Access token)
- Provide the user email address
In a scenario in which the user is the log into the organization domain, the user email address is automatically “pulled” or “extract” from the On-Premise Active Directory user account. In other words: the user who creates the new Outlook mail profile doesn’t need to provide his E-mail address.
- Get the required configuration information from the Exchange server
The process in which Outlook gets the configuration information that needed for creating the new Outlook mail profile is also “happened automatically”.
Outlook query the local Active Directory and ask a list of Exchange CAS server\s.
After getting the name\s of existing Exchange server\s, Outlook will try to connect one Exchange server from the list.
As mentioned the part in which the user will need to provide his E-mail and user credential of the Exchange server implemented automatically.
After the Exchange server to verify the user identity and the Outlook verify the Exchange server’s identity, Exchange sends the Outlook client the required configuration setting using the Autodiscover.xml file.
On-Premise Active Directory as a source for information
One of the most noticeable advantages of the Active Directory is that the Active Directory serves as a “bulletin board” for her client.
Servers who provide a particular service, can register themselves in the Active Directory and by doing so, use the Active Directory as a “board” for the information.
Active Directory clients can address the Active Directory (using LDAP query) and ask for information about a particular service, who is the host who provides the service, etc.
In our scenario, the Exchange CAS server registers himself in the Active Directory as “entity” that can provide Autodiscover service.
The On-Premise Active Directory allocates a dedicated location (part of the On-Premise Active Directory system partition) for this purpose, by using a folder named- SCP (Service Connection Point).
In the following diagram, we can see an example of this process.
Each time that a new Exchange On-Premise installed, the Exchange On-Premise accesses the Active Directory and, “report about himself.”
The term – “Autodiscover client”, can be translated to an Autodiscover client such as Outlook that needs to find Autodiscover Endpoint for creating a new Outlook mail profile and for other purposes, but at the same time, the “Autodiscover client” can be “other Exchange server.”
For example, a scenario in which Exchange server from Active Directory Site A, need to get information that is “represented” by an Exchange CAS server in Active Directory Site B.
Physical location of the SCP (Service Connection Point)
To be able to find the “physical path” of the SCP, we can use the Site and Service tools that installed on each of the DC servers.
After you have enabled the “View Services Node” option from the “View” tab, we can see the physical path of the On-Premise Active Directory configuration partition.
The SCP object can be found in AD at the following path:
CN=exchangeserver,CN=Autodiscover,CN=Protocols,CN=exchangeserver,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=org name,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com
Each of the Exchange CAS servers has the “Autodiscover folder” and the Autodiscover folder serves as a container for the Autodiscover Endpoint object (a particular Exchange CAS server).
To be able to see the property of a specific Autodiscover Endpoint (in our example ex01), we can right click on the Exchange CAS server name and choose the menu properties.
The property named – ServiceBindingInformation
The property named –Keywords, contain the Active Directory site name of a specific Exchange CAS server.
Creating a new Outlook mail profile | The process behind the magic!
In the following section, we will analyze the process of Autodiscover in an Active Directory environment.
Because of the Autodiscover method that implemented in an Active Directory environment, the task of – “creating a new Outlook mail profile” is a very simple task that can be deployed by any user in a matter of seconds.
The real magic is that behind the scenes, the “simple task” is “translated” too sophisticated and smart infrastructure that helps to make this process to appear as “simple and easy”.
An organization user, get a new desktop, the user double-click on the Outlook icon and after a couple of seconds, Outlook profile was successfully completed, and the user can see his mail, send and receive mail and so on.
In the following section, we will review what was the sequence of events, which led to the above result
Phase 1 – query the local Active Directory
The communication between the Autodiscover client and the Active Directory implemented by using the LDAP protocol.
Step 1 – Client query the local Active Directory
The Autodiscover client (Outlook) creates an LDAP query and addresses the local Active Directory, asking for a list of URL address of existing Autodiscover Endpoint.
In other words – list of available Exchange CAS server\s
Step 2 – Active Directory look at the SCP partition, looking for a value of an attribute named – ServiceBindingInformation
The Active Directory SCP contains a different or a dedicated ServiceBindingInformation
The Exchange CAS server Autodiscover URL, is implemented by using the following format:
The Exchange CAS server name is the internal Exchange server name (FQDN -Fully Qualified Domain Name)
In our example, the internal FQDN of the Exchange CAS server who was registered at the Active Directory SCP is – ex01.0365info.com and the Autodiscover URL will be:
Additional information that the Active Directory “returns” to the Autodiscover client described as – Keywords
The “Keywords” contain information about the Exchange CAS server Active Directory site name.
(The Active Directory site name in which the Exchange CAS server resides).
When the Autodiscover client (Outlook) gets the list from the Active Directory, the Autodiscover client will prefer to address the Exchange CAS server, which has the same Active Directory site value, as the Active Directory site to which the Autodiscover client belongs also.
This method in which the Autodiscover client prefers to contact a particular Exchange CAS server over other Exchange CAS servers described as – Site Affinity
Phase 2 – query the local DNS server
Step 3 – The Autodiscover client will need to get the internal IP address of the Exchange CAS server. The Autodiscover client connects the internal DNS server. In our example, look for the IP address of the host named – ex01.o365info.lcoal
Step 4 – The DNS server reply (answer) to the DNS query and send the internal IP address of the specified hostname (192.168.1.10 in our example).
Phase 3 – Mutual verification process
In this phase, the client (Outlook) and the “server” (the Exchange CAS server) will need to identify each other.
Step 5 – Outlook asks for the Exchange CAS server to prove his identity by providing a certificate.
Step 6 – The Exchange CAS server, send his certificate to the client and the client verifies the Exchange CAS server certificate.
Step 7 – In case that the Exchange certificate is “OK”, the client sends his “identity” (user credentials) to the Exchange CAS server.
Step 8 – In case that the user credentials are correct, the process of mutual authentication and identification is completed.
Phase 4 – communicate the Exchange CAS server using RPC or HTTP/S
Step 9 – the mail client (Outlook) asks from the Autodiscover Endpoint (Exchange CAS server) for the Autodiscover information (the Autodiscover.xml file)
Step 10 – The Exchange server “generate” the configuration file based on the Outlook version software and save it to a file named – Autodiscover.xml
Step 11 – Outlook client gets the configuration file and create a new Outlook mail profile that includes all the required configuration settings.
Autodiscover in the Active Directory environment a diagram representation
In the following diagram, we can see a representation of the “decision-making table” of the client that relates to the Autodiscover process.
We will not go into all the details in the diagram, but instead, I will just recap and emphasize some part of the Autodiscover process in an Active Directory environment.
Step 1 – the Autodiscover method is entirely dependent on the information that supposed to registered in the SCP partition in the Active Directory.
In other words, the Active Directory is the “information source authority” for providing the Autodiscover client information about available Autodiscover Endpoints.
Step 2 – in case that the Exchange organization includes more than one Exchange CAS server, the answer that will the Autodiscover client gets to include a list of “optional Autodiscover Endpoints”.
The Autodiscover client will need to implement some method for choosing the most “appropriate” Autodiscover Endpoint for him.
This approach described as “site affinity”. The Autodiscover client will “prefer” Autodiscover Endpoint that located in the same Active Directory as he.
Step 3 and Step 4.1 – in case that the Autodiscover client gets a list of available Autodiscover Endpoint, the client will try to communicate the “first Autodiscover Endpoint” and if the Autodiscover Endpoint is not an available, “move” to the next Autodiscover Endpoint in the list and so on.
Step 5.1, 5.2, 5.3 and step 6, are steps that need to successfully complete before starting the phase in which the Autodiscover Endpoint provides the desired information to his Autodiscover client.
The Autodiscover Endpoint must be sure that the Autodiscover Endpoint can be trusted, and vice versa – the Autodiscover Endpoint must identify the Autodiscover client.
Step 7 – the Autodiscover Endpoint (Exchange CAS server) generates the required information (Autodiscover response) and sends it to the Autodiscover client (Outlook).
Step 8 – this is the “happy end phase” in which, the Outlook client “take” the information and use it for creating a new Outlook mail profile.
It is important for us to know your opinion on this article