Forum Discussion

Russell_77729's avatar
Russell_77729
Icon for Nimbostratus rankNimbostratus
Oct 01, 2014
Solved

Persistence 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.

     

4 Replies

  • mikeshimkus_111's avatar
    mikeshimkus_111
    Historic F5 Account

    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

     

  • Yes, 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
    

    }

  • mikeshimkus_111's avatar
    mikeshimkus_111
    Historic F5 Account

    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.

     

  • Ok, I let it limp along for a few days and get the official release and rebuild it. Thanks for the help.