“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:
- The attribute gets set when you create mailbox database.
- The attribute does not seem to get updated when a database is moved.
- 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 (cas1.abc.com) in a site. You then create a mailbox database on a mailbox server in that same site. The RpcClientAccessServer attribute is then defined as cas1.abc.com. Now, if cas1.abc.com 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 (cas2.abc.com) 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:
- When a computer science degree matters, and when it doesn't
- Since when did cloud computing become/need a manifesto?
- Why would one phish using a Certificate Authority (CA) as bait?
- Would I trust you, if everyone else trusted you?
- Here is a good question: Is scripting programming or just systems administration?
- PowerShell boy and the case of the missing cmdlets!
- Fun with PowerShell 2.0 Eventing!
- Creating a custom 404 page to handle link redirection for ASP.NET web applications
Or if you want, you can also check out some of Tyson's latest publications:
- Windows PowerShell Unleashed (2ndEdition)
- Windows Server 2008 Unleashed (Yes, I did help on this book)