BigFix Content still relevant after being applied and "Fixed"

[fermt]

We are seeing a few servers taking up to one day to report as not relevant for content that has been already applied(Servers have been restarted and the updates have successfully been installed).

The only way to make the clients report as not relevant is to send a refresh from the console or wait for more than 24 hrs to let the agent self-report. When I look at the agent’s logs I don’t see any entry saying the content was re-evaluated and reported.
As I mentioned the fixlets has been successfully installed the updates and it is just a matter of taking too long to reflect the changes. This is an issue for our patching reports because it is not reflecting the real compliance of our environments and therefore there are some doubts raised about BigFix.
We are running 10.0.7 for all the components

Besides forcing the refresh of clients from console, what else can be done to ensure the clients re-evaluate the content once it was applied?

[ageorgiev]

“Send Refresh” is technically under the hood the equivalent to running actionscript command: notify client ForceRefresh, so there are ways you can workaround the problem if you want a short-term fix (you can create a custom task with that command and either add it to reboot task; schedule to run as a policy after reboots; etc) but in all fairness this shouldn’t be happening / shouldn’t have to do all that and if I was you I would open a support case and get L2/L3 to review. I’ve seen this happen a long time ago on certain machines (on a few it got cleared with complete wipe and reinstall of the client; on a few we found agent getting hung on wmi-based properties due to WMI corruption and never resumes its agent cycle to go through fixlet evaluations; etc) but some of those refer to bugs/improvements that have been put in the agent since. Support would need you to potentially run the client debug mode & potentially the client profiler on machine with the issue and see what exactly is happening.

[JasonWalker]

Can you give an example of some of the Fixlets that are not refreshing?

As a client optimization, it is possible to configure specific content to delay re-evaluation, like “evaluate every 6 hours” or “once a day”. We’re leveraging that in the “Updates for Windows Extended”, “Middleware Extended”, and “KEV Content Pack” sites, among others, because there’s a lot of content there or content with slow relevance.

When you take an Action from these, the client gets a “hint” and should re-evaluate the source Fixlets right away, but it might get complicated if you’re using custom copies of the Fixlets instead of the original source Fixlets.

Not sure whether that’s the problem, but knowing which sites & Fixlets are delayed will give me a start on what to look for.

[fermt]

We are seeing this with Fixlets from the Patches for Windows External Site.
No custom copies of the fixlets are being used.

This is one of the Fixlets that I have noticed:

502108501 MS22-DEC: Cumulative Update for .NET Framework 3.5 and 4.7.2 for Windows Server 2019 - Windows Server 2019 - .NET Framework 3.5/4.7.2 - KB5020866 (x64) Patches for Windows 2 / 27 Important 3 Security Update 76.34 MB Microsoft KB5021085 12/13/2022

Once the fixlet gets applied I would expect a re-evaluation of the relevance to report whether or not the content is still relevant but that doesn’t happen. I either have to wait many hours or send a manual refresh to get the agent re-evaluate the content and then it will report the Fixlet as Not Relevant/Applicable.

[fermt]

The weird thing is that, as I mentioned before, we need to wait hours some times days so the relevance gets re-evaluated by the agent itself without having someone to restart or send a manual refresh.
It’s hard to troubleshoot as once the content has been re-evaluated we can’t reproduce the issue on the same endpoints until we see different endpoints presenting the same behavior.

[MatthiasW]

When running a baseline to Patch the clients I find it useful to place the fixlet “notify Client force refrsh” at the end. This makes sure that analyses which eg. report OS Versions are updated.

[fermt]

I don’t feel like we want to have thousands of servers refreshing their data at the same time and then sending that back to the Root Server.

[D.Dean]

I don’t disagree with you but it is highly doubtful they would run at the same time. They won’t check in, run the actions, take the same amount of time to install and check back in, all at the same time, they all would take different lengths of time to run everything.

[JasonWalker]

I still think opening a Support incident and providing client debug logs will be helpful, they can step you through troubleshooting.

It may be useful to check out long-running evaluations… I describe some methods at Troubleshooting Client Reponsiveness

[strawgate]

Once the fixlet gets applied I would expect a re-evaluation of the relevance to report whether or not the content is still relevant but that doesn’t happen. I either have to wait many hours or send a manual refresh to get the agent re-evaluate the content and then it will report the Fixlet as Not Relevant/Applicable.

Unless I’m misunderstanding what you’re saying this is exactly what’s happening. An action is totally independent from the underlying Fixlet, it’s a copy of the underlying Fixlet. And the action can vary arbitrarily from the underlying fixlet (you can modify both the relevance and the actionscript when making the action). After applying, the action is no longer relevant.

As others have stated, because the Fixlet and your Action are not directly related, it takes a background evaluation for the original Fixlet to show as non-relevant and Windows patch content is not evaluated every evaluation loop and so does not refresh particularly quickly.

[fermt]

I agree that an action is independent from its source Fixlet. However, we are having servers that keep reporting as relevant for the source Fixlet after a few hours it has been remediated. It will eventually report as Not relevant for the Fixlets, either we wait more than 24hrs or we send a manual refresh. This is not happening across all our servers so I suspect something in particular is happening with a subset of servers.

I am working on enabling client debug logs to trace what could be causing this. And I will be opening a support case to formally work with HCL on this issue.

Thanks everybody for their inputs.