Patch status "No Data" on Windows 10 and 11 devices
IMPORTANT The instructions below are specifically for Patch Status of No Data issues related to the 0x8002802B error. If you have devices that have the Patch Status of No Data but are not experiencing this error, please refer to How to address a patch status of "No Data".
NOTE For more information on the 0x8002802B error, refer to this Microsoft article.
Issue
Windows 10 and 11 devices return a patch status of No Data and patch audit failures in the Activity Log that include the error code "0x8002802B".
This article is a response to a change made by Microsoft in June 2024 which affected how devices running Datto RMM performed patch scans.
As of the time of writing, without manual intervention, Windows 11 (and potentially Windows 10) devices with recent patches installed will not be able to perform patch scans. The devices will report as having No Data as their patch status in Patch Management.
This document explains what has happened, how to fix it, and what Datto is doing long term to address the issue.
Summary
A recent Servicing Stack Update (SSU) pushed via Windows Update has caused patch scans to return No Data, leaving them unable to audit patches and, as a result, rendering Patch Management unusable in Datto RMM. Checking for updates manually on the device works without issue. This issue is not restricted to Datto RMM but rather affects any software that performs patch scans in the same manner.
Cause
The cause of this issue is an unannounced change made by Microsoft to the backend API powering Windows Update patch scans. The issue appears to lie with the Windows Update Agent (WUA) and the IUpdateSearcher COM object, with which Datto RMM interacts for patch data. WUA versions 1300 and higher are no longer returning metadata for discovered patches and are instead returning empty objects, which cannot be parsed and for which Datto RMM thus returns No Data.
Comparison of healthy versus unhealthy WUA responses
A healthy response with WUA version 12xx. The Microsoft.Update.Session COM object returns the title property of the first patch it discovers:
PS > $varUpdateSearcher=$(New-Object -ComObject Microsoft.Update.Session).CreateUpdateSearcher()
PS > ($varUpdateSearcher.Search('IsInstalled=1').Updates | select -first 1).title
MSXML 6.0 RTM Security Update (925673)
An unhealthy response with WUA version 130x. No data returned for any patch:
PS > $varUpdateSearcher=$(New-Object -ComObject Microsoft.Update.Session).CreateUpdateSearcher()
PS > ($varUpdateSearcher.Search('IsInstalled=1').Updates | select -first 1).title
PS >
IMPORTANT Datto RMM is not the only software affected by this bug. Any software using the same methods as Datto RMM will encounter these issues when scanning for patches.
Before covering suggested remediation steps, several fixes have been proposed by the community, which Datto has found to be either ineffective or inadvisable as follows:
• Registry adjustments: It has been proposed to adjust Registry data at HKLM:\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides\4\1931709068, but Datto has not found this to be effective since the affected WUA versions graduated from Preview to Release status.
• Uninstalling updates: Datto RMM does not support uninstallation of updates, and it is generally not supported on Windows-as-a-Service. Refer to Best practices for uninstallation of Windows updates. As the updates causing these issues are intermingled with patches for serious security flaws, Datto does not recommend attempting to uninstall the updates causing this behavior. Further, removing patches has not shown to be consistently effective at remediating this behavior.
Resolution
(Short term): ComStore component
A component that fixes this behavior, which must be run on all devices manifesting patching errors, has been prepared. This component, WUA JSON Adjustment Tool [WIN], for Windows 10 and Windows 11 devices, is available from the Datto RMM ComStore.
How the component works
Windows-as-a-Service contains a JSON file located at $env:ProgramData\Microsoft\Windows\OneSettings\UUSSettings.json which stores a blocklist for WUA versions. Windows uses this information to leverage in-built functionality to ignore specific WUA versions and fall back to earlier ones. By adding known-problematic WUA versions – such as those added in recent SSUs – to this blocklist, Windows can be instructed to fall back to earlier versions which do not return blank object data.
The component works by adding all known-problematic WUA versions to this blocklist, and then rebooting twice. In testing, rebooting twice was consistently shown as an important step to activating the changes, so be ready for all systems on which the component is run to reboot twice in quick succession as part of the fix.
When to run the component
The component can be run multiple times against a device without ill effect. In a case where a subsequent Windows Update breaks functionality again, users can rerun the component to restore functionality by adding the latest affected WUA version to the blocklist.
The component can also be run with the Revert Adjustment mode to return the system to default settings and remove all custom WUA version blocks.
Now that Microsoft has issued a fix, as detailed in the next section, the component can be run to remove the adjustments it had made, but this step should not be necessary to return patching functionality.
(Long term): Microsoft fix
Microsoft has fixed this behavior on Windows 11 devices as part of KB5041585, released August 2024.
Devices rendered unable to scan by previous, breaking updates will need to run the WUA JSON Adjustment Tool [WIN] component to regain their scanning functionality. Alternatively, for the same effect, you can employ the Download and Apply Windows Update File (Current) [WIN] component alongside a Windows Update Catalog link to push the KB5041585 update directly to devices. For information on how to deploy components to devices, refer to Creating a job.
