Wednesday, May 1, 2013

Exchange 2010 - CAS Array

OK. First blog. Subject: the CAS Array or "Client Access Server Array".

Questions about the CAS Array appear quite frequently on the Microsoft Exchange (2010) Technet forums. I emphasize "2010" because the CAS Array is unique to Exchange 2010. Exchange 2007 had no such concept and with Exchange 2013 it has simply been eliminated.

So what is the CAS Array? Contrary to something like a "RAID Array" composed of tangible physical objects - hard drives - the CAS Array is an object in Active Directory, comparable in that respect to a user, contact, group or site.


I had to dissect this concept before understanding it myself:


1. CAS Array = Active Directory object

2. This object links two elements: the "RPC CAS Service" with a DNS name.

3. The DNS name, in turn, is associated with an IP address.


  • As a simple Active Directory object, the CAS Array can be the foundation for a RPC ( = Outlook connections) load-balancing or high availibilty solution but cannot provide any sort of load-balancing or high availability in and by itself.

  • However, the IP address associated with the DNS record can designate a Windows NLB cluster or a hardware load-balancing device. It is this cluster or device that would actually provide the load-balancing.

  • It is considered best practice to configure a CAS Array even when you only have a single Exchange 2010 server. This can facilitate the replacement of one Exchange server by another, since Outlook client settings, configured by Autodiscover, designate an object in Active Directory rather than a specific physical server.

It seems to me that this is quite similar to DFS (Distributed File System) in the file server world where one can map drives to an object in Active Directory rather than to the name of a particular server.  

  • Note that unlike DAGs (Database Availability Groups), a CAS Array cannot span two or more sites.

  • The CAS Array has to do with Outlook, not OWA, not ActiveSync and not Outlook Anywhere (that uses HTTPS - in which the RPC data is encapsulated).

  • The name of the CAS array does NOT have to be included among the names on any SSL certificate. SSL has to do with IIS. Outlook RPC connections have nothing to do with IIS and SSL. This comes up in the Technet forums quite often... and the answer is always NO



Now, my objective is not to provide an exhaustive presentation on the CAS Array. There are plenty of existing resources on the subject and I'll provide some links below. So I'll just present in the most simple and concise manner I can, the procedure for creating a CAS Array.




How to create a CAS array


A CAS Array can be configured in a minimum of three steps - or even two!


1. We create CAS Array object in Active Directory


New-ClientAccessArray -Name CasArray-S1 -Fqdn casarray-s1.mynet.lan -Site Default-First-Site-Name

The command above names the CAS Array "CASArray-S1" and sets its FQDN to casarray-s1.mynet.lan. MYNET.LAN is fictional domain name used for practice.


Currently we have only one Active Directory Site. However, since CAS arrays cannot span sites, and since my network might have more sites in the future, I will create a site-specific CAS Array from the very start.


2. We create a DNS record for the CAS Array pointing to the IP address of my CAS server.


dnscmd dc2.mynet.lan /recordadd mynet.lan casarray-s1 A 10.0.0.21

Note: this is for the present network configuration. If I had - or add - a load balancer, then I would have the record point to the IP address of the load balancer. I used the command line to create the DNS A record in question but it is, of course, possible to use the dnsmgmt.msc GUI. DC2 is the name of the domain controller / DNS server.

 

3. Configure the RPCClientAccessServer attribute on mailbox databases.

If we configure the CAS Array before creating a mailbox database, the RPCClientAccessServer attribute of the database should be configured correctly and automatically without further action.


Note: if no CAS Array is configured, the attribute is set to the FQDN of the CAS (in a single CAS scenario).

 
If we need to adjust the attribute on an existing database, we can execute the following command in the EMS:


Set-MailboxDatabase MBDB1 -RpcClientAccessServer casarray-s1.mynet.lan

Here is an example of settings before and after the reconfiguration of the attribute:


[PS] C:\>Get-MailboxDatabase MBDB1 | fl *rpc*

RpcClientAccessServer : EX10C.mynet.lan

[PS] C:\>Get-MailboxDatabase MBDB1 | Set-MailboxDatabase -RpcClientAccessServer casarray-s1.mynet.lan

[PS] C:\>Get-MailboxDatabase MBDB1 | fl *rpc*

RpcClientAccessServer : casarray-s1.mynet.lan

 


There we go! In the future, the CAS can be changed and Outlook client settings will not have to be adjusted individually - on one condition: that the CAS Array is created before the mailbox database.

Further configuration, such as establishing a static IP endpoint, is possible if desired.



Sources:

Understanding RPC Client Access - Technet.

Exploring Exchange 2010 RPC Client Access service


Demystifying the CAS Array Object

Exchange 2010 Technet Forum

3 comments:

  1. I'm still trying to grasp this. I have 2 Exchange 2010 servers running side-by-side. I need to move all mailboxes from A to B. Should I just link the CAS Array to the databases on server B since server A will be decommissioned? What of the clients. Do I need to point them at the new server or will they re-home automatically?

    Thanks.

    ReplyDelete
  2. First, was the CAS array created before the mailbox database on Exchange server B?

    Second, how quickly can you migrate the mailboxes from A to B?

    If you can do this overnight, or over the weekend, yes, you could simply link the casarray entry in DNS to the IP address of Exchange Server B (instead of A).

    If not, I think you could... do nothing. Even if users are initially directed to A, and even if their mailbox is migrated to B, A will allow them to connect to their mailbox, just like if you had separate CAS and MB servers. If you have CAS A and CAS B, with user mailboxes on MBX1, either CAS A *or* CAS B can provide access to those mailboxes.

    Before you retire A, you would want to set the TTL (Time to live) setting on the record for A to a lower value so clients would not retain an outdated reference in their local DNS cache.

    ReplyDelete
  3. Zohno Tools have come long way since you looked at our software. Will you consider reviewing Zohno Tools version 5.1 ? I understand that you are very busy with personal and professional life, honest review is all we ask for. If you like, we can compensate for your time also.
    Please see http://www.zohno.com/support.html for latest release.
    Thanks
    Denny

    ReplyDelete