?

Log in

No account? Create an account

Previous Entry | Next Entry

WSUS help

This is more for my reference, and if Googlebots finds it, others as well...


WSUS clients not appearing in WSUS
When a computer first connects to WSUS, it updates the Automatic Updates client to the latest version. At the time of this writing, that client version is 5.8.0.2469. You can find exactly what version the client is running by searching the %windir%\WindowsUpdate.log file (notice no space - the one with the space is the legacy client) for the last intance of "WU client version". You can also check this by running the Client Diagnostic Tool, which is a handy tool to have in the arsenal anyway.

After the client has been updated, the computer information is supposed to show up in WSUS. However, there are many times when it doesn't. Come to find out that the new Automatic Updates client has it's own SID-like creature called a SUSClientID. So, if you are using an image that had previously connected to a WSUS server, and the image was not sysprepped with a -reseal option, you have the same SUSClientID on all machines that came from that image. Also, if you aren't running sysprep at all, you have the same SID for Windows itself, which is used in generating the SUSClientID.

Luckily, this isn't as horrible as it might sound. If you don't use sysprep at all, you should. You might want to look at SysInternal's NewSID, and you can use that at your own risk.

If all you are needing is to change the SUSClientID, the good news is that the information is kept in the registry. All you need to do is delete the following registry keys

HKLM\Software\Microsoft\Windows\CurrentVersion\Windowsupdate
AccountDomainSID
SusClientID

After that, reboot the machine. When the Automatic Updates service starts, it will notice that it has no SUSClientID. It will connect to the defined server, and be issued a new SUSClientID. To expedite this process, type in the following command: wuauclt.exe /resetauthorization /detectnow

If the machine still isn't showing up within a reasonable amount of time, then you may have a server configuration issue, client configuration issue, or network based issue. That, right now, it outside the scope of this post. However, from the client, trying to get to http://your-sus-server/iuident.cab might give you some clues. (Obviously (?), change the server name for your environment...)



Approved updates not installing
Here are some of the fixes I have done to get the installs to perform, especially after seeing error codes 80070002 and 80070003.
- Reauthorize yourself. wuauclt.exe /resetauthorization /detectnow Learn it. Use it. Love it. Oh, but that's XP SP1 or higher only... =(
- Delete the downloaded files. These could be found in a variety of locations: \WUTemp, %windir%\SoftwareDistribution, and possibly \Program Files\WindowsUpdate. You will likely need to stop the Automatic Updates client prior to doing this.
- Manually apply one update. It might sound silly, but you need to find out if the problem is WSUS or the client machine itself. A lot of times, the 8007000x errors are the equivilent of "File not found". Many times, I've seen manually applying the update also results in the error. Therefore, your problem isn't WSUS.
- Panic. I'm still working through this right now, so this will be updated as I find more info.




BITS not starting
Assuming you've already made sure that BITS is installed, it may be that something isn't registered. Head to "the dark place" AKA the Command Prompt and do the following:

regsvr32 oleaut32.dll
regsvr32 jscript.dll
regsvr32 vbscript.dll
regsvr32 msxml.dll
regsvr32 softpub.dll
regsvr32 wintrust.dll
regsvr32 initpki.dll
regsvr32 cryptdlg.dll


Time to reboot! After that comes the ol' faithful command: wuauclt.exe /resetauthorization /detectnow

Tags:

Comments