Exchange Server 2013 Load Balancing Indepth

What are the options available to load balance Exchange 2013 traffic?

I am sure all of you have come across the statement that Exchange 2013 only needs Layer 4 load balancer and in fact Microsoft marketing heavily uses it to convey the message that it will reduce the cost of implementing an Exchange 2013 infrastructure. What if you already have a Layer 7 load balancer which is currently serving 2010 CAS? Let's take a look as to how Exchange 2013 gets away without the need for affinity.

The use of layer 4 load balancing in Exchange 2013 assumes that all CAS servers have the same SSL certificate (whether it is from an internal or 3rd party CA). When I say the same certificate, it should absolutely be the same certificate, not different certs issued by the same CA which covers the same urls. One scenario where this might happen is during the certificate renewal & rollout process, where one or more servers will have the new cert with a longer expiry date than the other ones.

Let's take the example of a user accessing OWA internally and try to understand why affinity is not required in 2013. The way OWA connection works in 2013 is as follows.

• The user connection is authenticated by any one of the 2013 CAS servers.
• The CAS issues an authentication token (cookie) with session keys and other info and the cookie gets encrypted using the public key of the SAN cert on the CAS server.
• The OWA client hands the cookie to the server with any new requests. In this case, it doesn't matter if the new request is handled by a different CAS server, as that server is capable of decrypting the cookie with it's private key, as all CAS servers have the same certificate.
• As the authentication cookie is successfully decrypted irrespective of which CAS 2013 server it hits, the user or client is not challenged to authenticate again with an FBA page.
• The 2013 CAS server does NOT do any data rendering, everything is done by the mailbox server that hosts the user's mailbox.
• Hence, irrespective of the route the client takes (whichever CAS) and even if the same client opens multiple paths (via different CAS), they all end up on the same backend mailbox server which hosts the user mailbox.

This change in logic in Exchange 2013 ( to encrypt the cookie using a shared key across the CAS pool) enables it to avoid having layer 7 load balancing and session affinity. What if you already have invested in a layer 7 LB (maybe you have 2010 up & running)? Can you use that with 2013? You absolutely can and you should use L7 LB if you already have it, as they have much richer protocol specific health checks.

So, are there any drawbacks in using L4 load balancers? Yes, there is and it is around protocol specific health checks. As layer 4 load balancer only sees the IP and port to which the traffic is routed, it is impossible to differentiate the protocol the client is trying to get to – whether the user is accessing OWA or OAB or EAS or EWS etc, as they all use port 443.

A workaround to overcome this limitation will be to use one VIP per protocol and do health checks that way. In this case, you will have a number of different urls (one for OWA, another for EWS etc) hitting different VIPs and depending on the protocol the VIP is serving, an appropriate health check can be performed, say check whether /owa/auth/logon.aspx is assessable before routing the OWA traffic. This means that we will need all those different urls in the cert and more importantly, the LB should have corresponding number of VIPs to service each Exchange 2013 protocol.

Hope this clears the confusion. Have you already deployed Exchange 2013 load balancing? If so, please share your config with the community.