Removing session affinity
As we saw in Chapter 1, Getting Started, Exchange 2013 does not require session affinity any longer. To understand why this is the case, let us look at how the new CAS role works from a protocol perspective:
- A client resolves the namespace to a CAS.
- The CAS authenticates the requests and queries Active Directory for the following pieces of information:
- Mailbox version (if the mailbox is hosted on Exchange 2010 or 2013, for example; let us assume a 2013 mailbox)
- Mailbox location information such as database and
ExternalURL
- The CAS decides if it will redirect or proxy the request to another CAS or array (within the same AD forest).
- The CAS queries the instance of the Active Manager responsible for the database in order to discover in which Mailbox server the active copy is hosted.
- The CAS will either proxy the request to the Mailbox server currently hosting the active copy using HTTPS, IMAP, or POP, or, in the case of a telephony request, redirect it to the Mailbox server instead because SIP and RTP sessions need to be established directly with the Mailbox server's Unified Messaging components.
Two changes in the new CAS architecture made it possible to remove session affinity at the load balancer: the fact that data rendering is no longer performed by the CAS and from step 4 that mentions the CAS queries the instance of the Active Manager responsible for the database. For any protocol session, CASs now maintain a relationship of 1:1 with the Mailbox server that hosts the user's mailbox. If an active database copy gets moved to another Mailbox server, the CAS will close the session(s) to the previous server and establish a new session to the new server, meaning that all sessions, independent of their point of origin (CAS), will always terminate at the same place: the Mailbox server that currently hosts the active database copy.
In regards to authentication, Forms-Based Authentication (FBA) was another reason why session affinity was necessary for OWA in the previous versions of Exchange. This was due to the cookie in FBA using a per-server key for encryption—if the request was received by another CAS, it would not be able to decrypt the session. By using the private key of the certificate installed on the CASs instead, Exchange 2013 no longer has a per-server session key, which enables a logged on user to resume a session on a different CAS without having to reauthenticate. However, it is extremely important that all CASs share the same SSL certificate as this will allow them to decrypt the authentication cookie that clients present.