Updates not installing from Configuration Manager: WUAHandler.log, UpdatesDeployment.log

When Configuration Manager (still widely called SCCM or MECM) deploys updates that never install, the console rarely tells you why. The answer is almost always in a handful of client logs. In this post I'll follow an update through the client — scan source, scan, evaluation, download and installation — and show what each log should say, the errors you'll actually meet and how to fix them.

Symptoms#

• Software Center shows no updates, even though the device is in the target collection.
• In Monitoring › Deployments, devices sit in Unknown or Error, or stay In progress for days.
• WUAHandler.log repeats Scan failed with error = 0x80244022 (or another code) at every scan cycle.
• Updates download but wait indefinitely, or install outside the hours you expected.

Why it happens#

The client doesn't scan by itself. It points the Windows Update Agent (WUA) at the WSUS server on your software update point (SUP), lets WUA scan, and then enforces your deployments against the result. A break anywhere in that chain stops everything after it. All of these logs live in C:\Windows\CCM\Logs:

The usual culprits: the client can't reach WSUS (ports, proxy, an overloaded WSUS application pool), a domain GPO points WUA at a different server, a failed SUP synchronisation, content missing from the client's boundary group, or maintenance windows shorter than the updates' maximum run time.

How to fix it#

1. Confirm the client has a scan source#

Trigger a scan and a deployment evaluation, then read ScanAgent.log and LocationServices.log:

# Scan by Update Source (software updates scan cycle)
Invoke-CimMethod -Namespace root\ccm -ClassName SMS_Client -MethodName TriggerSchedule -Arguments @{sScheduleID='{00000000-0000-0000-0000-000000000113}'}
# Software Updates Assignments Evaluation Cycle
Invoke-CimMethod -Namespace root\ccm -ClassName SMS_Client -MethodName TriggerSchedule -Arguments @{sScheduleID='{00000000-0000-0000-0000-000000000108}'}

If no WSUS location comes back, or WUAHandler.log is never created, the client has no scan policy or the management point returned an empty location. Check CcmMessaging.log for communication errors, then Monitoring › Software Update Point Synchronization Status: a failed or stale sync is a classic cause of an empty reply.

2. Read the scan result in WUAHandler.log#

Async searching of updates using WUAgent started.
Async searching completed.
OnSearchComplete - Failed to end search job. Error = 0x80244022.
Scan failed with error = 0x80244022.

WUAHandler.log only relays what WUA reported, so the detail is in the Windows Update log. On Windows 10 and 11, run Get-WindowsUpdateLog to produce a readable WindowsUpdate.log. The codes you'll see most:

3. Test WSUS from the client#

Test-NetConnection sup01.contoso.com -Port 8530
Invoke-WebRequest http://sup01.contoso.com:8530/ClientWebService/wusserverversion.xml -UseBasicParsing
Invoke-WebRequest http://sup01.contoso.com:8530/SimpleAuthWebService/SimpleAuth.asmx -UseBasicParsing
netsh winhttp show proxy

If these succeed but the scan still fails, read the IIS logs on the SUP to see whether WSUS returned the error or something in between (proxy, firewall) did.

4. Remove Group Policy conflicts#

The client writes the SUP URL into local policy. A domain GPO that sets Specify intranet Microsoft update service location to anything else wins, and WUAHandler.log tells you:

Group policy settings were overwritten by a higher authority (Domain Controller) to: Server http://server and Policy ENABLED

Run gpresult /h gp.html to find the GPO, then remove it from Configuration Manager clients (or make it identical, port included). Confirm:

Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate' | Select-Object WUServer, WUStatusServer
Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU' | Select-Object UseWUServer

WUServer and WUStatusServer should both show your SUP URL with its port, and UseWUServer should be 1.

5. Follow evaluation and download#

Add the Deployment Unique ID column in the console and search for it in UpdatesDeployment.log. Healthy evaluation shows Assignment {...} has total CI = n, then Making updates available for assignment and progress lines with Status = ciStateDownloading. If downloads stall, read CAS.log, ContentTransferManager.log and DataTransferService.log, and confirm the deployment package is on a distribution point in the client's boundary group (or that fallback is allowed).

6. Check maintenance windows and maximum run time#

Search ServiceWindowManager.log for Refreshing Service Windows. Upper-case IDs are collection maintenance windows; lower-case IDs are business-hours windows from Software Center. If UpdatesDeployment.log reports No current service window available to run updates assignment, the window is too short or doesn't apply to updates:

• An update only starts if the remaining window can fit its Maximum Run Time (update properties in Software Library › Software Updates › All Software Updates).
• A window lasts 24 hours at most, and its Apply this schedule to value must be All deployments or Software updates.
• If a device has both kinds, updates use only the Software updates window unless you enable the Software Updates client setting that allows installation in "All deployments" windows.

Verify the fix#

1. Run the scan cycle again. WUAHandler.log should end with Successfully completed scan.
2. UpdatesStore.log raises state messages for missing updates; the client forwards them on the state message cycle (every 15 minutes by default).
3. Software Center lists the required updates, and UpdatesDeployment.log shows them moving through download and installation.
4. In Monitoring › Deployments, right-click the deployment, choose Run Summarization and refresh: the device should leave Unknown for In progress or Compliant.

Prevent it next time#

• Keep WSUS lean and its application pool healthy; a bloated database is a common source of 0x80244022. See software update point and WSUS maintenance.
• Never target Configuration Manager clients with a GPO that sets a WSUS server.
• Alert on SUP synchronisation failures: clients can't scan against content the site doesn't have.
• Size maintenance windows for the slowest update and patch a pilot ring first — see ring-based automatic deployment rules for Patch Tuesday.

References#

• Troubleshoot software update scan failures in Configuration Manager
• Troubleshoot software update deployments in Configuration Manager
• Track software update compliance assessment