Patch Policy -- "Pending Restart" not clearing

[atlauren]

While experimenting with Patch Policy, I’m not seeing the “PP_” actions’ Pending Restart status clearing after the machine has, indeed, actually restarted. (In this case it the machine was manually restarted at the Start menu.)

Dissecting the relevance for the “Restart Needed - Triggered by a BES Action” fixlet:

Q: exists key "HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\BESPendingRestart" of registry
A: True
T: 3.000 ms

Q: exists value "BESPendingRestart" of key "HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\BESPendingRestart" of registry 
A: True
T: 5.000 ms

Q: exists key "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce" of registry 
A: False
T: 5.000 ms

Q: exists value "BESPendingRestart" of key "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce" of registry
E: Singular expression refers to nonexistent object.
T: 5.000 ms

Is there an explanation for the BESPendingRestart not clearing?

[D.Dean]

How long after you rebooted did you check these settings? The system would have to call in and run the relevance again to clear the values.

Second, if you waited a period of time and they did not clear, did the patches show installed?

Third, if you waited a period of time, check your evaluation times and compare that to your polling time. If polling is set and it is shorter than the evaluation time, the system will check in but not update because it never finished the evaluation. Evaluations start over if they are not completed when the system polls.

I have the relevance to check all of that but my session is hung on my jump box. I will come back and add it after I get it back.

[atlauren]

Thanks @D.Dean. You’ve prompted me to take a fresh look at our configured settings for reporting and CPU usage… It seems we have a bit of work to do there.

[D.Dean]

I often get asked why a system calls in but does not take action on a deployment someone sent, or why a property does not update. Every time it comes down to the evaluation time and the poll settings. See below, this system had a maximum evaluation time of 48 minutes but the average is 23 minutes. The poll time is set to 7200 (seconds) so 7200/60 = 120 minutes, or 2 hours. This system should update every time it calls in. But there are some systems that are slower or has an applicable fixlet that takes a long time and the evaluation time will be more than 2 hours. At the poll time, it will interrupt the evaluation and start it all over again.

q: ((maximum of it /1000* second)/minute) of evaluationcycle of client
A: 48
T: 0.034 ms

q: ((average of it /1000* second)/minute) of evaluationcycle of client
A: 23
T: 0.034 ms

q: track fixlets of evaluationcycle of client
A: 40.526: actionsite.1370938:Background Evaluation
A: 15.505: actionsite.977479:Background Evaluation
A: 13.469: actionsite.977479:Background Evaluation
A: 13.009: actionsite.977479:Background Evaluation
A: 12.901: actionsite.977479:Background Evaluation
A: 11.977: actionsite.55095:Evaluate Property 1
A: 11.913: actionsite.977479:Background Evaluation
A: 10.533: actionsite.977479:Background Evaluation
A: 10.403: actionsite.977479:Background Evaluation
A: 10.201: actionsite.977479:Background Evaluation
T: 0.300 ms

q: value of settings "_BESClient_Comm_CommandPollIntervalSeconds" of client
A: 7200
T: 0.034 ms

[atlauren]

Speaking of, what units are reported by track fixlets?

Is it seconds.milliseconds?

[D.Dean]

seconds

https://help.hcltechsw.com/bigfix/9.5/platform/Platform/Config/r_client_set.html

[JasonWalker]

It is indeed seconds.milliseconds.

It should also be the “real/clock time” for evaluation, i.e. modifying your _BESClient_Resource_WorkIdle and _BESClient_Resource_SleepIdle will change the average times. These aren’t “# of cpu cycles spent” added up. That’s why these times will be so much longer than what’s seen for equivalent expressions in the Fixlet Debugger, where the CPU usage is not constrained.