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

<sigh>

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- http://bit.ly/1kWoiJ5 – said it all. Under the “Setup Windows and Configuration Manager” section, just add SMSSLP=yourserver.yourdomain.com 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.

UPDATE 15AUG2014:

<sigh>

Yes, this was me being stupid. As this thread explains- http://www.windows-noob.com/forums/index.php?/topic/11126-system-center-configuration-manager-2012-build-and-capture-with-updates-gold-image/- I’d just forgotten to redistribute everything. Seemples.

System Center Configuration Manager 2012 R2 SUP Error

Strange one. I started getting loads of these:

“STATMSG: ID=6703 SEV=E LEV=M SOURCE=”SMS Server” COMP=”SMS_WSUS_SYNC_MANAGER” SYS=SRVSCCM01V.nmgw.ac.uk SITE=000 PID=2176 TID=4892 GMTDATE=Mon Jul 28 00:00:07.224 2014 ISTR0=”Microsoft.SystemsManagementServer.SoftwareUpdatesManagement.WsusSyncAction.WSyncAction.SyncWSUS” ISTR1=”UssCommunicationError: WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. —> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.~~at System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request)” ISTR2=”” ISTR3=”” ISTR4=”” ISTR5=”” ISTR6=”” ISTR7=”” ISTR8=”” ISTR9=”” NUMATTRS=0″

When synching my test SUP with WSUS. Found loads of stuff on the web about checking up on the SSL certificate assigned to the WSUS/ SUP site, checking the permissions on the ApiRemoting030 etc. Nothing worked. Turned out I’d changed its synch point from our internal WSUS to Microsoft’s web-based one, changing this back to internal resolved this error. Must be something to do with our web proxy.

Deploying Apple QuickTime 7.74.80.86 with SCCM 2012 SP1 CU2

Yet again, I’ve encountered a really strange error (bearing in mind this is an entirely test CM set-up I’ve got going). I had a few packages- Java 7-25 (both bit-versions), Office 2012 ProPlus and Quicktime. After this mornings outing, I was pretty happy- I could install Java repeatedly, and (due to an accident) re-built my Office install from scratch and it worked first time. But QuickTime wouldn’t play ball- I kept getting “The software change returned error code 0x643 (1603)”. Neither Bing nor Google were much help, so I was on the verge of giving up when- rather obviously- I spotted on some website about starting at the start and trying to install QuickTime manually on the PC. So I did this, and immediately got some spiel about there being a newer version of QuickTime installed. Now I knew this was wrong because (a) I’d just downloaded the installer this morning, so it was unlikely Apple had released another version and (b) QuickTime wasn’t installed, because Add/ Remove programs didn’t list it.

After stripping most of the QuickTime entries from the Registry (just obvious program-centric ones, I ignored anything to do with media type files using QuickTime) I retried using SCCM to push the QuickTime.msi file and that also failed. I re-stripped the Registry, created an SCCM package (not application) using the QuickTimeInstaller.exe file and it worked. I have no idea where all those Registry entries came from, I can only guess that my test PC was so messed up from having stuff installed and uninstalled that it’s corrupted.

Deploying Office 2013 with SCCM 2012 SP1 CU2

After (metaphorically) banging my head against a brick wall for some time, I’ve finally got Office 2013 installed (on-demand) as per this guide (which is excellent):

http://www.ronnipedersen.com/2012/11/how-to-deploying-microsoft-office-2013-using-configmgr-2012/

I’d tried using this guide over and over again with no success. My clients CAS log was reporting 0 distribution points, and the Software Center was either saying that the installation failed (with various error codes, one of which was 0x87d00607) or that the software couldn’t be found on any servers. The server side was just reporting that Distribution Manager couldn’t find or create… blah blah blah. I think you get the message. Anyway, at various points of searching I found- in sequence- these two pages:

http://blog.msvconsultancy.co.uk/2013/01/system-center-configuration-manager-2012-sp1-distribution-point-bug/

http://www.windows-noob.com/forums/index.php?/topic/7199-help-big-issue-with-primary-dp-after-updating-to-sp1/

Which both basically refer to

http://social.technet.microsoft.com/Forums/en-US/8e860651-4288-42c1-b04f-c6ac72dd02f1/help-big-issue-with-primary-dp-after-updating-to-sp1

The irritating thing is, I’d tried this suggestion from msvconsultancy.co.uk and it hadn’t worked because I hadn’t tied everything together. After finally (re-)finding the same info at windows-noob.com I re-configured the Site System Installation account properties, deleted the distribution point from the application, re-distributed it and then it worked very, very quickly- I think Office was installed in about 5 minutes. So a big thanks to Ronni Pedersen and Ben Kellermann for their joint effort at sorting out my Office 2013 deployment issues (I hadn’t followed Ronni’s blog exactly as I’d skipped the “Requirements” bits- I just wanted to get Office installed on a test Hyper-V machine so wasn’t that bothered about providing conditions). Ben Kellerman’s post is particularly helpful as presumably I’d have encountered these errors regardless of which program I was distributing.

Yet Another SCCM 2012 post…

I’m still having a few teething issues. I booted up a physical PXE client this morning and had that strange error from a previous post, so I assumed it might be a PXE firmware issue or something. PXE booted my laptop fine, then booted the same client and that was fine too. ?

Also, I couldn’t figure out why my work PC (Hyper-V) wasn’t really getting the SCCM agent installed properly. Looks like I’d forgotten to configure Administration > Site Configurations > Sites > sitename > Client Installation settings > Client Push Settings. Also, there was no FQDN under Administration > Site Configuration > Site system Properties, made both these changes and it all started working fine.