Chris Sanders

 I write a lot about WSUS because I think it is a necessity for any network with Windows servers or clients. It is typically pretty easy to setup but occasionally you will run into some issues. Out of all of the WSUS issues I hear about and directly experience (and trust me, I manage a LOT of WSUS servers) the most common problem I hear is when the computers in a network simply don’t connect to the WSUS server.

Here are a few items which are the most typical causes to this problem:

Lack of Patience

This is the number one overall issue I see. WSUS is built upon a technology that is by no means instant. It takes some time for updates to download, it takes some time for Group Policy Objects to apply, and it takes some time for computer to report in to WSUS in general. That being the case, if you have just installed WSUS and are looking at this article two hours later because computers aren’t reporting in, then you most likely haven’t waited long enough. I generally tell people to wait as long as two days after installing WSUS to start looking into why individual clients aren’t reporting.

Group Policy Issues

One of the simpler problems is that either the Group Policy Object for configuring the automatic update service is not being applied or it is misconfigured. At a minimum, your GPO should be configured so that it points the automatic update service to download from the WSUS server. Make sure you don’t have any typos in this path.

You can make sure that your GPO is being applied to the computer in question by typing GPRESULT into a command prompt on one of the machines in question. Remember, the Group Policy setting for configuring automatic updates is to be applied to computer objects, not users.

Client Requirements

WSUS clients must be Windows 2000 SP3, Windows XP, or Windows Server 2003 in order to take advantage of WSUS. I’ve seen lots of cases where someone would tell me a bunch of their workstations weren’t reporting in and updating only to find out they were Windows 2000 SP2 or something like that.

Imaged/Cloned Computers

In some network most if not all of the workstations were deployed with system images via Acronis, Ghost, or some similar program. If that’s the case, there is a good chance that the WSUS ID, a unique identifier found in the registry of every computer on your network, was not regenerated. These WSUS IDs are generated based upon the SID of a computer. If you configured your image so that it would generate a new SID upon pasting then you likely won’t have this problem, but this step is commonly forgotten. The WSUS ID is stored in these three registry keys:

HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdateAccountDomainSid
HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdatePingID
HKLMSOFTWAREMicrosoftWindowsCurrentVersionWindowsUpdateSusClientId

In order to generate a new WSUS ID, you will need to delete these keys on the client machine in question. After doing this, restart the Automatic Update service and run the command “wuauclt.exe /resetauthorization /detectnow. You should see the computer in the WSUS console shortly after that.

This process may seem a bit too manual when you have to perform it on multiple computers, so there is a VB script that can automate this a bit. You can download this script here: http://www.vbshf.com/vbshf/forum/forums/thread-view.asp?tid=199&start=1. You can simply download this script and perform the aforementioned steps remotely by just entering the computer name.

This covers a few of the most common reasons clients don’t report in. Obviously, there is no way to cover every possibly avenue, but hopefully this will eliminate some of the more common possibilities. As always, I respond to direct WSUS questions via e-mail. Also, the WSUS forums over at http://www.wsus.info/ are a great community driven resource for figuring out issues like this.

Be Sociable, Share!

•