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.

Tuesday, March 16, 2010

Can't see call logs or voice mail on Tanjay (CX700) with Exchange 2007 and 2010?

We had an issue with our Exchange 2010 and 2007 environment recently where some users were migrated to our Exchange 2010 servers and activated for Unified Messaging and their call logs and voice mail weren't showing up on the Polycom CX700 (Tanjay) phones.

During our involvement with the Exchange 2010 TAP program we implemented a single all-in-one server. In order to keep everything working and reduce the potential for outages we decided to keep our '' record pointing at the existing Exchange 2007 environment. Everything seemed to work fine except the CX700's. It turned out to be resolved by pointing the Autodiscover record at our Exchange 2010 environment which didn't cause an issue for our UM users on 2007 with CX700's either.

This was pretty much our own fault since the deployment guidance from Microsoft suggests migrating to a 2010 CAS server out of the gate. Anyway, live and learn....

Wednesday, March 3, 2010

Load balancing Exchange 2010 CAS servers (CAS Array)

I've been spending much of my time lately working on Exchange 2010 designs for customers here in Canada. One of the common design scenarios we propose is a multi-server DAG with all roles collocated on the same server. When installing multiple Exchange 2010 servers you'll notice that each collocated (MB/HT/CAS) server has a default database. I typically remove the database and create my own with it's own name and file location rather than moving and renaming the default....personal preference. Either way, when you create a database or use the default database on an E2010 MB server there is an attribute called "RPCClientAccessServer" tied to the database which needs some special attention if you intend on load balancing the CAS server role. I'll come back to this in a few moments...

You may know by now that the CAS server in E2010 actually takes on a more critical role than before. In previous versions of Exchange (2007-) the CAS role basically handled IIS (web) traffic for Outlook Web Access users and that's about it. Now with E2010 the CAS role actually handles MAPI/RPC traffic. This means your Outlook 2003/2007/2010 client traffic on the LAN will not connect directly to the database server, but rather the CAS server. Where this becomes more of an impact in deployments is when you want to provide redundancy and DR capabilities to Outlook clients. The clients are configured to "talk" to a specific server initially....and if you have lets say three all-in-one E2010 servers with users in mailboxes on each system, their client settings in Outlook are going to show the specific name of the E2010 server hosting their mailbox. So what if that server goes down? Will the client connect to another server hosting a replica of the database? The answer is no....because you haven't created an RPC Array or set up anything else.

First off if you're wanting to load balance between multiple collocated servers in a Database Availability Group (DAG), you need a hardware (or virtualized) load balancer. Personally I prefer the Citrix NetScaler VPX since it works with VMWare vSphere 4 and the basic model is free and downloadable as a virtual appliance. You can't use NLB since the DAG is using Windows Clustering components and collocation of those technologies isn't supported.

Setting up your hardware load balancer

Let's walk through the setup of the load balancer first. With your hardware load balancer you're going to define a name and IP used by clients to connect to E2010....let's say "". This name needs a DNS record on your corporate DNS server and you need to pick an IP address.....let's say Once you've created your DNS host record for the name, we need to configure the load balancer. In my example I'm load balancing to 4 all-in-one servers (see image). Each server and the IP address has been defined in the NetScaler VPX UI.

First, create/define your servers and IP's. These will be later linked to your services which are then bound to the Virtual Server.

Now I need to create a monitor to keep track of the RPC services for each server. Later I'm going to bind this monitor to each RPC service for each server. I use the format of "mon_" for monitor, "rpc_" for the type of monitor, then "cas" for what I'm monitoring. The monitor name is "mon_rpc_cas" and has no specific IP....but rather it has port 135 listed as the port to check to determine if it's operational (up) or not (down).

Now I'm going to create RPC services for each server I need to load balance to. Each service name contains the format of "svc_" then the type "rpc_" then the server name "jcsexchcal" so the entire name looks like "svc_rpc_jcsexchcal". The first service name I've created is linked to the "jcsexchcal.lvsedmtest.local" server (defined earlier) and has both a PING monitor but also the mon_rpc_cas monitor tied to it. This step is critical otherwise your services won't operate in an up/down state properly. You need to repeat this step for each server/service you want to load balance to.

Next I need to create a "Virtual Server" which contains all my services, the IP address, and load balancing attributes (i.e. round robin vs. least connection). I've chosen the name of "vs_" for virtual server, then "rpc_" for the type of data I'm load balancing, then "webmail" for the DNS host name I'm load balancing so the entire name looks like "vs_rpc_webmail". My IP address is which is linked in DNS to "". Each service in the UI should show "UP" in the state column by this time by the way! You will want to make sure you click on the "Method and Persistence" tab to set the timeout value to 15min to ensure connections persist with the same CAS server. This will prevent odd re-login issues with OWA.

Great. Now you have a load balanced RPC cluster that can serve up traffic for Outlook clients. Now back to Exchange since we're not quite done there yet.

Setting up the Exchange CAS Array

The CAS Array is a new feature in E2010 which needs some PowerShell hands-on to create and configure. When you define the CAS Array a "site" parameter is specified which is used to determine which CAS servers are a member of the array. You don't actually pick the CAS servers when you create the array. I use the "New-ClientAccessArray" command as follows:

New-ClientAccessArray -fqdn -site Default-First-Site-Name -name "CAS Array 1"

At this point if you create any new databases on CAS servers in that site, the "RPCClientAccessServer" attribute will be set to the CAS Array fqdn. I mentioned this at the beginning as an important point because any existing databases you create or databases created during Exchange setup will have the attribute set to the server in which they were created. You will need to change this attribute using the following PowerShell command:

Set-MailboxDatabase database01 -RpcClientAccessServer

To view the RPCClientAccessServer attribute currently set on all databases:

Get-MailboxDatabase |fl rpc*,name

This means if you have users within the database you don't have to move them....just update the attribute to be "" and their Outlook clients will update too.

Performing a connection status on Outlook will show a TCP/IP connection (not RPC/HTTPS) to the fqdn of your CAS Arrray!