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.
- A CAS array object does not load balance your traffic
- A CAS array object does not service Autodiscover, OWA, ECP, EWS, IMAP, POP, or SMTP
- A CAS array object's fqdn does not need to be part of your SSL certificate
- A CAS array object should not be resolvable via DNS by external clients
- A CAS array object should not be configured or changed after creating Exchange 2010 mailbox databases and moving mailboxes into the databases
- 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.
- Microsoft Exchange RPC Client Access (aka MSExchangeRPC)
- 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.
Premier Field Engineer, Messaging
Continue to Demystifying the CAS Array Object - Part 2.