Thursday, March 25, 2010

Load balancing Exchange 2010 OWA

In a recent post: I talked about how to load balance an array of Exchange 2010 CAS servers using a Citrix NetScaler VPX.

In this post I wanted to take a step back and offer a more simple configuration for those of you wishing to load balance basic HTTP/S traffic between your Exchange 2010 CAS servers. One of the primary reasons for this is to provide high availability for internal (or external) clients. The types of connectivity you can expect the NetScaler to see includes both direct and indirect traffic. Direct traffic would be a user opening a web browser and navigating to your load balanced OWA servers. Indirect traffic would be Outlook 2007 or 2010 connecting to the Autodiscover service connection point (SCP).

STEP 1: Setting up HTTP Services
If you followed my previous article on how to set up servers and services, then this should be easy for you. If you haven't, go back and read those steps.

  • Create a service for each server you wish to load balance to. I've given mine a name of "svc_http_jcsexchcal" for my Calgary server and "svc_http_jcsexchedm" for my Edmonton server and so on.
  • The service should have HTTP as the protocol and 80 as the port number.
  • The monitor can be left at TCP for now.
STEP 2: Setting up HTTPS Services
You'll need to perform the same steps for the SSL services with a few differences.
  • When you create the service use the same naming convention but alter it accordingly (i.e. svc_https_jcsexchedm).
  • The service should have a protocol of SSL_BRIDGE and a port of 443.
  • The monitor should have both TCP and HTTPS.

STEP 3: Setting up an HTTP Virtual Server (redirect)
You may be asking yourself at this point why I need HTTP services? You'll need them for your redirect from HTTP to HTTPS. You want to make sure a person is redirected to the SSL site when they type in the base URL.

  • Create your virtual server with the same IP as your CAS array if you wish and give it a proper name such as "vs_http_webmail".
  • Set your protocol to HTTP and port to 80.
  • Add your HTTP services (i.e. svc_http_jcsexchedm and so on)
  • Click on the Advanced tab and type in the full path of OWA into the redirect URL (i.e.
  • Click on the Disable button to make sure the vserver is in a "down" state. You want to do this because the redirect won't work otherwise.
STEP 4: Setting up an HTTPS Virtual Server
This is the virtual server actually accepting connections, both direct and indirect.
  • Create another virtual server with the same IP as your CAS array and HTTP vserver.
  • Give it a proper name such as "vs_https_webmail".
  • Set your protocol to SSL_BRIDGE and port to 443.
  • Add your SSL_BRIDGE services to the vserver (i.e. svc_https_jcsexchedm and so on).
  • Click on the Method and Persistence tab and be sure to set the LB Method to Round Robin and your Persistence to SOURCEIP with a timeout of 15min and mask of
At this point you should have your two new services with the vs_http_webmail service in a "out of service" state. This is normal. The effective state will be "down". Your vs_https_webmail service should be "up" and "up" for both state and effective state. Try it out by browsing to your OWA URL and see how things work. Try disabling services, pausing VM's, and disconnecting network cables to simulate various failures. Record your results and convey the expectations to management and your user community. They will ask the questions anway....."what happens if......".

STEP 5: Setting up Exchange 2010
We need to make changes to AD and Exchange 2010 so clients can find your newly created vserver(s). First we need to modify the SCP's for each CAS server and make sure all the internal URL's point to the NetScaler's VIP.

The services we're going to modify include:

  • Autodiscover
  • Exchange Web Services
  • Offline Address Book
  • OWA Virtual Directory
  • Run the following on your E2010 server using PowerShell (Get-ClientAccessServer |fl auto*). This will spit out the Service Connection Point (SCP) settings which probably point to the server fqdn.
  • As an example run (Set-ClientAccessServer jcsexchedm -AutoDiscoverServiceInternalUri You can run the Get-ClientAccessServer command again to view the changes.
  • Run the above command for each CAS server you have.
Exchange Web Services:
  • Run the following on your E2010 server using PowerShell (Get-WebServicesVirtualDirectory |fl Server, InternalUrl). This will spit out the defined URL for each CAS server.
  • As an example, run (Set-WebServicesVirtualDirectory -identity jcsexchedm\ews* -InternalUrl
  • Repeat for each CAS server.
Offline Address Book:
For this one I just leave things as is. You don't typically need to load balance the OAB. If you run a (Get-OABVirtualDirectory |fl Server, InternalUrl) you'll notice the default is to use HTTP and not HTTPS. I typically leave each server hosting the OAB.

OWA Virtual Directory:
This is key to Outlook Web App when you have an environment with a mixed environment of Exchange 2007 and 2010. These settings help with redirection and proxy connections coming from OWA clients. For example, if you have an Exchange 2007 environment with users homed on it and you've installed your first E2010 CAS server you should be pointing them to the new box. You should also have a legacy URL for your 2007 CAS servers (i.e. Using PowerShell you would modify the InternalUrl parameter to be "" for each 2007 CAS server so that your E2010 CAS servers know where to send users with a 2007 mailbox to when they authenticate through OWA.
  • Run (Get-OwaVirtualDirectory |fl Server, InternalUrl) to see how things are set up in your environment. Following the same logic here you want to make sure all the URL's for each object on each server point to the same name.
  • You need to switch things up here a bit and add the -identity parameter to the PowerShell command ensuring your modifying the servers you actually want to change. As an example run (Set-OwaVirtualDirectory -identity JCSEXCHEDM\* -InternalUrl
  • Repeat for each E2010 CAS server you have.
One thing to note here is that we've only configured the InternalUrl parameter for the various services. Each of them have an ExternalUrl parameter as well with the exception of Autodiscover. If you're using ISA or TMG to front your OWA/EWS/Autodiscover connectivity (which you SHOULD be doing), then be sure to modify the ExternalUrl's as well. Quick example: Set-OwaVirtualDirectory -identity JCSEXCHEDM\* -ExternalUrl In my environment the "" name resolves to my NetScaler's vserver VIP when I'm inside the network and the same name resolves to my public IP bound to my TMG server. This is called "split horizon DNS" and is essential if you don't want to confuse your users with different URL's for inside vs. outside connectivity.

Anyway, that's enough for now. Enjoy.


  1. The Syntax bellow is incorrect...

    Set-WebServicesVirtualDirectory -server jcsexchedm -InternalUrl

  2. You're correct. I've made a typo and have corrected it. It should read "-Identity \ews*" and not "-server".