# Maintenance Windows & Patch Scheduling Reference in Hexnode UEM Executive Summary ----------------- This document consolidates all patch and deployment scheduling behavior in Hexnode UEM into a single reference. Moving away from scattered per-policy settings and separate automation triggers, Hexnode UEM treats the Maintenance Window as a central, first-class object. Maintenance Windows govern when disruptive actions—such as patch installations, app updates, and reboots—are permitted to execute on a device. This page defines the strict operational hierarchy (where deadlines outrank Maintenance Windows, and grace periods govern only the reboot) and establishes explicit conflict resolution rules for devices targeted by multiple scheduled policies. 1. The Maintenance Window Object -------------------------------- A Maintenance Window defines a recurring span of time during which disruptive actions may execute on member devices. Maintenance Windows are designed as reusable objects: you define a Maintenance Window once and attach it to any number of patch policies, app deployments, or actions. [![Screenshot of Hexnode UEM console showing the Maintenance Window configuration settings under the App Updates policy. The interface displays options to set scheduled days and a scheduled time frame. The Auto-update preference is set to 'Update targeted apps only' alongside an 'Add Apps' button.](https://cdn.hexnode.com/mobile-device-management/help/wp-content/uploads/2026/08/Maintenance-Windows-configuration-under-App-Updates-policy.png)](https://cdn.hexnode.com/mobile-device-management/help/wp-content/uploads/2026/08/Maintenance-Windows-configuration-under-App-Updates-policy.png) PropertyDescription**Name**Unique identifier, referenced by policies.**Time span**Start and end time (may cross midnight, e.g., 22:00–04:00).**Recurrence**Daily, weekly, or monthly calendar pattern.### What a Maintenance Window does NOT control: - **Content delivery:** Downloads and [DAFS](https://www.hexnode.com/mobile-device-management/help/distribution-server-for-windows/) (Distributed Apps and Files Server) pre-staging happen ahead of the Maintenance Window. Maintenance Window hours are spent installing, not downloading. - **Scans and inventory:** Detection of missing patches runs on its normal scheduled cadence. - **Non-disruptive actions:** Policy evaluation, messaging, and compliance checks remain unaffected. 2. Timezone Handling for Global Fleets -------------------------------------- Hexnode UEM evaluates Maintenance Windows exclusively against each device’s local OS clock. **Device-Local Execution:** A “Weeknights 22:00–04:00” Maintenance Window patches a device in London at London’s 22:00 and a device in Sydney at Sydney’s 22:00. This achieves a global, follow-the-sun overnight patch cycle using a single configuration, requiring zero regional policy duplication. (Note: Hexnode UEM does not support fixed-timezone absolute cutovers; schedules always adapt to the endpoint’s local time). ### Edge Cases: - **DST transitions:** Maintenance Windows are evaluated against local wall-clock time. A 22:00 Maintenance Window opens at 22:00 on both sides of a Daylight Saving Time change. It does not double-fire on fall-back. - **Travel (Timezone changes):** If a device changes timezones mid-window, the current Maintenance Window instance completes under the timezone in which it opened. The next instance will use the new timezone. - **Midnight crossing:** A Monday 22:00–04:00 Maintenance Window runs into Tuesday morning, but counts strictly as Monday’s occurrence. 3. Recurrence cycles -------------------- Hexnode UEM supports complex, real-world calendar logic for maintenance cycles. PatternOptions**Daily**Every day, or weekdays/weekends only.**Weekly**Selected weekdays (e.g., Tuesday + Thursday).**Monthly (by date)**A specific calendar date (e.g., the 15th of the month).**Monthly (by ordinal weekday)**e.g., “Second Tuesday” to seamlessly align with Microsoft’s Patch Tuesday for Windows devices. Supports offsets (e.g., “Second Tuesday + 3 days” for vendor release soaking).4. The Enforcement Hierarchy ---------------------------- Administrators frequently configure Maintenance Windows, Deadlines, Grace Periods, and Forced Reboots. In Hexnode UEM, their relationship is an unbreakable hierarchy: - **The Maintenance Window governs routine installation.** While a patch is before its deadline, installation attempts occur only inside an open Maintenance Window. If a device is offline or busy, it retries in the next occurrence. - **The Deadline overrides the Maintenance Window.** Once a deadline passes (e.g., 7 days from patch availability), the install proceeds at the next opportunity regardless of Maintenance Windows. A deadline is the ultimate security backstop; if the two conflict, the deadline always wins. - **The Grace Period governs the reboot, not the install.** After an install finishes, the grace period is the span during which the user is notified and may postpone the reboot. The install has already happened; only the restart is negotiable. - **Forced Reboot ends the negotiation.** When the grace period expires, the device reboots. If reboot enforcement is scoped to a Maintenance Window, it waits for the next Maintenance Window; otherwise, it executes immediately. ### Worked Example **Policy Setup:** Maintenance Window = Weeknights 22:00–02:00; Deadline = 7 days; Grace Period = 24 hours. **Sequence of Events:** - **Days 1–6 (Pre-Deadline):** The laptop is shut down every night. No Maintenance Window occurrence succeeds. - **Day 7, 14:30 (Deadline Passes):** The install executes immediately during work hours. The Maintenance Window no longer applies. - **14:30 to Next Day (Grace Period Active):** The user sees reboot prompts and utilizes their grace period to postpone the restart and keep working. - **24-Hour Mark (Forced Reboot):** The grace period expires, triggering an immediate, un-deferrable forced reboot. 5. Conflict Resolution (Multiple Policies on One Device) -------------------------------------------------------- When multiple scheduled policies target the same device, Hexnode UEM resolves conflicts deterministically—never by chance of sync order. - **Maintenance Windows combine for eligibility:** The device is eligible for each policy’s actions during that policy’s attached Maintenance Windows. Maintenance Windows do not cancel each other out; a device covered by a “Servers” Maintenance Window and a “Finance” Maintenance Window is simply eligible during both. - **Strictest deadline wins:** If two policies target the same patch with different deadlines, the earlier deadline governs per patch. - **Reboots are consolidated:** If multiple policies complete installs in the same Maintenance Window and require restarts, the device reboots once after the final install, honoring the shortest applicable grace period. - **Automate workflows:** Workflows that explicitly trigger an “install now” command are treated as deadline-class actions and execute immediately. To make automation respect Maintenance Windows, the workflow’s action must target the policy (which carries the Maintenance Window) rather than the raw install command. 6. Default Templates -------------------- To simplify scheduling, Hexnode UEM provides standard templates for common deployment scenarios: TemplateDefinitionIntended use**Overnight**Daily 22:00–04:00General fleets, follow-the-clock global patching.**Patch Tuesday +3**Monthly, 2nd Tuesday + 3 days, 20:00–06:00OS updates for Windows devices after vendor-release soak.7. Troubleshooting ------------------ - **A patch installed during business hours despite the Maintenance Window.** Almost always, the deadline had passed—check the patch’s deadline against its availability date. Relative deadlines (“7 days from availability”) often start earlier than admins expect. The second most common cause is an Automate workflow triggering the raw install action, which ignores Maintenance Windows. - **Device rebooted twice in one night.** Check whether one of the involved policies enforces a reboot outside the Maintenance Window scope while another consolidates within it. Mixed “Scope of enforcement” settings across policies prevent reboots from being consolidated. - **Maintenance Window never seems to fire for some devices.** Verify the device’s OS timezone is correct. Because Hexnode UEM trusts the OS clock, a device with an incorrect timezone offset will open its Maintenance Window at the wrong real-world time. - **Installs pile up in the first minutes of the Maintenance Window and saturate the site link.** Confirm DAFS pre-staging is active for the site. If devices are downloading at window-open, delivery scheduling isn’t completing before the Maintenance Window begins.