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

of 28 | Part 03#23 | The importance of Exchange 2013 CAS in Exchange 2013
coexistence environment | Part 2/2
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
THE IMPORTANCE OF EXCHANGE 2013 CAS
IN EXCHANGE 2013 COEXISTENCE
ENVIRONMENT | PART 2/2 | 3#23
In the current article, we will focus on two main subjects:
1. The essence of the relationship that exists between Exchange client and their
Exchange CAS server. We will review the different scenario in which different
Exchange client addresses the Exchange CAS 2013 asking for a specific
information or a specific service.

2. The meaning of the term: “client protocol connectivity flow” in Exchange 2013
coexistence environment. What is the “parts” that construct the client protocol
connectivity flow.
The current article is a continuation of the previous article: The importance of
Exchange 2013 CAS in Exchange 2013 coexistence environment | Part 1/2
Client protocol connectivity flow | The secret
relationship of Exchange client and his
Exchange CAS server
The term “client protocol connectivity flow” appears many times along the current
article series so it’s important that we will understand the meaning of this term.
In simple words, I relate to the term “client protocol connectivity flow” as a
description of the path or the road on Exchange environment that is implemented
when Exchange clients need to access his data or get a specific Exchange service.

If we want to simplify the term: client protocol connectivity flow we can define two
different “areas”.
In the following diagram, we can see that the first “area” relates to the part in which
different Exchange clients address the Exchange CAS 2013 and ask for “something”
The second “area” is client protocol connectivity flow part which relates to the flow
or the steps that are implemented by the Exchange CAS 2013 “in the background”
or “behind the scenes”. This is that part in which the Exchange 2013 client “forward”
the client request to “other Exchange servers”, that will provide the required
information or a specific service and when this “other Exchange server” reply with
the required information, the Exchange CAS 2013 fetched the information and sent
it to the Exchange client (move again to the first area).
Client protocol connectivity flow | Different
point of views

In the relationships of clientserver who exists between the Exchange clients and
the Exchange CAS server, each of the sides relates to the term “client protocol
connectivity flow” from a different perspective.
1. The Exchange client side
From the Exchange client’s point of view, the term “client protocol connectivity flow”
could be translated into:
 How do I find my Exchange CAS server?
 Where the Exchange service provides a specific service?
 What are the data and the services that I can get from the Exchange CAS server?
2. The Exchange server side
From the Exchange CAS server point of view, the term “client protocol connectivity
flow” is translated into:
 What do I need to “do” for getting the required data and “deliver” the data for my
clients?
 Do I need to provide a specific service for my client or should I instruct my client
to contact other elements that could provide him the required services?

As you can see on the diagram, the term client protocol connectivity flow is not just
“one thing” but instead, a “collection” of events and process.
The “yellow rows” (Number 1 and 4), describe the relationships between the
Exchange CAS server and his Exchange mail clients. The Exchange mail client
addresses the Exchange CAS server asking for “information”. The “information”
could be:
 The data that is stored in the user mailbox.
 Autodiscover information
 Exchange web service information such as information about FreeBusy time
with other users
 “Redirection” – information about “other elements” that can provide the data or a
specific service.
The “back end” section – the white rows (Number 3 and 2), describe the “back end
operation” that the Exchange CAS server “do for his client”.
The options that are available for the Exchange CAS server are:
1. Provide by himself a specific data or service (the option of “provide by himself,”
is relevant only to Exchange CAS server version 2007 or 2010),
2. Proxy the request to Exchange Mailbox server
3. Proxy the request to “other Exchange CAS servers”

4. Send a redirection message, which will inform the Exchange client that he needs
to contact “other elements.”
The responsibilities of Exchange CAS server
The Exchange CAS server has a couple of “commitments” to his clients. To be able
to understand better the relationship between Exchange CAS server and Exchange
clients, let’s briefly review the “services” that Exchange CAS server.

1. Enable Exchange clients to access their mailboxes
Just a quick reminder, in an Exchange environment, the Exchange clients cannot
access their mailbox directly. The only available way for Exchange client to get
accesses his mailbox, is by using the Exchange CAS server as a mediator. Exchange
CAS server except Exchange client’s requests and “fetch” the data from the
Exchange Mailbox server who host the user mailbox “on behalf” of his client.
The Exchange CAS server is responsible for connecting Exchange mail client to their
mailboxes. Most of the time, the Exchange CAS server will “connect” the Exchange
mail client to their mailboxes by proxy the request to Exchange Mailbox server.
Note – the only exception to this rule is a scenario of Exchange 2013/2007
coexistence environment and Exchange 2007 OWA clients. You can read more
information about this scenario in OWA client protocol connectivity flow in
Exchange 2013/2007 coexistence environment | 3/4
In the Exchange 2013 coexistence environment, Exchange 2013 CAS will proxy,
Exchange 2013 client requests to Exchange Mailbox server and Exchange legacy
client’s requests to a legacy Exchange CAS server infrastructure. For example, when
Exchange 2010 address Exchange 2013 CAS in an Exchange 2013 coexistence

environment, asking to get access to his mailbox, Exchange 2013 CAS will locate
available Exchange 2010 CAS and proxy the request to the Exchange 2010 CAS.
2. ProvideDeliver Autodiscover services.
In an Exchange 2013 coexistence environment, the Exchange 2013 CAS is the
element that is responsible for “delivering” Autodiscover services (information) to
Exchange mail client. I use the term “deliver” because it’s important to emphasize
that the Exchange 2013 CAS is not generating the Autodiscover information by
himself, but instead, “fetch” the information form “other Exchange servers”.
 In a scenario in which the Exchange client is Exchange 2007 or Exchange 2013
client, Exchange 2013 CAS will “fetch” the information from the Exchange 2013
Mailbox server.
 In a scenario in which the Exchange client is Exchange 20100 clients, Exchange
2013 CAS will “fetch” the information from Exchange 2010 CAS (Exchange 2013
CAS will proxy the request for the Autodiscover information on behalf of the
Exchange 2010 client)

3. Providedeliver Exchange web services.
Similar to the concept of Autodiscover services, Exchange 2013 CAS is the element
that is responsible for “delivering” the Exchange web services information to
Exchange clients.
I use again the term: “deliver” because the Exchange CAS 2013 server is not the
element that generates, or actually provides the Exchange web services. Instead the
element that is responsible for providing the Exchange web services infrastructure
is the Exchange 2013 Mailbox server or Exchange legacy CAS server.
 In a scenario of Exchange 2013 client, the Exchange clients address the Exchange
CAS 2013 server and ask for the required Exchange web services. Exchange CAS
2013 server will locate the Exchange 2013 Mailbox server and proxy for him the
requests. Exchange 2013 Mailbox server is a real provider of the Exchange web
services.

 In a scenario of Exchange 2007 clients, the Exchange 2007 clients address the
Exchange CAS server with the same version (Exchange 2007 CAS). For example,
Exchange 2007 clients will address the Exchange 2007 CAS when they need
Exchange web services.
The information about the Exchange web services URL for Exchange 2007 is
provided by the Exchange CAS 2013 server in the “Autodiscover phase”.
The information that the Exchange CAS 2013 server provides includes URL
address that “point” to the Exchange 2007 CAS. In an Exchange 2013/2007
coexistence environment, the Exchange 2007 CAS needs to be available for
internal + external Exchange 2007 clients.
 In a scenario of Exchange 2010 clients the way that the Exchange web services
are provided depends on the Exchange 2010 client location.
Internal Exchange 2010 client will use the existing Exchange 2010 CAS
infrastructure for getting Exchange web services.
An external Exchange 2010 client will need to get their Exchange web services
from the Public facing Exchange 2013 CAS because, the Exchange 2010 CAS is not
available for the public Exchange client. The Exchange 2010 client will address the
Public facing Exchange 2013 CAS and the Exchange CAS 2013 server will proxy
the Exchange 2010 client request for Exchange web services to the internal
Exchange 2010 CAS.

The concept of “information” in an Exchange environment
Many times we use the term: ”information” in a sentence such as: Exchange CAS
server provides the required information to his client.
A reasonable question that could appear is: what is this information?
Well, for me, everything that “happened” in the Exchange environment could be
described as: “information”.
For example, when we say that Exchange client access his mailbox, in other words,
we say that the Exchange client gets datainformation that is stored in his mailbox.
When we say that Exchange mail client uses the Autodiscover service for creating a
new Outlook mail profile, we can say, in other words, that the Outlook client gets

the information (Autodiscover information) that includes the required configuration
setting needed for creating an Outlook mail profile.
Other questions regarding the subject of “information” are:
Q1: What is the source of the information?
Q2: Who is the element that delivers the information to the Exchange client?
A1: In an Exchange environment, the only “element” that is authorized to deliver
information to the Exchange client is the Exchange CAS server.
A2: Regarding the question of: What is the source of the information, the answer
depended of the Exchange version and the specific Exchange infrastructure
To be able to better understand meaning of: information provider versus the
information “creator” or “generator” in different Exchange infrastructure, we can
define three major “groups” of Exchange infrastructures:
Exchange CAS 2013 server versus former
Exchange CAS server versions
Exchange CAS 2013 server underwent a significant transformation versus former
Exchange CAS server version such as Exchange 2007 and Exchange 2010.

To encapsulate the essence of the architecture changes in Exchange 2013, we can
say that the “role” of the Exchange 2013 CAS server was reduced into one purpose:
serve as a “smart router”.
The responsibilities of Exchange 2013 CAS server are:
1. Serve as a “smart router/proxy” – the meaning of this responsibility is to: Enable
Exchange clients to reach their destination (Mailbox data)
2. “Deliver” the information to Exchange client – the meaning of this responsibility
is to: “fetch data” such Exchange web services and Autodiscover from “other
Exchange servers” and deliver the data to his client.

Exchange CAS 2013 server serves as “smart router”, which accepts Exchange mail
client requests and, based on specific charters such as the type of the Exchange
client or the specific protocol decides how to “route” the request to the required
destination.
In former versions of Exchange server, such as: Exchange 2007 and Exchange 2010
the Exchange CAS server role was responsible for:
1. Serve as a “smart router/proxy”
2. “Deliver” information to Exchange client
3. Generate information
4. Render protocol data

In a former version of Exchange such as: Exchange 2007, Exchange 2010 the role of
the Exchange CAS server includes additional responsibilities.
Besides of being “smart router” the Exchange CAS server was responsible for many
other tasks.
 Rendering – the Exchange CAS server was responsible for a task that described
as: “rendering”. The meaning if this term is implementing the task of a protocol
translation. The Exchange mail client uses a specific “language”(protocol) and, the
Exchange CAS server “translate” the Exchange mail client language into other
languages which the Exchange Mailbox server can “understand”
 Autodiscover – the element that was responsible for gathering the required
information and generating the Autodiscover information was the Exchange CAS
server.
 Exchange web services – the element that was responsible for providing the
Exchange web services was the Exchange CAS server by himself.

In Exchange 2013, all the “responsibilities” that was mentioned above was “pull out”
from the Exchange 2013 CAS server and was assigned to the Exchange 2013
Mailbox server.
In the Exchange 2013 architecture, the “main load” is lying on the Exchange 2013
Mailbox server shoulders. Exchange 2013 CAS server accepts Exchange 2013 client
requests and, forward (proxy) these requests to the Exchange 2013 Mailbox server.
Exchange 2013 Mailbox server will “do what he needed to do” for example:

generate Autodiscover information or render protocol information and send back
the “digested information” to the Exchange 2013 CAS server.
In the following comparison table, we can see the deference between the Exchange
2013 CAS server architecture and the “legacy Exchange CAS server versions”
(Exchange 2007, 2010).
The main point of this table is that the only responsibility of Exchange 2013 CAS
server is they serve as a gateway between Exchange mail client and the “rest of the
Exchange infrastructure.” Exchange 2013 CAS server will accept the client request
and forward these requests to “other authority” (Exchange Mailbox server) that will
handle all the operations that relates to the Exchange mail client request.
Versus the “lazy behavior” of Exchange 2013 CAS server who Delegates the
authority to the Exchange 2013 Mailbox server, the legacy Exchange architecture if
the Exchange CAS server was based on a different concept in which the Exchange
CAS server was the “owner” many additional tasks such as generating Autodiscover
answers, rendering protocol data, etc.

Exchange 2013 architecture | Exchange CAS 2013 server
Despite that, this article’s seriously deal with the subject of Exchange 2013
coexistence environment, it’s important to understand in the way that Exchange
2013 CAS operates in a native Exchange 2013 environment that includes only
Exchange 2013 servers and Exchange 2013 clients.
In a “native Exchange 2013 environment” the “division of labor” is very clear:
 Exchange 2013 CAS is the component the “delver” information to Exchange
clients and accept Exchange client’s requests that need access to their mailboxes.

 Exchange 2013 Mailbox server is the “component” that “hold the date” (user
mailboxes) and generate required data such as: Exchange web services data and
Autodiscover data.
 Exchange 2013 Mailbox server is the “component” that is responsible for
rendering protocol data meaning “translating” the Exchange client specific
protocol to the “native” Exchange Mailbox server internal protocol.
Exchange 2013 coexistence environment | Exchange 20102007 CAS server
In a “legacy Exchange environment” that’s based on Exchange 2007 or Exchange
2010, the “division of labor” is divided between the Exchange CAS server role and
the Exchange Mailbox server role in the following way:
 Exchange 2007/2010 CAS is the component that: “deliver” information to
Exchange clients and accept Exchange client’s requests that need access to their
mailboxes.
 Exchange 2007/2010 CAS is the component that: It is responsible for rendering
protocol data meaning – “translating” the Exchange client specific protocol to the
“native” Exchange Mailbox server internal protocol.
 Exchange 2007/2010 CAS is the component that is responsible for “generating”
Autodiscover information and Exchange web services information.
 Exchange 2013 Mailbox server is the “component” that “hold the date” (user
mailboxes)

Exchange 2013 architecture | Exchange 2013 coexistence environment
 Exchange 2013 CAS is the component that: “deliver” information to the Exchange
clients and, accept Exchange client’s requests, which need access to their
mailboxes.
 The process of: “rendering protocol data” (“translating” the Exchange client
specific protocol to the “native” Exchange Mailbox server internal protocol) is
implemented by the legacy Exchange CAS server based on the type of the user
mailbox.
For example, in a scenario of Exchange 2010 client, the request will be accepted
by the Exchange 2013 CAS and then, proxy to the Exchange 2010 CAS. The only
exception to this rule is Exchange 2007 OWA client, you can read more
information about this scenario in Exchange 2013/2007 coexistence | Exchange
web service client protocol connectivity flow
 “Generating” Autodiscover information and Exchange web services, information –
will be implemented by the legacy Exchange CAS server based on the type of the
user mailbox. For example, in a scenario of Exchange 2010 client, the request will
be accepted by the Exchange 2013 CAS and then proxy to the Exchange 2010
CAS.
 Hostingkeep the user’s mailboxes – implemented by the legacy Exchange
Mailbox server based on the type of the user mailbox. For example, an Exchange
2010 mailbox will be hosted on Exchange 2010 Mailbox server.

Exchange 2013 coexistence environment –
Exchange 2007 clients versus Exchange 2010
clients
Regarding the relationships of Exchange CAS 2013 server and his Exchange clients,
we can classify the Exchange clients into two major groups:
1. Exchange 2013 – Exchange clients which their mailbox is hosted on Exchange
2013 Mailbox server.
2. “Other Exchange clients” – in this category, we can include Exchange 2007 and
Exchange 2010 client.
Exchange CAS 2013 server and Exchange 2013 client’s relationships
In a scenario, in which the Exchange CAS server is an Exchange CAS 2013 server and
the Exchange client is also “Exchange 2013 client” (Exchange client that his mailbox
is hosted on Exchange 2013 Mailbox server), the relationships between the “server
and the client” are quite simple to explain.
As mention before, in the Exchange 2013 environment the Exchange CAS 2013

server serves as a “smart router” that route Exchange clients requites to other
Exchange servers.
All the standard Exchange services are provided by the Exchange 2013 Mailbox
server.
The Exchange 2013 Mailbox server is responsible for generating Autodiscover
infrastructure, render Exchange client’s protocol, provide web services, etc.
Note – in an Exchange 2013 environment, most of the time each of the Exchange
server holds the two roles: Exchange CAS server and Exchange Mailbox server.
In case that the specific Exchange CAS 2013 server who gets the request is also the
Exchange Mailbox server who host the specific user mailbox, the request will be
proxied to the Exchange Mailbox server on the same server.
In case that the Exchange client mailbox is hosted on another Exchange Mailbox
server, the Exchange CAS 2013 server will address (proxy the client request) the
specific Exchange Mailbox server and “fetch” the data for his client.

Exchange 2013 coexistence environment
serving Exchange 2007 & Exchange 2010
clients
The second part of this article seriously, include a very detailed description of the
client protocol connectivity flow in Exchange 2013/2010 coexistence environment
and Exchange 2013/2007 coexistence environment, but, before we will get into the
specific details, let’s quickly review major difference between Exchange 2007 and
Exchange 2010 client protocol connectivity flow.

Exchange CAS 2013 server and Exchange 2013 client’s relationships
The standard way that Exchange CAS 2013 server use for serving legacy Exchange
clients in an Exchange 2013 coexistence environment is by
1. Proxy the Exchange legacy client request to “legacy Exchange infrastructure”
2. Getting the required datainformation

3. Delivering the datainformation to the legacy Exchange clients
Note – there are to 2 exceptions to the “default proxy behavior”:
1. Exchange 2007 webmail client and, OWA mail client in a scenario of regional
namespace and multiple Public facing Exchange site.
You can read more information about this scenario in the article: OWA client
protocol connectivity flow in Exchange 2013/2007 coexistence environment | 3/4
2. Exchange 2007 Autodiscover client – when Exchange 2007 client asks for
Autodiscover information, the Exchange CAS server doesn’t proxy the request to
Exchange 2007 CAS but instead proxy the request to Exchange 2013 Mailbox
server.
You can read more information about these scenarios in the
article: Autodiscover and Outlook client protocol connectivity flow in Exchange
2013/2007 coexistence environment | 2/4
The following tables include just a brief description of the “logic” that Exchange CAS
2013 server use in an Exchange 2013 coexistence environment.
1. Providing access to the mailbox

On the Exchange 2013 coexistence environment, Exchange CAS 2013 server-client
protocol connectivity flow is based most of the time on the “Proxy” process.
Exchange legacy client such as Exchange 2007/2010 that needs access to their
mailbox content will address the Exchange CAS 2013, Exchange CAS 2013 “find
Outlook” what is the Exchange client version and based on this information, proxy
the Exchange client request to the “suitable” legacy Exchange CAS server.
The exception to the proxy process relates to Exchange 2007 OWA clients. In this
scenario Exchange CAS 2013 will not Proxy the Exchange 2007 client request to the
Exchange 2007 CAS but instead, send a redirection command to the Exchange 2007
browser that includes a “referral” to the Exchange 2007 CAS.
2. Providing Autodiscover services to legacy Exchange clients
From the Exchange legacy client point of view, the Exchange CAS 2013 server is the
“source” for Autodiscover information. As mentioned, the Exchange CAS 2013
doesn’t really “generate” the Autodiscover information, but instead, “fetch” the
Autodiscover information from “other Exchange servers.”

 In a scenario on Exchange 2010 clients, Exchange CAS 2013 gets the Autodiscover
information from Exchange 2010 CAS.
 In a scenario on Exchange 2007 clients, Exchange CAS 2013 gets the Autodiscover
information form the Exchange 2013 mailbox.
3. Providing Exchange web services to legacy Exchange clients
In the Exchange 2013 coexistence environment, the process of providing Exchange
web services to legacy Exchange clients is a little confusing because the Exchange
web services “roles” implement differently based on the Exchange legacy client
version and based on the Exchange legacy client location.
Internal Exchange 2010 client – The Exchange CAS 2013, is not responsible or
involved in the process of “providing Exchange web services”. The Internal
Exchange 2010 client will directly address the Exchange 2010 CAS when he needs
Exchange web services.
External Exchange 2010 client – in a scenario of “public” or external Exchange 2010
client, because the Exchange 2010 CAS is not “exposed” to the public client, the
element that provides the Exchange web services is the Public facing Exchange
2013.
Regarding Exchange 2007 client – The Exchange CAS 2013, is not responsible or
involved in the process of “providing Exchange web services”. Exchange 2007 client
will directly address the Exchange 2007 CAS when he need Exchange web services.

The Exchange 2013 coexistence article series index page

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

Recommended

Recommended

More Related Content

What's hot

What's hot (15)

Viewers also liked

Viewers also liked (12)

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

Similar to The importance of Exchange 2013 CAS in Exchange 2013 coexistence | Part 2/2 | 3#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 2/2 | 3#23