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.

PackageProp

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)
[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.

HWInven

ImportMof

KRSoundDriver

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

Enjoy!