(Originally posted 11/6/2014. Reposting for reference)

This topic has come up several times on the myITforum email lists, so this seems like a good opportunity to provide an example of how to do image version control in ConfigMgr.  There are numerous different ways this can be done, so this is just an outline that should be modified or improved upon to fit the particular implementation.  Ultimately, do what works best for your situation.

This two-part series of articles will provide a method of tracking end-to-end OSD revisioning using a few simple Task Sequence tasks and an optional PowerShell script.  In this first article, we’ll look at why the out-of-box forensic information is useful but insufficient, and we’ll implement a method for version control in the core image.

ConfigMgr 2012 – Image Revisioning (Getting Started)
ConfigMgr 2012 – Image Revisioning (Deployment and Archiving)

Why Take Extra Steps?

Out of the box, ConfigMgr doesn’t really do much in the way of stamping the system with build information.  Many folks leverage MDT integration to enhance OSD functionality, and one of the benefits is the ZTItatoo.wsf script that runs as part of the “Tattoo” step and writes some specific information into the registry under HKLM\Software\Microsoft\Deployment 4.  Among the information recorded is the method (ZTI, LTI, etc.), th MDT Toolkit version, the Task Sequence advertisement and package IDs, and a timestamp.

ZTItatoo.wsf registry information

While this can be useful information, it only represents an isolated snapshot in time and it’s not in a place inventoried by default in ConfigMgr.  I can look on any given system and see the date it was built and the Package ID of the Task Sequence, but it doesn’t tell me how it might be different from a system built a day/week/month/year before. If I want to find other systems like it, even assuming I have MDT integrated and have modified inventory to include these registry keys, I still have to know a date range and a Task Sequence PackageID so that I can create a custom report to run.

Creating a Build Number

There are two primary areas to track with image revisioning: changes to the core image itself, and changes to the deployment of that image.  Ideally, both of these areas should be automated using Task Sequences.  For the purpose of this example, we’ll use a standard ConfigMgr Task Sequence for our core image build and capture, but the principles can easily be used for MDT-integrated or even MDT-only task sequences.  We’ll look at the deployment side in the next article, as well as handling archiving of Task Sequences.

Since we need to have a way to know what exactly each image revision includes, we’ll use just a simple Excel spreadsheet. We’ll use a four-part numerical sequence to track revisions in the following form: A.BB.CC.YYYYMMDD

A – This is the major OS revision, corresponding to the unique OS/platform combination. For example, 1.BB.CC.YYYYMMDD would be Win7x86, 2.BB.CC.YYYYMMDD would be Win7x64, and so on for each additional image created. (Note that they do not have to be ordered oldest to newest; if you have Win7x64 as 1 and Win8x64 as 2 and then have to go back and create a Win7x86 image, simply designate it as 3. As long as it’s recorded, it doesn’t matter what the order is.)

BB – This corresponds to any changes made to the core media for the OS platform designated by A that is used to create the core image. The most common reason for this change would be slipstreaming software updates into the install.wim file, particularly to handle the known issue with certain updates breaking OSD.

CC – The third number tracks any changes made to the core image build process.  This includes apps added or removed, settings changes, or any other substantive change to the core image other than those included in BB.

YYYYMMDD – This is a date marker notated by year, month and day.  This tracks the date the core image was created. It can also be used to track the patch level of the image if the Build and Capture is set up to install available patches up to that date (not including any handled by slipstreaming in BB).

An example of an initial build number would be 1.00.00.20141101 for a new image build on November 1, 2014.  How many digits the second and third numbers use is not important except for the sake of consistency; if you think you’ll iterate it less than ten times during the course of the platform’s lifecycle, then a single digit is sufficient…if less than a hundred times, then use two digits.  The goal is to make it simple programmatically to handle, and that’s much easier when you have a fixed number of characters.

Integrating into the Process

So let’s look at how we integrate this into our build process.

While we could maually set the build date, I find it’s easier to just use a simple PowerShell script to auto-generate the date in the YYYYMMDD format we want. So the first step is to call this script (in this case, from a Package called BuildScripts) and get our build date:

The code for this script is extremely simple:

$tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment

$builddate = Get-Date -Format yyyyMMdd

$tsenv.Value(“BuildDate”) = $builddate

Now that we have the build date in a variable, we’ll use it to set a variable with our full build number:

An optional next step is to create a custom folder location to store the build marker. It’s a good practice to have a designated folder for storing things such as administrative files, installation logs, etc.  In this case, I’m showing my age a bit by using the old C:\Windows\Options folder:

Finally, we need to create our build marker to tag the image.  We’re simply creating a .EXE file with a generic prefix and the build number as the file name (the prefix simplifies the process of sorting for later queries):

Because we’ve created this as a .EXE file, it’s easily retrieved by standard Software Inventory in ConfigMgr. (Note that while the TechNet documentation for Software Inventory claims there are “no significant changes for software inventory in Configuration Manager since Configuration Manager 2007″ the fact is in SCCM 2007 .exe files were included by default whereas in ConfigMgr 2012 there are no default file types configured. So .exe files must be added to the Client Settings policy, which is a good practice anyway)

While what we have is sufficient at this point to mark out our image revision, we’ll add one additional step here to create a marker for the Task Sequence used to create the image:

Same principle as the build number marker; we’re creating an executable using a Task Sequence variable to automate the naming. In this case, it’s the built in TS variable _SMSTSPackageName which contains the actual name of the Task Sequence (ex – “Win7x64 Build and Capture v1.0”). Ideally, this should match up with the third set in your build number, but as we’ll see in the next article this is not essential so long as a consistent archival process is being followed.

We now have our core image tagged with a build number, but there’s yet another step we can add to make our lives easier: we can use the build number to name the captured .WIM file.

This helps ensure that we will not overwrite our previous captured image, and it will help us manage a transition and archiving strategy going forward.

So far we’ve established a numbering methodology for creating a custom image revision tag for our core build and capture image, and we’ve implemented some tasks to facilitate managing that build number with very little customization (the only thing we have to change going forward is the “Set BUILDNUMBER” task) and including that numbering in the actual .wim file name.

Next we’ll look at applying the same principle to deployment of that core image, as well as a methodology for handling implementation and tracking of these changes in the environment.