Tattoo and inventory the registry

OBS: This post is primary about how to tattoo the registry with any given information, and then inventory it with SCCM2012.

In need of knowing when a client got it’s OS intalled/reinstalled? Read further. There is no built-in feature in ConfigMgr, that quickly enables you to find that piece information, which basically means we have to make our own.

In following post I will explain what I do, using hardware inventory in ConfigMgr 2012.

First off, we have to make sure that the information we need, in this instance, the date of OS deployment is created during the actual installation. This can be achieved in various ways. I choose to add an entry to the registry.

Running following commandline from within your OS task sequence does just that:

reg add “HKLM\Software\COMPANYNAME” /v InstallDate /t REG_SZ /d “%date%”


With this in place, we have what we need on the clientside. The command will leave a trace of the actual date of when the computer got installed.

Now we need to tell ConfigMgr how to use this, and for this I use hardware inventory.

Hardware inventory means changes to the configuration.mof. Download and use RegKeyToMof will make your life easier on this one: Download here

What you basically need to do, is to browse your way to the registrykey you wish to inventory. In this case HKLM\Software\COMPANYNAME\ and check off InstallDate. RegKeyToMof will automatically generate the necessary snippet of code to be inserted into the configuration.mof file and for your Client Settings in the ConfigMgr console.



Client Settings:


Now update the client’s policy, run a new hardware inventory cycle and monitor the log files. InventoryAgent.log on the client, and dataldr.log on the server are relevant in this case. Datalgr.log vil start updating once the changes to configuration.mof has been done.

If everything goes as expected, you will be able to run a resource explorer on the client from the ConfigMgr console, and see something similar to this:


And finally from here, you will be able to use this information in queries or even build a report, and this way locate clients which haven’t been reinstalled for a long period of time.


Edit default user registry hive

You can apply registry settings in various ways, but sometimes you might consider making a setting default, not only for the current users of a computer, but also for every new user. This is already achieveable through Group Policies you might think, and that is true. What I prefer to do however, is to make changes to the default user. You can do that during deployment of the OS, and therefore limit the changes coming from your group policies. (Awesome!)

Consider this: You have decided to show the icon for This PC on the desktop on Windows 8, and would like that for every future users of your computers in the environment.

This is what I do:

Create a simpe batch script containing following:


This will make changes to the default user, and all future userprofiles created on the computer, will have this change.

BitLocker on Windows 8.1 and ConfigMgr 2012 R2

We have decided to encrypt our harddrives on our upcoming Windows 8.1 environment using BitLocker.

I had no previous experience with BitLocker, so I started out reading and learning and eventually got it to work. All the necessary information was spread across several TechNet articles, so I decided to put together a post explaining how I did it.

1) Fortunately for me, our domain is running on 2012 servers, so no need to extend the AD schema. You have to though, if you’re running 2003 domain controllers. Here’s something about the topic on TechNet:

2) What I had to do instead, was to verify that the schema objects was there, and delegate the correct permissions on the OU where my new Windows 8.1 computers are going to be. This is explained in details on TechNet as well. Here: and here:

3) Further to that, I configured BitLocker policy settings for the Windows 8.1 clients, enabling the TPM chip to backup BitLocker recoverykeys into AD. These are the exact policies that I apply to my Windows 8.1 OU:

  • Computer Configuration > Policies > Administrative Templates > System > Trusted Platform Modul Services:


  • Computer Configuration > Policies > Administrative Templates > Windows Components > BitLocker Drive Encryption:


  • Computer Configuration > Policies > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives:


4) Configuring the task sequence in ConfigMgr was pretty straightforward. 2012 SP1 has added support for pre-provisioning of BitLocker, which means SCCM will start encrypting the disk right after partitioning of the disks, and will be done with the image. Make sure the steps are exactly as on the picture.


5) Finally I installed the BitLocker Drive Encryption Administration tools on my DC’s, which enables me to view the BitLocker recoverykeys on the computer objects in AD.


6) Deploy the task sequence to the proper collection, and make sure the TPM chip is enabled in BIOS and you are set. (You can enable the TPM chip from within the task sequence using a script provided by Lenovo. I will update this post on how to do that ASAP. Download the scripts here:

Updating KMS to activate Windows 8.1 and Server 2012 R2 hosts

As many others these days, I’m messing around with Windows 8.1 and was looking into upgrading our KMS to support the new OS.

Here’s what I did:

1) Download and install following update on your KMS host: and reboot the server.

2) Uninstall current KMS key from an elevated command prompt using: slmgr.vbs /upk

3) Install the new Server 2012 R2 KMS key also from an elevated prompt using: slmgr.vbs /ipk NEWKEYGOESHERE

4) Activate the new key running slmgr.vbs /ato

…and voila: our KMS is ready for Windows 8.1 and Server 2012 R2 🙂

Failed to resume task sequence (0x800700EA)

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 ( and R2 will upgrade them automatically.

The new boot images will look like this:


Automatic Deployment Rule and Deployment Package

*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:

Peter’s work is accepted to TechNet galleries:

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

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