Windows Update restart Scheduling

we have an issue with Windows Updates,
We have them scheduled with a reboot message is there a way to force reboot the device at the scheduled time rather than them accidentally rebooting their device?

eg our message says “Your computer has installed updates please save your work and Restart, Otherwise, it will restart at 7 PM”

can we change the buttons so that the buttons have [restart now] and [restart later]?

Or so that it force reboots at the reboot by Time but the Message appears at 3pm reminding them to leave their PC on for the updates to install and then again 20 minutes before it force reboots?

I feel like your above request, conflicts with your request below. If you set the policy to prompt and reboot at specified time, then it will try and reboot that the time you selected.

As far as the messages appearing at specific times, you would have to write something custom and just use something like msg *.

I personally do not use the patch policy to initiate reboots, and instead, I allow the patching of workstations to happen every day, during the day so the likely hood of them staying up to date is much better than patching once a week at night or whatever. I then have a custom reboot script that runs hourly and checks some custom fields to determine when it’s time to reboot the device on the clients local time.

it’s more of an either-or question.

If I can’t force a reboot at a scheduled time then can I change what the buttons say (currently allow or deny)

While we have patching running daily, we also have a weekly one for our clients that are notorious for never restarting their machines and then complaining when Microsoft forces them to do it in the middle of the day,

if I have to script it, I will be. Just trying to avoid it/ leverage something if it already existed :slight_smile:

Ohh ok. I was just not understanding then. Cannot change those buttons to my knowledge.

If they are known to turn off their computer so you can’t do your updates… you can always just remove the power option for powering down during the time/day you plan to do your updates.

Also, plan around when they are not in the office normally fixes that. We push all updates to times that the offices are close or till midnight for most of our clients.

As for office road runners - that can be a bit challenging. You would just need to make an office policy with your client’s office that will best work with everyone. Every day updates wouldn’t work there - you would have them return every month or just do your best to update them on the go. That or warn them its automatic - but failure to turn on your laptop first Wednesday night means it will try the next time you open your laptop and that will be on you.

While I dont have this issue with my clients, if they complain that they can’t shutdown their computers - that gives you time to talk with them and explain. If anything you can be a bit smirky about it. “Yes, I know you can’t power down your workstation. We are going to do update tonight and need it on. I mean, you don’t want to do this in the middle of your work session, correct?”

Hi is it possible to have that reboot script?


Sure. Make the 2 below variables.

##Initial Setup##
Import-Module $env:SyncroModule -WarningAction SilentlyContinue
##End Enitial Setup##

Write-Host "Checking reboot day and time..."

$DefaultRebootTime = "Saturday|1"

if ($CustomerRebootDayTime) {
    $DayTime = $CustomerRebootDayTime
if ($DeviceRebootDayTime) {
    $DayTime = $DeviceRebootDayTime
if (!($DayTime)) {
    $DayTime = $DefaultRebootTime
$Today = (Get-Date)
$DayTimeSplit = $DayTime.Split("|")
$Day = $DayTimeSplit[0]
try {
    $Time = [int]$DayTimeSplit[1]
catch {
    Write-Host "Error. Integer not detected."
    Exit 0

if ($Day -ne $Today.DayOfWeek) {
    Write-Host "Not my reboot day"
    Exit 0
if ($Today.Hour -ne $Time) {
    Write-Host "Reboot day, but not time yet."
    Exit 0

$ActivityMessage = "Device Reboot Initiated at $($Today) by Reboot Monitor."

Write-Host "This is my reboot time. Rebooting now..."
Log-Activity -Message $ActivityMessage -EventName "Reboot Monitor"
Invoke-WmiMethod -Class Win32_Process -Name Create -ArgumentList "cmd.exe /c shutdown /r /t 15 /f"
Exit 0

Thank you for this. I gave up some time ago on the built-in Syncro updater’s reboot function and started using a reboot script instead and the level of patching for our assets has improved dramatically.

1 Like

Awesome, glad it could be useful to someone else :slight_smile:

I’m curious about your use of Invoke-WmiMethod to run a cmd command. Did you run into some specific problem that caused you to reach for this method to shell out to cmd, vs just using the shutdown command from PowerShell, or even the Start-Process cmdlet?

Yes. I originally wrote this for use in a different RMM, and did it this way because of the scripting engine and how it communicates back with the agent. If I used PowerShell native functions to trigger the reboot, it would basically killed PowerShell and reboot too quickly and it would not communicate back to the platform in time, so by dumping it off to a cmd process and delaying the reboot by those 15 seconds would allow PowerShell to continue and complete and report back the proper status to the platform, followed by the reboot. In the other platform, it would also cause the device to show the script has still running in it’s activities (until the script timeout period would expire) thus causing other items to hold in queue until the reboot script expired. So doing it this way was the workaround for that as well.

Syncro definitely does some things differently than the other platform and I don’t know to be honest if the same problems I mentioned above would also happen here, so I figured this way is a tried and true method at this point, so I didn’t see much of a reason to change it for Syncro other than the needed pieces to make it work with Syncro and it’s environment variables.

I probably could have used Start-Process or even & "cmd.exe /c shutdown /r /t 15 /f" but at the time I just went this way figuring it was a safe bet especially for some pretty old Windows devices that were still out in the wild on the other platform.

Syncro has a similar issue with Restart-Computer. The script doesn’t ‘complete’, so syncro runs the script again after it comes back online which cab cause a loop. shutdown /r doesn’t seem to have that issue. I never played with adding a delay to restart-computer, that might solve that.