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
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)
- Load Balancing Exchange 2010 Client Access Servers using an Hardware Load Balancer Solution (Part 3)
Comments
Post a Comment