WSUS clients install updates properly but don’t send any status reports back to the server

Here’s a cool tip and a cool tool that was sent to me by Joe Tindale, one of the top Support Escalation Engineers in our WSUS group.  If you find that your WSUS clients are not sending status updates back to the server then this is something you’ll want to check out:


Issue: You may notice that your clients will check into WSUS and install updates properly but don’t send any status reports back to the server even though you can see that events were being generated locally.  If you review the IIS logs you may also see that the client IP addresses never attempt to post to the WSUS servers “reportingwebservice”.

We saw the following in the windowsupdate.log so we know it was generating local reporting events:

2008-02-21    05:22:58:989     668    1408    Report    REPORT EVENT: {91CFE792-1064-473B-8AA0-C9E392F2E76C}    2008-02-21 05:22:53:989-0500    1    162    101    {671ACCFF-0C42-4DDF-AF69-50DA8004EC29}    100    0    AutomaticUpdates    Success    Content Download    Download succeeded.
2008-02-21    05:22:58:989     668    1408    Report    REPORT EVENT: {1060A038-6F4D-49BB-9CA6-E02FADD13DE9}    2008-02-21 05:22:54:001-0500    1    188    102    {00000000-0000-0000-0000-000000000000}    0    0    AutomaticUpdates    Success    Content Install    Installation Ready: The following updates are downloaded and ready for installation. This computer is currently scheduled to install these updates on ?Friday, ?February ?22, ?2008 at 3:00 AM:  – Definition Update for Microsoft Forefront Client Security (Antimalware 1.27.6904.0)

What we didn’t see was something like the following which would tell us that the client was uploading those reporting events to the WSUS server:

2008-02-16    00:39:00:494     668    8d0    Report    Uploading 2 events using cached cookie, reporting URL = http://some_WSUS_server/ReportingWebService/ReportingWebService.asmx
2008-02-16    00:39:00:932     668    8d0    Report    Reporter successfully uploaded 2 events.

Even if you try forcing a report and taking a network trace you’ll never see any traffic to the reportingwebservice. 

Note: You can force a report from the command line with the following: wuauclt /reportnow

Cause: This can occur if ConfigMgr 2007 had been previously installed on the server as a Software Update Point (SUP) and Automatic Update reporting events was set to “Do not create WSUS reporting events”:


Note: These settings were added specifically for ConfigMgr 2007 to reduce the number of reporting events sent back to the WSUS server.  This configuration sets a value within WSUS and then WSUS tells the Automatic Update agent on each client to configure reporting accordingly.

Resolution: In my case ConfigMgr 2007 had already been uninstalled so we could not revert the setting back to “Create all WSUS reporting events” unless ConfigMgr 2007 was reinstalled, however the above settings are exposed via a “clientreportinglevel” property of “IUpdateServerConfiguration” so  I wrote a tool to configure the various members of this property:

All = Clients should send all reporting information to the server
None = Clients should not report update status or activity reports to the server
StatusOnly = Clients should send update status reports to the server, but not activity reports.

For more information on these properties see:

The tool I wrote has a “/?” option which will display the help menu.  It first displays the current reporting level and then gives you the options to change the reporting level:

C:\Users\Administrator\Desktop>WSUS_Reporting_Level.exe /?

Current Reporting Level: All

Please enter a numeric option:
Press ‘1’ to set the client reporting level to ‘ALL’.
Press ‘2’ to set the client reporting level to ‘NONE’.
Press ‘3’ to set the client reporting level to ‘STATUS ONLY’.
Press ‘4’ to exit.

Once you set the clientreportinglevel to “All” the clients should start to send status reports within a short period of time.

To download my WSUS_Reporting_Level tool visit


Keep in mind that the standard disclaimers apply (e.g. Microsoft has not fully tested this tool, use at your own risk, we make no warranties or guarantees as to the suitability of this tool, etc. etc.).

Thanks Joe!

J.C. Hornbeck | Manageability Knowledge Engineer