WSUS Clients Not Reporting: A Read-First Console, Client Policy, Proxy, and SusClientId Triage

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 same SUSclientID."
• 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 1: Capture the symptom (read-only)

Write these on the ticket first:

Then branch on what the console shows:

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:

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."

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

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:

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."

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:

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.

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:

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.

Common false starts (read these before you change anything)

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

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:

👉 https://cashflow4375.gumroad.com/l/ujkqxb?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=wsus-clients-not-reporting

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.