Monthly Archives: February 2013

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.


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)"

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


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. Continue reading


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?


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


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.


Continue reading