skip to Main Content

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

The essence of the connectivity protocol flow in Exchange environment is the Exchange CAS server. We can relate to the Exchange CAS server is the Gatekeeper that stands between Exchange client and all the rest of the Exchange infrastructure.

For this reason, it is imperative that we get a better understanding of the “what the Exchange CAS server is”, 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 primary 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 for 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 servers. Also, 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 a request from Exchange mail clients.

Exchange CAS server - Decision Making Process

In the following diagram, we can see the “flow” that applied 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).
The Exchange 2013 CAS secret spring of information

A3: in an Exchange 2013 coexistence environment, when the Exchange legacy client addresses the Exchange 2013 CAS, the most valuable 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 hosts the particular user mailbox.
  • The name of the Exchange Mailbox server which is “connected” to the particular 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 located.

Exchange 2013 CAS needs to know what the Exchange Mailbox server version because, based on this information, the Exchange CAS server will choose the “correct” routing path. For example, in case that the Exchange CAS server which queries the Active Directory is Exchange 2013 CAS server, and the Exchange Mailbox server which 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 located. Based on 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.

The information details that are required for the Exchange CAS 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 particular scenario.

Exchange 2013 coexistence environment - client protocol connectivity flow -

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 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 servers will Proxy the requests to the appropriate Exchange server, such as Exchange 2013 Mailbox server in a scene of Exchange 2013 client or legacy Exchange CAS server (Exchange CAS server 2007/2010) in a scene of Exchange legacy clients.
The scenarios in which Exchange 2013 CAS server considered as a focal point

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 primary external namespace or identified and the mechanism that we use for “publishing” the main namespace in the internal network is distinct from the mechanism that we use for publishing the main 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 main 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 “unplug” 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 2013 2010 coexistence environment - switching the pointers to Exchange 2013 CAS

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 207\2010 clients), the Exchange 2013 CAS will “route” (Proxy) the request, to the legacy Exchange CAS server infrastructure (Exchange 2007\2010 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.
Exchange clients and legacy Exchange clients address the Exchange 2013 CAS

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 underlying 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). When we choose to complete the migration process to the “new Exchange 2013 environment,” there will be no “leftovers” that point or direct Exchange client to the “old\Legacy Exchange infrastructure.”

Legacy Exchange infrastructure as a temporary 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 former\legacy 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 entirely 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 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” of 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 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.

Verify that the pointers are set to the Exchange 2013 infrastructure

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 based on the underlying assumption that each of Exchange CAS 2013 server is holding both roles – Exchange Mailbox Server + Exchange CAS server).

The meaning of Exchange CAS 2013 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 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”. Briefly mention that in previous 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 based on the following idea:

  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 the Exchange 2013 coexistence environment, we try to explain the logic of an accurate client protocol connectivity flow or a particular 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 particular client protocol connectivity flow, but technically or physics, the underlying assumption is that one Exchange server holds the two different Exchange roles.

Exchange 2013 CAS - Physical implementation versus logic implementation

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 performed of the “Exchange CAS server” can implement in different ways, in our scope the physical implementation is not necessary 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 meaning of Exchange CAS 2010 server

The same logic 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.

The meaning of Exchange CAS 2010 server

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 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 implement regardless the particular implementation that was selected.

In the following diagram, we can see the workflow logic that will be carried out on an Exchange 2013 coexistence environment project.

Exchange 2013 coexistence environment project - The basic flow

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 to the main corporate site from the Exchange legacy infrastructure to the Exchange 2013 infrastructure.

Exchange 2013 coexistence project phase 1

Step 2: Adding the Exchange 2013 infrastructure to the rest of the Active Directory sites

In this step, we continue the process of “distributing” the Exchange 2013 infrastructure in the remainder of the company site (Madrid site and Los Angles site). Note that the Exchange 2013 infrastructure 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.

Exchange 2013 coexistence project phase 2

Step 3: Removing the legacy Exchange infrastructure

And the last step is to remove or decommission the Exchange legacy infrastructure.

Exchange 2013 coexistence project phase 3

The next article in the current article series

In the next article, we continue to review the subject of – the importance of the Exchange 2013 CAS role in Exchange coexistence environment.

The o365info Team

The o365info Team

This article was written by our team of experienced IT architects, consultants, and engineers.

This Post Has One Comment

Leave a Reply

Your email address will not be published. Required fields are marked *