Once the rings are running, patching stops being a project and becomes a loop, and the loop is where the product’s honest limits show. You get seven days of assessment history, thirty days of installation history, and alerting that has been in preview for the better part of three years. Every estate I have seen run this seriously ends up building the same small scaffolding around it, out of the same four or five parts, for the same reasons. Knowing that in advance is the difference between planning an afternoon and discovering a hole in an audit.
Where the data actually lives
Every operational decision in this article follows from one architectural fact, so it is worth stating before anything else. Update Manager writes its results into Azure Resource Graph. Not into a Log Analytics workspace, not into an Automation account, and not into a storage account you nominate. Two tables, both queryable from Resource Graph Explorer or any of the graph clients: patchassessmentresources for what is pending, and patchinstallationresources for what happened during a run.
That matters more than it sounds, because there is a decade of Azure patching advice written against a product that no longer exists. Automation Update Management wrote to Log Analytics, and estates built their compliance reporting on top of the Update, UpdateSummary and UpdateRunProgress tables in a workspace. Those tables went away with the product that populated them. If you inherit a runbook, a workbook or a Sentinel rule that queries any of them, it is not broken and it is not misconfigured. It is describing a world that ended, and the honest fix is to rewrite it against Resource Graph rather than to debug it.
The upside is real and I do not want to undersell it. Resource Graph costs nothing, requires no workspace to size and no ingestion to budget, and answers queries across every subscription your identity can read. For a ten server estate that means the entire reporting surface is available on day one with nothing deployed. The downside is retention, and retention is the rest of this section.
Seven days and thirty days
Pending updates are retained for seven days. Installation results are retained for thirty. Those are not throttles or defaults you can raise on a support call. They are the retention of the store, and Microsoft publishes them as such.
Do the arithmetic against a monthly patch cycle and the shape of the problem appears immediately. A machine patched on the second Tuesday has its installation record until roughly the twelfth of the following month, which means there is a window of a few days each cycle in which last month’s evidence has expired and this month’s has not yet been created. Any question of the form “show me that this server has been patched every month this year” cannot be answered from the product at all. Not with difficulty. At all.
Microsoft’s own architecture guidance says the quiet part plainly: if your workload must retain patch history longer than Resource Graph provides, build a process to export the data to a store that you control. I have a lot of time for that sentence, because it declines to pretend. It also hands you a piece of work, and the work is not difficult but it is yours, it needs an owner, and it needs to exist before the first thing you want to prove happened more than thirty days ago.
Seven days and thirty days is not a reporting system. It is a buffer, and buffers exist to be drained by something.
If nobody in your organisation has ever asked for patch evidence going back a year, you can defer this and I will not pretend otherwise. But be honest about who is deferring it. The auditor asking that question in eighteen months is not going to accept an explanation about retention windows, and the person who has to answer them will not be the person who decided to skip the export. That is a normal way for infrastructure debt to be created and it is worth naming while it is still a choice.
Alerting, nearly three years in preview
Update Manager’s alerting entered preview in November 2023 and the page is still titled with the word preview today. I am not going to editorialise about Microsoft’s release cadence, but I am going to tell you what that means for a design decision, because a capability that has sat in preview for the better part of three years is not something to make load-bearing, and it is also not something to ignore, since it works and it is free.
The mechanism is worth understanding because it explains the constraints. There is no dedicated alerting engine here. What Update Manager gives you is an entry point that builds an ordinary Azure Monitor alert rule whose signal is a Resource Graph query, either one of the predefined ones or your own. Everything downstream is standard Azure Monitor: action groups, severities, evaluation frequency, automatic resolution. The alert rule is an Azure resource in a resource group of your choosing and it outlives any of the Update Manager surfaces you created it from.
Three constraints follow directly. The rule needs a managed identity holding Reader on the resources you want it to see, which is not automatic and is the single most common reason a rule that looks correct never fires. The query returns a maximum of one thousand rows, and the documentation notes separately that the query only ever returns what that identity has access to, so an alert can be silently scoped smaller than you think by a role assignment nobody remembers making. And the whole capability is unavailable in Azure US Government and Azure operated by 21Vianet, which for most readers is trivia and for a few is the end of the conversation.
The row ceiling deserves a moment because it fails in the direction that hurts. A thousand rows is enormous for ten servers and unremarkable for two thousand, and the failure mode is not an error. The query returns its thousand rows, the rule evaluates against them, and the machines beyond the ceiling are simply not considered. An alert that is quietly evaluating a subset of your estate looks exactly like an alert on a healthy estate. The mitigation is not clever: write alert queries that aggregate or filter hard rather than returning per-update rows, and keep the alert scoped to something you can reason about.
The workbook is the compliance surface
Alongside the queries there is a built-in workbook, and it is better than the words “built-in workbook” usually promise. Out of the box it covers the overall status and configuration of your machines, an overview of update data, the schedules and maintenance configurations with the machines attached to each, and the history of installation runs. A general availability release in August 2025 split that into separate views for overall compliance, recommendations, pending updates, update history, schedules and operation history.
Two properties make it the right place to point a non-engineer. It works across subscription boundaries, which matters the moment your Arc machines and your Azure machines are not in the same place. And it is editable, which means the compliance report your auditor or your change board actually wants is a fork of the shipped one rather than a project. If you customise it, put the definition in source control with the rest of your infrastructure, because a workbook that exists only in a portal is one careless edit from being an afternoon of rework.
What the workbook does not do is retain anything. It renders the same seven and thirty day windows the queries do, prettily. It is a surface, not a store, and treating it as evidence is the most common way people convince themselves the export is not needed.
Pre and post events, and the machine that was off
The one piece of operational machinery here that is properly general available, and has been since August 2024, is pre and post events. Event Grid sits on the maintenance configuration and emits Microsoft.Maintenance.PreMaintenanceEvent before the window and Microsoft.Maintenance.PostMaintenanceEvent after the installation completes. You handle them with whatever Event Grid handles: a webhook into an Automation runbook, an Azure Function, a storage queue, an Event Hub.
The canonical documented use case is the first row of Microsoft’s own table of sample tasks, and it is exactly this estate’s problem: turn on the machines before patching, turn them off afterwards. That is not a contrived example. Periodic assessment only assesses machines in a running state, a scheduled run simply skips a machine that is not there, and the result is a ring that reports a clean cycle while one of its members has not been patched in a quarter. If you have any machine that is deliberately or accidentally off at three in the morning, the pre-event is not an optimisation. It is the thing that makes the ring’s success honest.
The timing rules around this are unforgiving enough that they change how you operate the schedule, which is why I am putting them in a doctrine article rather than leaving them to the build sheet. The pre-event fires at least thirty minutes before the window opens. If you have more than one, all of them must complete inside twenty minutes. Creating or editing a schedule that carries a pre-event requires at least forty minutes of lead time before the window start, and if you are inside that, the upcoming run auto-cancels rather than proceeding. So attaching a pre-event to a maintenance configuration converts an ordinary schedule edit into something with a cutoff, and the cost of forgetting is a skipped patch cycle that nobody was alerted about.
The cancellation semantics are the part people get wrong, and Microsoft states it in a way that leaves no room for interpretation. You must initiate cancellation as part of the pre-event. Update Manager and maintenance configuration will not automatically cancel the schedule. If you fail to cancel, the schedule run proceeds. Read that as a design statement rather than a caveat: a pre-event is not a gate, it is a notification with an optional response. If your pre-event is meant to abort the run when a precondition fails, somebody has to write that abort, and the cancellation call has to land at least ten minutes before the window. A pre-event that fails silently does not stop anything.
One more property that shapes the handler rather than the schedule: Event Grid delivers at least once, so a handler will occasionally run twice for the same event. Anything that starts a machine, snapshots a disk, stops a service or writes a record has to be safe to run twice, and the cheapest way to get that is to make the handler check the current state before acting rather than assuming its own delivery is unique.
Four things that are true whatever the console says
What follows is not documentation. These are convergences from the field, mine and other people’s, and I state them as generalisations rather than as citations. They are also the most valuable paragraphs in this article, because every one of them describes a green console over a machine that is not being patched, and every one of them reduces to the same sentence this series has been repeating since the anchor: Update Manager orchestrates, and the local Windows Update agent executes.
Extension health is not update source health. An Arc Windows machine carries two extensions, one for periodic assessment and one for on-demand and scheduled operations, and both can sit at Succeeded on a machine that has installed nothing for a year. Succeeded means the extension did its job, which is to drive the Windows Update client and report what came back. If the client is pointed at a WSUS server with nothing approved, or at a WSUS server it can no longer reach, or is blocked from the internet by a policy nobody remembers enabling, the extension reports success on an assessment that found nothing to do. Extension state answers whether the orchestrator is working. It says nothing whatsoever about whether the content path is.
Connected is a claim about a heartbeat. The Arc status tells you the Connected Machine agent is talking to Azure. It does not tell you the assessment pipeline recovered from whatever knocked it over. A machine that has been disconnected for a week and comes back will show Connected long before it shows a current assessment, and in the intervening period the compliance view is reporting stale data with a healthy-looking status next to it. If you build one alert beyond the failure alert, build the one that looks for machines whose last assessment is older than it should be, because that is the failure that presents as silence.
Both extensions can report Succeeded on a machine that has not installed a patch in a year. The console is telling you the truth about the wrong thing.
A window too short for a cumulative update skips it, and does not shout. Windows reserves ten minutes of the maintenance window for the reboot, and an update will not be started unless enough of the window remains, fifteen minutes for an ordinary update and twenty for a service pack. A cumulative update on an older server routinely wants more wall clock time than that arithmetic assumes. The run ends inside its window, the ring reports completion, and the update that mattered was never attempted. This is why the exit criterion this series set for the cutover is a full successful cycle verified in the installation records rather than a run that reported success. Those are different statements and only one of them is evidence.
And Never reboot is not a guarantee, particularly on an Arc machine. Microsoft documents the general caveat plainly, that a reboot can occur even when you specify never reboot, because the Windows Update registry keys can force one. On an Arc machine that caveat has more force, because Update Manager does not write to the registry there at all and Group Policy fully controls update behaviour. The reboot option in the maintenance configuration is an instruction to the orchestrator, and the orchestrator is not the authority on this machine. If a domain policy is going to restart your domain controller, it will, and your schedule will record the outcome rather than prevent it.
What the loop is actually made of
Put together, the operating surface of this product is four things you build and one you inherit. You inherit the workbook. You build a handful of Resource Graph queries that answer the questions people actually ask, an alert that fires when a run fails, an export that survives the thirty day cliff, and, if any of your machines are ever off when a window opens, a pre-event that wakes them and a post-event that puts them back.
None of that is large. All of it is invisible in a project plan that stops at the rings, which is precisely why it gets discovered rather than scheduled. If you have read the Arc series here, [ARC 5] makes the wider version of this argument about the whole management plane, and patching is only one of the capabilities that arrives with an operations bill attached.
The build sheet that follows stands all of it up: the queries with their expected output, one alert rule with the managed identity it needs, the export path, and the pre and post event pair wired against the machine in this estate most likely to be sitting dark when its window opens. Then the series closes on what the estate looks like once WSUS is gone and who owns what afterwards.
Azure Update Manager
‹ Previous: [AUM 6] The Meter and the Waivers: What Patching Costs Now
Next: [AUM 7.1] Build Sheet: The Operations Scaffolding ›
