WSUS vs Windows 7/ Windows 8.1 client issues

We’ve recently needed to be a bit more rigorous about using WSUS, so I started off on our servers and found out that if you go with “Scheduled Installs”, what this means is that any given server can reboot pretty much when it likes with up to 30 minutes grace.

This was no good at all, so I started using a PowerShell script to do the WSUS side of things, then used a server to run scheduled tasks against a group of servers at a time. This meant that we could reboot the servers when we liked, which is around 04:00.

This was all ticking along nicely, so we opened this out to a select number of clients- mix of Windows 7 Pro SP1 and Windows 8.1 Pro. Very little happened. PCs didn’t get patched, running WSUS through the GUI resulted in the progress bar looping, PowerShell didn’t work, the Event Viewer only displayed errors and WSUS itself complained the PCs hadn’t reported for a long time, or maybe not at all.

After a week of fiddling about with the Windows Update client, deleting registry keys, deleting WindowsUpdate.log etc etc, turns out it seems there are 2 KB articles- KB3138612 & KN3138615- that appear to be critical to getting WSUS working on clients. These KBs relate to “updates for Windows Update” dated March 2016.

The long and the short of it is that it appears the best way to get Windows 7 & 8.1 working is to start from scratch: reinstall Windows from a DVD and then immediately install the relevant KB .msu file.

I tried pointing freshly-built clients at WSUS (before installing the KB) and they either just looped (Windows 8.1) or told you to install an update to Windows Update (Windows 7). This build under Windows 8.1 wouldn’t even talk to WSUS until I’d installed the KB, and I assumed the Windows 7 Windows Update Client Update was the right KB article, although it didn’t say.

I now have 3 new Windows 8.1 images: the OS by itself, the OS with KB3138615 and the OS with all available updates from WSUS. I’m doing the same thing for Windows 7. Unfortunately, this means our existing SCCM images are “fine” in that they’re patched, but it looks like they can’t talk to WSUS so our choice is either to talk to Microsoft to fix this, or re-image all our PCs with the new images. This isn’t my call, but is seriously annoying to find out when we’ve just gone around using SCCM to apply images to PCs whic won’t actually update on a day-to-day basis.


SCCM: build and capture with installed updates


Yet again, I’ve been chasing my tail with SCCM. I know my (extremely limited sub-set) Windows 7 updates package was working and downloaded, and deployed etc. I know my Build and Capture was working. But I couldn’t get updates to install as part of the build and capture process. I could build and capture a WORKGROUP machine no problem, because the SYSPREP stage requires WORKGROUP membership. I could build and capture- and update- a domain machine but this would fail to capture because SYSPREP wouldn’t work.

In the end, this link- – said it all. Under the “Setup Windows and Configuration Manager” section, just add under the “Installation properties” section. If the build machine is on the domain, it can use AD/ DNS to locate the SCCM server. If it’s in a workgroup, it needs to be told explicitly where to find services- hence adding the property above. Thanks to Mathias Haas for this, it was driving me around the bend.



Yes, this was me being stupid. As this thread explains- I’d just forgotten to redistribute everything. Seemples.

Windows Server 2003 Wuauclt command line

Finally- after a lot of misses, I think I’ve got a list of command-line switches for wuauclt.exe thanks to the SysInternals procexp.exe tool (although I don’t use all of them, the Sysinternals suite is just great…). Here goes:


If you’re wondering why I needed this, we still have a few Server 2003 boxes kicking around that don’t have the nice Updates UI that appeared with Server 2008. It’s funny, all I needed was for the server to tell me it needed a reboot to finish installing updates but I had to try a lot of the above switches before I got the right little yellow shield.

Weird Windows 8 Update error

So far I’ve only noticed this on Windows 8 Enterprise, so can’t comment as to whether this would affect any other flavour of W8. However, I decided to use my own PowerShell script (see previous post!) to update my W8Ent host. It seemed to be going fine but I kept on installing updates assuming that the reboot detection was working- which I’m pretty sure wasn’t  :)) Anyway, I went off to lunch and left my PC rebooting… and came back, only to find that the updates configuration was failing. I had to resort to powering off at the power switch, and eventually- after hammering F8 repeatedly- was able to do a system restore and it’s back to normal now (incidentally, the system restore process reported itself as having failed but it didn’t).

I haven’t had much luck identifying which particular update crashed it yet, but so far I think it’s KB2768703. There have been a lot of WER log entries relating to this update, it’s a critical update (matching the system restore title) and the timing is right. I’m going to restart doing updates, this time rebooting after each batch of updates…

EDIT 17-MAY-2013@16:34 : I’m pretty sure it is now KB2768703. This is the only KB installer that seems to crop up in the WER errors (application log), however I have noticed that Bing Desktop also generates WER errors so it may be that that is clashing. Anyway, I’m going to avoid installing the above update for now (using the Windows Update client so I can de-select it).