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

The focus of the current article is the Exchange Autodiscover infrastructure in the 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.

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 receiving 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 particular 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 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 previous 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 in 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 previous 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 select 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 previous 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 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 vs. 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).

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

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 carried out 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:

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.

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 from 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:

Set-ClientAccessServer –Identity EX01 -AutoDiscoverServiceInternalUri: "https://STS.o365info.local/Autodiscover/Autodiscover.xml"

In the PowerShell console of the Exchange 2007 CAS server (EX02) we will run the following PowerShell command:

Set-ClientAccessServer –Identity EX02 -AutoDiscoverServiceInternalUri:"https://STS.o365info.local/Autodiscover/Autodiscover.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