autodiscover scenarios in enterprise environment | part 16#36
DESCRIPTION
Autodiscover scenarios in enterprise environment | Part 16#36 http://o365info.com/autodiscover-scenarios-enterprise-environment-part-16-of-36 The different scenario of Autodiscover flow in an enterprise environment that have a specific character such as multiple Active Directory sites, multiple Exchange servers, multiple Public facing Exchange servers etc. Eyal Doron | o365info.comTRANSCRIPT
Page 1 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
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.
Page 2 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
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 on-
Premises 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.
Page 3 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
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.
Page 4 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
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.
Page 5 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
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 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.
Page 6 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
The method that was 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 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.
Page 7 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
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.
Page 8 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
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:
Page 9 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
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 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 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 with two Exchange CAS server names:
ex01.o365info.local the New York Exchange CAS server
ex03.o365info.local the Bangkok Exchange CAS server
Page 10 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
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”.
Page 11 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
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
Page 12 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
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 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.
Page 13 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
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 organization’s 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 (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 is 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 –[email protected]
Bob is located at the company New York site.
Page 14 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
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
Page 15 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
or if we want to be more accurate – not authoritative for
the [email protected] 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
Page 16 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
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).
Page 17 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
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 article-
XX) 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 “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
Page 18 of 18 | Autodiscover scenarios in enterprise environment | Part 16#36
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
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.