We’ve been hard at work to improve OS Patch Management and we’ve got a huge announcement for the Syncro community! Full details will be released very soon - but until then - here’s a sneak peek at what’s coming:
Ability to block patches by KB
Ability to block patches globally or at individual policy levels
Ability to customize based on Severity or Category of KB with expanded capabilities - Allow, Reject, and now Defer
Expanded information on Asset records
Details on the planned rollout schedule will be shared in the very near future, so stay tuned!
To see what’s coming, take a look at our OS Patch Management video:
This is a great start! Other things that need work with regard to patching that I don’t see mentioned in the video:
Ability to uninstall patches in mass (I’m assuming reject doesn’t remove)
Windows 10/11 build installation (and ideally an “update to x build option” for those that don’t want to be bleeding edge)
Microsoft product patching (Office, etc) that is currently disabled when Syncro patching is on.
Alerting when patches fail to install (maybe a threshold of how many times before alerting)
Reporting
Are rejected patches reflected properly in reports so that reporting can finally be useful? I don’t want to know Silverlight isn’t installed, it’s an EOL product I’ve removed from all machines. Drivers, etc.
Missing Patches by KB: title on page makes no sense, patches are not what’s vulnerable It’s called Missing Patches by KB on the reports page, the title on the page and URL should match that.
Missing Patches by KB: doesn’t have ignore new patches option like the Vulnerable Systems Report
Missing Patches by KB: the KB numbers don’t have links to the articles like the Vulnerable Systems Report
The Stale Age control lets you go all the way down to negative numbers. You can set a minimum value in the HTML. Same for the Vulnerable Systems Report. The reason I noticed this is I was hoping to only show PCs that are online. Thought maybe setting it to 0 would do this but it does not. Could this be added? Or just make it a separate checkbox. Same for the Vulnerable Systems Report.
Vulnerable Systems Report: Driver category option doesn’t work properly, you get a big list of assets but no info on the drivers and the missing column just says 0.
Neither report shows the description of the patch. If you don’t want to squeeze another column in, at least a tooltip would be nice so we don’t have to open each one to see what it is.
Reporting updates are something we’ll look at down the road. We first wanted to tackle blocking patches by KB and getting some proper severity/category approvals in place, including the defer mechanics.
I like the notifications on installation failure idea, though I bet that gets noisy. If we looked at making that an RMM alert you could handle in Automated Remediations, would that give you the flexibility you are looking for here?
What about a retry on installation failure for a set number of times then send an alert if exceeds that. This is a feature that we used in another RMM platform and worked well to reduce the noise.
Yup, that’s what I was thinking. A threshold would help (x failures in x days, BSOD and app crash monitors need these too). A report would be good also so you could see an overview across a customer or your whole clientbase for those we don’t want an alert for every failure.
On our last platform we had patch reporting without patching. It was useless. Having patching that works wouod be great, but without reporting still severely lacking. Hey customer, just trust us. We patch everything.
Ok, I will look into the AR route. The only thing with the x in y days thing is that folks will likely have differing install schedules. So if it fails it would retry at the next scheduled cycle. That might be a few days or even a few weeks depending on the policy.
It makes me wonder if it might work better as part of the Windows Patch subpolicy because of that.
Eh, if it fails once it’s probably going to fail again until there’s a reboot (running programs cleared/other updates applied/pending operations completed). Not sure retrying immediately would be very beneficial.
That is a good point Andy. Some may choose to patch different categories at different schedules even, so having it at the subpolicy level would make more sense. It would still be an alert and AR-able either way though wouldn’t it?
Yep. So hard coded logic goes into the Windows patching subpolicy, and then when that trips it fires of an RMM alert that can get picked up with AR. I’d have to check with engineers to make sure there aren’t any hiccups or other technical “gotchas” with that logic, and if we did opt to do something like this it would definitely be a post-release thing.
I’ve seen patches fail and then succeed later. If it alerted at the first failure, there’s going to be a lot of noise. In CWA, it gave 3 attempts, then it went into failure mode and then triggered. I can’t recall what the time between attempts were though.
For patch scheduling, I’d like a daily schedule with a day picker. For example, I’d want it to start patching 5 days after patch Tuesday, daily, until the last day of the month.
This is a great addition, happy to have these changes. One thing I would love to see are “Maintenance Windows” that we could set, which would absolutely prevent any kind of reboot.
So we could set the patch policy to reboot after installation, but if it is outside the maintenance window, the reboot will be queued until the maintenance window kicks in.
Unless I missed it, I don’t see anything here that makes it clearer how to handle patch reboots.
I’ll piggyback on what Isaac said for reporting, rejected patches should not affect patch health and should not show up as a missing patch. Secondly, excluding patches is a little cumbersome compared to other platforms. Say you need to reject the monthly patch across all OS. In other platforms, we can pull up a list of patches to approve and deny in bulk. In Syncro, it looks like our only choice will be to manually enter each KB. If it was a list we could choose from, then Syncro could validate it and the link to the KB and patch title could follow through to the deny list.
So patch reboots weren’t touched for this update, because that already existed with the previous version. So you can control reboots today, actually, in regard to Windows Updates.
Yeah but it’s kind of crappy in it’s existing form. I can’t trust it, so I don’t use it. There really needs to be a reboot window where the system can’t automatically reboot outside that window. The popup is confusing and causes unexpected reboots when clients choose an option they think is supposed to reboot later.
Perhaps a simple “Fail Count” metadata value we could access in automated remediations. Then we could action manual intervention however we wanted. @Andy, would that address concerns on this one?
It’s called Missing Patches by KB on the reports page, the title on the page and URL should match that.