“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:
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:
Or if you want, you can also check out some of Tyson's latest publications:
With more than ten years of experience in IT, Tyson Kopczynski has become a specialist in Active Directory, Information Assurance, Windows automation, PKI, and IT security practices. Tyson is also the founding author of the Windows PowerShell Unleashed series and has been a contributing author for such books as Microsoft Internet Security and Acceleration (ISA) Server 2006 Unleashed and Microsoft Windows Server 2008 R2 Unleashed. He has also written many detailed technical papers and guides covering various technologies. As a consultant at Convergent Computing, Tyson works with and provides feedback for next generation Microsoft technologies since their inception and has also played a key role in expanding the automation and security practices at CCO. Tyson also holds such certifications as the Certified Information Systems Security Professional (CISSP), the SANS Security Essentials Certification (GSEC) and SANS Certified Incident Handler (GCIH), and the MCTS (Application Platform, Active Directory, and Network Infrastructure).