Deploying Service Pack 2 for Microsoft Office 2010 using ConfigMgr

Earlier in july Microsoft released Service Pack 2 for Office 2010, which means most sys. admins is about to review, test and finally deploy SP2 for Office 2010 to their Office 2010 clients. (You can read more about SP2 here:

At first SP2 doesn’t seem to be released to WSUS as it’s predecessor (Edit: It is as of now, 2014), but that is not an obstacle. You can just import it yourself.

1) On your server hosting WSUS, launch the Windows Server Update Services console.

2) Right-click on Updates and chose Import Updates.

3) Your browser will direct you to

4) Search for KB2687455 and import it to WSUS.

5) Syncronize Software Updates in the SCCM2012 console and deploy it like any other regular update.











Ps. Another option is to download the SP2 directly from Microsoft, and deploy it using an application (SCCM2012) or a standard package. You can download SP2 here:

How to install SCEP client during OSD

Some might claim that installing the SCEP client during OSD is an unnecessary step, but I’d claim otherwise.

Installing the SCEP (System Center Endpoint Protection) client as an step in your OSD task sequence, will provide instant protection against malware, whereas waiting for the automatic installation through the client policy, will leave the OS unprotected for the duration of the client policy polling interval + the time needed for the actual installation.

With that said, I’ll recommend to install the SCEP client during OSD. You can do that by seperating the scepinstall.exe from the SCCM client installation folder (\\SITESERVER\SMS_<SITECODE>\Client\) and create a standard package and program running following command: scepinstall.exe /s /q /NoSigsUpdateAtInitialExp

Distribute the package to your distribution points, and add the step to your OSD Task Sequence as any other package.

/NoSigsUpdateAtInitialExp will prevent the installation to reach out to for definitions updates, and therefore limit the WAN usage, which is considered good practice. Definitions should be installed from your Software Update Point:


Install the SCCM client using a script

There are several ways to install the SCCM client. As you know, it may be installed during OSD using a package, or the built-in push feature after discovery, but sometimes it might come handy to be able to install it using a script. (More about Client Deployment here:

Nothing really fancy, just a plain .bat file containing following information:


Replace everything in bold with your own details.

Cannot install applications during OSD – the task sequence fails

During configuration of our new SCCM 2012 environment, I had this annoying error in my smsts.log when installing applications during OSD. Note that the applications did install fine to an existing OS, but would still fail when installed during OSD with following error:

Execution status received: 24 (Application download failed)

I found a temp. solution in changing following setting on the application deployment type to “Download content from distribution point and run locally”. This is a setting related to slow or unreliable networks, and my client is on the same network as my distribution point.


I redid my boundaries and boundary groups several times, and applications would install fine during tests, besides when installed from OSD.

It turned out to be quite simple. In this case the computer failed to be joined to the domain, but that will not break the TS. The download of applications will when using AD sites as boundaries. No domain = no AD sites = no working boundaries.

Extending hardware inventory in SCCM2012

Following is a post on how to extend the hardware inventory in SCCM2012. This is a tad different from 2007, and is very useful if you e.g. wants to know what sound drivers that are currently installed in your environment, and based on that knowledge, wants to update the very same driver. (Note: This can be done with pretty much any driver. Just extend the HW inventory as necessary)

First off, you need to locate where this information is stored. All driver classes are stored in the registry as a subkey to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class and in this instance the sound driver is {4D36E96C-E325-11CE-BFC1-08002BE10318}.

With this in place, you have to decide what regkeys you find relevant to inventory. In this example following keys is relevant: DriverDate, DriverDesc and DriverVersion. Inventorying these keys will tell you information about the date, description and version of the sound driver on any system in your environment. (Note: The keys to inventory might differs from OS to OS. This is done in Windows 7)

So, I know what to inventory – how do I do it?

1) First off you need to stage your clients the ability to know HOW to report. This is done on your CM2012 server where you browse to <install location>\inboxes\clifiles.src\hinv and edit the configuration.mof (I’m usually making a backup manually before editing this)

2) In the bottom of the configuration.mof file you find the below section. It’s in this section you will add your edits (My edits in italic). You will recognize the path of the registry keys, and the name of the subkeys to inventory.

// Added extensions start

pragma namespace (“\\\\.\\root\\cimv2“)
#pragma deleteclass(“KRSoundDrivers”, NOFAIL)
[dynamic, provider(“RegProv”), ClassContext(“Local|HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Class\\{4D36E96C-E325-11CE-BFC1-08002BE10318}”)]
Class KRSoundDrivers
[key] string KeyName;
[PropertyContext(“DriverDate”)] String DriverDate;
[PropertyContext(“DriverVersion”)] String DriverVersion;
[PropertyContext(“DriverDesc”)] String DriverDesc;
[PropertyContext(“Driver”)] String Driver;

// Added extensions end

3) When doing changes to configuration.mof I strongly recommend to monitor the dataldr.log. Immediately after saving your changes, the log file will show following entry: Configuratin.Mof change detected. The entries following will tell you if your changes got accepted or rejected. If they got rejected you most likely have got something wrong in your spelling, or in your C/P.

4) Assuming everything is fine so far, it’s time to tell the clients WHAT to report. This is done in the Client Settings in your CM2012 console (Administration -> Client Settings). Open up Notepad, and C/P below text and save it as SoundDriver.mof. This will be imported into your Client Settings in CM2012

#pragma namespace (“\\\\.\\root\\cimv2\\SMS“)
#pragma deleteclass(“KRSoundDrivers”, NOFAIL)
Class KRSoundDrivers: SMS_Class_Template
[SMS_Report(TRUE),key] string KeyName;
[SMS_Report(TRUE)] String DriverDate;
[SMS_Report(TRUE)] String DriverVersion;
[SMS_Report(TRUE)] String DriverDesc;
[SMS_Report(TRUE)] String Driver;

5)  Import the SoundDriver.mof to the Client Settings. Follow the screenshots.




6) Verify the changes on the client. Refresh the policy on the client, and run a HW inventory. Monitor the InventoryAgent.log to verify the changes being picked up. Running a resource explorer on the client will now show this, and everything is OK:

Resource Explorer


ConfigMgr 2012 client update during OSD

After updating my ConfigMgr 2012 SP1 with the latest CU from Microsoft (, a new update for the console and client was created as well. These can be distributed to the distribution points and deployed as any other packages, everything quite easy.

What you might want to consider as well, is to make sure that the ConfigMgr client is updated during OSD for new installations. This is done through the step ” Setup Windows and Configuration Manager” in your task sequence.

Different from ConfigMgr 2007, the hotfixes for the client is no longer created within the existing client installation package directory (<SCCM2012 Install Directory>\Client), but is instead created in <SCCM2012 Install Directory>\Hotfix>. What does it mean? It means that you have to modify the existing client package, or create a new, to be able to patch the ConfigMgr client during the mentioned step in your task sequence.

I will explain in steps what I did:

Step 1: Install the CU, and verify that the client packages is created.

Step 2: Copy the actual hotfix from the hotfix folder (<SCCM2012 Install Directory>\Hotfix\KB2817245\Client\i386\configmgr2012ac-sp1-kb2817245-i386.msp), and create a new subfolder to the client installation folder called Hotfix. (<SCCM2012 Install Directory>\Client\i386\hotfix). Put the copy of the hotfix in this folder, and update the package on your distribution points.

Step 3: In the step “Setup Windows and Configuration Manager” of your task sequence, make following installation properties: PATCH=”%_SMSTSMDataPath%\OSD\<replace with client package id>\i386\hotfix\KB2817245\configmgr2012ac-sp1-kb2817245-i386.msp”