Load balancing serves two primary purposes. It reduces the impact of a single Client Access server failure within one of your Active Directory sites. In addition, load balancing ensures that the load on your Client Access server and Hub Transport computers is evenly distributed.

Several changes in Exchange 2010 make load balancing important for your organization. The Exchange RPC Client Access service and the Exchange Address Book service on the Client Access server role improve the user's experience during Mailbox failovers by moving the connection endpoints for mailbox access from Outlook and other MAPI clients to the Client Access server role instead of to the Mailbox server role. In earlier versions of Exchange, Outlook connected directly to the Mailbox server hosting the user's mailbox, and directory connections were either proxied through the Mailbox server role or referred directly to a particular Active Directory global catalog server. Now that these connections are handled by the Client Access server role, both external and internal Outlook connections must be load balanced across the array of Client Access servers in a deployment to achieve fault tolerance.

A load-balanced array of Client Access servers is recommended for each Active Directory site and for each version of Exchange. It isn't possible to share one load-balanced array of Client Access servers for multiple Active Directory sites or to mix different versions of Exchange or service pack versions of Exchange within the same array.

When you install Exchange 2010 within your existing organization and configure a legacy namespace for coexistence with previous versions of Exchange, your clients will automatically connect to the Exchange 2010 Client Access server or server array. The Exchange 2010 Client Access server or Client Access server array will then proxy or redirect client requests for mailboxes on older Exchange versions to either Exchange 2003 front-end servers or Exchange 2007 Client Access servers that match the mailbox version. For more information, see Understanding Upgrade to Exchange 2010.

Note:
You can mix Quick Fix Engineering (QFEs) and update rollups when you apply them to all or parts of an array. We recommend that you apply QFEs and update rollups to all computers within an array.

Your load balancing configuration will have a direct effect on the host names that your clients use to connect and the Secure Sockets Layer (SSL) certificates that you use. For more information about Exchange 2010 certificates, see Understanding Digital Certificates and SSL.

Configuring the Client Access Server Array

When a load balancing solution provides client-to-Client Access server affinity, it means that there is a long-standing association between a particular client and a particular Client Access server. The client can be Outlook running on a laptop, Microsoft Exchange ActiveSync running on a mobile device, Microsoft Office Outlook Web App, Exchange Web Services, or another client application.

This long-standing association, or affinity, ensures that all requests sent from the client go to the same Client Access server. Some Exchange 2010 protocols require affinity and other Exchange protocols do not.

Windows Network Load Balancing (WNLB) is the most common software load balancer used for Exchange servers. There are several limitations associated with deploying WNLB with Microsoft Exchange.

• WNLB can't be used on Exchange servers where mailbox DAGs are also being used because WNLB is incompatible with Windows failover clustering. If you're using an Exchange 2010 DAG and you want to use WNLB, you need to have the Client Access server role and the Mailbox server role running on separate servers.
  
  
• Due to performance issues, we don't recommend putting more than eight Client Access servers in an array that's load balanced by WNLB.
  
  
• WNLB doesn't detect service outages. WNLB only detects server outages by IP address. This means if a particular Web service, such as Outlook Web App, fails, but the server is still functioning, WNLB won’t detect the failure and will still route requests to that Client Access server. Manual intervention is required to remove the Client Access server experiencing the outage from the load balancing pool.
  
  
• WNLB configuration can result in port flooding, which can overwhelm networks.
  
  
• Because WNLB only performs client affinity using the source IP address, it's not an effective solution when the source IP pool is small. This can occur when the source IP pool is from a remote network subnet or when your organization is using network address translation.
  
  

The first load balancing option is WNLB with source IP affinity. This solution is suitable if you have more than one Client Access server per Active Directory site but fewer than eight. This solution is built into Windows and doesn't require additional computers.

There are two scenarios in which you will not want to use WNLB.

• Your organization has a reverse proxy server that communicates directly with the Client Access server and not through the WNLB virtual IP address. The reverse proxy server hides the client IP addresses from the Client Access server array. Therefore, source IP affinity won't work as expected. However you may still want to use WNLB to load balance internal traffic.
  
  
• Your organization has many clients accessing your Client Access servers through a very small set of IP addresses. WNLB tends to affinitize an entire class C subnet to one Client Access server.
  
  

If you have more than eight Client Access servers in a single Active Directory site, your organization will need a more robust load balancing solution. Although there are robust software load balancing solutions available, a hardware load balancing solution provides the most capacity. For more information about Exchange 2010 server load balancing solutions, see Microsoft Unified Communications Hardware Load Balancer Deployment.

Hardware load balancers support very high traffic throughput and can be configured to load balance in many ways. Most hardware load balancer vendors have detailed documentation about how their product works with Exchange 2010. The simplest way to configure hardware load balancers is to create a fallback list of the affinity methods that will be applied by the load balancer. For example, the load balancer will try cookie-based affinity first, then SSL session ID, and then source IP affinity.

If you have a reverse proxy solution that can perform load balancing for the servers it publishes to the Internet, such as Microsoft Forefront Threat Management Gateway (TMG) or Forefront Unified Access Gateway (UAG), we recommend that you use it.

As traffic passes through the reverse proxy server to reach your Client Access servers, the client's original IP address is replaced by the IP address of the reverse proxy server. This breaks source IP affinity. There are ways to resolve this problem, including configuring the reverse proxy server to be the default gateway for the subnet it is proxying to.

However, most current reverse proxy servers can do load balancing for the services they publish to the Internet. These reverse proxy servers support load balancer-created cookie load balancing for the Exchange services that support this. This solution is more reliable than source IP load balancing. For this to work, the reverse proxy server must be able to read and modify the HTTP data stream. If you're using SSL, this means that the reverse proxy server must decrypt the traffic to read the contents and create the cookie within the stream. This decryption isn't possible in some circumstances, such as when you're using client certificate authentication, where the client connects to the Client Access server.

Return to top

Using existing cookies or HTTP headers is the most reliable way to identify a client and associate it with a specific Client Access server. These cookies and headers are created by the client or server as part of the communications protocol. This option also doesn't require the load balancer to modify the traffic, which helps performance.

When you use this affinity option, be aware of the following:

• Your load balancer must support this type of affinity. Currently only hardware load balancers support this affinity.
  
  
• This affinity only works for protocols that pass traffic on HTTP.
  
  
• There must be an existing cookie or header that remains constant during the client session and is unique to each specific client, or small set of clients, in the protocol.
  
  
• The load balancer solution must be able to read and interpret the HTTP data stream. If you're using SSL, this means that the load balancer must decrypt the traffic to read the contents. Sometimes this results in an increased load on the load balancer. Also, this decryption isn't possible in some circumstances, such as when you use client certificate authentication with the SSL session where the client connects to the Client Access server.
  
  

The existing cookies and HTTP headers suitable for load balancing that are available in Exchange 2010 protocols are the following:

• HTTP Basic authentication authorization header   This header works when HTTP Basic authentication is used. Basic authentication is the default and most commonly used type of authentication for Exchange ActiveSync. This header is uncommon for other protocols and authentication methods. The Basic authentication authorization header sends all traffic that uses Basic authentication and that is from a specific user to the same Client Access server. This header is also used when Outlook traffic is transmitted completely via HTTP and clients are behind a reverse proxy server.
  
  
• HTTP OWA UserContext cookie   This cookie works for Outlook Web App, which is the only client that uses it. When you use forms-based authentication (FBA) with Outlook Web App, which is the default configuration, a small set of requests are made at the start of an Outlook Web App session before the UserContext cookie is created. To ensure that those requests use affinity to connect the client to the same Client Access server, which is required for forms-based authentication to work, there has to be a fallback affinity option when you use the UserContext cookie. We recommend that you use the SSL session ID or source IP affinity as a fallback to provide affinity for those initial requests, before the load balancer gets the UserContext cookie to use.
  
  

  Note:

  Outlook Web App requests that use explicit logon to access a specific mailbox result in the use of a UserContext cookie with a different name and ID. The cookie starts with UserContext, but a string that identifies the individual mailbox is appended. This complicates load balancing with the UserContext cookie because the load balancer must first find a cookie starting with UserContext. This can result in decreased performance.

• HTTP Exchange Control Panel msExchEcpCanary cookie   This cookie only works for the Exchange Control Panel.
  
  
• HTTP Outlook 2010 OutlookSession cookie   Hardware load balancers support the OutlookSession cookie and other generic cookies. The following table describes the OutlookSession client cookie support requirements for Outlook RPC/HTTP:
  
  

  	Windows XP	Windows Vista	Windows 7
  Outlook 2003	Not supported	Not supported	Not supported
  Outlook 2007	Not supported	Not supported	Not supported
  Outlook 2007 Hosting Pack (KB2544404)	Not supported	Supported	Supported
  Outlook 2010	Not supported	Supported	Supported

  Note:
  Microsoft Outlook running on Windows XP does not support the OutlookSession cookie for load balancing. In this scenario, we recommend that you use IP load balancing.

• HTTP Remote PowerShell MS-WSMAN cookie   This method works only for Remote PowerShell.
  
  

Return to top

The second most reliable way to associate a client session with a Client Access server is by using a load balancer-created cookie. The load balancer adds an HTTP cookie to the client/server protocol conversation and then uses that cookie to determine which Client Access server should handle an incoming request. The Exchange 2010 applications that support this method are Outlook Web App, Exchange Control Panel, and Remote PowerShell. This type of cookie has several limitations.

• The load balancer must support this type of affinity. Currently only hardware load balancers and software load balancers that run on a separate server tier support this affinity.
  
  
• This method only works for protocols that pass traffic on HTTP. You can't use this method for the RPC Client Access service, Exchange Address Book service, POP3, or IMAP4.
  
  
• The load balancer solution must be able to read and interpret the HTTP data stream. If you're using SSL, this means that the load balancer must decrypt the traffic to read the contents. Sometimes this results in a bigger load on the load balancer. In other cases, it isn't possible for the load balancer to interpret the HTTP data stream, such as when you use client certificate authentication on the Client Access server.
  
  
• The client must be able to receive arbitrary cookies from the server and must then include those cookies in all future requests sent from the client to the server. Exchange ActiveSync clients, Outlook Anywhere clients, and some Exchange Web Service clients such as Microsoft Office Communications Server 2007 devices don't support this.
  
  

Load balancing based on the SSL session ID provides more detail than source IP affinity and lets you split up traffic from different clients even if those clients are coming in from the same IP address. SSL session ID load balancing also has the advantage of letting you load balance without decrypting the SSL traffic. This is required when you use client certificate authentication and when you end the SSL connection at the Client Access server.

SSL session ID affinity isn't recommended in the following two situations:

• Some clients, such as Internet Explorer 8, re-create their SSL session for each browser process that runs on the client computer. This results in a new SSL session for each Outlook Web App window. Because this breaks client affinity for Outlook Web App, deploying load balancing in this manner is not supported for Exchange 2010. Some mobile devices, such as the Apple iPhone, also create new SSL sessions for some parts of their Exchange ActiveSync communication with Exchange.
  
  

  Note:
  When you use client certificate authentication, browsers will use the same SSL session for all traffic to a given host name. As long as client certificate authentication is enabled, SSL session ID is a valid affinity option for Outlook Web App and Exchange Control Panel.

• In the case of Outlook Anywhere, the Client Access servers will use the Windows RPC Proxy component to pair up the RPC_DATA_IN and the RPC_DATA_OUT connections. This can adversely affect performance.
  
  

The most common way to provide affinity between clients and Client Access servers is by using source IP affinity. The load balancer examines a client's IP address and sends all traffic from a specific source IP to a specific Client Access server. This is the only type of affinity supported by WNLB. There are two important aspects to consider when you use source IP affinity.

• Affinity breaks when the client changes IP address. This can occur when a laptop is moved from a wired LAN to Wi-Fi or roams between different Wi-Fi networks. There is a user impact when the client changes IP address. For example, when they're using Outlook Web App, users will have to authenticate every time their computer obtains a new IP address.
  
  
• If many of your clients access your load balancing solution from the same IP address, the load distribution will become uneven. The impact of this depends on how many clients are masked behind a given IP address. For example, if you have four Client Access servers and 50 percent of your clients access your load balancer from the same IP address, at least 50 percent of your traffic will go to one Client Access server and the other three Client Access servers will handle the rest of the traffic. There are two main reasons why most clients will access your Exchange organization through a single IP address.
  
  
  • Network address translators (NATs) or outgoing proxy servers, such as Microsoft Forefront Threat Management Gateway (TMG). When there is a NAT or outgoing proxy server between your clients and your Client Access servers, the original client IP addresses are masked by the NAT or outgoing proxy server IP address.
    
    
  • Client Access server to Client Access server proxy traffic. In some scenarios, one Client Access server proxies traffic to another Client Access server. Typically, this happens between Active Directory sites because a client must access the Client Access server within the same Active Directory site as their mailbox. For more information about proxying, see Understanding Proxying and Redirection.
    
    

The last type of affinity is no affinity. When you don't use affinity, each request from a client is assigned to a random Client Access server. We don't recommend this option for protocols that require affinity or those that experience performance benefits from affinity.

It's recommended that you not use affinity for protocols that don't need affinity when SSL offloading is configured.

Return to top

The following table provides a summary of the load balancing options that are available.

There are several advantages and disadvantages to each of these options.

• Hardware load balancers usually include performance and security functionality such as SSL offloading and traffic inspection.
  
  
• Software load balancers in a separate server layer are usually included as parts of larger software packages, with reverse proxy capabilities like pre-authentication, SSL offloading, and extensive traffic inspection. When software load balancers pre-authenticate users, those users don't need to re-authenticate if the Client Access server they are affinitized to fails. However, some software load balancers require an affinity between the client and the reverse proxy server. In this case, you need an additional load balancing layer in front of the reverse proxy servers before those reverse proxy servers can perform load balancing duties for your Client Access servers.