Maybe add a checkbox option in policy to enable reboots triggered by syncro windows updates put the asset in maintained mode for 30 min or something.
I have servers set to update Friday nights and I get flooded with 20-30 offline alerts as they reboot.
You can schedule a script that has the option set for maintenance mode for the time period you do reboots, that should take care of it. The script doesn’t have to have anything any it iirc. It would make sense to have this part of the patch policy itself though.
@isaacg I know its been a few months but I wanted to share that i’ve had a scheduled script set since your recommended it and have found it ineffective and thought I would share here in case anyone else reads this post.
Firstly Syncro is having issues with recurring scripts running consistently. I think this is a bug that will be fixed hopefully soon
Secondly when a recurring script does work, syncro queues scripts, so they dont all trigger in parallel. For example when the batch of 30 or so servers do queue up, I will have the script set to execute at midnight but some of them wont actually trigger until 12:05. 12:10 etc. so i still get an offline alert for some of them.
Yes, they’ve been having sporadic issues with scheduled scripts for a while. The migration off Heroku is supposed to help with this, if not directly then in troubleshooting or both. And yes script run times are not percise (load balancing reasons I imagine) so you’ll want to set your maintenance period script to run before the scripts that would cause machines to create alerts.
which feels silly.
Tell x minutes in advance that the endpoint is to run a script at y time.
Apart from telling the agent when to run the script, and receiving the response after the script has been run, the Syncro cloud servers do not need to be involved.
You can adjust the duration the asset has to be offline for before it trips the alert for exactly this reason (machines taking excessively long to reboot).
I don’t think any rmm’s queue up things on the client side, but it’s an interesting idea. It would add some complexity, not sure it’s worth the development time and possible issues. Also scripts would be setting on a machine vs just when they’re currently being run which can be a security issue in some cases.
Yeah definitely not something we’d ever do due to the security implications.
what are the security implications you are concerned about?
The agent gets told in advance to run a script at such and such time.
Only if the implementation in code of that idea is done poorly could a security problem be introduced.
Essentially this is about shifting the compute cycles to manage the timing of the execution of tasks from the cloud down to the end point. I’m confident that many anti virus and backup agents do this already. The end point agent knows when to run the local scan, or run the local backup, even though the timing of that scan task or backup task is configured by someone logging into a cloud WebUI.
Apart from being more reliable than the current task management implementation that Syncro has in place, Syncro saves money by using less cloud compute resources, and we all get a new feature (offline script execution), in the event that the Internet connect to the site goes down, or Syncro Cloud is offline.
Changing the offline time is not an acceptable solution, because during production I want to know ASAP if a server is down. Right now we have it set to alarm at 5 minutes, If I was to set the offline alarm further out I would be doing my customers a dis-service. I want to call them and tell them there is a problem before they call me. Maybe if we could have offline alarm times dynamic based on time of day that would be ok, but that would likely be more complicated to implement then having an option in your update policy to set the machine in maintenance mode for x minutes when rebooting for windows updates. Since that exists for scripts already I would think it would transfer to update policies fairly easy. Currently Its messy having to coordinate recurring scripts to do this. And unreliable.
Ok I like this idea overall. So basically you just want what we do on scripts which is enable maintenance mode, reboot (as part of the Windows Update process), and then disable maintenance mode at next check-in, correct? The only issue I see there is if the patches take forever (like 60+ minutes) to process for whatever reason, or if something bombed and Windows never came back up, you theoretically wouldn’t get notified on that.
So maybe if we ever implemented this we’d set a max window for reboots of 30 - 60 minutes where maintenance mode is a rearm mechanic if needed. Thoughts?
That’s exactly what I’m thinking, just like the maintenance mode checkbox in scripts but auto clears when the device checks back in. I agree that there need to be a timeout, any update that takes longer then an hour to update and reboot is a red flag.
Got it. Thanks for the extra details. This one makes total sense to me and would definitely add a good bit of value to the feature overall.