Targeted Reboot Within Timeframe

What the targeted reboot enforcer does

This Automox Worklet™ reboots Windows endpoints inside a defined start and end time window, but only when a reboot is actually pending and the active user has been idle for a configured threshold. The Worklet does not schedule a future task in Task Scheduler. Instead, every Automox evaluation re-checks the three gating conditions in real time, so the reboot fires the first time the policy runs while all three are true.

The script reads three policy parameters: rebootStartTime and rebootEndTime in 12-hour format ("11pm", "1:30am", "6:00am"), and minIdleTime in minutes. PowerShell parses the start and end strings with Get-Date, compares them against the current Get-Date timestamp on the endpoint, and only proceeds when the current time falls inside the window. The Worklet uses Add-Type to load a small C# helper that calls GetLastInputInfo from user32.dll, then converts the result into minutes of idle time so the script can compare against minIdleTime.

When the reboot is required and the window and idle thresholds are satisfied, the Worklet invokes a forced restart through shutdown.exe /r /t 0 (with /f to close hung applications). The endpoint goes down immediately with no countdown dialog, applies any staged Windows updates on the next boot, and returns to a patched, compliant state. If any condition is false, the Worklet exits cleanly and Automox re-evaluates on the next policy interval, so the reboot still lands the moment the window opens and the user steps away.

Why schedule reboots inside a defined window

Patches do not protect anything until the endpoint reboots. The longer a CVE fix sits staged but inactive on a workstation, the larger the exposure window between patch availability and patch effectiveness. Standard maintenance windows assume a server fleet that admins can drain, restart, and validate on a schedule. A workstation fleet does not behave that way. End users keep their laptops awake through the documented maintenance hours, suppress reboot prompts, and quietly accumulate pending restarts for weeks. The targeted reboot pattern closes that gap by combining a hard time window (the policy author owns when reboots are allowed) with an idle gate (the user owns whether they are interrupted).

The targeted-reboot pattern is straightforward to express but expensive to enforce by hand: each endpoint needs the same three-gate evaluation (reboot pending, current time inside the window, user idle past the threshold), and the evaluation has to keep firing until all three line up. One policy with rebootStartTime, rebootEndTime, and minIdleTime applied to a group rolls the rule across thousands of endpoints. Every Automox evaluation re-checks the conditions, so the reboot lands the first time a workstation falls quiet inside the window rather than waiting for an admin to stage it host by host.

How time-windowed reboot enforcement works

1. Evaluation phase: The Worklet instantiates the Microsoft.Update.SystemInfo COM object and reads its RebootRequired property. If RebootRequired is false, the Worklet reports compliant and exits 0 without remediation. If RebootRequired is true, the script proceeds to the second check: it parses rebootStartTime and rebootEndTime with Get-Date and compares them against the current Get-Date timestamp. An endpoint with a pending reboot inside the configured window is flagged non-compliant and Automox schedules remediation.

2. Remediation phase: The remediation script re-validates the time window with Get-Date, then loads a C# struct via Add-Type to call GetLastInputInfo from user32.dll. It converts the returned tick count into minutes of user idle time and compares against minIdleTime. When all three gates pass (reboot pending, current time inside the window, user idle long enough), the Worklet calls shutdown.exe /r /f /t 0 to force an immediate restart. If any gate fails, the script writes the reason to stdout ("outside window", "user not idle", etc.) and exits 0, leaving the endpoint for the next evaluation cycle.

Time window and idle parameter requirements

• Windows 10, Windows 11, or Windows Server 2016 and later (Windows 7, 8.1, and Server 2008/2012 still run the script if the Automox agent is supported on that OS)

• PowerShell 3.0 or later, which provides Get-Date and Add-Type natively

• Local administrator or SYSTEM context (the Automox agent runs as SYSTEM, which satisfies this)

• rebootStartTime in 12-hour format with am or pm suffix: "11pm", "1:30am", "2:00pm". The string is passed directly to Get-Date for parsing

• rebootEndTime in the same 12-hour format. Must be later than rebootStartTime on the same day. To allow overnight windows like 10pm to 6am, deploy two policies or extend the start time to cover the relevant period

• minIdleTime in minutes (integer). Set to 0 to reboot whenever the time window is active. Set to 15 or higher on workstations so the reboot waits for a coffee break or end-of-day idle period

• A pending reboot must be present (Microsoft.Update.SystemInfo.RebootRequired returns true). Without it, remediation never fires

Expected endpoint state after the reboot fires

When all three gates pass, the endpoint executes shutdown.exe /r /f /t 0 and goes down within seconds. Open applications are terminated without saving (the /f flag forces hung processes to close), so communicate the reboot window to users before deploying the policy at scale. On reboot, Windows Update completes staged installations, the Microsoft.Update.SystemInfo.RebootRequired property returns false on the next evaluation, and the Worklet reports compliant without taking further action.

Validate by running the Worklet on a pilot endpoint with a known pending reboot (you can stage one by applying a cumulative update without restarting). Confirm the activity log shows the script entering remediation, recognizing the pending reboot, evaluating Get-Date against the configured window, and reading the GetLastInputInfo idle value. If the endpoint reboots inside the window, the policy is correctly configured. If it does not, check the Worklet stdout for the gating reason ("outside window", "user not idle", or "no reboot pending") and adjust rebootStartTime, rebootEndTime, or minIdleTime accordingly. The Worklet is FixNow compatible, so admins can trigger an on-demand reboot evaluation from the console when a critical patch needs to land before the next scheduled policy run.