Exchange Server 2010 and RPCClientAccessServer Madness!

What is the RpcClientAccessServer attribute and how might if affect my Exchange Server 2010 deployment?

“A déjà vu is usually a glitch in the Matrix. It happens when they change something.” Needless to say glitches happen a lot with new software and Exchange Server 2010 is no stranger. As we all know, there has been many fundamental changes to how Exchange operates under the hood. In tonight’s post, I would like to zero in on a particular change and a related glitch that I happened to get hit upside the head with. :>)

The change that I’m referring to is MAPI on the Middle Tier (MOMT). In short, this is a new feature (most likely be renamed before RTM) which is designed such that clients will no longer terminate their MAPI connections at a mailbox server. Instead, a MAPI connection is terminated on a Client Access Server, which then proxies the connection back to the correct mailbox server that holds the database. By doing this, in theory the end-user experience is improved because MAPI “access” to their mailboxes is transparent to the actual mailbox database location. Thus, a mailbox server failure or mailbox move should not impact a user’s connection to their mailbox provided another copy of their mailbox is online at the time.

Now, to make all of this wonderful proxy wonderment a reality each mailbox database object has an attribute called RpcClientAccessServer. The information contained in this attribute is what point’s clients back to the MAPI end-point that they should be using. No problem seems easy enough. Well, that’s not entirely true:

  1. The attribute gets set when you create mailbox database.
  2. The attribute does not seem to get updated when a database is moved.
  3. The attribute also does not get updated when the CAS server defined in that attribute is down or removed from the organization.

Err… To illustrate the problem, let’s say that you install one CAS ( in a site. You then create a mailbox database on a mailbox server in that same site. The RpcClientAccessServer attribute is then defined as Now, if is turned off, or worse removed from the organization all client access to their mailboxes is “interrupted”. Making matters worse, even if I bring up another CAS ( the RpcClientAccessServer attribute still needs to be manually updated on each mailbox database to reflect that change.

In other words… issues. However, to be fair, the E2010 product team did try to build in a fix. The idea that they came up with is called a CASArray. Thus using the New-ClientAccessArray cmdlet you can create an object that represents a load balanced array of Client Access servers within a single Active Directory site. I can then define the CASArray as the value for the RpcClientAccessServer attribute. Great! Now, in theory this solves the issue when a single CAS server fails. However, it’s still a little concerning that the RpcClientAccessServer attribute is static and there is no logic built into E2010 to maintain the value in that attribute.

For example: what about in cross-site failover scenario? Hmmmmmm… me wonders!

If you like this, check out some other posts from Tyson:

Or if you want, you can also check out some of Tyson's latest publications:

Lastly, visit the Microsoft Subnet for more news, blogs, and opinions from around the Internet. Or, sign up for the bi-weekly Microsoft newsletter. (Click on News/Microsoft News Alert)

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2009 IDG Communications, Inc.