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

• Outlook Web App and the Exchange Control Panel   Microsoft Office Outlook Web App and the 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 the 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. An affinity timeout value of 45 minutes is recommended for Exchange Web Services clients to ensure that periodic polling for events associated with a subscription are not directed to a new Client Access server resulting in inefficient new subscriptions for each request. We don't support the use of Exchange Web Services without affinity.
  
  
• Outlook RPC over TCP on the Intranet   Outlook clients on the Intranet 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.
  
  

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.
  
  

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
  
  

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.

	Copy Code
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.

In Exchange 2010 SP1, the static ports for the two RPC endpoints maintained by the Exchange Address Book service are configured in the registry. Use the following registry key to configure these endpoints.

	Copy Code
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeAB\Parameters Value: RpcTcpPort Type: REG_SZ (String)

Warning:

When you apply Exchange 2010 SP1 to a machine that previously had the static ports configured by editing the Microsoft.Exchange.AddressBook.Service.Exe.config file, the upgrade process will not recognize the static ports configured in the file. If you are planning to deploy Exchange 2010 SP1, we recommend you create the registry key before you install Exchange 2010 SP1. The registry key has no impact prior to SP1, so configuring it before installation can prevent service interruptions.