MSExchangeGuru.com

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

Posted May 22nd, 2013 under CAS, Exchange 2013. RSS 2.0 feed. Leave a response, or trackback.