The RPC Client Access service in Exchange 2010 is one of the most different services from any previous version of Exchange. The Exchange 2010 Client Access Server role handles all the heavy lifting for clients whether they use MAPI, IMAP, POP3, or OWA, but MAPI clients (such as Outlook clients connecting over traditional RPC connections, or those who connect using RPC over HTTPS) all connect directly to the Exchange 2010 RPC service. In this article, we will discuss the RPC Client Access service in detail; including how to configure it to work in more restrictive environments, and how to provide high availability.

Overview of the service

The Exchange 2010 RPC Client Access service is responsible for some of the most important, and likely the highest volume, client connections to your system. MSExchangeRPC runs on the Client Access Server role only, and services both MAPI and directory access connections. When Outlook connects a user to their mail, it connects to the MSExchangeRPC service on the CAS server, which proxies the connections to the Mailbox Server role hosting the user’s mailbox. Whether an Outlook client is on the same network as the CAS server and connects to the NSPI RPC endpoint, or is coming across the Internet and using Outlook Anywhere (RPC over HTTPS), it’s the Exchange 2010 RPC Client Access Service that is ultimately handling the connection to the mailbox.

Mailbox databases associate with a particular CAS server or CAS server array. If you move a database from one mailbox server to another, or implement a new CAS array after you have already created a mailbox database, you will want to update that association using the Exchange Management Shell.  That command is:

Set-MailboxDatabase –Identity “<databasename>” -RpcClientAccessServer <newmailboxservername> [enter]

How to configure static RPC ports

In environments where internal firewalls separate clients from their CAS server (we are not talking about Internet traffic in this situation, but you still want to use RPC connectivity instead of Outlook Anywhere), your firewall administrator may want you to restrict the ports used by RPC services. First however, you need to consider the below:

1)      Don’t restrict RPC traffic to a set of fixed ports. I have seen far too many times where this caused unintended outages because it was not done properly, or it was done with too narrow a range.

2)      If you really find you must restrict RPC traffic, use Outlook Anywhere instead, so that you only need to permit TCP 443 traffic through the firewall.

3)      If you are still going to restrict RPC traffic, make sure you monitor this closely, and train your helpdesk personnel to recognize RPC errors in client event logs so that you can quickly resolve any client problems.

Windows 7 and later clients, and Windows 2008 and later servers, both follow the RFCs and use ports from 49152-65535 for dynamic RPC connections (and other ephemeral traffic). Exchange 2010 CAS servers will use dynamic ports between 6005 and 59530. Because that is such a large range, and starts well below the 49152 mark, many security or firewall admins would want a static port. Recommended practices are that when you must restrict traffic to a specific port, choose one between 59531 and 60544. Make sure you do this on every CAS server, and that you use the same port on all CAS servers in your environment. You could use different ports per AD site, but that will quickly become an easy way to make a mistake. To configure a static port you should:

1. Open regedit.
2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeRPC.
3. Create a new key called ParameterSystem.
4. Create a new REG_DWORD called TCP/IP Port.
5. Enter the value in decimal.
6. Restart your CAS server’s MSExchangeRPC service.

Confirm that port number with your firewall admin, and make sure they are still permitting TCP 135. Even with a static port assignment, clients must still connect to the RPC end point mapper on TCP 135 to learn the static port used by NSPI.

How to provide high availability for Outlook MAPI clients

As you recall from above, Outlook MAPI clients can either make direct RPC connections to their CAS server, or take advantage of Outlook Anywhere (which uses the RPC over HTTPS connection). The CAS server proxies their connection to the appropriate mailbox server. Should the CAS server fail, all MAPI access (and OWA too) will fail. To avoid a single point of failure, you should implement CAS server arrays.

A CAS server array is when you have two or more CAS servers participating in a load balanced configuration, typically using Microsoft’s NLB service. This enables you to add as many CAS servers as you want, both to handle load and provide fault tolerance. To set up an array, you need to do the following:

1. Determine the virtual ip.addr to be used by the array.
2. Create an A record for the array, such as casarray.example.com.
3. Configure the Network Load Balancing on all CAS array members to load balance TCP 135 for the RPC endpoint mapper, and TCP ports 6005-59530 (or if you are going to use a static port, TCP 135 and that specific port).
4. On each CAS server, open the Exchange Management Shell and enter the following command:
   New-ClientAccessArray –name “your CAS name” –Fqdn “casarray.example.com” –site “ADsiteName” [enter]
5. Update any existing mailbox databases as covered in the overview paragraph above.

Exchange 2010 moved the client access components to the CAS server to simplify, unify, and improve the client connection experience, and to make things like connection logic more consistent across all connection methods. Understanding how this server works, and how to manage it, helps to ensure you will have no problems, can set up redundancy on the service, and can update your databases as your environment grows. Finally, understanding how clients connect and the options you have, will make it much easier for you to work with your firewall administrators if necessary.

Article By: Eva Ciganova (90 Posts)