Martin Bengtsson

I just upgraded my SCCM 2012 environment to the latest R2-release and while everything seemed to be without obstacles, I ran into this error:

<![LOG[Failed to resume task sequence (0x800700EA).]LOG]!><time=”08:41:37.801+420″ date=”09-19-2013″ component=”TSMBootstrap” context=”” type=”3″ thread=”3256″ file=”tsmbootstrap.cpp:426″>EA)

My OSD Task Sequence got to install the OS and the SCCM client, and then just booted directly into the OS skipping the rest. No error was displayed, so I checked the SMSTS.log and saw the above error.

I was using boot images created from MDT 2012, which I thought would be OK in this case. But apparently it’s not – boot images created with MDT 2012 is no longer working and when I switched back to the default ones, my Task Sequence completed.

The new boot images comes with the new Windows 8.1 ADK (http://www.microsoft.com/en-US/download/details.aspx?id=39982) and R2 will upgrade them automatically.

The new boot images will look like this:

This blog-post from the ConfigMgr Team explains it all: http://blogs.technet.com/b/configmgrteam/archive/2013/08/23/reinstalling-cumulative-updates-in-configuration-manager.aspx

Very useful information, as you might end up in situation where a reinstall of the CU is required.

*UPDATE* This has been fixed in R2, and you are now able to select a deployment package from within the console *UPDATE*

Just a quick note on the above topic. I have created several Automatic Deployment Rules in my ConfigMgr environment, and was looking for a way to change which Deployment Package the updates was stored in. The console in SP1 doesn’t offer the opportunity, so I went to my favorite search engine and came across this blog post:

http://www.petervanderwoude.nl/post/changing-the-deployment-package-linked-to-an-automatic-deployment-rule-in-configmgr-2012/

Peter’s work is accepted to TechNet galleries:

http://gallery.technet.microsoft.com/Change-the-Package-linked-65662298

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 separating 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 Microsoft.com for definitions updates, and therefore limit the WAN usage, which is considered good practice. Definitions should be installed from your Software Update Point:

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: http://technet.microsoft.com/en-us/library/gg682132.aspx)

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

“\\SITESERVER\SMS_SITECODE\Client\ccmsetup.exe” /mp:FULLY QUIALIFIED SERVERNAME SMSSITECODE=SITECODE

Replace everything in bold with your own details.

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)
[SMS_Report(TRUE),SMS_Group_Name(“KRSoundDrivers”),SMS_Class_ID(“KRSoundDrivers”)]
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:

Enjoy!

After updating my ConfigMgr 2012 SP1 with the latest CU from Microsoft (http://support.microsoft.com/kb/2817245), 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”