Load Balancing Exchange 2010 Client Access Servers using an Hardware Load Balancer Solution 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 Uncovering the new RPC Client Access Service in Exchange 2010 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 backend 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. 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 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 reauthenticate. 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.
Creating the necessary Virtual Services in the Load Balancer Solution In part 4 of Uncovering the new RPC Client Access Service in Exchange 2010, 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 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. 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 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.