8.6. MAPI Latency Optimization

MAPI latency optimization works in the following ways:

MAPI latency optimization does not work if:

8.6.1. Setup of an optimized MAPI session

The Outlook client sets up a TCP session on port 135 to the Exchange servers port mapper to find out on which TCP port the Exchange service is running. The client-side Steelhead appliance shows this session as EPM, Exchange Port Mapper. The server-side Steelhead appliance will receive the answer from the EPM service, rewrite the TCP port to port 7830 and forwards the answer to the client-side Steelhead appliance. Then the client-side Steelhead appliance will tell the Outlook client to use port 7830 and sets up a hidden in-path rule which states that all traffic towards the Exchange server on TCP port 7830 has to go to the current server-side Steelhead appliance.

The Outlook client will setup three TCP sessions to the Exchange service on port 7830, they are intercepted by the client-side Steelhead appliance and forwarded to the configured server-side Steelhead appliance. There they are forwarded to the Exchange server on the TCP port received in the answer from the Exchange Port Mapper.

By default three TCP sessions are setup, one will be added for every shared calendar.

The hidden in-path rule is for all new TCP sessions towards the Exchange server and is parsed before the normal in-path rules. To disable this in-path rule, use the CLI command in-path probe-mapi-data command. Use the command show in-path probe-mapi-data to see the current setting of this feature.

Figure 8.29. See the MAPI probing option

CSH (config) # in-path probe-mapi-data 
You must restart the optimization service for your changes to take effect.
CSH (config) # show in-path probe-mapi-data
Probe MAPI connections to learn VLAN info: yes