Issue Summary: WSUS Client Status Reporting Issue

The described behavior indicates that WSUS clients can scan and install updates, but their status reports are not being correctly stored or surfaced in the WSUS database/console. Based on the provided information, focus should be on WSUS-side configuration, database health, and client reporting rather than basic client-side connectivity (which is already working).

Proceed with the following checks and remediation steps:

1. Verify WSUS configuration vs. Windows Update

• Confirm that clients are actually configured to use WSUS for reporting, not just for scanning.
• Check the registry on an affected client:
  • HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
  • Ensure UseWUServer is set to 1 so that the client uses WSUS and reports there.
• If WSUS is misconfigured (for example, updates are not approved or policies are inconsistent), clients may scan and install but not show usable status in the console. The article on bad WSUS setups shows that incorrect WSUS configuration can cause scans to succeed but no actionable status to appear because nothing is approved or properly targeted.

2. Confirm that updates are approved and targeted correctly

• In WSUS, verify that updates for the affected clients’ OS versions are approved for the correct computer groups.
• If the WSUS server is not approving updates or targeting them correctly, the console may show no status or stale status even though clients can scan.
• The Windows Update troubleshooting guidance notes that when WSUS does not provide proper deployment criteria, the client will scan but not receive install/download instructions, and the console will not show expected status.

3. Check for duplicate SUSClientID issues

• Even though the SUSClientID reset was already performed, ensure that there are no remaining duplicate IDs in the environment.
• The WSUS client agent troubleshooting guidance describes a scenario where only one of several clients appears in the console at a time due to duplicated SUSclientID values (for example, from imaging).
• On a sample affected client:
  1. Stop the Windows Update service: sc stop wuauserv.
  2. Delete the SUSclientID registry value under:
     • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate
  3. Start the Windows Update service: sc start wuauserv.
  4. Run wuauclt /resetauthorization /detectnow.
  5. Run wuauclt /reportnow.
• Repeat on a few affected clients and then check whether they appear correctly and maintain status in the console.

4. Check WSUS database event table size and health

• If clients can reach WSUS but status is not updating, the WSUS database may be overloaded or blocked.
• The WSUS event table tbEventInstance can grow beyond 1 million rows, causing timeouts and blocking client reporting. Symptoms include:
  • Clients failing to upload events with errors like WARNING: Failed to upload events to the server with hr = 80244008 in Windowsupdate.log.
  • SQL timeout errors in WSUS logs (SoftwareDistribution.log) referencing Timeout expired and ConnectionRead (WrapperRead()).
• Check the size of tbEventInstance on the WSUS database (SUSDB):
  1. Connect to the WSUS SQL instance.
  2. Select the SUSDB database.
  3. Run:

          select count(*) from tbEventInstance
     

  4. If using WMSDE or the built-in WSUS SQL instance, the same can be done with osql:

          "%programfiles%\Update Services\tools\osql\osql.exe" -S %COMPUTERNAME%\WSUS -E -dSUSDB -Q"SELECT COUNT(*) FROM dbo.tbEventInstance"
     

• If the count exceeds 1 million rows, automatic deletion of old events is slow and can block new status reports. In that case, reduce the table size (for example, by purging old events per Microsoft guidance) so that client reporting is no longer blocked.

5. Differentiate WSUS vs. Windows Update issues

• Since updates install successfully, the Windows Update engine on the clients is likely healthy.
• To confirm that the issue is strictly WSUS-related:
  • Manually download and install a test update from the Microsoft Update Catalog on an affected client.
  • If manual installation succeeds, this aligns with guidance that the problem is likely WSUS configuration or communication, not the WU service itself.

6. Validate scheduling and policy for reporting

• Ensure Group Policy settings for Automatic Updates are configured so that clients regularly scan and report to WSUS.
• WSUS uses approvals and deadlines plus Group Policy scan/install schedules to control when clients install and report. If policies are misconfigured or disabled, clients may not send regular status reports even though they can install updates when manually triggered.

7. If the issue persists

• Collect logs from affected clients (WindowsUpdate.log) and WSUS server logs (SoftwareDistribution.log) around the time clients are expected to report.
• If SQL timeouts or WSUS database issues are visible, prioritize database cleanup and performance tuning.
• If no database issues are found and SUSClientID duplication is ruled out, follow the WSUS client agent troubleshooting article end-to-end for deeper diagnostics.

References:

• Client computers do not report back to the Windows Software Update Services (WSUS) server
• Troubleshoot issues with WSUS client agents
• Determine whether WSUS configuration causes WU installation failures
• Windows Update issues troubleshooting
• Managing WSUS Client computers and WSUS computer Groups
• Some computers do not receive updates from the WSUS server
• WSUS SelfUpdate service doesn't send automatic updates