http://marcdekeyser.com

Exchange 2013: The Client Access Server

We've been beaten to death with it at this point: "Exchange 2013 introduces fundamental changes in roles and architecture compared to earlier versions." But what does this mean? Today we are going to have a look at the Client Access Server Role (or CAS for short) and what role it serves in Exchange 2013.

Fundamentals

Before talking about anything else we have to keep in mind that the "new" CAS Exchange role does 3 things and only those things:

1. The CAS authenticates the connection made by the user so that it can determine who is trying to connect.

2. Once authenticated it will locate the user's mailbox and find out on which mailbox server that mailbox is currently active

3. It then proxies the connection from that user to his or hers mailbox on the mailbox server and maintains that connection or redirects it to the appropriate CAS server.

Superficially that doesn't look at all to different from Exchange 2010, but under the hood we can see that the CAS role got significantly "dumbed down".

Autodiscover (external clients)

When an external client opens his mailbox and establishes a connection to the Exchange 2013 CAS server through autodiscover.contoso.com it will authenticate, the CAS will look up where the mailbox is stored and build the connection accordingly.

If the mailbox is local on an Exchange 2013 mailbox server, nothing much special happens. The CAS proxies the connection to the 2013 mailbox sever. If the mailbox would be on an Exchange 2010 mailbox server the connection will be proxied to an Exchange 2010 CAS server in the same site to handle the request.

If the Exchange 2010 mailbox server is in another, non-internet facing, site the Exchange 2013 CAS server will proxy to the 2010 CAS server to handle the request.

In the case of coexistence with Exchange 2007 things are slightly different… Once the traffic hits the 2013 CAS box it will forward the 2013 mailbox will answer the AutoDiscover request and will proxy the authentication to the outlook anywhere enabled 2007 CAS in either a local or remote site.

Autodiscover (internal clients)

Internal clients in an Exchange 2010 coexistence scenario will behave in a similar fashion to external clients. The main difference is that, like before, the SCP records will be looked up in the almighty triangle (Active Directory) and the client will make the connection to the CAS server or the load balanced namespace if you decided to deploy in this fashion (which really is the recommended way to go to be honest!)

In the case of a 2007 coexistence scenario the same is true. Lookup would occur in Active Directory which points to the load balanced namespace (or a single CAS server) and from the Exchange 2013 Mailbox server would handle the rest, just like in the external scenario.

Outlook connectivity

Internally and externally Outlook uses Outlook Anywhere (Https) traffic to connect to the Exchange 2013 environment. The big difference in regards to earlier versions is that 2 connection strings are offered to clients depending their location, internal or external.

Load balancing

In Exchange 2010 load balancing had the requirement to be performed on layer 7. This requirement was due to the simple fact that session state was tied to a specific server in 2010. In 2013 stateless sessions for outlook connectivity was introduced and, as such, the requirement for a layer 7 load balancer is no longer needed and we can revert to using a layer 4 capable device. Good news if you are deploying a new environment or just moving to 2013 from 2007, bit of a pain if you invested in a layer 7 load balancer for a 2010 environment.

That being said, there is still a use for a layer 7 load balancer… Since layer 4 load balancer have no idea what the actual target URL (like /owa or /ews) it could pose a problem for the health probes in Exchange 2013…

When performing health probes with a layer 4 load balancer the result of the test will determine the health of the server, not of the protocol on that server.

On the other hand, when a layer 7 load balancer is used the SSL terminiation will reveal the full URL and the health probes will be able to determine health checks on a per protocol level (yes that means that, if for example, the OWA was not working properly only owa traffic will be directed away from that server.)

There is a way around all of this though as the above is true when a single namespace is used (mail.contoso.com). If you were to set up a namespace per protocol (owa.contoso.com, ecp.contoso.com, etc) you would be able to use a layer 4 load balancer and have health check on a per protocol level



Feedback

# re: Exchange 2013: The Client Access Server

Hi,

Great article. I'm in the middle of setting up an Exchange 2013 environment. We are currently running 2007 with all roles installed on 1 server... The new build out will be the following:

2-Server
Ex2013a=Both roles installed
Ex2013b=Both roles installed

Server specs:
HP DL380 Gen8
32 GIGS-Ram
700 GIGS-HD RAID 10

We don't want to spend money on a load balancer. How can we make this design semi-redudant. DNS? What happens if Ex2013a server goes down?

We also can't use NLB because CAS/Mailbox roles needs to be separated out.

Any recommendations? Thoughts?



Our current 2007 store is about 120 gigs in total. Any advice or comments would be appreciated.

Thanks!
J 5/21/2013 9:51 PM | Joel

# re: Exchange 2013: The Client Access Server

DNS round robin would be your only option. And that isn't really redundant as you will still be sending connections to a failing server. You can get a HLB quite cheaply already, you don't need a layer 7 device, a layer 4 will do but you would need more names on the certificate if you are publishing to the internet... 5/21/2013 11:49 PM | Marc

# re: Exchange 2013: The Client Access Server

I have a coexistance o Exchange 2010 and 2013. Mail flow between the servers is working perfectly. The roles on Exchange 2013 Servers are installed separatly.
Clients on 2013 server cannot connect to automatically to the server, only manual.
What should I do? 1/9/2014 11:49 AM | Constantin

# re: Exchange 2013: The Client Access Server

Hey Joel,

I would look at ARR (Application Request Routing) as an option. You can set it up to do health checks and then forward requests accordingly.

http://www.iis.net/downloads/microsoft/application-request-routing

http://blogs.technet.com/b/exchange/archive/2013/07/19/reverse-proxy-for-exchange-server-2013-using-iis-arr-part-1.aspx

Regards,

P 1/13/2014 6:18 AM | Parth

# re: Exchange 2013: The Client Access Server

I've been discussing the issue constantin has been having offline. 1/13/2014 8:49 AM | Marc