Wednesday, August 1, 2012

EHLO: I am Exchange 2013–CAS Role

Hello again and welcome to the second part of my Exchange 2013 articles. As you might have noticed there is already lots of information available on Internet, varying from Microsoft technet articles to blog posts and article posted by some Exchange Geeks like me.

So in this article I’ll share what I have learned until now about the CAS role and try to share my own thoughts on the topic. Great source of of information is the blog of Michael Van Horenbeeck.

Microsoft has called the relation between the MBX and CAS roles “loosely coupled” in their documentation. And here is why:

As mentioned in my previous article, CAS server in Exchange 2013 is only going to proxy the traffic and not render the mailbox data. Besides the advantage of having only Level 4 Load balancing solution (hell you could just use Round Robin), the new architecture will reduce the amount of namespaces you are going to need if you are deploying Exchange across 2 Data Centers, a Site-resilient setup.

In Exchange 2010 site-resilience is extremely complex, and the bad guy here is the client actually - Outlook connecting via MAPI (RPC over TCP) internally needs an endpoint which is provided by the CAS array. Each Database has an attribute called “RPCClientAccessServer” which defines the endpoint for the Outlook client when it connects to Exchange. The “RPCClientAccessServer” attribute is also not too flexible. Although you could change that value in case of failover to state that the database belongs to different CAS array, the mailboxes hosted on that Database will not update this value for the client… Only new mailboxes placed into the Database after the swap will truly have the new endpoint. So you need to play around with DNS to make sure your clients connect to Exchange in case of failover.

In Exchange 2013 the preferred connection method is RPC over HTTPS, or Outlook Anywhere. Coupled with the changes in the architecture the client does not really rely on the value stamped in the “RPCClientAccessServer” of the database where the mailbox is hosted, but instead sends a query including the mailboxGUID@UPN to the CAS server. CAS server does a lookup in Active directory and determines which Mailbox server holds the active copy of the Database for the mailbox, and returns this value to the client. So this is truly dynamic and in does not matter where the mailbox resides, the CAS server will always direct the Outlook client to the correct Mailbox server. I would think it acts as a sort of broker, but instead of load balancing it simply tells the client where to connect.

There is another GREAT feature added, which is Outlook Anywhere Internal URL. Since the preferred connection method is Outlook Anywhere you will most probably want internal clients connecting to you internal server URL instead of the external one. And you can also set different authentication method for internal and external clients. For example you might want to use NTLM internally and Basic externally. This actually was exactly the case by one of my clients and we ended up deploying a whole CAS layer in a different AD site to cater for this.

Have a look at this Article written by Michael Van Horenbeeck. There are nice diagrams there explaining the flow, which I felt were inappropriate to copy here without Michaels permission.

So to summarize: It might seem that Microsoft is sending us to “stone age” by slimming the CAS role, but appearances are VERY deceptive. The new architecture is actually focusing on the Site-Resilience and best interest of the client experience (besides simplifying deployments).


  1. Seems like they focused on the back end, and took 100 light year backward with this junk EAC web console and OWA that looks like google apps. What are they thinking? My god this EAC is horrible.

  2. I have by now worked with EAC, and I must say, it takes a bit of time to get used to, but it does the job well. It is fast and does not require any installation on the machines. Of course a real Exchange admin will opt for Powershell, but me I am a GUI man...

  3. Hi I am trying to research on exchange2013 high availability and Site Resilience.
    We have 3 site .(Primary , Branch and DR site) from the link below it looks like we should be able to achieve automatic failover if I put the witness server on the third site.
    my goal is put 2 Mailbox\CAS server on the primary site and 1 Mailbox\CAS at the DR site
    is this configuration be possible if not what is the minimum server requirement to achieve this. We are small company I cannot justify the cost of 4 exchange server

  4. Hi, I believe it will work in your scenario!