Windows - Configuration - Restart Device If Required

What the pending-reboot restart Worklet does

This Automox Worklet™ reads the registry locations Windows uses to flag a required restart and forces a reboot when any of them is set. It is a conditional action: endpoints already in a clean state remain online and untouched, and endpoints carrying a pending-reboot flag from Windows Update, the Component Based Servicing stack, or a queued file rename operation are restarted on the spot.

The evaluation script checks four signals to decide whether a restart is owed. It calls Test-Path against HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending and HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations, opens HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired through the 32-bit registry view and enumerates value names while filtering out three known-benign Windows Update GUIDs, and queries the Microsoft.Update.SystemInfo COM object so that recently installed updates that have not yet written a registry flag are still caught. If any signal is present, the endpoint is flagged non-compliant and the remediation phase runs.

The remediation script invokes Restart-Computer -Force, which translates to shutdown.exe /r /f at the Win32 layer and brings the endpoint down without waiting for a user session to confirm. The script does not stage a delayed restart and does not write a scheduled task; the reboot is immediate. Console operators see the Worklet result in activity logs, the endpoint checks back in once the OS finishes restarting, and the next policy evaluation reports a clean state.

Why close the pending-reboot gap on every endpoint

A patch that is installed but not activated is not a patch. Windows servicing writes the new binaries to disk, queues file renames, and sets RebootPending in the registry, but the running kernel and loaded DLLs do not change until the endpoint actually restarts. Until then, the CVE that the patch addresses is still exploitable on the live system. Pending-reboot drift is one of the most common reasons a fleet that looks fully patched in a vulnerability scan still shows exposure in production: the binaries are on disk, the registry is flagged, and nobody has rebooted the laptop in three weeks.

Sequencing this Worklet after the patch policies that produce the pending-reboot state closes the loop on Windows servicing. The evaluation phase reads the three RebootPending, RebootRequired, and PendingFileRenameOperations registry signals plus the Microsoft.Update.SystemInfo COM check; remediation fires Restart-Computer -Force only on the endpoints that actually need it. A workstation that has been carrying a pending kernel update for three weeks gets the reboot on the same policy run that detects the condition, and the next vulnerability scan reports the live kernel and DLLs at the patched version instead of the version on disk.

How pending-reboot detection and restart work

1. Evaluation phase: The Worklet runs Test-Path against HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending and HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations, opens HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired through the 32-bit registry view and counts value names that fall outside a small ignore list of known-benign GUIDs, and calls (New-Object -ComObject Microsoft.Update.SystemInfo).RebootRequired. If every probe returns false, the script exits 0 and the endpoint is reported compliant. If any probe returns true, the script exits 1 and remediation is scheduled for the same policy run.

2. Remediation phase: The Worklet executes Restart-Computer -Force, which immediately initiates a system reboot equivalent to shutdown.exe /r /f /t 0. The -Force flag closes user sessions and any open applications without prompting. The Automox agent records the exit and the endpoint reconnects once Windows finishes restarting. If the cmdlet is blocked by a Group Policy lockdown or a missing privilege, the script returns a non-zero exit code with the PowerShell error so the failure is visible in activity logs rather than silent.

Pending-reboot restart requirements

• Windows 10, Windows 11, Windows Server 2016, 2019, 2022, or 2025 with PowerShell 5.1 or PowerShell 7

• Local administrator privileges for the Automox agent so Restart-Computer can issue a forced reboot (the default agent context already meets this)

• Read access to the registry hives HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing, HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate, and HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager

• FixNow compatible – trigger directly from the Devices page in the Automox console to reboot a single endpoint immediately, without waiting for the next scheduled policy run

• Pair with a maintenance-window policy on servers and workstations where unannounced restarts are not acceptable; the conditional design means the Worklet only acts when a reboot is genuinely pending

• Compatible with both interactive workstations and headless servers; there is no UI dependency and no user prompt

Expected endpoint state after the restart Worklet runs

On an endpoint that had a pending reboot, the Worklet returns the endpoint to a fully patched runtime state. The Component Based Servicing\RebootPending key is gone, WindowsUpdate\Auto Update\RebootRequired is gone, PendingFileRenameOperations is empty, and (New-Object -ComObject Microsoft.Update.SystemInfo).RebootRequired returns False. The next scheduled policy evaluation reports the endpoint compliant and remediation is not triggered again.

On an endpoint that had no pending reboot, the Worklet exits with status 0 after the evaluation phase and the endpoint stays online. This is the safe-by-default behavior that makes the Worklet appropriate to schedule on a recurring policy across the fleet without risking unscheduled reboots on healthy hosts.

To audit the result, capture the exit code in the Automox activity log, then validate from a separate PowerShell session against the same endpoint: Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending', Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired', and Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager' -Name PendingFileRenameOperations -ErrorAction SilentlyContinue should all confirm the post-restart clean state. For compliance evidence aligned to CIS Microsoft Windows benchmarks and NIST 800-53 SI-2 (Flaw Remediation), pair the Worklet result with the patch policy run that preceded it so the audit trail shows both the patch and the activating restart.