Hello everyone,
Can anyone suggest when should we use this feature “fixlet for BigFix Client Settings:Enable command polling”.
and it’s impact or it’s benefit please.
Basically everyone should enable Command Polling. How frequently to poll is a matter of some debate, and generally the answers fall between one to four hours.
In a default installation, the BES Client will check its upstream relay/server every 24 hours for updated content. That’s when it will find new Actions to run, as well as new Fixlets and Analyses to evaluate.
Checking only once a day is far too much delay for most deployments, so the client can also be “informed” by its upstream relay every time there is a change in content, pretty close to immediately. That is done by the upstream relay sending a UDP message to the client to inform the client that there is something new.
However, if anything is blocking the UDP message from the relay to the client, the client won’t be informed of the new content and falls back to gathering new content once per day. It’s common for a network firewall, host-based firewall, or NAT-translating router to prevent these UDP messages from getting through.
In short - when the UDP is blocked, Command Polling is essential to keeping the client current and responding more quickly to new content and taking new actions. And as long as you don’t tune the command polling interval too low (say, no more frequently than once per hour), you aren’t going to cause much workload increase on your relays.
3 Likes
in the fixlet note it says clients may not functioning properly. so the confusion gets created on this point.
“There are various reasons to modify a BigFix Client gathering interval. The most common is that the BigFix Server/Relays are not able to send UDP messages to the BigFix Clients due to network constraints. Changing the Gather Interval will put more load on your BigFix Server/Relays so be careful when modifying this setting.”
You’ll need to consider the performance tuning based on the size of your environment and its network and relay topology.
As long as you set the interval no more frequently than an hour, you should be fine in most deployments. If your deployment is over fifty thousand endpoints or so then you’ll need to be careful about every performance-sensitive change you make, so, as always, your mileage may vary.
I wonder why the command polling interval default is 15 minutes when you are recommending 1 hour? I was considering changing my command polling to 15 minutes from 1 hour, but after reading your post, I have decided to keep it at 1 hour. We have 8,000 endpoints, but less than 1000 on the internet without VPN or LAN connection.
@JasonWalker I remember that the Root Server will Gather new content every 24 hours by default.
The BES Client will make Relay Selection every 6 Hours by default, and with that he will also gather new content that is waiting for him. Am I wrong?
Yes that’s correct. Command Polling may be used to increase the frequency of checking new content, so Actions or new Fixlets are evaluated more frequently than the 6-hour Gather interval when the client does not receive the UDP messaging.
When it comes to the Command Polling interval, “It Depends ™”
There were cases on older BES versions and slower processors where too-frequent Command Polling could have a couple of impacts - overloading the Relays responding to the polls, and interrupting the evaluation loop on the client.
My memory’s fuzzy on the client loop issues but in my recollection, in some cases (usually with very large Baselines), if it took the clients more than 15 minutes to evaluate the Baseline, that evaluation could be interrupted by a Command Poll and the client would start over on the baseline after the poll completes. Then the re-evaluation gets interrupted again on the next Poll and every time after - with the net result that the client never finishes a loop and appears to be “stuck”, never sending reports about the new content. It’s been a long time since I’ve heard of such a case but I don’t know whether that’s because of any enhancements/fixes we made or a natural result of better processors or just that everyone followed the recommendations of longer Polling intervals.
I always suggest to customers to take a look at their client evaluation loop when they are talking about command poll.
I always suggest creating a property with the following relevance to show how long the client eval cycle is.
average of evaluationcycle of client / 1000 * second / minute
In my lab environment I actually have a task that checks this value and resets the command poll interval based on it.
1 Like
I may need to re-check some of this
I have issues with “average” of anything. If we have a content author create a package that takes hours to evaluate, the severely impacts the average, even after I delete it. (This actually happened with a file scanning fixlet.)
If I sit in heavy traffic for 3 days and get 10 miles to the gallon but then get 30 miles to the gallon the rest of the week, the 21 miles to the gallon my car reports is not really an indicator of what kind of gas mileage my car gets.
track fixlets of evaluationcycle of client
This was giving fixlet IDs of Fixlets that no longer existed and how I discovered that the average was skewed by poor content authors.
There is also this if you prefer. I believe it is the max of the last 10 cycles just like the average is.
maximum of evaluationcycle of client / 1000 * second / minute