Thursday, 18 October 2012

Load Balancing Exchange 2010 Client Access Servers using an Hardware Load Balancer Solution (Part 3)

Introduction

In part 2 of this multi-part article, I showed you how to create and configure the virtual services required for the Exchange 2010 protocols/services as well as how you went about and changed the external and internal URLs for each respectively.
In this part 3, I will show you how to enable SSL offloading so that SSL sessions are terminated on the HLB solution instead of on the Exchange 2010 CAS servers in the CAS array.

Why enable SSL Offloading?

There are several benefits of enabling SSL offloading when using a hardware load balancer (HLB). When you enable SSL offloading you terminate the incoming SSL connections on the HLB instead of on the CAS servers. By doing so you move the SSL workload (encryption and decryption tasks) which are CPU intensive from the CAS servers to the HLB device(s). With CAS servers getting more and more responsibility with the introduction of new features such as MailTips, Move Request Service (MRS) and because it now also is the endpoint for MAPI clients, it makes even more sense to let the HLB take care of the SSL workload compared to earlier versions of Exchange Server.
Another important reason is the fact that you only can take advantage of layer 7 (L7) processing such as cookie-based persistence. If you don’t offload SSL to the HLB solution, you can only use source IP address based persistence, which isn’t ideal. Especially not if you have clients that appear to come from the same IP address.
Most HLB devices support software SSL. When software SSL is used, the HLB device uses the general processor (CPU) to perform SSL encryption and decryption tasks. Since the general CPU also handles things such as load balancing, health checks and other administrative tasks, if you have thousands of users in your messaging environment, it’s recommended to use a HLB that has a separate CPU with the sole purpose of processing SSL workload.

Enabling SSL Acceleration on the Hardware Load Balancer

In this article, I will show you how to configure a Load Master 2000 HA pair from KEMP Technologies for SSL acceleration, but in general the steps should be similar on devices provided by other vendors.
To enable SSL acceleration for the HTTPS virtual service, that we created earlier on in this article series, log on to the LoadMaster web interface and expand “Virtual Services” followed by clicking “View/Modify Services”. Now find the HTTPS virtual service and click “Modify”.

Figure 1: Accessing the property page of the HTTPS Virtual Service
On the property page of the HTTPS virtual service, check “SSL Acceleration

Figure 2: Enabling SSL Acceleration
You will now be presented with the dialog box shown in Figure 3.

Figure 3: Temporary certificate will be used
When clicking ”OK”, the property page will be extended with additional SSL options.

Figure 4: Enabling SSL Acceleration extends the property page with new SSL options
As you noted a self-signed certificate was automatically installed when you enabled SSL acceleration. Since we want to use the 3rd party SAN/UC certificate currently used on the CAS servers in our CAS array, click “Add New”. Then either paste in the entire body of the certificate or point to the cert file by clicking “Browse”.

Figure 5: Installing the UC/SAN certificate
Click ”Submit” and ”OK” and the certificate is installed for the HTTPS virtual service.


Figure 6: UC/SAN certificate installed
Now make sure that the port for each real server (CAS server) is set to port 80.

Figure 7: Make sure port 80 is specified as target server port
We can now see the common name for the cert (mail.exchangelabs.dk) on the virtual service list and we’re done on the HLB side of things. In the next section, we will go over the steps necessary to configure SSL offloading on the CAS servers in our CAS array.

Figure 8: Certificate properly installed on the HTTPS Virtual Service

Enabling SSL Offloading for the Exchange 2010 CAS Services

In this section, I will explain how to configure each service/protocol so that it supports offloading SSL for each service/protocol to a hardware load balancer.

Configuring Outlook Web App

To configure SSL offloading for Outlook Web App (OWA), you must perform two steps on each CAS server in CAS array. First, we must add a SSL offload REG_DWORD key. To do so, open the registry editor and navigate down to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchange OWA
Under this registry key, create a new REG_DWORD key named “SSLOffloaded” and set the value for this key to “1” as shown in Figure 9.

Figure 9: Creating the SSL Offload key for OWA
We now need to disable the SSL requirement on the OWA virtual directory. To do so, let’s open the IIS Manager and expand the Default Web Site. Under the Default Web Site, select the “OWA” virtual directory. Under features view, double-click on “SSL Settings”.

Figure 10: Accessing SSL settings for the OWA virtual directory
Now uncheck ”Require SSL” and click “Apply” in the Actions pane.

Figure 11: Disabling SSL requirement for the OWA virtual directory
Finally, open a command prompt windows and run “iisreset /noforce so that the changes are applied.

Configuring Exchange Control Panel

Unlike OWA, configuring SSL offloading for the Exchange Control Panel (ECP) doesn’t require a registry key to be set. Well, to be more specific ECP will use the same registry key as the one we set for OWA.
So in order to enable SSL offloading for ECP, the only thing we need to do is to disable the SSL requirement on the ECP virtual directory. To do so, let’s open the IIS Manager and expand the Default Web Site. Under the Default Web Site, select the “ecp” virtual directory. Under features view, double-click on “SSL Settings”.

Figure 12: Accessing SSL settings for the ECP virtual directory
Now uncheck ”Require SSL” and click “Apply” in the Actions pane.

Figure 13: Disabling SSL requirement for the ECP virtual directory
Finally, open a command prompt windows and run “iisreset /noforce so that the changes are applied.

Configuring Outlook Anywhere

To enable SSL offloading for Outlook Anywhere only requires one step which, depending on whether Outlook Anywhere already is enabled or not, can be done via the Exchange Management Console (EMC) or the Exchange Management Shell (EMS).
If you haven’t yet enabled Outlook Anywhere, you can use SSL offloading when running the “Enable Outlook Anywhere” wizard. You can access this wizard by right-clicking on the respective CAS server in EMC and select “Enable Outlook Anywhere” in the context menu.

Figure 14: Enabling Outlook Anywhere using the EMC
This brings up the wizard where you enter the external host name to be used and check “Allow secure channel (SSL) offloading”.

Figure 15: Allowing SSL offloading for Outlook Anywhere
If you already enabled Outlook Anywhere in your environment, you need to use the Set-OutlookAnywhere cmdlet to enable SSL offloading. If this is the case, open the Exchange Management Shell and type the following command:
Set-OutlookAnywhere –Identity CAS_server\RPC* -SSLOffloading $true

Figure 16: Enabling SSL offloading using the EMS
Running the above command will disable the requirement for SSL for the RPC virtual directory in IIS, which means we don’t need to do so manually like it’s the case with the other services/protocols.

Configuring Exchange ActiveSync

Some of you may recall having read on Microsoft TechNet and various other places that SSL offloading isn’t supported by Exchange ActiveSync. This used to be true but is now fully supported (although the Exchange documentation on Microsoft TechNet hasn’t been updated to reflect this yet).
Bear in mind however that SSL offloading is only supported by Exchange ActiveSync at the Internet ingress point. It’s still not supported in CAS-CAS proxy scenarios between Active Directory sites.
Configuring Exchange ActiveSync to support SSL offload is extremely simple. We just need to remove the requirement for SSL in IIS. To do so, let’s open the IIS Manager and expand the Default Web Site. Under the Default Web Site select the “Microsoft-Server-ActiveSync” virtual directory. Under features view, double-click on “SSL Settings”.

Figure 17: Accessing SSL settings for the Microsoft-Server-ActiveSync virtual directory
Now uncheck ”Require SSL” and click “Apply” in the Actions pane.

Figure 18: Disabling SSL requirement for the Microsoft-Server-ActiveSync virtual directory
Finally, open a command prompt windows and run “iisreset /noforce so that the changes are applied.

Configure Exchange Web Services

In order to configure Exchange Web services to support SSL offloading, we must perform two modifications. The first one is to remove the SSL requirement for the EWS virtual directory in IIS. To do so, let’s open the IIS Manager and expand the Default Web Site. Under the Default Web Site select the “EWS” virtual directory. Under features view, double-click on “SSL Settings”.

Figure 19: Accessing SSL settings for the EWS virtual directory
Now uncheck ”Require SSL” and click “Apply” in the Actions pane.

Figure 20: Disabling SSL requirement for the EWS virtual directory
Next step is to make a change to the configuration file (web.config) for the EWS virtual directory. This file can be found under C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\exchweb\ews and be modified using a text editor such as Notepad.

Figure 21: Locating the EWS web config file
In the web.config file, you should replace all occurrences of “httpsTransport” with “httpTransport” and then save the file.

Figure 22: Replacing httpsTransport with httpTransport
Note:
With Exchange 2010 SP1 you will no longer need to perform the latter change (see KB article 980048 for details).
Finally, open a command prompt windows and run “iisreset /noforce so that the changes are applied.

Configuring Autodiscover Service

In order to configure the Autodiscover service to support SSL offloading, you must perform the same steps as those applied to the Exchange Web service virtual directory.
So let’s open the IIS Manager and expand the Default Web Site. Under the Default Web Site select the “Autodiscover” virtual directory. Under features view, double-click on “SSL Settings”.

Figure 23: Accessing SSL settings for the Autodiscover virtual directory
Now uncheck ”Require SSL” and click “Apply” in the Actions pane.

Figure 24: Disabling SSL requirement for the Autodiscover virtual directory
Next step is, without surprise, to make a change to the configuration file (web.config) for the Autodiscover service virtual directory. This file can be found under C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Autodiscover and be modified using a text editor such as Notepad.

Figure 25: Locating the Autodiscover web config file
In the web.config file, you should replace all occurrences of “httpsTransport” with “httpTransport” and then save the file.

Figure 26: Replacing httpsTransport with httpTransport
Lastly, open a command prompt windows and run “iisreset /noforce so that the changes are applied.

Validating Access works as expected

advertisement

After having offloaded SSL to the HLB, we of course need to validate that access from the miscellaneous Exchange clients/applications works as expected. A good first step is to use the Exchange remote Connectivity Analyzer for this purpose.

Figure 27: Using the Exchange remote Connectivity Analyzer to test access
In order to verify you installed the required root and intermediate certs as well as the UC/SAN cert properly, you can use SSL Installation Diagnistics tools such as the one provided by DigiCert.

Figure 28: Testing the SSL chain using the DigiCert SSL Diagnostics tool
If you get all green checkmarks using these tools, chances are things are in good shape. But you should of course also test access using the real Exchange clients.
And with that this multi-part article ends. Yes I also said that when we reached the end of part two, but this time I mean it :)
If you would like to read the other parts in this article series please go to