I’ve run into another very annoying WSUS bug and this one deals with Computer Model information being corrupted when being entered into the SUS DB.
Crashing groups highlighted in red.
Twice I’ve encountered a bug where
the WSUS console would crash every time I tried to browse the All Computers or Unassigned Computers groups, but it wouldn’t crash when I browse another sub-group.
I found a very useful blog post that showed how to fix it but I’m unable to find it now; however, I was able to remember the steps I took.
Using SSMS, export the table tbComputerTargetDetail to a csv. (Select * query, then save the results as csv.)
Sort the various columns to find the one with the box (like an unknown character). This is the corrupt entry. For me, its always been the ComputerModel field.
A similar example. Note the TargetID #.
You can use the TargetID number in the tbComputerTarget table to find out the hostname of the offending machine for a permanent fix.*
WHERE TargetID = '<targetid#>'
Blank out this field.
WSUS will be working again.
*To fix this issue on my client machines, I’ve only needed to update the offending machine’s BIOS.
While rebuilding WSUS (once again) I discovered another snag. When first configuring WSUS I put in “D:” for the drive to store the updates because the wizard didn’t like “D:\”. Unfortunately,
both are wrong. From what I read in various posts, the wizard used to default to the largest drive with free space and append \WSUS for a directory. If you just specify “D:”, the updates try to download to D:WsusContent and not D:\WsusContent. (The eventlog shows this.)
A comment on this blog post helped fix it without a reinstall: wsusutil movecontent D:\WsusContent D:\WsusContent\movelog2.log -skipcopy
After a reboot (and waiting, as WSUS isn’t very speedy) , the updates started downloading.
For future installs:
don’t specify the just the root of a drive, specify a subdirectory like “D:\WSUS”.
PS: here’s what the log file says:
2017-04-07T21:04:23 Successfully stopped WsusService.
2017-04-07T21:04:23 Beginning content file location change to D:\WsusContent
2017-04-07T21:04:23 Did not copy files due to -skipcopy flag.
2017-04-07T21:04:23 Successfully changed WUS configuration.
2017-04-07T21:04:24 Successfully changed IIS virtual directory path.
2017-04-07T21:04:24 Successfully removed existing local content network shares.
2017-04-07T21:04:24 Successfully created local content network shares.
2017-04-07T21:04:24 Successfully changed registry value for content store directory.
2017-04-07T21:04:24 Successfully changed content file location.
2017-04-07T21:04:25 Successfully started WsusService.
2017-04-07T21:04:25 Content integrity check and repair...
2017-04-07T21:04:25 Initiated content integrity check and repair.
I had to rebuild my SUS server because the old one was still on Win2008 (x86) and I couldn’t get any of the Win10 Anniversary Edition updates.
After rebuilding the server, everything is going great. The service is installed, the updates are downloading, and I see that there are updates for the SUS server pending. So I apply them and reboot.
And the updates breaks SUS and the SUS Console giving me a constant “Reset Server Node” error.
this post with details to fix it. KB3159706 needs some post install steps done to unbreak SUS. (Why can’t these post install steps can’t be done automatically or with a warning?)
Summary of the fix:
Open an elevated Command Prompt window and run:
“C:\Program Files\Update Services\Tools\wsusutil.exe” postinstall /servicing Install
HTTP Activation under .NET Framework 4.5 Features Restart the WSUS service.
Also, don’t forget to add the port (:8530) to the GPO:
(I haven’t configured SSL yet. It is recommended, and it does change the port to 8531.)