The firewall factor
During the initial negotiation between Outlook and Exchange, information is exchanged to establish these communication channels. However, if the server and client are isolated by a firewall, an additional important process also takes place.

Many modern firewalls perform "stateful inspection". Essentially, they breakdown the communication between the two parties and ensure that defined and legal parameters are adhered to. This covers many elements, for example, validating the protocol that is being exchanged (RPC, HTTP, FTP, etc), the ports that are being accessed, correct TCP/IP sequencing and the list goes on.

To accomplish this, the firewall establishes session-based information. Separate similar session information also exists within the server and clients for its NetBIOS connection table. We now have extended the scenario where the client is communicating with the firewall and the firewall is communicating with the server.

It is important to check how your particular firewall manufacturer handles sessions. In a normal communication process, these are established when all the rules for a particular event are met (stateful inspection) and released when this communication process is ended, for instance when a TCP FIN (Final) packet is sent and received. However, there will be unplanned situations where this graceful removal of sessions is not carried out, such as removing a device from the network or a system crash, for example.

During these events, the sessions will continue their existence within the firewall as they have no way of knowing the device or system is no longer around. If this situation occurred on a regular basis, we would end up with a cumulative growth of sessions and, at some stage, run out of capacity. To prevent this, firewall manufacturers incorporate a housekeeping process to remove inactive sessions forcefully, by applying a timeout period.

This is usually a configurable parameter and needs to be planned quite carefully. Too short, and applications that communicate infrequently will be interrupted, too long and the risk of session build-up increases. In my experience, thirty minutes seem to be the normal assumption. Any valid, acceptable, communication across a session between the two parties will reset this housekeeping timer back to zero, and the counter starts again.

So how does this relate to our problem?
If you recall, when the Outlook client establishes itself with the Exchange server (in our scenario), we end up with three sessions in the firewall handling the services required (ports 135, 49152 and 49153). Each session will be available for up to a maximum of thirty minutes. However, if nothing is transferred, the firewall session will timeout and effectively break the communication between the client and the server.

Furthermore, the session is unlikely to re-establish itself as these are stateful firewalls, and the services that are attempting to continue to communicate are unlikely to match the rules for session establishment (in reality, you will just see TCP ACKs requests being transferred which have no session to belong to).