About Microsoft Exchange Acceleration

The MAPI communication mechanism is also known by a more recent name: Microsoft as Outlook-Exchange Transport Protocol. The combination of Outlook and Exchange server is one of the most common client and server combinations for email in a corporate business environment.

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.

Exchange server communicates using an encrypted conversation with compatible versions of the Outlook client. By default, the encryption mode is enabled. SteelHead securely accelerates this encrypted MAPI traffic by using the SteelHead MAPI acceleration along with the Windows-domain-related SteelHead features.

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. SteelHead provides acceleration 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 acceleration, see the SteelHead User 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:

3. The Outlook client performs remote operations (ROPs) to open (that is, create and write) a new email message, saves the changes, and creates and adds an attachment, if needed.

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 acceleration is based on the streamlining of ROPs.

SteelHead intercepts and accelerates 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. SteelHead intercepts and accelerates subsequent connections made to the MAPI port and performs MAPI-specific acceleration on them.

If the Outlook client connections to the Exchange server are intercepted and accelerated, MAPI-specific accelerated 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 SteelHead learns the MAPI port for an Exchange server, SteelHead 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.

Always use the in-path probe-mapi-data command to perform autodiscovery for MAPI connections and to allow in-path rules to have immediate impact, even on Outlook clients that are currently accelerated.

When using fixed-target rules to accelerate MAPI traffic, configure the client-side SteelHead to accelerate 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 acceleration). If you want acceleration 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 acceleration).

The MAPI acceleration module comprises several acceleration techniques:

Each separate MAPI connection is used by one user only, but it is common for one Outlook to have several MAPI connections active simultaneously—and it usually does. For example, in a branch office where a SteelHead accelerates MAPI traffic for several users, there are several accelerated MAPI connections per user, but no single MAPI connection is shared between users. However, when a user closes Outlook and triggers the start of a MAPI prepopulation session, there is only one accelerated MAPI prepopulation connection per user.

The following are MAPI acceleration methods on the SteelHead:

• MAPI acceleration—This method is the fundamental component of the MAPI acceleration module and includes acceleration for Read, Write (Receive, Send), and Synchronize operations. This setting uses port 7830 and is enabled by default. If the Exchange server is not configured to use random ports (allocated by EPM) and needs to use a fixed port configured by the administrator, you must change port 7830 to the fixed port number used by the Exchange server.

• MAPI prepopulation—Allows a SteelHead to warm its SteelHead data store with the data patterns of new mail and attachments that arrive after a user shuts down Outlook. This is especially useful in global organizations where communication to a user continues long after local business hours. MAPI prepopulation reduces the bandwidth consumed by a branch office when users start their day, and it can accelerate the reception of mail when a user first connects to an Exchange server.

MAPI prepopulation does not use any additional Client Access Licenses (CALs) from the Exchange server. To start a MAPI prepopulation session, the SteelHead automatically holds open an existing authenticated MAPI connection after Outlook has shut down on the client. At the same time, the client-side SteelHead sends a message to the server-side SteelHead to prepare a MAPI prepopulation session. The session begins if the following conditions are met:

The remote SteelHead uses these preauthenticated connections to pull the data for mail from the Exchange server over the WAN link, automatically prepopulating the client-side SteelHead data store.

If a user starts a new Outlook session, the MAPI prepopulation session terminates. If for some reason the MAPI prepopulation session does not terminate (for example, the user starts a new session in a location that is different than the SteelHead that has the MAPI prepopulation session active), the MAPI prepopulation session will eventually time-out per the configuration setting.

The control of MAPI prepopulation is on the client-side SteelHead. This allows for a higher rate of prepopulated sessions, and it enables MAPI prepopulation to take advantage of the read-ahead mechanisms in the MAPI acceleration feature.

MAPI prepopulation v2 is supported. The client-side and server-side SteelHeads provide prepopulation v2 capabilities.

MAPI prepopulation v2 tracks the User ID as well as the client IP address. This is helpful in scenarios where the user returns to the branch office and is assigned a different IP address by DHCP. In MAPI prepopulation v1 (where just the IP address was tracked), the prepopulation session could have remained until the connection timed out (default 96 hours).

When accelerating 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 accelerated MAPI connection between the two SteelHeads is also encrypted, configure SteelHead secure inner channel. For details, see the SteelHead Deployment Guide.

Take these steps to configure SteelHead to accelerate encrypted MAPI traffic between the Outlook client and the Exchange server.

2. Join the server-side SteelHead to the same Windows domain that the Exchange server belongs to and operates as a member server. The server-side SteelHead must be able to ping the domain controller by name. You can use an adjacent domain through Cross-Domain support.

4. Enable the Encrypted Accelerate option on client-side and server-side SteelHeads involved in accelerating MAPI encrypted traffic. Alternatively, use the protocol mapi encrypted enable command.

5. Use transparent mode for all client types. Delegate mode is a legacy feature and should migrated to transparent mode, unless you have a specific need for Kerberos Constrained Delegation.

You can confirm that the SteelHead is successfully performing encrypted MAPI acceleration by going to the Management Console Current Connections report and looking for the highlighted lock icon listed in the Applications column of the report page.

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 User 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 acceleration.

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 the Exchange icon in the 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 accelerating new connections because it has exhausted a certain type of resource. During admission control, new connections pass through, while existing connections are accelerated. Upon exiting admission control, the SteelHead once again intercepts and accelerates new connections.

For more information about admission control, see the SteelHead Deployment Guide and the SteelHead User 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 accelerated, the SteelHead remaps contexts to prevent inadvertent mixing of accelerated and nonaccelerated 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 accelerate 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 accelerate only some of the connections, the session fails. If the connections are not accelerated by the same pair of SteelHeads, the session fails.

MAPI admission control v2 in SteelHead includes:

• MAPI admission control v1 was a client-side SteelHead implementation only. MAPI admission control v2 continues as a client-side SteelHead implementation, but it is also aware of the server-side SteelHead.

• MAPI admission control v2 preemptively closes MAPI sessions to reduce the connection count in an attempt to bring the SteelHead out of admission control. MAPI sessions are closed in the following order:

While the SteelHead is in the admission control state, a special handling of MAPI sessions is activated. Because new connections cannot be accelerated 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 acceleration expects all connections from an Outlook client to be accelerated by the same SteelHead and not split across two SteelHeads. However, the thresholds 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 accelerated on the same SteelHead.

In larger Microsoft Exchange deployments, the Exchange server can comprise 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:

You must restart the service for this command to take effect.

There is not a specific configuration required on the server-side SteelHead to support acceleration for Exchange clusters.

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, communication between the Outlook client and the Exchange server is sent over a secure connection known as S-Channel.

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

protocol mapi outlook-anywhr schannel enable

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

protocol ssl client-cer-auth enable

You can verify the Outlook connection status. It is important that you verify that the connection state is HTTP or HTTPS, and not TCP. To view the Outlook connection status, hold the Control key and click the Outlook icon in the task tray, and then select Connection Status. The Connection Status screen opens.

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

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. 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.

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

To use MAPI over HTTP, you must have SteelHead 9.1 or later on the client-side and server-side SteelHeads.

For SteelHead 9.7 and later, you do not need to explicitly set the latency acceleration policy to Exchange Autodetect for MAPI over HTTP traffic acceleration.

To accelerate MAPI over HTTP traffic for SteelHead versions prior to 9.7, you must change the default in-path rule to enable Exchange Autodetect, which is a latency acceleration policy. Exchange Autodetect automatically detects MAPI transport protocols (Autodiscover and MAPI over HTTP) and HTTP traffic. The Exchange Autodetect latency acceleration 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.

We recommend 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 acceleration.

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

Microsoft deprecated RPC over HTTP in Exchange Online deployments as of October 31, 2017, and this command is not supported in Exchange Online deployments as of that date. Details are at https://support.microsoft.com/en-us/help/3201590/rpc-over-http-deprecated-in-office-365-on-october-31,-2017. This change only affects customers using Outlook for Windows to connect to Exchange Online mailboxes in Office 365. Customers using RPC over HTTP to connect Outlook for Windows and on-premises Exchange Server continue to do so.

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 SteelHead to correctly track connections.

A typical MAPI connection has the following flow:

In high-security environments, hard code the Exchange server port if 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.

To disable the remapping capabilities of the MAPI software, connect to the CLI on the client-side SteelHead and enter the following commands:

no protocol mapi port-remap enable

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

MAPI enables 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 is prevalent with recent Exchange releases. SteelHead supports multiple context. We recommend that you enable this feature in an Exchange environment. Enabling this feature does not have any adverse effect on nonmultiple context traffic.