Installed patches are still relevant

A customer is testing Windows Patching with BigFix, but we are facing a situation I cannot explain:

May/5 - MS17-DEC KB4054518 was installed and server rebooted

May/6 - MS17-DEC KB4054518 was still relevant and new action failed with Exit Code -2145124329, which means windows consider it as installed
May/6 - MS18-MAY Monthly Rollup KB4103718 was installed and server rebooted

After this reboot, KB4054518 is still relevant even though the last action failed because it was not applicable.

I’ve seen multiple posts in this forum regarding discrepancies about WSUS and BigFix, but I have no idea how to explain to the customer why BigFix still considers the MS17-DEC patch as applicable if the latest MS18-MAY bundle was already installed and it should have covered all patches to date.

Any advices will be appreciated

This may take some investigation. I would recommend a PMR to run the issue to ground.

  1. For KB4054518 in order to be relevant at this late of a date… you should have the following setting, set. Which I believe you did as it was relevant. Or was the relevance modifieed to distribute the fixlet? (value of setting "_BESClient_WindowsOS_EnableSupersededEval" of client as integer = 1) | false

  2. For KB4103718 it to be relevant and actioned this patch should not have a pending restart. If the reboot pending has cleared, I would assume that since the device should now be able to properly action the Fixlet.

One way to check for a pending restart. would be to use this relevance in a property or analysis.
not pending restart

-jgo

2 Likes

Another troubleshooting technique would be to test each relevance statement from the MS17DEC KB4054518 fixlet in the target endpoints QNA tool or via Query in WebUI. Once you’ve identified the offending relevance statements you can better determine if the issue is the fixlet content or a systems config/state issue. I would recommend doing this before opening your PMR as it would provide needed details for L2/L3 if it is in fact a content issue.

2 Likes

Thank you jgo and cmcannady for your replies.

Jgo:

1 - Yes, all systems have “_BESClient_WindowsOS_EnableSupersededEval = 1” and that’s why superseded patches can still be installed by the users. This is the desired state, but they should became not relevant after MS18-MAY bundle was installed

2 - Servers are not pending restart as “Pending Restart” fixlets from BES Support site are not relevant.

cmcannady:

I agree this is something that can be done, but It became a pain after this new bundle approach by MS due to dozens of verifications that would be needed, so that’s why I was looking for creative suggestions in this forum, but perhaps is the only way to find the root cause :wink:

Thanks everyone

1 Like

I wonder whether that’s actually expected behavior, to some degree.

Part of the problem with evaluating superseded content, is that each new monthly rollup gets a new package name from Microsoft. Once a package is Superseded on the Bigfix side, I wouldn’t expect the content team to keep updating its relevance to lookfor newer package names.

1 Like