Exchange CAS server | Providing Exchange clients access to their mailbox | Part 06#36

Page 1 of 24 | Exchange CAS server | Providing Exchange clients access to their mailbox |

Part 06#36

Written by Eyal Doron | o365info.com | Copyright © 2012-2015

Exchange CAS server | Providing

Exchange clients access to their

mailbox |Part 06#36

In this article, I would like to review the secret romance of Exchange mail clients

and “his” Exchange CAS server.

Exchange clients have very special and interesting relationships with their Exchange

CAS server and, the Autodiscover infrastructure is the glow that unified these two

lovers.

http://o365info.com/exchange-cas-server-providing-exchange-clients-access-to-their-mailbox-part-06-of-36


https://il.linkedin.com/in/eyaldoron1

http://o365info.com/


Part 06#36


Continue with our romantic metaphor, the truth is that the Exchange client can

have these “relationships” with any available Exchange CAS server.






Part 06#36


In simple words – the Exchange client totally depends on an Exchange server who

holds the CAS server role but the Exchange client is not “tied up” to a specific

Exchange CAS server.






Part 06#36


So what is so special about these “secret relationships” between Exchange client

and the Exchange CAS server?

In the following article, we will analyze the charters of these relationships and how

the Autodiscover does is related or involved in these relationships.






Part 06#36


What is the Exchange CAS server?

In a modern Exchange environment, each of the Exchange servers is “holding” a

specific role (or a couple of Exchange server roles).






Part 06#36


We will not get into the specific charters for each of the “Exchange server roles” and

a comparison of the difference between: Exchange 2007, 2010 and Exchange 2013

environment, but instead, emphasize two of the Exchange server roles: Exchange

CAS role and Exchange Mailbox role.

To be able to connect the Exchange infrastructure, an Exchange client will need to

find + connect an Exchange CAS server.

The way that the Exchange mail client finds or locates “his Exchange CAS server” is

by using the Autodiscover service.

For this reason, the Autodiscover process takes up such an important part in the

Exchange infrastructure because, without a proper completion of the Autodiscover

process, Exchange client:

Cannot create a new Outlook mail profile.

Cannot connect to his mailbox.

Cannot get information about available Exchange web services.






Part 06#36


Cannot recover from errors and respond to changes in the Microsoft

Exchange environment automatically.

Additional reading about the Exchange server role architecture

Exchange Server 2013 SP1 Architecture Poster

Exchange 2013 Server Role Architecture

Understanding Exchange 2013 Server Roles in the Simplest way

Server roles in Exchange 2013 hybrid deployments

Server roles in Exchange 2013/Exchange 2010 hybrid deployments

Server roles in Exchange 2013/Exchange 2007 hybrid deployments

The Exchange CAS server responsibilities

Before we go into the “details” or the relationships, let’s review the Exchange CAS

server “responsibilities” in high-level view.

The following screenshot is taken from the- Exchange Server 2010 Architecture

Poster – in the diagram, we can see a detailed description of the “responsibilities” of

the Exchange 2010 server that hold the CAS role.





http://www.microsoft.com/en-us/download/details.aspx?id=42542

http://blogs.technet.com/b/exchange/archive/2013/01/23/exchange-2013-server-role-architecture.aspx

http://social.technet.microsoft.com/wiki/contents/articles/16953.understanding-exchange-2013-server-roles-in-the-simplest-way.aspx

http://technet.microsoft.com/en-us/library/jj659051(v=exchg.150).aspx

http://technet.microsoft.com/en-us/library/dn393966(v=exchg.150).aspx

http://technet.microsoft.com/en-us/library/dn151302(v=exchg.150).aspx




Part 06#36


The Exchange CAS server provides many types of services to “his clients.”

We can be even more dramatic and say that – without the Exchange CAS server,

Exchange client cannot communicate or connect to the Exchange infrastructure.

As we can see in the following diagram, we can classify the Exchange CAS server

“services” into four major groups.

Each of these “groups,” is equally important for Exchange clients to be able to

connect and use the Exchange infrastructure.






Part 06#36


THE EXCHANGE CAS SERVER THREE MAJOR RESPONSIBILITY’S TRIANGLE

The exchange CAS server is responsible for the three major tasks:

1. Providing Exchange clients with access to their mailboxes.

2. Providing Web services \ Access to Web services for Exchange clients.

3. Providing information (Autodiscover information) for Exchange clients.

The rest of the current article will be dedicated to the task described as:

Providing Exchange clients access to their mailbox.

The next article – Exchange CAS server as information + Web service provider | Part

07#36, will be dedicated to the Exchange CAS server tasks described as:

1. Providing Web services \ Access to Web services for Exchange clients.

2. Providing information (Autodiscover information) for Exchange clients.





http://o365info.com/exchange-cas-server-as-information-web-service-provider-part-07-of-36

http://o365info.com/exchange-cas-server-as-information-web-service-provider-part-07-of-36


Part 06#36


Providing Exchange clients access to their mailbox

In this section, we focus on the Exchange CAS server job of serving as a “proxy” or a

“mediator” between Exchange client and their mailbox that is hosted on the

Exchange server who holds the mailbox role.






Part 06#36


In a modern Exchange environment, the only way that Exchange client can use for

connecting his mailbox is, via the Exchange CAS server.






Part 06#36


Exchange client such as the Outlook client, cannot access directly their mailbox,

which is hosted on Exchange server who has the role of Exchange mailbox server.

The way that Outlook client access the user mailbox is – through the Exchange

server who has the CAS role.






Part 06#36


Exchange mail client’s classification

In the following section, we will describe the flow that is used for Autodiscover

clients. For this reason, it’s important that we will use some kind of general

classification that relates to the Exchange clients.

The most prominent example for Autodiscover client is the Outlook client.

ActiveSync client and OWA client can also consider as “Autodiscover client” but this

client is not so heavily depended on the Autodiscover services.

An additional classification that we should use is the different flow that is

implemented by Outlook client that are located on the internal private network

(access to Active Directory) versus the Autodiscover flow that is implemented by the

outlook client that located on a public network or in a network in which they cannot

access the Active Directory.






Part 06#36


The exchange CAS server and the transparency concept

| Different proxy scenarios

One of the most basic concepts of the relationships between Exchange client and

the Exchange CAS server the “transparency concept”.

Exchange client doesn’t need to be aware of the complex Exchange infrastructure

that can include a large number of servers, tens or even hundreds of servers.

Instead, they only need to find an Exchange CAS server.

The Exchange CAS server is the element the “stand in the middle” and separate

between the Exchange client and the Exchange mailbox server who hosts the user

mailbox.

The Exchange clients don’t need to know:

1. The name of the Exchange mailbox server who hosts his mailbox

2. The physical location of the Exchange mailbox server who hosts his mailbox






Part 06#36


The significant advantage of using the concept of “man in the middle” (aka the

Exchange CAS server) is that, the “task” of locating and connecting the Exchange

mailbox server who hosts the user mailbox, is hidden from the Exchange clients.

This concept of “transparency”, enables the Exchange infrastructure to provide

many types of services and solutions.

For example:

Scenario 1: external mail client

In a scenario in which external mail client needs access to his mailbox, there is no

need to “expose” the internal Exchange mailbox server who hosts the user’s

mailboxes.

Instead, all we need to do is configure at least one Exchange CAS server as a -Public

facing Exchange CAS server.

The external Exchange mail client request will be accepted by the Public facing

Exchange CAS server and the Exchange CAS server “know” how to locate and

connect the specific internal Exchange mailbox server, which hosts the user

mailbox.

Scenario 2: Exchange mailbox server redundancy

In case that the organization implements a clustering mechanism in which the

user’s mailbox database is replicated to the different Exchange site, in case that the

“original” (active) Exchange mailbox server is not available, the Exchange CAS server

“know” how to connect the Exchange clients to the “other” Exchange mailbox store.






Part 06#36


In the following diagram, we can see an example to different kind of passable

scenarios, in which the Exchange CAS server needs to “serve” the request of

Exchange clients.






Part 06#36


External versus internal Outlook client | Using different

Autodiscover mechanism

When Outlook clients try to locate and connect his Exchange CAS server, the

Autodiscover process that is implemented by the internal Outlook client is different

from the Autodiscover process that is implemented by external Outlook clients.

In addition, the Autodiscover information that the Exchange CAS server provides to

the internal Outlook client is different from the information that the Exchange CAS

server provides to external Outlook mail clients and so on.






Part 06#36


In the following section, we will review some of the Autodiscover common

scenarios and the different characters of the “relationships” that realized between

Exchange clients and their Exchange CAS server.

To be able to simplify the description, we will base on a scenario in which the mail

client is Outlook.

Scenario 1: Internal Outlook Exchange client | Exchange mailbox server on

the same Active Directory site

The charters of this scenario, are as follows:

A user in the internal network tries to create a new Outlook mail profile.

When the user activates the New Outlook mail profile wizard, the following flow will

be implemented:

1. Outlook will locate the name of available Exchange CAS server\s by query the

local Active Directory.

2. Active Directory replay with a list of available Exchange CAS server\s using the

private or the “internal name” of the existing Exchange CAS server\s.






Part 06#36


3. Using the Exchange CAS server names who appear in the list, Outlook will

randomly pick one of the names and try to submit a connection request to the

Exchange CAS server.

4. The Exchange CAS server will query the Active Directory, looking for the name of

the Exchange mailbox server who hosts the specific user mailbox.

5. The Exchange CAS server recognizes two charters of the “Exchange client” (the

Outlook mail client):

That the mail client is a – MAPI mail client + that the mail client is an “internal

mail client”.

6. The exchange CAS server will generate Autodiscover response, which includes

information that is relevant for Outlook mail clients and includes “sections of

information.”

The information that will be provided to include URL’s address of the available

Exchange web services. The URL address that includes din the Autodiscover

response will include:

Internal host names + external host names (internal and external URL address).

Internal URL addresses are not exposed to a host from the public network and

can be used only by the internal mail client.

7. The Exchange CAS server will connect the “destination Exchange mailbox server”

and start the process of “proxy” the information from the Exchange mailbox

server (the mailbox content) to the internal Outlook mail client and vice versa.

Scenario 2: External Exchange Outlook client

When the Exchange mail client is located in a public network, the only way that the

external mail client can use for reaching his: “internal mailbox” (the internal

Exchange infrastructure”) is via the Exchange CAS server who configured as -Public

facing Exchange CAS server.

In this scenario, the Exchange CAS server will be published by using a public name

and public IP address. To be able to get the required services, Exchange mail client

will need to identify and create an encrypted communication channel (secure

channel) with the “Public facing Exchange CAS server”.

The Exchange client requests, to access their “internal mailbox” is located on the

internal Exchange mailbox server, can be implemented only by the mediation of the

“public facing Exchange CAS server”.






Part 06#36


The Exchange CAS server, will accept Exchange client requests and implemented a

“proxy mechanism” in which the Exchange CAS server “present” himself to the

internal Exchange servers as the mail client that he “represent”.

When the Exchange CAS server gets the required data from the user mailbox, the

Exchange CAS server will send back the data to the external mail client.

Note – in many scenarios, the Exchange CAS server doesn’t relay “exposed” to

external clients, but instead, a Firewall server, such as ISA\TMG serves as the “public

entity” that accepts external Exchange client communication requests and

“forward” these requests to the Exchange CAS server.

When the user activates the New Outlook mail profile wizard, the following flow will

be implemented:

1. Outlook will locate the name of available Exchange CAS server\s by “generating”

the Exchange CAS server name. Outlook will use the SMTP domain name form

the recipient E-mail address as a “passable name” of the Exchange CAS server

(the Public facing Exchange CAS server).

2. Outlook tries to submit a connection request to Autodiscover Endpoint meaning

the Public facing Exchange CAS server.

3. The Public facing Exchange CAS server will query the Active Directory, looking for

the name of the Exchange mailbox server who hosts the specific user mailbox.






Part 06#36


4. The Exchange CAS server recognizes two charters of the “Exchange client” (the

Outlook mail client):

That the mail client is a – MAPI mail client + that the mail client is an “external

mail client”

5. The Exchange CAS server will generate Autodiscover response, which includes

information that is relevant for Outlook mail clients and includes, “sections of

information.”

The information that will be provided includes – the public URL’s address of the

available Exchange web services. The URL address that included in the

Autodiscover response will include:

only external\public host names.

6. The Public facing Exchange CAS server will connect the “destination Exchange

mailbox server” and start the process of proxy the information from the

Exchange mailbox server (the mailbox content) to the external Outlook mail

client and vice versa.

Scenario 3: External Exchange client | two Exchange site

two Public facing Exchange CAS servers

Another interesting service, that the Exchange CAS server is capable of providing

described as –redirection.

In an Exchange enterprise environment such as a large company that has a couple

of sites worldwide, a common scenario is a scenario of multiple Exchange sites.

In this scenario of multiple Exchange sites, the organization can decide to

implement one of the following scenarios:

Option 1: “Expose” only a specific Exchange CAS server who will serve as a “focal

point” or gateway for all the Exchange clients worldwide (this is the scenario that

was described in the former section which described as – Proxy services)

Option 2: Publish more than one Public facing Exchange CAS server or a Public

facing Exchange CAS server for each of the company sites.

In a scenario of multiple Exchange sites + multiple Public facing Exchange CAS

server, there are two main scenarios for managing the way that external mail client

will find the required Exchange CAS server.






Part 06#36


Configure a single Public facing Exchange CAS server is the focal point.

In this scenario, although the Exchange infrastructure includes more than one

“public facing Exchange CAS server”, only one “public facing Exchange CAS server”

will be mapped to the Autodiscover records for the public domain name.

In our example, we have two physical Active Directory and Exchange sites: New

York site and Los Angel’s site.

The public domain name is, o365info.com and the Autodiscover record –

autodiscover.o365info.com is mapped to the public IP address of the “New York

Public facing Exchange CAS server” using the Public IP address: 212.25.80.239

In our scenario, a user named Bob that uses the E-mail address

– [email protected] needs to connect his Exchange mailbox, which is hosted on the

Exchange mailbox server in the Los angel’s site.

When the Outlook client starts the Autodiscover process, he will find and connect

the “New York site Public facing Exchange CAS server”.






Part 06#36


The “New York site Public facing Exchange CAS server” knows that

Bob’s mailbox is on another Exchange site (Los angel’s site)

That there is a Public facing Exchange CAS server on the Los angel’s site that

could serve an external mail client request.

Because of this information, the “New York site Public facing Exchange CAS server”

will not serve the Exchange client by himself and instead, send redirection

instructions” to the external Outlook Exchange client.

The redirection instructions include the name (FQDN) of the “Los Angeles site Public

faces Exchange CAS server”.

The external Exchange clients start the process all over again, but this time, the

Exchange Outlook client is trying to connect the “Los Angeles site Public facing

Exchange CAS server”.

Given that the user provides the correct credentials and the “Los Angeles site Public

facing Exchange CAS server” has the required public certificate, the “Los Angeles

site Public facing Exchange CAS server” will locate the Exchange mailbox server who

hosts Bob’s mailbox and proxy the connection request back and forward between

the internal Los Angeles Exchange mailbox server and the external Exchange client

(Bob).






Part 06#36


Additional reading

Understanding Proxying and Redirection

Microsoft Exchange 2010 – Using Proxying and Redirection (Part 1)

Microsoft Exchange 2010 – Using Proxying and Redirection (Part 2)

How Exchange Server 2010 CAS Proxy & Redirection works for Exchange

ActiveSync

Exchange 2013 interoperability with legacy Exchange versions

Client Connectivity in an Exchange 2013 Coexistence Environment

Understanding Client Access Protocol Connectivity Flow – Microsoft Exchange

Server 2013





http://technet.microsoft.com/en-us/library/bb310763.aspx

http://pei.com/2012/01/microsoft-exchange-2010-%E2%80%93-using-proxying-and-redirection-part-1

http://pei.com/2012/03/microsoft-exchange-2010-%E2%80%93-using-proxying-and-redirection-part-2/

http://charlesgate86.wordpress.com/2012/01/30/how-exchange-server-2010-cas-proxy-redirection-works-for-exchange-activesync/

http://charlesgate86.wordpress.com/2012/01/30/how-exchange-server-2010-cas-proxy-redirection-works-for-exchange-activesync/

http://vanhybrid.com/2012/10/09/exchange-2013-interoperability-with-legacy-exchange-versions/

http://blogs.technet.com/b/exchange/archive/2014/03/12/client-connectivity-in-an-exchange-2013-coexistence-environment.aspx

http://charlesgate86.wordpress.com/2013/10/15/understanding-client-access-protocol-connectivity-flow-microsoft-exchange-server-2013/

http://charlesgate86.wordpress.com/2013/10/15/understanding-client-access-protocol-connectivity-flow-microsoft-exchange-server-2013/

Documents

Exchange CAS server | Providing Exchange clients access to their mailbox | Part 06#36