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 unusual and exciting relationships with their Exchange CAS server and, the Autodiscover infrastructure is the glow that unified these two lovers.

Continue with our romantic metaphor; the truth is that the Exchange client can have these “relationships” with any available Exchange CAS server.

In simple words – the Exchange client entirely depends on an Exchange server which holds the CAS server role, but the Exchange client is not “tied up” to a particular Exchange CAS server.

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.

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).

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 of 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.
• Cannot recover from errors and respond to changes in the Microsoft Exchange environment automatically.

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 holds the CAS role.

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.

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.

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.

In a modern Exchange environment, the only way that Exchange client can use for connecting his mailbox is, via the Exchange CAS server.

Exchange client such as the Outlook client, cannot access directly their mailbox, which hosted on Exchange server which has the role of Exchange mailbox server.

The way that Outlook client access the user mailbox is – through the Exchange server which has the CAS role.

Exchange mail client’s classification

In the following section, we will describe the flow that 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 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) vs. the Autodiscover flow that is performed by the Outlook client that found on a public network or, in a network in which they cannot access the Active Directory.

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 which hosts his mailbox

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 which 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 which 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 accepted by the Public facing Exchange CAS server and the Exchange CAS server “know” how to locate and connect the particular 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 replicated to the different Exchange site, in the event 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.

In the following diagram, we can see an example to different kind of possible scenarios, in which the Exchange CAS server needs to “serve” the request of Exchange clients.

External vs. 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.

Also, 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.

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 reply with a list of available Exchange CAS server\s using the private or the “internal name” of the existing Exchange CAS server\s.
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 which hosts the particular 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 CAS exchange 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 listed in the Autodiscover response will include:
   Internal host names + external host names (inner and outer 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 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 which configured as -Public facing Exchange CAS server.

In this scenario, the Exchange CAS server will be published by using a known 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” located on the internal Exchange mailbox server, can be implemented only by the mediation of the “public facing Exchange CAS server”.

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.

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 of the recipient E-mail address as a “possible 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 which hosts the particular user mailbox.
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 provided includes – the public URL’s address of the available Exchange web services. The URL address that listed 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 typical scenario is a situation of multiple Exchange sites.

In case of multiple Exchange sites, the organization can decide to implement one of the following situations:

Option 1: “Expose” only a particular Exchange CAS server who will serve as a “focal point” or gateway for all the Exchange clients worldwide (this is the scenario that described in the previous 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 + various 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.

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 – Bob@o365info.com needs to connect his Exchange mailbox, which 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.”

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 that 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 which 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).