Welcome back! In Demystifying the CAS Array Object - Part 1 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, SMTP, or POP
  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.

  1. A CAS array object should not be resolvable via DNS by external clients
  2. A CAS array object should not be configured or changed after creating Exchange Server 2010 mailbox databases and moving mailboxes into the databases
  3. 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 clients

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 don’t, and if you do you’ll 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 outlook.corp.contoso.com while your other non-RPC (over TCP) service URLs utilize something like mail.contoso.com 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 contoso.com. 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 mail.contoso.com 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 Internet-facing 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 SomeFunkyNameThatDoesNotExist.contoso.com 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 URL.

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 is-alive 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 is-alive 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 can’t 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. Wouldn’t you rather be using a load-balanced pool of Client Access servers about the time that happens? ? Yes, you would!

You may think to yourself “Ok smarty pants, if that day ever comes I’ll create a CAS array object and fix RpcClientAccessServer on the databases and life will be good.” I’m 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 article’s 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 doesn’t matter. I guess one could argue it doesn’t 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 you’re 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 everyone’s 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.

Brian Day Premier Field Engineer, Messaging

Not applicable

Can't stress enough "A CAS array object should not be resolvable via DNS by external clients".

Not applicable

Great Article !!  CAS Array is great concept  for MAPI . i would like to have features should be load balanced /clustered   instead of  Hardware load balancer ...

Not applicable

We worked around the DNS issue (apparently we cannot and will never implement split DNS) by adding a line in the hosts file on each CAS to point to " servername". Outlook Anywhere works perfectly now, but didn't before.

I understand it may not be a supported configuration, but that's the way it is.

Not applicable

Great articles! Very informative. I had always created CAS Arrays upfront, but I was completely unaware of the fact that a profile would have to be manually fixed if a CAS Array was introduced into the system later on. Good to know.

Not applicable

Thanks for sharing such information Brian

Not applicable

Could it by any mean you can make clear/elaborate the 4th part as am unable to get the message out of the paras in regards to the subject

And the rest was informative & Thanks!

Not applicable

@Brian: Now it makes sense why AutoD does not update the OL profile. Thanks.

Not applicable

@Imrul, glad to hear Part-2 cleared it up. :)

@Charles, in summary #4 means two things; (1) don't make your CAS Array Object FQDN the same as the URLs you use or OWA, EAS, etc..., and (2) make sure the CAS Array Object FQDN is only resolvable by internal clients and not resolvable from the internet. If the CAS Array Object FQDN is resolvable externally your Outlook Anywhere clients may have a 30-60 second delay when trying to connect because it will think it is on the internal network and attempt an RPC (over TCP) connection instead of HTTPS. Even if you don't use Outlook Anywhere today I'd strongly suggest following this practice just in case you do deploy it in the future.

Not applicable

Thanks for clarifying, that was so ease to understand.

I was aware of the best practice but again thanks for the jotting down the impact of getting delay and trying to connect rpc via OA.

Enjoyed :)

Not applicable

You're quite welcome, Charles.

Not applicable

Super explaination Brian :)

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

Here if we want the clients to update their profile to point to the Cas-array in the main site(once the CAS-array in the main site is back up and running), instead of decommisioning the CAS in the DR site , can we just stop the services in the DR server or something else ?

Not applicable

Praveen, currently, when a datacenter switchover happens all you do for the CAS Array Object is change the DNS entry to point to the virtual IP of your CAS Array Object In your disaster recovery site. Clients do not reconfigure themselves and you do should not be changing the RpcClientAccessServer of the databases as part of a datacenter switchover. This is why the CAS Array Object should have a low TTL, perhaps 5 minutes, so clients begin using the new IP soon after you update the record. When your primary site is operational again all you do is change the DNS record once more to point back to the primary virtual IP.

Not applicable

The fact that Outlook profile will not be updated but user will still have access to his mailbox after cross-site mailbox move is true only if AllowCrossSiteRPCAccess is set to true (or is this setting always set to true, as in SP2 help to set-databaseavailabilitygroup i see that "The AllowCrossSiteRpcClientAccess parameter is reserved for future use by Microsoft")?

What if there is no DAG, will RPC access work cross site?

Not applicable

Pawel, the AllowCrossSiteRPCAccess setting currently does nothing in Exchange 2010. You can ignore that setting for now.

Not applicable

Hey Brian

I was reading in a technet article that even if you have a single CAS in the domain, even then it is recommended to configure CAS array.. Although i could not understand the logic of configuring CAS array with a single CAS in the domain.. Can you please help me in understanding the same?

Thanks in advance!

Not applicable

@v-2, Item # 6 in this article goes into why you may want to use a CAS Array even if there is a single CAS in the environment. It is all about future-proofing the solution. If you ever have to replace or add additional CAS resources at a later time due to growth, or perhaps hardware failure, it will make your job far easier when that time comes. If item #6 is not clear please do let me know, we can always follow-up with each other.

Not applicable

Thanks for the info Brian..

I guess i have understood item no.6.. I asked that question since i am working with the SBS team.

I am reading DAG and CAS array. Can you help me with good study material, so that i can start from basics.

(Already gone through technet)

Please feel free to mail me the study material, if possible -- v_2akgup@msncs.com

Thanks in advance!!

Not applicable

Thanks Brian for this article.

I plan to deploy CAS Array in my infrastructure, but it's not possible for me to repair all Outlook profil (arround 1000users)..so is it possible to give CAS server name to CAS Array (in this situation Outlook point directly to the good URL) ?

Of course, we planned to uninstall the CAS server.

Ex : cas server name exchange.company.com

cas array name : exchange.company.com

The Cas Array Name must not be resolvable on the Internet but in my situtation i don't know how i can do...

Our users just using Outlook RPC overs HTTPS (and OWA, non RPC connection).

Thanks ;)

Not applicable

@Jr., if all clients are for example currently pointing at "CAS-01.company.com" and you uninstall that server and create a static DNS record with the same name that points to a load balanced IP then you should be fine. I would however still suggest creating a good non-server-specific CAS Array Object FQDN and use it on your databases so any new user that comes online will get the proper CAS Array Object FQDN and be all set. Over time your users with the old CAS name in their profile will eventually begin to reduce due to attrition, future mailbox moves across sites (with SP2 RU3) or other reasons.

Not applicable

Ok thanks Brian.

So, in my case the deployment steps are :

1) change IP of CAS-01.company.com to point to my Load balancer

2) Uninstall Exchange on the actual cas server (with name CAS-01.company.com)

Am i right ?

Actually RpcClientAccessServer attribute in my database is "CAS-01.company.com". Can i create a cas array with that name too to avoid problem with Outlook ?

Not applicable

@Jr, I suggest creating a better CAS Array FQDN than CAS-01.company.com. You don't want it looking like a specific server name, you want something more general sounding.