Your Autopatch report says Up to Date and the device disagrees: reconciling cloud update reporting against on-device truth

The report says Up to Date. The engineer sitting in front of the device says it is not. One of them is wrong, and the argument usually gets settled by whoever is more senior rather than by whoever is right.

Both can be telling the truth. A cloud update report is not a live view of a device. It is a view of a batch, built from a snapshot, assembled from a diagnostic-data upload, produced by a device that had to be enrolled, reachable, configured for data collection and awake at the right moment. Every one of those is a documented dependency, and every one of them is a place where the report and the machine can legitimately diverge.

None of that is a bug. It is the architecture. Once you know what the report is actually derived from, "the portal is wrong" stops being a complaint and becomes a diagnosis with a procedure attached.

This post is about that procedure. Not what Autopatch is, and not how to configure it - just the reconciliation discipline: what the cloud report is built from, which prerequisites have to be true for a device to appear correctly in it, what Microsoft publishes about latency, and which on-device evidence overrides the report when the two disagree.

The problem: the report is a snapshot of a snapshot

The disagreement arrives in two directions, and they need different treatment.

In the first direction the portal is green and the device is behind. Somebody runs a scan by hand, finds a missing security update, and now your compliance number is a fiction. In the second direction the portal is red and the device is fine. Somebody spends a morning rebuilding an update stack that was never broken.

The second one is more expensive, because the "fix" destroys the evidence. Once you have cleared SoftwareDistribution, the agent's scan cache and its history of what it was offered are gone, and you can no longer prove which side was lying.

Before any of that can be argued, you need a build number both sides agree on. This is where most reconciliations fall over on the first step, because Windows will hand you three different answers depending on which API you ask.

Six values on one machine, four of which will mislead a script. The report's Current version column is documented as "The current version or build number of the device" - so the only on-device value you can legally compare it against is CurrentBuild joined to UBR.

Why it happens: what the cloud report is actually made of

Microsoft is explicit about the data source. For the Autopatch quality and feature update reports: "The data source for these reports is Windows diagnostic data and Microsoft Intune." For Windows Update for Business reports: it "uses Windows diagnostic data", routed into a Log Analytics workspace you own.

That single sentence is the whole story. The report is not asking your device anything. Your device pushed something, some time ago, through a telemetry pipeline, and the report is rendering a processed batch of that.

The chain, component by component

There are only a handful of moving parts, and each has a name you can check on the device.

The documented latency, in one table

Do not guess at these and do not let anyone else guess either. Microsoft publishes them.

Notice that these do not stack neatly. A device can be inside the four-hour data window and still be carrying a readiness verdict computed 23 hours ago, from an agent run that happened before the change you made. There is no single "refresh" that resolves everything at once.

The prerequisites that decide whether a device reports at all

This is the part that turns "the portal is wrong" into a fixable finding. Microsoft splits the data into two tiers, and the split is the reason a device can appear in the report while telling you almost nothing:

• "Service state and substate data are included for all devices configured for Windows quality and feature updates. No data collection configuration is required."
• "Client and substate data are collected from devices only if Windows data collection data is properly configured."

So the service always knows what it intended for a device. It only knows what the device actually did if diagnostic data is configured. A device with broken data collection does not vanish from the report - it sits there displaying the service's intention as though it were the device's state. That is the single most misleading thing a cloud update report can do.

The documented requirements to get the client side populated:

• Diagnostic data at Required or higher. Autopatch: "you must configure the Enable Windows diagnostic data collection settings from devices at the Required or higher level." WUfB reports: "At minimum, Windows Update for Business reports requires devices to send diagnostic data at the Required level (previously Basic)."
• Join type: "Devices can be Microsoft Entra joined or Microsoft Entra hybrid joined." And explicitly: "Devices that are Microsoft Entra registered only (workplace joined) aren't supported with Windows Update for Business reports."
• A servicing floor: "Installing the February 2023 cumulative update, or a later equivalent update, is required for clients to enroll into Windows Update for Business reports."
• Services configuration, also called OneSettings: "Disabling the services configuration can cause some of the client data to be incorrect or missing in reports."
• Device name opt-in, or the row arrives anonymous.
• A named set of reachable endpoints.

That last one deserves its own list, because it is where a locked-down proxy quietly breaks reporting without breaking patching. From the WUfB reports prerequisites:

Autopatch adds its own list on top - mmdcustomer.microsoft.com, mmdls.microsoft.com, devicelistenerprod.microsoft.com, login.windows.net, device.autopatch.microsoft.com, services.autopatch.microsoft.com, payloadprod*.blob.core.windows.net and *.webpubsub.azure.com - plus the blunt requirement that "The proxy or firewall must support TLS 1.2."

And Autopatch actively tests reachability rather than assuming it. The documented internet connectivity readiness check "uses the PingReply class. Windows Autopatch tries to ping at least three different Microsoft's public URLs two times each, to confirm that ping results aren't coming from the device's cache." A readiness failure there is a network verdict, not a patching verdict.

How to verify: the reconciliation procedure, in order

Step 1 - Read the report's own staleness before you read its verdict

The Quality update status report prints a "last refreshed on" date and time at the top of the page. Write it down. If the change you are investigating happened after that timestamp, you are done - the report is not wrong, it is old, and the documented refresh cycle is four hours.

While you are there, add the optional columns that turn a verdict into evidence: Intune last check-in time, Service State, Service Substate, Client State, Client Substate, Hex Error Code and Quality update Installed Time. If the client-side columns are blank while the service-side ones are populated, you already know the answer: this device is not reporting client data, and everything you are looking at is the service's intention.

Step 2 - Establish the on-device build authority

Take CurrentBuild and UBR from HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion and treat them as the only legitimate comparand for the report's Current version column. Do not use OSVersion, do not use ProductName, do not use ReleaseId. The console block in the previous section shows exactly why.

Step 3 - Ask whether the device is even capable of reporting

This is the step almost nobody does, and it is the one that most often ends the investigation. Check the diagnostic-data configuration, and check it by value name rather than by key existence.

Three things in that block will break a naive prerequisite check.

First, the value name. Microsoft's Policy CSP documents the Group Policy registry key for AllowTelemetry as Software\Policies\Microsoft\Windows\DataCollection, which is exactly where this device is configured - but the value on disk is AllowTelemetry_PolicyManager, and plain AllowTelemetry is absent from all three of the obvious locations. A script that tests for AllowTelemetry concludes "diagnostic data unconfigured" on a device where it is set to 3. Per Microsoft's own value table, 3 is Optional (Full) - two levels above the Required minimum. The device is over-configured and the check reports it as unconfigured.

Second, AllowDeviceNameInDiagnosticData is not present, and its documented default is 0 (Disabled). This device would appear in WUfB reports without a name. If your triage starts by searching the report for a hostname, you will not find this machine, and you will conclude it is not reporting - when in fact it is reporting anonymously.

Third, wlidsvc was Stopped at capture time with StartType Manual, against documentation that says "The Microsoft Account Sign-in Assistant service must also be running (wlidsvc)" and that without login.live.com "devices aren't visible in the solution". It is a trigger-start service so it may well start on demand - but "must be running" and "was not running" is exactly the kind of gap you want on the record before you start blaming the update stack.

Here is the surface worth having in a runbook. Shared parent key:

Step 4 - Prove the census actually ran and the upload actually left

Diagnostic data configuration being correct is not the same as data having been sent. Both are checkable, and neither requires a single change to the device.

The census task is the piece Microsoft names directly in the endpoint table, so LastRunTime plus LastTaskResult = 0 is the strongest cheap evidence that the inventory half of the pipeline is alive. Note that Device User has no next run time - it is trigger-driven, so a stale timestamp there is not automatically a fault.

Step 5 - Confirm the device is in the service you are reading

Reading an Autopatch report and diagnosing a device that was never registered with Autopatch is a surprisingly common way to lose a day. There is an on-device footprint for this. Microsoft documents that the post-registration readiness checks are "powered by the Microsoft Cloud Managed Desktop Extension. It's installed right after devices are successfully registered with Windows Autopatch", and that it writes its results to a specific path.

That single absent folder is a complete answer to "why is this device's Autopatch readiness status odd" - it has no Autopatch client-side component at all. Check it before you check anything else about readiness.

Step 6 - Read the package inventory, not the hotfix list

Now to the on-device truth that overrides the report. The instinct is Get-HotFix. The instinct is wrong, and Microsoft says so in the class documentation.

Four rows against 415 packages. This is not a fault - it is documented behaviour, and the wording is unambiguous: "This class returns only the updates supplied by Component Based Servicing (CBS). These updates are not listed in the registry. Updates supplied by Microsoft Windows Installer (MSI) or the Windows update site are not returned by Win32_QuickFixEngineering." The class documentation also warns that "an enumeration of this class can result in duplicates", and that InstalledOn "may use different formats" including a raw 64-bit FILETIME hex value.

Two details from that block are worth pulling out because they change how you write a compliance check.

The first is the naming. Exactly one package on this entire device is named after a KB, and it is KB5054156 - the Windows 11 25H2 enablement package. The August cumulative update is not Package_for_KB5121003; it is Package_for_RollupFix~...~26100.9168.1.19, and the servicing stack update is Package_for_ServicingStack_9156. A script that greps the package inventory for KB numbers will conclude the device has no cumulative updates installed. It has four generations of them, in a visible supersedence ladder: 1742 Staged, 8655 and 8875 Superseded, 9168 Installed.

The second is that the RollupFix version reads 26100.9168 while the OS reads 26200.9168. That is the 25H2 enablement-package model showing through: the servicing payload is still 24H2-family, and the release identity comes from the enablement package. If you are diffing package versions against build numbers, expect that offset and do not treat it as drift.

Step 7 - Read the agent's own session history

The Windows Update agent keeps its own record of every operation it performed, reachable through the COM surface in wuapi.dll. This is the closest thing to a confession you will get, and it is entirely read-only: create a Microsoft.Update.Session, get an update searcher, call GetTotalHistoryCount(), then QueryHistory().

Fifty-two failures out of 153 entries, on a device whose current state is clean and which any report would call compliant. That is what a normal fleet device looks like on the inside, and it is exactly the information a status column cannot carry.

Three things to take from it. The Samsung driver pair is a genuine transient - failed at 08:21:25, succeeded at 08:21:32 - and 0x80240016 tells you why in plain language. The KB5074109 block is a real 44-attempt download retry storm over six days. And the ClientApplicationID column matters: only 105 of the 153 entries came from MoUpdateOrchestrator. Forty-three came from Store and app acquisition clients. "153 update history entries" is not 153 OS patches, and a script that counts history rows as patch attempts will be wrong by about a third.

Decode the codes rather than pasting them into a search engine. Microsoft's error reference gives the constant names:

Step 8 - Read the event log last, and know what it cannot tell you

The operational channel is the weakest of the three on-device sources, and it is the one most people start with. Here is why that ordering is wrong.

Event 26 is the single most over-trusted line in Windows patching, and this census is why. A fully patched device emits "found 0 updates". A device excluded by a stale version pin emits the identical line. So does a device pointed at the wrong service. Seven seconds apart on this machine it reported 0, and minutes earlier it reported 1, and the day before it reported 35 - because different scan calls target different services and different criteria. The number is a property of the query, not of the device's compliance.

Note also what is absent. Events 19, 20, 43 and 44 have zero occurrences in the entire channel. If your detection logic looks for "Installation Successful" as Event 19, on this device it will never fire - not because installs are failing, but because this channel simply is not emitting that ID. Build detection on what you have measured in your own estate, not on an event-ID list from a blog post.

Channel: Microsoft-Windows-WindowsUpdateClient/Operational. Every message string below was read off the live device.

For install-stage evidence you have to leave this channel. The Setup log carries the servicing side - on this device, Event 2 ("Package <name> was successfully changed to the Staged state") appears 1301 times and Event 1 1197 times, alongside Event 4 ("A reboot is necessary before package <KB> can be changed to the Installed state") eight times. That is where "staged but not installed" becomes visible, and it is a different log to the one everyone opens.

The fix: decide which side is authoritative for which question

The fix is not making the portal agree with the device. It is deciding, once, in writing, which side answers which question - and then only ever comparing like with like.

Remediate in dependency order

1. Fix reportability before you fix patching. Diagnostic data at Required or higher, checking for both value names. Add AllowDeviceNameInDiagnosticData = 1 if you want to search by hostname. Confirm the endpoint list is allowed through the proxy - especially *v10c.events.data.microsoft.com, which the census binary needs, and login.live.com, without which "devices aren't visible in the solution". Confirm TLS 1.2 support on the proxy.
2. Fix the policy source conflict. Autopatch's readiness checks include a documented check for "Windows update policies managed via Group Policy Object (GPO)", and the verdict is blunt: "Windows Autopatch doesn't support Windows update policies managed via GPOs. Windows update must be managed via Microsoft Intune." That is checkable on the device, and on this one it is genuinely split.
3. Re-run the census, then wait one documented latency window. Not five minutes. Four hours for the data, up to 24 for a readiness verdict.
4. Only now touch the update stack - and only if the on-device evidence from steps 6 and 7 actually shows a failure.

Step 2 needs its own look, because the lab device is a textbook case. Shared parent keys:

The pin is the whole disagreement in miniature. Policy says stay on 24H2. The device is on 25H2, having been moved there in February 2026 by KB5054156, the 25H2 enablement package. The pin did not fail; it was simply overtaken, and Intune documents the reason it cannot pull the device back: "Feature update policies don't downgrade devices."

Now consider how that renders in a report. Compliance is evaluated against what the service has offered and what the device reported installing. It is entirely possible for a device to show Up to Date while running a release its own policy says it should not be on. Nothing in the status column is lying. It is just answering a different question to the one you thought you asked.

Proof it worked: a reconciled device, measured

Here is what agreement actually looks like, assembled from the read-only captures above on one real machine.

Read the top block first. The revision in the single Installed Package_for_RollupFix entry is 9168, and UBR is 9168, and the agent's last successful orchestrator entry names KB5121003 (26200.9168). Three independent sources, one number. That is what "the device is patched" looks like when it is proven rather than asserted, and it does not depend on the cloud at all.

Then read the reportability block. Diagnostic data is above the documented minimum, the census ran clean 15 minutes before capture, and telemetry uploaded successfully 82 seconds before capture. This device is capable of reporting and has recently reported. If the report still showed the wrong build, the residual explanation is latency - and the documented window is four hours, not four minutes.

Then read the disagreement block, which is the part worth keeping. Two of those three lines will make a report and a device look like they contradict each other, and neither is a fault:

• Get-HotFix will always report far fewer updates than are installed, because the class returns CBS updates only. Four against 415 is normal.
• Event 26 "found 0 updates" will appear on a healthy device and on a device excluded by a stale pin. Identical text, opposite meanings. It resolves nothing.
• The 24H2 pin against a 25H2 installation is a real configuration drift that a status column can mask entirely - and it took a registry read, not a report, to find.

The discipline is small and it holds. Read the report's staleness before its verdict. Read the device's build from the registry, never from OSVersion. Establish whether the device can report before deciding whether it did. Prefer the package inventory and the agent's own history over the hotfix list and the event log. And when the two sides still disagree after all that, check the clock before you check the update stack - because four hours of latency looks exactly like a broken device, right up until you know it is four hours.

References

• Windows quality and feature update reports overview - the core document for this post: the diagnostic-data prerequisite at Required or higher, the service-state versus client-state data split, the "maximum end-to-end latency is approximately four hours" figure, and the definitions of Up to Date, Not up to Date and Not Ready.
• Quality update status report - the four-hour report refresh, the "last refreshed on" stamp, and the full default and optional column list including Intune last check-in time and the note that Service/Client State columns "are supplemental and might not display for all devices".
• Prerequisites for Windows Update for Business reports - the supported join types, the Entra-registered-only exclusion, the February 2023 cumulative update floor, the OneSettings warning, the device-name opt-in policy, and the full endpoint table including the DeviceCensus.exe and login.live.com notes.
• Windows Update for Business reports overview - how the service works, the Log Analytics dependency, and the UCClient / UCClientUpdateStatus / UCUpdateAlert table list.
• UCClient data schema - the per-device record, and the two fields that make latency legible: LastCensusScanTime and LastWUScanTime. Also OSBuild, OSRevisionNumber, and the many fields marked "Currently, data isn't gathered to populate this field".
• Post-device registration readiness checks - the once-a-day agent cadence, the up-to-24-hours return to Ready, the 28-day Intune communication rule, the GPO-versus-Intune policy conflict check, the PingReply connectivity test, and the DRCResults.json.log path.
• Register devices with Windows Autopatch groups - the "up to 48 hours for devices to appear as registered" statement, the hourly device discovery function, and the Registered / Not registered readiness substatuses.
• Windows Autopatch: configure your network - the TLS 1.2 requirement and the Autopatch-specific endpoint allowlist.
• Configure Windows diagnostic data in your organization - the four diagnostic-data settings and their numeric values, the Windows Update recommendation, the diagnostic endpoints, and the DisableEnterpriseAuthProxy conflict with Defender for Endpoint.
• Policy CSP - System - AllowTelemetry (values, default, and the Software\Policies\Microsoft\Windows\DataCollection registry mapping), AllowDeviceNameInDiagnosticData, and the deprecation note on AllowMicrosoftManagedDesktopProcessing.
• Win32_QuickFixEngineering class - "This class returns only the updates supplied by Component Based Servicing (CBS)", the duplicate-enumeration warning, and the InstalledOn format caveat. The reason Get-HotFix returns 4 rows on a device with 415 packages.
• Windows Update error code list by component - the constant names and descriptions for 0x80240034, 0x80240016, 0x8024000B and 0x80244022, and confirmation that 0x80240438 is not enumerated.

Every measured value in this post was captured read-only from a single live Windows 11 Enterprise device on build 26200.9168 (25H2) on 23 August 2026. Nothing was cleared, reset, stopped or repaired to produce them - which is rather the point.