# Stop Disruptive Reboots: A Guide to Non-Disruptive Patching

Purpose and Scope 
------------------

This document outlines the technical configurations and operational workflows required to prevent unexpected operating system reboots during business hours. The focus is on controlling restart behavior during patch deployment, ensuring system stability while maintaining security compliance across managed endpoints.

Strategic Overview: Non-Disruptive Patching 
--------------------------------------------

In a Unified Endpoint Management environment, system reboots represent the highest risk phase of patch management. A poorly timed restart can interrupt user productivity, disrupt critical workflows, and erode trust in IT operations.

Hexnode UEM addresses this risk through a layered control model that combines:

- Active Hours enforcement
- Update Experience policies
- Scheduled maintenance windows
- User driven postponement controls
- Optional script-based automation for advanced scenarios

Together, these mechanisms ensure that patch-related reboots occur only when devices are least likely to be in active use.

1. Active Hours and Update Experience Configuration 
----------------------------------------------------

### Objective 

Prevent the operating system from initiating automatic restarts during defined working hours.

### Policy Area 

Policies > Windows > Patches & Updates > Windows Update Experience

### Key Configuration Elements 

**Active Hours Definition** Administrators specify the daily work window during which automatic restarts are blocked. Example configuration:

- Start time: 08:00
- End time: 18:00

During this period, the operating system suppresses any reboot triggered by update installation.

**Restart Readiness Validation** Restart checks can be configured to ensure the device is idle before a reboot is allowed. This validation should be applied only outside business hours, preventing forced restarts when the system is actively in use.

2. Staged Deployment and Maintenance Window Scheduling 
-------------------------------------------------------

### Objective 

Validate patch behavior and reboot impact before large scale deployment.

### Deployment Model 

Instead of deploying updates to all devices simultaneously, a phased rollout model is recommended.

**Pilot Phase** Updates are first applied to a limited set of IT managed or test devices. This stage helps identify reboot behavior, application conflicts, and stability issues early.

**Scheduled Execution** Using rule-based workflows from the Automate section, administrators can restrict patch execution to off hours.

Typical scheduling parameters include:

- Execution days limited to weekends
- Execution time set to early morning hours such as 02:00

This ensures both patch installation and any resulting reboot occur well outside normal operating hours.

3. User Controlled Restart Postponement 
----------------------------------------

### Objective 

Reduce productivity loss when updates are deployed during the workweek.

When immediate patch deployment is required, control can be shifted from the system to the end user through configurable postponement options.

CapabilityConfiguration AreaOperational OutcomeRestart notificationsPatches & Updates > Windows Update Experience > NotificationsUsers are informed that a restart is pendingRestart deadlineUpdate deadline set to 3 to 7 daysUsers receive a grace period to plan the restartPause and defer optionsAllow users to pause updates or restartsUsers can delay reboots during meetings or critical tasksThis approach balances security enforcement with user autonomy, reducing frustration, and unplanned downtime.

4. Advanced Restart Control Using Custom Scripts 
-------------------------------------------------

### Objective 

Enable granular reboot scheduling beyond standard policy capabilities.

For environments requiring precise control over reboot timing, custom scripts can be executed remotely.

### Windows Based Devices 

A PowerShell script can be used to register a scheduled task that triggers a reboot at a predefined off hour time.

Example logic:

- Detect pending restart conditions
- Create a scheduled task
- Execute a reboot command at a fixed late-night timestamp

This method ensures reboots occur only when explicitly scheduled by IT.

### macOS Devices 

macOS devices support queued restarts using native system commands. A restart can be scheduled for late night hours using the shutdown command executed remotely through the console.

This provides parity in reboot control across platforms where native policy options may differ.

Outcome and Operational Impact 
-------------------------------

By combining policy-based controls, scheduled workflows, and optional scripting, administrators can achieve:

- Zero unexpected reboots during business hours
- Predictable patch behavior across device fleets
- Reduced helpdesk tickets related to forced restarts
- Higher user trust in update operations

This structured approach transforms patch reboots from a disruptive risk into a controlled maintenance activity.