Forum Discussion
blwavg_10621
Nimbostratus
NimbostratusAPM Active Session Reduction
Migrated an exchange environment to the F5. The number of APM fronted connections was massive. We quickly ran out of concurrent sessions. We have since implemented a reduction measures such as inactivity timeout, Access Policy Timeout, Max Session Length. Are there other tricks to lowering the APM session count? I see there are other options on the APM page. I am more worried about implementing those. Although it looks like every time a person does a manual active sync connection that it creates a new session on the F5. Can we reuse session or kill sessions that now longer need to be opened because they are just push or pull request? I see some users with 15+ sessions (average is maybe 1-5 per user).
Notes: - We are on 11.4 code - OWA and Active Sync are on the same VS and so the same access policy applies to both
It sounds like you have implemented all the right checks - setting the proper timeouts is key here.
Regarding creating new session each time a user does manual activeSync - that should not be happening - if it really does, it would help to get a case open with F5 support and supply all the relevant data(debug logs from the APM as well as ssldump of the traffic that shows two separate manual activeSync connections). Also, it would help us to know which platforms/devices do you experience ActiveSync issues on, and what exactly do you classify as "manual" ActiveSync?
Michael_KoyfmanCirrocumulus
It sounds like you have implemented all the right checks - setting the proper timeouts is key here.
Regarding creating new session each time a user does manual activeSync - that should not be happening - if it really does, it would help to get a case open with F5 support and supply all the relevant data(debug logs from the APM as well as ssldump of the traffic that shows two separate manual activeSync connections). Also, it would help us to know which platforms/devices do you experience ActiveSync issues on, and what exactly do you classify as "manual" ActiveSync?
- blwavg_10621I was under the impression that every manual refresh was creating a new session. I have been testing this for a while and this does not appear to be the case. I do not know why though I have seen users with up to 20 sessions in a relatively short time frame. I guess I will have to look into those on a case by case basis.
- Michael_KoyfmanGlad to see that it does not appear to be the case - I've never seen this to be the case. You could have some users that have a ton of unique devices accessing Exchange.... pulling a report on those user ids and analyzing their UserAgent strings would help to find out what is really going on.
Michael_Koyfma1Cirrus
It sounds like you have implemented all the right checks - setting the proper timeouts is key here.
Regarding creating new session each time a user does manual activeSync - that should not be happening - if it really does, it would help to get a case open with F5 support and supply all the relevant data(debug logs from the APM as well as ssldump of the traffic that shows two separate manual activeSync connections). Also, it would help us to know which platforms/devices do you experience ActiveSync issues on, and what exactly do you classify as "manual" ActiveSync?
- blwavg_10621I was under the impression that every manual refresh was creating a new session. I have been testing this for a while and this does not appear to be the case. I do not know why though I have seen users with up to 20 sessions in a relatively short time frame. I guess I will have to look into those on a case by case basis.
- Michael_Koyfma1Glad to see that it does not appear to be the case - I've never seen this to be the case. You could have some users that have a ton of unique devices accessing Exchange.... pulling a report on those user ids and analyzing their UserAgent strings would help to find out what is really going on.
- blwavg_10621
It is also good to note APM concurrent user limitations when sizing. http://www.f5.com/pdf/products/big-ip-access-policy-manager-ds.pdf
Review Page 12