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

internal\private 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.

http://o365info.com/exchange-2013-coexistence-environment-autodiscover-infrastructure-part-22


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

http://o365info.com/




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.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-12/Autodiscover-infrastructure-Single-Active-Directory-site-01.jpg




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





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-12/Autodiscover-infrastructure-Multiple-Active-Directory-site-02.jpg




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.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-12/One-source-for-Autodiscover-information-Exchange-CAS-2013.jpg




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.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-12/Exchange-CAS-2013-server-the-king-of-the-Autodiscover-services.jpg




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.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-12/Autodiscover-infrastructure-internal-environment-1-of-2.jpg




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.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-12/Autodiscover-infrastructure-internal-environment-2-of-2.jpg




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





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-12/The-forbidden-Autodiscover-model-in-Exchange-2013-coexistence-environment.jpg




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.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-12/Autodiscover-infrastructure-Distributed-Autodiscover-infrastructure-model.jpg




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





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-12/Exchange-2013-coexistence-non-recommended-implementation-of-the-Autodiscover-infrastructure.jpg




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.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-12/Autodiscover-infrastructure-Passable-issues-1-of-2.jpg




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.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-12/Autodiscover-infrastructure-Passable-issues-2-of-2.jpg




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.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-12/Centralized-Autodiscover-model-in-Exchange-2013-coexistence-environment.jpg




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 server\s).





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-12/The-dilemma-of-Exchange-client.jpg




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.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-12/Updating-the-Active-Directory-SCP.jpg




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?





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-12/Exchange-CAS-2013-server-the-Chameleon-of-Autodiscover-services.jpg




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

external\public Exchange mail client.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-12/Exchange-Server-2013-as-a-focal-Autodiscover-point-01.jpg




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.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-12/Exchange-versions.jpg




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.





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-12/Configuring-Exchange-2013-as-the-Autodiscover-Endpoint-in-Exchange-2013-coexistence-environment.jpg




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





http://o365info.com/wp-content/gallery/exchange-2013-coexistence-12/Updating-the-internal-Autodiscover-information-001.jpg




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





http://exchangeserverpro.com/exchange-server-2010-2013-migration-reviewing-autodiscover-configuration/





The Exchange 2013 coexistence article series index page





http://o365info.com/the-exchange-2013-coexistence-article-series-index-page

http://o365info.com/exchange-2013-coexistence-environment-and-client-protocol-connectivity-flow-the-prefix

exchange 2013 coexistence | autodiscover infrastructure | part 2/2 | 12#23

Documents