MSExchangeGuru.com

Learn Exchange the Guru way !!!

 

Exchange 2013 CAS Role Demystified

Let’s take a deeper look into the Exchange 2013 Client Access Server Role through this article.

Even though the client access server roles where very much present in the exchange 2010 and exchange 2007, it has been transformed a lot in the latest exchange release. Exchange 2013 CAS role consists of Client Access front end role (CAFE) and the Front-End Transport (FET). The functions of CAS role has evolved from authentication, proxy/redirection logic, and performed data rendering for various Internet protocol clients in exchange 2007 to an additional data rendering for MAPI in exchange 2010. However, in exchange 2013, CAS does not have any data rendering capability any more. The functions of CAS role is now limited to authenticating and proxy redirection logic, supporting

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.

 

 

 

Session Affinity

Exchange 2013 does not require session affinity at the load balancer end any more. Taking a closer look at the CAS 2013 functioning will help us understand this better. The following steps happen:

  1. The namespace to the load balanced virtual IP address is resolved by the client.
  2. The session is assigned to a particular member of the CAS in the load balancer pool by the load balancer.
  3. The request is authenticated by the CAS. it then access the Active directory to do a service discovery so that the following information can be furnished:
    1. The version of the Mailbox
    2. The location information about the Mailbox like database information, External URL values, etc.
  4. Now a decision is made on if the request is to be redirected to another CAS or proxy the request by itself.
  5. The CAS now determines which mailbox server is hosting the active copy by initiating an active manager instance.
  6. Finally, the request is proxied to the active copy mailbox server by the CAS proxies the request to the Mailbox server hosting the active copy.

The CAS proxies the request to the mailbox server hosting the active copy using the same protocol as the one used to connect to the CAS. For example if it is HTTP that is being used by the cllient, then the CAS also utilises HTTP (via SSL).

There is an exception for 6 in case of Telephony requests. Since the telephony device requires establishing its RTP and SIP sessions with the Unified Messaging components directly, instead of proxying the request, the request is redirected to the mailbox server that hosts the active user database copy.

The fact that session affinity is no longer required by the load balancer is mainly facilitated by the step 5. During any session, CAS can now maintain an equal ratio relation with the user’s Mailbox server. Whenever the location of the active database copy changes, the CAS terminates the present session to establish a new session with the server to which the active database copy is moved. All these result in the fact that all sessions running shall be at the Mailbox server hosting the active database copy.

If the incoming request is HTTP, POP or IMAP then the request for authentication is passed through the HTTP payload. If the authentication is Forms-Based Authentication (FBA) then the encryption decryption process becomes complex. FBA cookies use a different key for different servers while encrypting. So when another server receives a request, it cannot decrypt the session. The per server decryption key is no longer used in exchange 2013. The key is now obtained from the certificates installed on the CAS. If same certificates are deployed throughout the CAS, then the decryption is possible.

Proxy vs. Redirection

Now the step 4 we discussed earlier deals with the decision whether the request is to be proxied or redirected. Now the redirection of requests is performed under the following circumstances:

  • If the Client is a Telephony Client.
  • When the mailbox location for an OWA request is in a distant active directory site and an ExternalURL is associated with the CAS in that particular active directory site then the request is redirected. However if the ExternalURL has the same value as that of the CAS to which the request was originally received then the request is proxied.
  • If the mailbox version of OWA is 2007 then the request is redirected.

Outlook Connectivity

In order to increase the stability and the connectivity reliability, exchange 2013 houses an important architectural change. RPC/TCP is no longer an available connectivity solution. Instead, exchange now uses RPC/HTTP (Outlook Anywhere).

To understand this clearly, keep these points in mind

  • The CAS role in exchange 2013 is restricted to just authentication and proxy/redirection. The data is no longer processed by the CAS. It only manages the proxying or redirection part using a specific protocol.
  • CAS2013 and MBX2013 are not inter dependant on the affinity front nor are they co-located geographically. CAS can perform authentication and proxying from a particular location to a MBX2013 server located in any datacenter. For this reason the communication protocols have been modified from RPC to the protocols that offer tolerance of throughput & latency over the WAN/Internet connections – HTTPS.
  • The protocol by which the request is processed is now the protocol which is being used by the mailbox server which is being used by the user’s mailbox as the active directory. This hence eliminates the need to deploy CAS2010, HT2010, and MBX2010 together to avail functionalities. And because of this shift in protocol use, FQDN is no longer required for the RPC endpoint. This is substituted by the mailbox GUID which is unique for an organization. Hence CAS can now detect the location and proxy the request to the correct MBX2013 server not considering of where the database is enabled and stored.

With these architectural changes comes an improved reliability in the connection model. During any session, CAS can now maintain an equal ratio relation with the user’s Mailbox server. The job of decrypting the RPC from HTTP now is rested within the mailbox server responsible for the user’s database.

Further the architectural changes now facilitate internal and external namespaces for Outlook Anywhere, hence avoiding the need to use the external firewall or load balancer to deploy split-brain DNS or deal with all Outlook clients during MAPI connectivity.

Third-Party MAPI Products

With all the architectural changes, third party MAPI products suffer some blows. They now have to leverage RPC/HTTP to connect to CAS in exchange 2013. Users can download MAPI/CDO which support for RPC/HTTP connectivity to facilitate third party MAPI products. However, your third-party vendor should now support RPC/HTTP.

Having said that, it is to be noted that custom MAPI/CDO solutions are supported by the exchange 2013 which may, in future require the third-party products to move to Exchange Web Services (EWS) to access Exchange data.

Namespace Simplification

Another distinct advantage of the improved architecture is the simplification offered to the namespace model. The previous version of exchange (Exchange 2010) used as many as 9 namespaces, namely:

  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)

Since exchange 2013 no longer utilises RPC, the 5th and 6th namespaces are eliminated. Now, since the request is proxied to the active database copy’s mailbox server, the proxy logic spans beyond the active directory site borders. CAS can now proxy requests across multiple mailbox servers and AD sites. This in turn results in the elimination of 3 more namespaces- 2nd, 3rd and 4th.

Transport

All SMTP sessions in the exchange 2013 is handled by the Front-End Transport service. Besides managing the incoming and outgoing SMTP traffic for the organization, it act as a client endpoint for SMTP traffic. It act as a layer 7 proxy and has full access to the protocol conversation. It is stateless, cannot perform message bifurcation and does not have a message queue.

With the front end transport service, the exchange avails a centralized and load balanced egress or ingress terminal, a network protected system, regardless of the kind of client accessing it – sharepoint, POP/IMAP Clients, third-party or even external SMTP systems.

Front end transport service act as a proxy for outgoing messages if the FrontEndProxyEnabled property is set for Send Connecters located on the mailbox server. These messages will look like they are coming from a CAS of exchange 2013 system.

If there is an incoming message to the front end transport service, it should reach an unoccupied transport service on a mailbox service so as to receive the incoming message without considering the type of recipients:

  • If the message is to a single recipient, a mailbox server in the delivery group is selected and the one closest in proximity to the active directory site is preferred.
  • If there are more than one recipients, the first twenty recipients are used to select the closest to the active directory site.
  • The message is transferred to a random mailbox server if the recipient is not specified.

Conclusion

Through this article we have seen that the CAS role in Exchange 2013 removes the requirement of session affinity at load balancer, simplifies the network layer and also achieve namespace simplification and hence deployment flexibility.

Ratish Nair

Microsoft MVP | Exchange Server

Team @MSExchangeGuru

11 Responses to “Exchange 2013 CAS Role Demystified”

  1. manoj vijaykumar Says:

    Awesome article Ratish. All the concepts are very clear and detailed.

  2. John Says:

    Great Article for Exchange 2013 On-Premises customers 🙂

  3. Blog Posts of the Week (19th - 25th May 2013) - The South Asia MVP Blog - Site Home - TechNet Blogs Says:

    […] Exchange 2013 CAS Role Demystified […]

  4. Exchange 2010/2007 to 2013 Migration and Co-existence Guide « MSExchangeGuru.com Says:

    […] 2013 CAS Role Demystified: https://msexchangeguru.com/2013/05/22/exchange-2013-cas/ Exchange 2013 High Availability demystified: […]

  5. Ramu Says:

    Is there any documentation on how the Proxy/redirection actually works? How the data flow works?

  6. Steve Says:

    How does Exchange 2013 determine which Exchange 2010 server to proxy to when the Exchange 2010 mailbox lives on a server that only hosts the mailbox role and not client access. The example I have is if an Exchange 2010 mailbox connects with IMAP to a Exchange 2013 CAS server that fronts IMAP, through testing we know that the Exchange 2013 will always proxy to the Exchange 2010 CAS/MBX server that hosts the active database copy for where the mailbox lives. But if the mailbox lives on a server that only hosts the mailbox role, any CAS server will be chosen which seems at random in order to establish the connction. Would it be possible to control which Exchange 2010 servers are available for CAS selection by Exchange 2013 or set a weight/cost to them?

  7. Ratish Nair Says:

    Well… Exchange 2013 uses Active directory to determine which E2010 to proxy connections to and the best route will be chosen.
    To answer your question – please see Greg’s presentation from 19th minute: http://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/OUC-B313#fbid=

  8. Parveen Khanna Says:

    Hi Ratish

    I have one query related to SMTP Mail flow from Internet. If there are two AD sites having Exchange 2013 deployed in HA mode in same Exchange Organization. Both have individual local DAG ( Say DAG1 for site A & DAG2 for Site B ) Site A is Internet facing site. If incoming mail sent from external domain meant for a recipient in DAG2, will the Exchange 2013 CAS at Site A will send the mail directly to Exchange 2013 CAS server in Site B or mail will first go to Exchange 2013 Mailbox server in Site A first, which then route it to Exchange 2013 Mailbox server in Site B.

  9. Mario Rivas Says:

    Hi Ratish
    Want to deploy an additional Exchange 2013 on a remote site (Same AD) and move a small number of mailboxes there. This remote site is linked to corporate via a VPN Tunnel. The MX record points to a spam filter device at the main Exchange site (Corporate). If emails come to a mailbox in the remote site, will CAS know to re-direct them through the VPN Tunnel, to the appropiate exchange server? Will there be a way, perhaps adding another MX record, and a spam filter, to have users connect directly to the remote site, instead of going through corporate site spam filter? Thanks

  10. Prabhat Nigam Says:

    CAS does not have routing skills so mail will go to Mailbox server then Exchange “Transport service” will transfer to the site B.
    I would recommend watching my New Jersey session recording here – https://www.youtube.com/watch?v=u23fzR1GsH4

  11. Shivappa Hosamani Says:

    Awesome article Ratish.

Leave a Reply

Categories

Archives

MSExchangeGuru.com