Excluding unwanted updates from ADR

In a previous post I wrote about how to uninstall (or “Approved for Removal” in WSUS terms). But how do we exclude updates from appearing in our Software Update Groups (SUG) created by out Automatic Deployment Rules (ADR)?

Before you’re asking, of course I’m using ADR’s for patching the whole environment! Everyone should!

Problem

A week after we deleted KB123456 from our deployment it reappeared. Since we know that this is a production breaking update we do not want it to appear in our update deployments.

Solution

To understand how to solve this we first need to understand how ADR works. I won’t go into detail about the mechanics and logs related to ADR, but the key fact that needs to be known here is:

Each time an ADR runs it completely regenerates the SUG associated with the ADR.

64-bit script execution in SCCM

Pushing out scripts with SCCM can, depending on your environment, be a bit of a hassle. Even if the script runs perfectly from the cmd/powershell console on all the target computer it’s not a guarantee it will run smoothly when distributing the script through SCCM.

Problem

We’re trying to install Type 1 Format fonts with the following non-signed powershell script named “Install.ps1”:

$sa = New-Object -ComObject Shell.Application
$pathFonts = "$(Get-Location)\Fonts"
$pathDest = "$env:windir\Fonts"
$folder = $sa.Namespace($pathFonts)
$fonts = Get-ChildItem $pathFonts *.PFM

foreach ($font in $fonts) {
	$testpath = "$pathDest\$($font.Name)"
	if ((Test-Path $testpath) -eq $false) {
		Write-Output "Installing font: $($font.Name)"
		$folder.ParseName($($font.Name)).InvokeVerb("Install")
	}
}

In short the script will scan a folder for .PFM files and do a Right-Click -> Install action on the object. This script is called from a Package/Program with the following command line:

powershell.exe -executionpolicy bypass -file .\Install.ps1

When testing this script we notice that it’s installing the fonts on Windows 7 x86 but it’s not working properly on Windows 7 x64. When looking deeper into what the script is doing on Windows 7 x64 we notice the following:

• Script output tells that the fonts install successfully
• We’re unable to locate fonts under C:\Windows\Fonts
• Font files are located under C:\Windows\Fonts when using dir
• Registry values are located under the Wow6432Node

Solution

The SCCM programs are per default started from a 32-bit command-line. To get around this problem we need to run the script in a 64-bit environment. What we’re essentially doing to work around this problem is starting the 64-bit executable from the 32-bit command line. Since the powershell.exe is located under the System32 folder we’ll have to use the sysnative folder.

Managing production breaking updates in SCCM 2012

If you’re managing updates through SCCM 2012 with the help of Automatic Deployment Rules (ADR). Why wouldn’t you? I mean, what could possibly go wrong? There’s no need for pre-prod testing!

It’s a couple of days past patch tuesday, the new patches are deployed and installed. This is when you get the dreadful call about how a production application broke over night. Ooops?

Problem

Patch KB123456 has been installed into the production environment and it broke core functionality.

Solution

This is resovled by creating a package with an uninstall program which is deployed to the collection with the affected devices.

1. The Collection

Navigate into the Asset and Compliance workspace and create a new Device Collection.