## TL;DR
0x87d20b15 in WUAHandler.log means the update scan itself failed. Because scans run against the WSUS instance behind the software update point, an overloaded or unmaintained SUP produces this across many clients at once. Check whether the failure is one client or the whole site, verify the SUP WSUS health and its IIS pool, and run the WSUS cleanup and reindex if it is site-wide.

```text
sccm error 0x87d20b15 software update scan failed
```

## Use this when
- Clients show Unknown compliance for deployments.
- WUAHandler.log records scan failed with 0x87d20b15.
- Scans time out during large Patch Tuesday cycles.

## Not for this skill when
- One client fails scans while its site peers succeed and the SUP is healthy. That is a client WUA or WMI fault.
- Scans succeed but installs fail. Work the install error code instead.

## Steps
1. Determine scope: check three clients on the same SUP for the same code. Verify: you know if this is per-client or SUP-wide
2. On the SUP, open the WSUS console and check synchronization status and responsiveness. Verify: the console responds and sync is current
3. Check the WsusPool in IIS on the SUP for stopped state or rapid recycling during scan windows. Verify: the pool is started and its memory limit is not the default low value
4. Run WSUS cleanup and the SUSDB reindex on the SUP if maintenance has lapsed. Verify: scan response times in WUAHandler.log drop on a test client
5. Force a scan cycle on a test client and watch WUAHandler.log. Verify: scan completes with a count of updates and no 0x87d20b15

## Variant phrasings
### wua handler scan failed 0x87d20b15
The log-first phrasing.
### sccm clients unknown compliance sup scan timeout
The symptom phrasing at site level.
### wsus sup overloaded client scans failing
The root-cause phrasing for Patch Tuesday load.

Compatibility: Compatibility: Configuration Manager current branch software update points on WSUS, Server 2016 and later.

## Why it happens
A ConfigMgr scan is a WSUS catalog query filtered by everything the client reports. As the WSUS catalog grows with unmaintained superseded updates, scan payloads and server query times grow until clients hit their scan timeout and record this code. The failure therefore scales with catalog neglect and with simultaneous scan load after deployments are created.

## Edge cases / pitfalls
- Staggering scan and deployment deadlines across collections reduces the self-inflicted scan storm.
- Client-side, a huge WindowsUpdate.log with repeated rescan loops can indicate the local datastore also needs a reset, but only after SUP health is proven.
- Express installation files change download size, not scan cost; do not chase them for a scan error.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_lwFKcDODf5Qywl12s-UQSQ