I’m going crazy. I submit an Action to patch a machine and the action fails. I submit the action again later and it says “Fixed”, but I go to the machine to manually check if the patch applied and it’s still not on the machine. This drives me crazy. What causes this? Do I need to delete the completed Action that failed before I run the Action again to get this to accurately reflect in Bigfix? I just want my reports to be accurate when I run them, and I’m lost as to what could be causing this.
Is there a pattern to this behavior? What type of patch is it? Which operating system?
I recommend that you start troubleshooting by viewing the client log file(s) for the time periods in question and find the lines that reference the Actions’ ID numbers, especially for the the Actions with a “Fixed” status.
There is a direct correlation between the relevance and the result. For a fixlet (Not a task), the relevance is checked after the action is applied. If the system is still relevant, the action is considered to have failed. This will happen every time if the relevance is set to all computers. A task, used just to take an action on a system, can have relevance but the relevance is not checked after the action completes. It simply executes the command and then returns “completed”. If the task is still relevant, the task will still return a “completed”.
There is often confusing between tasks and fixlets. Typically Fixlets are used for patches and vulnerabilities, tasks are just that, made to execute a task.
Its possible you are going to need to get access to the affected system to troubleshoot this one. Things I would be looking at are
When is the fixlet being applied (the action stats or client logs will record this)
Does anything appear in the Windows event logs that correspond to the attempted installation?
Do the event logs show the update failed?
Does the Windows Update History show the update as failing?
Is the update being rolled back after reboot (that might be one possible reason why its seen as Fixed)
Is the endpoint at the minimum required SSU for the update? KB5006667 has a pre-requisite that the July 2021 SSU KB5004748 is installed.
I have seen numerous cases where local OS factors will impede an update from being installed, be it via Bigfix, or even directly from Windows Update. If you think about it, Bigfix is pulling the MSU then running WUSA to apply the MSU so the install at that point is passed to the local Windows Update service. These can be hard to troubleshoot and typically will require getting onto the endpoint to dig deeper into event logs and logs such as the CBS.log.
The relevance that is most likely to be transitioning from true to false and back to true again is relevance 6 or 7
(it as integer < 1854) of value "UBR" of key "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" of native registry
not pending restart "202bc0d5c7a8ffe626ff09ddb3b3f81e757a9d37" OR ((value of setting "_BESClient_WindowsOS_BypassPendingRestartRelevance" of client as integer = 1) | false)
Next time it goes non-relevant after applying the patch, test those relevancies (you can use relevance debugger locally, or WebUI Query remotely).
I also wonder what this relevance returns for both the “non relevant after patching” and the “relevant again” states:
value "UBR" of key "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" of native registry