Exchange Geek's Weblog

I'm a Geek!

Exchange 2010 CAS Role and High Availability

Posted by Milind Naphade on 21/03/2010

I am working on a Exchange 2010 design these days. The design needs to be in a way so that the maximum availability can be achieved. For Exchange 2010 mailbox server roles I didn’t worry much because a DAG dispersed across the sites can take care of it very well. However, it is a little challenging job to design HA for CAS and HT servers.

If my primary site fails due to catastrophic conditions the Exchange DAG will of course failover to another site where passive copies of my databases exist but what about my CAS and HT server roles. I am least bothered about the HT server roles either because they  have their built in logic to load balance themselves and keep working with just a little modification in my MX records on internet (if at all I have multiple records which are pointing to another server in another site then there is very little left that I need to worry about, so this functionality eliminates the need of Exchange 2010 HT failover or high availability. Needless to say; this is the perfect solution in case I have already setup my internal settings correctly). Now, let’s think of CAS server role. CAS does not have any built in logic to load balance between themselves unless they are a part of a CAS array and/or NLB. If one server fails the other server can still work using the NLB. Yet the question remains unanswered, how do I achieve maximum availability to configure HA between my CAS server roles in case of a complete site failure?

As I mentioned above, they don’t have any built in logic for this but of course, there are ways around to configure it with a little additional efforts. So what do in this case? A simple DNS modification would serve the purpose.

Let’s us say I have two sites involved in this scenario. Site A and Site B, Site A is my primary site. Where:

  1. MAIL.COMPAY.COM is the name of my CAS Array in Site A.
  2. MAIL.COMPANY.COM is an internet facing site.
  3. INTERNAL.COMPANY.COM is the name of CAS array in another site.

Due to some reasons the whole of Site A goes down and CAS servers are totally inaccessible then I change followings:

  1. Change the IP address of to point to the new IP address of INTERNAL.COMPANY.COM on internal and external DNS servers both. Revert these changes when your site is back online.
  2. Configure Outlook to “on fast network, connect via RPC, on slow network, connect via HTTPS” – This way outlook uses Outlook Anywhere if it connects to discover the RPC endpoints. This works perfect with Outlook 2003 and Outlook 2007 in cached mode.

In this solution the only drawback is, it needs the time to replicate the changes across the globe (on both internal and external DNS servers). If you have SCOM then it makes your life much easier to handle this situation.

Bottomline, for CAS servers in Exchange 2010, using the CAS Array capabilities of Exchange 2010 will allow you to create a CAS Array in each Exchange site and then configure the system to major an array object in your primary site resolve to a CAS Array in your secondary site until the primary site is back up and running.

Please do let me know if you think I have missed on anything in above. I would be glad to learn if you can think of any better solution than it 🙂

EDIT: Elan Shudnow has two excellent articles covering the considerations related to CAS HA. Read more here:

3 Responses to “Exchange 2010 CAS Role and High Availability”

  1. Not a simple yet a powerful solution;

    UAG – Unified Access Gateway

    Individuals who are still left with a taught of what this might be, in simple words SSO SINGLE SIGN ON. As this is a microsoft product compatability issues will not come us, although configuring this is a pain, it still is a pretty viable solution.

    Best part is this can very well work as a hardware load-balancer, All you need is change the nat in the background. This product comes with ready made publishing rules (just like ISA) so setting it up and makeing is work is not a big deal.

    Hope this helps.

  2. Using a CAS Array in another site is only useful if you also have a cross-site DAG and have made a database copy active in that other site. And yes SCOM monitoring and alerting can automate changing the DNS records for you. However, the best solution is to use a second tier of load balancer with global scope to provide entire site failover. Check out F5’s BIG-IP GTM product line for more information.

    @Raghunath, UAG does not work as a hardware load balancer. TMG/UAG can only provide round robin type balancing for web farms, that is HTTP and HTTPS only. A CAS Array requires RPC (TCP 135) plus the dynamic range (1024-65535) balancing and that is why you need either WNLB or a HLB. You are correct in that TMG/UAG will solve your SSO problem as long as the other site you wish to have SSO with is published with the same listener AND TMG/UAG is a member of the domain.

  3. Thanx Brian I appreciate your comment. I did not consider hardware load balancers in this case. Yes, they can do it in much better way of course.

Sorry, the comment form is closed at this time.

%d bloggers like this: