Windows - Maintenance - Maintenance Window Reboots

What the maintenance window reboot enforcer does

This Automox Worklet™ enforces a maintenance-window reboot policy on Windows endpoints. The Worklet checks for an existing scheduled task named ScheduledRestart and validates that its StartBoundary trigger time falls inside your configured restart window. If the task is missing, in a state other than Ready or Running, or scheduled outside the window, the evaluation exits with code 2 and triggers remediation.

During remediation, the Worklet inspects the standard pending-reboot registry locations. If any signal is dirty, the script registers or refreshes a ScheduledRestart task running as the SYSTEM principal with RunLevel Highest. The task action is shutdown.exe /r /t 0, scheduled at the next valid start time inside your window. Task settings include -RestartInterval (New-TimeSpan -Minutes 10) and -RestartCount 3, so a failed restart attempt retries up to three times at ten-minute intervals. If $rebootForce is set to $true at the top of remediation, the script bypasses the scheduled-task path entirely and calls Restart-Computer -Force immediately, regardless of pending-reboot state or window.

Default behavior runs the window between 1:00 AM and 4:00 AM in the endpoint's local time. The $restartWindow variable accepts either 12-hour format with AM or PM, or 24-hour format. The $restartTimezone variable defaults to (Get-TimeZone).Id, and System.TimeZoneInfo.ConvertTimeBySystemTimeZoneId rebases the window into a different Windows time zone ID when you uncomment a value such as Eastern Standard Time, Pacific Standard Time, or GMT Standard Time.

Why enforce maintenance-window reboots

Pending reboots are the silent dead-weight on a Windows fleet. A patched endpoint that never reboots is not a patched endpoint. Several common change types all wait on a restart to take effect: critical Windows Update remediations, application installs that wrote PendingFileRenameOperations, domain joins recorded under HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon, and queued renames under HKLM:\SYSTEM\CurrentControlSet\Control\ComputerName. Letting users decide when that restart happens means the slowest user sets the security posture of the fleet.

Mid-day reboots generate help-desk tickets. Stalled patch windows generate audit findings. The same scheduled task prevents both. This Worklet writes a ScheduledRestart task under Windows Task Scheduler on every Windows endpoint in scope, sets the trigger to your maintenance-window cadence, and re-validates the task's existence and trigger times on each evaluation pass so a user-deleted or GPO-overridden task does not silently disappear.

How ScheduledRestart enforcement works

1. Evaluation phase: The Worklet parses $restartWindow into a $startTime and $endTime, converts both to the requested $restartTimezone via [System.TimeZoneInfo]::ConvertTimeBySystemTimeZoneId, and formats them as HH:mm strings. It calls Get-ScheduledTask -TaskName ScheduledRestart and reads $task.Triggers.StartBoundary. If the task exists, is in state Ready or Running, and its StartBoundary HH:mm falls between $startTime and $endTime, evaluation prints a confirmation and exits 0. Any other state (missing, Disabled, Queued, or scheduled outside the window) prints a remediation-required message and exits 2.

2. Remediation phase: The Worklet walks an array of pending-reboot signals using a Test-Reg helper. It checks PendingFileRenameOperations and PendingFileRenameOperations2 under Session Manager, the WindowsUpdate RebootRequired, Services\Pending, PostRebootReporting, and RunOnce DVDRebootSignal keys, the Component Based Servicing RebootPending, RebootInProgress, and PackagesPending keys, ServerManager CurrentRebootAttempts, Netlogon JoinDomain, and a ComputerName comparison against ActiveComputerName for pending renames. If $rebootForce is $true, the script calls Restart-Computer -Force immediately. Otherwise, if any pending-reboot signal fires, Get-RestartSchedule picks the next valid start time and Create-ScheduledTask or Update-ScheduledTask registers a SYSTEM-principal task running shutdown.exe /r /t 0 with -RestartInterval 10 minutes and -RestartCount 3.

ScheduledRestart policy requirements

• Windows 10, Windows 11, or Windows Server 2016 and later with PowerShell 5.1 or PowerShell 7

• Automox agent running as SYSTEM (the default context already has the rights to call Register-ScheduledTask under the SYSTEM principal at RunLevel Highest)

• Set $restartWindow at the top of the evaluation and remediation scripts to your desired range. Use 12-hour format with the AM or PM suffix (1:00AM-4:00AM) or 24-hour format (01:00-04:00)

• Optional: uncomment a $restartTimezone value such as Eastern Standard Time, Pacific Standard Time, GMT Standard Time, or any ID returned by Get-TimeZone -ListAvailable to rebase the window into a fixed time zone

• Optional: set $rebootForce = $true inside remediation to call Restart-Computer -Force on the endpoint immediately at the next policy run, regardless of pending-reboot state or window. This bypasses the scheduled-task path, so pair it with a policy schedule that only fires inside your intended window

• Coordination with downstream agents: if BitLocker, third-party EDR, or backup tooling guards against scheduled restarts, allowlist the ScheduledRestart task in those tools before broad rollout

Expected ScheduledRestart task state

After remediation, a task named ScheduledRestart appears at the root of the Task Scheduler library on every flagged endpoint. The trigger fires once at the next start time inside your maintenance window, runs shutdown.exe with argument /r /t 0 as the SYSTEM principal at the highest run level, and is configured with -AllowStartIfOnBatteries, -DontStopIfGoingOnBatteries, -StartWhenAvailable, and -MultipleInstances IgnoreNew. If the first restart attempt fails, Task Scheduler retries up to three additional times at ten-minute intervals before giving up.

Validate from PowerShell with Get-ScheduledTask -TaskName ScheduledRestart | Format-List TaskName, State, Triggers; the StartBoundary on the returned trigger must fall inside the configured restart window. Confirm the last-reboot history with Get-CimInstance Win32_OperatingSystem | Select-Object -ExpandProperty LastBootUpTime after the window passes; the value should land inside the window on every flagged endpoint. The Automox activity log records which conditions triggered the schedule, for example 'Pending Windows Updates' or 'An installed or updated application requires a reboot to complete', which gives change-management reviewers a per-endpoint reason code. Subsequent evaluations exit 0 once the task is in place and timed correctly, so the policy is safe to schedule on a recurring cadence without re-registering the task each run.