Client Access Servers, Load Balancing, and High Availability with Exchange Server 2007

Microsoft developers put a great deal of emphasis on high availability when they were designing Exchange Server 2007. One of the earliest public communications about Exchange 2007 was Microsoft vice president Dave Thompson's comment that Exchange high availability was too complex and hard to implement, and that a key goal for Exchange 2007 was to make it easier to set up and deploy Exchange while providing enhanced availability.

The combination of local continuous replication (LCR), cluster continuous replication (CCR), single copy clusters (SCC), and standby continuous replication (SCR) certainly gives us many options that were missing from previous versions of Exchange. In particular, the introduction of CCR and SCR means that we can build configurations that combine resiliency against server failures with resiliency against larger failures such as whole data centers or metropolitan area networks (MANs). However, there are lots of design considerations to bear in mind along the way.

One major design consideration is how to efficiently maintain client access. The Client Access server role in Exchange 2007 handles all client requests except MAPI. However, Microsof Office Outlook 2007 uses the Autodiscover service through the Client Access server to find user mailboxes, information about the correct availability service to use, and so on. That means that if your Client Access server fails, the majority of your clients will be out of luck until you fix it.

The Client Access role can be installed in conjunction with other server roles, so your first thought might be to install it in a Mailbox server cluster. Unfortunately, that's one of only two cases where you can't combine roles: No other role can be installed on a clustered Mailbox server. (The other exception is the Edge Transport server, which can't be combined with any other role). That means that you have to pursue other options to increase the availability of your Client Access services.

The simplest option in most cases is to use software-based network load balancing, such as the Windows Network Load Balancing Service (NLBS). You can also use hardware load balancers if you prefer (and, when choosing a solution, remember that Microsoft Office Communications Server doesn't support software load balancing). Another alternative is to install a different Client Access server for each site, business unit, or location.

For example, you could have westcoast.company.com as an Internet-facing Client Access server for employees west of the Rockies, and eastcoast.company.com for employees east of the Rockies (or the Mississippi River, or whatever other local geographic feature you want to use). Because Client Access server affinity is tied to Active Directory site topology, Client Access requests are proxied to the "best" available Client Access server in the target site. This means that if you install multiple Client Access servers in a site, failover should be largely automatic.

However, what happens if your eastcoast.company.com server fails and you want users to be able to get to their East Coast mailboxes by hitting the westcoast.company.com Client Access server? It turns out that each Client Access server has a set of parameters you can use to control how this proxy behavior works. You control and set these properties with the Set-OwaVirtualDirectory cmdlet in Exchange Management Shell. Take a look at the Microsoft article "Understanding Proxying and Redirection" to see the full set of proxy configuration options. In my example, the RedirectToOptimalServer parameter needs to be set to $false to allow cross-site forwarding from the West Coast Client Access server to the East Coast Mailbox servers.

Next week, I'll discuss some other little-known Client Access server options that you can use to adjust Client Access behavior in your environment. In the meantime, don't forget about our contest for the worst Exchange design or administrative mistake you've ever seen (or committed!). Submit your entries via email to [email protected] by December 15, 2007. (More information about the contest can be found in "Inexpensive Unified Communications Deployment, Part 2," November 15, 2007.)