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:

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.