Last report time client - Windows vs Unix-like systems

Usage and Config Platform
1

Hi all,

Our environment contains hosts with AIX, Linux and Windows operating systems. We don’t customize performance/cpu related settings on clients, but, we see an “strange” behavior: when we send refresh on Unix-like systems, we get response faster, and “Last report time” info is almost immediate (with current date and time). But, when we send refresh on Windows systems, the last report time response have a delay, and sometimes it takes some minutes to update report time info. It occurs considering both servers/OS types are in same network/vlan and set to same relay.

That is: Unix systems, last report time returned by client is “up to date”. Windows systems, not so…

Someone had similar experience, or have any idea about what can be happening?

Regards

Uiliam Mello

2

@foschiera, I would recommend comparing the BESClient daily log (i.e. yyyyMMdd.log) from a Unix and Windows endpoint after sending a “Send Refresh” from the BES console. Specifically look for the “ForceRefresh command received.” and “Full Report posted successfully” entries and their associated timestamps. The following was taken from a Linux endpoint in my BigFix lab environment.

At 12:48:41 -0400 -
ForceRefresh command received.
…
At 12:48:48 -0400 -
Full Report posted successfully

So on that particular endpoint, it took approximately 7 seconds between when it received the UDP ping on 52311 until it posted the full report with its new timestamp for the “Last Report Time” property.

Assuming all your timestamps are reasonably the same, then I would have to chalk it up to differences between *NIX and M$ Windows.

Two other items that you could check if you’re so inclined are:

  1. FillDB performance as this directly impacts when endpoint reports get committed to the BFEnterprise or BFENT database (name depends on Win/MSSQL vs. RHEL/DB2).
  2. Clear the cache for your BES console instance, close the BES console, reload the BES console, wait until all objects have loaded, and then re-run your refresh test.

There is documentation available for both of the above on the support.bigfix.com portal. I hope this is helpful.

Best,
@cmcannady

1 Like
3

I think one of the very likely thing is that your Windows clients may have more, or longer-running properties or analysis results.

When send the “Force Refresh” command, the system re-evaluates every property and Evey fixlet relevance for sites that the computer has subscribed, which can take longer on Windows systems where there are usually more fixlets and properties to evaluate.

Using the “Force Refresh” command is something you generally shouldn’t be doing on a regular basis, it should be reserved for cases where you think something has changed on the computer and you need the results updated now, rather than waiting for the normal evaluation period (which might be daily, weekly, or even monthly for some properties).

4

Hi all,

Thank you @cmcannady and @JasonWalker, I’ll re-evaluate our environment considering items that both you’ve pointed.

Best regards,

Uiliam Mello