Introduction
Level uses the Microsoft Windows Update Agent (WUA) API to detect and manage patches. If you’re seeing unexpected patch counts, missing updates, or no updates at all, the two most common causes are result-set differences between WUA and other update sources, and leftover WSUS configuration that redirects devices away from Microsoft’s update servers.
How Level Queries Windows Updates
Level queries the Microsoft WUA API for both available and installed patches. The WUA API is the same one Windows uses internally, but its results don’t match Windows Update History. Don’t compare the two directly — they pull from different data stores.
To see exactly what the WUA API returns for a given device, run these commands in PowerShell.
Installed patches:
$Session = New-Object -ComObject Microsoft.Update.Session
$Searcher = $Session.CreateUpdateSearcher()
$Searcher.Search("IsInstalled=1").Updates | ft -a title
Pending patches:
$Session = New-Object -ComObject Microsoft.Update.Session
$Searcher = $Session.CreateUpdateSearcher() $Searcher.Search("IsInstalled=0").Updates | ft -a title
If Level’s patch list matches what these commands return, Level is working correctly. Any discrepancy lives in the WUA layer itself.
When an update reports installed but appears again
When you use the Install Windows Updates action, Level refreshes the device’s update list after installation and verifies that the expected updates remain installed. For an install that does not reboot the device, the action waits about 10 minutes before verification.
If an expected update is offered again or is no longer reported as installed after verification, Level reports Some updates were not installed correctly. This indicates that the update may have rolled back after first reporting success. The action also sends the refreshed update state back to Level so the Updates view can reflect what the device currently reports.
If Windows still requires a reboot and Reboot after updates is disabled, the pending-reboot state can mask the final install state. Level waits for the reboot rather than treating that state as a rollback.
Diagnosing WSUS-Related Issues
If Level shows no available updates and the WUA commands above also return nothing, a leftover WSUS configuration is the likely cause. Devices still pointed at a WSUS server won’t query Microsoft’s update servers, so Level has nothing to report.
Check for WSUS Configuration
Run this in PowerShell to inspect the Windows Update registry key:
Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate"
If the output includes references to a WSUS server address, the device hasn’t been reconfigured.
Remove WSUS Settings
The correct fix is to reverse the Group Policy Object that originally pushed WSUS to the devices. If that’s not possible, the following script removes the WSUS client settings manually:
⚠️ WARNING: Test on a single device before deploying to production. If the GPO that configured WSUS is still active, the settings will return on the next policy refresh. Removing the GPO is the only permanent fix.
PowerShell
# Stop the BITS and Windows Update services
Stop-Service -Name BITS, wuauserv -Force
# Remove WSUS client configuration properties
$wsusProperties = @("AccountDomainSid", "PingID", "SusClientId", "SusClientIDValidation")
foreach ($property in $wsusProperties) {
Remove-ItemProperty -Name $property -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\" -ErrorAction SilentlyContinue
}
# Remove the SoftwareDistribution folder
Remove-Item "$env:SystemRoot\SoftwareDistribution\" -Recurse -Force -ErrorAction SilentlyContinue
# Start the BITS and Windows Update services
Start-Service -Name BITS, wuauserv
# Optionally, reset the Windows Update client settings
# This step ensures that the client re-registers and checks for updates from the correct source
$wuaucltPath = "$env:SystemRoot\System32\wuauclt.exe"
if (Test-Path -Path $wuaucltPath) {
Start-Process -FilePath $wuaucltPath -ArgumentList "/resetauthorization /detectnow" -NoNewWindow
} else {
Write-Output "wuauclt.exe not found. Ensure the Windows Update client is available."
}
After running, Level re-queries WUA on the next sync. Updates from Microsoft’s servers should appear at that point.
💡 TIP: Save this as a script in Level’s script library to deploy it via automation across multiple devices at once rather than running it manually.
FAQ
Level shows updates, but Windows Update History says they’re already installed. Who’s right? Both can be correct. Level queries the WUA API directly; Windows Update History reads from a separate log. The WUA PowerShell commands above are the ground truth for what Level sees. If those commands return the same patches Level is showing, Level is behaving correctly.
The WSUS cleanup script ran but devices are still pointing to WSUS. The Group Policy that configured WSUS is likely still active. The script removes the current registry values, but policy re-applies them on the next refresh. Reverse or disable the GPO first.
After removing WSUS config, how long until Level shows updates? Level re-queries WUA on the next device check-in cycle. In most cases, updated patch data appears within a few minutes of the device reconnecting or the agent polling.
An update reported installed, but it appeared again. What should I check? If the update was installed through the Install Windows Updates action, Level now performs a post-install verification, including after a no-reboot install has had time to settle. Check the action output for Some updates were not installed correctly and confirm whether Windows still requires a reboot. A pending reboot can prevent final verification until the device restarts.
Can I run the WSUS cleanup script across all affected devices at once? Yes. Save it as a script in Automations → Scripts, then run it via an automation targeting the relevant devices or via an ad-hoc run from the device listing.