Demystifying the CAS Array Object – Part 1

Since its release in 2009, the interest in Exchange 2010 has been fantastic. While working with customers to educate them and prep them for moving to Exchange 2010, we’ve uncovered some common misconceptions. One trend has to do with misconceptions around the Client Access Server array object, or CAS array object for short. Technical Writer and frequent blogger Scott Schnoll suggested I put pen to paper… err… keys to keyboard (?) when I was commenting on this trend on an internal Microsoft distribution group, so here we are with this post.

I’m not going to go into all of the technical aspects of a CAS array object in this post. That’s already been covered wonderfully by Nagesh Magadev in a prior post: Exploring Exchange 2010 RPC Client Access service.

The following list is a collection of truths many customers are not aware of when it comes to the CAS array object which I’ll try to demystify. Part 1 will discuss the first three items and l’ll cover the last three items in part 2.

  1. A CAS array object does not load balance your traffic
  2. A CAS array object does not service Autodiscover, OWA, ECP, EWS, IMAP, POP, or SMTP
  3. A CAS array object’s fqdn does not need to be part of your SSL certificate
  4. A CAS array object should not be resolvable via DNS by external clients
  5. A CAS array object should not be configured or changed after creating Exchange 2010 mailbox databases and moving mailboxes into the databases
  6. A CAS array object should be configured even if you only have one CAS or a single multi-role server.

Everyone confused? Nice. Let’s try to fix that as best we can by going through each of these one at a time. You’ll see some server names throughout this article so why don’t I show you what I’m working with in my lab first?

Name ServerRole AdminDisplayVersion
E2K10-MLT-01 Mailbox, ClientAccess, HubTransport Version 14.2 (Build 247.5)
E2K10-MLT-02 Mailbox, ClientAccess, HubTransport Version 14.2 (Build 247.5)
E2K7-MLT-02 Mailbox, ClientAccess, HubTransport Version 8.3 (Build 83.6)
E2003-BE None Version 6.5 (Build 7638.2: Service Pack 2)

OK, let’s dig in!

1. A CAS array object does not load balance your traffic

A CAS array object performs no load balancing. It’s an Active Directory object used to automate some functions within Exchange and that’s all. Exchange 2010 documentation says all over the place that it’s recommended to use load balancers (LB) to load balance CAS traffic. So what do I mean by saying the CAS array object performs no load balancing?

What you’re actually doing with a load balancer is balancing traffic across a pool of CAS or perhaps you could call it an array of CAS – but not the CAS array object itself. The difference is subtle yet distinct; perhaps we didn’t make the names distinct enough to help prevent the confusion in the first place.

The primary reason, and perhaps the only reason, a CAS array object exists is to automatically populate the RpcClientAccessServer attribute of any new Exchange 2010 mailbox database created in the same Active Directory site (as the CAS array object).

The RpcClientAccessServer attribute is used to tell Outlook clients during the profile creation process what server name should be in the profile. That’s pretty much it folks, there’s no more magic going on here and once you’ve created your CAS array object it’s simply an object in Active Directory and there’s zero load balancing going on at this point in time.

The rest is up to you at this point. It’s up to you to:

  • Create an ‘A’ record in DNS that’ll allow the client machine to resolve the hostname to an IP address. This IP address will most likely be the virtual IP (VIP) of the LB reachable only by internal clients. This VIP is where Outlook or any other MAPI/RPC capable application will then connect to gain access to Exchange 2010 mailbox resources.
  • Configure your load balancing solution to pass traffic to the pool of CAS servers by way of the VIP.

The CAS themselves have no idea there is any load balancing happening.

You may also be confused by what can be seen after creating a CAS array object using the New-ClientAccessArray cmdlet or viewing a pre-existing CAS array object using the Get-ClientAccessArray cmdlet.

Here I’m creating a new CAS array object in my lab with the Name CASArray-A, the FQDN of outlook.lab.local, and in the Active Directory site very aptly named Site-A.

Figure 1: Creating a Client Access array

First of all my FQDN and Name fields don’t match because the Name is a display name – it’s purely cosmetic. It’s whatever you want to name it so you know what that CAS array object is being used for. The FQDN is the record you must then create in DNS or else clients will never be able to resolve it to an IP address to connect to. At this point, I’ll remind you that there can be only one CAS array object per Active Directory site.

So why is the Members property populated with two CAS immediately after creation? Didn’t I tell you there’s no load balancing going on at this point? It looks kind of like I lied to you doesn’t it?

To be honest, the Members property is a touch misleading. If you didn’t read up on the steps to create a CAS array object you may think you’re done at this stage. You created your CAS array object and you can see two CAS have automatically joined the array. By this time you may be off for a celebratory drink or going down cube-town hallway to steal some cookies from this guy. Not quite yet my friend!

Due to the fact that we associated the CAS array object to Active Directory site Site-A, the cmdlet simply goes and finds all Client Access servers registered as residing in Site-A and then lists them in the Members column. I like to tell customers to think of this column as the Potential Members column or as my colleague Kamal Abburi, another PFE here at Microsoft, suggests it’s the Site CAS Members column. You can add these Client Access servers as nodes in your load balancing solution because they all reside in the same Active Directory site. But until the load balancer is configured we have no load balancing.

How did the cmdlets know what site the CAS are in? Well, I’m glad you asked because we get to break out everybody’s best friend AdsiEdit.msc and dig down into the Configuration partition of Active Directory to find the magic beans.

Figure 2: The msExchServerSite attribute of an Exchange 2010 server contains the Active Directory site the server resides in

Each Exchange server has an msExchServerSite attribute that contains the Active Directory site they currently reside in. In case you’re wondering, yes it’s dynamically updated if you move an Exchange server to a new site and the Microsoft Exchange Active Directory Topology service has a chance to run and update a few things. But the AutoDiscoverSiteScope attribute (Part of Get/Set-ClientAccessServer) will not be dynamically updated and you may have funky Autodiscover results until this is fixed – depending on your site, server, and client layout.

2. A CAS array object does not service OWA, ECP, EWS, Autodiscover, IMAP, SMTP, or POP

Let’s go back for a moment to what a CAS array object actually does. It populates the RpcClientAccessServer attribute of an Exchange 2010 mailbox database, which is then used to tell Outlook where it needs to connect when using RPC (over TCP). For Outlook Anywhere (HTTPS) clients, it indicates where the traffic that leaves the RPC-over-HTTP proxy needs to connect on the client’s behalf in order to reach their mailbox.

So what services does the Outlook client attempt to connect to when using RPC (over TCP)?

First Outlook connects to the CAS array object on TCP/135 to communicate with the RPC Endpoint Mapper in order to discover the TCP ports the following two services are listening on.

  1. Microsoft Exchange RPC Client Access (aka MSExchangeRPC)
  2. Microsoft Exchange Address Book (aka MSExchangeAB)

That’s it for RPC (over TCP) mode!

Outlook Anywhere (aka RPC over HTTP) clients connect to the RPC-over-HTTP proxy component on TCP/443 on a CAS by resolving the Outlook Anywhere external hostname, or what the Outlook profile calls the proxy server.

Interesting geeky side note for anyone interested, Outlook automagically and quietly adds /rpc/rpcproxy.dll to the server name specified, as that’s really what it needs to connect to, but if we asked people to type these names in, like we used to back in Outlook 2003 days, can you imagine how many would have missed it, or got it wrong?)

Figure 3: Specifying the RPC Proxy URL in Outlook 2003

Traffic is routed out of the RPC-over-HTTP proxy to the appropriate MAPI/RPC endpoint using a list of hard-coded, rather than dynamically assigned TCP ports, those being TCP 6001, TCP 6002, and TCP 6004. The Outlook Anywhere external hostname is purposefully not the same FQDN as the CAS array object and I’ll explain why later on.

A client may also make HTTPS connections to services such as Autodiscover, OAB downloads, EWS, POP, or IMAP, but these services are defined by entirely different methods such as virtual directory URLs or the AutoDiscoverServiceInternalUri value. None of these additional services are serviced by the CAS array object as none of them are using RPC, although it’s likely to be the same server they are connecting to. The CAS array object’s FQDN may share the same VIP as the other service’s URLs, but we strongly recommend the CAS array object FQDN not be the same as the other services’ URLs if split DNS is in use. More on that last recommendation later.

3. A CAS array object’s FQDN does not need to be part of your SSL certificate name list

This is a very common misconception usually spawned due to the item directly above. SSL certificates in the realm of this article are only utilized when we want to do something like establish an SSL-protected HTTP session. Because RPC (over TCP) is not an HTTP session, it’s not going to be protected with SSL and therefore, we don’t need the CAS array object’s FQDN to be included on the subject name list of the SSL certificate. Let’s take a look at it.

Below is Outlook 2010 in MAPI/RPC mode connected to an Exchange 2010 CAS array object.

Figure 4: Outlook 2010 RPC (over TCP) connections to Exchange 2010 CAS

We can see it has made one directory and two mail connections. In the netstat output (overlayed above the screenshot) we see the machine has made one endpoint mapper connection (TCP 135) to the CAS array object as well as connections to TCP 59531 and TCP 59532 which represent the statically assigned TCP ports for the MSExchangRPC and MSExchangeAB services respectively in this lab.

From the server side we can see the services listening using the command netstat –n –b.

Figure 5: Services Outlook needs to connect to when using RPC (over TCP)

As expected, it shows that none of the services are being contacted over HTTP (to TCP 443). This is why you don’t need the CAS array object FQDN on the SSL certificate.

Thinking you need the CAS array FQDN on the SSL certificate can sometimes be confused by the way Outlook displays connections while in HTTPS mode as seen below.

Figure 6:Outlook Anywhere connections

This time we see Outlook 2010 has made two mail connections and a Public Folder connection when the screen shot was taken and we can also see we are using HTTPS. From within Outlook it looks as if we are connected to outlook.lab.local and E2K10-MLT-01.lab.local, which we are sort of, but utilizing netstat once again we see we are actually connected to the RPC-over-HTTP proxy located at webmail.lab.local on TCP/443 (HTTPS). Outlook will always display what server is eventually connected to for data by itself or via RPC-over-HTTP proxy. If you’re wondering why we see 6 connections via netstat instead of three, it’s because HTTP is a half-duplex protocol and we therefore establish an RPC_DATA_IN and an RPC_DATA_OUT channel for each connection seen inside Outlook.

You may also be thinking, “Wait! Outlook 2007 and 2010 encrypt RPC sessions by default! We have to have the name on the cert!” Wrong-O my friends because the encryption setting you see below utilizes RPC encryption and has nothing to do with SSL. The communication is still happening over RPC and not over HTTPS.

Figure 7: When connecting using RPC (over TCP), Outlook uses RPC encryption

Simple isn’t it! If a CAS array object met a Certification Authority and the CA said: “Hey man you really need me! C’mon I’ll sell you a swanky wildcard cert on the cheap!” the CAS array object would simply reply “Honey badger don’t care!” and probably use the CA to crack open a pistachio. Now that’s of course if you followed our recommendation to use a different FQDN for the CAS array object than you’re using for the other service FQDN(s). Yes, I’m getting to why…

I hope Part 1 of this article has been helpful to you so far in making sense of some common misunderstood issues with CAS array objects, and hope that you’ll tune in for Part 2 at a later time where we’ll cover the remaining three common misconceptions about CAS array objects.

Brian Day
Premier Field Engineer, Messaging

Continue to Demystifying the CAS Array Object – Part 2.

Comments (26)
  1. AA says:

    LOL, I know the URL that defines the name of the CAS Array object doesn't need SSL, but I have included it in a SAN certificate before without even thinking about it.

    I am sure alot of people do that.  As long as you are opening port 443 on the LB then no harm.  Atleast it was an internal CA and it didn't cost me any money.

  2. AA says:

    I meant not opening port 443 on the LB.

  3. Brian Day [MSFT] says:

    @AA, Part-2 will help complete the picture but generally the very same LB will also have TCP/443 open for everything non MAPI; OWA, ECP, EAS, OLA, EWS, etc…

  4. TB says:

    Great article.  If you were bringing up two stand alone multi-role servers in a site (CAS/HT/MB) and you wanted to start using a CAS array but did not have any load balancer in place yet, could you just add an A record for each server using the CAS array name?  Or would you be better off just using a single A record for the CAS array name and letting one of the two servers handle that load until a LB is in place?

    I really don't want to have all the users profiles have the server names and then have to run a profile repair on each one after the '-rpcclientaccessserver attribute is changed if we move to a CAS array at a later time.


  5. Andrey Podlesnykh says:

    Hi Brian,

    Thank you for useful information!

  6. Praveen Kumar Ethiraj says:

    Superb Part 1 Brian, cant wait to read Part 2 :)

  7. Brian Day [MSFT] says:

    Thank you everyone.

    @TB, Part-2 will touch on this, but I would consider creating the CAS Array Object with a friendly FQDN name (e.g. '') , create an A record with a low TTL value (5 mins maybe), set RpcClientAccessServer to point to that FQDN on all DBs, and temporarily point that DNS record to one server for now. It'll mean manual failover for now by changing the DNS record (why we want the low TTL), or if both servers are on the same subnet you may be able to get away with adding an IP to one box, point the A record at that IP, and then move the IP between servers when you have to. If you never plan on implementing a DAG (which you should! :) ) then Windows NLB could be stop-gap option, but we generally recommend a Hardware Load Balancer for all customers. You can usually find me in the Exchange 2010 TechNet forums if you have more detailed questions, but some more coming in Part-2….

  8. Charles Derber says:

    That was a great info for me & added to my knowledge, clarified few things.

    Looking forward on your next part too :)

  9. TB says:

    @Brian…. thanks for the confirmation.  I'll stick with a single A record for now until we can move to a DAG.  

    One more follow up question:  If we change the -rpcclientaccessserver attribute on existing databases once we bring up the CAS array, shouldn't the existing clients continue to work if they still point to a previous multi-role

    server that still exists (and resolves to the server IP).  I know a profile re-creation would update them to show the new CAS array name in the profile but I don't want to have to do that for 700+ users in a particular office.  


  10. Imrul says:

    @TB: Outlook autodicover service will be picking up the new CAS Array name for the OL clients.

  11. Brian Day [MSFT] says:

    @Imrul, this actually isn't the case and Part-2 discusses how AutoD doesn't update the server name in the profile.

    @TB, yes the clients will continue to connect to whatever server their profile was originally setup with.

  12. Praveen Kumar Ethiraj says:

    @brian: Corrent me if i am wrong, its kinda bug in Outlook that it does not update the server name.

    In a cross-site failure when the whole site is down, mailbox become active in DR site thanks to DAG. We have to make sure in DNS CAS in Site A must be made to resolve to an IP of CAS in DR site and we dont have to modify the RPCClientAccess Property of the databases right ?

  13. Imrul says:

    @Brian: We deployed a CAS Array for a customer and later configured the pre-existing DB's rpccclientaccessserver attribute to point to the CAS Array. We found that autodiscover picked up the CAS Array name in the user's OL profile. There was no need  for profile repair/ profile recreation. Yes, there are still some users whose OL was not updated with the new CAS Name  and we had to do the profile repair / profile recreation for those small number of users. So far my understanding and experience, autodiscover is responsible for updating OL with the new cas array name. Please correct me, if I misunderstood anything. Thanks.

  14. Wes says:

    Hi Brian,

    Your recommendation to TB re: a DAG – is that so that they can take advantage of the cluster to add an ip resource that can be used for failover (rather than load balancing) for smaller 2-node DAGs that only require HA but don't have the need for LB?

  15. Brian Day [MSFT] says:

    @Wes, it was just a way to get a relatively quick switchover instead of waiting for DNS updates to propagate but adding a 2nd IP to the NIC (not cluster). WNLB could be used, but if you then wanted to DAG enable the two machines then you'd have to remove WNLB and go with a Hardware LB.

    @Praveen & Imrul, wait for Part-2 then re-ask. :)

  16. Imrul says:

    @brian: no problem. Will be waiting for part 2. Thanks.

  17. Ryan says:

    Regarding #3, if you would like to integrate Lync into OWA, you will need the FQDN of the Client Access server or CAS Array FQDN as the subject line of the SSL certificate.  This ending up biting me when I was integrating Lync into OWA.

  18. Amit says:

    Excellent Article. Waiting for the part 2

  19. Brian Day [MSFT] says:

    @Ryan, Lync does not use the CAS Array Object as it is not using MAPI to integrate with OWA. When setting up the trusted application in Lync you would be using the "Multiple Computer Pool" option and then give Lync a load balanced name (such as also included in the SSL cert, but not the CAS Array Object name (such as Items #2 and #3 come into play here as the CAS Array Object is not used for EWS and it does not need to be on the SSL certificate as long as you properly gave it a name different from all of your other load balanced services like OWA, EWS, AutoD, OAB, etc…

  20. Bhargav Shukla [KEMP] says:

    Great article Brian! Just wanted to mention, lot of customers don't actually utilize different namespaces for RPC vs HTTP traffic hence resulting design uses same name that is used by CAS Array FQDN. This is where the name will need to be in certificate.

  21. Brian Day [MSFT] says:

    @Bhargav, quite right you are my friend which is why Item 4 in Part-2 will discuss this common misconfiguration. :)

  22. Serene says:

    When is Part 2 due Brian..? We're interested in the issues with having a common namespace for the array as well as the client access URLs for OWA, IMAP etc.


  23. Andrei Kondrashov says:

    You touched every aspect I could imagine for your 1-3 items. Air five!

  24. SAT says:

    Great article; but can you guys please enable a "printer friendly' button for those of us that would like to print this for reference materials?  right now we have to cut and paste into Word and reformat to make legible!!!!!!!


  25. Dan says:

    This was a great article – thank you. Wish however this was around before as it would have saved me adding the CAS Array name to our SSL Cert. :-s

    Nice to know for the future however.

    Again thank you as this was very informative

  26. Rod says:

    We may need to fix Chapter 5, lesson 2, pg. 196-197 of MSTS Self-Placed Training kit Configuring Microsoft Exchange Server 2010 which says:

    "A client access array is a collection of load balanced Client Access servers"

    "A client access array is a load-balanced collection of Client Access servers that are all

    members of the same site"

Comments are closed.