When publishing Exchange 2010 “Outlook Anywhere” via TMG 2010, you may find that some of your external Outlook users may intermittently experience issues sending email. They may report, when sending a new email, that the email may get “stuck” in the Outbox folder. The users may find that the email will be sent after a random number of minutes…or not at all. Forcing a Send and Receive does not help. However, they may find that if they close and restart the Outlook client, the items are then sent.
The difficulty in troubleshooting this problem is that none of the endpoints in question will log any relative error messages. Neither the Outlook client, TMG nor the Exchange CAS server log any events or errors that appear relative to the issue.
This turns out to be a timing issue which can result in ‘orphaned’ TCP connections. The Outlook client has a default RPC timeout of 12 minutes. The server to client default RPC timeout is 15 minutes.
In a publishing scenario that allows access from external clients, it’s not unusual to have a number of different network devices between the Outlook client and the internal Exchange CAS servers. If the TCP connection timeout of one or more of these devices is sufficiently low enough, the TCP connection may be dropped by the device, causing the RPC connections between the Outlook client and the Exchange CAS server to drop. In our scenario, the device we’re interested in is TMG.
A TMG SP2 server has a default TCP keepalive value of 5 minutes. Therefore, it’s possible that TMG may drop the RPC connection from an ‘idle’ Outlook Anywhere client.
The registry value that controls the Exchanges RPC Proxy connection timeout is:
The TMG servers’ registry value that controls TCP/IP keepalive time is:
NOTE: The value of MinimumConnectionTimeout is specified in seconds and the value of KeepAliveTime is specified in milliseconds.
Decrease the Exchange CAS servers’ RPC Proxy timeout to be less than the TMG servers’ TCP keepalive time. As the default TCP keepalive value on TMG is 5 minutes, you can configure the CAS servers’ RPC Proxy timeout to 3 minutes (180 seconds) as follows:
HKLM\Software\Policies\Microsoft\Windows NT\Rpc\MinimumConnectionTimeout DWORD 0x000000b4 (180)
NOTE: The MinimumConnectionTimeout registry value does not exist by default. You’ll need to create it if it doesn’t exist in this location. Also note that adding and/or editing this registry value will require a reboot of the Exchange CAS server.
Don’t forget to check other devices on the network and make sure they do not have TCP timeout settings that might be lower than your newly configured RPC Proxy MinimumConnectionTimeout values.
Sr. Security Support Escalation Engineer
Microsoft CSS Forefront Edge Team
Thank you very much for the info. We have F5 hardware load balancer to set idle connection timeout for 15 minutes, on our Exchange 2010 SP2 CAS servers we set both Windows TCP Keepalive to 120000 (ms) and and RPC connectiontimeout 120 (s) (2minutes). Outlook clients (inside via Mapi) and Outside (Outlook anywhere) still get Event ID 26 every 5 minutes Event ID: 26 "Connection to the Microsoft Exchange Server has been lost. Outlook will restore the connection when possible." following instantly within less than a millisecond with another Event ID: 26 :Connection to the Microsoft Exchange Server has been restored."
BTW, F5 was setup idle connection 5 minutes before, Outlook client got Event ID 26 every 5 minutes. Then we changed F5 idle connection 15 minutes, Outlook client got Event ID 26 every 15 minutes. After reading your post and other post about these register key, we change both above register key to 2 minutes, now Outlook client got Event ID 26 every 5 minutes ago. This doesn't make sense at all.
Any idea? Thanks.
BTW, F5 was setup idle connection 5 minutes before, Outlook client got Event ID 26 every 5 minutes. Then we changed F5 idle connection 30 minutes, Outlook client got Event ID 26 every 15 minutes. After reading your post and other post about these register key, we change both above register key to 2 minutes, now Outlook client got Event ID 26 every 5 minutes ago. This doesn't make sense at all. Thanks again.