Exchange 2013 coexistence | Autodiscover infrastructure | Part 2/2 | 12#23

of 26 | Part 12#23 |Exchange 2013 coexistence environment | Autodiscover
infrastructure | Part 2/2
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
EXCHANGE 2013 COEXISTENCE
ENVIRONMENT | AUTODISCOVER
INFRASTRUCTURE | PART 2/2 | 12#23
The focus of the current article is the Exchange Autodiscover infrastructure in
internalprivate environment.
In the current article, we will review the following subjects:
1. General review of the Exchange Autodiscover environment
2. The specific characters of Exchange Autodiscover infrastructure in an Exchange
2013 coexistence environment
3. The reason for implementing the “Autodiscover centralized model”
4. The Active Directory SCP (Service connection point) and the Exchange
Autodiscover name registration concepts and management using PowerShell.

The current article is the continuation of the previous article: Exchange 2013
coexistence environment | Autodiscover infrastructure | Part 1/2
General concepts of Autodiscover
infrastructure in the internal network
environment
Before we start from the description of the Exchange internal Autodiscover in a
scenario of Exchange 2013 coexistence environment, it’s important to review some
of the basic concepts of the Autodiscover logic in internal Exchange environment
and only then, “move forward” to the description of Autodiscover in Exchange 2013
coexistence environment.
Scenario 1: The internal Autodiscover process on Exchange site
The “standard internal Autodiscover process” in a single Exchange site environment
is implemented in the following way:
The exchange CAS server registers himself in the Active Directory SCP (Service
connection point).
When Exchange clients (Autodiscover client) need to locate Autodiscover Endpoint
(Exchange CAS server), he queries the Active Directory, gets a list of existing
Exchange CAS servers and addresses the Exchange CAS server for getting the
required Autodiscover information.

Scenario 2: The internal Autodiscover process in multiple Exchange sites
environment
The “internal Autodiscover process” in a multiple Exchange site environment is
implemented in the following way:
Each of the Exchange CAS servers, register himself in the Active Directory SCP
(Service connection point).
When Exchange client need to locate Autodiscover Endpoint (Exchange CAS server),
he queries the Active Directory, gets a list of existing Exchange CAS servers and
chooses the most “suitable” Exchange CAS server from the list, based on the “Active
Directory site” property.
Exchange clients will always prefer to connect “local Exchange CAS server” that is
located in the same Active Directory as, he.

In our scenario, the “red Exchange client”, will prefer to connect the Exchange CAS
server in site 1 for getting the required Autodiscover information.
In our scenario, the “Yellow Exchange client”, will prefer to connect the Exchange
CAS server in site 2 for getting the required Autodiscover information.
Internal Autodiscover infrastructure in an
Exchange 2013 coexistence environment
The scenario of Exchange 2013 coexistence environment, requires the
implementation of adjustments of the internal Autodiscover infrastructure.
The best practice for internal Autodiscover infrastructure in coexistence
environment is based on a concept in which the Exchange 2013 CAS serves as an
“Autodiscover focal point”
The meaning of the term, is that instead of the default Autodiscover infrastructure
that is implemented in a multiple Exchange site , in which each of the Exchange

sites, have his “own” Autodiscover Endpoint”, in an Exchange 2013 coexistence
environment , the Exchange CAS 2013 is “replacing” the “other source of
Autodiscover information” ( the legacy Exchange CAS servers) and the model is
transform into a “centralized model” in which there is only one source of
Autodiscover information: the Exchange CAS 2013.
Scenario 1: Exchange 2013 coexistence environment |Single Exchange
site environment
The charter of this scenario is a single Exchange site, which include multiple
versions of Exchange servers. Technically, each of the Exchange CAS server can
provide Autodiscover services, but as mention before, the ability of “legacy
Exchange CAS server” to provide Autodiscover services to more “advanced
Exchange clients” is limited.

For example, Exchange 2007 CAS will not be able to provide the required
Autodiscover services for Exchange 2013 client.
For this reason, the solution will be to “crown” the Exchange CAS 2013 server as the
“focal Autodiscover point” for all the different types of Exchange clients.
In the following diagram, we can see an example of the concept in which the
Exchange CAS 2013 server becomes the focal point of Autodiscover services for the
internal Exchange clients in a specific Exchange site.
Each of the different Exchange clients such as: Exchange 2007, 2010 and 2013, will
address the Exchange CAS 2013 server looking for Autodiscover services. The
Exchange CAS 2013 server is “smart enough” to know or to provide the required
“Autodiscover answer” to the Exchange clients based on their version.

Scenario 2: Exchange 2013 coexistence environment | Multiple Exchange
sites environment | Centralized Autodiscover model
In the current scenario, the organization Exchange infrastructure is based on a
multiple Exchange sites infrastructure.
In an Exchange 2013 coexistence environment, the Exchange 2013 coexistence
environment becomes the “main source for Autodiscover information” even for
Exchange client clients that are physically located in another Exchange site.
In this scenario, each of the Autodiscover Exchange clients requisites (Exchange
client from all the sites), will always be addressed to the Exchange CAS 2013 server
in site 1.

When the Exchange CAS 2013 server on site 1 will get the Autodiscover request, he
will identify the Exchange client, query the Active Directory about the specific user
and find what the exact “Exchange client version” is.
For example, in case that the Exchange clients are a client that his mailbox is hosted
on Exchange 2010 Mailbox server, the Exchange CAS 2013 server “understand” that
he will need to provide a specific Autodiscover information to this specific Exchange
2010 client.
In this scenario, the Exchange CAS 2013 server will proxy the request to Exchange
2010 CAS server (the Exchange 2010 CAS server in the same Active Directory as the
Exchange client), get the required Autodiscover information from the Exchange
2010 CAS server and provide this information to the Exchange 2010 client.

Exchange 2013 coexistence environment
distributed Autodiscover model | The
forbidden model
In the former section, we have to review the best-practice configuration for the
Autodiscover infrastructure in an Exchange 2013 coexistence environment.
Technically, the “best practice” is not mandatory, and additionally I’m not familiar
with formal Microsoft’s article that describes the best-practice recommendation for
the Autodiscover infrastructure in an Exchange 2013 coexistence environment.
Let’s say that, for some reason, you are not willing to adopt the recommendation of
the best practice, and you prefer to use the “standard Autodiscover infrastructure”.
A small clue: in the next section, we will demonstrate the consequences of not
using the best-practice Autodiscover model for the Exchange 2013 coexistence
environment.
In a “non-Exchange 2013 coexistence environment” or homogeneous Exchange
environment, in a scenario of multiple Exchange sites, each of the Exchange sites

has a “local Exchange CAS server”, which serve as an Autodiscover Endpoint for the
local Exchange clients.
To be able to demonstrate this concept, let’s use the following scenario.
On organization have three Active Directory site and two Exchange sites (one of the
company sites doesn’t include Exchange infrastructure).
 Site 1 is based on Exchange 2013 infrastructure.
 Site 2 is based on Exchange 2007 infrastructure
The information about the two Exchange CAS servers, is registered in the Active
Directory at the SCP (Service Connection Point).
In the following diagram, we can see that in our scenario, the Active Directory SCP
includes information about two different Exchange CAS servers. The Exchange CAS
server from site 1 and the Exchange CAS server from site 2.

When the internal Exchange 2013 client from the site 1 look for Autodiscover
Endpoint, he will get a list that includes the names of the Exchange 2007 CAS and
the Exchange 2013 CAS. Because the “site 1 Exchange client” and the Exchange
2013 CAS are on the same site, the Exchange client from site 1 will choose to
address the Exchange 2013 CAS.
The same logic will be implemented with the internal Exchange 2007 client from
site 2. When the “site 2 Exchange client” query Active Directory, he gets the list of
available Exchange CAS servers, he will prefer to address the local Exchange CAS
server meaning: the Exchange 2007 CAS.
The “distributed” Autodiscover infrastructure that we have a review, can cause to
the problem in which an Exchange client, will access the “wrong Exchange CAS
server”.

As mentioned, a more modern version of the Exchange CAS server can serve
“native Exchange clients” (an Exchange client that has the same version as the
Exchange CAS server) and additionally: legacy Exchange client.
For example: Exchange 2013 CAS can serve the Autodiscover request of Exchange
2013 client + Exchange 2007 client.
This “rule” doesn’t apply to former versions of the Exchange CAS server. Exchange
2007 CAS can serve the Autodiscover request of Exchange 2007 client, but cannot
serve Autodiscover requests of Exchange 2013 client.
Problem 1: An Exchange site without local Exchange CAS server
In the following scenario, an Exchange 2013 client is located in Active Directory site
3. When the Exchange 2013 client query the Active Directory for a list of available
Exchange CAS servers, he will get the names of the Exchange 2013 CAS + Exchange
2007 CAS.
Q1: Which Exchange CAS server the Exchange client will choose from the list?
A1: The answer is that in this scenario, the Exchange 2013 client will randomly
choose one of the Exchange CAS server’s names.
 In case that the Exchange 2013 client will choose the name of the Exchange 2013
CAS, the Autodiscover process will complete successfully.
 In case that the Exchange 2013 client will choose the name of the Exchange 2007
CAS, the Autodiscover process will not complete successfully.

Problem 2: Exchange client located at other Active Directory sites.
The current scenario charters are: an Exchange 2013 client that “belong” to site 1, is
visiting the other company site: site 2.
When the Autodiscover Exchange 2013 client, create a query, looking for names of
available Exchange CAS servers, the “answer” will include two names: the Exchange
2013 CAS in site 1 and the Exchange 2007 CAS in site 2.
In this scenario, the Exchange 2013 client will choose the address the Exchange
2007 CAS because from his point of view, this is the “nearest Exchange CAS server”.
In this case the Autodiscover process will not complete successfully because the
Exchange 2007 CAS cannot provide the “correct Autodiscover information” to the
Exchange 2013 client.

Exchange 2013 coexistence environment | The
required updates for the Active Directory SCP
As was mentioned in former sections, in the Exchange 2013 coexistence
environment, we will need to implement a “centralized Autodiscover model” in
which the Exchange CAS 2013 will serve as the “main source” for Autodiscover
information.
The implementation of this “centralized Autodiscover model” is implemented by
updating the existing Autodiscover information that exists in the Active Directory
SCP. Before the implementation of the required updates, the Active Directory SCP
will include “pointers” to the legacy Exchange CAS servers.

By default, every Exchange CAS server knows how to register himself automatically
in the Active Directory, in a special system folder named: SCP (Service Connection
Point).
In the Exchange coexistence environment, this “default behavior” will cause to
problematic scenarios because, when Exchange client queries the Active Directory
for a list of available Exchange CAS server/s, the Exchange CAS server list, will
include information about Exchange CAS server/s with different server versions.
For example: an Exchange 2013 client, need to get an Autodiscover infrastructure.
The Exchange 2013 client is located on Exchange site that has three different
Exchange CAS servers.
In the following diagram, we can see a scenario of Exchange infrastructure that
includes three “generations” of Exchange CAS versions.
Exchange client query the Active Directory and get a list of: three Autodiscover URL
address.

The main problem is that the Exchange 2013 client has now is - how to decide
which Exchange CAS server name to choose?
The formula for calculating the mathematical probability for successful
Autodiscover events versus none- successful Autodiscover events, could be quite
complicated.
We need to implement a configuration in which the Autodiscover process will
successfully complete 100% of the times!
To be able to eliminate a scenario in which a “newer Exchange client” will address
an “older Exchange CAS server”, we will need to remove any pointer from the Active
Directory SCP that points Exchange client to the legacy Exchange infrastructure and
maintain Autodiscover pointers only to the Exchange 2013 infrastructure (pointer to
the Exchange 2013 CAS servers).

In our scenario, we will need to “remove” from the Active Directory SCP the pointer
to the: Exchange 2010 CAS server: cas2010-01.o365info.com and the Exchange 2007
CAS server: cas2007-01.o365info.com
When a mail client (2007, 2010 or 2013) will query the Active Directory, the Active
Directory “answer” will include only the name of the Exchange 2013 CAS server.
Exchange CAS 2013 server the Chameleon of
Autodiscover services
In interesting metaphor that we can use for describing the way that Exchange CAS
2013 “behaves” relating to different versions of Autodiscover clients, can be: an
Exchange CAS 2013 as a chameleon.
In the same way that a chameleon change her skin color based on the specific
environment in which she is located and “adapt” herself to the new infrastructure,
the Exchange CAS 2013 is operated in a similar way.

When Exchange 2013 CAS “accept” Autodiscover requests, he will not answer the
Autodiscover client until he verifies the Exchange client version. Based on the
Exchange client version, the Exchange 2013 CAS will implement a “custom flow”
which will end with is Autodiscover response that include Autodiscover information
that was customized to the specific Exchange client.
The source of the Autodiscover information
that Exchange CAS 2013 uses
As mentioned, the Exchange CAS 2013 knows how to provide each of the different
Exchange client Autodiscover clients that specific Autodiscover information that
they need.
The question that can appear is: how does the Exchange CAS 2013 know what the
“right Autodiscover information?
Or in other words, what are the sources if information that is used by the Exchange
CAS 2013 for getting the required Autodiscover information for different type
(versions) of Exchange clients?

The answer is that the Exchange CAS 2013 knows how to address additional
“sources” for getting the require Autodiscover information.
In the following diagram, we can see an example for the different “Autodiscover
flow” that the Exchange 2013 CAS server implements for serving different versions
of Exchange clients.
For example: when the Exchange 2010 client (an Exchange client that his mailbox is
hosted on Exchange 2010 Mailbox server) connects the Exchange 2013 CAS server,
the Exchange 2013 CAS server recognizes the Exchange client as “Exchange 2010
client”. For this reason, he proxy the request to Exchange 2010 CAS server, get the
required Autodiscover information and “deliver” the information to the Exchange
2010 client.
Note – the same concept in which the Exchange 2013 CAS server serves as a focal
point for internal Exchange Autodiscover requests, is implemented for serving an
externalpublic Exchange mail client.

Manage the Autodiscover information in the
Active Directory SCP
Despite the formal declaration that: “this article seriously is not a “how to” articles,
but instead: “general concept and architecture articles”, it’s important to have a
“small taste’” of the “technical part’” of implementing the required Autodiscover
infrastructure updates in an Exchange 2013 coexistence environment.
Update the Active Directory SCP
The way that we use for updating the “internal Autodiscover information” that is
stored in the Active Directory SCP is by using a PowerShell command.
The PowerShell commands that we use are:
 Get-ClientAccessServer – for viewing the information that is “stored” in the
Active Directory SCP.
 Set-ClientAccessServer – for updating the information that is “stored” in the
Active Directory SCP.
To be able to demonstrate the required Autodiscover configurations in an
Exchange 2013 coexistence environment let’s use the following scenario:
The organization has three Exchange versions in an Exchange 2013 coexistence
environment.

To be able to implement the best practice of Autodiscover infrastructure in an
Exchange 2013 coexistence environment, we will need to implement the
“centralized Autodiscover model”.
The “centralized Autodiscover model” will be implemented by: remove any
Autodiscover pointers to the legacy Exchange 2007/2010 CAS and, configure the
internal Autodiscover infrastructure to point the “new Exchange 2013 CAS”.
The namespace of the internal Autodiscover infrastructure
When choosing the: “the namespace of the internal Autodiscover infrastructure” we
can choose a model in which the internal Active Directory namespace is not
identical to the external Autodiscover namespace (disjoint module) or the other
model of identical external and internal Autodiscover namespace.
The current scenario is based on a module in which the internal Autodiscover
namespace is not identical to the Public Autodiscover namespace.
In our scenario, we will “publish” the Exchange CAS 2013 as a central Autodiscover
point using the FQDN (internal name) of the Exchange CAS 2013. The Autodiscover
URL that we will register is based on the Exchange CAS 2013 host
name: sts.o365info.com
In the following diagram, we can see a representation of the tasks that we need to
implement. We will update the existing Autodiscover URL address of the legacy
Exchange CAS server, there are registered at the Active Directory SCP to “point” the
Exchange 2013 CAS.

1. Viewing internal Autodiscover information
To be able to view the current information about the Autodiscover Endpoint, which
appears in the Active Directory SCP, we will use the PowerShell command:
PowerShell
Get-ClientAccessServer | FL auto*
In the following screenshot, we can see the information about the three Exchange
CAS servers (EX01, EX02 and STS).
When looking after the property: AutoDiscoverServiceInternalUri, we can see that
each of the Exchange CAS server “registered himself” at the Active Directory SCP.
Each of the Exchange CAS servers “declare himself” as Autodiscover Endpoint.

Note – technically we can run the PowerShell command Get-ClientAccessServer | FL
auto*
From each of the Exchange CAS server PowerShell CLI but, from my experience, the
best practice is to execute this command from the PowerShell console of the
“newer Exchange version”.
In our scenario: the Exchange CAS 2013 server PowerShell console.
2. Updating the internal Autodiscover information
The task of “removing the information” about the legacy Exchange CAS server
infrastructure, is not implemented by deleting the information from the Active
Directory SCP but instead, by running the PowerShell Set-ClientAccessServer, that
updates the information in the Active Directory SCP so the Autodiscover URL
address will point to the Exchange CAS 2013 server (sts.o365info.com).
The PowerShell command syntax includes the Exchange CAS server name so in
theory, we can run the required Set-ClientAccessServer PowerShell command from
any Exchange CAS server PowerShell console.
From my experience, the best practice is to execute the PowerShell, which will
update the Autodiscover Endpoint URL of a specific Exchange CAS server form the
PowerShell console of the Exchange CAS server.
For example: in case we will use the Exchange CAS 2013 server PowerShell console
for running the Set-ClientAccessServer command that needs to update the

Autodiscover URL address of the Exchange 2010 CAS server (EXO1), the following
error appears:
You can’t make this change because ‘CN=EX01,CN=Servers,CN=Exchange
Administrative Group.
(FYDIBOHF23SPDLT),CN=Administrative Groups,CN=First
Organization,CN=Microsoft
Exchange,CN=Services,CN=Configuration,DC=o365info,DC=local’ is read-only to the
current version of Exchange.
+ CategoryInfo : InvalidOperation: (:) [Set-ClientAccessServer],
CannotModifyCrossVersionObjectException
+ FullyQualifiedErrorId : [Server=STS,RequestId=b041d5d1-c2a3-4117-9dd3-
061253859afc,TimeStamp=11/21/2014 2:11:03
PM] [FailureCategory=Cmdlet-CannotModifyCrossVersionObjectException]
96B3710A,Microsoft.Exchange.Management.System
ConfigurationTasks.SetClientAccessServer
+ PSComputerName : sts.o365info.local
The “right way” for updating the Autodiscover URL address of each if the existing
Exchange CAS servers are by implementing the following procedure:

In the PowerShell console of the Exchange 2010 CAS server (EX01) we will run the
following PowerShell command:
PowerShell
Set-ClientAccessServer –Identity EX01 -AutoDiscoverServiceInt
ernalUri: "https://STS.o365info.local/Autodiscover/Autodiscov
er.xml"
In the PowerShell console of the Exchange 2007 CAS server (EX02) we will run the
following PowerShell command:
PowerShell
Set-ClientAccessServer –Identity EX02 -AutoDiscoverServiceIn
ternalUri:"https://STS.o365info.local/Autodiscover/Autodiscov
er.xml"
In the following screenshot, we can see the results: the information about the three
Exchange CAS servers still appear in the Active Directory SCP (STS, EX01 and EX02)
but when we look at the AutoDiscoverServiceInternalUri value, we can see that the
FQDN name was updated to the Exchange CAS 2013 server FQDN: sts.o365info.com
Additional reading
 Exchange Server 2010 to 2013 Migration – Reviewing Autodiscover Configuration

The Exchange 2013 coexistence article series index page

Exchange 2013 coexistence | Autodiscover infrastructure | Part 2/2 | 12#23

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (20)

Similaire à Exchange 2013 coexistence | Autodiscover infrastructure | Part 2/2 | 12#23

Similaire à Exchange 2013 coexistence | Autodiscover infrastructure | Part 2/2 | 12#23 (20)

Plus de Eyal Doron

Plus de Eyal Doron (20)

Dernier

Dernier (20)

Exchange 2013 coexistence | Autodiscover infrastructure | Part 2/2 | 12#23