Branding Image Version in Registry using TASKSEQUENCEVERSION TS Variable

For sometime now I have been branding my image versions into the registry by leveraging the TASKSEQUENCEVERSION Task Sequence Variable.  This variable contains the value set as the Task Sequence Version in the Task Sequence Properties in the MDT Workbench.  I also setup a registry entry which will display the Image Version in the right click context menu when any folder on a deployed machine with that image is clicked.  It popped up in a forum today that a fellow Imaging architect was looking to do something similar here is my solution.

 

First here is a link to my script to do the work:

ZTIImageRegisty.WSF 

 

The script was created using ZTITemplate.wsf so functions as a standard script in MDT generating entries in BDD.Log and in its own log.  It was originally created in BDD 2007 and has continued to work through all versions up to and including MDT 2013 Update 1.

 

The script does a number of things for me beyond the image version stamping however here are the relevant things to do to get the image version functionality:

 

1. Place in the "Scripts" directory of the MDT Deployment share you use to build the image
2. Edit the script Define the "MyCompany" variable on line 81
3. Set the Task Sequence Version to whatever is Sensible for your Environment in the Task Sequence Properties for the Task Sequence that builds the Image in the MDT Workbench (see Screenshot1 and Screenshot2)
4. Add a Run Commandline Step to the Task Sequence to Call the Script to be run as part of the build Task Sequence the Logical place for this is under "Custom Tasks" (See Screenshot3)
5. Build Your Image

 

Further Explanation:

 

1. Line 79 of the script gets the value of the Task Sequence variable "TASKSEQUENCEVERSION" and stores it in the VBScript Variable "buildversion" for later use
2. The code block at line 100 makes use the "buildversion" variable to build a registry entry which adds the Image Version String defined as the Task Sequence Version to the context menu when a Folder is right clicked (See Screenshot4) 
   Note: We call our Images the Standard Client, Thus the SC Notation prepended at line 102, its safe to take that out if you don't want that in your Image
3. The code block at line 105 stamps the Version information into the registry in an easily collectable registry hive.  The location referenced existed at my company before I was hired and took over imaging so that is what we have continued to use as a standard location to collect image information, We put a lot more there.  The location predates the use of MDT at the company which I introduced when I arrived otherwise I'd have put all the info in "Deployment 4".  The referenced registry path (Line 106) could easily be updated to place the information in the standard location
   regPath = "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Deployment 4\ImageVersion"
4. Finally the Code Block at line 224 defines a Function which is used to perform each write to the registry so its done in a standard and logged manner

Screenshots:

Screenshot1

Screenshot2

Screenshot3

Screenshot4







Adding SCCM 2012 Client CU Patches, A Different Approach

The Update of the Client in the TS is challenging....

I've been working on the problem of how to patch the Configuration Manager Client Up to the Currnet CU level deployed in my infrastructure since we first rolled out SCCM 2012 RTM a couple years ago. In that time I have tried a couple of approaches and followed the various blogs which typically come down to the use of the PATCH public property of the Client .MSI.

However this has met with varying degrees of success and several problems in my environment.

I want to start by saying I have been informed by a couple of reliable sources that the PATCH property isn't actually recommended, supported, or really even reliably tested by Microsoft.  So I suppose any use of it is best effort, and if it works "lucky you".

That said...I DON'T use it.

Why?

The PATCH property only "sort of" works.

What does sort of mean:

1. The pathing for it can be tricky, using variables in the path as some articles point out can be tricky, or just plain not work.
2. I've seen problems with using it when deploying on machines with more than one drive. The system will throw the files on the secondary drive when it goes to apply the patch and then the Client install bombs out entirely because it can't find the patch files.

 So What do I do to get the Client Patched during OSD deployment:

To get the Client Patched I've gone a bit "Old School" and approached it as a true patch install, I arrived here by sitting at my desk one day, and thinking "Well its .MSP" so shouldn't I be able to use it like any other .MSP and install it with "MSIEXEC /P"

I removed the PATCH property from my Client install command line, and tried the patch install as a separate "Run Command" step and after a little trial and error got it working, I haven't looked back since.

Up front warning, since I have personally chosen to avoid any use of variables my syntax assumes that the system drive and therefore the drive the Task Sequence is running from is C: if this isn't true of your OSD setup then YMMV.

1. Create a new Copy of the Client Install package
2. Put a Patch folder under this with an X86 and a X64 subfolder...basically the same as articles about using the PATCH property
3. Put the SCCM Client patch or patches (CU3 needed a couple of hotfixes in addition to the one to patch things up to CU3)
   
4. Set this up a Old Style Package in Config Manager, Mine ends up being package ID PS100540...distribute this.
5. Make this package the package used by the client install step.
6. After the Client Install Step in the TS add a reboot step
7. Create a Run Command line step in the TS and apply the Client Patch for the current CU with a "MSIEXEC /P" command line.
   ex..."msiexec /p C:\_SMSTaskSequence\OSD\PS100540\Patch\x64\configmgr2012ac-r2-kb2994331-x64.msp /qn REBOOT=R"
8. Add another Reboot Step
9. Add similar patching steps followed by a reboot step for each Client Hotfix