Intune Maintenance Windows: Preventing Unplanned Reboots & Ensuring Compliance on Production Endpoints
Unscheduled Windows Update reboots on critical production endpoints like manufacturing equipment, kiosks, or shared workstations directly impact operational continuity. Existing update policies, such as active hours or deferrals, often fall short of reliably enforcing restart windows for all update types or specific device groups. Intune's Maintenance Windows feature, now a robust capability in 2026, provides the granular control necessary to dictate precisely when automatic update actions—download, installation, and restart—can occur, mitigating disruption and ensuring compliance.What We're Building & Prerequisites
We are implementing a recurring weekly maintenance window policy in Microsoft Intune to restrict Windows Update installation and restart actions to a specific, predefined schedule. This ensures that critical devices remain operational during business hours while maintaining security patch levels.| Requirement | Detail | Status |
|---|---|---|
| Intune Licensing | Microsoft 365 E3/E5, Enterprise Mobility + Security E3/E5, or Microsoft Intune Plan 1 | ✓ |
| Entra ID Roles | Intune Administrator or Policy and Profile Manager | ✓ |
| Microsoft Graph Scopes | DeviceManagementConfiguration.ReadWrite.All |
✓ |
| Target OS Build | Windows 11, version 24H2 with KB5077181 (build 26100.7840) or later | ✓ |
| Device Enrollment | Devices must be enrolled in Intune (MDM managed) | ✓ |
Step-by-Step Implementation (Intune Admin Center)
This procedure outlines creating a maintenance window policy via the Intune portal. We'll configure a weekly overnight window, allowing downloads anytime but restricting installation and restarts to the scheduled period.-
Navigate to Maintenance Windows:
Sign in to the Microsoft Intune admin center.
Go to Devices > Manage devices > Maintenance windows.
Click .
-
Basics Configuration:
On the Basics tab, provide a descriptive name and optional description:
- Name:
Contoso - Weekly Kiosk Update Window - Description:
Enforces weekly update installation and restart for critical kiosk devices every Sunday 23:00 to Monday 03:00 local time.
Click .
- Name:
-
Configure Settings:
On the Configuration settings tab, expand Maintenance Windows:
- Workload type: Select
Updates. This ensures the policy applies specifically to Windows Update actions. - Enable Maintenance windows: Set to On.
- Update action: Select
Install and restart. This allows devices to download updates during operational hours, but critically, defers the installation and subsequent restart until the defined window. Choosing "Download, install and restart" would block downloads too, which might not be optimal for bandwidth distribution. "Restart only" is useful if installations are managed separately.
- Workload type: Select
-
Define the Schedule:
Configure the schedule settings precisely:
- Repeat schedule: Select
Weekly. - Weekly – Day selection: Check Sunday. This targets the specified day for the maintenance window.
- Start date: Enter a date in
YYYY-MM-DDformat (e.g.,2026-11-16). While Windows uses the recurring pattern for weekly schedules, a start date is mandatory for policy creation. - Duration (hours): Enter
4. This sets the window from 23:00 to 03:00 (4 hours). The minimum duration is 2 hours, maximum 24 hours. - Start time: Enter
23:00. This is local device time, ensuring consistency across different time zones.
Click .
- Repeat schedule: Select
-
Scope Tags and Assignments:
On Scope tags, add any relevant administrative scope tags for your organization, then click .
On Assignments, assign the policy to your target Entra ID device group (e.g.,
Contoso-KioskDevices). Always test with a small, representative group first, then expand. Click . -
Review and Create:
On Review + create, verify all settings. Click to deploy the policy.
Automated / Scripted Alternative (Microsoft Graph PowerShell)
For large-scale deployments or CI/CD pipelines, leveraging Microsoft Graph PowerShell is essential. This script creates a similar weekly maintenance window policy programmatically.Connect-MgGraph -UseDeviceAuthentication for reliable MFA prompt support across Cloud Shell and headless administration servers.# Required Scopes: DeviceManagementConfiguration.ReadWrite.All
# Ensure Microsoft.Graph module (v2.x.x) is installed: Install-Module Microsoft.Graph -Force
# Connect to Microsoft Graph with required scopes
Connect-MgGraph -Scopes "DeviceManagementConfiguration.ReadWrite.All"
# --- Parameters for the Maintenance Window Policy ---
$PolicyName = "Contoso - Automated Weekly Kiosk Updates"
$PolicyDescription = "Automated weekly update installation and restart for critical kiosk devices via Graph. Sunday 23:00 - Monday 03:00 local time."
$TargetGroupDisplayName = "Contoso-KioskDevices" # Display name of the Entra ID device group
# Get the target Entra ID device group ID
try {
$TargetGroup = Get-MgGroup -Filter "DisplayName eq '$TargetGroupDisplayName'" | Select-Object -First 1
if (!$TargetGroup) {
Write-Error "Target group '$TargetGroupDisplayName' not found."
exit 1
}
$TargetGroupId = $TargetGroup.Id
} catch {
Write-Error "Failed to retrieve group ID: $_"
exit 1
}
# Define the maintenance window schedule payload
$MaintenanceWindowSchedule = @{
@odata.type = "#microsoft.graph.windowsUpdateScheduledMaintenanceWindow"
durationInHours = 4
recurrenceType = "weekly"
startDateTime = "2026-11-16T23:00:00Z" # UTC, but policy applies to device local time. Actual start date for recurring is ignored.
updateAction = "installAndRestart" # Options: downloadInstallAndRestart, installAndRestart, restartOnly
weeklySchedule = @{
@odata.type = "#microsoft.graph.windowsUpdateWeeklySchedule"
dayOfWeek = "sunday"
}
workloadType = "updates"
}
# Construct the device configuration policy body
$PolicyBody = @{
@odata.type = "#microsoft.graph.deviceConfiguration"
displayName = $PolicyName
description = $PolicyDescription
deviceManagementConfigurationSettingCollection = @(
@{
@odata.type = "#microsoft.graph.deviceManagementConfigurationSetting"
settingInstance = @{
@odata.type = "#microsoft.graph.deviceManagementConfigurationSettingInstance"
definitionId = "windowsUpdateScheduledMaintenanceWindow_1" # This is the OMA-URI based setting ID for Maintenance Windows
settingValue = @{
@odata.type = "#microsoft.graph.deviceManagementConfigurationComplexSettingValue"
value = $MaintenanceWindowSchedule
}
}
}
)
}
# Create the device configuration policy
try {
Write-Host "Creating Intune device configuration policy '$PolicyName'..."
$NewPolicy = New-MgDeviceManagementDeviceConfiguration -BodyParameter $PolicyBody -WhatIf
if ($NewPolicy) {
Write-Host "Policy created successfully with ID: $($NewPolicy.Id)"
# Assign the policy to the target group
Write-Host "Assigning policy '$($NewPolicy.DisplayName)' to group '$TargetGroupDisplayName'..."
$AssignmentBody = @{
@odata.type = "#microsoft.graph.deviceConfigurationAssignment"
target = @{
@odata.type = "#microsoft.graph.deviceAndAppManagementAssignmentTarget"
deviceAndAppManagementAssignmentTargetType = "group"
groupId = $TargetGroupId
}
}
New-MgDeviceManagementDeviceConfigurationAssignment -DeviceConfigurationId $NewPolicy.Id -BodyParameter $AssignmentBody -WhatIf
Write-Host "Policy assignment initiated."
}
} catch {
Write-Error "Failed to create or assign policy: $_"
exit 1
}
Disconnect-MgGraph
-WhatIf on New-MgDeviceManagementDeviceConfiguration and New-MgDeviceManagementDeviceConfigurationAssignment. Remove this parameter only after thorough testing in a non-production environment to apply changes.
Validation & Fleet Verification
After policy deployment, confirming its application and enforcement on endpoints is critical.-
Intune Admin Center Status:
Navigate to Devices > Manage devices > Maintenance windows and select your policy.
Review Device and user check-in status and Per setting status. Ensure devices show a "Success" state. This confirms policy reception, not necessarily enforcement.
-
Client-Side Event Log Inspection:
On a target Windows 11 endpoint, open Event Viewer (eventvwr.msc).
Navigate to Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin.
Look for Event IDs related to policy application (e.g., Event ID 814, 865) indicating the OMA-URI for the Update Policy CSP has been processed. Search for entries containing
./Vendor/MSFT/Policy/Config/Update/ScheduledMaintenanceWindow. -
Registry Inspection:
The Maintenance Window policy settings are reflected in the registry under the Device Management CSP path.
Open Registry Editor (regedit) and navigate to:
HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device\Update
You should find values pertaining to
ScheduledMaintenanceWindowthat reflect your Intune configuration. -
Intune Management Extension Logs:
For additional detail on policy processing by the Intune Management Extension (IME), check the log file:
%ProgramData%\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log
Look for entries indicating the application of Device Configuration policies and any potential errors related to the Update CSP.
-
Windows Update Logs:
To confirm actual update activity during the window, use PowerShell to analyze Windows Update logs:
⚠️ State-Changing Action Script: This script modifies tenant or device configurations. Always test in a non-production pilot group first. Supports-WhatIfwhere applicable.# Get Windows Update Logs (requires admin privileges) Get-WindowsUpdateLog -LogPath "C:\Temp\WindowsUpdate.log" Invoke-Item "C:\Temp\WindowsUpdate.log" # Open the generated log file # Or directly query Event Log for Update Orchestrator activity Get-WinEvent -LogName "System" -FilterXPath '*[System[(EventID=19 or EventID=20)]]' | Select-Object -First 20 | Format-List -Property TimeCreated,Id,MessageCorrelate installation and restart timestamps with your configured maintenance window, accounting for the device's local time zone.
Gotchas & Edge Cases
Maintenance windows primarily control *automatic* update actions. However, policies like Expedited Quality Updates (e.g., for out-of-band zero-day patches) or expired Update Deadlines with grace periods will take priority and can force updates and restarts outside the defined window. Always consider the full update policy stack.
Maintenance windows do not prevent users from manually initiating update checks, downloads, or installations via Windows Settings (Settings > Windows Update) if other policies (e.g., disabling user access to Windows Update) are not in place. For true lockdown, consider combining maintenance windows with additional settings catalog policies to restrict user interaction.
All maintenance window times are interpreted based on the device's local time zone. This is a powerful feature for globally distributed fleets but requires careful planning. A 23:00 start time in London will be 23:00 in London, and 23:00 in New York for devices in those respective time zones. Avoid miscalculating cross-timezone synchronization if your policy assumes a single UTC enforcement time.
A maintenance window only governs *when* an update action can begin if an update is already *available* to the device. If an update is still deferred by another policy (e.g., a 7-day quality update deferral), it won't be offered to the device even if a maintenance window occurs. The window will only apply once the deferral expires and the update becomes available.
An update action (download, install, restart) that *begins* during the maintenance window can continue and complete *after* the window ends. The policy strictly dictates the *initiation* of the action within the scheduled period, not its guaranteed completion before the window closes. Ensure your duration is adequate for typical update cycles.