The situation is further exaggerated as there will be a time period for Outlook and Exchange to realise the communication path is broken and move on to re-establishing a new connection. Outlook will eventually attempt to re-negotiate a new connection by making an RPC call to port 135. But guess what? There's a pretty good chance this session has also timed out in the firewall and has to go through re-negotiation as well. All this leads to an excessively long view of the "Requesting Data" dialog box, and a slow creep of the progress bar.

The intermittent nature of problem is connected with the frequency that these ports are accessed or more specifically, the impact on the intermediate firewall session. This problem is complicated by the profile of the Outlook user. Someone who is constantly sending and receiving emails and accessing address books will be sending regular information across these ports. In turn, they are also resetting the timeout values of the associated firewall sessions. Conversely, a more irregular user is more likely to leave Outlook open, but not exchange any information and is likely to exceed the thirty minute firewall session timeout.

There are background services within Outlook that will force exchange of information and potentially reset these sessions without user interaction, such as new mail notification. However, during analysis of my particular problem, the demand on the NSPI service was very much in line with user demands. In turn, this leads to what appears to be a lengthy, sporadic and inconsistent appearance of the "Requesting Data" dialog prompt.

A detailed observation of firewall sessions and traffic analysis typically showed frequent timeouts of the session handling the NSPI requests (49153 in this example). This was further reinforced by the reports of TCP retransmissions from the client and server. They all followed a pattern of being divisible by four. The reason for this is related to Microsoft's implementation of TCP/IP and the default configuration parameters.

So how do we deal with this?
I guess it's debatable where the real blame for the problem exists, but from my point of view, I feel that control of the communication process between the Exchange server and the Outlook client was designed on the basis of direct client and server connectivity.

Manipulating these applications to take the firewall session issues into consideration is not a viable option for existing releases and installations.

However, there is an alternative. What we need is to be able to force some element of data exchange between the client and the server on a regular basis, to ensure that infrequently used sessions are refreshed and maintained.

This can be achieved by implementing TCP keep-alive packets.

At this point, I would refer you to Microsoft's knowledge base article number 120642, which covers the configuration parameters in great detail. Many of these are irrelevant to our problem with the exception of the following entry: KeepAliveTime.