Not that the total traffic amounts to a hill of beans but if I do tweak the following setting then it looks like it would just accumulate marginally longer. Say that I change the value to 10 or so from the default of 3.
We’re just trying to cut down communication to the relays marginally without altering the real time component.
_BESRelay_PostResults_ResultTimeLimit
The BES Relay accumulates reports from the BES Clients and then compresses them and sends them to the parent BES Relay or BES Server after waiting a specified amount of time. This setting sets the amount of time to wait before sending the reports. The longer the wait, the more latency before the BES Server receives the reports from the BES Clients, but the greater the efficiency of the system (lower network traffic).
We don’t typically use this setting much, except maybe on relays with low bandwidth and not very many clients. You can give it a try, but I’m not sure you’ll get the results your looking for. You will want to be very careful that the change does not cause the relay buffer directory to fill up at times when the relay is receiving lots of reports from its clients.
You might consider raising the client minimum report interval instead (_BESClient_Report_MinimumInterval). We do this more commonly for large deployments.
The default is 15 seconds, you might try changing it to 30, 45, or 60.
Note that this means you might miss some of the intermediary action status reports, such as evaluating, running, etc.
There are many other ways in BES to tweak network utilization and there may be a better solution. For example, if you have properties where the value changes frequently (e.g. it includes a time stamp), this will cause the client to send up more reports. You could locate these types of properties and set them to report less frequently than every report.
You can also try reducing the size/number of results returned by your properties and remove any unused properties to reduce network utilization.
A good place to start looking for performance enhancement possibilities is the BES Health Check dashboard.
What about cases where issues are caused by properties whose evaluation frequency is set to be “too frequent” and where BES admins cannot change them because they are grey-ed out and set by BigFix as part of managed content? (firewall, antivirus, antipest, dlp, etc. sites)
I am currently unable to effectively use many of the built-in dashboards because enabling associated analysis kills our high-latency, low-bandwidth networks. At least it did in the past. I am contemplating re-activating analysis now that we have implemented several tuning adjustments. One adjustment was setting the BESClient_Report_MinimumInterval to 300.
Will this help address my problem, or am I looking at this wrong? If I am able to compensate for BigFix-set property evaluation frequencies by slowing down how often clients report in, this raises a couple of other questions:
Will only the evaluated property values at the time of client report be uploaded, or will all evaluated property values since the last report be sent? In other words, will the firewall, A/V, and other analysis blast up every bit of statistical data since the last report or just the values set at the time of its next report?
My understanding is that only property value deltas are reported and that unchanged property values are not re-sent with future client reports. Is this correct?
Any advice on how to effectively enable and use the many BigFix analysis and dashboards without killing inbound network pipes on high-latency, low-bandwidth networks would be appreciated.
Most of the time the client report status information is so small that it doesn’t create any issues, but if you do have an extremely slow WAN and lots of reports, I suppose it could be an issue… although I would expect that you would need to have lots of other things going on because even a “big” BigFix report is usually less than a few kb and most networks can easily handle that…
Answers:
Any property that has had its evaluation period elapse will be evaluated and will report if changed. So if a property has a 6 hour evaluation period and the agent last reported it 6 hours 10 min ago, the agent will re-evaluate the property on the next report.
Only properties that change get reported. So if the previous answer to the property was “WinXP”, the agent won’t bother to resend the report data…
If you are worried about agent reports causing too much traffic, raising the minimum report interval will be a very powerful setting to ratchet back the amount of data… note that the max is 1 hour in older versions of BigFix I believe…