This chapter describes the optimization of the Messaging Application Programming Interface (MAPI) used between Microsoft Outlook clients and Exchange servers. The combination of Outlook and Exchange server is one of the most common client and server combinations for email in a corporate business environment. This chapter includes the following sections:

MAPI comes in two forms: extended and simple. This chapter discusses the extended form, which is used by Outlook. The simple form is included as part of Microsoft Outlook Express and is not discussed here.

In the last ten years, MAPI has evolved through Exchange 5.5, Exchange 2000, Exchange 2003, Exchange 2007, and Exchange 2010. Outlook versions have followed in close coordination. RiOS can perform optimization for each of these Exchange versions.

For information about Exchange 2013, see Microsoft Exchange 2013 Optimization.

Because of the requirements of Exchange 2003, the Exchange server communicates using an encrypted conversation with compatible versions of the Outlook client. By default, the encryption mode is enabled in Exchange 2007 and Exchange 2010. RiOS securely optimizes this encrypted MAPI traffic by using the RiOS MAPI optimization along with the Windows-domain-related RiOS features.

Cached Exchange Mode was introduced with Outlook 2003. Cached Exchange Mode attempts to hide performance issues over the WAN by preemptively downloading new email and their attachments from the Exchange server to a cache of storage on the local hard disk of the Outlook client workstation. Although this gives an appearance of fast performance, it has no effect on emails going to the sent items or trash folder of the user. Using Cached Exchange Mode also means that any mail, including unwanted or junk mail (and attachments), is downloaded to the Outlook client. RiOS provides optimization for Outlook clients using Cached Exchange Mode, both by reducing the increased WAN bandwidth impact of Cached Exchange Mode and decreasing the wait time for arriving and transmitted emails.

For more information about configuring MAPI optimization, see the SteelHead Management Console User’s Guide.

The Exchange server includes an Endpoint Mapper (EPM) that listens on TCP port 135. The Outlook client connects to this port and is assigned random TCP server ports to communicate with the Exchange server using the MAPI protocol. These MAPI connections are used to send and receive emails, calendaring, address lookup, and more. You can configure the Exchange server to use a fixed TCP port for the MAPI connections.

The conversation between the Outlook client and the Exchange server is quite complex. The following is a basic overview for the Exchange server communication:

Other conversations between the Outlook client and the Exchange server include opening folders for reading or searching, deleting items, and synchronizing folders. Synchronizing folders is required to download and read emails from the Exchange server to the Outlook inbox. Figure: Outlook Client and Exchange Server Synchronization shows the synchronization process. The incremental change synchronization (ICS) state is how the client knows what new items to download from the Exchange server.

SteelHead MAPI optimization is based on the streamlining of ROPs.

RiOS intercepts and optimizes the EPM conversation between the Outlook client and Exchange server on TCP port 135. For Outlook client connections that are configured for correct addressing, the client-side SteelHead alters the port that the EPM service sends to the Outlook client for MAPI connections (default is port 7830). For port or full transparency addressing modes, no changes are made to the reported MAPI port, and the Outlook client connects to whichever port EPM assigns to MAPI. RiOS intercepts and optimizes subsequent connections made to the MAPI port and performs MAPI-specific optimization on them.

If the Outlook client connections to the Exchange server are intercepted and optimized, MAPI-specific optimized connections are not used when the client-side SteelHead has an in-path rule to pass-through traffic on TCP port 135 (or the server-side SteelHead has a peering rule to pass-through traffic on TCP port 135).

After RiOS learns the MAPI port for an Exchange server, RiOS no longer goes through the autodiscovery process for connections to the Exchange server IP address and learned MAPI port. Although this gives some performance benefits to new MAPI connections (especially in large latency WANs), it also means that configuring pass-through or other types of in-path rules might not have the immediately desired impact on traffic.

When using fixed-target rules to optimize MAPI traffic, configure the client-side SteelHead to optimize traffic where the destination IP address is the Exchange server and the destination port is 7830 (or whatever port is configured on the client-side SteelHead for MAPI optimization). If you want optimization for NSPI connections, a fixed-target rule in which the destination IP address is the Exchange server and where the destination port is 7840 (or whatever port is configured on the client-side SteelHead for NSPI optimization).

The MAPI optimization module comprises several optimization techniques:

The following are MAPI optimization methods on the SteelHead:

When optimizing encrypted MAPI traffic, normal encryption methods are maintained between the Outlook client and client-side SteelHead and between the Exchange server and server-side SteelHead.

To ensure the optimized MAPI connection between the two SteelHeads is also encrypted, configure RiOS secure inner channel. For detail, see the SteelHead Deployment Guide.

The Windows Security section also provides information about the relevant, earliest version of RiOS to ensure support for different Windows client operating systems and Windows domain structures.

For more information about how to ensure the SteelHead is joined to the domain, as well as configuring transparent or delegation modes, see Domain Relationships.

You can confirm that the SteelHead is successfully performing encrypted MAPI optimization by going to the SteelHead Management Console Current Connections report and looking for the highlighted lock icon listed in the Applications column of the report page. In versions prior to RiOS 8.6, this is listed as ENCRYPT-MAPI.

If for some reason this is not successful, you see a red triangle in the Notes column.

You can see the WAN KB values are higher than the LAN KB values. For information about how to troubleshoot this problem, see the SteelHead Management Console User’s Guide.

Enabling support for encrypted MAPI when there is a mixture of both encrypted Outlook clients and native Outlook clients allows the native clients to benefit from optimization.

In RiOS 8.6 and later, applications are defined by the DPI engine. All Exchange connections are displayed as MAPI, specifically DCE-RPC > Exchange-Protocols > MAPI. Encrypted MAPI is noted by the highlighted lock icon. You can also see this on the client machine by holding the Control key and right clicking on Exchange icon in task tray.

MAPI admission control for Microsoft Outlook are control measures to prevent the SteelHead from entering admission control when there are many TCP connections. Admission control is a state a SteelHead enters when it has stopped optimizing new connections because it has exhausted a certain type of resource. During admission control, new connections pass through, while existing connections are optimized. Upon exiting admission control, the SteelHead once again intercepts and optimizes new connections.

For more information about admission control, see the SteelHead Deployment Guide and the SteelHead Management Console User’s Guide.

When you use an Exchange server and the clients are using Microsoft Outlook, Outlook initiates and maintains multiple TCP connections with the Exchange server. A MAPI session is the collection of multiple TCP connections from an Outlook client.

When Microsoft Outlook connections are optimized, the SteelHead remaps contexts to prevent inadvertent mixing of optimized and nonoptimized traffic. MAPI differs from other protocols because the TCP connections of a session are not independent of other TCP connections from the same session.

Because of how Exchange servers interact with MAPI sessions, you must optimize all client MAPI connections by the same pair of client-side and server-side SteelHeads, or have them all set to pass through. If you optimize only some of the connections, the session fails. If the connections are not optimized by the same pair of SteelHeads, the session fails.

Prior to RiOS 7.0, MAPI admission control v1 used a threshold percentage used to calculate control. For example, if a SteelHead had a 1000 connection limit, the admission control cutoff value of 85% was 850 connections. The remaining 150 connections were made available only for existing MAPI sessions.

MAPI admission control v2 in RiOS 7.0 and later is enhanced to include:

While the SteelHead is in the admission control state, a special handling of MAPI sessions is activated. Because new connections cannot be optimized for an existing client session, the SteelHead closes all connections from this existing client. Outlook reestablishes connectivity to the Exchange server, and because the SteelHead is in an admission control state, the new connections of the client are detected as pass-through connections.

MAPI admission control is helpful when there are two client-side SteelHeads in a serial cluster. MAPI optimization expects all connections from an Outlook client to be optimized by the same SteelHead and not split across two SteelHeads. However, the thresholds in RiOS 7.0 and later significantly reduce the likelihood of this situation occurring.

In a typical parallel deployment in which you configure the SteelHeads as connection forwarding neighbors, the SteelHeads forward new MAPI connections to the SteelHead that detects the initial MAPI connection for the user session. This effectively avoids failure situations in which the MAPI connections for a single session are not optimized on the same SteelHead.

In larger Microsoft Exchange deployments it is possible that the Exchange server comprises several nodes working in a cluster. With Exchange 2010, the cluster can have some form of load balancer to distribute connections among the various nodes in the cluster, including one or more client access servers (CAS) that act as a front end to the mailbox servers. You must configure the client-side SteelHead with one of the following settings:

CAS requires RiOS 6.1.1 or later. There is not a specific configuration required on the server-side SteelHead to support optimization for Exchange clusters.

Riverbed recommends RiOS 6.1.4 or 6.5.1 for Exchange clusters that use multiple CAS and Microsoft Network Load Balancing (NLB) for load balancing.

Outlook Anywhere (OA) is a feature in Exchange 2003 or later. It allows Outlook clients to connect to Exchange over HTTP or HTTPS. Remote users can connect to Exchange without using specialized VPN software. The Outlook Anywhere protocol uses a variant of the existing MAPI protocol transported over HTTP. In releases earlier than RiOS 6.5, the SteelHead was unable to provide latency-specific optimization for this traffic.

Outlook Anywhere optimized traffic uses the new RPC over HTTP optimization engine, as well as the existing MAPI, HTTP, and SSL optimization features.

Outlook Anywhere can leverage both traditional MAPI and encrypted MAPI. If you use encrypted MAPI, the server-side SteelHead must be a member of the domain.

The following table shows encryption types using HTTP and encrypted MAPI.

The following list describes requirements for Outlook Anywhere:

The communication flow of Outlook Anywhere is among an Outlook client, the Outlook Anywhere server, and an Exchange server. The Outlook Anywhere server is an RPC Proxy server. The server takes RPC calls to and from the Exchange server, removes the RPC headers, and encapsulates the data in HTTP or HTTPS. Because MAPI is a full duplex protocol, two HTTP/HTTPS connections are required for each Outlook Anywhere connection. This is called a virtual connection.

Figure: Virtual Connection shows the RPC connection between the Outlook Anywhere server and the Exchange server. The Outlook Anywhere server strips the RPC headers, and encapsulates them in either HTTP or HTTPS, and sends them to the Outlook client. The Outlook client then strips the HTTP from the session and reads the traffic as RPC and MAPI.

Outlook prefers to make connections with TCP/MAPI. Despite configuring Outlook to use Outlook Anywhere (RPC over HTTP) connections, Outlook sometimes checks to see if it can connect to the Exchange server with a TCP/MAPI connection.

A Common Access Card (CAC) is a type of smart card often used in military and other high-security environments. The cards are usually about the size of a credit card and contain a chip that holds one or more public-key infrastructure (PKI) certificates and an identifier that is unique to the card holder.

You can configure Outlook clients and Exchange servers so that they communicate only with each other after the user has inserted the CAC into a card reader attached to the client and entered a PIN. When a CAC is used, the communication between the Outlook client and the Exchange server is sent over a secure connection known as S-Channel.

You can configure SteelHeads to optimize traffic over S-Channel as part of an Outlook Anywhere over SSL (RPC over HTTPS) session. You must first configure your SteelHeads to optimize Outlook Anywhere over SSL, including installing the correct certificates.

After you complete this initial configuration, you must configure the server-side SteelHead to enable support for S-Channel:

Next, configure the client-side SteelHead to enable support for passive key derivation (PKD):

You can verify the Outlook connection status. It is important that you verify that the connection state is HTTP or HTTPS, and not TCP.

View the Reports > Networking: Current Connections page to identify if the active connections are standard MAPI (MAPI-OA) or encrypted MAPI (eMAPI-OA).

The following list describes how to troubleshoot issues with Outlook Anywhere optimized traffic.

Riverbed recommends that you disable SSL and MAPI encryption to facilitate troubleshooting and easily decipher packet captures.

By default, Exchange 2010 only accepts encrypted MAPI connections. This is not a problem for the SteelHead because of the encrypted MAPI feature. However, for troubleshooting purposes, Riverbed recommends that you disable encrypted MAPI.

Microsoft has made significant changes to Outlook MAPI-based traffic optimization in Microsoft Exchange 2013. Client access is simplified by elimination of the traditional EPM and MAPI protocols. This new implementation enables users to more easily access to mailbox servers by leveraging well-known protocols HTTPS and HTTP. This change in protocols also enables organizations to define tighter network security for their Exchange environments by allowing only HTTP and HTTPS traffic from client-facing networks.

Figure: Client Traffic Using Wireshark shows an example of client traffic from Exchange 2013 and Outlook 2013 using Wireshark.

Figure: Exchange Traffic on Port 80 shows that the Exchange traffic is traversing HTTP TCP port 80 using a netstat -n output from the client running Outlook 2013.

Figure: Outlook Connection Status Window shows the Outlook Connection Status window.

To take advantage of the MAPI-based traffic optimization change, you must configure your SteelHeads to optimize Outlook Anywhere traffic. RiOS enables Outlook Anywhere-TCP streams to be initially intercepted by the HTTP protocol optimization function, and then it transparently switches to Remote Procedure Call (RPC) over HTTP.

For information about configuring Outlook Anywhere, see Outlook Anywhere Optimization.

This section provides information about MAPI over HTTP. It contains the following topics:

Upon the release of Outlook 2010 update (KB 2878264), Outlook 2013 SP1, and Exchange Server 2013 SP1, Microsoft added a new dialect to the Exchange communication protocol. Rather than placing a wrapper around remote procedure call (RPC) in HTTP, Microsoft created a full version of MAPI that can be wrapped in HTTP. This new configuration is officially called MAPI over HTTP transport protocol.

To use this new dialect with the Outlook and Exchange Server versions, you must enable MAPI over HTTP on all Client Access Servers (CAS) across the Exchange deployment. With Exchange Server 2016, MAPI over HTTP is enabled by default at the organization level. Even with MAPI over HTTP enabled, the Exchange server can still use RPC over HTTP (Outlook Anywhere) for any Outlook clients that are not MAPI over HTTP capable.

MAPI over HTTP reduces the overall load on the Exchange environment by decreasing the client-to-server connections to two per MAPI-over-HTTP connection. MAPI over HTTP makes the entire conversation stateless. A client can change to a different CAS throughout the lifetime of the session to the Exchange infrastructure and not have to authenticate on each new server connection. This protocol change is a significant improvement compared to the legacy Microsoft RCP over HTTP protocol.

In RiOS 9.2 and later, the SteelHead can:

Full MAPI over HTTP latency optimization is provided on the SteelHead by the MAPI over HTTP feature. This feature includes latency optimization, data reduction, and TCP optimization. MAPI over HTTP has acceleration parity with the legacy native MAPI (RPC over TCP) optimization feature with the exception of MAPI prepopulation.

The down negotiation feature removes information from the Outlook client request that is being sent to the Exchange server and forces the connection to use RPC over HTTP (Outlook Anywhere). RPC over HTTP is still available on the Exchange server to support Outlook clients that are not MAPI-over-HTTP capable. Remember that one of the improvements made by Microsoft with MAPI over HTTP is that it uses fewer TCP connections compared to previous Outlook-to-Exchange dialects. Therefore, when you use down negotiation, you increase the connection count compared to MAPI over HTTP.

For more information about down negotiation, see MAPI over HTTP Down Negotiation.

To use MAPI over HTTP you must have RiOS 9.1 or later on the client-side and server-side SteelHeads. If you use a lower version of RiOS, optimized traffic connections fail.

To optimize MAPI over HTTP traffic, you must change the default in-path rule to enable Exchange Autodetect (Figure: Changing the Default In-Path Rule), which is a latency optimization policy. Exchange Autodetect automatically detects MAPI transport protocols (Autodiscover, Outlook Anywhere, and MAPI over HTTP) and HTTP traffic. The Exchange Autodetect latency optimization policy should only be applied to HTTP traffic. If you do not enable this policy, the MAPI over HTTP feature does not engage and connections in the current connections page shows as HTTP only, with minimal data reduction.

SSL is required for MAPI over HTTP to work properly. For more information about SSL, see SSL Deployments.

When you properly configure the in-path rule, the SteelHead Current Connections report looks similar to Figure: MAPI over HTTP Connections.

Riverbed recommends that you adopt MAPI over HTTP natively. However, there are certain instances in which you might require RPC over HTTP connections. For example, your server-side SteelHeads might not yet be enabled to support MAPI over HTTP optimization.

To enable MAPI over HTTP down negotiation, you must meet the following requirements:

To see the status of the MAPI over HTTP engine, enter the show protocol eos command.

If you place an Exchange server behind a firewall, you must use static MAPI ports for the firewall to statefully inspect traffic to and from the MAPI servers. Default dynamic port mapping is not available in this scenario. You must enable static MAPI ports to Exchange Client Access servers that are placed behind load balancers for RiOS to correctly track connections.

A typical MAPI connection has the following flow:

In high-security environments it is desirable to hard code the Exchange server port in the event that multiple Exchange servers need multiple static ports. With a firewall between the clients and the Exchange server, an issued dynamic port cannot always be interpreted. The default behavior of the SteelHead is to remap the port to a single dynamic port. This causes a problem for MAPI servers running on multiple defined ports and the operation fails.

After you disable remapping capabilities of the MAPI software, MAPI has the following flow:

Both MAPI and Outlook Anywhere enable multiple protocols to run over an individual TCP session and a TCP connection with the same TCP source and destination port. This feature minimizes the number of TCP connections consumed per client. Multiple context is when a client requests a new protocol over the same TCP connection. This technology has become increasingly prevalent with the adoption of Exchange 2013. RiOS 9.0 or later supports multiple context. Prior to RiOS 9.0, multiple contexts caused the connection to enter pass-through mode and create errors in the log, similar to the following examples:

and

RiOS 9.0 and later support multiple context. Riverbed recommends that you enable this feature in an Exchange 2013 environment. Enabling this feature does not have any adverse effect on nonmultiple context traffic.

For more information about Outlook Anywhere, see Outlook Anywhere Optimization.