The related threads are 2 years old. I am new to WSUS. I am trying to figure out why some computers are showing this message. How would I go about trouble shooting and fixing this. Thanks
While there are several related threads here that may be somewhat aged, I can tell you that fundamentally the reasons for computers not reporting have not changed.
The starting point for this issue is to always inspect the WindowsUpdate.log and see what is actually happening.
The most common causes are:
1. The client is not actually configured to be a WSUS client. Typically this occurs as a result of either the GPO not being linked to the correct OrgUnit(s), or the client not being a member of the correct OrgUnit(s).
2. The client cannot communicate with the WSUS server. This can happen because the URL in the GPO is incorrect, not resolvable, or not accessible. These specific possibilities will be revealed by the entries in the WindowsUpdate.log
3. There are multiple clients with identical SusClientIDs. In this case you see
some (but not all) of the clients reporting, and if you pay special attention you'll notice that the quantity of clients reporting stays the same, but the names of those clients changes regularly. This issue is discussed, and resolution provided, in
4. The client is registered (can communicate with WSUS), but isn't actually detecting/reporting. This is typically the scenario when you have computers listed in the console, but the Last Reported Date is empty, and you get the subject message. Typically
this occurs in one of three scenarios:
The WSUS server is misconfigured or broken, and cannot accept the client detection attempts. This will be reflected in the WindowsUpdate.log.
The client is unable to selfupdate -- either because the client is broken, or the server's selfupdate feature is broken.
The client is already running the latest Windows Update Agent, but the WSUS server has not been patched with the latest WSUS patches, or the installation of those patches failed. There are very specific error messages that indicate this scenario, and have
been discussed in this forum at least once a month during most of the 2nd half of 2012.
In any of those scenarios, though, Step #1 is always to review the WindowsUpdate.log on the client system to determine what actually IS happening.
slide deck, from a webcast I did a few years ago, covers the commonly known error codes in more depth.
Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
SolarWinds Head Geek Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2013)
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.
Microsoft is conducting an online survey to understand your opinion of the Technet Web site. If you choose to participate, the online survey will be presented to you when you leave the Technet Web site.