Hi,
I’ve got a customer, that have a Patching Policy every 3 months.
He configured a Patch Policies for:
- Security Patches from Patches for Windows
- Browser Patches from Updates for Windows Applications
Each Patch Policy not configured with Auto-Refresh
He configured all of the schedules (Deployment Rings)
And he configured all of his machines to evaluate Superseded Content.
Before each Cycle, he manually “Refresh” the Patch Policy List and gets all of the Relevant Patches that are not Superseded and got Default Action
The cycles starts , and then as expected some of the Patches are turning to Superseded
- Security Patches from Patches for Windows - When a Patch become Superseded , The Default Action is removed - It will still be shown on the External Content - but when the Schedule arrives - It won’t be added as a Sub-Action
- Browser Patches from Updates for Windows Applications - All Superseded Content is still being deployed - because it still got a Default Action
This behavior - “The default/existing remediation action will be disabled, and a new remediation action added to prevent superseded patches from deploying automatically during a baseline sync; but to still allow for the patch to be deployed, if desired.” - Supersedence handling change for Windows Patches - Patch (Release Announcements) - From June 2017
causing the “Deployment Rings” to be non-consistent
And much worse, it is causing the Servers to be unpatched.
And the weird thing is, you are allowing Superseded content from other content sites to be deployed through WebUI Patch Policy - so the following statement “Superseded patches are flagged but not deployed” is False - Content (Custom/External) Tab
What I Expect:
-
While Refreshing Patch Policy content - It will only contain Fixlets that have a default action
-
When Content from the Patches for Windows becomes Superseded it will just be tagged as Superseded but will not remove the Default Action
I’ve already opened a Support Ticket about this and got the following workaround:
I should Copy all of the Relevant Fixlets to a Custom Site and change the behavior of the Patch Policy to Custom content and not External content.
This is quite absurd, because the only reason the patch is not being deployed - is the removal of the Default Action for the Fixlet - and this behavior is being done from HCL side.
What do you think?
I would like to hear more opinions about his matter.
I’ve already seen an Idea about this - https://bigfix-ideas.hcltechsw.com/ideas/BFPTCH-I-272 - Please also vote
With a three-month cycle, I don’t expect Patch Policy is going to be the optimal path for you, and you should probably consider the traditional model of creating and actioning Baselines instead.
Patch Policy is intended to meet the use-case of automatically creating actions dynamically according to your policy criteria. But in your case you specifically need it to not be dynamic, i.e. you aren’t trying to action things that meet your criteria now, you want the things that met your criteria three months ago. That’s a better fit for the traditional baseline approach.
“A patch policy is a set of criteria that defines a patch list; that is, a collection of Fixlets that meet the patching criteria of a specific set of endpoints.”
“Implement a patching strategy that meets your organization’s patching cycles and security guidelines. Use patch policies to establish and maintain a process of continuous security and compliance for your organization”
https://help.hcltechsw.com/bigfix/10.0/webui/WebUI/Users_Guide/c_get_started_with_patch_policy.html
@JasonWalker As I mentioned the Patch Policy method works great!
The only issue is with removing the Default Action of content from the Patches for Windows content site
This is not a Patch Policy issue - This is only an issue with the Removal of the Default Action.
I can understand why it was applied 6 years ago when patches were created through Baselines - But this is not the case anymore.
Hi @JasonWalker
Right now, I see that also content from the “Updates for Windows Applications” removed the default action from content when it is getting to the Superseded state.
Another situation that I’ve encountered - Weekly Updates for Microsoft Edge Stable Channel
As we can see in here - https://learn.microsoft.com/en-us/deployedge/microsoft-edge-relnote-stable-channel
Version 118.0.2088.61: October 20, 2023
Version 118.0.2088.57: October 18, 2023
Version 118.0.2088.46: October 13, 2023
Version 117.0.2045.60: October 6, 2023
Version 117.0.2045.55: October 4, 2023
Version 117.0.2045.47: September 29, 2023
Version 116.0.1938.98: September 29, 2023
Version 117.0.2045.43: September 25, 2023
Version 117.0.2045.41: September 23, 2023
Version 117.0.2045.40: September 22, 2023
Version 117.0.2045.36: September 19, 2023
Version 117.0.2045.35: September 19, 2023
Version 109.0.1518.140: September 15, 2023
Version: 117.0.2045.31: September 15, 2023
Version 116.0.1938.81: September 12, 2023
Version 116.0.1938.76: September 7, 2023
Version 116.0.1938.69: August 31, 2023
Version 116.0.1938.62: August 25, 2023
Updates were released in a rate lower than 1 week…
The prefetch links on those Fixlets contains working links and relevance statement will result true , if the computers are configured to evaluate superseded content.
This behavior - “The default/existing remediation action will be disabled, and a new remediation action added to prevent superseded patches from deploying automatically during a baseline sync; but to still allow for the patch to be deployed, if desired.” is invalidates the statement - “Implement a patching strategy that meets your organization’s patching cycles and security guidelines” - https://help.hcltechsw.com/bigfix/10.0/webui/WebUI/Users_Guide/c_get_started_with_patch_policy.html