MAPI Accelerator

The MAPI accelerator optimizes Microsoft Outlook Exchange e-mail traffic. Exchange uses the EMSMDB protocol, which is layered on MS-RPC, which in turn uses either TCP or HTTP (unsupported) as the low level transport.

The MAPI AO supports Microsoft Outlook 2000 through 2007 clients for both cached and noncached mode traffic. Secure connections that use message authentication (signing) or encryption are not accelerated by the MAPI AO. Such connections and connections from older clients are handed off to the generic AO for TFO optimizations. Additionally, Outlook Web Access (OWA) and Exchange-Exchange connections are not supported.

Note: Microsoft Outlook 2007 has encryption enabled by default. You must disable encryption to benefit from the MAPI application accelerator. In Outlook, choose Tools > E-mail Accounts, choose View or Change Existing E-mail Accounts, and then click Next. Choose the Exchange account, and then click Change. Click More Settings, and then click the Security tab. Uncheck the Encrypt data between Microsoft Office Outlook and Microsoft Exchange Server check box, as shown in Figure 1.

Alternatively, you can disable encryption for all users of an Exchange Server by using a Group Policy.

Figure 1. Disabling Encryption in Outlook 2007

In the following cases, the MAPI AO does not handle a connection:

Encrypted connection (handed off to the generic AO)

Unsupported client (handed off to the generic AO)

Unrecoverable parsing error. All TCP connections between the client and server service are disconnected. When the client reconnects, all connections are handed off to the generic AO.

Client attempts to establish a new association group on the connection when the WAE is overloaded.

Client establishes a connection when the WAE is overloaded and MAPI reserved connection resources are not available.

The Outlook client and server interact in a session over a group of TCP connections called an association group. Within an association group, object accesses can span across any connection and connections are dynamically created and released as needed. A client can have more than one association group open at the same time to different servers or the same server. (Public folders are deployed on different servers from the mail store.)

It is essential that all MAPI connections within an association group go through the same pair of WAEs in the branch and data center. If some connections within an association group do not go through the MAPI AO on these WAEs, the MAPI AO would not see the transactions performed on those connections and the connections are said to "escape" the association group. For this reason, the MAPI AO should not be deployed on serially clustered inline WAEs that form a high availability group.

The symptoms of MAPI connections that escape their WAE association group are Outlook error symptoms such as duplicate messages or Outlook stops responding.

During a TFO overload condition, new connections for an existing association group would be passed through and escape the MAPI AO, so the MAPI AO reserves a number of connection resources in advance to minimize the impact of an overload condition. For more details about reserved MAPI connections and their impact on device overload, see the section "MAPI Application Accelerator Reserved Connections Impact on Overload" in the Troubleshooting Overload Conditions article.

Verify the general AO configuration and status with the show accelerator and show license commands, as described in the Troubleshooting Application Acceleration article. The Enterprise license is required for MAPI accelerator operation and the EPM application accelerator must be enabled.

Next, verify the status specific to the MAPI AO by using the show accelerator mapi command, as shown in Figure 2. You want to see that the MAPI AO is Enabled, Running, and Registered, and that the connection limit is displayed. If the Config State is Enabled but the Operational State is Shutdown, it indicates a licensing problem.

Figure 2. Verifying the MAPI Accelerator Status

Use the show statistics accelerator epm command to verify that the EPM AO is functional. Check that the Total Handled Connections, Total Requests Successfully Parsed, and Total Responses Successfully Parsed counters increase when a client is started.

Use the show running-config command to verify that the MAPI and EPM traffic policies are properly configured. You want to see accelerate mapi for the Email-and-Messaging application action and you want to see the MS-EndPortMapper classifier and traffic policy defined, as follows:

Use the show policy-engine application dynamic command to verify that dynamic match rules exist, as follows:

Look for a rule with User ID: EPM and Map Name: uuida4f1db00-ca47-1067-b31f-00dd010662da.

The Flows field indicates the total number of active connections to the Exchange service.

For each MAPI client you should see a separate entry with the User ID: MAPI.

Use the show statistics connection optimized mapi command to check that the WAAS device is establishing optimized MAPI connections. Verify that "M" appears in the Accel column for MAPI connections, which indicates that the MAPI AO was used, as follows:

Note: In version 4.1.5, the Current Reserved Flows counter was added in the output. This counter refers to the number of reserved MAPI connection resources on the WAE that are currently unused but set aside for future MAPI connections. For more details about reserved MAPI connections and their impact on device overload, see the section "MAPI Application Accelerator Reserved Connections Impact on Overload" in the Troubleshooting Overload Conditions article.

If you observe connections with "TGDL" in the Accel column, these connections were pushed down to the generic AO and optimized with transport optimizations only. If these are connections that you expected to be handled by the MAPI AO, it may be because they are encrypted MAPI connections. To check on the number of encrypted MAPI connections that have been requested, use the show statistics accelerator mapi command as follows:

Encrypted MAPI Acceleration

Summary

As of WAAS 5.0.1 the MAPI accelerator can now accelerate encrypted MAPI traffic. This feature will be enabled by default in the 5.0.3 release. However, in order successfully accelerate encrypted MAPI traffic there are number of requirements in both the WAAS and Microsoft AD environment. This guide will help you verify and troubleshoot eMAPI functionality.

Feature Information

eMAPI will be enabled by default in 5.0.3 and will require the following to successfully accelerate encrypted traffic.

1) CMS secure store must be initialized and open on all Core WAEs

2) The WAEs must be able to resolve the FQDN of the Exchange server(s) and Kerberos KDC (Active Directory Controller)

3) The WAE's clocks must be in sync with the KDC

4) SSL acclerator, WAN Secure, and eMAPI must be enabled on all WAEs in the path from Outlook to Exchange

5) The WAEs in the path must have the correct policy-map configuration

6) The Core WAE(s) must have one or more Encrypted Services Domain Identies configured (User or Machine account)

7) If a machine account is used this WAE must be joined to the AD domain.

8) Then with either the Machine or User account use case, those objects in Active directory need to be given specific permissions. "Replicating Directory Changes" and "Replicating Directory Changes All" must both be set to allow.

The recommended way to do this is via a Universal Security group (e.g. assign the permissions to the group and then add the WAAS devices and/or usernames specified in the Encryption service to this group). See the attached guide for screenshots of AD configuration and WAAS CM GUI.

Troubleshooting Methodology

While the diagnostics command (step 2 below) verifies the existence of an Encryption service it does not verify whether key retrieval will be successful. Hence we do not know by just running that diagnostic command if the proper permissions were given to the object in Active Directory (either Machine or User account).

Summary of what needs to be done to configure and verify Encryption service will succeed key retrieval

User account :

1. create AD user

2. create AD group and set "Replicating Directory Changes" and "Replicating Directory Changes All" to ALLOW

Step 3- Manually verify the WAE settings that are not checked by the diagnostic command above.

1) The above command while it chekcs for the existence of NTP configured, it does not actually verify the times are in sync between the WAE and KDC. It is very important the times are in sync between the Core and KDC for key retrieval to be successful.

If the manual check reveals they are out of sync a simple way to force the clock of the WAE to be in sync would be the ntpdate command (ntpdate <KDC ip>). Then point the WAEs to the enterprise NTP server.

2) Verify dnslookup succeeds on all WAEs for the Exchange servers' FQDN and the KDCs' FQDN

3) Verify the class-map and policy-map is configured correctly on all WAEs in the path.

Resolution 3: If your Core WAE services multiple Exchange servers in different domains you must configure an Encryption service Identity for each domain the Exchange servers reside in.

Note, there is NO support for sub-domain include at this time. So if you have myexchange.sub-domain.domain.com , the Encryption service Identity must be in sub-domain.domain.com; it CAN NOT be in the parent domain.

Problem: If WANSecure fails your connections can drop to TG

eMAPI connections can be handed over to Generic AO because WAN secure plumb failed. WAN Secure plumb failed because cert verify failed. Peer cert verify will failed because the default self-signed peer cert is being used or the cert has legitimately failed OCSP check.

Resolution: The customer must enable / require Kerberos authentication in their Exchange environment. NTLM is NOT supported (as of 5.1)

Be aware there is a Microsoft tech brief that calls out a fall back to NTLM when a CAS is used.

The scenario where Kerberos does not function is specific to Exchange 2010, and is in the following scenario:

Multiple Exchange Client Access Servers (CAS) in an organization/domain.These CAS servers are clustered together using any method - using Microsoft's built-in Client-array function, or a 3rd party load balancer.

In the scenario above, Kerberos does not work - and clients will fall-back to NTLM by defult. I believe this is due to the fact that clients have to AUTH to the CAS server vs. the Mailbox server, as they did in previous Exchange releases.

In Exchange 2010 RTM, there is no fix for this! Kerberos in the above scenario will never function pre-Exchange 2010-SP1.

To set up and enable debug logging of the MAPI AO, use the following commands.NOTE: Debug logging is CPU intensive and can generate a large amount of output. Use it judiciously and sparingly in a production environment.You can enable detailed logging to the disk as follows: