Monthly Archives: January 2012

SCCM OSD: Installing multiple hotfixes quickly (.msu & .msp) quickly

Imagine yourself the following situation:

You are deploying Windows 7 using SCCM OSD.

You have performance issues which requires you to install let’s say >10 hotfixes.

The hotfix files that need to be deployed have the extension .msu or .msp.

You  create a package which contains all the hotfix files.


For every hotfix you create a program.

The command line used for a .msu hotfix: wusa.exe <hotfix>.msu /quiet /norestart

The command line used for a .msp hotfix: msiexec.exe /p <hotfix>.msp /qn Reboot=ReallySupress

You create a Task Sequence to deploy the hotfixes to all existing workstations and you edit your Task Sequence(s) to include them in your deployment.


Now here’s the problem:

If a hotfix is installed it may generate success code 3010 which will initiate a reboot.

If the list is pretty long then it running the Task Sequence might take a lot longer than really necessary.

Even though the reboot has been suppressed in the command line, the reboot request (which occurs after success code 3010) will still be initiated as is described here:


This is a design limitation of SCCM 2007.

Side note: I expect this behavior to be the same in SCCM 2012 but I haven’t tested this yet.

You could modify the sitectrl.ct0 file but this is not supported by Microsoft.



The solution:

Instead creating each task of type ‘Install Software’, you need to choose type ‘Run Command Line’

Each command line contains the same command as mentioned before.

You need to select the package that contains the hotfix files.

At every task you can define your own success codes, by default the codes 0 and 3010 are already present.


SCCM 2007 Operating System Deployment: Auto-Apply drivers vs. Driver packages, a personal opinion…

A number of times I’ve been involved in implementing SCCM 2007 in organizations.

Some of them I designed and implemented myself, others I only implemented or did some reviewing only.


One of the most challenging parts of OSD is having drivers installed.

Two types of drivers exist:

  • ·         ‘Good’ drivers: drivers that can be installed using an .inf file
  • ·         ‘Bad’ drivers: drivers that can only be installed using a setup program


For the ‘bad’ drivers I’ll cut it short.

There’s not much choice than making sure the setup program runs correctly in order to have the driver installed.


For the ‘good’ drivers I prefer to use the ‘Auto-Apply drivers’ method.

Quite a bunch of hardware manufacturers have built a driver suite which uses the principle of ‘one driver – many hardware models’.

Good examples are Intel, AMD and nVidia just to name a few.


This allows you to import a limited number of driver files, put them all in just one driver package and have the ‘Auto-Apply drivers’ task figure it out.

Clients will just grab the available drivers they need and will install them properly.

The driver package will just function as a big pool of drivers which client machines can during deployment.


This opinion is based on experience with SCCM 2007.

I haven’t had the opportunity to figure it out with SCCM 2012, I’ll get back to it when I have figured it out…


SCOM 2007 R2 monitoring directories for application logfiles

Applications might have the tendancy to generate logfiles for application specific purposes.

It is possible to monitor the directories and receive alerts when one or more files are created.

Unfortunately, SCOM itself doesn’t provide this functionality…


Fortunately, the File System Management Pack which was custom built by someone named Jaime Correia allows monitoring the presence of files in specified folders.

Not only is the Management Pack free to use, a very comprehensive user guide is written as well which will allow easy monitoring of files.

This Management Pack makes creating complicated scripts obsolete.

The Management Pack and manual can be downloaded at the following location (registration required):


In this Management Pack all settings are disabled.

This is good because it prevents a large collection of data which will be stored in SCOM database and allows narrowing down to only monitor the directories needed.


The user guide is self-explanatory and should get you going when monitoring logfiles.

Steve Thompson [MVP]

The automation specialist

Boudewijn Plomp

Cloud and related stuff...

Anything about IT

by Alex Verboon

Deployment Made Simple

Modern Workplace

Azure, Hybrid Identity & Enterprise Mobility + Security

Daan Weda

This site is all about System Center and PowerShell

IT And Management by Abheek

Microsoft certified Trainer -Abheek

Heading To The Clouds

by Marthijn van Rheenen