The importance of Exchange 2013 CAS in Exchange 2013 coexistence | Part 1/2 | 2#23

of 35 | Part 02#23 | The importance of Exchange 2013 CAS in Exchange 2013
coexistence environment | Part 1/2
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
THE IMPORTANCE OF EXCHANGE 2013 CAS
IN EXCHANGE 2013 COEXISTENCE
ENVIRONMENT | PART 1/2 | 2#23
The essence of the protocol connectivity flow in Exchange environment is the
Exchange CAS server. We can relate to the Exchange CAS server is the Gatekeeper

that stand between Exchange client and all the rest of the Exchange infrastructure.
For this reason, it is very important that we get a better understanding of the “what
is the Exchange CAS server”, what does the Exchange CAS server “do” and what how
the Exchange CAS 2013 operate in Exchange 2013 coexistence environment.
The current article and the next article (The importance of Exchange 2013 CAS in
Exchange 2013 coexistence environment | Part 2/2 ) will be dedicated to the
description of Exchange 2013 CAS role in Exchange 2013 coexistence environment.
Exchange 2013 CAS server as a “Smart Router”
The simplest term that I can use for describing the essence of the role of the
Exchange 2013 CAS server, in an Exchange 2013 coexistence environment is: Smart
Router.
I use the term “smart”, because viruses a standard router, which is responsible for
routing a packet from network A to network B, Exchange 2013 CAS needs to handle
much more complicated routing decisions.
The main responsibility of Exchange 2013 CAS in Exchange 2013 coexistence
environment is “direct” Exchange legacy clients (Exchange 2007/2010) to their

destination.
The responsibility of “redirecting the Exchange legacy client” doesn’t mean that the
Exchange 2013 CAS will provide the information or the services by himself but
instead,
1. Get the information from “other resources” such Exchange 2013 Mailbox server
or legacy Exchange CAS servers (Exchange 2007/2010 CAS)
2. Redirect legacy Exchange clients to the “right place”. For example, redirect
Exchange 2007 OWA client to the Exchange 2007 CAS.
Note – In a former version of Exchange such as: Exchange 2007 and Exchange 2010
the Exchange CAS server role includes additional responsibilities such as: rendering
the protocol data, manage Exchange web services, manage the Autodiscover
service and more.
So now, a couple of questions could appear in our mind:

Q1. When we relate to Exchange 2013 CAS is a “Smart Router”, what is the “thing”
that he need to write?
Q2: What is the “source of information” that enables Exchange 2013 CAS to get the
“right routing decision” or the “appropriate response” that he needs to provide to
his Exchange clients?
Q3. What does the “information” that is provided to Exchange 2013 CAS includes?
Q4. What is so “smart” in the process that is implemented by the Exchange 2013
CAS?
A1: the “things” the Exchange 2013 CAS needs to route are:
 Exchange client’s requests for: access the data stored in their mailbox.
 Exchange client’s requests for: Autodiscover information
 Exchange client’s requests for: Exchange web services
Note – In Exchange environment, Exchange client will never have a direct access to
his mailbox, the only way that Exchange client can use to “get their mailbox
content” is via the Exchange CAS server.

A2: The “secret source of information” that provides the Exchange 2013 CAS the
required “data” is the Active Directory. The Active Directory stores information
about all the Exchange infrastructure.
 The “information” about the Exchange infrastructure creates a very clear map
that describes each of the existing Exchange server and very detailed information
about each of this Exchange server, such as article series: the Exchange role,
vision, physical location (Active Directory site), information about an optional
public availability (external URL) and much more.
 The other part of the information related to the Exchange client’s meaning, what
is the exact location of each of the Exchange user mailboxes or in other words?
Who is the Exchange Mailbox server who hosts an active copy of the user
mailbox and what is the Exchange Mailbox server version?
Based on this information, Exchange 2013 CAS can implement the “correct
decision” when he accepts request form Exchange mail clients.

In the following diagram, we can see the “flow” that is implemented in Exchange
environments.
 Exchange mail client addresses the Exchange 2013 CAS (Number 1).
 Exchange 2013 CAS queries the Active Directory looking for information
(Number 1).
 The Active Directory reply with the required information (Number 3).
 Based on the information that he got from the Active Directory, Exchange 2013
CAS can decide about the “next step” (Number 4).

A3: in an Exchange 2013 coexistence environment, when the Exchange legacy client
addresses the Exchange 2013 CAS, the most important information that Exchange
2013 CAS needs to get from the Active Directory is the version of the Exchange
legacy client.
The information about the Exchange legacy version is mandatory because based on
this information Exchange 2013 CAS will know how to handle the request or what
“root path” he should use.
The “order” in which the Exchange 2013 CAS “process” the information that he got
from the Active Directory, could be described as “reverse engineering”.
The first “information item” that Exchange 2013 CAS needs are:

 The name of the Exchange database that host the specific user mailbox.
 The name of the Exchange Mailbox server who is “connected” to the specific
database.
 The version of the Exchange Mailbox server, such as: Exchange version 2007,
2010 or 2013.
 The Active Directory site name in which the Exchange Mailbox server is located.
Exchange 2013 CAS needs to know what the Exchange Mailbox server version
because, based upon this information, the Exchange CAS server will choose the
“correct” routing path. For example: in case that the Exchange CAS server who
queries the Active Directory is Exchange 2013 CAS server and the Exchange Mailbox
server who hosts the user mailbox is Exchange 2010 Mailbox server, the Exchange
2013 CAS server will need to “find” an available Exchange 2010 CAS server and
proxy for him the Exchange client communication request.
The Exchange CAS server needs to know what is the Active Directory site name in
which the Exchange Mailbox server is located because, based upon this information
he will know if he needs to proxy the communication request to local Exchange CAS
server, proxy the request to “remote Exchange CAS server (Exchange CAS server on
the “other Active Directory site”) or maybe, redirect the Exchange client to his
destination Exchange server.

A4. The answer to the question: “why I use the term “smart”, for describing the
process that is implemented by the Exchange 2013 CAS” is: that I really think that
the process that is implemented by the Exchange 2013 CAS “smart”.
The Exchange CAS server needs to be able to get the required information, draws a
picture or a map, which includes the full path from the source to the destination
and decides what is the most appropriate “routing decision” for a specific scenario.

Configuring Exchange CAS 2013 server as a
“Focal Point”
One of the most unclear concepts and at the same time, the most essential concept
for Exchange 2013 coexistence environment is the concept that I described as:
Exchange 2013 as a focal point.

In Exchange 2013 coexistence environment, we are redirecting the “spotlight” from
the existing Exchange infrastructure that now becomes the “legacy Exchange
infrastructure” and aims the “spotlight” to the Exchange 2013 infrastructure, or if

we want to be more accurate to the Exchange CAS 2013 server.
The term: Exchange 2013 CAS should be configured article series a focal point is
“translated” into two meanings:
1. The Exchange 2013 CAS is becoming the focal point for the Exchange
Autodiscover infrastructure. Every Exchange client (native and legacy Exchange
clients), will “relate” to the Exchange 2013 CAS is the Autodiscover Endpoint.
Exchange 2013 CAS will serve as an Autodiscover Endpoint for internal + external
Exchange clients.
2. Exchange client that needs access to their mailboxes – native Exchange clients
(Exchange 2013) and legacy Exchange clients (Exchange 2007/2010), will need to
connect to the Exchange 2013 CAS when they need to access their mailbox data.
In most of the scenarios, the Exchange 2013 CAS serves will Proxy the requests
to the appropriate Exchange server, such as Exchange 2013 Mailbox server in a
scenario of Exchange 2013 client or legacy Exchange CAS server (Exchange CAS
server 2007/2010) in a scenario of Exchange legacy clients.

Switching the primary namespace to Exchange CAS 2013
infrastructure
When we say that “Exchange clients connect Exchange 2013 CAS”, Exchange clients
address the Exchange 2013 CAS by using a “name” (FQDN, if we want to be more
precise).
The naming convention, which we use for “publishing” the Exchange infrastructure
for internal and external Exchange client can be described as the: primary
namespace.

Technically speaking, the Exchange internal primary namespace can be different
from the external primary namespace or identified and the mechanism that we use
for “publishing” the primary namespace in the internal network is different from the
mechanism that we use for publishing the primary namespace in the public
network.
The main “idea” is that all the Exchange clients (native and legacy) should be able to
locate + connect the Exchange 2013 CAS using the primary namespace.
When we add Exchange CAS 2013 into existing Exchange infrastructure, the primary
namespace will need to point to the “new Exchange 2013 infrastructure” instead of
the existing Exchange infrastructure such as: Exchange 2007, 2010 CAS servers.
In other words, we will need to “un-plug” all the existing pointers to the Exchange
legacy infrastructure and update existing pointers to point to the “new Exchange
2013 infrastructure”.

In the following diagram, we can see a representation of this concept. In the
following scenario, the primary namespace
is: mail.o365info.com and autodiscover.o365info.com
 Before we add the Exchange 2013 CAS to the existing Exchange infrastructure,
the primary namespace was pointing to the Exchange 2010 CAS server.
 After we add the “new Exchange CAS 2013 server” to the existing Exchange
infrastructure (this is the actual meaning of the Exchange 2013 coexistence
environment), we will need to “repent” the primary namespace of the Exchange
CAS 2013 server.

Exchange mail client requests for accessing mailbox content
In an Exchange environment, Exchange clients cannot access directly their mailbox,
but instead, they need to address the Exchange CAS server who will proxy their
request to the appropriate Exchange Mailbox server or redirect them to the
appropriate Exchange CAS server (such as the scenario of Exchange 2007 OWA
clients).

A reasonable, logical assumption could be that each of the Exchange client versions
should connect with the Exchange CAS server from the same version.
For example, Exchange 2010 client will need to address Exchange 2010 CAS, etc.
Theoretically, this assumption could seem to write but, in an Exchange 2013
coexistence environment, this assumption is not correct!
All the Exchange clients: Exchange 2013 native client + Exchange legacy clients
should “know” and communicate only with the Exchange 2013 CAS server.
 In case that the Exchange client is: “Exchange 2013 client”, the Exchange 2013
CAS will “route” (Proxy) the request to the Exchange 2013 Mailbox server.
 In case that the Exchange client is: “legacy client” (Exchange 2072010 clients), the
Exchange 2013 CAS will “route” (Proxy) the request, to the legacy Exchange CAS
server infrastructure (Exchange 20072010 CAS server) or other routing decision
such as: proxy the request to Exchange 2013 Mailbox server in a scenario of
Exchange 2007 client that requests Autodiscover information.

Reflections, questions & Answers about
Exchange 2013 coexistence
Q1: Does the requirement for: “configuring Exchange 2013 CAS as a focal point” is
mandatory?
Q2: Why do I need to implement the configuration of: “Exchange 2013 as a focal
point”?
Q3: In the current article, the term “pointers” mention a couple of times, what is the
meaning of these “pointers”?
There are a couple of optional answers for this question:

A1: the answer is “Yes”
A2: There are a couple of optional answers for this question:
1. Legacy Exchange infrastructure as a temporary infrastructure
The most important thing that we need to remember regarding the Exchange 2013
coexistence environment, is that the basic assumption is that “someday” (in the
near or far future), we will completely remove the legacy Exchange infrastructure
after we successfully have migrated all the legacy mailboxes to the “new Exchange
infrastructure” (Exchange 2013 infrastructure in our scenario).
For this reason, we are implementing a configuration in which everything will be
“pointed” or “redirected” to the Exchange 2013 infrastructure.
Exchange 2013 CAS is the element that “decide” what to do with the legacy
Exchange client communication request (proxy or redirect these requests to the
legacy Exchange infrastructure) and, in the day that we will complete the migration
process to the “new Exchange 2013 environment”, there will be no “left overs” that
point or direct Exchange client to the “oldLegacy Exchange infrastructure”

2. Exchange 2013 and the backward compatibility
The concept of “backward compatibility” in Exchange environment is very simple to
understand: new Exchange version “knows how to talk” to be formerlegacy
Exchange versions but not vice versa.
For example: Exchange 2013 knows how to accept requests from a variety of
Exchange clients such as: Exchange 2007, 2010 and Exchange 2013 and know how
to “reply” to this request or what to do with the Exchange client communication
requests.

Contrary the backward compatibility concept, older versions of Exchange CAS
servers are not fully compatible with a “new Exchange client”
For example: theoretically, Exchange 2007 server can provide Autodiscover services
to the Exchange 2013 clients (an Exchange client that their mailbox is hosted on
Exchange 2013 Mailbox server) but the information will be partial and will not
include additional information that can provide only by Exchange 2013 CAS server.
Update existing pointers to point to the “new
Exchange 2013 infrastructure”
The implementation of the concept which I described as: Using the Exchange 2013
as a focal point is done by “removing the pointer” that exist in the legacy Exchange
infrastructure and update these pointers to the “new Exchange 2013 infrastructure”
or we want to be more accurate: to the new Exchange 2013 CAS server.
There are a couple of “translations” to the term pointers:

1. Autodiscover infrastructure
When we implement Exchange 2013 coexistence environment, we need to “re-
paint” the internal and the external Autodiscover infrastructure to the “Exchange
2013 CAS server” (the existing Exchange infrastructure includes “pointers” to the
Exchange 2010 or Exchange 2007 infrastructure).
In the following diagram, we can see an example of the process which I describe as:
“Removing the pointer” that exist in the legacy Exchange infrastructure.
In our scenario, the organization uses an Exchange 2010 infrastructure. The “focal
point” of this infrastructure is the Exchange 2010 CAS server. The Autodiscover
services for external and internal Exchange clients will be provided by the Exchange
2010 CAS server.
2. Outlook infrastructure
The Exchange 2010 CAS server will serve as a focal point for additional services
such as for Outlook mail client. Each of the Exchange clients that use Outlook, will
relate to the Exchange 2010 CAS server as an: RPC Endpoint.
When we use Exchange 2013 coexistence environment, we add to the existing
Exchange environment the Exchange 2013 infrastructure. Now we have two types
of Exchange clients: Exchange 2010 clients and Exchange 2013 clients.
Note – the term Exchange 2010 clients relate to users whom their mailbox is hosted
on Exchange 2010 Mailbox server.
Exchange 2013 coexistence environment, we define the Exchange 2013 CAS server
as a focal point for the 2010 clients and Exchange 2013 clients. Each of the
“standard Exchange services” such as: Autodiscover, Outlook, will point to the
Exchange 2013 CAS server.
When the Exchange 2013 CAS server gets a communication request from Exchange
clients, he will decide “what to do” with the request based upon the Exchange
client’s version.

The term: “Exchange CAS 2013” server
In the following article series, will we mention the term: “Exchange CAS 2013 server”
hundreds of times. For this reason, it’s important to clarify this term.
Q1: When we say: Exchange CAS 2013 server, what do we mean?
Do we mean Exchange Mailbox server or Exchange CAS 2013 server?
A1: Technically, the term: “Exchange CAS 2013 server” relate to the booth of the
Exchange server roles, and Exchange 2013 architecture is based on the basic
assumption that each of Exchange CAS 2013 server is holding both roles: Exchange
Mailbox server + Exchange CAS server).

Most of the time, when we use the term: “Exchange 2013 server”, the meaning is
“Exchange CAS 2013 server”. In the Exchange 2013 coexistence environment, the
“hero” or the element that makes the noise is the Exchange 2013 CAS server.
In the Exchange 2013 architecture, the Exchange 2013 Mailbox server has very
important and crucial responsibilities, but most of the time, he remained in the
background.

Exchange 2013 CAS | Physical versus logic
implementation
An additional important concept that I would like to emphasize is the concept of the
Physical versus logic implementation of the Exchange 2013 CAS.
We will not get into a detailed description of the history of Exchange CAS server
Architecture and the specific charters of the “legacy Exchange CAS server
infrastructure” but briefly mention that in former versions of Exchange server, such
as: Exchange 2007 and Exchange 2010 the Architecture of “Exchange server role”
was based on the following concepts”:

1. A very clear separation of Exchange roles. Each of the Exchange “role” is
dedicated to a very specific task or set of task
2. The best practice or the recommendation was to implement a physical Exchange
role separation. The simple meaning is: allocate a dedicated physical server for
each of the Exchange roles and in case of multiple Active Directory sites, a
dedicated Exchange server in each of the sites.
Regarding the “Exchange 2013 CAS Architecture” we can see that the Architecture
logic is almost the opposite to the Architecture concepts of Exchange CAS legacy.
Exchange 2013 CAS Architecture is based on the following concept:
1. Minimize significantly the number of Exchange server roles – in the Exchange
2013 architecture, there are only two Exchange server roles versus five server
role in the Exchange CAS legacy architecture.
2. The best practice or the general recommendation is not to use a separated
physical server for each of the Exchange server roles, but instead to “bind” or
“attach” the two different Exchange 2013 server roles (Exchange CAS server +

Exchange Mailbox server) in one physical server.
My point is that in an Exchange 2013 environment and in the Exchange 2013
coexistence environment, we try to explain the logic of a specific client protocol
connectivity flow or a specific process flow, I relate to the two Exchange 2013 server
role separately. For example: the Exchange CAS server proxy the request to the
Exchange 2013 Mailbox server.
Logically, this is the exact description of what Happens in a specific client protocol
connectivity flow, but technically or physics, the basic assumption is that one
Exchange server holds the two different Exchange roles.

Exchange CAS server single server or an array?
The term: “Exchange CAS server” is used for representing the specific Exchange role
and his part in the client protocol connectivity flow.
The implementation of Exchange CAS server can be implemented as a single
Exchange CAS server or as an array of Exchange CAS servers.
Despite the fact that the physical implemented of the “Exchange CAS server” can be
implemented in different ways, in our scope the physical implementation is not
important or not related because when we describe the client protocol connectivity
flow we describe the “logic flow” of the communication channel. When we say that
Exchange mail client address Exchange CAS server, it doesn’t matter of the
Exchange CAS server = single server or an array of Exchange CAS servers that are
“represented” by load balancing.

The same logic is implemented when using the term Exchange 2010 CAS server.
The “translation” of this term, can be: a single Exchange 2010 CAS or an array of
Exchange 2010 CAS that is represented by the load balancer.

Exchange 2013 coexistence project | Phases
and Life cycle
Along this article seriously, we will mention the term: Exchange 2013 coexistence
environment, tens and perhaps hundreds of times, so it looks like we should spend
some time for a brief description of this term and of the “Exchange 2013
coexistence environment – Life cycle”
Technically, the term “Exchange 2013 coexistence” can be implemented in many
ways. The specific “way” that the Exchange 2013 coexistence environment will be
implemented depends on the organization physical infrastructure, the specific
organization needs, etc.
Although we can “build” the Exchange 2013 coexistence environment in many ways,
there are a couple of basic concepts that will always be implemented regardless the
specific implementation that was selected.
In the following diagram, we can see the workflow logic that will be implemented on
an Exchange 2013 coexistence environment project.

To be able to demonstrate the implementation of Exchange 2013 coexistence
environment, let’s based on the following scenario:
An international organization that has three sites.
The “headquarters site” – New York site, include a “mixture” of Exchange server
version: Exchange 2007 + Exchange 2010.
Additional company sites are: Madrid site and Los Angles site.
 Madrid site – include Exchange 2007 infrastructure.
 Los Angles – include Exchange 2010 infrastructure.
The result of the Exchange 2013 coexistence project is: complete the migration
process to the Exchange 2013 environment and decommission all the Exchange
legacy environments.
Step 1: Add the Exchange 2013 infrastructure in the main corporate site
In this step, we add the “new Exchange 2013 infrastructure” to the main corporate
site and + update the primary namespace to “point” to the Exchange 2013
infrastructure (Exchange 2013 CAS).

The additional site (Madrid site and Los Angles site) will continue to use the “legacy
Exchange infrastructure” (Exchange 2007 and Exchange 2010).
Exchange clients from all the company sites: the main corporate site (New York site)
and Exchange client from the rest of the company site (Madrid site and Los Angles
site) will address the Exchange 2013 CAS in the main corporate site as their
Autodiscover Endpoint.
After we complete all the required configuration setting that relate to the “new
Exchange 2013 infrastructure”, the next step will be: migrating all of the user’s
mailboxes in the main corporate site from the Exchange legacy infrastructure to the
Exchange 2013 infrastructure.
Step 2: Adding the Exchange 2013 infrastructure to the reset of the Active
Directory sites
In this step, we continue the process of “distributing” the Exchange 2013
infrastructure in the rest of the company site (Madrid site and Los Angles site). Note

that the Exchange 2013 infrastructure is added in parallel with the existing
Exchange legacy infrastructure.
For example, the Exchange 2013 that we add to Madrid site will coexist with the
Exchange 2010 infrastructure.
The next step will be: migrating all the user’s mailboxes from the Exchange legacy
infrastructure to the Exchange 2013 infrastructure.
Step 3: Removing the legacy Exchange infrastructure
And the last step is to remove or decommission the Exchange legacy infrastructure.

The Exchange 2013 coexistence article series index page

The importance of Exchange 2013 CAS in Exchange 2013 coexistence | Part 1/2 | 2#23

Recommended

Recommended

More Related Content

What's hot

What's hot (9)

Viewers also liked

Viewers also liked (20)

Similar to The importance of Exchange 2013 CAS in Exchange 2013 coexistence | Part 1/2 | 2#23

Similar to The importance of Exchange 2013 CAS in Exchange 2013 coexistence | Part 1/2 | 2#23 (20)

More from Eyal Doron

More from Eyal Doron (20)

Recently uploaded

Recently uploaded (20)

The importance of Exchange 2013 CAS in Exchange 2013 coexistence | Part 1/2 | 2#23