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

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

Introduction

In part 1 of this multi-part article I talked about why it is a good idea to use a hardware load balancer (HLB) solution with your CAS array as well as explained what type of persistence (affinity) settings that are preferred for each protocol/service. Finally, I briefly talked about suggested timeout values for the miscellaneous Exchange 2010 protocols/services.
In this part 2, I will show you how to create and configure the virtual services required for the protocols/services as well as how you go about changing the external and internal URLs for each respectively.
Now organizations that have a reverse proxy solution based on TMG/ISA/IAG/UAG deployed in the perimeter network will typically use the web server farm load balancing capabilities in the solution to publish HTTP based clients and services to clients and applications located on an external network such as the Internet. However, it’s still a good idea to create virtual services to use HTTP, so that internal HTTP based clients and applications can leverage the internal HLB solution instead of going to a reverse proxy solution in the perimeter network. Said in another way, it’s a good idea to let internal clients hit the virtual service on the internal HLB solution instead of going to the Internet and then to the reverse proxy in the perimeter network.
There are also many organizations that do not have a dedicated reverse proxy solution in the perimeter network and these particular organizations will create a firewall rule that sends external HTTP based traffic directly to the HLB solution, which in such topologies usually is two-armed (aka two-legged).
Note:
Two-armed configurations are outside the scope of this multi-part article. Instead refer to the documentation written for your particular HLB solution.

Creating the necessary Virtual Services in the Load Balancer Solution

In part 4 of the multi part article where I uncovered the new RPC CA service, I explained how to create the virtual services used by internal Outlook clients (TCP End Point mapper and fixed RPC ports for Exchange Address Book service and Mailbox access), so I will not repeat those steps here.
So if we continue from the setup we ended out with in the above mentioned article series, we currently have the virtual services shown in Figure 1 up and running. Back since I played around in this lab environment the last time, I also added an extra Exchange 2010 CAS server to the CAS array so that there are a total of three CAS servers associated with each rule instead of two.

Figure 1: Virtual Services created in previous article uncovering the RPC CA Service
It is time to create a new virtual service for HTTPS and an HTTP respectively. The HTTPS virtual service will be used by internal clients and applications and depending on whether you have a reverse proxy solution in your perimeter network or not also by external clients. The HTTP virtual service will be used for re-direction purposes so that we do not need to simplify the OWA URL using the IIS HTTP Redirect feature on each CAS server in the CAS array.
To create the new virtual services, let’s log into the KEMP GUI and click Virtual Services > Add New.

Figure 2: KEMP Web GUI
This brings us to the page shown in Figure 3. Here we need to specify the virtual IP address and the port (in this case TCP/443) and then click “Add this Virtual Service”.

Figure 3: Specifying IP address and port for HTTPS Virtual Service
On the property page of the virtual service, we now need to set the specific settings such as layer 4 or 7, persistence method, timeout values as well as distribution model. For persistence it’s a good idea to select cookie based with fallback to source IP since this will support both clients that use cookie (OWA, ECP and Outlook 2010) and if the client doesn’t support cookie based persistence it will use source IP instead.
Note:An alternative method would be to have two virtual IP addresses configured in the HLB solution and then configure one with cookie-based persistence (for OWA and ECP) and one for the other clients/services used in the organization.

Figure 4: Configuring Basic Property Settings for the HTTPS Virtual Service
If you plan on doing SSL offloading this is also the place to enable it for this virtual service. Under Advanced Properties, we can specify a health check URL (connectivity verifier) and a port 80 redirector as well as several other things such as caching, compressions etc.

Figure 5: Configuring Advanced Property Settings for the HTTPS Virtual Service

Finally, we need to add the real servers (Exchange 2010 CAS servers) that should be associated with the virtual service.


Figure 6: Adding Real Servers to the HTTPS Virtual Service
And that’s it! A cool little detail around this is that we do not need to manually create the HTTP virtual service as it has been created automatically back when we specified the redirection URL.
As can be seen in Figure 7, we now have the virtual services required by the miscellaneous Exchange 2010 clients and services.


Figure 7: The HTTPS virtual service redirection setting also creates a HTTP Redirect virtual service

Changing External Exchange 2010 CAS URLs to point to HLB

Now that we have prepared the HLB solution by creating the necessary HTTP/HTTPS virtual services, the internal (typically mail.domain.com and outlook.domain.com) and external DNS records (mail.domain.com and autodiscover.domain.com) should be changed so they point to the virtual IP address (VIP) associated with the virtual service used to publish the CAS array. If you don’t use a reverse proxy such as TMG/ISA/IAG/UAG, you should also point the records in the external DNS to point to the HLB VIP (depending on whether the HLB solution is two-armed this is done in different ways). If you use TMG/ISA/IAG/UAG, the external DNS records should of course point to a public IP on the external interface of the reverse proxy array.

Figure 8: Changing DNS record for in the internal DNS infrastructure

Changing Internal & External Exchange 2010 CAS URLs to point to HLB

advertisement

Since the Configure External Domain name wizard doesn’t change the internal URLs, we still need to changes those either using the Exchange Management Console (EMC) or the Exchange Management Shell (EMS). The easiest thing is to do so using EMS. You just run the following command against each Internet-facing CAS server:

Figure 9: Default setting for OWA and the other vdirs
A nice improvement to the Exchange 2010 setup wizard is that when installing the CAS server role, you now have the option of specifying the external domain on the Internet-facing CAS servers you are deploying (see Figure 10). By entering the FQDN during setup, you won’t need to change the external URL for the miscellaneous IIS virtual directories afterwards.


Figure 10: Configuring the external domain on Internet-facing Exchange 2010 CAS Servers
If you did not configure the external domain during the installation of the CAS roles, you can of course do so using the Exchange Management Shell (EMS) or via the property page of each vdir like it was possible in Exchange 2007. But Exchange 2010 also makes you do this via a new “Configure External Client Access Domain” wizard. This new wizard can be accessed simply by right-clicking on Client Access under the Server Configuration workspace in the Exchange Management Console (EMC) as shown in Figure 11.

Figure 11: Launching the Configure External Client access Domain wizard
In the ”Configure External Client Access Domain” wizard, enter the domain name used for external access to the Exchange 2010 CAS servers, then add any Internet-facing CAS servers and click “Configure”.

Figure 12: Entering the external domain name and adding the Internet-facing CAS servers
This wizard set the specified FQDN as the external URL for the miscellaneous clients/services as shown in Figure 13.

Figure 13: External URL being set for the respective virtual IIS Directories
Alternative if you want to change the external URLs using Exchange PowerShell commandlets, you can do so using:

Outlook Web App (OWA)

Unlike the other internal URLs the internal OWA URL should point to the server FQDN of the CAS server and not the HLB FQDN since kerberos is used when accessing a mailbox in a non-Internet facing site.
Set-OwaVirtualDirectory -Identity "CAS_Server\OWA (Default Web Site)" -InternalURL https://serverFQDN.domain.com/OWA
Exchange Control Panel (ECP)
OWA and ECP basically uses the same code. So just like it’s the case with OWA, the internal ECP URL should point to the server FQDN of the CAS server and not the HLB FQDN. Again this is because kerberos is used when accessing a mailbox in a non-Internet facing site.
Set-EcpVirtualDirectory -Identity "CAS_Server\ECP (Default Web Site)" -InternalURL https://serverFQDN.domain.com/ECP -FormsAuthentication $True -BasicAuthentication $True
Exchange ActiveSync (EAS)
Set-ActivesyncVirtualDirectory -Identity "CAS_Server \Microsoft-Server-ActiveSync (Default Web Site)" -ExternalURL https://mail.domain.com/Microsoft-Server-Activesync -BasicAuthentication $True
Offline Address Book (OAB)
Set-OABVirtualDirectory -Identity "CAS_Server\oab (Default Web Site)" -ExternalUrl https://mail.domain.com/oab;
Exchange Web Services (EWS)
Set-WebServicesVirtualDirectory -Identity "CAS_Server\EWS (Default Web Site)" -ExternalUrl https://mail.domain.com/ews/exchange.asmx
Unified Messaging (UM)
Set-UMVirtualDirectory -Identity "CAS_Server\unifiedmessaging (Default Web Site)" -InternalUrl https://mail.domain.com/unifiedmessaging/service.asmx
Since the Configure External Domain name wizard doesn’t change the internal URLs, we still need to changes those either using the Exchange Management Console (EMC) or the Exchange Management Shell (EMS). The easiest thing is to do so using EMS. You just run the following command against each Internet-facing CAS server:
Outlook Web App (OWA)
Set-OwaVirtualDirectory -Identity "CAS_Server\OWA (Default Web Site)" -InternalURL https://mail.domain.com/OWA
Exchange Control Panel (ECP)
Set-OwaVirtualDirectory -Identity "CAS_Server\ECP (Default Web Site)" -InternalURL https://mail.domain.com/ECP -FormsAuthentication $True -BasicAuthentication $True
Exchange ActiveSync
Set-ActivesyncVirtualDirectory -Identity "CAS_Server \Microsoft-Server-ActiveSync (Default Web Site)" -InternalURL https://mail.domain.com/Microsoft-Server-Activesync -BasicAuthentication $True
Offline Address Book (OAB)
Set-OABVirtualDirectory -Identity "CAS_Server\oab (Default Web Site)" -InternalUrl https://mail.domain.com/oab
Exchange Web Services (EWS)
Set-WebServicesVirtualDirectory -Identity "CAS_Server\EWS (Default Web Site)" -InternalUrl https://mail.domain.com/ews/exchange.asmx
Unified Messaging (UM)
Set-UMVirtualDirectory -Identity "CAS_Server\unifiedmessaging (Default Web Site)" -InternalUrl https://mail.domain.com/unifiedmessaging/service.asmx
You could of course also set both the internal and external URL using the same command, you just include both parameters. For instance to set both URLs for OWA, use this command:
Set-OwaVirtualDirectory -Identity "CAS_Server\OWA (Default Web Site)" -InternalURL https://mail.domain.com/OWA -ExternalURL https://mail.domain.com/OWA -FormsAuthentication $True -BasicAuthentication $True

Finally we need to point the Autodiscover Service Internal Uri to the FQDN of the HLB. This can be done using:
Set-ClientAccessServer –Identity <Server Name> -AutoDiscoverServiceInternalUri: https://mail.domain.com/Autodiscover/Autodiscover.xml

Figure 14: Configuring the Autodiscover Service Internal Uri to point to the HLB FQDN
We have reached the end of part 2, but you can look forward to part 3 which will be published in a near future. Part 3 will explain how you go about offloading SSL from the Exchange 2010 CAS servers to the HLB solution.

If you would like to read the other parts in this article series please go to:


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

Introduction

With Exchange 2010, Outlook MAPI clients use the Client Access Server (CAS) role in the middle tier as the RPC endpoint, which has resulted in this role being even more critical than in previous versions of the product. Because of this, all organizations (big and small) should consider making this role highly available by introducing multiple CAS servers in each Active Directory site as well as load balance the protocols and services provided by this role.
In this previous multipart article of mine I, among other things, explained how you load balance the RPC CA service using Windows NLB and HLB technology, but I did not go into the details on how you configure load balancing for protocols and services such as Outlook Web Access (OWA), Exchange ActiveSync (EAS), Exchange Control Panel (ECP), Offline Address Book (OAB), Post Office Protocol (POP), Internet Message Access Protocol (IMAP), Exchange Web Services (EWS), and AutoDiscover (AutoD).
In this multipart article, I will show you how you load-balance the different protocols and services on an Exchange 2010 CAS role using a redundant external hardware load Balancer (HLB) solution. By implementing a load balancer solution, you distribute client workload among multiple servers and thereby increase performance and decrease downtime by eliminating the single point of failure that exists in a topology with only one single CAS server or when you have multiple CAS servers where the internal URL for the miscellaneous services point to the server FQDN.

Why use a Hardware Load Balancing solution over Windows NLB?

With the architectural changes in Exchange 2010 that amongst other things, introduces the new RPC Client Access service (which moves Outlook MAPI mailbox connections from the back-end Mailbox servers in the data tier to the Client Access servers (CAS) in the middle tier) providing both a load balanced and highly available Client Access Server (CAS) solution is even more important than was the case with previous versions of Exchange.
Windows Network Load Balancing (WNLB) technology may be a fine choice for organizations that do not plan to deploy multi-role Exchange 2010 servers with both DAG protected mailbox databases and load balanced/highly available CAS clients and services. In addition, using WNLB can be the right fit for organizations that do not have:
  • More than 8 nodes in a WNLB based array (the Exchange Product group does not recommend more than 8 nodes in a WNLB based cluster due to scalability and functionality limitations).
  • Requirements for the LB solution to be application-aware (check state of application and not just check for IP connectivity like WNLB does).
  • The need for affinity methods other than source IP address based affinity which is the only method provided by WNLB (a HLB solution provides other affinity methods such as cookie and SSL ID based affinity).
However, if you plan to deploy multi-role Exchange 2010 servers with both DAG protected mailbox databases and load balanced/highly available CAS server service, you cannot use WNLB due to Windows Failover Cluster (WFC) and WNLB hardware sharing conflicts (see this KB article for more information). Also, depending on your environment and network topology, the persistence (affinity) settings provided by WNLB may not be sufficient. This may especially be true if you have clients that look like they are coming from the same source IP address etc.
When a hardware load balancer based CAS array has been properly configured, all servers in the array are represented by a single virtual IP (VIP) address and a fully qualified domain name (FQDN). When a client request comes in, it will be sent to an Exchange 2010 CAS server in the CAS array using DNS round robin distribution method. Of course we have options to prefer one or more CAS servers over other via features such as weighted round robin, least connection and so on.

But my organization cannot afford a hardware-based load balancer solution

This could definitely be true if you go with one of the big players on the market (such as F5 BIG-IP, Cisco ACE, Citrix NetScaler etc.), but you know what? A hardware based load balancer solution is not just an expensive luxury of LORGs (large organizations) with just as large IT budgets at their disposal. A hardware load balancer solution does not necessarily need to cost many thousands of dollars. You can actually get sophisticated, high performance devices at a very affordable price (you just need to find the right vendor). This means that even though you work for an organization with a limited IT budget, it does not mean they cannot afford to invest in a hardware load balancer solution.
Personally, I have recommended different hardware load balancer solutions from different vendors to my customers over the years, but for Exchange 2010, I really like the low cost devices from KEMP Technologies. Their smallest device (LoadMaster 2000) has a price tag of $1,590 dollars which even includes one year of support. This means that you can get a redundant hardware load balancer solution for approximately $3,000 dollars if you are a SMORG (small or medium organization)! On top of that, the LoadMaster 2000 device has the same rich feature set as the LoadMaster 2200 (this one gives you a lot more bang for the buck that the LM 2000 model although the price difference is very small!), 2500, 3500, and 5500 models (which are minded for the LORGS (large organizations). That is it has full support for premium features such as load balancing using layer 4 and 7, automatic failover cluster (active/hot standby with failover time of less than 3 seconds in my test environment), SSL offloading, layer 7 persistence (stickiness), up to 256 virtual services (with a total of up to 1000 real servers!) and server/application health checking etc. These are features you typically only see listed when looking at expensive load balancer devices from the aforementioned more well-known vendors on the market.
By the way, if you are on the virtualization bandwagon (who isn’t?), KEMP Technologies also has a virtual appliance with a feature set identical to the hardware based devices.
Note:LORGs with lots of users or SMORGs that will use the HLB solution for purposes other than Exchange may need to use one of the larger KEMP models. To help you decide, check out the product matrix here.
Because I have very good experience with the devices from KEMP Technologies and because they are affordable even for the SMORGs that typically are planning to deploy a fully redundant Exchange solution consisting of two multi-role Exchange 2010 servers, I have used two LoadMaster 2000 devices configured in a cluster (one active and one hot standby) as the basis for this article. The setup is illustrated in Figure 1 below.

Figure 1: Topology used in this lab environment
Note:It is important to stress that I am in no way affiliated with KEMP Technologies. In addition, I am not being paid to point readers at hardware load balancer devices provided by this company. I simply do so as I have good experience with their devices.

What about reverse proxies such as TMG/ISA/IAG/UAG?

Can’t I use one of these solutions to load balance the miscellaneous protocols and services on a CAS server? You definitely could! At least you can load balance everything that’s HTTP or HTTPS protocol. However, none of these products are capable of load balancing RPC traffic. Read more in this newsletter I wrote a few months ago. In addition, you may not want to send traffic from internal clients to the reverse proxy solution in your perimeter network and back again.

Finally if you load balance HTTP/HTTPS traffic using one of the above mentioned solutions as well as an internal HLB solution, it’s also important to mention that you shouldn’t point them at the VIP/FQDN of the HLB, but instead have the reverse proxy itself distribute the traffic across the CAS servers in the CAS array.

What Persistence (affinity) type should I use?

Persistence (aka affinity, stickiness etc.) is the ability of a load balancer to maintain a connection between a client and a server. Persistence can make sure that all requests from a client are sent to the same server in a NLB array or server farm (in case of Exchange CAS array).
So depending on the Exchange client or service, there are different recommendations in regards to what persistence settings to use. Below I highlight which are the preferred ones for each client and service.
Exchange Clients:
  • Outlook Web App (OWA) - For OWA the recommended persistence methods are Client IP (source IP address) or Cookie (either existing cookie or one created by hardware load balancer aka LB-cookie). Both methods works fine in most deployments, but if you’re working with environments where client’s looks like them come from the same source IP address, you should avoid using Client IP and instead go with one of the cookie based persistence methods. It is recommend to not use SSL ID based persistence with OWA as this can result in users required to re-authenticate because browsers like Internet Explorer 8 create new separate worker processes when for instance creating a new message in OWA. The issue here is that with each new worker process a new SSL ID is used.

  • Exchange Control Panel (ECP) - Same recommendation as above.


  • Exchange ActiveSync (EAS) - For Exchange ActiveSync the recommended persistence methods are Client IP (source IP address) or Authorization header. If your organization uses the same mobile provider/cellular carrier network for all users that connect to Exchange using EAS, then chances are they appear to come from the same source IP address as NAT are often used in a cellular carrier network. This means that you may not see optimal distribution of EAS traffic among the CAS servers behind the NLB array. So for EAS it’s often a good idea to use the Authorization HTTP header as a key for persistence. Again, it is not recommended to use SSL ID based persistence for EAS as some mobile devices renegotiates SSL security parameters on a frequent basis.

  • Outlook Anywhere (OA) - For Outlook Anywhere (aka RPC over HTTP), the recommended persistence methods are Client IP (source IP address), Authorization header or “OutlookSession” cookie based persistence. If OA clients appear to come from the same Client IP, then you should consider using Authorization header or “OutlookSession” cookie persistence. Bear in mind though that “OutlookSession” persistence only is supported by Outlook 2010.

  • IMAP and POP3 - IMAP and POP3 do not require any special persistence settings, so the recommendation is to set it to no persistence.
Exchange Services:
  • Autodiscover- The Autodiscover service doesn’t require any special persistence settings, so the recommendation is to set it to no persistence.


  • RPC Client Access Service (RPC CA)- For the RPC CA service used as endpoint for internal Outlook clients, the recommended persistence method is Client IP.

  • Exchange Address Book Service- Same recommendation as for RPC CA service.


  • Exchange Web Services (EWS)- For EWS the recommended persistence methods are cookie or SSL ID.
Now since many of the above clients and services use the same port, you can often only specify one persistence method for all clients and services that use the same port/IP address. If you want to use a different persistence method for let’s say OWA and OA, depending on your HLB solution, this may be possible (by using split-persistence etc.) but is outside the scope of this multipart article. Instead, I suggest you contact the vendor of the HLB solution you plan on using.

Timeout Settings for each Protocol and Service

advertisement

For each virtual service you can set time out values for the sessions that are established from the miscellaneous clients to the HLB solution (memory, CPU etc.).
In order to make optimal use of your HLB solution you should not set these timeout values to high, but also be careful not to set them too low as this could result in clients needing to reestablish as session which may or may not mean the end user will be informed to re-authenticate.
Needless to say you would want to set timeout values for protocols and services such as OWA, ECP, EAS, Outlook Anywhere, and RPC CA relatively high (several hours such as hours in a workday) while IMAP, POP, AutoD, EWS, OAB should have low values set (typically few minutes). To be on the safe side contact the vendor of the HLB solution for details on what makes most sense with their solution.

Okay we have reached the end of part 1. But what we covered so far should make you well prepared for part 2 where we dive into how the virtual services for each protocol and service is created in a LoadMaster based HLB solution. If you have questions in regards to what has been covered so far, let me know.
If you would like to read the other parts in this article series please go to:

Configure SSL Offloading in Exchange 2010

How to Configure SSL Offloading in Exchange 2010.

This Exchange Wiki article explains how to configure SSL offloading for the Exchange 2010 protocols and client access services on an Exchange 2010 Client Access server (CAS).
When using a hardware load balancer to load balance traffic to CAS servers belonging to a CAS array, it can depending on the Exchange 2010 topology be beneficial to enable SSL offloading for the Exchange 2010 protocols and client access services on each CAS server in the CAS array.

Table of Contents

  • Configuring SSL Offloading for Outlook Web App (OWA)
  • Configuring SSL Offloading for Exchange Control Panel (ECP)
  • Configuring SSL Offloading for Outlook Anywhere (OA)
  • Configuring SSL Offloading for the Offline Address Book (OAB)
  • Configuring SSL Offloading for Exchange ActiveSync (EAS)
  • Configuring SSL Offloading for Exchange Web Services (EWS)
  • Configuring SSL Offloading for the Mailbox Replication Proxy Service (MRSProxy)
  • Configuring SSL Offloading for Autodiscover Service (AS)
  • Using a Script to Enable SSL Offloading
  • Notes on reverse SSL

By enabling SSL offloading, you terminate the incoming SSL connections on the hardware load balancer instead of on the CAS servers in the CAS array. Doing so moves the SSL workload (encryption and decryption tasks) which is 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, Mailbox Replication Service (MRS)) and because it now also is the endpoint for MAPI clients, it can in some scenarios make sense to let the LB device(s) take care of the SSL workload. This could be true in an environment where the CAS servers are restricted to a limited number of CPUs (could be in virtual environments etc.).
Another important reason is the fact that you only can take advantage of layer 7 (L7) processing such as cookie-based persistence if you offload SSL to the LB devices or configure reverse SSL (see section later in this article). If you do not offload SSL or configure reverse SSL, you can only use source IP address based persistence, which isn’t ideal in large scale environments. This is especially true, if you have clients that appear to come from the same source IP address (such as when clients are located behind a NAT device etc.).


note Important
If you configure SSL offloading on an Exchange 2010 CAS server, all user passwords will be sent in clear between the HLB device(s) and the CAS servers, so it's important the traffic is sent over a secure network not accessible by malicious users. If the security policy within the organization states that all passwords should be sent in an encrypted form (even when occurring over a secure network), it's recommended to enable reverse SSL on the HLB device(s). In addition, it's recommended to enable reverse SSL, if the organization does not have a secure network in place between the HLB device(s) and the CAS servers or if there's no noticeable performance gain of offloading SSL to the HLB device(s) in the environment.

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.
When configuring SSL offloading in Exchange 2010, you must also enable SSL acceleration on the LB device(s). This is however outside the scope of this article as the method differs from vendor to vendor.
Conceptual diagrams

The following diagram illustrates client connectivity with SSL Offloading (SSL acceleration) enabled:

The following diagram illustrates client connectivity with SSL bridging (Reverse SSL) enabled:



note Note
This Wiki page has been reviewed by the Exchange Product group and all included steps have been validated and approved. Also bear in mind that the steps for how to configure SSL offloading for Autodiscover and Exchange Web services are less complex when using Exchange 2010 SP1/SP2 and not Exchange 2010 RTM as it won't be necessary to modify any web.config files when these service packs has been applied.



Configuring SSL Offloading for Outlook Web App (OWA)

To configure SSL offloading for Outlook Web App (OWA), you must perform two steps on each CAS server in the respective CAS array. First, you 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





Next disable the requirement for SSL on the OWA virtual directory. To do so, 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”.




Finally, open a command prompt window and run “iisreset /noforce in order for the changes to be applied.







Configuring SSL Offloading for Exchange Control Panel (ECP)


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”.
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 “”.


Now uncheck ”Require SSL” and click “Apply” in the Actions pane.


Finally, open a command prompt windows and run “iisreset /noforce” so that the changes are applied.





Configuring SSL Offloading for Outlook Anywhere (OA)


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 yet, you can select to 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.

This brings up the wizard where you enter the external host name to be used and check “Allow secure channel (SSL) offloading”.

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

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 SSL Offloading for the Offline Address Book (OAB)

To enable SSL offloading for the Offline Address Book (OAB) you just need to remove the SSL requirement on the OAB virtual directory. To do so, let’s open the IIS Manager and expand the Default Web Site. Under the Default Web Site select the “OAB” virtual directory. Under features view, double-click on “SSL Settings”.


Now uncheck ”Require SSL” and click “Apply” in the Actions pane.



Finally, open a command prompt windows and run “iisreset /noforce” so that the changes are applied.




Configuring SSL Offloading for Exchange ActiveSync (EAS)

Some of you may probably recall you have read on Microsoft TechNet and various other places, that it isn't supported . 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).
note Important
SSL offloading for Exchange ActiveSync is only supported 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 very simple. You only 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”.


Now uncheck ”Require SSL” and click “Apply” in the Actions pane.

Finally, open a command prompt windows and run “iisreset /noforce” so that the changes are applied.


Configuring SSL Offloading for Exchange Web Services (EWS)


note Important
With Exchange 2010 SP1 and SP2, you will no longer need to modify the web.config file. Performing the process below with the new SP1 or SP2 files will cause EWS to fail activation. To offload SSL for EWS, you only need to remove the SSL requirement from the IIS virtual directory as described in the steps above.

To configure SSL offloading for Exchange Web services in Exchange 2010 RTM, you 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”.

Now uncheck ”Require SSL” and click “Apply” in the Actions pane.

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.


note Important
It's recommended you take a backup of the web.config file before you perform the next step.
In the web.config file, replace all occurrences of “httpsTransport” with “httpTransport” and then save the file.
The new SP1 web.config file contains binding entries for both httpTransport and httpsTransport that match the Binding name. For example, there is an EWSHttpBinding and an EWSHttpsBinding now.
Finally, open a command prompt windows and run “iisreset /noforce” so that the changes are applied.
note Important
With Exchange 2010 SP1, you will no longer need to modify the web.config file. To offload SSL for EWS, you only need to remove the SSL requirement from the IIS virtual directory.



Configuring SSL Offloading for the Mailbox Replication Proxy Service (MRSProxy)

The Mailbox Replication Proxy (MRSProxy) service is installed on every Exchange 2010 Client Access server. MRSProxy helps to facilitate cross-forest move requests and mailbox move requests to Office 365. By default, MRSProxy is disabled. If enabled, it's enabled in the remote Exchange forest (aka source Exchange forest). Although the MRSProxy service runs under Exchange Web Services (EWS) it's not supported to configure SSL offloading for this service.
The reason for this is because the MRSProxy service code expects the traffic to be signed/encrypted. This means that you must configure SSL bridging for this to work.


Configuring SSL Offloading for Autodiscover Service (AS)


To enable SSL offloading for the Autodiscover service, you must perform the same steps as those applied to the Exchange Web service virtual directory.


note Important
With Exchange 2010 SP1 and SP2, you will no longer need to modify the web.config file. Performing the process below with the new SP1 or SP2 files will cause Autodiscover to fail activation. To offload SSL for Autodiscover, you only need to remove the SSL requirement from the IIS virtual directory as described in the steps above.


To configure SSL Offloading for Autodiscover on Exchange 2010 RTM, 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”.




Now uncheck ”Require SSL” and click “Apply” in the Actions pane.

Next you need to change 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.


note Important
It's recommended you take a backup of the web.config file before you perform the next step.

In the web.config file, replace all occurrences of “httpsTransport” with “httpTransport” and then save the file.


The new SP1 web.config file contains binding entries for both httpTransport and httpsTransport that match the Binding name. For example, there is an AutodiscoverBasicHttpBinding and an AutodiscoverBasicHttpsBinding now.
Finally open a command prompt windows and run “iisreset /noforce” so that the changes are applied.

SSL Offloading in an Exchange 2003/2010 Coexistence Scenario

During a coexistence scenario where you have a mix of Exchange 2003 and Exchange 2010 servers in the organization, one of the first steps you need to perform after having deployed Exchange 2010 Client Access Servers is to change DNS, so that Exchange 2003 users access their mailbox via a set of Exchange 2010 Client Access servers in a Client Access array (CAS array).

In such a scenario it's fully supported to enable SSL offloading on the load balancer used to distribute client traffic across the CAS server in the CAS array.

Outlook Web App (OWA)

When configuring coexistence between Exchange 2003 and Exchange 2010, one of the steps you must to is to configure an OWA 2003 redirect URL on the OWA 2010 virtual directory. When doing so, you introduce a legacy FQDN that will be associated with Exchange 2003. This legacy FQDN is used when configuring the OWA 2003 redirection URL. The legacy URL is configured like the following:

https://legacy.contoso.com/exchangeBecause the Exchange 2020 CAS server will do a redirect when sending the client to Exchange 2003, it will work fine with SSL offloading enabled on the load balancer used with Exchange 2010.


Exchange ActiveSync (EAS)TBD.
Outlook Anywhere (OA)

TBD.

Using a Script to Enable SSL Offloading

If you're working with a large organization with many Exchange 2010 Client Access services , you may want to accelerate the steps we went through above. To configure SSL offloading using a scripted method, see this blog post .

The following cmdlets are a summary of tasks required to configure SSL offloading for Exchange Server 2010 SP1 on each Client Access server:


Set-OutlookAnywhere –Identity "$($env:COMPUTERNAME)\RPC (Default Web Site)" -SSLOffloading $true

New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\MSExchange OWA' -Name SSLOffloaded -Value 1 -PropertyType DWORD

Import-Module webadministration

Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None" -PSPath IIS:\ -Location "Default Web Site/OWA"

Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None" -PSPath IIS:\ -Location "Default Web Site/ECP"

Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None" -PSPath IIS:\ -Location "Default Web Site/OAB"

Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None" -PSPath IIS:\ -Location "Default Web Site/EWS"

Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None" -PSPath IIS:\ -Location "Default Web Site/Microsoft-Server-ActiveSync"

Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None" -PSPath IIS:\ -Location "Default Web Site/Autodiscover"

iisreset /noforce






Notes on reverse SSL

If you enable reverse SSL (aka SSL bridging) on the HLB devices, you will not need to perform the above steps on each CAS server in the CAS array. However, bear in mind enabling reverse SSL on the HLB device(s) will mean the SSL workload (encryption and decryption tasks) which are CPU intensive won't be moved away from the CAS servers. Instead, the SSL workload will occur on both the HLB device(s) and the CAS servers. With that said, if you do not enable reverse SSL, passwords will be sent in clear between the HLB device(s) and the CAS servers, so it's important this traffic occurs over a secure network not accessible by malicious users.
Whether you should use Exchange 2010 SSL offloading or the reverse SSL method is up to the respective organization to decide. If the CAS servers can handle all expected workload and if you do not have a secure network in place between the HLB device(s) and the CAS servers, it's recommended to enable reverse SSL.