A closer look at the changes in the Client Access Infrastructure in Exchange Server 2013

Disclaimer:

All the information in this blog post is subject to change as Exchange Server 2013 is still under construction. Although it’s not very likely that big changes will occur between now an RTM, it might.

In a previous post, I already mentioned there were some fundamental changes in the way Outlook clients would connect to Exchange: RPC (over TCP) is no longer supported as a direct access mechanism for Outlook clients. Instead, Outlook clients will now connect using HTTPS (Outlook Anywhere).

In this article, we will dig a bit deeper into this subject and cover some of the questions I’ve received over the past few days.

RPC over TCP is dead, long live RPC over HTTP!

Exchange 2010 was – especially with regards to namespaces – relatively complicated. In a typical site-resilient architecture, you could potentially end up with up to 8 namespaces. One of the evil-doers is the RPC Client Access Endpoint: because RPC over TCP was used, Outlook needed an (RPC) endpoint to which it could connect to. What endpoint to connect to is defined by a property of a mailbox database called “RPCClientAccessServer”. Each mailbox database potentially has it’s own value for it, but it’s more likely that – certainly in a highly available setup – multiple databases share a common endpoint, usually being a CAS Array.

To retrieve what the RPC endpoint for a given database is, run the following command:

[sourcecode language=”powershell”]Get-Mailboxdatabase | Format-List *RPCClient*[/sourcecode]

This value is also represented in the user’s local Outlook profile:

Moving from RPC to HTTP in Exchange Server 2013 actually solves some ‘problems’:

• You are no longer required to have ‘fixed’ endpoint (server FQDN) to connect to
• the Client Access Server no longer requires a RPC Client Access Service

Because you no longer have a RPC Client Access Service, you don’t require a namespace (server FQDN) for it, making the design of a highly available Exchange 2013 environment a little simpler.

Nonetheless, Outlook still needs somewhere to connect to. In Exchange Server 2013, Outlook will use AutoDiscover to create the new connection point. This connection point is made of a Mailbox GUID and an UPN Suffix:

How does this change affect the way load balancing is performed?

Before answering that question, we first need to take a look at how an Exchange 2013 Client Access Server handles requests coming from Outlook clients. The following image displays how a connection from Outlook to the mailbox is created:

Note   Before contacting CAS to access the mailbox, the Outlook client will perform an AutoDiscover lookup at startup to retrieve it’s settings, which includes the endpoint based on the Mailbox GUID.

1. Outlook connects to the CAS (Array) using HTTP. In the request, it provides the endpoint in the form:<mailboxguid>@upn
2. CAS will extract the endpoint and perform a lookup for the user in Active Directory, using the mailbox GUID.
3. AD will provide the user information back to CAS, which will then perform an Active Manager lookup to determine which Mailbox Server currently has the active mailbox database copy mounted in which the user’s mailbox is located.
4. CAS now proxies the request to the appropriate Mailbox server.

Because CAS will only proxy requests and data rendering only happens on the backend server (Mailbox server role), it doesn’t really matter what CAS is used to connect to the mailbox server. As a result, we no longer need affinity for the user’s session to the Client Access Server. This is also what Microsoft refers to when stating that CAS and MBX are “loosely” coupled.

Since affinity or persistence is no longer required for a user’s session, you can revert to ‘simple’ Layer 4 load balancing which is IP-based. This also means that you could consider using DNS Round Robin. It should be noted though, that DNS Round Robin doesn’t care whether the Exchange server is healthy or even running. So if you’re planning on using DNS RR, you still need to take into account a DNS records’ TTL. This means that during a *-over event, clients potentially can experience some (limited) downtime. This downtime is usually equal or less than the TTL of the record, without taking into account DNS replication of course.

Does this mean that you cannot use L7 Load Balancing anymore? No. You could still do that. However, there’s no real need for it.

Personally, I would still recommend using a Hardware Load Balancer. These devices offer some advantages over NLB or DNS RR like better performance, advanced health checks and – depending on what device you choose – perhaps some other functionalities (revers proxy) as well. If you already bought a Hardware Load Balancer in the past, you should be fine. However, I am curious to see how vendors will react to this change as you don’t require  devices anymore that perform advanced Layer 7 load balancing. You could now safely choose products from the lower ranger of a vendor’s product portfolio…

What design changes does this new behavior imply?

Because in Exchange 2010 there was a tight relationship between CAS and Mailbox, you were required to have a at least one CAS server in the same AD site as a Mailbox server. However, this requirement no longer applies. You could now deploy a Mailbox server in one site, while having your CAS servers in another site. This opens up the possibility to create a site that serves as single access point to your mailbox data which is possibly stored elsewhere.

To better understand this, let’s have a look at the proxy and redirection behavior of a Client Access Server in Exchange 2013. The following image display three different scenario’s (each indicated by a different color):

1. Outlook connects to the CAS (possibly though a L4 Load Balancing device)
2. The CAS finds that the mailbox is located in the same site and will forward the request to the appropriate Mailbox server.
   
3. Outlook connects to the CAS
4. CAS finds out the mailbox is located in Site 2. Site 2 contains a CAS which has an externalURL set. CAS in Site 1 will issue a redirect to the Outlook client.
5. The Outlook client will now connect to the CAS in Site 2
6. The CAS in site 2 will forward the request to the appropriate Mailbox server
   
7. An Outlook client in Site 2 connects to the CAS
8. The CAS determines the mailbox is located in Site 3. However, site 3 does not have a CAS deployed or the CAS has no ExternalURL set.
9. The CAS will proxy the request to the appropriate Mailbox server in site 3.

The Client Access Servers is a proxy… Does that mean I can deploy it in my DMZ?

I’ve had a few questions about this earlier. CAS is now indeed only proxies request. However, it still is a domain-joined computer. Technically speaking, you could deploy it in a DMZ. At least as long as you make sure that all required ports to your internal network are open. In other words: you would have to make your firewall look like a Swiss cheese… The questions therefore isn’t so much if you could do it, but rather: would you want to do it…?

How do I configure what URL an internal client should connect to?

In Exchange 2010, you could only specify the External Hostname. Exchange 2013 now conveniently adds the “Internal Hostname”. You can change the value with the following command:

[sourcecode language=”powershell”]Get-OutlookAnywhere -Server <servername> | Set-OutlookAnywhere -InternalHostname <CASArray>>[/sourcecode]

You can also define what authentication mechanism internal clients should use:

[sourcecode language=”powershell”]Get-OutlookAnywhere -Server <servername> | Set-OutlookAnywhere -InternalClientAuthenticationMethode <auth_method>[/sourcecode]

Note   after running the command, allow a few minutes for the settings to become active

For more information what other parameters you can use with this command or to see what authentication mechanisms are supported, please have a look at the following page: http://technet.microsoft.com/EN-US/library/85806a0c-0e98-4aba-b103-8ec128dd4222(EXCHG.150).aspx