Exchange 2007’s Client Access Server (CAS) role, while similar to the Front-End server configuration of Exchange 2003, introduced a number of new features and capabilities that distinguished it significantly. For example, instead of just passively acting as a relay for Internet-based access to a Back-End server via Outlook Web Access (OWA) and ActiveSync like in Exchange 2003, the Exchange 2007 CAS role actively facilitated access for such functions and, in doing so, offloaded some load from the back-end Mailbox server role. In Exchange 2007, OWA, ActiveSync, and Outlook Anywhere (formerly RPC-over-HTTPS) clients all connected through the CAS role as an endpoint, which then connected to the Mailbox role to provide access to the necessary content. However, native on-network Outlook MAPI connectivity still connected directly to the Mailbox role for mailbox access.
Introducing the RPC Client Access Service
In Exchange 2010, the dependency on CAS increases dramatically, as on-network Outlook connectivity now connects to the CAS role via the newly introduced RPC Client Access Service. At a basic level, the RPC Client Access Service is simply an RPC endpoint written for the CAS role so that it can service or refer native MAPI connectivity requests from Outlook. This fundamental change in client connectivity helps to facilitate a better client experience during switchovers or failovers (see an upcoming blog post on Database Availability Groups and the changes to high availability and disaster recovery in Exchange 2010) such that any client will see only a 30 second disconnection, as compared to 1 minute or more previously. In addition, this architectural shift allows the usage of the same business logic for Outlook clients as for other CAS clients (OWA, ActiveSync, etc.). This, in turn, allows for better calendar logging and fixup, better content/body conversion, and simplified Active Directory topology requirements for Outlook.
This increased dependency on the CAS role makes high availability of this role even more important than before. Where some firms may have simply deployed multiple servers with the CAS role installed and relied on reactive measures to move OWA, ActiveSync, and other services to another server if the primary were to fail in Exchange 2007, this would not be acceptable in Exchange 2010. MAPI profiles on user workstations will now have a reference to the CAS role as the Exchange access point and, as a result, must be sufficiently resilient to failure.
CAS High Availability Options
The least expensive option to provide high availability for the CAS role remains native Windows Network Load Balancing (NLB). NLB is widely considered to be an unintelligent load balancer because it does not inspect underlying services or ports on an NLB cluster node to determine if it can fulfill a client request. Instead, if the node itself is up and reachable, it is considered a candidate for load balancing. Situations where this may cause problems for the CAS role would be if the server itself was up but the Exchange or IIS services had failed. In this scenario, NLB could still direct incoming client requests to a failed server for processing. However, despite this significant limitation, its cost effectiveness (specifically that it is included in Windows Server) make it attractive for many firms. Some creative scripting could be leveraged to forcibly take various NLB cluster nodes offline if a particular service stops or a port is unreachable to mitigate this problem but, given the importance of CAS to a firm’s environment, I would encourage pursuing other options if at all possible.
Other possibilities to provide high availability for the CAS role include physical and virtual load balancing appliances. These devices receive requests for a particular host name/IP address and intelligently route these requests to appropriate servers that can fulfill them.
Introducing the ClientAccessArray
Regardless of the method chosen for high availability, once it is configured, there are a few Exchange 2010-specific steps that must be completed before clients should attempt to connect. Specifically, a ClientAccessArray should be created and the RPCClientAccessServer attribute on all mailbox databases should be appropriately configured. A ClientAccessArray is new to Exchange 2010 and simply represents a set of Exchange 2010 servers with the CAS role installed that are load balanced in some fashion. It provides a layer of abstraction between the client and whichever CAS it is connected to as a result of the load balancer’s assignment. Without this layer of abstraction, an Outlook client would attempt to connect to the load balanced name of its set of CAS servers, such as internalCASArray.client.local, and the load balancer would return an available server, such as NYCAS01.client.local. The Outlook client would then be connected to only a single CAS server and, should that server fail or go offline, Outlook connectivity to Exchange would be severed. The ClientAccessArray keeps the Outlook client connected to a shared hostname that can be serviced by any available server the load balancing method chooses.
Configuring a ClientAccessArray
Assuming a load balancing method has already been deployed and configured, the process for creating a ClientAccessArray is quite simple. For the purposes of this example, I will assume that the hostname internalCASArray.client.local is configured such that its associated IP address is managed by the load balancer.
-
- Launch the Exchange 2010 Management Shell.
-
- Run the following cmdlet:
New-ClientAccessArray -Name “Internal CAS Array” -FQDN internalCASArray.client.local
One ClientAccessArray can be created per Active Directory site and, once it has been created, new mailbox databases will automatically detect its existence and configure themselves to use it. However, for any mailbox databases that have already been created, you must update the RPCClientAccessServer attribute on each database to configure client mailboxes hosted on these databases to also use the ClientAccessArray.
3. Run the following cmdlet:
Set-MailboxDatabase “NAME_OF_DATABASE” -RPCClientAccessServer internalCASArray.client.local
Note that you could also set the RPCClientAccessServer attribute by running Get-MailboxDatabase | Set-MailboxDatabase -RPCClientAccessServer internalCASArray.client.local and it would configure this attribute for all mailbox databases in the organization. If you have multiple sites, you would want to restrict this.
4. Check the output of the following cmdlet to confirm that the RPCClientAccessServer attribute was set properly for the appropriate databases:
Get-MailboxDatabase | Select Name,RPCClientAccessServer | fl
Once the above steps have been completed, try creating a MAPI profile for a user hosted in Exchange 2010. Enter your load balanced name (internalCASArray.client.local), a username, and click Check Name. You should see your load balanced name remain and not be replaced by one of your underlying CAS servers!