Autodiscover scenarios in enterprise environment | Part 16#36

Exchange on-Premises infrastructure was designed to serve the need of a small company and at the same time, meet the needs of an enterprise business that needs to provide mail services to thousands or even tens of thousands of users.

The main characters of enterprise environment are:

1. The use of multiple Exchange servers in multiple Active Directory sites.
2. The need for implementing load balancing and high availability solutions for the Exchange infrastructure.

In the previous article (Autodiscover flow in Active Directory based environment | Part 15#36), we review the basic concepts if the communication channel between an Autodiscover client such as Outlook and a specific Exchange CAS server.

In the current article, I would like to “move on” to the more advanced or complex scenario that is common in the enterprise environment.

The Autodiscover is a very “flexible creature” that was designed for a simple infrastructure and at the same time, for a complex and compound infrastructure.

In the following article, we will “taste” just part of the possible Exchange on-Premises scenarios in an enterprise environment, so we will be able to understand better, the way that the Autodiscover services implemented in a multiple Active Directory and Exchange server environments.

The knowledge about the “behavior” of the Autodiscover services, in a different Exchange infrastructure and environments, can help us in an Autodiscover troubleshooting scenario.

Scenario 1: Multiple Exchange CAS servers on the same Active Directory site

The scenario of multiple Exchange CAS servers in the same Active Directory site is a popular scenario in a large or enterprise organization, which uses an Exchange infrastructure, which can serve a large amount of Exchange clients at the same time and can provide answers for subjects as – High availability and optimize performance.

Technically speaking, there is no limitation on the amount Exchange CAS servers whom we can use in a particular Active Directory site.

Additionally, we do not need to do or configure anything to make this Exchange CAS server available for Exchange client because the registration of the Exchange CAS servers in the Active Directory SCP implemented automatically.

Each time that an Autodiscover client will query the Active Directory SCP for information about available Autodiscover Endpoint (Exchange CAS servers), the answer will include the URL and the FQDN for each of the Exchange CAS servers.

In the diagram, we can see that when the Autodiscover client queries the Active Directory, the Autodiscover client gets two names of “optional Autodiscover Endpoint.”

In case that all the Autodiscover Endpoint “belong” to the same Active Directory site, the Autodiscover client will just randomly pick a name of Autodiscover Endpoint (Exchange CAS server) from the list and try to address him.

In case that the Autodiscover Endpoint doesn’t reply, the Autodiscover Endpoint will “move on” to the next host in the list that he got an answer from the Active Directory query.

The method that described in which the Autodiscover client just “pick” an Exchange server name from a list doesn’t provide the need for load balancing.

The subject of implementing a load balancing solution for Exchange CAS servers has changed radically in Exchange 2013 architecture vs. Exchange 2010 architecture.

We will not get into the specific details of the “load balancing and high availability world” in Exchange environment, but instead, will be satisfied with a very simple explanation.

The implementation of high availability solution in Exchange environment implemented by using a logical Exchange server name which serves as a representative for two or more “physical Exchange” servers.

When implementing a solution of load balancing and high availability in an Exchange environment, we will not use the default option in which the Exchange CAS servers registered them self automatically in the Active Directory SCP, but instead, we will manually register the name if the logical entity that represents the existing Exchange CAS servers.

Each time that an Autodiscover client will query the local Active Directory for the name (URL) if Autodiscover Endpoint, the answer will include the URL address that uses the FQDN of the logical entity” such as the FQDN that chosen for the load balancer that “represent” the existing on-site Exchange CAS servers.

In other words – the Autodiscover client will not connect a specific Autodiscover Endpoint directly but instead, connect the logical entity (such as load balancing) that will “forward” their request to a particular Exchange CAS server.

Scenario 2: Multiple Exchange CAS servers on multiple Active Directory sites | 
Active Directory site without a local Exchange CAS server

In the following scenario, we will base on the following Active Directory and Exchange infrastructure:

A company, have three physical sites – New York site, Los Angles site, and a thread company site is in Bangkok.

The Exchange infrastructure is implemented as follows:

Exchange CAS server name	On-Premises Active Directory site
ex01.o365info.local	NY
ex01.o365info.local	Bangkok
N/A	LA

The Los angles site doesn’t include an Exchange infrastructure.

All of the “Los Angles user’s” mailboxes located on the Exchange server in the New York site.

The main question is – in case that “users from Los Angles site” will need to connect their Exchange mailbox (with the mediation of the Exchange CAS server) what Exchange CAS server they should contact?

At a first glance, the answer looks quite evident – the Los Angeles users will probably address the Exchange CAS server in the New York site because the “New York Exchange CAS server” is geographically closer to them than the Exchange CAS server in the Bangkok site.

Well, in the reality the answer is not so simple.
Technically speaking, Exchange client doesn’t know who the “right Exchange CAS server” is. The only way that is available for the Exchange client is to query their local Active Directory.

In our scenario, the answer includes a list of two Exchange CAS server names:

• ex01.o365info.local the New York Exchange CAS server
• ex03.o365info.local the Bangkok Exchange CAS server

What will acutely happen is that the Los Angles Exchange client will randomly pick on of Exchange CAS server names from the list.

Statistically 50% of the connection requests will be pointed to the New York Exchange CAS server (ex03.o365info.local) and the other 50% of the connection requests will be pointed to the Bangkok Exchange CAS server (ex03.o365info.local).

The underlying assumption is that we would like to avoid this scenario because there is no point that the Los Angles users connected to their mailbox via the Bangkok Exchange CAS server located on the “other side of the world”.

The good news is that there is a solution for this “problem” named – Site Affinity

The option of Site Affinity, enable us to “mark” a particular Exchange CAS server as a preferred server for a one or more Active Directory site.

In our scenario, the New York Exchange CAS server was automatically registered as an Exchange CAS server for the New York site.

In our scenario, we will like to “tell” to the Los Angles Exchange client that they should prefer the New York Exchange CAS server (ex01.o365info.local).

To implement this requirement, we can “bind” or “attach” an additional Active Directory site name to the New York Exchange CAS server.

The implemented of this “binding” in which we define the New York Exchange CAS server as a sieve that considers as prefer Exchange CAS server for Los Angles users implemented by editing specific Exchange values that are registered in the Active Directory named – Keyword

After completing this task, from this day forwards, each time the Exchange client from Los Angeles site will query the Active Directory for available Exchange CAS servers, because the New York Exchange CAS server (ex01.o365info.local) has the Keyword that includes their site name (LA), they will prefer to connect this particular Exchange CAS server.

Scenario 3: Internal mail client looking for “External” Autodiscover services

In the following section, we will review a scenario in which an organization’s user who is connected to the private\local company network, tries to create a new Outlook mail profile for connecting to Exchange Online mailbox that located in a public network.

A popular example could be – Office 365 users whom his mailbox hosted in Exchange Online.

The organization uses an Exchange on-Premises infrastructure, but, in our scenario, the particular user needs to connect to the “external Exchange infrastructure” (Exchange Online) and not to the Exchange on-Premises infrastructure.

Note that in our scenario, the user uses an organization’s desktop, which can access the On-Premise Active Directory.

The underlying assumption of Outlook client is that – the local Active Directory can provide the required information about the Autodiscover Endpoint names (URL’s if we want to be more accurate) of the available Autodiscover Endpoints.

Technically, the Outlook client doesn’t know that the mailbox that he wants to connect not hosted on an Exchange on-Premises server.

To make the example real, let’s use the following scenario:

• The Active Directory domain name is –o365info.lcoal
• The Public SMTP domain name is – o365info.com
• The organization has two Active Directory\ Exchange sites: New York site and Los angels site. Each of the Active Directory sites, includes Exchange CAS server.
• The name on the Exchange CAS server in the New York site is – ex01.o365info.com
• The name on the Exchange CAS server in the Los Angles site is – ex02o365info.com
• The E-mail address of a domain user who is hosted on the external Exchange Online server is – Bob@Ihaveaverysmallbrain.com
• Bob is located at the company New York site.

Phase 1- connecting On-Premises Active Directory

Outlook client connects to the On-Premises Active Directory and asks for a list of available Exchange on-Premises server\s.

Note that there is no “relations” or connection between the local Active Directory domain name and the E-mail SMTP domain name.

The Active Directory sends the Autodiscover client a list of registered SCP objects (Exchange CAS servers).

In our example, the list includes names of two Exchange servers:
ex01.o365info.local and ex03.o365info.local (number 1 in the diagram).

Phase 2- connecting to each of the on-Premises Exchange CAS servers

The first Autodiscover Endpoint that the Outlook client will try to connect is the Exchange CAS server who located in the same Active Directory site.

The “strange” thing is that the Autodiscover client (Outlook) will manage to find and communicate the Exchange on-Premises server ex01.o365info.local

When the Autodiscover client tries to get the required Autodiscover information (the autodiscover.xml response), the Exchange CAS server sends a “negative response” because the Exchange CAS server (ex01.o365info.local) is not responsible or if we want to be more accurate – not authoritative for the Bob@Ihaveaverysmallbrain.com domain (number 2 in the diagram).

Note – the Autodiscover communication process will complete successfully because the Exchange CAS server – ex01.o365info.local have a certificate that includes the specified FQDN, the Autodiscover client could provide the require user credentials, etc.

Despite the fact all the Autodiscover basic steps were successfully completed, the process cannot be complete because ex01.o365info.local is not responsible (authoritative) for the name space – Ihaveaverysmallbrain.com

The Autodiscover logarithm based on the method in which, when the “first Autodiscover Endpoint” in the list cannot provide the required information, the Autodiscover client “move” to the next name on the list (if such name exists).

In our scenario, the Autodiscover Endpoint that provided by the Active Directory include the additional name – ex03.o365info.local

Outlook mail client assumes that this is the “right Autodiscover Endpoint” that will provide the required Autodiscover information.

Outlook addresses the ex03.o365info.local Exchange CAS server and again, the assumption is that Outlook will find the internal IP address of ex03.o365info.local, manage to complete the mutual authentication process, but the process cannot be successfully completed because ex03.o365info.local is also not responsible or authoritative for the domain name –Ihaveaverysmallbrain.com (number 3 in the diagram).

Phase 3- looking for the Autodiscover Endpoint by using the SMTP domain name

This is the phase in which the Autodiscover client understands that he cannot continue to use the “Active Directory Autodiscover method.

The “next Autodiscover method” is implemented by “extracting” the SMTP domain name from the recipient E-mail address and connect a DNS server looking for the IP address of the “Hostname.”

In our scenario, Outlook will extract the domain name – Ihaveaverysmallbrain.com and ask for a DNS server the IP of this domain.

In case that the DNS server has an IP address that mapped to the domain name, the DNS server provides to the client (Outlook) the IP address (number 4 in the diagram).

Phase 4- connecting to the “external” Exchange server

Outlook tries to connect to the Autodiscover Endpoint by using the following URL – Https://Ihaveaverysmallbrain.com/Autodiscover/Autodiscover.xml

Outlook client will query the DNS server. Given that all the required configurations applied in advance, the DNS will provide an answer that includes the IP address of the Exchange Online infrastructure.

The Autodiscover client can complete the process with the “external Exchange CAS server”.

Outlook client will address Exchange Online, supplement the process of mutual authentication and send a request for Autodiscover information.

Exchange Online sends to Outlook (the Autodiscover client) the required Autodiscover information.

The Outlook client uses the information that included in the Autodiscover.xml file for building a new Outlook mail profile and enables the user to connect to his “remote” or “external” Exchange Online mailbox.