Exchange 2013 focuses on RPC-over-HTTPS

One of the more interesting evolutions incorporated in Exchange 2013 is the decision to use RPC-over-HTTPS as the sole method to connect Outlook clients. In other words, direct MAPI connections over TCP are no longer supported, even for intranet connections.

RPC-over-HTTPS or Outlook Anywhere has been supported since Exchange 2003 so it’s a well-known mechanism by this stage. Insisting that all MAPI clients encapsulate (or wrap) their traffic inside HTTPS packets delivers some advantages from the perspective of Exchange. First, it simplifies the Client Access Server (CAS) as CAS now has one less (albeit very important) protocol to deal with. Second, because CAS doesn’t have to handle MAPI any more, the RPC Client Access service is removed. Apart from reducing the amount of code that runs on a CAS, losing the RPC Client Access service allows Exchange 2013 to function better than Exchange 2010 CAS when supporting site-resilient failovers (for example, you wouldn't have to play with namespaces to effect a site switchover). Third, HTTP is a protocol that is well-suited to connections over many different kinds of networks and RPC-over-HTTPS has proven its ability to reliably support huge number of connections over even extended links like those used to access Exchange Online in Office 365.

The last advantage is gained by being able to remove the requirement to provide Outlook with a server FQDN as its endpoint. Exchange 2010 started the process by switching the endpoint from a mailbox server to a CAS server. Exchange 2013 completes matters by using the mailbox GUID and UPN suffix as the endpoint. The mailbox GUID is unique within an organization and directs Exchange to connect to a user’s mailbox without worrying about a referral from a CAS. You don’t have to reconfigure clients to provide the new endpoint information as this is handled by AutoDiscover when a client connects to an Exchange 2013 CAS for the first time. Note that Exchange 2013 only supports Outlook 2007 or higher, so it really is time to transition off Outlook 2003, despite the now-historical fact that Outlook 2003 was the first client to support RPC-over-HTTPS.

Changing the format of the client endpoint might seem like an exercise in computer science but it is an important step along the way to enable a mailbox to be “portable” within a server infrastructure. Exchange 2007 and previous versions tied mailboxes to specific databases that ran on specific servers. Exchange 2010 removed the link between database and server by moving the MAPI endpoint to the CAS and introducing the Database Availability Group. Exchange 2013 now provides a further level of abstraction in that the mailbox becomes the focus for connectivity. Apart from anything else, this change is supposed to eliminate any chance that Outlook users will see the infamous “Your administrator has made a change to your mailbox. Please restart”. Hopefully this is true.

Because of the fundamental change in the way CAS works, it’s important to follow the deployment advice provided by Microsoft when the time comes to implement Exchange 2013. In a nutshell, you’ll deploy Exchange 2013 CAS servers in Internet-facing sites first followed by internal sites to allow Exchange 2013 to gradually take on the role of handling client connections.

Given that RPC-over-HTTPS is the way forward, we’ll all have to pay more attention to the way that the RPC Proxy Service runs within IIS as this is the component that Exchange depends upon to handle incoming HTTPS traffic. The RPC proxy has to be configured on any server that runs the CAS role and most of the time it works well without requiring further intervention. However, in some instances you might have to tweak various settings to accommodate other network components. For example, to create a full duplex link with Exchange, Outlook uses two TCP connections over a RPC-over-HTTPS link. These are called RPC_In_Data and RPC_Out_Data (see this EHLO post for more information). By default, if no traffic is passing along the two connections, the client keeps them alive by passing some bytes along the link every 720 seconds (12 minutes). Exchange also does its part to keep connections alive but uses a 900 second (15 minute) interval. 

However, while the default intervals are usually appropriate in most circumstances, they can work less effectively if other network devices drop TCP connections sooner. The result is that clients continually lose connections with Exchange and have to reestablish the connection to synchronize or send email, which can then result in symptoms like “my email is stuck in the outbox”. The cure is to reduce the keep-alive interval used by the RPC Proxy component to something like 180 seconds (3 minutes) or even 120 seconds (2 minutes). This is done by updating the value held in the HKLMSoftwarePoliciesMicrosoftWindows NTRpcMinimumConnectionTimeout registry setting and then rebooting the CAS server (or servers, assuming that you spread incoming client connections across a CAS array). The effect is to create a little more network traffic to maintain client connections but this is not normally a concern.

We’re still learning about Exchange 2013. Like all new software it will take time before the technical changes can be assimilated in a way that makes sense. Hopefully that process won’t take you too long!

Follow Tony @12Knocksinna