Exchange 2013 Client Access Server Role

While this Exchange server role shares the same name as a server role that existed in the last two
Exchange Server releases, it is markedly different. In Exchange 2007, the Client Access server role
provided authentication, proxy/redirection logic, and performed data rendering for the Internet protocol
clients (Outlook Web App, EAS,EWS, IMAP and POP). In Exchange 2010, data rendering for MAPI was
also moved to the Client Access server role.
In Exchange 2013, the Client Access server (CAS) role no longer performs any data rendering
functionality. The Client Access server role now only provides authentication and proxy/redirection
logic, supporting the client Internet protocols, transport, and Unified Messaging. As a result of this
architectural shift, the CAS role is stateless (from a protocol session perspective, log data that can be
used in troubleshooting or trending analysis is generated, naturally).

Session Affinity
As I alluded to in the sever role architecture blog post, Exchange 2013 no longer requires session
affinity at the load balancer. To understand this better, we need to look at how CAS2013 functions.
From a protocol perspective, the following will happen:
1.

A client resolves the namespace to a load balanced virtual IP address.

2.

The load balancer assigns the session to a CAS member in the load balanced pool.

3.

CAS authenticates the request and performs a service discovery by accessing Active Directory
to retrieve the following information:

4.

a.

Mailbox version (for this discussion, we will assume an Exchange 2013 mailbox)

b.

Mailbox location information (e.g., database information, ExternalURL values, etc.)

CAS makes a decision on whether to proxy the request or redirect the request to another CAS
infrastructure (within the same forest).

5.

CAS queries an Active Manager instance that is responsible for the database to determine
which Mailbox server is hosting the active copy.

6.

CAS proxies the request to the Mailbox server hosting the active copy.

The protocol used in step 6 depends on the protocol used to connect to CAS. If the client leverages the
HTTP protocol, then the protocol used between the Client Access server and Mailbox server is HTTP
(secured via SSL using a self-signed certificate). If the protocol leveraged by the client is IMAP or POP,
then the protocol used between the Client Access server and Mailbox server is IMAP or POP.
Telephony requests are unique, however. Instead of proxying the request at step 6, CAS will redirect
the request to the Mailbox server hosting the active copy of the users database, as the telephony
devices support redirection and need to establish their SIP and RTP sessions directly with the Unified
Messaging components on the Mailbox server.

Figure 1: Exchange 2013 Client Access Protocol Architecture

In addition to no longer performing data rendering, step 5 is the fundamental change that enables the
removal of session affinity at the load balancer. For a given protocol session, CAS now maintains a 1:1
relationship with the Mailbox server hosting the users data. In the event that the active database copy
is moved to a different Mailbox server, CAS closes the sessions to the previous server and establishes
sessions to the new server. This means that all sessions, regardless of their origination point (i.e., CAS
members in the load balanced array), end up at the same place, the Mailbox server hosting the active
database copy.
Now many of you may be thinking, wait how does authentication work? Well for HTTP, POP, or IMAP
requests that use basic, NTLM, or Kerberos authentication, the authentication request is passed as part

of the HTTP payload, so each CAS will authenticate the request naturally. Forms-based authentication
(FBA) is different. FBA was one of the reasons why session affinity was required for OWA in previous
releases of Exchange the reason being that that the cookie used a per server key for encryption; so if
another CAS received a request, it could not decrypt the session. In Exchange 2013, we no longer
leverage a per server session key; instead we leverage the private key from the certificate that is
installed on the CAS. As long as all members of the CAS array share the exact same certificate
(remember we actually recommend deploying the same certificate across all CAS in both datacenters
in site resilience scenarios as well), they can decrypt the cookie.

Proxy vs. Redirection

In the previous section, I spoke about CAS proxying the data to the Mailbox server hosting the active
database copy. Prior to that, CAS has to make a decision whether it will perform the proxy action or
perform a redirection action. CAS will only perform a redirection action under the following
circumstances:
1.

The origination request is telephony related.

2.

For Outlook Web App requests, if the mailboxs location is determined to be in another Active
Directory site and there are CAS2013 members in that site that have
the ExternalURL populated, then the originating CAS will redirect the request unless
the ExternalURLin the target site is the same as in the originating site in which case CAS will
proxy (this is the multiple site single namespace scenario).

Figure 2: Exchange 2013 Client Access Proxy and Redirection Behavior Examples

3.

For OWA requests, if the mailbox version is Exchange 2007, then CAS2013 will redirect the
request to CAS2007.

Outlook Connectivity
For those of you paying attention, you may have noticed I only spoke about HTTP, POP, and IMAP. I
didnt mention RPC/TCP as connectivity solution that CAS supports. And that is for a very specific
reason CAS2013 does not support RPC/TCP as a connectivity solution; it only supports RPC/HTTP
(aka Outlook Anywhere). This architecture change is primarily to drive a stable and reliable
connectivity model.
To understand why, you need to keep the following tenets in the back of your mind:
1.

Remember CAS2013 is an authentication and proxy/redirection server. It does no processing of

the data (no rendering or transformation). It simply proxies the request to MBX2013 using the
client protocol. In this case HTTP.

2.

CAS2013 and MBX2013 are not tied together from a user affinity or geographical
perspective. You can have CAS2013 in one datacenter authenticate the request and proxy the
request to a MBX2013 server in another datacenter. To enable this we had to change the
communication protocols used between server roles. Moving away from RPC to the client
protocols that are more tolerant of throughput & latency over WAN/Internet connections.

3.

For a given mailbox, the protocol that services the request is always going to be the protocol
instance on the Mailbox server that hosts the active copy of the database for the users
mailbox. This was done to ultimately uncouple versioning and functionality issues weve seen
in the past two generations (i.e., have to deploy CAS2010, HT2010, MBX2010 together to get
certain functionality and upgrading one doesnt necessarily give you new capabilities and may
break connectivity).

The last item is tied to this discussion of why we have moved away from RPC/TCP as a connectivity
solution. In all prior releases the RPC endpoint was a FQDN. In fact, the shift to the middle tier for RPC
processing in CAS2010 introduced a new shared namespace, the RPC Client Access namespace. By
moving RPC Client Access back to the MBX2013 role, this would have forced us to use either the
MBX2013 FQDN for the RPC endpoint (thus forcing an Outlook client restart for every database *over
event) or a shared namespace for the DAG.
Neither option is appropriate and adds to the complexity and support of the infrastructure. So instead,
we changed the model. We no longer use a FQDN for the RPC endpoint. Instead we now use a GUID.
The mailbox GUID, to be precise (along with a domain suffix to support multi-tenant scenarios). The
mailbox GUID is unique within the (tenant) organization, so regardless of where the database is
activated and mounted, CAS can discover the location and proxy the request to the correct MBX2013
server.

Figure 3: RPC Endpoint Changes

This architectural change means that we have a very reliable connection model for a given session
that is routed to CAS2013, CAS2013 will always have a 1:1 relationship with the MBX2013 server
hosting the users mailbox. This means that the Mailbox server hosting the active copy of the users
database is the server responsible for de-encapsulating the RPC stream from the HTTP packets. In the
event a *over occurs, CAS2013 will proxy the connection to MBX2013 that assumes the responsibility
of hosting the active database copy. Oh, and this means in a native Exchange 2013 environment,
Outlook wont require a restart for things like mailbox moves, *over events, etc.
The other architectural change we made in this area is the support for internal and external
namespaces for Outlook Anywhere. This means you may not need to deploy split-brain DNS or deal
with all Outlook clients using your external firewall or load balancer due to our change in MAPI
connectivity.

Third-Party MAPI Products

I am sure that a few of you are wondering what this change means for third-party MAPI products. The
answer is relatively simple these third-party solutions will need to leverage RPC/HTTP to connect to

CAS2013. This will be accomplished via a new MAPI/CDO download that that has been updated to
include support for RPC/HTTP connectivity. It will be released in the first quarter of calendar year 2013.
To leverage this updated functionality, the third-party vendor will either have to programmatically edit
the dynamic MAPI profile or set registry key values to enable RPC/HTTP support.
I do also want to stress one key item with respect to third-party MAPI support. Exchange 2013 is
the last release that will support a MAPI/CDO custom solution. In the future, third-party
products (and custom in-house developed solutions) will need to move to Exchange Web
Services (EWS) to access Exchange data.

Namespace Simplification
Another benefit with the Exchange 2013 architecture is that the namespace model can be simplified
(especially for those of you upgrading from Exchange 2010). In Exchange 2010, a customer that
wanted to deploy a site-resilient solution for two datacenters required the following namespaces:
1.

Primary datacenter Internet protocol namespace

2.

Secondary datacenter Internet protocol namespace

3.

Primary datacenter Outlook Web App failback namespace

4.

Secondary datacenter Outlook Web App failback namespace

5.

Primary datacenter RPC Client Access namespace

6.

Secondary datacenter RPC Client Access namespace

7.

Autodiscover namespace

8.

Legacy namespace

9.

Transport namespace (if doing ad-hoc encryption or partner-to-partner encryption)

As I previously mentioned, we have removed two of these namespaces in Exchange 2013 the RPC
Client Access namespaces.
Recall that CAS2013 proxies requests to the Mailbox server hosting the active database copy. This
proxy logic is not limited to the Active Directory site boundary. A CAS2013 in one Active Directory site

can proxy a session to a Mailbox server that is located in another Active Directory site. If network
utilization, latency, and throughput are not a concern, this means that we do not need the additional
namespaces for site resilience scenarios, thereby eliminating three other namespaces (secondary
Internet protocol and both Outlook Web App failback namespaces).
For example, lets say I have a two datacenter deployment in North America that has a network
configuration such that latency, throughput and utilization between the datacenters is not a concern. I
also wanted to simplify my namespace architecture with the Exchange 2013 deployment so that my
users only have to use a single namespace for Internet access regardless of where their mailbox is
located. If I deployed an architecture like below, then the CAS infrastructure in both datacenters could
be used to route and proxy traffic to the Mailbox servers hosting the active copies. Since I am not
concerned about network traffic, I configure DNS to round-robin between the VIPs of the load balancers
in each datacenter. The end result is that I have a site resilient namespace architecture while
accepting that half of my proxy traffic will be out-of-site.

Figure 4: Exchange 2013 Single Namespace Example

Transport
Early on I mentioned that the Client Access Server role can proxy SMTP sessions. This is handled by a
new component on the CAS2013 role, the Front-End Transport service. The Front-End Transport
service handles all inbound and outbound external SMTP traffic for the Exchange organization, as well

as, can be a client endpoint for SMTP traffic. The Front-End Transport Service functions as a layer 7
proxy and has full access to the protocol conversation. Like the client Internet protocols, the Front-End
Transport service does not have a message queue and is completely stateless. In addition, the FrontEnd Transport service does not perform message bifurcation.
The Front-End Transport service listens on TCP25, TCP587, and TCP717 as seen in the following
diagram:

Figure 5: Front-End Transport Service Architecture

The Front-End Transport service provides network protection a centralized, load balanced
egress/ingress point for the Exchange organization, whether it be POP/IMAP clients, SharePoint, other
third-party or custom in-house mail applications, or external SMTP systems.
For outgoing messages, the Front-End Transport service is used as a proxy when the Send Connectors
(that are located on the Mailbox server) have theFrontEndProxyEnabled property set. In this situation,
the message will appear to have originated from CAS2013.
For incoming messages, the Front-End Transport service must quickly find a single, healthy Transport
service on a Mailbox server to receive the message transmission, regardless of the number or type of
recipients:

For messages with a single mailbox recipient, select a Mailbox server in the target delivery
group, and give preference to the Mailbox server based on the proximity of the Active Directory
site.

For messages with multiple mailbox recipients, use the first 20 recipients to select a Mailbox
server in the closest delivery group, based on the proximity of the Active Directory site.

If the message has no mailbox recipients, select a random Mailbox server in the local Active
Directory site.

Conclusion
The Exchange 2013 Client Access Server role simplifies the network layer. Session affinity at the load
balancer is no longer required as CAS2013 handles the affinity aspects. CAS2013 introduces more
deployment flexibility by allowing you to simplify your namespace architecture, potentially
consolidating to a single world-wide or regional namespace for your Internet protocols. The new
architecture also simplifies the upgrade and inter-operability story as CAS2013 can proxy or redirect to
multiple versions of Exchange, whether they are a higher or lower version, allowing you to upgrade
your Mailbox servers at your own pace.