Load Balancing Exchange 2010 with NetScaler: No SSL Offload

Now true to form this isn’t a how to on “Load Balancing Exchange 2010 with NetScaler”; there are plenty of blogs on that, some of the best ones I’ve come across are below:

For the process end to end, these are very good:

http://www.cb-net.co.uk/citrix-articles/2013-netscaler-load-balancing-exchange-2010

http://benddiscount.com/2015/01/15/exchange-2010-load-balancing-with-netscaler-10-1

Two from Dave Stork:

For handling rewrite which basically means appending ‘/owa’ to the end of a blank URL:

https://dirteam.com/dave/2012/12/24/simplifying-the-owa-url-with-citrix-netscaler

and another detailing content switching:

https://dirteam.com/dave/2012/12/21/loadbalancing-exchange-2010-with-citrix-netscaler-using-content-switching

Actually the best one I have found, particularity for content switching is this one, which has a smart single expression covering OWA, RPC and OAB. It also has a summary of some useful tips at the end:

http://blog.decepticlone.com/2013/10/load-balancing-exchange-2010-on.html

I do a fair amount of NetScaler work normally due to XenApp or XenDesktop and a requirement to include remote access within the solution. On the odd occasion I am called upon to do pure load balancing assignments however. Most of them are pretty straightforward including Exchange if you have a lot of IP addresses at your disposal. When you don’t you will need to get your head around content switching. One of the above blogs will help you there.

SSL Offload – Quick how to

Now to the point, Content Switching to one side, most blogs and guides you will come across will blindly advise the same course of action to achieve load balancing of Exchange. In summary:

1. Create the targets to be load balanced
2. Assign them to either an HTTP based Service Group or Service (which, is a personal preference but I always prefer flexibility from Service Groups).
3. Assign the Service Groups to an SSL based vServer with a commercial public SSL certificate assigned
4. Modify the IIS virtual directories on the Exchange Servers to Not Require SSL and set Client Certificates to ‘Accept’
5. Ensure authentication is set correctly in the IIS virtual directories or the Exchange console.
6. In HKLM\system\CurrentControlSet\Services\MSExchange OWA Create a DWORD SSLOffloaded = 1

Collectively these steps enable SSL offload on the NetScaler; that is the CPU intensive decryption process is moved away from the Exchange servers onto the NetScaler appliances. This is a particularly good thing if you have physical MPX NetScalers as they have dedicated SSL offload cards built into them, ultimately the Exchange servers will have improved efficiency. For a VPX it’s probably marginally better than having your Exchange servers carrying out this task but it will increase CPU utilisation on the associated hypervisor host(s).

So although I’m quite comfortable with NetScalers, Exchange is not my thing, so I’m not really happy about blindly making these changes to a production Exchange servers which have thousands of internal users on-board. After-all in many cases you may only have a maybe fifty or a few hundred concurrent external users to cater for, but with thousands of internal users using these CAS servers, there could be adverse affects.

The needs of the many outweigh the needs of the few

Consider the following:

• Remote access for Exchange services is only likely to be used for ~100 concurrent users, meaning SSL transaction load will be low
• These SSL transactions are going to be spread across a number of CAS servers
• Modification of the IIS settings could adversely affect internal users of OWA (I’ve seen this happen)
• Removing the requirement for SSL would mean some internal Exchange related traffic will be sent in plain text

Going against the grain

I decided I didn’t like the smell of the above scenario so I thought what’s wrong with using an SSL only Service Group assigned to my SSL vServer? To me it sounded like SSL bridge was the ticket, this will just proxy the connection through carrying out no decryption. There are two issues with this:

1. The Exchange CAS servers will require the public SSL certificate (more changes to the Exchange infrastructure that I don’t want to make)
2. SSL Bridge is a very limited option, it removes the possibility of carrying out move ‘advanced’ features such as Content Switching and Rewrites on the NetScaler.

So the only remaining course of action is to use standard SSL service groups and vServers with no SSL offload, and do you know what? It works. OWA, ActiveSync, RPC over HTTP etc, all work just fine; there is no need to to make any changes to your Exchange servers that you may not fully understand (like me) at all. Sure you have no SSL offload but consider how many users you will be presenting this solution to, and the capability of your CAS servers.

What actually occurs in the scenario is:

1. The vServer accepts SSL traffic
2. Traffic is then decrypted within the NetScaler
3. As traffic leaves the Netscaler on it’s way to the Exchange servers, it is re-encrypted
4. The public SSL certificate is only required on the NetScaler, specifically the Load Balancing vServer and Service Group and the Content Switching vServer