Microsoft Exchange Email Optimization
Microsoft Exchange Email Optimization
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 Client and Server Communication
•  RiOS MAPI Optimization
•  MAPI over HTTP
•  MAPI Destination Port Handling
•  MAPI Multiple Context
Note: The MAPI communication mechanism is also known by a more recent name: Microsoft as Outlook-Exchange Transport Protocol.
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.
MAPI Client and Server Communication
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:
1. The Outlook client contacts the directory service and DNS to establish the universal resource identifier (URI) for the Exchange server.
2. The Outlook client uses the URI to connect to the EPM server, and then it logs in to the Exchange server.
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.
4. Using Name Service Provider Interface (NSPI), the Outlook client resolves the name of a recipient.
5. The Outlook client submits the message to the Exchange server for sending.
Note: For information about Exchange server communication, go to
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.
Figure: Outlook Client and Exchange Server Synchronization
Source: (Sep. 2, 2010)
SteelHead MAPI optimization is based on the streamlining of ROPs.
Autodiscovery and MAPI Connections
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.
Note: 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 optimized.
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).
RiOS MAPI Optimization
The MAPI optimization module comprises several optimization techniques:
•  Read Ahead on attachments
•  Read Ahead on emails
•  Write Behind on attachments
•  Write Behind on emails
•  Folder Synchronization
•  Prepopulation
Note: : 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 optimizes MAPI traffic for several users, there are several optimized 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 optimized MAPI prepopulation connection per user.
The following are MAPI optimization methods on the SteelHead:
•  MAPI optimization - This method is the fundamental component of the MAPI optimization module and includes optimization 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.
•  Encrypted optimization - Enables the client-side SteelHead functionality required for encrypted MAPI optimization. For details, see Encrypted MAPI Optimization.
•  MAPI prepopulation - Allows a SteelHead to warm its RiOS 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 considerably reduces the bandwidth consumed by a branch office when users start their day, and it can greatly 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 server-side SteelHead has MAPI prepopulation enabled
–  The existing total client-side SteelHead active connections for MAPI prepopulation has not reached its maximum configured limit
–  A MAPI prepopulation session has not already been started for the client
No user credentials are used or saved by the SteelHead when performing prepopulation.
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 RiOS 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.
In RiOS 6.5 and later, 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 optimization feature.
MAPI prepopulation v2 is supported in RiOS 6.0.4 and later, 6.1.2 and later, and 6.5 and later. The client-side and server-side SteelHeads can be at any of these code train levels and provide prepopulation v2 capabilities. For example, a client-side SteelHead running RiOS 6.0.4 connecting to a server-side SteelHead running RiOS 6.5 or later provides prepopulation 2 capabilities. In contrast, a 6.0.1a client-side SteelHead connecting to a RiOS 6.5 or later server-side SteelHead supports prepopulation v1, but it does not provide prepopulation v2.
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).
Note: MAPI prepopulation does not occur when using MAPI Outlook Anywhere connection (RPC over HTTP). When a MAPI Outlook Anywhere session disconnects the SteelHead terminates all proxy flows.
Encrypted MAPI Optimization
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.
Figure: Encrypted Connections Between Client and Server
To enable the SteelHead to optimize encrypted MAPI traffic between the Outlook client and the Exchange server
1. On the server-side SteelHead, choose Optimization > Active Directory: Domain Join.
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) if the SteelHead is running RiOS 6.1 or later.
3. Verify that Outlook is encrypting traffic.
4. Enable the Encrypted Optimization option on client-side and server-side SteelHeads involved in optimizing 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.
6. Restart the service on all SteelHeads that have the Encrypted Optimization option enabled.
Note: The server-side and client-side SteelHeads must be running RiOS 5.5.x or later.
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.
Figure: Current Connections Report
If for some reason this is not successful, you see a red triangle in the Notes column.
Figure: Unsuccessful Current Connections Report
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.
Figure: Outlook Connection Status
MAPI Admission Control for Microsoft Outlook
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:
•  Server-side SteelHead awareness.
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:
–  MAPI prepopulation connections
–  MAPI sessions with the largest number of connections
–  MAPI sessions with the most idle connections
–  The oldest MAPI session
–  MAPI sessions exceeding the memory threshold
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 Optimization with SteelHeads in a Serial Cluster or a Parallel Deployment
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.
MAPI Optimization with Exchange Clusters
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:
•  Enable port transparency for MAPI traffic.
•  Enable full transparency for MAPI traffic.
•  Disable MAPI port remapping with the no protocol mapi port-remap enable command.
Note: You must restart the service for this command to take effect.
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 Optimization
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.
Note: The SteelHead must be properly licensed to use SSL. For details, see SSL Optimization Required Components.
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.
Tunnel Type
HTTP tunnel regular MAPI
Not encrypted
HTTPS tunnel regular MAPI
Encrypted once
HTTP tunnel encrypted MAPI
Encrypted once
HTTPS tunnel encrypted MAPI
Encrypted twice
The following list describes requirements for Outlook Anywhere:
•  RiOS 6.5 or later
•  Microsoft Outlook and Exchange Server 2003 or later
•  Encrypted MAPI requires the server-side SteelHead to join the windows domain of the Exchange server (for details, see Joining a SteelHead to a Domain)
•  HTTPS requires SSL licensing and an SSL certificate and key from the Outlook Anywhere server
Note: Outlook Anywhere optimized connections cannot start MAPI prepopulation.
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.
Figure: Virtual Connection
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.
Note: To disable fallback to TCP, enter an in-path rule on the client-side SteelHead to prevent EPM to the Outlook Anywhere server. An in-path rule to deny MAPI TCP is not normally used in most field deployments, as HTTP and HTTPS are the only protocols allowed through the firewall.
To block RPC to the Outlook Anywhere server
•  On the client-side SteelHead, connect to the CLI and enter the following command:
in-path rule deny rulenum [number] dstaddr [address] dstport 135 srcaddr description BlockRPC
To configure Outlook Anywhere
1. Configure Outlook Anywhere MAPI:
•  On the client-side and server-side SteelHead, choose Optimization > Protocols: MAPI.
•  Select Enable Outlook Anywhere optimization.
•  Select Auto-Detect Outlook Anywhere Connections.
•  Click Apply.
The corresponding CLI commands are [no] protocol mapi outlook-anywhr enable and [no] protocol mapi outlook-anywhr auto-detect.
Figure: Configuring Outlook Anywhere on the MAPI Page
2. Configure an in-path rule for HTTPS connections to enable SSL preoptimization only if the SteelHead has not had port 443 removed from the port label Secure. Normally port 443 is removed as part of the simple SSL configuration. For more details, see Setting Up a Simple SSL Optimization Deployment.
To configure an in-path rule for HTTPS connections:
•  Choose Optimization > Network Services: In-Path Rules.
•  Select Add a New In-Path Rule.
•  Select Auto Discover from the Type drop-down list.
•  Specify port 443.
•  Select SSL from the Preoptimization Policy drop-down list.
•  Click Add.
You can configure an in-path rule for HTTPS connections to enable SSL preoptimization through the CLI by entering in-path rule auto-discover preoptimization ssl dstport 443 rulenum end description SSLPreOptRule.
Figure: SSL In-Path Rule for Outlook Anywhere Optimization
3. Enable HTTP optimization the client-side and server-side SteelHead. For details, see HTTP Optimization.
4. Enable SSL on the client-side and server-side SteelHead. The certificate and key from the Outlook Anywhere server must be installed on the server-side SteelHead.
If you are using an internal CA, the CA root certificate must be installed.
If you are using encrypted MAPI, you must enable secure inner channel. For details, see Microsoft Exchange Email Optimization.
Note: When in-path rules are applied at the Management Console, or when you use the CLI, you must complete a save operation to save your changes permanently.
Support for Common Access Card
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:
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
Verifying Connection Status
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
1. Hold the Control key and click the Outlook icon in the task tray.
2. Select Connection Status.
The Connection Status screen opens.
Figure: Connection Status Screen
View the Reports > Networking: Current Connections page to identify if the active connections are standard MAPI (MAPI-OA) or encrypted MAPI (eMAPI-OA).
Figure: MAPI-OA Current Connections Page
Figure: eMAPI-OA
Troubleshooting Outlook Anywhere Optimized Traffic
The following list describes how to troubleshoot issues with Outlook Anywhere optimized traffic.
•  Change the Outlook Anywhere server to use HTTP rather than HTTPS
•  Disable encrypted MAPI on the Client Access server running Outlook Anywhere
Riverbed recommends that you disable SSL and MAPI encryption to facilitate troubleshooting and easily decipher packet captures.
To change the Outlook Anywhere server to use HTTP only
1. Change or create a registry key on the Outlook Anywhere server.
The key is located at HKLM\Software\Microsoft\Rpc\RpcProxy\AllowAnonymous. It is a DWORD value set to 0x1. Copy and paste the following into a.reg file for faster implementation.
Windows Registry Machine Editor Version 5.0
"Allow Anonymous"=dword:00000001
2. Restart the Outlook Anywhere server you modify the registry (by either manual or automated registry modification).
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.
To disable MAPI Encryption on Exchange 2010
1. To determine if MAPI Encryption is enabled, launch the Exchange server management shell by choosing Start > All Programs > Exchange Server 2010 > Exchange Management Shell.
2. Enter the following command:
Get-RpcClientAccess | fl
Figure: Exchange Management Shell Output shows an example output.
Figure: Exchange Management Shell Output
3. To determine if MAPI encryption is enabled, view the EncryptionRequired field. It has a value of True or False. A True value means that encryption is required and you must change it to False. If a False value is present, you can exit the shell.
4. Enter the following command to change the value to False:
set-RpcClientAccess -server mailbox -EncryptionRequired $False
5. Restart the Exchange server.
Microsoft Exchange 2013 Optimization
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: Client Traffic 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: Exchange Traffic on Port 80
Figure: Outlook Connection Status Window shows the Outlook Connection Status window.
Figure: 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:
•  MAPI over HTTP Requirements
•  MAPI over HTTP Down Negotiation
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:
•  optimize MAPI over HTTP with full-latency optimization.
•  down negotiate MAPI over HTTP to RPC over HTTP.
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.
MAPI over HTTP Requirements
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.
Figure: Changing the Default In-Path Rule
When you properly configure the in-path rule, the SteelHead Current Connections report looks similar to Figure: MAPI over HTTP Connections.
Figure: MAPI over HTTP Connections
MAPI over HTTP Down Negotiation
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:
•  The client-side SteelHead must be running RiOS 9.1 or later.
•  You must enable the Exchange Autodetect latency optimization policy.
•  You must enter the protocol eos moh down-negotiate enable command on the client-side SteelHead.
To see the status of the MAPI over HTTP engine, enter the show protocol eos command.
MAPI Destination Port Handling
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:
1. The client initiates a connection to the Exchange server on port 135. The EPM requests a dynamic port from the Exchange server.
2. The Exchange server responds with a dynamic port from which the client can connect to MAPI.
3. The client-side SteelHead intercepts the dynamic port response and moves it to port 7830. Port 7830 is the standard SteelHead MAPI port.
4. The client finishes initiating the MAPI connection with the client-side SteelHead.
5. The inner channel connection or optimized connection is established between the client-side SteelHead and server-side SteelHead.
6. The server-side SteelHead finishes the connection to the Exchange server on the dynamic port.
Figure: Flow of a Typical MAPI Connection
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.
To disable the remapping capabilities of the MAPI software
•  On the client-side SteelHead, connect to the CLI and enter the following commands:
no protocol mapi port-remap enable
write memory
service restart
After you disable remapping capabilities of the MAPI software, MAPI has the following flow:
1. The client sends the EPM request to the Exchange server.
2. The Exchange server responds with a static MAPI port.
3. The client-side SteelHead intercepts the response.
4. The client-side SteelHead issues the client the Exchange server address and the assigned static port.
5. The client-side SteelHead finishes setting up the client side connection
6. The inner channel between the client-side SteelHead and the server-side SteelHead is completed.
7. The server-side SteelHead completes the connection to the Exchange server on the assigned static port.
Figure: MAPI Flow with Static Ports
MAPI Multiple Context
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:
[rpch/mapi/csh/req.NOTICE] 1235184
{x.x.x.x:4149 x.x.x.x:4152} MSRPC Bind Request does not contain MAPI UUID, but f5cc5a18-4264-101a-8c59-08002b2f8426 (NSPI)
[rpch/csh.NOTICE] 1235176
{x.x.x.x:4152 x.x.x.x:443} detected Exchange 365, but peer SteelHead does not have multi-context support.
Note: You can identify multiple contexts in the header of the MAPI packet using a protocol decode tool, such as Wireshark.
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.
To enable MAPI multiple context support
•  On the SteelHead, connect to the CLI and enter the following command:
(config) protocol mapi multi-context enable
(config) protocol mapi encrypted multi-context auth enable
(config) protocol mapi outlook-anywhr multi-context enable
Note: You need multiple SteelHeads in deployments in which both Office 365 and On-Premises Exchange traffic need optimization.
For more information about Outlook Anywhere, see Outlook Anywhere Optimization.