What Does Your Windows Update Policy Look Like?

Curious what others are doing for Windows updates as far as scheduling, reboots, etc.

We’re thinking of patching once per week with a forced reboot overnight. We’d delay all patches 7 days, and simply set to approve all patch categories and levels unless there was a different requirement from the client.

One issue we have is patching laptops. Right now, the options for laptops I’m exploring are (1) do nothing and let Windows handle the patching, then manually intervene for any that are missing patches, or (2) install updates via Syncro policy with no reboot, then use a script to warn the user if they haven’t rebooted in over 14 days (for example), with an eventual forceable reboot.

What does your Windows update policy look like?

My servers defer updates for 7 days. Patching runs once a week for them and reboots if needed during patching.

Workstations also defer 7 days. However, workstations patch everyday starting at 11AM, and will patch once they come online if schedule was missed. They are set to not reboot. I then have a special reboot monitor I built that checks the local times of the devices and reboots them at a specified time approved by the client or during a time that will not interrupt them.


Critical and High patches auto approved, everything else delayed 5 days. Patch window every night with the non server policies set to install applicable patches when the asset comes online if the patch window was missed. I also use a script for reboots, it checks a bunch of the reboot required, type registry keys and if a reboot is required will reboot the machine.

A few clients that have a 3rd shift have special weekend only patch / reboot schedules.

To catch Laptops (and other devices that are off overnight) we have a late morning patch window with a requested reboot on the 4th Tuesday of the month. When people call about it, we tell them they don’t have to reboot right away but they should reboot sometime that day.

1 Like

I am liking the idea of using scripting to handle reboots. Would either of you care to share some of your scripting? I’m especially interested in the reboot-pending registry keys.

I believe I started with Adam Bertram’s Test-pending Reboot How to Check for a Pending Reboot in the Registry (Windows) code (Random-PowerShell-Work/Test-PendingReboot.ps1 at master · adbertram/Random-PowerShell-Work · GitHub). I whittled it down a bit to fit my needs. I found that some of the keys this script checks were getting set really frequently and causing reboots every night etc. It also seems like not all of the things that set registry keys saying they need a reboot clear them properly so that also caused some devices to reboot every night. In the end I ended up checking fewer keys, and then if the keys were present setting a scheduled task to check and clear the keys on next boot.

I do like the idea of specifying a local time for the reboot rather than necessarily relying on the RMM schedule to hit at the right time. This has not caused an issue for me yet but it’s a neat idea.

1 Like

Sure, I actually submitted this to the community library, but no idea how long it takes submissions to be reviewed. Either way, I run this against all workstations every hour. I moved away from checking if the device requires a reboot, because I like to make sure workstations are rebooted at least once a week anyway, just because we all know some users will leave their machines on forever and then call to complain their system is slow lol.

Anyway, the code below uses 2 custom platform variables. CustomerRebootDayTime is at the customer level, DeviceRebootDayTime is at device level. This allows you to set the reboot day/time at a customer level, but then if they have a specific device that needs a different time from then reset of the site, the Device level one will override the customer level on that specific device.
If no time is specified, it will default to a given time I have in the script.

Enter the info as Day|Hour. Hour is in 24 hour time. So if you want to set reboots for Friday at 4 AM, it’s Friday|4. Hope that makes sense.

##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

Do you do anything to deal with devices that are regularly off during their reboot window, any kind of notification to end users to let them know the device needs to be rebooted?

Not currently because the way I figure it, if updates happened that needed a reboot, and they happen to shut down their machine prior to my reboot schedule/script doing it, then that is fine, because on shutdown it would have installed the updates anyway. I disable fast startup on my client systems so that a shutdown is actually doing a shutdown, which resolves the 2nd concern that they never reboot the machine and complain of slowness.

Yea I have started disabling fast startup too. I assume/believe we have a bunch of systems that are sleeping or hibernating overnight.

I’ve been noodling on the idea of actually having my script change the power plan so the device does not sleep and lid-close or power button etc actually does a full shutdown when it is required.

I’m pretty sure there are edge cases where this would be problematic, but I haven’t thought of them yet.

I’d say go for all that except the lid close = shutdown. That would be the only one I could think of that would make someone angry, but the rest, I mean hey, if you hit the power button, expect a shutdown, can’t get mad at that lol.

Amazing info, thank you both very much!