Overview
Some MAPI users notice that their Outlook Traffic is not being classified as MAPI. If this traffic is not classified as MAPI chances are that if they are attempting to accelerate it, the MAPId service (specially designed to expedite MAPI flows) will not do its part either.
Root Cause
MAPI classification requires some special consideration. There is a communication between the client and the server on port TCP 135 before the real connection (Email Downloads for instance) starts.
There are four DCERPC/EPM packets between the MAPI Client and MAPI server on port 135:
- DCERPC - Bind
- DCERPC - Bind_Ack
- EPM Request
- EPM Response
The last of these (EPM Response) can be expanded in a packet sniffer and inside Tower-->Floor 5 and Floor 4 you can see an IP and a Port Number. This means that right after this message, the client will initiate a TCP conversation to the IP and on the port number pointed by the EPM Response packet, see example below:
Only after this, the real MAPI conversation will begin. To classify that conversation as MAPI, the server and the TCP port must be the one pointed by the EPM Response packet see above.
Sometimes, this is caused because of some load balancing or clustering configuration going on for the server, so the IP that the client access is a virtual IP while the one pointed by the EMP Response packet is the real one.
Resolution
To see if this is the actual problem:
- Close all instances of Outlook or any MAPI client you are running on your PC.
- Start a packet capture in the Exinda by going to System > Diagnostics > TCPdump and filtering the IP of the MAPI client with the command:
host <ip of the client>
- While the tcpdumps are running, open the MAPI client (Outlook) and start downloading some emails.
- Let the packet capture finish and through the use of a packet sniffer, filter the packets within port TCP 135.
- Analyze the EPM Response packet and look for the Server IP and TCP Port within the floors 5 and 4 as per the explanation above.
- Look for any tcp_syn packet initiated from the MAPI client right after the EPM response. If the IP or port destination for this traffic is not exactly what the EPM Response says then that is the problem.
The Network Administrator will be required to modify the MAPI settings, so the above issue does not occur.