Physical efforts in virtualization and mobility

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:

Two from Dave Stork:

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

and another detailing 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:

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

6 responses to “Load Balancing Exchange 2010 with NetScaler: No SSL Offload

  1. allenfox May 21, 2015 at 5:31 pm

    Great overview and write up! There are some excellent points here. Good idea to lay out all the options.


  2. Robin vadavathi October 9, 2015 at 10:59 am

    Really usefull and righting making simple to understand ..


  3. James December 14, 2015 at 4:03 am

    Any chance you have a more detailed setup guide for this scenario for a not so experienced NetScaler user?


    • veffort December 17, 2015 at 6:49 pm

      The other articles I have provided links to cover the implementation in more detail. I just wanted to, cover off the standard solution without the need for using SSL offload.


      • Aaron J Humphreys November 18, 2016 at 10:01 pm

        Do you have or know of a detailed deployment of non ssl offload to load balance Exchange?


      • veffort November 18, 2016 at 11:28 pm

        I posted a number of blog posts in the introduction to this article that cover this. To achieve non SSL offload (if indeed that is something to achieve) one just misses out the steps that involve working on the Exchange services.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: