In my previous blog I wrote about the new SSL offloading capabilities in Exchange 2013 SP1. In this blog I will explain how to use this with a load balancer. In my lab environment I’m using an F5 (virtual) LTM running on Hyper-V. My lab is configured as shown in the following figure:

I assume you already have configured the Exchange 2013 SP1 servers for SSL offloading. The first we have to do is configure the LTM and create a new VIP or iApp in F5 terminology.

To do this you can use an iApp template which are available on the F5 support website. You can download the latest iApp template here: http://support.f5.com/kb/en-us/solutions/public/13000/400/sol13497.html. On this page you’ll also find guidance on which files to download.

Store the downloaded template files on a local harddrive where you can access them when configuring the LTM. Also store a backup of the SSL certificate (webmail.exchange16.com in my lab) in the same location since we need to upload this as well. Remember that the LTM is terminating the SSL connection and therefore needs the SSL certificate.

Import the SSL certificate

To import the SSL certificate logon to the LTM web console as an administrator. Navigate to System | File Management | SSL certificate List and click on Import as shown in the following Figure:

For the Import Type select PKCS12 (IIS), enter the Certificate Name (for example Exchange16-com), select the certificate from the local disk, enter the password and click Import.

Import the iApp template

To import the iApp template we just downloaded open the LTM web console and navigate to iApp | Templates and click the + icon. Use the Browse button to locate the Exchange 2013 template file we just downloaded and click Upload as shown in the following figure.

At the moment of writing (just after the release of Exchange 2013 SP1) the template is not supporting Exchange 2013 SP1 but we’ll reconfigure the iApp later on for usage with SP1.

Create a new iApp

Creating a new iApp (or VIP) using a template is really easy. In the LTM web console navigate to iApp | Application Services and click on the + icon. Give the new iApp a name (Exchange16 in this example) and select the f5_microsoft_exchange_2010_2013_cas_v1.2.0 template we uploaded earlier as shown in the following Figure.

When the template is loaded you can start configuring the iApp. Scroll down through the template and enter the following details (I only highlight the details you have to enter or change):

• Which version of Exchange are you using? Select Exchange 2013
• Will incoming traffic arrive at this BIG-IP system encrypted or unencrypted? Select Encrypted
• Do you want to re-encrypt this traffic to your Client Access Servers? Select Do not re-encrypte (SSL Offload)
• Which SSL Certificate do you want to use? Select the SSL certificate we imported in the first step
• Which SSL key do you want to use? Select the corresponding SSL key

The other options depend on your implementation of the F5 of course, in my lab the Exchange 2013 SP1 Client Access servers use the F5 as their Default Gateway and I use all services except for POP3 and IMAP4. Enter a public IP address for the iApp, add the internal IP addresses of your Client Access servers and enter the FQDN you use for accessing the Exchange environment. When all data is entered successfully click Finish to store the new configuration.

The new iApp will now load and if all went well the availability will be green as shown in the following Figure:

In an earlier article I explained how to brand the OWA logon page and this is quite useful when testing your load balancer as can be seen in the following Figure:

If you want to test the other Exchange 2013 servers you can use the Microsoft Remote Connectivity Analyzer.

For creating this iApp the ‘old’ iApp template was used (supports up to Exchange 2013 CU3) so there’s no support for the MapiHttp protocol and we have to configure this manually.

To do this we have to take the following steps:

• Create a MapiHttp monitor;
• Create a MapiHttp pool;
• Configure the existing iRule to support the MapiHttp pool.
• Create a MapiHttp monitor

To create a MapiHttp monitor navigate to Local Traffic | Monitors and click the + icon. Enter a name like Exchange16_mapi_http_monitor and select HTTP in the Type dropdown box. Change the Interval to 10 seconds, the Timeout to 31 seconds and enter the following in the Send String:

GET /mapi/healthcheck.htm HTTP/1.1\r\nHost: webmail.exchange16.com\r\nConnection: Close\r\n\r\n

This will check the Managed Availability healthcheck page which will return a 200 OK when the service is running fine. Enter this 200 OK in the Receive String box as shown in the following Figure:

To create a new pool navigate to Local Traffic | Pools | Pool List and click the + icon. Enter a name for the new pool like Exchange16_mapi_pool, select the Exchange16_mapi_http_monitor (click on the two left arrows button to select), select the Node List radio button and in the drop down box select the first Client Access server, select HTTP in the small drop down box and click Add to add this server to the New Members box. Repeat this for the second Client Access server:

The last step is to edit the existing iRule that’s part to the iApp we’ve created. Navigate to Local Traffic | iRules | iRule List and click on the existing iRule. Its name should be related to the name of the iApp we’ve created earlier, in my environment it is Exchange16_combined_pool_irule3.

In the Definition box scroll down and in the listing of the various services add the following entry:

“/mapi*” {

## Requests for MapiHttp information.

pool Exchange16_mapi_pool

persist none

return

}

Click Update to save the edited iRule.

This should be sufficient to add MapiHttp support for our ‘old’ Exchange 2013 iApp. As a quick check you can navigate to the healthcheck page on https://webmail.exchange16.com/mapi/healthcheck.htm to see if the 200 OK is actually returned:

You can also check the pool itself on the LTM by navigating to Local Traffic | Pools | Pool List and select the Exchange16_mapi_pool we’ve created earlier. The green dots show the availability of both Pool members (i.e. the /mapi Virtual Directory on each Client Access server):

Summary

Exchange 2013 SP1 supports SSL Offloading, but using this in a load balancer like the F5 LTM takes some configuration since the downloadable template only supports Exchange 2013 CU3 (as of February 28, 2014 but support for SP1 will be added soon). It’s not that difficult to make the necessary changes to you can use the F5 with SSL Offloading in Exchange 2013 SP1.