SteelHead™ Deployment Guide - Protocols : Microsoft Exchange Email Optimization : RiOS MAPI 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
  • : 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 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 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 v6.5 and later, the control of MAPI prepopulation is on the client-side SteelHead. This allows for a higher rate of prepopulated sessions, and enables MAPI prepopulation to take advantage of the read-ahead mechanisms in the MAPI optimization feature.
    MAPI prepopulation v2 is supported in RiOS v6.0.4 and later, v6.1.2 and later, and v6.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 v6.0.4 connecting to a server-side SteelHead running RiOS v6.5 or later provides prepopulation v2 capabilities. In contrast, a 6.0.1a client-side SteelHead connecting to a RiOS v6.5 or later server-side SteelHead supports prepopulation v1, but 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).
    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 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 2‑2. Encrypted Connections Between Client and Server
    To enable the SteelHead to optimize encrypted MAPI traffic between Outlook and the Exchange Server:
    On the server-side SteelHead, choose Optimization > Active Directory: Domain Join.
    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 v6.1 or later.
    Verify that Outlook is encrypting traffic.
    Enable the Encrypted Optimization option on client-side and server-side SteelHeads involved in optimizing MAPI encrypted traffic. Alternatively, use the CLI command protocol mapi encrypted enable.
    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.
    Restart the service on all SteelHeads that have the Encrypted Optimization option enabled.
    The server-side and client-side SteelHeads must be running RiOS v5.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 8v.6, this is listed as ENCRYPT-MAPI.
    Figure 2‑3. Current Connections Report
    If for some reason this is not successful, you see a red triangle in the Notes column
    Figure 2‑4. 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 v8.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 2‑5. 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 v7.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 v7.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 v7.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 forwards 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 between 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 CLI command no protocol mapi port-remap enable.
  • You must restart the service for this command to take effect.
    CAS requires RiOS v6.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 v6.1.4 or v6.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 v6.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.
    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 v6.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
  • Outlook Anywhere optimized connections cannot start MAPI prepopulation.
    The communication flow of Outlook Anywhere is between an Outlook client, the Outlook Anywhere server, and an Exchange server. The Outlook Anywhere server is a 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 2‑6 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 it to the Outlook client. The Outlook client then strips the HTTP from the session and reads the traffic as RPC and MAPI.
    Figure 2‑6. 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.
    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
    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 2‑7. Configuring Outlook Anywhere On The MAPI Page
    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 2‑8. SSL In-Path Rule for Outlook Anywhere Optimization
    Enable HTTP optimization the client-side and server-side SteelHead. For details, see HTTP Optimization.
    Enable SSL 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.
    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 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 appliance 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
    Hold the Control key and click the Outlook icon in the task tray.
    Select Connection Status.
    The Connection Status screen opens.
    Figure 2‑9. Connection Status Screen
    View the Reports > Networking: Current Connections page to identify if the active connections are standard MAPI (MAPI-OA), or if they are encrypted MAPI (eMAPI-OA).
    Figure 2‑10. MAPI-OA Current Connections Page
    Figure 2‑11. 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
    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
    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
    To determine if MAPI Encryption is enabled, launch the Exchange server management shell by choosing Start > All Programs > Exchange Server 2010 > Exchange Management Shell.
    Enter the following command:
    Get-RpcClientAccess | fl
    Figure 2‑12 shows an example output.
    Figure 2‑12. Exchange Management Shell Output
    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.
    Enter the following command to change the value to False:
    set-RpcClientAccess -server mailbox -EncryptionRequired $False
    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 2‑13 shows an example of client traffic from Exchange 2013 and Outlook 2013 using Wireshark.
    Figure 2‑13. Client Traffic Using Wireshark
    Figure 2‑14 shows that the Exchange traffic is traversing HTTP TCP port 80 using a netstat -n output from the client running Outlook 2013.
    Figure 2‑14. Exchange Traffic on Port 80
    Figure 2‑15 shows the Outlook Connection Status window.
    Figure 2‑15. 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.