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.

0xc0000098 Error PXE booting a client in SCCM 2012 R2

Our SCCM PXE boot system broke recently, and started flagging up the above error code- something about the \tmp\x86x64{…..}.bcd file not containing a valid OS entry for the client.

Went through everything I found on the internet: stopped PXE, watched WDS uninstall, Rename RemoteInstall, start PXE, watch WDS re-install, delete all the boot images, re-import boot images, uninstall ADK8.1, reboot, re-install ADK8.1 etc etc. Nothing, which was getting more and more frustrating.

Turns out… I think either the existing boot images had been corrupted, or the task sequences had lost their link to the boot images, or both.

(1) disable all existing task sequences- just disable so they’re there when things work again;

(2) delete the existing boot images from SCCM, extract known good ADK boot images for x86 and amd64 using copype.cmd;

(3) Re-import these two boot images, alter them so they respond to PXE requests, distribute them to whatever DPs necessary (we only have one SCCM server doing everything). Make sure they are the real ADK boot images- they should only offer a single image, which is WinPE- trying to use an OS Boot image that has a second, Setup image can cause problems;

(4) At this point, PXE should boot but will exit straight away as there are no advertisements- this is a good thing;

(5) pick a task sequence, enable it, right-click it and choose properties, then go to the advanced tab and point it to the right boot image (x64 for a 64-bit OS, x86 for a 32-bit OS);

(6) with a bit of luck, you can boot into WinPE and get your chosen task to display in the menu. If this works, just go around pointing all other task sequences at the correct bit version and re-enable them;

I still have absolutely no idea why this broke- if I hadn’t got way-laid by all the “get-rid-of-PXE-WDS-ADK-and-put-them-back-again-posts” on the internet I might have looked more cautiously first and either spotted the task sequences not having a boot image, or the boot images themselves being corrupt or inappropriate in some way.

It’s really important to get just a single-image WinPE boot WIMs from the ADK; I know you can use and create other WIMs, but I got into a knot where my x64 OS boot WIM insisted on using the Windows setup image in the WIM rather than the WinPE image, and actually wouldn’t let me pick the WinPE image because it told me it was already in use.

This isn’t actually all that big a deal (despite it having just swallowed 3 days of my life): start with clean ADK boot images, and point all your task sequences at one or the other. If I’d known this last Tuesday morning I’d have saved a lot of time.

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.

System Center Configuration Manager 2012 installation

Running System Center 2012 is just an evaluation project at the minute, but as with SharePoint yesterday there are a couple of things that will make life easier before trying to install it:

  • Install full blown SQL! Not Express;
  • SCCM runs a utility called setupdl.exe to download a whole raft of pre-requisite files. This utility seems to use the proxy configuration stored in inetcpl.cpl. This worked for me anyway; I messed around with netsh winhttp and the UpdDwnldCfg.exe utilities and neither worked. However, putting the right proxy settings into inetcpl.cpl worked instantly;
  • Install the Windows 8 ADK from first. You only need Windows PE, USMT and Deployment tools- this will save you (hopefully) from encountering some failures when SCCM runs the pre-requisite checks before the install;
  • Install IIS (I installed everything apart from Application Development) and Remote Differential Compression- this will prevent yet more failures;
  • You should be good to go then; the pre-req’s checker will still bring up a lot of warnings, but I really do just want this to play around with and I thought it would ne a lot easier than this (when I walk into a shop to try out a laptop, I don’t usually expect to source the screen myself and then actually put the laptop together but c’est la vie);