autodiscover scenarios in enterprise environment | part 16#36

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.

http://o365info.com/autodiscover-scenarios-enterprise-environment-part-16-of-36


https://il.linkedin.com/in/eyaldoron1

http://o365info.com/



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.





http://o365info.com/autodiscover-flow-in-active-directory-based-environment-part-15-of-36

http://o365info.com/autodiscover-flow-in-active-directory-based-environment-part-15-of-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.







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







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.







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.







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:







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







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”.







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







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.





http://exchangeserverpro.com/modifying-Autodiscover-site-scope-exchange-2010/



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.







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







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







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).







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







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.





autodiscover scenarios in enterprise environment | part 16#36

Documents