Helpdesk: "The Patch Tuesday report says 140 of our 600 workstations are 'Not yet reported,' and the 30 laptops we imaged last week aren't in the WSUS console at all. A forum thread says to push a reset script to every PC and run the Server Cleanup Wizard. Can we just do that before Monday's audit?"
Don't push the script yet. "Not reporting" in WSUS is several different failures that look the same in the console. Microsoft's message reference for "Computer hasn't reported status" says it "is typically caused by the WSUS client computer, not the WSUS server," and the most common reasons are a computer that lost network connectivity or is turned off. A reset script that deletes client IDs on every machine fixes one cause (cloned IDs) and adds noise for the rest. The cleanup wizard deletes the computer records you're trying to read. Work through it as a chain: the console status, the computers, and what changed on the ticket → the console view itself (status filter, group, last contact vs last status report) → the client received the WSUS policy (detection URL, statistics URL, port, scheme) → the client is actually scanning WSUS, not Windows Update → the Windows Update agent ran a scan and logged a result → the network path to ClientWebService and SimpleAuthWebService, including the WinHTTP proxy and TLS trust → the WSUS server's IIS site, app pool, and logs → each client has its own SusClientId. Get-WsusComputer, the WSUS administration API, gpresult, the WindowsUpdate policy key, Microsoft.Update.ServiceManager, Get-WindowsUpdateLog, the WindowsUpdateClient Operational log, Test-NetConnection, netsh winhttp show proxy, and the IIS logs are the sources for that chain. Reset every client and a wrong statistics URL or a stopped app pool is still there next month.
If the WSUS GPO doesn't show up in gpresult at all, read Group Policy Not Applying first. If some of these devices are also getting Intune update rings, read Windows Update Rings for Intune Pilots. Deferral policies on a WSUS-pointed Windows 10 device change where it scans. This post covers "WSUS clients show 'Not yet reported' or a stale Last Status Report, sit in Unassigned Computers, appear and disappear, or never show up in the console, and you need a read-first path through the console view, the client policy, the scan source, the agent's logs, the network and proxy path, the WSUS server, and the client ID before you push reset scripts, delete SoftwareDistribution, run the cleanup wizard, or rebuild WSUS."
TL;DR
- The console hides healthy computers by default. Microsoft: "The default shows only computers for which updates are needed or which have had installation failures." Set Status to Any and select Refresh before you count anything.
- "Not reported" usually starts on the client. Microsoft: the message "is typically caused by the WSUS client computer, not the WSUS server."
- The policy has two URLs with two jobs. Microsoft: "the server from which the client detects and downloads updates, and the server to which updated workstations upload statistics." Our reading: a wrong statistics URL can break reporting while scans still work.
-
Only one cloned PC visible at a time? That's a duplicate
SusClientId. Microsoft: "This issue can happen when systems are imaged and the clients end up having the sameSUSclientID." - Scans and reports try proxies in a different order. Microsoft: scan URLs try the system (WinHTTP) proxy first; URLs "used for reporting" try the user proxy first.
- New clients take time. Microsoft: after a successful scan, the client appears in the console "Within about 20 minutes." The default detection interval is 22 hours.
Where in the chain did it break?
| Step | What should be true | Typical symptom when it breaks |
|---|---|---|
| 1. Symptom captured | Which computers, which console status, both dates, what changed | "WSUS is broken" with no computer names or dates |
| 2. Console and server view | Status filter on Any, right group, last contact and last status report read | Healthy computers "missing"; computers stuck in Unassigned Computers |
| 3. Client policy |
WUServer, WUStatusServer, and UseWUServer point at the right site, scheme, and port |
Typo in the URL, wrong port, HTTP vs HTTPS mismatch |
| 4. Scan source | The client scans WSUS for the update types you expect | Client gets updates, WSUS shows no status |
| 5. Agent scan | Services running, a recent successful search, no scan errors |
LastSearchSuccessDate days old; errors in the Operational log |
| 6. Network path | Name, port, web services, WinHTTP proxy, and TLS trust all work from the client |
0x8024402C, 0x80072EE2, 0x8024401B, 0x80072F8F
|
| 7. WSUS server | WSUS service, IIS site, and WsusPool up; client requests in the IIS logs |
Every client stops at once; 0x80244022 (503) |
| 8. Client ID | Each client has a unique SusClientId
|
Names flip; only one of a batch appears |
| 9. Change | Only after Steps 1-8 agree: one layer, one change | Reset script pushed everywhere, same gaps next month |
Step 1: Capture the symptom (read-only)
Write these on the ticket first:
| Fact | Why it matters |
|---|---|
| Which computers (all, one group, one site, one image, one OS) | All of them points at the server or a GPO; one batch points at an image or a subnet |
| What the console shows for them | Missing, "Not yet reported," stale status, Unassigned Computers, or a name that keeps changing (table below) |
| Last contact and last status report dates | Two different timestamps (Step 2). One fresh and one stale narrows it to reporting |
| When it started | Match it to a change: patch night, GPO edit, certificate renewal, proxy change |
| What changed? | New image, WSUS moved to HTTPS or a new port, server rebuilt, proxy or firewall change, Intune or Configuration Manager taking over update policy |
| How the client gets its update policy | Domain GPO, local policy, Configuration Manager, or Intune. Each can overwrite the other |
| The WSUS server URL you expect | Scheme, FQDN, and port, e.g. https://wsus01.corp.contoso.com:8531
|
Then branch on what the console shows:
| What the console shows | What it usually means | Start at |
|---|---|---|
| Computer missing from every view | Status filter hiding it, or it never contacted this server | Steps 2, 3 |
| Listed, but status not yet reported | Contacted the server, never sent status (our reading of LastReportedStatusTime) |
Steps 2, 5, 6 |
| Last status report days old, last contact recent | Scans work, reporting doesn't (our reading) | Steps 3, 6 |
| Both dates days old | The client stopped talking to WSUS | Steps 3-7 |
| In Unassigned Computers instead of its group | Client-side targeting off on the server, or the requested group doesn't exist | Step 2 |
| Name keeps changing; only one of a batch visible | Duplicate SusClientId (Microsoft) |
Step 8 |
| Every client stopped on the same day | Server side: app pool, IIS, certificate, port | Step 7 |
| Client installs updates, WSUS shows nothing | It's scanning Windows Update instead | Step 4 |
Step 2: Read the console and the server's view (read-only)
Start in the console: Computers > All Computers, set Status to Any, then Refresh. Microsoft: "The default shows only computers for which updates are needed or which have had installation failures," and you need to "Click Refresh after changing the status filter." A healthy, fully patched computer is invisible in the default view.
Then read the same data from PowerShell on the WSUS server (UpdateServices module):
# Read-only. On WSUS01. Use your real port, and -UseSsl only if the WSUS site is HTTPS
$wsus = Get-WsusServer -Name 'wsus01.corp.contoso.com' -PortNumber 8531 -UseSsl
# Read-only. Name, IP, OS, and Last Status Report for every client
Get-WsusComputer -UpdateServer $wsus -All
# Read-only. Last contact vs last status report, the group each client asked for, and its WSUS ID
$wsus.GetComputerTargets() |
Select-Object FullDomainName, IPAddress, LastSyncTime, LastReportedStatusTime, RequestedTargetGroupName, Id |
Sort-Object LastReportedStatusTime |
Format-Table -AutoSize
Get-WsusServer takes "the server name, port number and a flag that specifies if the server uses Secure Sockets Layer (SSL)" (Microsoft). GetComputerTargets() is the WSUS administration API's method that returns all known clients. How to read the fields, from Microsoft's IComputerTarget reference:
| Field | Microsoft's definition | How to read it |
|---|---|---|
LastSyncTime |
"the UTC time at which the client last synchronized itself with the WSUS server" | Recent means the client is reaching this server and scanning |
LastReportedStatusTime |
"the last time this client sent its update installation status"; DateTime.MinValue "means that the client has never sent its status" |
Old or MinValue while LastSyncTime is recent: reporting is the broken half (our reading) |
RequestedTargetGroupName |
"the name of the computer group to which this computer claims to belong" | A name here while the computer sits in Unassigned Computers: see targeting below |
Id |
"the unique identifier of the client computer" | Our reading: this is the client's SusClientId (Step 8) |
Both dates are UTC. Convert before you compare them with client log times.
Targeting mode. Check whether the server expects the client or the console to decide the group:
# Read-only. Client = Group Policy or registry decides the group; Server = you assign groups in the console
$wsus.GetConfiguration().TargetingMode
Microsoft's TargetingMode reference: "If client-side targeting is enabled and the group exists, the client is added to the specified group. Otherwise, the client is added to the Unassigned Computers group and IComputerTarget.RequestedTargetGroupName is set to the request group name." The GPO side says the same thing: "If the target group name doesn't exist in WSUS, it's ignored until it's created."
| Finding | What it means | Next |
|---|---|---|
TargetingMode is Server, GPO sets a target group |
The server ignores the client's request | Pick one model (Step 9). Microsoft: you select it under Options > Computers |
TargetingMode is Client, requested name has a typo or missing group |
Client lands in Unassigned Computers | Create the group with that exact name, or fix the GPO |
TargetingMode is Client, you try to move computers in the console |
Microsoft: "you can't assign client computers to computer groups, or move them from one computer group to another, through the WSUS Administration Console" | Change the client's policy instead |
TargetingMode is Server, new computers in Unassigned Computers |
Expected. Microsoft: "you must manually move new client computers from the Unassigned Computers group" | Not a reporting problem |
Computer not in GetComputerTargets() at all |
It never registered with this server | Step 3 |
Step 3: Read the client's update policy (read-only)
Microsoft's first check for WSUS client problems: "Make sure the proper Active Directory Group Policy is being received by the client, and the details of the WSUS server are present." Their command is GPRESULT /V > GPRESULT.TXT, then find your WSUS GPO under Applied Group Policy Objects in the computer section. A shorter summary works too:
# Read-only. Elevated on the client. Computer-side GPOs that applied (and the ones that were filtered out)
gpresult /scope computer /r
# Read-only. The policy values Windows Update actually reads
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate' -ErrorAction SilentlyContinue
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU' -ErrorAction SilentlyContinue
| Value | What Microsoft says | What to check |
|---|---|---|
WUServer (WindowsUpdate key) |
"sets the WSUS server by HTTP name" | Exact scheme, FQDN, and port of the WSUS site |
WUStatusServer (WindowsUpdate key) |
"sets the SUS statistics server by HTTP name" | Usually the same as WUServer. A missing or stale value is our first suspect when scans work and reports don't |
UseWUServer (AU key) |
"Set this value to 1" to use the WSUS server instead of Windows Update |
0 or missing: our reading is that the URLs above aren't used |
NoAutoUpdate (AU key) |
1 means "Automatic Updates is disabled" |
Microsoft: if Configure Automatic Updates is disabled, the intranet location policy "has no effect" |
| Target group values (WindowsUpdate key) | Client-side targeting sends "the specified target group information" to WSUS | Spelling must match a console group exactly (Step 2). Our note: the values are usually TargetGroup and TargetGroupEnabled
|
DisableDualScan and scan-source values |
Step 4 | Step 4 |
Port and scheme. Microsoft: WSUS uses "port 8530 for HTTP protocol and port 8531 for HTTPS protocol to provide updates to client workstations," and the GPO warning is "Make sure to include the correct port in the URL." If you changed ports, Microsoft requires two adjacent numbers: "The port number used for HTTP connections must be exactly 1 less than the port number used for HTTPS connections." Clients using TLS must use the server's FQDN (Microsoft). A short name in WUServer with an HTTPS URL is a common certificate-name mismatch (our reading).
Where the GPO lives. Microsoft: on Windows 10 and 11, Specify intranet Microsoft update service location and Enable client-side targeting are under Windows Update > Manage updates offered from Windows Server Update Service.
Configuration Manager clients. Microsoft: an Active Directory GPO for the WSUS location "overrides the local Group Policy setting" that Configuration Manager writes, and WUAHandler.log then shows Group policy settings were overwritten by a higher authority (Domain Controller). Check locationservices.log for the WSUS URL the client was given.
Step 4: Which service is the client really scanning? (read-only)
# Read-only. Microsoft's check for the client's update source
$MUSM = New-Object -ComObject 'Microsoft.Update.ServiceManager'
$MUSM.Services | Select-Object Name, OffersWindowsUpdates
Microsoft's table for the output:
Name with OffersWindowsUpdates: True
|
Meaning |
|---|---|
| Windows Server Update Service | "The client is configured to receive updates from WSUS." |
| Windows Update | "The client is configured to receive updates from Windows Update Online." |
| Microsoft Update | Updates for other Microsoft products can also be delivered |
The "updating but not reporting" case. Microsoft's WSUS and Windows Update client policies page: "If you configure a WSUS server and deferral policies on Windows 10: All of your updates will come from Windows Update unless you specify the scan source policy or have disabled dual scan." The dual scan policy "is no longer supported on Windows 11 and on Windows 10 it's replaced by the new Windows scan source policy," and "If you configure both on Windows 10, you won't get updates from Windows Update." On Windows 11 with only the WSUS policy, "All of your updates still come from WSUS unless you configure the specify scan source policy."
| Finding | What it means (our reading unless noted) | Next |
|---|---|---|
| WSUS URL set, Windows 10, deferral policy from GPO or an Intune update ring | Microsoft: updates come from Windows Update. WSUS sees little or no status | Decide which service owns this device (Step 9) |
| Scan source policy set for some update types | Microsoft: those types come "from the source chosen in the scan source policy" | Expected for a split. Report on each type where it's actually scanned |
| Only Windows Update listed, no WSUS entry | The WSUS policy isn't in effect | Step 3 |
| Windows Server Update Service listed | The source is right | Step 5 |
The scan source policy is Specify source service for specific classes of Windows Updates in the same Manage updates offered from Windows Server Update Service folder, or the SetPolicyDrivenUpdateSourceFor... CSPs (Microsoft). The CSP notes that if Update/UpdateServiceUrl isn't pointed at your WSUS server, "this policy has no effect."
Step 5: Did the agent scan, and what did it log? (read-only)
# Read-only. Services the scan and downloads depend on
Get-Service -Name wuauserv, BITS | Format-Table Name, Status, StartType
# Read-only. Automatic Updates' own record of the last successful search and install (UTC)
$au = New-Object -ComObject 'Microsoft.Update.AutoUpdate'
$au.Results | Format-List LastSearchSuccessDate, LastInstallationSuccessDate
Microsoft: LastSearchSuccessDate "Gets the last time and Coordinated Universal Time (UTC) date when AutomaticUpdates successfully searched for updates," and "Only the AutomaticUpdates object will update this property." Microsoft also notes BITS "must run under the LocalSystem account by default."
Now the log. Microsoft: "Windows Update no longer directly produces a WindowsUpdate.log file. Instead, it produces .etl files," and Get-WindowsUpdateLog merges them. The result is a static copy that doesn't update unless you run the cmdlet again.
# Read-only output to a path you choose (the default is the current user's Desktop)
Get-WindowsUpdateLog -LogPath "$env:TEMP\WindowsUpdate.log"
Select-String -Path "$env:TEMP\WindowsUpdate.log" -Pattern 'FAILED', 'Server URL', 'Reporting status' |
Select-Object -Last 40
# Read-only. Windows Update client errors and warnings from the last 7 days
Get-WinEvent -FilterHashtable @{
LogName = 'Microsoft-Windows-WindowsUpdateClient/Operational'
Level = 2, 3
StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue | Select-Object -First 20 TimeCreated, Id, Message
The patterns come from Microsoft's own log samples. A Configuration Manager scan logs Server URL = http://...:8530/ClientWebService/client.asmx, and an Automatic Updates scan against WSUS ends with Reporting status event with 0 installable, 83 installed, .... If the Server URL isn't your WSUS server, go back to Step 3. If scans end without a Reporting status line, our reading is that you're looking at a reporting problem. Microsoft's Windows Server update guidance points to Applications and Services Logs > Microsoft > Windows > WindowsUpdateClient > Operational for the failure code. The log name in the script is ours.
Match the code. Meanings are quoted from Microsoft's error reference and common-errors pages:
| Code | Microsoft's meaning | Layer |
|---|---|---|
0x8024402C |
WU_E_PT_WINHTTP_NAME_NOT_RESOLVED: "the proxy server or target server name can't be resolved" |
DNS or a typo in WUServer (Steps 3, 6) |
0x80072EE2 |
Timeout: the agent "was unable to connect to the update servers or your own source, such as WSUS" | Firewall or routing (Step 6) |
0x8024401B |
HTTP 407: "proxy authentication is required" | WinHTTP proxy (Step 6) |
0x80244017 |
HTTP 401: "the requested resource requires user authentication" | IIS authentication (Step 7) |
0x80244018 |
HTTP 403: "server understood the request but declined to fulfill it" | IIS or certificate configuration (Step 7) |
0x80244019 |
HTTP 404: "the server can't find the requested URI" | Wrong port or missing virtual directory (Steps 3, 7) |
0x8024401C |
HTTP 408: "the server timed out waiting for the request" | Server load (Step 7) |
0x80244022 |
HTTP 503: "the service is temporarily overloaded" |
WsusPool stopped or out of memory (Step 7) |
0x80244007 |
SOAP fault; Microsoft's guidance pairs it with SyncUpdates_WithRecovery failed
|
A ClientWebService setting on the server (Step 9) |
0x80072F8F |
"TLS 1.2 isn't configured correctly on the client" | TLS on the client (Step 6) |
Step 6: The network path from the client (read-only)
Microsoft: "During a scan, the Windows Update Agent needs to communicate with the ClientWebService and SimpleAuthWebService virtual directories on the WSUS computer." Test the same path from the client, using the scheme and port from WUServer:
# Read-only. Name resolution and the TCP port
Resolve-DnsName -Name 'wsus01.corp.contoso.com'
Test-NetConnection -ComputerName 'wsus01.corp.contoso.com' -Port 8531 |
Select-Object ComputerName, RemotePort, TcpTestSucceeded
# Read-only. The WSUS web services Microsoft says to test (GET requests, nothing written)
$base = 'https://wsus01.corp.contoso.com:8531'
foreach ($path in '/ClientWebService/wusserverversion.xml', '/SimpleAuthWebService/SimpleAuth.asmx', '/selfupdate/wuident.cab') {
try {
$r = Invoke-WebRequest -Uri ($base + $path) -UseBasicParsing -TimeoutSec 15
'{0} {1}' -f $r.StatusCode, $path
} catch {
'{0} {1}' -f $_.Exception.Message, $path
}
}
The three URL paths are from Microsoft's scan-failure article, which uses telnet for the port test. Test-NetConnection is our substitute. Microsoft's WSUS client article also asks that you can "access the URL http://<WSUSSERVER:port>/iuident.cab and download the file without errors." Two cautions: Microsoft notes "Accessing most WSUS URLs in a browser will return a 403 error," so a 403 on the root isn't proof of a fault. And Invoke-WebRequest runs as you, with your proxy settings, while the Windows Update service runs as LocalSystem (our note). Treat a failure as evidence and a success as a hint.
| Finding | Microsoft's cause | Next |
|---|---|---|
| Name doesn't resolve | "There's a name resolution issue on the client." | DNS, or the FQDN in WUServer
|
TcpTestSucceeded is False
|
Firewall rules or "an intermediate network device is blocking that port"; Microsoft: test from a client on the same subnet | Firewall on WSUS01 or between segments |
| Port open, URLs fail | Name, proxy, port, or "IIS availability problems" | Proxy (below), then Step 7 |
| HTTPS fails with a certificate error | The client doesn't trust the WSUS certificate | TLS trust (below) |
Proxy. Microsoft: the Automatic Updates service "runs under the Local System account" and can only discover a proxy configured with netsh or through WPAD (DNS or DHCP). For "scan URLs (connect to SimpleAuth Web Service, Client Web Service)" the system proxy (WinHTTP) is tried first, then the user proxy. For URLs "which aren't used for update detection (for example, URLs used for reporting)," the user proxy is tried first, then the system proxy.
# Read-only. The system (WinHTTP) proxy used for scans
netsh winhttp show proxy
Our reading: if the WinHTTP and user proxy settings disagree about bypassing the WSUS name, scans and reports can take different paths. That's one way to get a recent last contact with a stale status report. Microsoft also notes that for intranet WSUS URLs "you can use the Specify intranet Microsoft update service location setting to choose the proxy behavior."
TLS trust. Microsoft: "The WSUS server's TLS/SSL certificate must be imported into the client computers' Trusted Root CA store," and "You must use the certificate store for the local computer. You can't use a user's certificate store."
# Read-only. Is the issuing root in the computer's store? (match the issuer shown on the WSUS site's certificate)
Get-ChildItem -Path 'Cert:\LocalMachine\Root' |
Where-Object Subject -like '*Contoso*Root*' |
Select-Object Subject, NotAfter, Thumbprint
Step 7: The WSUS server (read-only)
When every client stops reporting on the same day, start here. Microsoft's connection-failure steps: verify "the Update Services service and the World Wide Web Publishing Service are running," that the WSUS Administration website is running, and review the IIS logs.
# Read-only. On WSUS01. Service names WsusService and W3SVC are our note
Get-Service -Name WsusService, W3SVC | Format-Table Name, DisplayName, Status
# Read-only. IIS: the WSUS app pool and its private memory limit (KB)
Import-Module WebAdministration
Get-WebAppPoolState -Name 'WsusPool'
(Get-ItemProperty -Path 'IIS:\AppPools\WsusPool' -Name recycling.periodicRestart.privateMemory).Value
Get-Website | Format-Table Name, State, Bindings -Wrap
Microsoft's 503 guidance: when the console or http://WSUS01:8530 returns "HTTP Error 503. The service is unavailable," "the most likely cause is that the WsusPool Application Pool in IIS is in a stopped state." The Private Memory Limit "is probably set to the default value of 1843200 KB." Microsoft adds that 503 errors in IIS "may be accompanied by xxxx2ee2 errors" in the client's Windows Update log.
Then look for the client in the IIS logs:
# Read-only. Has this client's IP hit IIS today? (the WSUS Administration site often isn't W3SVC1)
$ip = '10.20.30.114'
Get-ChildItem -Path 'C:\inetpub\logs\LogFiles' -Recurse -Filter 'u_ex*.log' |
Where-Object LastWriteTime -gt (Get-Date).Date |
Select-String -SimpleMatch $ip |
Select-Object -Last 20
Microsoft's article says c:\inetpub\logfiles. On IIS 7 and later the default folder is C:\inetpub\logs\LogFiles (our note). Microsoft: "If a client's IP address doesn't appear in the IIS logs, verify that the client is set to connect to the correct WSUS server," or look for network blocking, and check C:\windows\system32\logfiles\httperr.
Microsoft's status code table for those logs:
| Status | Microsoft's explanation |
|---|---|
| 200 / 206 | Success / continuation |
| 401 | "Authorization: OK if followed by 200" |
| 403 | "Access failure: Certificate issues or incorrect IIS configuration." |
| 404 | "Not found: Missing Virtual directory or IIS configuration" |
| 500 | "Service not available" |
| 503 | "Busy: This can be caused by a WSUS application pool memory issue or just too many client connections." |
Step 8: Does each client have its own ID? (read-only)
Microsoft: "You may experience an issue where only one WSUS client appears in the console. Or you may notice that out of a group of clients, only one appears in the console at a time but the exact one that does appear may change over time. This issue can happen when systems are imaged and the clients end up having the same SUSclientID." Microsoft's archived WSUS team blog puts it more bluntly: "99% of the time this happens because the clients in question have duplicate SUSClientID values."
# Read-only. Compare SusClientId across machines from the same image (PowerShell remoting must already be allowed)
$pcs = 'PC-ACC-114', 'PC-ACC-115', 'PC-ACC-116'
Invoke-Command -ComputerName $pcs -ScriptBlock {
(Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate' -Name SusClientId -ErrorAction SilentlyContinue).SusClientId
} | Group-Object | Where-Object Count -gt 1 | Select-Object Count, Name
Any group with a count above 1 is a duplicate. The registry path is Microsoft's; the comparison is ours. On the server you won't see the duplicates as separate rows. Our reading: they share one record, whose name and IP change to whichever machine reported last.
| Finding | What it means | Next |
|---|---|---|
Same SusClientId on two or more machines |
Duplicate client ID (Microsoft) | Reset only those machines (Step 9) |
| Unique IDs, still missing | Not an ID problem | Steps 3-7 |
No SusClientId value |
The client hasn't registered yet (our reading) | Step 5: is it scanning at all? |
Common false starts (read these before you change anything)
| False start | Why it hurts | Read-first alternative |
|---|---|---|
| Counting from the default console view | Microsoft: the default shows only computers that need updates or had failures | Status Any, Refresh (Step 2) |
| Pushing a reset script to every PC | Deletes healthy IDs too. Microsoft's archived blog: old IDs then show as not checked in until cleanup | Find the duplicates first (Step 8) |
| Running the cleanup wizard during triage | Microsoft: it deletes "all client computers that haven't contacted the server in 30 days or longer" | Run it after triage, as maintenance |
| Deleting SoftwareDistribution first | Microsoft limits that rebuild to "errors relating to the software distribution store" | Read the log and the error code (Step 5) |
Running wuauclt /reportnow on Windows 11 and calling it done |
Microsoft's setup guide lists wuauclt /detectnow only for versions before Windows 10 |
Settings > Check for updates, or the documented DetectNow() (Step 9) |
| Fixing only the browser (user) proxy | Microsoft: scans try the WinHTTP proxy first |
netsh winhttp show proxy (Step 6) |
| Treating a 403 in the browser as the fault | Microsoft: "Accessing most WSUS URLs in a browser will return a 403 error" | Test the specific web service URLs (Step 6) |
| Moving computers in the console under client-side targeting | Microsoft: you can't move them there in that mode | Fix the GPO's group name (Step 2) |
| Switching the GPO from HTTPS to HTTP to dodge a certificate error | Microsoft recommends TLS for the metadata connection; going back to HTTP to avoid a certificate weakens it (our reading) | Fix trust on the client (Step 6) |
| Adding deferral policies to WSUS-pointed Windows 10 devices | Microsoft: their updates then come from Windows Update | Pick one owner, or set the scan source policy (Step 4) |
| Reinstalling the WSUS role | Swaps one unknown for a new server and fresh client registrations (our reading) | Step 7 first: app pool, IIS, logs |
Step 9: Change one layer, then watch (only after the read)
Pick the one change Steps 1-8 point at. Back up what you change, and test on one client first.
Client policy (Step 3) or targeting (Step 2): fix the GPO (URL, port, statistics server, group name), then follow Microsoft's re-register order: gpupdate /force, let the client scan, and "In rare cases" wuauclt.exe /resetauthorization /detectnow. Microsoft's setup guide also restarts the client: "This step makes sure that the Windows Update software on the computer detects the policy changes." To start a scan from PowerShell, there's a documented API call:
# Change (starts a scan; low risk). IAutomaticUpdates::DetectNow runs only if Automatic Updates is enabled
(New-Object -ComObject 'Microsoft.Update.AutoUpdate').DetectNow()
Microsoft: DetectNow "Begins the Automatic Updates detection task if Automatic Updates is enabled," and returns WU_E_AU_NOSERVICE if Automatic Updates is "disabled, initializing, uninitializing, or not configured." Our reading of Microsoft's log sample: the status report goes out at the end of a successful scan.
Duplicate SusClientId (Step 8), only on the machines that share one:
# Change. Back up the key, then dry-run each step with -WhatIf; remove -WhatIf to run
$key = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate'
reg export 'HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate' "$env:TEMP\WindowsUpdate-key.reg" /y
Stop-Service -Name wuauserv -WhatIf
Remove-ItemProperty -Path $key -Name SusClientId -WhatIf
Start-Service -Name wuauserv -WhatIf
# Then start a scan (DetectNow above). Microsoft's KB follows with: wuauclt /resetauthorization /detectnow, then wuauclt /reportnow
Microsoft's KB stops the service, deletes SUSclientID, restarts the service, then runs the two wuauclt commands. Microsoft's archived blog script also deletes PingID and AccountDomainSid and stops BITS. Community scripts often add SusClientIDValidation; we didn't find that on the Learn pages we used. Fix the image too. Our reading: a reference machine that contacted WSUS before capture passes its ID to every copy.
Proxy (Step 6): Microsoft's Windows Update pages use netsh winhttp import proxy source=ie or netsh winhttp set proxy with a bypass list that includes the WSUS name. The netsh reference now marks set proxy as deprecated in favor of set advproxy. netsh has no dry run, so save the show proxy output first. netsh winhttp reset proxy returns to direct access.
TLS trust (Step 6): distribute the issuing root through Group Policy for the fleet (our recommendation), or for one machine:
# Change. One test client: import the issuing root into the computer's Trusted Root store
Import-Certificate -FilePath 'C:\Temp\ContosoRootCA.cer' -CertStoreLocation 'Cert:\LocalMachine\Root' -WhatIf
Agent store (only for errors relating to the software distribution store): Microsoft's rebuild stops wuauserv, renames SoftwareDistribution, restarts the service, then runs wuauclt /resetauthorization /detectnow and wuauclt /reportnow.
# Change. Microsoft's rebuild, dry-run first. Our reading: the client's local update history goes with the old folder
Stop-Service -Name wuauserv -WhatIf
Rename-Item -Path "$env:SystemRoot\SoftwareDistribution" -NewName 'SoftwareDistribution.old' -WhatIf
Start-Service -Name wuauserv -WhatIf
WSUS server (Step 7): Microsoft's 503 fix is IIS Manager > Application Pools > WsusPool > Advanced Settings > Private Memory Limit (KB) = 4000000, then restart the application pool ("It may be necessary to increase the Private Memory Limit to 8GB (8000000 KB) or higher"). The PowerShell form is ours:
# Change (WSUS01). Raise WsusPool's private memory limit to Microsoft's 4 GB value; dry-run first
Set-ItemProperty -Path 'IIS:\AppPools\WsusPool' -Name recycling.periodicRestart.privateMemory -Value 4000000 -WhatIf
For 0x80244007 with SyncUpdates_WithRecovery failed, Microsoft's fix is in %ProgramFiles%\Update Services\WebServices\ClientWebService\web.config: change <add key="maxInstalledPrerequisites" value="400"/> to 800, then run IISReset. Copy web.config first. IISReset briefly drops every client connection (our note).
Cleanup, after triage: once the real cause is fixed, clear the stale records:
# Change (WSUS01). Deletes computers that haven't contacted the server in 30+ days (Microsoft); dry-run first
Get-WsusServer | Invoke-WsusServerCleanup -CleanupObsoleteComputers -WhatIf
In a hierarchy, Microsoft's warning is to run cleanup "on the lower-most, downstream/replica WSUS server first and then move up the hierarchy."
Scan source (Step 4): decide which service owns each update type. Then set Specify source service for specific classes of Windows Updates (or the matching CSPs) to match, and remove deferral policies from devices that should stay on WSUS. Don't layer dual scan on top. Microsoft: configuring both on Windows 10 means "you won't get updates from Windows Update."
Read-only confirm afterwards:
# Client: a fresh successful search (UTC)
(New-Object -ComObject 'Microsoft.Update.AutoUpdate').Results.LastSearchSuccessDate
# Server: both dates moving for this client, and it's in the group you expect
$wsus.GetComputerTargets() |
Where-Object FullDomainName -like 'pc-acc-114*' |
Select-Object FullDomainName, LastSyncTime, LastReportedStatusTime, RequestedTargetGroupName
Watch one full cycle. The client's LastSearchSuccessDate moves, its log shows your WSUS Server URL and a Reporting status line, and both server dates advance. A newly registered client should appear "Within about 20 minutes" after its scan (Microsoft). After that, expect a check-in within the detection interval. Microsoft: the default is 22 hours, and an Enabled policy waits "between 80 and 100 percent of the hours specified."
When a change is justified
| Finding | Prefer | Avoid |
|---|---|---|
| Default console filter hid the computers | Status Any, then Refresh | Any client-side change |
Wrong or missing WUStatusServer / WUServer
|
Fix the GPO, gpupdate /force, restart, scan |
Editing the registry by hand on hundreds of PCs |
| Client in Unassigned Computers, requested group missing | Create the group with the exact name, or fix the GPO | Switching targeting modes mid-incident |
| Windows 10 device with deferrals scanning Windows Update | One owner per device, or an explicit scan source policy | Dual scan plus scan source |
| Name resolution or port blocked | DNS record or firewall rule for the WSUS port | Pointing clients at an IP address with HTTPS |
| WinHTTP proxy without a WSUS bypass |
netsh winhttp bypass list for the WSUS FQDN |
Fixing only the browser proxy |
| Certificate not trusted | Distribute the issuing root to LocalMachine\Root
|
Downgrading the GPO to HTTP |
WsusPool stopped, 503s |
Raise the private memory limit, restart the pool | Reinstalling WSUS |
Duplicate SusClientId on a batch |
Reset only the duplicates, fix the image | Reset script on the whole fleet |
| Software distribution store errors | Microsoft's rename-and-rescan on that client | Deleting SoftwareDistribution everywhere |
| Stale records after the fix | Cleanup wizard / Invoke-WsusServerCleanup with -WhatIf first |
Running cleanup before triage |
FAQ
Why are my WSUS clients not reporting status?
Microsoft says "Computer hasn't reported status" is typically caused by the client, not the server: lost network connectivity or a computer that's turned off are the most common reasons. After that, check the console filter, the client's WUServer and WUStatusServer policy values, whether the client is scanning WSUS or Windows Update, the WinHTTP proxy, TLS trust, the WSUS app pool, and duplicate SusClientId values, in that order.
How do I force a WSUS client to report?
Fix the cause first, then start a scan. On Windows 10 and 11, Microsoft's setup guide uses Settings > Windows Update > Check for updates, and lists wuauclt /detectnow only for versions before Windows 10. From PowerShell, the documented Windows Update Agent API call is (New-Object -ComObject 'Microsoft.Update.AutoUpdate').DetectNow(). Microsoft's WSUS client KB still uses wuauclt /reportnow after a reset.
Why does only one of my cloned computers show up in WSUS?
They share a SusClientId. Microsoft: "This issue can happen when systems are imaged and the clients end up having the same SUSclientID," and the computer you see can change over time. Compare the value under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate across the batch. Reset it only on the duplicates, and fix the image.
Why is a WSUS client getting updates but not reporting?
It's probably scanning Windows Update. Microsoft: on Windows 10, a WSUS server plus deferral policies means "All of your updates will come from Windows Update unless you specify the scan source policy or have disabled dual scan." Check the source with Microsoft.Update.ServiceManager. If it's WSUS, compare LastSyncTime with LastReportedStatusTime and check WUStatusServer and the proxy.
How long until a new client appears in the WSUS console?
Microsoft: once the policy applies and the client scans, it appears "Within about 20 minutes": in All Computers and Unassigned Computers with server-side targeting, or in its requested group with client-side targeting. Without a scan it waits for the detection interval: 22 hours by default, or 80-100 percent of the hours you set in Automatic Updates detection frequency.
Related posts
- Group Policy Not Applying (when the WSUS GPO never reaches the client: scope, filtering, replication)
- Windows Update Rings for Intune Pilots (deferral policies, the same settings that pull WSUS-pointed Windows 10 devices to Windows Update)
- Expedite a Windows Quality Update in Intune (why expedite does nothing on devices still pointed at WSUS)
Free checklist
When devices move from WSUS to Intune update rings, compliance policies like minimum OS version start feeding Conditional Access, and a device that stops patching can lose access to email. The free Conditional Access pre-enforcement checklist keeps break-glass accounts, pilot groups, and report-only review on one page:
If you want the rest of the Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=wsus-clients-not-reporting
Admin Pack Studio; not affiliated with Microsoft. Steps 1-8 favor read-only checks: the console with Status set to Any, Get-WsusServer, Get-WsusComputer, GetComputerTargets(), TargetingMode, gpresult, the WindowsUpdate policy key, Microsoft.Update.ServiceManager, Get-Service, LastSearchSuccessDate, Get-WindowsUpdateLog, Get-WinEvent, Resolve-DnsName, Test-NetConnection, Invoke-WebRequest GETs, netsh winhttp show proxy, the computer certificate store, Get-WebAppPoolState, the IIS logs, and a SusClientId comparison. Changing GPOs or targeting, starting scans, deleting client IDs, changing the WinHTTP proxy, importing certificates, renaming SoftwareDistribution, changing the app pool or web.config, IISReset, and server cleanup are deliberate changes. Change one layer at a time, test on one client first, and check current Microsoft Learn for version-specific behavior.
Top comments (0)