Exploring Exchange 2010 RPC Client Access service

In Exchange 2007, we introduced five server roles that performed distinct functions within the Exchange organization. One role in particular – the Client Access server role – introduced a variety of new Web services, including the Availability service, the Autodiscover service and Calendar Concierge services.

In Exchange 2010, we have the same five server roles. However, there are some significant architectural changes and some shift in responsibilities. In this blog, I focus on the Client Access server role and go into detail about some of its architectural changes.

Perhaps the most significant change is that, in Exchange 2010, two new services on CAS called the RPC Client Access and Address Book services establish the RPC endpoint for MAPI, NSPI and RFR client access. This new functionality replaces the RPC endpoints in the Information Store. The RPC endpoint in the Information Store has not been removed in Exchange 2010, but it has been modified to only accept requests from CAS servers.

The RPC endpoint for public folder database access remains on the Mailbox server, however, Outlook clients now communicate directly with the RPC Client Access service on the Mailbox Server for public folder database access, and not with the Information Store.


In Exchange 2003, all clients either connect directly to the Information Store for data access and data rendering, or through front-end servers that proxy communications to the Information Store for data access.

In Exchange 2007, we started to consolidate data access paths, so that most clients (for example, OWA, Exchange Web Services, POP and IMAP), all went through a common business logic layer known as the Exchange middle tier. The middle tier is a library that is built into all of the server roles. Clients that went through this common business logic layer were able to take advantage of consistent business logic for their operations. At this point, MAPI clients (such as Outlook) and WebDAV clients (such as Entourage 2004) still connected directly to the Information Store.

In Exchange 2010, new managed-code RPC end-points were introduced in the CAS role that sit on top of the core business logic layer shared by the other internal Exchange server roles. In addition, WebDAV has been removed. This of course means that applications that use WebDAV need to be updated or migrated to versions that support Exchange Web Services.

Below is a comparison of the data access paths in Exchange 2007 and Exchange 2010:

Exchange 2010 Middle Tier

In order to facilitate this move to the middle tier, two new services were created that run on the Client Access Server role: the RPC Client Access service and the Address Book service.

The RPC Client Access service handles all data connections for mailboxes and the Address Book Service handles all data connections for access to Active Directory. One notable exception is public folders. For public folder connections, clients connect to the RPC Client Access service on the Mailbox role, and not the Information Store.

RPC Client Access service

In Exchange 2007 and earlier, MAPI clients connect directly to the Mailbox server. This meant when failover of a clustered mailbox server occurred, clients were disconnected from their MAPI and directory endpoints. In Exchange 2010, we have abstracted the client connection away from the Mailbox server. Thus, when a mailbox database switchover or failover occurs, clients remain connected to their MAPI and directory endpoints. This provides a more seamless experience for Outlook clients.

Achieving seamless switchovers and failovers was one of the main motivators for moving these endpoints to the CAS role. By abstracting the client connection away from the Information Store, when some kind of failure occurs to the database containing a user’s mailbox, Outlook doesn’t necessarily need to reconnect or restart. Another huge benefit is the ability for all clients to use the same code and logic to access the store and for content and body conversion. This means that whether the client is coming through IMAP, MAPI or if someone’s making a Web-based connection using OWA, we no longer have to be concerned about the business logic manipulating data into a format that other clients might not be able to read. This is done to mitigate issues like MIME to MAPI conversion. Additionally, this simplifies the Information Store process by making it leaner.

RPC Client Access Array

When a Client Access server communicates with the Mailbox server, it makes sense to view it as the Client Access server communicating with the Mailbox database via the Mailbox server that hosts the database. This is especially evident in a load-balanced array of Client Access servers and/or where your environment is configured to use Database Availability Groups that are associated with a Client Access server or Client Access server array. In a non-load balanced environment, the mailbox database is associated with only a single Client Access server. In a load-balanced environment, the Mailbox database is associated with the load balanced array of multiple Client Access servers. When you start adding two or more Client Access servers, you take advantage of the RPC Client Access Array feature.

By default, before a Client Access array is configured, all databases are associated with a Client Access server in the environment and the Outlook clients communicate directly with the Client Access server until the association with the database is updated to be the Client Access array.

In order for the clients to utilize a CAS array, by default, a CAS array should be created ahead of time. Below is an overview of these steps:

  • Create a Client Access array utilizing a unique FQDN.
  • Add the Client Access servers within the AD site to a load balanced array and in DNS associate the unique FQDN to the Virtual IP of the load-balanced array.
  • Configure the databases to utilize the CAS array.

New-ClientAccessArray –FQDN <RPCClientAccess ArrayName> –Site <SiteName>

The New-ClientAccessArray cmdlet is used to create a new Client Access array. This creates an object that represents a load balanced array of Client Access servers within a single Active Directory site as shown below.

The networkAddress attribute corresponds to the FQDN of the array.

From this point on, any new mailbox database that are created in the environment (in this same site) will be associated with this array. The database creation process pulls the value of the networkAddress attribute from the Array object in Active Directory and assigns it to the database’s RPCClientAccessServer attribute.

Associating the CAS Array with a Mailbox Database

Each mailbox database object has an attribute called RpcClientAccessServer. The information contained in this attribute is what point’s clients to the MAPI end-point they should be using. If you have more than one database, you will see multiple listings and the RpcClientAccessServer value could be different servers.

Use the following command to associate a database with a Client Access server or Client Access array:

Set-MailboxDatabase <Database_name> -RpcClientAccessServer <ClientAccess ServerName or ClientAccess-ArrayName>

This command changes the legacyExchangeDN attribute of the Mailbox Database. The value is stored in the following location:

CN=Mailbox Database ##########,CN=Databases,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Contoso,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com

After changing the value stored in this attribute, the client knows the location of the RPC endpoint for the array.

Note: Before the Set-MailboxDatabase cmdlet is executed, the attribute is set to one of the Client Access servers in the environment in the same site.

To determine the end point that clients will use for access to this database, Exchange first checks if there is a CAS array in the local site. If there is, it will use the array; the RPCClientAcessServer attribute would be set to the FQDN of the array.

If an array does not exist, Exchange will determine if the server hosting the database is also a CAS. If it is a CAS, Exchange will use it. If the server hosting the mailbox database is not also a CAS, Exchange will pick a random CAS from the site containing the user’s mailbox.

In order to find the MAPI endpoint for mailboxes, Exchange queries AD for the HomeMDB value of the user, as well as the name of the user’s mailbox database. The legacyExchangeDN for the user’s mailbox database is also retrieved. This value is the endpoint that Autodiscover will give to the client, and that the client should use to connect to the user’s mailbox.

RPC Client Access in a High Availability Scenario

In an environment with a DAG and an NLB CAS Array, Active Manager always keeps track of which database is active. Active Manager reports this information to servers in the CAS array. Because of this, the Outlook client does not have to keep track of this and continues to only communicate with the Client Access array. In case of a failure at the mailbox and/or at CAS level, the client should regain data access within 30 seconds.

Address Book Service

Prior to Exchange 2010, Exchange Server included a referral service that told Outlook clients where to find the Name Service Provider Interface (NSPI) endpoint. This referral usually pointed Outlook to a Global Catalog server (although Outlook Anywhere connections would leverage the mailbox servers as a proxy for Global Catalog functions). This functionality was provided by a component called Directory Services Proxy (DSProxy). Outlook expects to find this referral service on the same server that it is using for MAPI access.

When Outlook contacts the Client Access server, two possible actions happen:

  • If the user’s mailbox is on an Exchange 2010 Mailbox server, then either:
    • If the user’s mailbox is in the same site as the Client Access server, the local Client Access server or local CAS array is used; or
    • If the user’s mailbox is in a different site, the request is referred to a Client Access server in the remote site or a remote CAS array.
  • If the user’s mailbox has been moved back to a legacy Exchange Mailbox server, the directory request is referred to the user’s mailbox server. Existing legacy mailboxes don’t talk to Exchange 2010 CAS servers for directory information.

Note: If a mailbox is moved back to 2003/2007, CAS will redirect the client to the legacy Mailbox server which will provide a referral to a Global Catalog server. Otherwise, all legacy mailboxes are unchanged

This also acts as a simplified solution for finding a writable domain controller and a unified solution for GAL access.

A representation of the directory access path in Exchange 2010 is shown below:

RPC Encryption Settings

By default, Exchange 2010 requires encryption for RPC client access. This means that by default, Outlook 2003 clients will not be able to connect to Exchange. To enable connectivity, we recommend enabling encryption for Outlook 2003, and not disabling encryption on the server.

For more information about this issue, including workarounds, see Outlook Connection Issues with Exchange 2010 Mailboxes

In addition to the RPC encryption requirement, UDP notification support was removed from Exchange2010. As a result, Outlook 2003 clients in Online Mode can only use polling notifications. This will result in a slight delay in updates to item status (30 seconds on average, with up to a one-minute delay) when changes are made to items in a mailbox accessed by Outlook 2003. There are two workarounds for this issue:

  • Use Outlook 2003 in Cached Exchange Mode; or
  • Adjust the polling interval on the Client Access server. This will impact the performance of the Client Access server.

For more information about this issue, see

In Outlook 2003, e-mail messages take a long time to send and receive when you use an Exchange 2010 mailbox and

Common Client Access Considerations for Outlook 2003 and Exchange 2010

Benefits of RPC Client Access

The goal in Exchange 2010 was to make the store leaner and really more of a data store than a factory for the client business logic. We’ve been able to move quite a bit of business logic out of the store by removing many of the legacy APIs. We’ve also moved processing of inbox rules out of the store and into the transport stack. We’ve moved quite a bit of calendar logic out of the store to the Microsoft Exchange Mailbox Assistants. And, we removed support for ExCDO, epoxy and item level security descriptors.

Another area that hugely benefits from moving RPC endpoints to the middle tier is scalability for mailbox connections. In Exchange 2007, we were effectively limited to 60K connections per mailbox server due to limitations in the TCP/IP stack in Windows, where there was a fixed number of source ports regardless of the number of IP addresses. In Windows 2008, those limitations were removed, and Windows now supported one source port per IP address. However, we couldn’t actually take advantage of that change because DSProxy was not updated to use the new feature. This means the Mailbox server is limited to 60k outbound TCP connections to the Global Catalog servers. The store process is hard-coded to only support 65,535 RPC context handles. All told, this limited us to 15,000 active mailboxes before even considering the message profile of these mailboxes and their effect on CPU scalability.

The landscape changed significantly in Exchange 2010 with the introduction of the RPC client access service. Between Outlook clients and the CAS servers, we still have a one-to-one mapping of connections to client sessions. In addition we are able to disconnect idle client sessions, and free up the connection CAS used to talk to the Mailbox role for the idle clients. Now we are able to share a pool of 100 connections among all clients, and when we disconnect those clients they just hang around in a disconnected state until they need to perform some action again or until the client drops the connection.

A representation of improved backend scalability in Exchange 2010 is shown below:

For more information, review: Outlook Anywhere Scalability with Outlook 2007, Outlook 2003, and Exchange 2007

We were also able to introduce logic to the Address Book service that helped enable archive mailboxes, we made improvements in compliance features (for example copy on write for dumpster), and we provided unified GAL capabilities and a writeable GAL.

Many thanks to Scott Schnoll, Victor Wang, Robin Thomas, Ross Smith IV and Vandy Rodrigues for their review and contributions!

Nagesh Mahadev

Comments (17)
  1. Jeff Guillet [MVP] says:

    Excellent article!

    I’m curious why Public Folders were excluded from this new client access design?

  2. MikeCrowley says:

    Thanks for posting this.  There was mucho confusion when trying to get this setup a few weeks back.  This should help people in the future.

    Here is a diagram of how we implemented this feature:


  3. Joseph T says:

    Who cares about this! With Exchange getting so complex which sane organization would want to waste infrastructure and intellectual capital on this stuff?

    The cloud is the way to go! Email is just a commodity and not a game changer.

  4. Frank says:

    Joseph T: I’ll agree that since Exchange 2007 there has been a pretty clear shift in turning it into a true enterprise product, choosing features and scalability over ease of use.  Most small/medium organizations, i.e. couple of hundred or thousand mailboxes, really should be looking at cloud services (incl. Exchange Online, unless they have specific rules about having custody of their own data of course.  It is getting a bit harder for a jack of all trades IT guy to keep up with all the capabilities of the product… it’s really something that big orgs need to have some specialists in.  On the other hand, while all of the above seems complicated, at the end of the day you can still pop the CD in, go Next-Next-Next and connect with Outlook like you always could.  I’ve seen some pretty complicated Exchange 5.5 diagrams too fwiw

  5. Jeff McLuckie says:

    Great write up. New design makes a lot of sense.

    Store.exe has always seemed a process with too much to do moving business logic and client access functions out a tier is great.

  6. Dave says:

    Thanks for this detailed information. I found it very handy.

  7. PraveenBalan says:

    Very nice article, though the changes were aware it was not so clear. Thank you Nagesh

  8. joBot says:

    Thanks for the interesting and informative post. I enjoyed reading it and look forward to more in the future.

  9. Frederic says:

    I don’t understand this part :

    "This value is the endpoint that Autodiscover will give to the client, and that the client should use to connect to the user’s mailbox."

    Could you please explain with more details the link between the Autodiscover Service and the discovery process for those attributs (homeMDB, LegacyExchangeDN, DatabaseName)

    thanks !!!

  10. danny says:

    Great Article!!!!

    When implementing a Client Access Array, some people would use a third party NLBn now some of the third party NLB do not allow dynamic port required for Rpc connectivity (RPC range TCP 1024-65535) and some solutions or the only solution would be to hard code the ports for rpc and address list.

    Is this something that is supported by Microsoft ???? if not is there a work around for the same ?


  11. iamme says:

    Why would setting the DS Server registry key to a GC in a different domain than Exchange/user domain cause Delegates to fail if the client is talking to the RPC CAS Array for NSPI?  It seems like there’s still some referral for clients directly to GCs in the code.  Setting DS server key to a GC in same domain causes Delegates to start functioning again.

  12. paul says:

    Nice article. Thanks..We’re implementing 2010 and this helps.

  13. DIck Beddoe says:

    Great article, very useful in trying to get to grips with how the engine works… Thanks

  14. Nagesh says:

    @Danny: The Directory endpoints are available for configuration via the app config file: Microsoft.Exchange.AddressBook.Service.exe.config.  Look for the RpcTcpPort key. The MAPI endpoint is configurable via the registry: HKLMSystemCurrentControlSetServicesMSExchangeRPCParametersSystemTCP/IP Port

    You can also take a look at: http://technet.microsoft.com/en-us/library/ff625248.aspx ; section: Configuring Static Port Mapping for RPC-Based Services and http://technet.microsoft.com/en-us/magazine/ff626260.aspx

    “Load Balancing CAS Arrays” section

    @iamme: Not sure there may be a trust issue but I would need a lot more info/troubleshooting to determine the cause for this.

  15. Office concierge says:

    Great article, very useful in trying to get to grips with how the engine works.

  16. arun says:

    Great article Nagesh, really informative :)

  17. Rashed K says:

    Great Article, very helpful and activity, i look for it regarding of Exchange 2010 communicate with Blackberry Enterprise Server 5.0

Comments are closed.