Deploying Security Only Updates for SCCM 2012 and Excluding Rollups

Excluding Windows Rollup Updates from SCCM Software Updates

Microsoft’s new servicing model pushes a new style of updates starting 10/11/2016. A security only update that contains all security fixes in a single update and Security rollup update containing this month’s fixes plus fixes from last month. The plan at MS is to retrospectively, reach back and add more of the past updates with each rollup update going back all the way to Windows 7 SP1.

A great explanation by Michael Niehaus can be found here. More on Windows 7 and Windows 8.1 servicing changes

Organizations that use WSUS can enable “express installation files” to make sure PCs only download the pieces they need from each Rollup update, thus keeping download size to a minimum. Those that use SCCM 2012/ConfigMGR 2012 are not so lucky as it has no support for such feature and the whole rollup will have to be downloaded.

I chose to go ahead with security only updates to avoid this issue. This involed excluding two types of updates: .NET Security and Quality Rollup, and Security Monthy Quality Rollup.

I ran into a problem trying to exclude both types of updates in the All software updates section of SCCM console.

Excluding one string “and Quality” works fine as you see below, .NET Rollup is taken out.

Trying to exclude Monthly Quality as well breaks the exclusion entirely. Numerous variations did not succeed.

Fortunately the ADR Property filters offer another option, exclude multiple strings from Title with just the minus sign in front.

Here is the wanted result, Security only updates for Windows 7 and .NET and NO Rollups.

Autochk program not found skipping AUTOCHECK - Windows 7 does not boot

Autochk program not found skipping AUTOCHECK - Windows 7 does not boot

Have you seen this dreaded error message? It is most likely to happen if you are cloning your OS to a new drive. I struggled with it for a while and just before giving up came across a posting that pointed me in the right direction.

Numerous runs of Windows Startup repair, including totally scrapping and recreating the boot list with bcdedit did not help my situation.

From startup recovery environment, choose command prompt and then type regedit. Select the Hkey_Local_Machine hive, click File>Load Hive and browse to the newly cloned drive/partition going to Windows\system32\config and pick the file named SYSTEM. Select a name under which the hive will be displayed in registry editor: system_new for example.

Note: this is your system registry hive so make a copy of it to be on the safe side.

Navigate to the HKLM\system_new\SYSTEM\MountedDevices. Look for an entry \DosDevices\C: as shown below. 
In my case it was missing and windows was failing to recreate it. I guess some users are lucky enough to just delete the whole MountedDevices key and Windows will recreate it correctly. Well mine did not.
No wonder autochk was not being found, there was no entry for C:

You need to create the entry for drive C:\. It will be one of the volumes listed in the first section as highlighted in the screen shot. To know which one, from your command prompt window type diskpart. Type list disk - this will show you attached disks. Look at the size to determine which one is your new disk and then type sel disk 0 (in my case it is 0). Then type uniqueid disk - this command with show you the disk ID.

Compare this to the volume IDs from the registry window and try to find a matching one, as shown screen shot. Look at the first 8 symbols. In registry they are in little endian format (in pairs and go backwards) so the section 7e d7 7e d0 is actually read backwards as d0 7e d7 7e, which needs to match the id you got from Diskpart.
Once you determine that, right click in registry, new>binary value and name it \DosDevice\C:
Double click the entry that starts with \??\Volume from above and copy the first line.

Now paste that line into your newly created entry for C:\. Repeat the same for the second line. Now your new entry's data value should show the same Data as the first volume entry.
In regedit select system_new hive and click File>Unload hive. This will save your changes in registry.
Attempt to boot into Windows now.

The posting that gave me the idea to look at the MountedDevices key is located here
http://answers.microsoft.com/en-us/windows/forum/windows_7-system/windows-7-fails-to-boot-autochk-program-not-found/46a244b4-970b-4753-9bbd-002916471f87

There is also a possible problem with disk ID collisions that Mark Russinovich describes in his blog and how to fix it.

http://blogs.technet.com/b/markrussinovich/archive/2011/11/08/3463572.aspx