Forum Discussion
Russell_77729
Nimbostratus
NimbostratusPersistence Profile for ActiveSync and AirWatch
Sorry if this sounds like a dumb question but I am still learning how to tame the beast that is LTM. I am using LTM to load balance ActiveSync coming in from an AirWatch server in the DMZ. the iApp uses source address for persistence but they all come from the same address and it is bringing one of my Exchange CAS servers to it's knees. Any have any recommendations for persistence in this setup? I tried cookie hash persistence but that stopped ActiveSync traffic and caused the monitor to mark both my CAS servers as down.
That's a very old version of the iApp. The problem is that the default source IP persistence is overriding the command to persist on the basic auth header in the iRule.
You could disable strictness and remove the source IP persistence from the VIP, but I recommend upgrading your deployment using the new v1.4.0 template since it has many other fixes. You can get an RC version here: https://devcentral.f5.com/wiki/iApp.Microsoft-Exchange-2010-and-2013-iApp-Template.ashx
Or you can wait until October 6th, when we'll be officially releasing v1.4.0 to downloads.f5.com. If you do decide to go with the RC, you'll still want to get the official version once it's out.
Hi Russell, I assume you are using Exchange 2010 since 2013 doesn't require persistence. Which version of the iApp are you using? It should default to persisting on the basic auth header for ActiveSync, but older versions of the iApp had an issue with connection clumping if you deployed with a fallback persistence profile of source IP (if you deployed RPC MAPI clients at the same time, for example). Can you post the tmsh configuration of your ActiveSync VIP here?
thanks
Russell_77729Yes, 2010, ActiveSynce was deployed using f5.microsoft_exchange_2010_cas.2012_06_08.
ltm virtual aa_exch2010_activesync_as_https { app-service /Common/aa_exch2010_activesync.app/aa_exch2010_activesync destination /Common/xx.xx.xx.xx:https ip-protocol tcp mask 255.255.255.255 persist { aa_exch2010_activesync_source_address_persistence_profile { default yes } } pool aa_exch2010_activesync_as_pool profiles { /Common/ntlm { } aa_exch2010_activesync_caching_profile { } aa_exch2010_activesync_clientssl { context clientside } aa_exch2010_activesync_http_profile { } aa_exch2010_activesync_lan-optimized_tcp_profile { context serverside } aa_exch2010_activesync_oneconnect { } aa_exch2010_activesync_serverssl { context serverside } aa_exch2010_activesync_wan-optimized-compression_profile { } aa_exch2010_activesync_wan-optimized_tcp_profile { context clientside } } vlans-disabled}
That's a very old version of the iApp. The problem is that the default source IP persistence is overriding the command to persist on the basic auth header in the iRule.
You could disable strictness and remove the source IP persistence from the VIP, but I recommend upgrading your deployment using the new v1.4.0 template since it has many other fixes. You can get an RC version here: https://devcentral.f5.com/wiki/iApp.Microsoft-Exchange-2010-and-2013-iApp-Template.ashx
Or you can wait until October 6th, when we'll be officially releasing v1.4.0 to downloads.f5.com. If you do decide to go with the RC, you'll still want to get the official version once it's out.
- Russell_77729
Ok, I let it limp along for a few days and get the official release and rebuild it. Thanks for the help.