Targeted Reboot Within Timeframe

What the targeted reboot scheduling Worklet does

This Automox Worklet™ automates system reboot scheduling by enforcing reboots within a defined time window while monitoring user activity. The Worklet checks whether a reboot is pending due to system updates or patches, then intelligently delays the reboot until the specified time period arrives.

The Worklet incorporates user idle detection to avoid interrupting active work sessions. Administrators define a minimum idle time threshold, and the Worklet only triggers the reboot when users have been inactive for the specified duration within the designated time window.

This approach combines automated reboot enforcement with user-awareness, preventing productivity loss while guaranteeing critical system updates are applied promptly.

Why schedule post-patch reboots automatically

Patch management requires reboots to activate updates and security fixes, but manual reboot scheduling creates operational friction. IT teams must coordinate with end users, manage escalations from missed notifications, and address endpoints that never restart, leaving security vulnerabilities unpatched.

Automated reboot scheduling with idle detection balances two competing priorities: getting systems to apply critical patches and protecting user productivity. By rebooting only during off-hours or when users are inactive, you eliminate security drift without disrupting business operations or generating user support tickets.

This Worklet directly addresses post-patch reboots after applying Windows updates or third-party software patches. Administrators can schedule reboots for times when user presence is unlikely–late evening, early morning, or maintenance windows–for compliance with patch management policies.

How scheduled reboot enforcement works

1. Evaluation phase: Checks the Windows Update system object to determine if a reboot is actually required. If no reboot is pending, the Worklet exits successfully without further action.

2. Remediation phase: When a reboot is required, the Worklet validates three conditions using the configured parameters: the current time falls within the reboot start and end times, user idle time exceeds the minimum threshold, and the system has permission to restart. When all conditions are met, the Worklet executes a forced restart.

Reboot scheduling configuration requirements

• Windows 7, 8.1, 10, 11, or Server 2008 and later

• PowerShell 2.0 or later (installed by default on all supported Windows versions)

• Local administrator or SYSTEM account privileges required to execute restart commands

• Configure rebootStartTime in 12-hour format: examples include "11pm", "1:30am", "2:00pm"

• Set rebootEndTime to define the reboot window duration–must be later than start time on same day

• Specify minIdleTime in minutes: 0 for always reboot if time window is active, or set higher values for workstations to wait for user inactivity

• System must have a reboot pending (indicated by Windows Update system info) to trigger remediation

Expected behavior after reboot scheduling

When the Worklet executes successfully and all conditions are met, the endpoint restarts immediately with no user warning. Open applications and unsaved work will be lost–verify users understand the reboot window and save documents accordingly.

If no reboot is pending, the Worklet completes successfully without action. If a reboot is pending but the current time is outside the window or users remain active beyond the idle threshold, the Worklet exits without restarting, allowing your scheduled policy to retry at the next evaluation interval. After successful restart, all pending Windows updates are applied and activated, returning the system to a compliant patched state.

How to validate targeted reboot within timeframe changes

1. Run this Worklet on a pilot Windows endpoint and review evaluation output for targeted reboot within timeframe.

2. Confirm Automox activity logs show successful completion and exit code 0.

3. Verify endpoint state using checks aligned to evaluation script logic, such as New-Object.

4. Validate remediation effects from script operations such as Add-Type, Trigger-TargetedReboot, New-Object, then rerun evaluation for compliance.