Patch Relevance Flip Flop

Usage and Config Patch
1

Hi. Knowing that the msu installation returned with an exit code of 112 (limited disk space), that adds some uncertainty but I’m trying to understand why it would have returned with “Fixed” after the KB fixlet applied if it failed to install? If it didn’t fail, why did it turn relevant again after the reboot?

At 20:39:41 -0500 - actionsite (http://root:52311/cgi-bin/bfgather.exe/actionsite)
Command succeeded (Exit Code=112) waithidden “C:\Windows\system32\wusa.exe” “C:\Program Files (x86)\BigFix Enterprise\BES Client__BESData\Enterprise Security__Download\windows10.0-kb5041773-x64_9d8edb92e5824ddc53e1621da1e59c6f8f6e8455.msu” /quiet /norestart (group:1625502706,action:1625502712)
Command succeeded action requires restart “9d8edb92e5824ddc53e1621da1e59c6f8f6e8455” (group:1625502706,action:1625502712)

At 20:39:42 -0500 - Enterprise Security (http://sync.bigfix.com/cgi-bin/bfgather/bessecurity)
Fixed - MS24-AUG: Cumulative Update for Windows Server 2016 - Windows Server 2016 - KB5041773 (x64) (fixlet:504177303)
At 20:39:44 -0500 - mailboxsite (http://root:52311/cgi-bin/bfgather.exe/mailboxsite5006853)
Not Relevant - MS24-AUG: Cumulative Update for Windows Server 2016 - Windows Server 2016 - KB5041773 (x64) (fixlet:1625502712)

–REBOOT

At 20:43:21 -0500 - mailboxsite (http://root:52311/cgi-bin/bfgather.exe/mailboxsite5006853)
Not Relevant - MS24-AUG: Cumulative Update for Windows Server 2016 - Windows Server 2016 - KB5041773 (x64) (fixlet:1625502712)

At 21:29:01 -0500 - Enterprise Security (http://sync.bigfix.com/cgi-bin/bfgather/bessecurity)
Relevant - MS24-AUG: Cumulative Update for Windows Server 2016 - Windows Server 2016 - KB5041773 (x64) (fixlet:504177303)

Would it be that the actionscript sets an ‘action requires restart’ flag regardless of exit code and that caused the fixlet to evaluate to not relevant after execution (so it thought it was successful), then post reboot it re-evaluated and saw the installation of the msu did not complete because the fixlet became relevant again? Nearly 50min later though after reboot?

2

Yes it’s very likely the ‘pending restart’ that causes it to evaluate Fixed, based on the Relevance clause

not pending restart "9d8edb92e5824ddc53e1621da1e59c6f8f6e8455" OR ((value of setting "_BESClient_WindowsOS_BypassPendingRestartRelevance" of client as integer = 1) | false)

The issue is that if we don’t make it non-Relevant after installing/before reboot, you can get into a situation where operators repeatedly attempt to install the same patch without rebooting, which can break the system in worse ways. This relevance ensures the same patch won’t be attempted again until after a reboot.
You could ignore that relevance by applying the client setting _BESClient_WindowsOS_BypassPendingRestartRelevance = 1 but be aware that has some risks too.

3

I saw that and it might be my next option.
Doesn’t 50min seem like a long time for the client to evaluate that fixlet as relevant? I do see that this client has an Avg Eval Cycle of “20” (I think this is minutes) which is slooow. Maybe part of the problem for this one.

4

That might be a little long but it’s not suprising, given that we do a lot to throttle how much resource the BESClient uses to try to make it un-noticeable in terms of performance hit.

5

I’m used to seeing it 0-10ish. I might do a Profiler and see what is taking long to evaluate. thanks for the info

(average of evaluationcycle of client / 1000 *second / minute) as integer

6

https://developer.bigfix.com/relevance/reference/client.html#evaluationcycle-of-client-evaluation-cycle
is this in millisecond’s?

Are the Client Usage Profiler results also in milliseconds?

7

If the operator or application tried to install it a second time, the QFE engine would just return a code that says that fix is not applicable right?

8

I’ve no idea, but I would guess somebody put that relevance in our templates to correct some problem. Feel free to experiment with the client setting, but I think we already have the expected behavior where the action should make as Failed on reboot and the Fixlet becomes relevant again.