The importance of Exchange 2013 CAS in Exchange 2013 coexistence | 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 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 implemented when Exchange clients need to access his data or get a particular 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 request to “other Exchange servers”, that will provide the required information or a particular service. 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 client\server 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 particular 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 particular 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 in 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 Free\Busy time with other users
• “Redirection” – information about “other elements” that can provide the data or a particular 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 | 3/4 |18#23

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. Provide\Deliver 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 from “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. Provide\deliver 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 the term again: “deliver” because the Exchange CAS 2013 server is not the element that generates, or 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 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 data\information that 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 provide 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 on of the Exchange version and the appropriate Exchange infrastructure

To be able better to understand meaning of information provider vs. the information “creator” or “generator” in various Exchange infrastructure, we can define three major “groups” of Exchange infrastructures:

Exchange CAS 2013 server vs. previous Exchange CAS server versions

Exchange CAS 2013 server underwent a significant transformation vs. previous 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 reduced into one purpose: serve as a “smart router.”

The responsibilities of Exchange 2013 CAS server are:

1. Act 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 sense 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 particular protocol decides how to “route” the request to the required destination.

In previous 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 previous 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 in charge of a task that described as: “rendering”. The meaning if this term is implementing the mission of a protocol translation. The Exchange mail client uses a particular “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 in charge of providing the Exchange web services was the Exchange CAS server by himself.

In Exchange 2013, all the “responsibilities” that 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 “primary 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 difference 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 relate to the Exchange mail client application.

Vs. 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 based on a different concept. 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 “deliver” information to Exchange clients and accept Exchange client’s requests that need access to their mailboxes.
• Exchange 2013 Mailbox server is the “part” 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 2010\2007 CAS server

In a “legacy Exchange environment” 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.
• Hosting\keep 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 vs. Exchange 2010 clients

Regarding the relationships of Exchange CAS 2013 server and his Exchange clients, we can classify the Exchange clients into two broad 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 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 requests to other Exchange servers.

All the standard Exchange services 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.

In case that the particular 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 hosted on another Exchange Mailbox server, the Exchange CAS 2013 server will address (proxy the client request) the particular 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 the 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 data\information
3. Delivering the data\information to the legacy Exchange clients

Note – there are two 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 situation 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 scene on Exchange 2007 clients, Exchange CAS 2013 gets the Autodiscover information from 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 needs Exchange web services.