One of the truisms much beloved by those who pontificate about designing for Exchange is the necessity to follow “best practice.” There’s absolutely nothing wrong with this approach as best practice is defined to be a method or technique that has consistently shown better results than other methods. In other words, it’s an approach that works well, probably because others have tried different methods and failed.
But the important thing is not to become clogged in best practice and to understand that best practice evolves constantly in line with human experience and developments in the underlying technology.
Take CAS arrays for instance. Introduced with Exchange 2010, CAS arrays provided a method to group a set of CAS servers together in such a way that they could be addressed as a single entity (and had a single IP address and FQDN). Individual servers could join and leave the array over time and the array would keep functioning as long as a single server was active. All-in-all, it was a nice concept, even if a CAS array didn’t perform any load-balancing of incoming client connections. In this respect, you can ignore the statement in TechNet’s documentation of the New-ClientAccessArray cmdlet that says it creates “a load-balanced array of client access servers within a single Active Directory site.” That’s not true, but the vendors of load balancers were all too happy to fill that gap.
Best practice duly had to be formulated and it was proclaimed that you should always create a CAS array within a site and assign the CAS array object to the RpcClientAccessServer property of mailbox databases. The value of RpcClientAccessServer is given by the AutoDiscover process to Outlook clients to populate their profiles when created and provides a MAPI endpoint for connectivity within the site (remember, a CAS server or an array is limited to a site). CAS arrays do nothing for non-MAPI clients such as Outlook Web App (OWA) or Exchange Web Services (EWS).
Once provided with the FQDN of the CAS array, Outlook clients would attempt to connect to the CAS array rather than to an individual CAS when they attempted to open a mailbox, which solved the problem of providing continual access to the mailbox when an individual CAS was taken offline for some reason, such as applying a roll-up update. This alone is an excellent reason for the suggested best practice to be valid and worth respecting.
Roll forward to today and the advent of Exchange 2013. You now observe that the CAS is a tad different. The Exchange 2013 version of the CAS is a much simpler beast as it is purely an authentication (are you authorized to connect to Exchange?) and proxy/redirect (where do you need to go to find your mailbox?) server. No processing is performed of mailbox data by the CAS; all it does is to send on client requests to connect to the mailbox server that hosts the currently active copy of their mailboxes via HTTPS (no MAPI RPCs).
The RPC Client Access namespace, which was introduced in Exchange 2010 to handle the concept of RpcClientAccessServer described above is no more and Exchange no longer uses FQDNs of CAS servers or arrays to locate user mailboxes. Instead, CAS uses the unique GUID assigned to the mailbox. When an incoming client connection must be processed, CAS looks up Active Directory to find details of the mailbox via its GUID (including the database that hosts the mailbox) and Active Manager will tell CAS what mailbox server currently hosts the active copy of the database. Voila!
In passing, I note that the mailbox GUID can be shown to humans from time to time by Outlook when it configures a new profile. I hope that Microsoft finds some method to translate the GUID to something more user-friendly before Exchange 2013 finally ships as otherwise I think this will cause some extra support calls for help desks. Computers are good at translating GUIDs, humans are not.
There are many reasons why Microsoft has taken this route for Exchange 2013, but perhaps the most basic is to uncouple the functionality of CAS from mailbox servers so that both can function independently of each other in terms of geographic location (a CAS in one datacenter can service requests going to a mailbox server in another) and software versions (you won’t have to update CAS and mailbox servers with the same software in future). Overall, CAS 2013 is much, much simpler (another example is how the load balancing focus shifts from layer 7 to layer 4) and CAS 2013 is much more of a lightweight service than before, one that can be removed from service without causing much disruption to the overall infrastructure or client connections.
As for the RpcClientAccessServer property, and our best practice of deploying CAS arrays for Exchange 2010 – well, they’re pretty much dead and buried by the developments in Exchange 2013. The property still exists in Exchange 2013 but it’s an artefact of the past about which we no longer need to concern ourselves, once the migration to Exchange 2013 is complete.
All of this goes to prove that each new version of software brings its own tweaks, improvements, and updates that challenge existing best practice. Those of us who’ve been around software for too many years to remember need to be reminded of this fact from time to time so that we don’t say something silly in public!
Follow Tony @12Knocksinna
