MAPI latency optimization works in the following ways:
Attachment read-ahead and write-behind.
MAPI pre-population for attachment warming.
MAPI latency optimization does not work if:
MAPI traffic is encrypted and the Active Directory integration has not been setup or is temporary suspended.
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