Forum Discussion

Nigel_01_136514's avatar
Nigel_01_136514
Icon for Nimbostratus rankNimbostratus
May 13, 2015

IApp does not match microsot recomendation

Our MS Exchange administrator has come to me with a problem with an issue relating to how the BigIP is handling ActiveSync connections. They are regularly seeing the following warnings:

 

The average of the most recent heartbeat intervals [540] for request [Ping] used by clients is less than or equal to [540]. Make sure that your firewall configuration is set to work correctly with Exchange ActiveSync and direct push technology. Specifically, make sure that your firewall is configured so that requests to Exchange ActiveSync do not expire before they have the opportunity to be processed.

 

He has pointed me to this article https://technet.microsoft.com/en-us/library/aa997252(v=exchg.141).aspx. It seems to say that firewalls (and possibly the BigIP) should have a time out of 30 minutes set.

 

We have used the iApp f5.microsoft_exchange_2010_2013_cas.v1.4.0 to configure the BigIP. (I've checked and there is now a 1.5.0 version but this appears to have the same issue). From what I can see when the iApps creates the TCP profiles for exchange is doesn't change the Idle Timeout values from 300 seconds (the default) to match the recommendations from Microsoft to 1800 seconds. If the option to enable RPC connectivity is selected then it appears that the Idle Timeout value is changed to 7200 seconds.

 

Can any one from Microsoft coment on why the iApp does not follow the recomendations from microsoft with regards tothe session time outs and if it is likely to be changed in future releases?

 

I have already tried asking this to the support TAC but as this is not a brake fix they are unable to assist (fair enough)

 

6 Replies

  • Forgot to mention we have already fixed the issue by manualy changing the time out settings this is more a question regarding the design of the iApp with a look to improving its deployment

     

    • laerm_151742's avatar
      laerm_151742
      Icon for Nimbostratus rankNimbostratus
      Hello Nigel, Have you noticed any fallout from these changes? We're hunting Apple Mail index corruption issues and wondering whether these timeout settings mights help alleviate these problems.
    • Nigel_01_136514's avatar
      Nigel_01_136514
      Icon for Nimbostratus rankNimbostratus
      Nothing reported back from the customer at the moment I am affraid although I am not sure they accomidate apple products in there environment at the moment.
  • mikeshimkus_111's avatar
    mikeshimkus_111
    Historic F5 Account

    Hi Nigel, thank you for bringing this to our attention. We'll investigate this issue and update the iApp and deployment guide accordingly.

     

    Mike

     

  • I've actually discussed this with MSFT on this explicit functionality (unofficial, we'll never admit it but I won the argument). We have to remember what ActiveSync was initially used for; short mobile delivery/submission bursts. Back then, 5 minutes (300 seconds) was the default recommendation for the work load expected of those clients. Even with push functionality introduced later, there was no logical reason a mobile device or any ActiveSync device kept anything open over 5 minutes; Blackberry was an exception with separate policies. ActiveSync was also a rather delicate service that still is susceptible to malicious use when CAS servers (in Exch2010) could drop at only a few thousand problematic connections (the calendar ActiveSync iOS issue comes to mind). So a 5 minute timer back then was a good idea.

     

    Fast forward, MSFT is reusing ActiveSync services as a smaller alternative to old school Mapi/RPC access for clients, but these usually don't conform to mobile functionality; this prompted the change to recommendations to require/request longer open session states. This is partly the reason why when you click RPC we bump the timer up (for single name space at least). 5 minutes is still ok for certain workloads, but so is 30 depending on what types of clients are connecting to ActiveSync.

     

    Given the error message by all means change strict mode and up the timer, remember the iApp is a template with the explicit idea that you may need to make customizations based off your need. In this case, we (F5) didn't update the iApp but mikeshumkus (the guy above) will fix to their current best practice needs. I know you already fixed the issue and Mike will update our guides, but I'd figure I give you the history our iApp and Exchange.

     

    I was asked by another DevCentral member at a recent conference how we setup these iApps... we do work with MSFT constantly, including F5'ers that sit over in Redmond to help certify and validate our products and often these are the little things that even they don't catch when we update our BP to match their BP.

     

    Just an FYI from the former F5 Exchange admin (and Exchange admin of 15+ years)...

     

  • Thank you very much for the clarification. Le gasp! microsoft blur the lines with there application... Ok they are not the only ones that do this pritty much every one does these days but it is nice to at least have decent heads up so where standard templates are developed to control traffic flow they can be modified to accomidate.

     

    Regards

     

    Nigel