Build Update Manager maintenance window configs with patch classifications, dynamic scoping, and pre/post-patch tasks.
Build Update Manager maintenance window configs with patch classifications, dynamic scoping, assessment schedules, and pre/post-patch tasks.
Required Fields
maintenanceConfigurationNameresourceGroupmaintenanceWindow.startDateTimemaintenanceWindow.durationmaintenanceWindow.recurEveryinstallPatches.rebootSettingOutput will appear here...The builder validates that maintenanceConfigurationName, resourceGroup, maintenanceWindow.startDateTime, maintenanceWindow.duration, maintenanceWindow.recurEvery, and installPatches.rebootSetting all resolve before accepting the JSON as a valid maintenance configuration; it can't verify the referenced Automation Runbooks actually exist and complete successfully, or that dynamicScoping's tag filters will match the intended set of machines, those are only confirmed when a real maintenance run actually executes.
Build an Azure Update Manager maintenance configuration combining a recurring maintenanceWindow, classification-based patch selection (installPatches with separate windowsParameters and linuxParameters, since Windows update classifications and Linux package classifications are genuinely different taxonomies), dynamicScoping that automatically includes matching VMs by tag/resource-group/location rather than a static machine list, and pre/post Automation Runbook tasks. dynamicScoping's tagFilters using both In and NotIn operators (patchGroup In [production-wave1] AND environment NotIn [sandbox, dev]) means new VMs matching the criteria are automatically included in future patch runs the moment they're tagged correctly, without anyone updating this configuration, which is the entire point of dynamic over static scoping, but also means a VM incorrectly tagged (or having its tags changed) silently drops in or out of the patch schedule without an explicit, reviewable change to this configuration.
Treat dynamicScoping's tag-based inclusion/exclusion as a real, consequential control surface, a tag added or removed elsewhere (by a deployment pipeline, a manual change) directly changes what gets patched, without a corresponding change to this configuration, audit tag hygiene on the criteria this scoping depends on.
Always populate both windowsParameters and linuxParameters appropriately for a maintenance configuration covering a mixed-OS fleet, they're independent classification taxonomies, not a shared list, an empty or default linuxParameters block on a config meant to also patch Linux VMs silently patches nothing on that OS.
Wire pre/post tasks to actually gate on failure where that matters, a health-check runbook that logs a failure but doesn't block the subsequent patch step provides visibility but not the safety guarantee its presence implies.
Yes, that's the specific behavior dynamicScoping provides, tag-based scoping is evaluated at each maintenance run, not fixed at configuration creation time, so a VM whose tags change to match (or no longer match) the configured tagFilters automatically joins or leaves the patch scope on the next run, without anyone needing to edit this configuration directly. This is powerful for scaling patch management automatically but means a tag change elsewhere (in a deployment pipeline, say) has a direct, sometimes non-obvious effect on what gets patched.
No, they're genuinely different, Windows classifications include values like Critical, Security, and UpdateRollUp reflecting Windows Update's own categorization, while Linux classifications (Critical, Security in the example) reflect the distribution's package classification scheme, which is why installPatches has entirely separate windowsParameters and linuxParameters blocks rather than one shared classification list, a configuration covering both OS types needs both blocks populated appropriately for each.
Depending on how the runbook and the pre-task wiring are configured, a failed pre-task can block the actual patch installation from proceeding, this is exactly the value of the preTasks pattern, catching a problem (like a service already in an unhealthy state) before compounding it with an actual patch/reboot cycle. Verify your specific pre-task's failure behavior is wired to actually gate patching, rather than just logging a failure and proceeding anyway.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.