Windows Auto Patch stuck in progress and rebooting inside Active HoursSolved

Participant
Discussion
1 month ago Sep 20, 2026

I’m testing Auto Patch on a Windows pilot device and ran into two related issues.

Several app update tasks, including browsers and utilities deployed through winget, stayed in In progress for a long time. The Hexnode agent itself looked healthy because actions like Scan Device and Scan for Updates completed quickly. Winget was also working manually from the device, and the same packages updated successfully when run locally.

After the device restarted, one of the pending app updates completed, so it looks like the installer was waiting because the application was open and files were locked.

The bigger concern is reboot timing. We have the App Updates policy set to run Outside of device’s Active Hours, but a third-party app update completed during working hours and triggered a 5-minute restart countdown. There was no separate restart action configured in the automation.

I’m trying to understand:

1. Can Auto Patch stay in progress while the app is open?
2. Does “Outside of device’s Active Hours” control only the installation, or the reboot too?
3. Where do we configure a fixed maintenance window for app patches?
4. Does the Windows Update Experience policy control reboots from app patches?

Replies (1)

Marked SolutionPending Review
Hexnode Expert
1 month ago Sep 20, 2026
Marked SolutionPending Review

Hi @remy,

Welcome to the Hexnode Community.

For Windows Auto Patch tasks, an app update can remain in In progress if the installer cannot replace files because the target application is currently running. In that case, the task may complete only after one of the following happens:

– The user closes the application.
– The device restarts and releases the locked files.
– The underlying installer or execution process reaches its timeout.

This can make the task look stuck even though the agent is still responsive. If actions such as Scan Device or Scan for Updates complete successfully, agent communication is likely healthy and the issue is more likely tied to the app installer execution or file locks.

For scale deployments, maintenance windows are the recommended approach so app updates run during off-hours when the affected applications are less likely to be open.

The fixed maintenance window is configured in the Windows App Updates policy, not in the Auto Patch automation rule itself. On Hexnode UEM portal, go to: Policies > Windows > Patches & Updates > App Updates > Maintenance Window

From there, choose Maintenance Window and define the required days and start/end times, such as a weekend or overnight patching window.

The Auto Patch automation does not define the window. Its Override Maintenance Windows option only decides whether the automated patch action respects or bypasses the maintenance window configured in the policy.

Regarding Active Hours: Outside of device’s Active Hours controls when Hexnode initiates the app patch installation. It does not necessarily suppress a reboot triggered directly by a third-party installer after the installation completes.

Regards,
Sienna Carter
Hexnode UEM

Save