Load Balancing Requirements of Exchange Protocols

Microsoft Exchange protocols and client access services have different load balancing requirements. Some Microsoft Exchange protocols and client access services require client to Client Access server affinity. Others will work without it but will display performance improvements from such affinity. Other Exchange protocols don't require client to Client Access server affinity and performance doesn't decrease without affinity.

Exchange Protocols That Require Client to Client Access Server Affinity

The following Exchange protocols require client to Client Access server affinity. Affinity must last during a client session.

  • Outlook Web App and Exchange Control Panel   Microsoft Office Outlook Web App and Exchange Control Panel both require client to Client Access server affinity. When you use forms-based authentication, which is the default in Microsoft Exchange Server 2010, both Outlook Web App and Exchange Control Panel must be affinitized to the same Client Access server. This is because they share the same authentication cookie and this cookie can only be decrypted by one specific Client Access server.
  • Exchange Web Services   Only a subset of Exchange Web Services requires affinity. Availability Service requests don't require affinity, but subscriptions do. All aspects of Exchange Web Services experience performance enhancements from affinity. We don't support the use of Exchange Web Services without affinity.
  • RPC Client Access service   Outlook clients assume that all RPC connections are made to the same server. Outlook uses multiple sessions per user and assumes that all sessions connect to the same server.

Exchange Protocols That Benefit From Client to Client Access Server Affinity

The following Exchange protocols and services will work without affinity. However, performance is significantly reduced when they're deployed without affinity.

  • Outlook Anywhere   Outlook Anywhere connections are unidirectional and split a single RPC data connection into two HTTP connections. One connection is for incoming data and one is for outgoing data. When there's no affinity between these two types of connections, Outlook Anywhere tries to correlate the connections by coordinating with other members of the Client Access server array. This increases traffic between Client Access servers by about 50% for a two-server array and up to 100% for an array with a large number of servers.
  • Exchange ActiveSync   Microsoft Exchange ActiveSync transmits new mail notifications to clients through a long-standing HTTPS request from the client to the server. When an Exchange ActiveSync client is assigned to a new Client Access server, that server must re-create the notification subscription against the user's mailbox. This results in a significant performance penalty.
  • Exchange Address Book service   This is a new service in Exchange 2010 that provides directory access for clients. Not using affinity results in a significantly higher level of communication between the client and the Client Access servers.
  • **Remote PowerShell   **Without affinity, users will need to reauthenticate if a connection is interrupted.

Exchange Protocols That Don't Require Affinity

There are several Exchange protocols and services that don't require affinity because they're transactional. This means that the connection is established, the transaction is completed, and the connection is closed. These protocols don't experience performance benefits from affinity.

  • Offline address book
  • Autodiscover service
  • POP3
  • IMAP4

Understanding IP Ports

Most Exchange 2010 services are built on top of HTTP and use port 443 for Secure Sockets Layer (SSL) access and port 80 for non-SSL access. Outlook Web App, Exchange ActiveSync, Outlook Anywhere, and Exchange Web Services are such services. POP3 and IMAP4 use ports 110 and 143 respectively when not encrypted with SSL and ports 995 and 993 respectively when encrypted with SSL.

Other Exchange services, such as the RPC Client Access service and the Exchange Address Book service, are RPC services. When an Outlook client connects directly to the Client Access server using these protocols, instead of using Outlook Anywhere, the endpoint TCP ports for these services are allocated by the RPC endpoint manager. Allocation occurs when the services are started. This requires a large range of destination ports to be configured for load balancing without the ability to specifically target traffic for these services based on port number. You can statically map these services to specific port numbers to simplify load balancing. If the ports for these services are statically mapped, the traffic will be restricted to port 135 and the two specific ports that were selected for these services.

Configuring Static Port Mapping for RPC-Based Services

The static port for the RPC Client Access service is configured in the registry. The following registry key should be configured on each Client Access server. Set the key to the value of the port that you want to use for TCP connections to the RPC Client Access service.

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeRPC\ParametersSystem
Value: TCP/IP Port
Type: DWORD

Note

This change will only affect internal connections via TCP and won't affect Outlook Anywhere connections that use RPC/HTTP tunneling. Outlook Anywhere connections to the RPC Client Access service occur on port 6001. This isn't configurable.

This process should also be performed on any public folder servers in your organization.

The static ports for the two RPC endpoints maintained by the Exchange Address Book service are configured in the file named Microsoft.Exchange.AddressBook.Service.Exe.config. This file can be found in the bin directory under the Exchange installation path on every client Access server. The RpcTcpPort value in the configuration file should be set to the value of the port that you want to use for TCP connections for this service. This port handles connections for both Address Book referral (ABREF) and the Name Service Provider Interface (NSPI).

Note

Don't change the values for the NspiHTTPPort and RfrHTTPPort configuration options. By default, Outlook is configured to use these ports. Changing these values will result in an unwanted delay when clients try to establish Outlook Anywhere connections. The default ports are 6002 for NspiHTTPPort and 6004 for RfrHTTPPort.