Microsoft.Exchange.AddressBook.Service.exe- timeouts and disconnects

Thx for the reply - our network engineer 'synced' the time out value last night for rpc persistence profile and TCP profile currently at 4 hours - things appear to be better today but I am seeking empirical evidence from the field. We will ratchet that time down towards 2 hours or less if things are improved. A question on the TCP profile - can that be set on a port basis (60001 and 60001) and keep the defaults for the other services (ssh, http, etc) or is this profile setting global.

I've tried various changes to the TCP and persistence timeouts, but haven't been able to replicate your issue. You could set different timeouts for the AB and RPC virtual servers, but you would need to create separate TCP profiles for each since the iApp only creates one profile (or two if your clients are on a WAN) and applies it to all 3 RPC virtual servers. This requires disabling strictness on the iApp, which we don't recommend. If you end up opening a support case with F5, please post the number here and I will have a look at your config. BTW, the default timeout set by the iApp is 2 hours, not 20 minutes.

Mike - thanks for the responses and sorry for the delayed response - never enough time/staff especially at the beginning of a higher ed semester - so the resolution involved: upgrading iApp, changing persistence values (syncing), removing SNAT (so we could actually capture individual sessions that were experiencing the issue on both interfaces of the F5, the client, and the CAS server) Once things calm down we will open a new case since part of our resolution (to follow) required disabling strictness: From our Network Engineer (9/3): "there have been a number of problems related to the Citrix to F5 move for Exchange. Some issues were resolved by upgrading to the latest iApp a few weeks ago. Some other issues were resolved by increasing the persistence and idle-connection timer on the respective profiles and keeping them in-sync with one another (4 hours). However, there is some configuration mystery on the F5. When you go to change the idle-connection timer, either (1) it does not really get changed, or (2) there is some other timer that uses TCP Keepalive misses as the actual trigger for killing off idle sessions. On the wire, it appears that the F5 will send a TCP Keepalive once every 30 minutes for these types of services, both to the client as well as the server. If a Keepalive test does not receive a response after 3 iterations (2 hours), the F5 will timeout the connection and send TCP RSTs to both the client and server. Since the Address Book application is NOT chatty, it is clearly evident that a user will experience a timeout under such conditions when the client is not routinely used. The problem is that the Juniper SRX has a default idle TCP connection timer of 30 minutes as well. Packet traces indicate that the SRX would time out the TCP connection first, thereby preventing the TCP Keeaplive from the F5 from reaching the client. This set in motion the basic problem. Increasing the SRX idle connection timer to 2 hours eliminates this problem for SecureNet users, which appears to be the last set of users that were having repetitive problems with the Exchange Address Book. Further discussion with F5 is needed to figure out if this timer mechanism is either a different animal from the "idle" timeout configuration parameter in the configuration, or if the "idle" timeout config parameter is being somehow ignored or overwritten by something else." Thanks again - as always tcpdump saves the day and networks with many network devices always need all of the devices considered as a source/part of an issue - the perfect storm? .... J