We are beginning limited rollouts of our new Windows Patch Management functionality starting today. The rollout is expected to last through the next couple of weeks before it’s been enabled on all Syncro instances. When the feature is rolled out to your Syncro account you and all of your users will be receiving an in-app notification. There is nothing you need to do or prepare for in advance.
For additional information please see our updated KB Article detailing what’s coming. You can watch our feature video HERE.
Feature updates are not done using the same API that is used for Windows updates. I personally don’t know of any RMM that pushes Feature Updates for Windows 10/11 by default. I spend a great deal of time in Datto RMM and their built in patching doesn’t push Feature Updates either. You can read right in their documentation stating the same as well.
There are however scripts that you can create (or get off the internet) that will allow you to update machines to the latest feature update.
It’s something we’ll look into down the road for sure, but our core focus with these enhancements was giving folks access to blocking patches by KB at the policy level, and the global level, as well as providing additional granularity to approve groups of patches by category and/or severity.
I’m not aware of any MSP platforms that push feature updates on the weekends. As I mentioned, our maintenance windows have been moved to the weekends. Our feature releases will continue to occur during the week. This is required for a great many things, including bug fixes.
In case anyone doesn’t realize why, MS has purposely left off switches that allow for silent installs and EULA acceptance on the feature updates. The workaround is to script the update assistance. @anon89643430
Thanks for the explanation. I knew Syncro didn’t do it and wondered more why, but your answer makes sense. - Although it does kind of suck, since it’s not as straightforward for RMM’s
I’m thrilled to see more advanced patch management coming to Syncro! The defer option is a brilliant idea that perfectly aligns with our update philosophy.
A couple of thoughts on this. Great job getting the deny and deferment, that’s going to help with automation.
On the asset record, it’s nice that things are broken down, but I didn’t see anything that showed deferred patches. It would be super handy to show a patch that’s deferred and when the next install date would be. Otherwise, you’re looking at Missing Patches and don’t know why it’s still missing without digging in.
Reboot should be a reboot window. If I patch during the day, I want it to only reboot during the evening during a set time and not notify the contact. By saying “Reboot By”, you’re saying you can reboot anytime from 12:00AM to whatever time you set and how many contacts have hit the wrong button on the prompt, way too many. This is not good for daytime patching because the system wasn’t online for various reasons. Because of this, I can’t rely on Syncro to reboot systems without interrupting my clients.
Why not run a custom reboot script that looks to a custom field and pulls the correct date time using the customers time zone (in case they are not same time zone as you)?
What I have set up is a custom field at Customer level that my script looks for and parses appropriately. It runs every hour and it checks that field and if it matches the day and the hour to reboot, it reboots, if it doesn’t it simple exits the script with not action taken. 1 script runs against all assets or targeted assets and you never have to worry about reboots again.
To expand on this if you need even more flexibility at a device level you can add another custom field at the device level that you enter the same information in, and just add a couple lines to the script to say if the device level isn’t null, then use that day/time instead of the customer level day/time. This way you can easily set exclusions and/or modifications simply by adjusting 1 field.
Sure, I work around it now with scripts, but this is something fundamental and should have been fixed with this update. Other RMMs I have used have reboot windows, so it’s an industry standard.
I agree some have it, but to say industry standard though, I’d disagree. My former RMM doesn’t have it, nor does Datto RMM which is arguably one of the largest RMM providers out there. It simply gives you the option to reboot when patching is finished or don’t. I know, because I’ve had to set up the same sort of reboot script in their system as well.
So just to be clear, I’m not arguing against having that feature, but I’m also not upset this wasn’t part of the focus in this update. I’m happy to have much better patching in Syncro now.
Well maybe I’ve been lucky then because I’ve had reboot windows since 2008-2009ish. Without proper reboot options, we all just have to band-aid. Even a Reboot At time would be better. When I first joined, I saw the complaints about the force reboot rebooting during the day, and the prompt not being clear enough and users accidently rebooting it by clicking the wrong button. This would have been a small update, but would have been a huge improvement, IMO. Maybe being an industry standard is a stretch, quick Googling shows others favor Reboot At times but also have modifiers if users are logged in or not. A better saying would have been that this Reboot By is not standard, is confusing, and has way too much human error involved. Datto’s looks gimp as well compared to others. Atera’s looks weak, looks like you should setup a second policy to run whenever you want it to reboot, otherwise it will reboot right after patching, but at least that’s an option without needing to script.
So missing patches will always be present regardless if they are deferred or not. This is because the agent will report back any new patches it finds daily, but they won’t be “evaluated” until the next patch schedule fires. This is largely due to the fact that you can have any number of Windows Patching subpolicies attached to an asset’s effective policy.
Reboot by is technically a window. It’s the time that the asset is allowed to reboot after the schedule fires. So if you have your scheduled set for 12am, and the reboot by is set to 2am, you have a 2 hour window. The only way that wouldn’t apply is if the updates went past 2am to process, so then the reboot would not occur during that window of the next scheduled cycle.
That part is OK, but it does not factor in daytime patching. “If offline, run at next boot”, that means that reboot window is from the time that machine finishes patching, which is during business hours. The option to “Prompt with message and attempt to reboot at specified time” doesn’t make sense, there isn’t a specified time, there is still only the Reboot by time.
At some point though - you are just better off creating your own time table using scripts. We did that just for reasons of only rebooting after hours and only if there isnt a sign on user after a bit of a idle delay. In cases where we know the user turns off the computer - we just still have it patch and just wait for the user to reboot by normal means. In other cases where the users puts their devices to sleep, we do prompt them to reboot before the end of the day or not to put their devices to sleep.
Yeah, we do this with scripts, we also do a weekly reboot that catches it, but the built-in options can be improved. It gets tiring when something is missing in the platform and the answer is to always script it. One of the selling points of Syncro was that it was easier and didn’t require paid onboarding, but the fact is, if it was easier, things would be built-in.