Exchange 2013 Client Access Server Role
Published Jan 25 2013 06:00 AM 255K Views
Microsoft

In a previous article, I discussed the new server role architecture in Exchange 2013. This article continues the series by discussing the 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:
    1. Mailbox version (for this discussion, we will assume an Exchange 2013 mailbox)
    2. Mailbox location information (e.g., database information, ExternalURL values, etc.)
  4. 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 user’s 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. CAS Protocol Arch 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 user’s 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 mailbox’s 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 ExternalURL in the target site is the same as in the originating site (and the ExternalURL is the URL entered in the web browser by the user) – in which case CAS will proxy (this is the multiple site single namespace scenario).Proxy-Referral 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 didn’t 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 user’s mailbox. This was done to ultimately uncouple versioning and functionality issues we’ve seen in the past two generations (i.e., have to deploy CAS2010, HT2010, MBX2010 together to get certain functionality and upgrading one doesn’t 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. RPC Endpoint 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 user’s mailbox. This means that the Mailbox server hosting the active copy of the user’s 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 won’t 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, let’s 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. namespace 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 Front-End Transport service does not perform message bifurcation. The Front-End Transport service listens on TCP25, TCP587, and TCP717 as seen in the following diagram: Trans1 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 the FrontEndProxyEnabled 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. Ross Smith IV Principal Program Manager Exchange Customer Experience
18 Comments
Not applicable

I definitely like simplifying the namespace and the single world-wide namespace across multiple datacenters.  For small companies that want the DR setup, they also would like to see these servers used in some fashion so this a big plus.  The other item for Transport load balancing is another big plus.

My one question deals with Edge Sync.  Does this connection sync with the CAS when FrontEndProxyEnabled is set or will it always be with the Mailbox Role servers?

Not applicable

@JasonApt - It will be with the Mailbox servers.

Not applicable

Thanks Ross - Very much informative @High-level....!

Not applicable

Good effort in putting all together. Exchange 2013 Rocks.

Not applicable

This is all great.  Now please give us a crumb...just a little wafer-thin...WITH NEWS ON THE RELEASE OF SP3 SO WE CAN MAKE ALL OF THIS WORK IN REAL LIFE.  Gee, thanks.

Not applicable

BTW, the change in the "announcement" article to state "Update 1/14/13: We have updated this blog post to narrow the release timeframe from "first half" to "first quarter" of CY 2013" is lame.  2013 should have never been released without a migration path from 2010.  Period. Making enterprise customers wait months is equally lame.  Wrap this up with the instability of the past two CU's and you've got the world questioning the product.

Not applicable

Service Pack 3 for Exchange 2010 please...

Not applicable

I assume that the next version of Exchange (lets say 2015 or 2016) will still support Outlook 2010 and 2013 which still use ExMAPI to communicate with Exchange.

So how comes that the ExMAPI implementation from the MAPI/CDO download package will not be supported with the next version of Exchange?

Not applicable

Thank you so much for an Useful Article Ross. !

Not applicable

Good effort in putting all together. Exchange 2013 Rocks.

Not applicable

Thanks Ross. Very informative. Also thanks for MEC video.

Not applicable

Ross

In the article you mentioned that it’s no longer required to deploy split-brain DNS, and the fact that the Exchange 2013 RPC namespace has been moved back to the 2013 mailbox server. I guess I do not understand how I can move away from using split-brain DNS?  From my understanding  the Outlook 2010/2013 clients still need to look up the "internet protocol namespace" and this namespace will point to a VIP that’s load balancing a pool of 2013 CAS servers.  

Lastly I understand the Outlook 20102013 clients will connect using HTTPS to the 2013 CAS server, and the RPC client access has been moved back to the 2013 mailbox role.  However the outlook client needs to connect to the 2013 CAS server first, then the 2013 CAS will proxy HTTPS to the 2013 mailbox server that has the active copy of the DB.  Knowing this, I do not understand how this removes the requirement of the outlook client's not having to connect to load balancer or internal firewall? If the Outlook client is required to connect to a 2013 CAS first, then wouldn’t this mean the Outlook clients still needs to leverage the load balancer for HA purposes?

Thank you

Not applicable

@Skipster -

1.  Split-Brain DNS.  That really should have been a "may not need to deploy".  In prior releases, there was only a single Outlook Anywhere namespace, thus if you wanted your clients to use OA internally and externally, you would have to do some sort of DNS trickery to get the desired result.  With the ability to have separate OA namespaces for internal and external usage in Exchange 2013, DNS trickery is no longer required for that particular namespace.  However, if you want to ensure users use a single OWA namespace, for example, and control the network pathway (internal vs. external) then you would still need deal with the DNS layer.  So split-brain DNS is still a viable scenario depending on your requirements.

2.  I never said load balancing is not required.  In fact I have stated that load balancing is still required, it is that you do not need to perform session affinity at the load balancer anymore.  You still want a load balancer for connection management policies like round-robin, least connection, etc.

Ross

Not applicable

Thanks. But one question. Is a separation of server roles required or can I put the CAS/FE role on the Backend server? Which disavantages I whould have with a (full) multi-role-server deployment?

Not applicable

@XMichael - CAS and MBX can be co-located.  Sizing is the critical factor in choosing this approach.  We'll have more guidance on this in the future.

Ross

Not applicable

@Ross: there is a new ExchangeMAPICDO download available since 2/12/2013. Is that the version which can connect to Exchange 2013? I could not find any documentation how to set up a profile with RPC over HTTP settings. Is that documentation already available?

Thank you

SvenC

Not applicable

nice article

What's the redirect vs proxy behavior of the cas 2013 when dealing with activesync mobile devices ?

We have two sites and would like to keep a single URL and not have CAS proxy the data through the WAN but just redirect to the proper externalurl.  Documentation is not clear on this regarding 2013

Not applicable

Hello,

We are a company with 110 Mailboxes (2 IT workers).

We planned to migrate from MDaemon to Exchange 2013 asap but we're actually working on network architecture for it. We already have the VM with Server 2012 installed on but we first want to design our network implementation.

Actually our MDaemon server is actually in our perimeter network - not linked to AD - and we will keep it for a while because we change our mail adress so he will redirect old mail adresses to new one.

To the flow is : WAN request for http or imap or smtp to the mail server are allowed in the FW and redirected to the Mail server in DMZ.

But here is the question :

With new design and role division of Exchange 2013, how to protect the AD from external attack still using activesync, OWA, outlookanywhere, etc...

Do we need to put CAS server on perimeter network ? Opening only needed port between it and AD + MailBox Server or do we put CAS + MBX server on LAN, then redirect all request to the cas server => which i think is not very safe.

What are bests practices for us ?

What's the safest/easiest way to implement exchange 2013 for "not too big company" ?

Thanks to everyone who can help us.

Version history
Last update:
‎Nov 09 2023 11:10 AM
Updated by: