Does this issue affect just OA or the other services (ie. EAS, OWA)?

Is there any way to test this with a client side setting without have to make the global change on the server?

We have encountered the very same issue with a Hosted Exchange service at Telus.com. What a pain :(

While monitoring internal office network for TCP/IP timeouts, we obserbe that while outlook is connected to exchange server (using RPC over https),  outlook opens and maintains five or so individual TCP/IP sessions on port 443 (https) and these connections do not time out whenever issue is encountered!.

Reading your blog message, you suggest when problem is encountered, it is because one or more of these TCP/IP sessions have timed out, but in reality they are up with consistent up-time. Furthermore, whenever problem is encountered, Outlook reports (in lower left corner) that it is "connected" to exchange server. I take it the connection is only half open, it can receive, but it cannot send.  while outlook is in that state, when a new email is composed and we press on TO: to perform a GLA look-up, outlook pauses and reports connection to exchange server is unavailable.

very much appreciate if you can offer further clarificaiton.

It's not a new topic and I always handled it with setting the KeepAliveTime to 270 seconds (which is a bit lower than the 300 second default setting in HLBs and most of *Nix-based network devices). I've been doing that since my very first Exchange 2010 implementation, several hundred of thousands of mailboxes later I still apply the same configuration with the same success. Never had to set MinimumConnectionTimeout.

Configuring the MinimumConnectionTimeout should basically have the same effect as the TCP KeepAliveTime, but I'm wondering which one works better, or if they are complementary. For sure, the TCP KeepAlliveTime applies to everything, while MinimumConnectionTimeout sounds to apply only to MSRPC-based connections.

>>

Value name: KeepAliveTime

Key: Tcpip\Parameters

Value Type: REG_DWORD-Time in milliseconds

Valid Range: 1-0xFFFFFFFF

Default: 7,200,000 (two hours)

This value controls how frequently TCP tries to verify that an idle connection is still intact by sending a keep-alive packet. If the remote computer is still reachable, it acknowledges the keep-alive packet. Keep-alive packets are not sent by default. You can use a program to configure this value on a connection. The recommended value setting is 300,000 (5 minutes).

<<

Great article, but i think somthing might be missing.

We needed to restart the server as iisreset didnt work.

This might be more related to the tcp stack than first sight.

I've seen this registry key in a Microsoft Exchange 2010 SP1 tip & tricks presentation.

The recommended value is 120 sec.

"The actual timeout used is the lower of this value and the IIS idle connection timeout" : unless i'm wrong, IIS default connection timeout is 120 sec.

So it's not clear for me. Is there a need to add this registry key because it permits to handle some timeout cases or it is useless?

Regards

Stéphane