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

 

This 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, looked at why the out-of-box forensic information is useful but insufficient, and we implement a method for version control in the core image.  Now that we have a method of tagging our core image, how do we capture changes around the deployment of that image and then handle ongoing release/archiving of our images?

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

Our core build and capture image has a significant portion of what constitutes “the image,” but quite often we’re going to be making changes at deployment time as our deployment Task Sequence executes.  This represents another piece we need to track so that if problems arise we know where to look (and, potentially, how far to roll back).

To track our Task Sequence changes, we’re actually going to employ the same method used to capture our Task Sequence in the previous article: we’ll leverage the _SMSTSPackageName variable and use it to create a .EXE file:

As with the Build and Capture Task Sequence, we want to be sure the name includes a version number that we can record and track changes against. This is separate from the Build Number we used previously because the core image is not being changed, just the method and circumstances of deployment.

So now that we have everything in place to track image revisions, let’s look at how we can record those changes.  One rather simple means is a shared Excel spreadsheet (a template is available here). We can use a separate tab for each of the numbers in the sequence, one for the deployment Task Sequence revisions, and one to show whatever the current production build is.

With a means of designating revisions and a place to track the changes, let’s look at how we can control implementation.  The method I prefer is to use a folder structure within ConfigMgr to handle the production Build & Capture, Deployment, Development, and Archived Task Sequences.

Here is an example of the steps involved in a Task Sequence revision:

1. A copy is made of the current production Task Sequence (right-click > Copy). The copy is renamed to identify it as non-production (ex – “zDEV – Win7x64 Build and Capture v1.1”) and moved to the Development and Testing folder.
2. Initial desired changes are made to the new Task Sequence. Any changes are added to the appropriate corresponding tab on the OS Deployment Revision History spreadsheet (a new line with a NON-bold number).
3. New Task Sequence is deployed to the appropriate test collection and put through whatever testing and quality assurance procedures are appropriate to the organization. Revise as necessary and record any changes in the spreadsheet. Having a “second set of eyes” is a good idea at this stage.
4. When approved for production use, move to the appropriate production folder and rename to reflect production status. Create the necessary deployment(s), and disable the previous production Task Sequence. *Test immediately* (the previous production TS can be quickly re-enabled in the event of unexpected problems)
5. Upon successful verification of new production Task Sequence, delete deployments for previous revision (optional), rename to reflect archive status (ex – “RETIRED – Win7x64 Build and Capture v1.1”) and move to the archive folder.
6. Update the spreadsheet to reflect the new production version (bold the appropriate number and update the Current Builds tab)

By following this procedure, we have a consistent revision and release process that provides thorough tracking of the history of an image as well as a means of controlling the release to reduce the opportunity for errors. In the event of an issue in the environment, this can be used to trace back and either identify what changes were introduced that may have caused the issue, or provide the documentation showing that no change was made that would have affected the environment.

As mentioned in the previous article, this is just a framework to get started and should be modified to apply to your specific environment. Hopefully this little bit of work will save you a ton of headaches the next time somebody wants to blame “the image” for a problem in the environment.

A very special thank you to David Megyesi for all of his insight and work (including the original version of the spreadsheet) when we first started managing corporate images almost ten years ago.