Page 1 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36

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, serve the needs of an enterprise company that
need 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.

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 2 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36

In the former 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 are 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 passable Exchange onPremises scenarios in an enterprise environment, so we will be able to understand
better, the way that the Autodiscover services are implemented in a multiple Active
Directory and Exchange server environments.
Note in the context of the Autodiscover infrastructure, when using the term
multiple Exchange servers, the meaning is to multiple Exchange servers who has
the CAS (Client Access Server) role.

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 3 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36

In the Exchange infrastructure, the Exchange server who holds the CAS role is
responsible for providing the client (such as Outlook) Autodiscover services.

The knowledge about the behavior of the Autodiscover services, in a different

Exchange infrastructure and environments, can help us in an Autodiscover
troubleshooting scenario.

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 4 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36

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.

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 5 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36

Technically speaking, there is no limitation on the amount Exchange CAS servers

whom we can use in a specific 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 is 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 query 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 doesnt reply, the Autodiscover Endpoint will
move on to the next host in the list that he got an answer from the Active
Directory query.

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 6 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36

The method that was described in which the Autodiscover client just pick an
Exchange server name from a list, doesnt 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 versus 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.

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 7 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36

The implementation of high availability solution in Exchange environment is

implemented by using a logical Exchange server name who 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 was chosen for the load
balancer that represent the existing on-site Exchange CAS servers.
In other words the Autodiscover client will not connect directly a specific
Autodiscover Endpoint but instead, connect the logical entity (such as load
balancing) that will forward their request to a specific Exchange CAS server.
Note in other types of implementation such as DNS round robin, the Autodiscover
client addresses the Exchange CAS server directly without a broker such as a load
balancer.

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 8 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36

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 are in Bangkok.
The Exchange infrastructure is implemented as follows:

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 9 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36

Exchange CAS server name

On-Premises Active Directory site

ex01.o365info.local

NY

ex01.o365info.local

Bangkok

N/A

LA

The Los angles site doesnt include an Exchange infrastructure.

All of the Los Angles users mailboxes are 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 obvious 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 doesnt 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 with two Exchange CAS server names:

ex01.o365info.local the New York Exchange CAS server

ex03.o365info.local the Bangkok Exchange CAS server

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 10 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36

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 basic assumption is that we would like to avoid this scenario because, there is
no point that the Los Angles users will be connected to their mailbox via the
Bangkok Exchange CAS server who is located on the other side of the world.

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 11 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36

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 specific 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 consider as prefer Exchange CAS server for Los Angles users
is 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

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 12 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36

Keyword that includes their site name (LA), they will prefer to connect this specific
Exchange CAS server.

Additional reading

Modifying Autodiscover Site Scope for Exchange 2010

Scenario 3: Internal mail client looking for External

Autodiscover services
In the following section, we will review a scenario in which an organizations 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.

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 13 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36

A popular example could be Office 365 users whom his mailbox is hosted in
Exchange Online.
The organization uses an Exchange on-Premises infrastructure, but, in our scenario,
the specific 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 organizations desktop, which can access
the On-Premise Active Directory.
The basic assumption of Outlook client is that the local Active Directory can
provide the required information about the Autodiscover Endpoint names (URLs if
we want to be more accurate) of the available Autodiscover Endpoints.
Technically, the Outlook client doesnt know that the mailbox that he wants to
connect is not hosted on an Exchange on-Premises server.
To make the example real, lets 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.

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 14 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36

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 is 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

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 15 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36

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

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 16 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36

The Autodiscover logarithm is 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 in the list (if such name is exist).
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 becauseex03.o365info.local is also not responsible or
authoritative for the domain name Ihaveaverysmallbrain.com (number 3 in the
diagram).

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 17 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36

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 (which will be reviewed in details in the text articleXX) is implemented by extracting the SMTP domain name from the recipient Email address and connect a DNS server looking for the IP address of the Host
name
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 is 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

Written by Eyal Doron | o365info.com | Copyright 2012-2015

Page 18 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36

Outlook client will query the DNS server. Given that all the required configurations
were 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, complete 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 is 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.

Written by Eyal Doron | o365info.com | Copyright 2012-2015