You are on page 1of 14


Demystifying the CAS Array Object - Part

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. Im 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. Lets 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
dont I show you what Im working with in my lab first?



E2K10-MLT- Mailbox, ClientAccess,


Version 14.2 (Build 247.5)

E2K10-MLT- Mailbox, ClientAccess,


Version 14.2 (Build 247.5)


Version 8.3 (Build 83.6)

Mailbox, ClientAccess,



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 didnt 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 theRpcClientAccessServer attribute of any new Exchange
2010 mailbox database created in the same Active Directory site (as the CAS array
The RpcClientAccessServer attribute is used to tell Outlook clients during the profile
creation process what server name should be in the profile. Thats 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 LBreachable 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 namedSiteA.

Figure 1: Creating a Client Access array

First of all my FQDN and Name fields dont 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, Ill 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? Didnt I tell you there's no load balancing going on at this point? It looks
kind of like I lied to you doesnt it?
To be honest, the Members property is a touch misleading. If you didnt read up on
the steps to create a CAS array object you may think youre 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 cubetown 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 SiteA, 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, Im glad you asked
because we get to break out everybodys best friend AdsiEdit.msc and dig down into
theConfiguration 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,
Lets 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 clients behalf in order to reach their
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)
Thats 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 thats 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 Ill 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 its likely to be the same server they are connecting
to. The CAS array objects FQDN may share the same VIP as the other services
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
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

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
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
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

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 isnt it! If a CAS array object met a Certification Authority and the CA
said: Hey man you really need me! Cmon Ill sell you a swanky wildcard cert on
the cheap!the CAS array object would simply reply Honey badger dont 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 youre
using for the other service FQDN(s). Yes, Im 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 youll tune in
for Part 2 at a later time where we'll cover the remaining three common
misconceptions about CAS array objects.

Demystifying the CAS Array Object - Part

we covered these three items to begin demystifying the CASarray object in
Exchange Server 2010.
1. A CAS array object does not load balance your traffic
2. A CAS array object does not service OWA, ECP, EWS, Autodiscover, IMAP,
3. A CAS array object does not need to be part of your SSL certificate

Here in Part 2 we will cover the following three items, and once and for all lift the
fog away from the CAS array object to help you correct existing deployments and/or
plan more strategically for future deployments.
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 Server 2010 mailbox databases and moving mailboxes into the
6. A CAS array object should be configured even if you only have one CAS or a
single multi-role server.

4. A CAS array object should not be resolvable via DNS by external

As mentioned in Part 1 (at least twice, I stopped counting) your CAS array object
FQDN should not be the same FQDN used for other services such as OWA, ECP,
EWS, EAS, Autodiscover, or the Outlook Anywhere external hostname.
The primary reason for this is Outlook Anywhere clients will first attempt to resolve
the CAS array object FQDN via DNS so it knows if it should even bother to attempt a
RPC (over TCP) connection or go right to HTTPS. Do you allow RPC (over TCP)
connections directly in from the Internet to your Intranet? I hope you dont, and if
you do youll be getting a big red flag on your Exchange Risk and Health
Assessment Program report. If the client does first attempt to connect via RPC
(over TCP) due to being able to successfully resolve the CAS array object
FQDN there could be a significant delay before the client falls back to attempt an
HTTPS connection to the Outlook Anywhere proxy URL. This delay may result in
higher helpdesk call generation if end users perceive this delay as degraded
performance and/or the service being broken.
To avoid this situation simply make sure your internal CAS array object FQDN is
something unique to internal DNS, perhaps like while your
other non-RPC (over TCP) service URLs utilize something
like internally and externally via split DNS.
If you haven't had the opportunity to utilize split DNS, it is when you have a set of
internal AND external DNS servers handling requests for the same forward lookup
zone, for example The two DNS infrastructures are completely
isolated from each other. There are no zone transfers, nor are they utilizing each
other as DNS forwarders. This configuration allows internal users utilizing the
internal DNS infrastructure to resolve the host to an internal IP
address (for example, that goes to your load balancer VIP while
external users resolve it to the public IP address which may point to your Internetfacing Forefront TMG/UAG infrastructure in your perimeter network. It's very
common for the CAS array object IP address and the internal IP address of the non-

RPC (over TCP) service URLs (OWA, ECP, EWS, etc) to be the same load balancer
VIP, but they may utilize different is-alive checks for proper service state detection.
Does your DNS serve a wildcard response?
I've had at least one customer who had an external DNS server that utilized a
wildcard record in response for any query it received for a non-existent hostname.
This meant you could send a DNS request
for and the DNS server would
always return the IP address of their corporate web site. (Wildcard records are
completely valid from an Internet standards viewpoint. See section 4.3.3 in RFC
1034 for details -Editor).
Because of this their Outlook Anywhere clients could always resolve the CAS array
object FQDN and would first attempt a RPC (over TCP) connection before switching
to HTTPS. If you find yourself in a similar situation with an external DNS server
utilizing a wildcard responses for a particular forward lookup zone, I'd recommend
trying to avoid using that forward lookup zone for your Outlook Anywhere proxy
A quick detour if we may to remind you not to forget to configure the proper service
health monitors for your load balancing solution. For the best service monitoring
results consult with your load balancing solution vendor. Check out Exchange
Server 2010 Load Balancer Deployment for a list of the load-balancer vendors
who've gone through Exchange 2010 solution testing and links to their relevant web
pages (for Exchange 2010). Note, it's *not* a definitive list of supported load
balancing vendors in any way. It's simply a list of vendors who've chosen to engage
with Microsoft directly for solution testing and support.
A quick and dirty example may be that your HTTPS service based FQDNs have isalive tests performed against TCP/443 responses and the load balancing solution
stops sending new client traffic to any Client Access server which stops responding
on TCP/443. The CAS array object RPC (over TCP) service FQDN may have is-alive
tests performed on the RPC Endpoint Mapper on TCP/135 as well as the two static
TCP ports you chose for RPC Client Access Service and the Address Book service. If
any of those three ports stop responding on a particular Client Access server, the
load balancing solution will not send new client traffic to that CAS for RPC (over TCP)
until all of ports begin responding once again. If you don't configure static TCP ports
then Exchange will choose a dynamic TCP port for each service at startup making isalive testing more difficult if not impossible for some load balancing solutions.

5. A CAS array object should not be configured after creating

Exchange Server 2010 databases
Many times we're all in a rush to install the Mailbox servers, have the mailbox
databases created, and hopefully begin storage solution validation testing
with Jetstress. May I suggest you slow your horses down for a moment and save

yourself some trouble later? While Mailbox servers are considered by many to be
the most important server role, it's no good to you if the front door is nailed shut
because you cant get to them through Client Access servers.
If you start creating mailbox databases before a CAS array object is in place you'll
see a random Client Access server in the same Active Directory site stamped on
the RpcClientAccessServer attribute of the each database.
Instead of looking like it should (use the CAS array object's FQDN)

Figure 1: If a CAS array object is created, the RpcClientAccessServer property of

the mailbox database is populated with the CAS array object's FQDN
It will look something like this:

Figure 2: If the CAS array object is not created, the RpcClientAccessServer property
of the mailbox database is populated with the Client Access server FQDN
Client profiles will look like the following

Figure 3: If a CAS array object is not created, Outlook clients are configured with
the Client Access server's fqdn

Clients will connect like the following

Figure 4: Clients connect to the Client Access server's fqdn

At first glance this may seem very innocuous and everything will work just fine, but
you are setting yourself up for trouble later. If you start to move mailboxes to
Exchange Server 2010 with this configuration in place Outlook will use the CAS
name in the Server field of the user profile. It'll work, unless that Client Access
server becomes unavailable or is perhaps decommissioned at a later date and
replaced with a differently named server. Wouldnt you rather be using a loadbalanced pool of Client Access servers about the time that happens? ? Yes, you
You may think to yourself Ok smarty pants, if that day ever comes Ill create a CAS
array object and fix RpcClientAccessServer on the databases and life will be good.
Im here to tell you that will only work for mailboxes you move to Exchange 2010
after the fact. Any user with a pre-existing Outlook profile configured to point to a
CAS name and not the CAS array object will continue to connect to the CAS name
and it will not update itself to utilize the CAS array object FQDN.
The profile will not update itself because the client will not receive
an ecWrongServer response from CAS. It will not receive this response because any
CAS is a valid connection point for any mailbox database via RPC (over TCP) so
clients can survive datacenter switchover/failover events without being reconfigured
and all an admin has to do is flip the CAS array object DNS record to point to a
surviving pool of CAS. Currently the only way to fix mailbox profiles would be a
manual profile repair within Outlook, by publishing an Office PRF file via GPO (not
going to work for non-domain joined machines), or by decommissioning the CAS
server named in the users profiles so the endpoint is no longer available. This last
option should (test test test!!) trigger a full profile repair by Autodiscover in Outlook
2007 or Outlook 2010. Outlook 2003 is only repairable with a profile repair or a PRF
file. Autodiscover will not as of this articles writing update a profile to a new server
name as part of the normal Autodiscover process which updates the Outlook
Anywhere configuration and discovers EWS URLs for other features such as OOF
Management, Free/Busy, and Inbox Rules management.

This also means if you move a mailbox from a database in an AD Site-A that uses a
CAS array object named Boston-CASArray to a database in AD Site-B which uses a
CAS array object named Redmond-CASArray that the profile will not update and the
server name field will remain the Boston-CASArray FQDN is. You may want to keep
this in mind if you have a user population that migrates to different sites due to job
changes or perform a massive internal mailbox move to another site at some time
during the solution lifecycle. If you do find yourself creating Exchange 2010
databases before creating a CAS array object it is imperative that you go back and
fix the databases RpcClientAccessServer attribute to use the CAS array object
before moving mailboxes into the databases.

6. A CAS array object should be configured even if you only have one
CAS server or one multi-role server.
Reflect for a moment about what was discussed in the prior item. A client will not
update itself to use a CAS array object if you add one at a later time. Well what if
you only have one CAS? You may think it doesnt matter. I guess one could argue it
doesnt matter at that very moment, but why not future proof things if you can and
save some cycles and frustration later? What if a year from now you find yourself in
need of replacing that CAS? If youre clients profiles are all pointing to a CAS name
then you have no clean way to transition them without some kind of outage or
manual work. You will have to repair their profiles with one of the means already
mentioned after adding a new CAS, or you will have to decommission the existing
CAS and introduce a new CAS with the same hostname which will require some
downtime. To me none of those options are acceptable.
What if later on your business requirements change and then dictate you should
have client access high availability? You can only achieve this goal by adding a
second CAS and a load balancing solution. You will find yourself stuck in the same
boat again having to repair everyones profile through one of the means already
discussed. Again these are not acceptable options to me.
What I would suggest is you create a CAS array object from the very beginning. How
do you do that if you have no load balancer and only a single CAS? Simple!
Configure the CAS array object like you normally would. Give it a name, an AD site,
a FQDN, and then simply point the DNS A record to the IP as the only existing CAS
or multi-role server you have at that time. You have just future-proofed yourself and
if you ever have to replace the single CAS or multi-role server all you have to do is
build the new server, and then change the DNS record IP address and everything
keeps working without interruption. If you ever want to add high availability at a
later time then all you have to do is get your load balancing solution operational
and then change the CAS array object DNS record IP address to point at the VIP of
the load balancing solution. Easy!
Hopefully this article has been helpful in addressing some of the CAS array object
misconceptions and will go a long ways towards helping everyone move towards a
healthy Exchange Server 2010 migration.