If you’re running Exchange 2007 or Exchange 2010 today and want to introduce Exchange 2013 at some point in the future (subject to code being available to permit version interoperability – see below), you’re going to have to put Exchange 2013 Client Access Servers (CAS) into operation. Ideally, the Exchange 2013 CAS will take over the namespace (for example, mail.contoso.com) for the organization and work with its Exchange 2007 or Exchange 2010 counterparts to route incoming client connections to the right mailbox servers.

This topic was addressed by Greg Taylor of Microsoft at the recent TEC event in Barcelona and I thought that he provided a pretty good overview of the way that the new (always improved) CAS handles client connections and why you might need to update existing CAS servers to deal with the way that Exchange 2013 proxies or redirects connections.

In many companies, the usual approach to handle incoming connections is to deploy a load balancer in front of the CAS. For the purpose of this article, “CAS” means either an individual CAS or a member of a CAS array in an Internet-facing site). It doesn’t matter whether the load balancer operates at layer 4 (now supported by Exchange 2013) or layer 7. What does matter is that the load balancer will pass incoming client connections to the CAS.

At this point, the CAS has to decide where to direct the connection. The location of the destination mailbox determines how processing proceeds. Clearly, if the mailbox is on an Exchange 2013 mailbox server, the CAS is able to proxy the connection direct to that mailbox server without any problems. However, if the mailbox is on an Exchange 2007 or Exchange 2010 server, the CAS has to use an HTTP proxy or redirection to transfer the connection to an Exchange 2007 or Exchange 2010 CAS, which then takes responsibility for making the final connection to the mailbox.

The proxy from the Exchange 2013 CAS uses Kerberos to communicate with its legacy counterparts and the destination is the RPCproxy or Outlook Anywhere endpoint (the /rpc virtual directory in IIS), which requires secured connections. If you configure Basic Authentication for Outlook Anywhere, IIS only enables Basic Authentication on the /rpc virtual directory. For this reason, IIS has to be updated to support Integrated Windows Authentication (IWA – previously known as NTLM) connections as otherwise Kerberos won’t work. However, if you were to simply modify IIS to support IWA, it would be overwritten by Exchange and have the side effect of changing the authentication mechanism used by clients to connect to the CAS, which is probably not what you want to happen.

The workaround is reasonably simple – you have to run the Set-OutlookAnywhere cmdlet in the Exchange Management Shell to update IIS on all your legacy CAS servers so that internal (between CAS) connections are authenticated with Kerberos while external (client) connections continue to use BASIC. The command is as follows:

Set-OutlookAnywhere –Name ExCAS01 –ClientAuthenticationMethod Basic                    –IISAuthenticationMethods Basic, NTLM

If you’ve already made the decision to enable NTLM for Outlook Anywhere you don’t need to make any changes to IIS. However, even if this is the case, you still need to consider how the Exchange 2013 CAS proxies connections to other CAS servers located in internal or non-Internet facing sites (that is, without a direct connection to the Internet via a firewall etc.).

This requirement does not exist for previous versions of Exchange so it’s unlikely that Outlook Anywhere is enabled on CAS servers in non-Internet facing sites as they do not expect to process incoming Outlook Anywhere connections. However, if the Exchange 2013 CAS has to proxy an incoming connection because the target mailbox is on a server in an internal site, the proxy is to the Outlook Anywhere endpoint. It therefore follows that the CAS servers in these sites need to be updated by running the Enable-OutlookAnywhere cmdlet so that they can accept the incoming proxy to their Outlook Anywhere endpoint with NTLM authentication enabled.

Microsoft hasn’t yet released the necessary updates that allow legacy versions of Exchange to co-exist with Exchange 2013 so it’s not yet possible to deploy Exchange 2013 into a legacy organization and have the Exchange 2013 CAS take over responsibility for the namespace. Exchange 2010 SP3 is expected in early 2013 and an update to Exchange 2007 SP3 should be available in the same timeframe.

On another CAS-related point, fellow MVP Jeff Guillet points out that Exchange 2013 enables RPC encryption for clients as the default once again. The default was the same for Exchange 2010 so this should only be a worry for those upgrading from Exchange 2007. However, it’s fair to say that only Outlook 2003 clients were really affected by making RPC encryption the default. Exchange 2013 doesn’t support Outlook 2003, so maybe we have nothing to worry about!

Follow Tony @12Knocksinna