Professional Documents
Culture Documents
The current article is the continuation of the previous article: Exchange 2013
coexistence environment | Autodiscover infrastructure | Part 1/2
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.
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.
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.
has a local Exchange CAS server, which serve as an Autodiscover Endpoint for the
local Exchange clients.
To be able to demonstrate this concept, lets use the following scenario.
On organization have three Active Directory site and two Exchange sites (one of the
company sites doesnt include Exchange infrastructure).
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.
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 doesnt 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 servers 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.
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!
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.
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 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.
Autodiscover URL address of the Exchange 2010 CAS server (EXO1), the following
error appears:
You cant 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.
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