IntroductionUsing a versioning method for the various task sequences in use should be a must-have for everyone. However, I still see it from time to time to be either forgotten completely or implemented in a fashion that makes reasonable reporting a mess.
My goal of this post is to show you a straightforward and reliable way to implement a versioning in all of your task sequences. I will provide you with a PowerShell script that you can use to store all required task sequence information in the local client’s registry in order to make it eligble for the SCCM hardware inventory and reportable via SQL.
The script is designed to get easily adjusted for running in different environments (e.g. different customers or different staging environments).
General informationLet’s start with a few notes:
- The script creates a log file. The path of log file is determined by the value of the built-in task sequence variable
_SMSTSLogPathduring script execution. Logging is based on a function from @wasserja. You can find the most current version of it at the Technet Gallery. If you like to have more information about the function, please also check his blog at http://mrautomaton.com
- The script generates registry entries based on the following built-in task sequence variables:
Further information can be found within the SCCM documentation, check: Task sequence built-in variables in System Center Configuration Manager
- All variables are prefixed. The prefix is defined by the custom task sequence variable
OSDPurpose. Having that, you can vary the value of that variable in order to distinguish between all your client installation iterations.
- Additionally the custom task sequence variable
[String]is supposed to be used as a version number for reporting purposes.
Using the scriptBefore we go on, download the source files first: OSD-Version on Github. The repository contains 5 source files; each with a quite descriptive naming:
The PowerShell script that writes the information into the client’s registry.
An example file to extend SCCM hardware inventory classes.
An example file to import the previously added classes into your client settings.
An example registry file, which you can use for testing without having to re-install your client.
A SQL query that demonstrates how you can build a report based on hardware inventory information.
- Create a SCCM-Package. You do not need a program within that package but it has to include the PowerShell script file.
- Add the three task sequence variables (see screenshot), that the script requires:
- Now add a “Run PowerShell Script” step to an appropriate location in your task sequence (it has to be outside WinPE). Within the step, link it to the previously created package, fill in the name of the PowerShell script file and provide the following parameter:
Extending hardware inventoryAs soon as your client is re-installed (or as soon as you have imported the example registry file) the information are written to the local registry. In order to get them collected by SCCM hardware inventory you can then use the well known tool written by Mark Cochrane: RegKeyToMof. There is nothing special to consider, except the fact that the x64 keys are not needed – so make sure that the setting in the tool is disabled. Now that you have created your .mof-files (you can also use the sample files from the Github repository) it’s time to import them:
- Create a backup of your “Configuration.mof”-file. You can find it within your SCCM installation directory on a primary site at the following path: “Installation-Directory\inboxes\clifiles.src\hinv”
- Open Configuration.mof and copy/paste the content of the first file created by the RegKeyToMof tool to the “AddedExtensions” area at the end of the file.
- Open the default client settings from within the management console (even if you have custom client settings, always do the import into the default client settings). Open the hardware inventory section and import the second .mof-file.
- Refresh the machine policy and trigger the hardware inventory cycle on the client afterwards.
If everything worked as expected, you can open the resource explorer for the client from within the management console and check if the OSD version information is available. In case you might have any troubles, you can check the following blog post, which describes the usage of the tool in a more detailed way: How-To RegKeyToMof
SQL ReportingIf you want to collect the data for all of your clients, a SQL-based report is the way to go. Use the following query to build it (note that I’m explicitly asking for version 1.0.0. in this example):
SELECT dbo.v_GS_OSD_Version0.Deploy_ReleaseVersion0, dbo.v_GS_OSD_Version0.Deploy_TasksequenceName0, dbo.v_GS_OPERATING_SYSTEM.InstallDate0, dbo.v_R_System.Name0, dbo.v_GS_OSD_Version0.ResourceID, dbo.v_R_System.Operating_System_Name_and0 FROM dbo.v_GS_OSD_Version0 INNER JOIN dbo.v_GS_OPERATING_SYSTEM ON dbo.v_GS_OSD_Version0.ResourceID = dbo.v_GS_OPERATING_SYSTEM.ResourceID INNER JOIN dbo.v_R_System ON dbo.v_GS_OPERATING_SYSTEM.ResourceID = dbo.v_R_System.ResourceID WHERE (dbo.v_GS_OSD_Version0.Deploy_ReleaseVersion0 LIKE '1.0.0')
Ok, that’s it for the moment. I hope that this post has been useful to you. In case you have any troubles or if you find any mistakes, please do not hesitate to leave me a comment.