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