Automatically Populate the PATCH Property for the ConfigMgr Client Installation - Updated for ConfigMgr 2012

Update 2013-06-12: The newest version of this script can be found here.

 

Two years ago I posted a script to automatically set the PATCH property used by ccmsetup.exe to install client updates during the Configuration Manager client installation in a task sequence.  That post is found here.  Since Cumulative Update 1 for ConfigMgr 2012 has a client update that is almost a necessity to apply if you installing applications during a task sequence, I needed to update the script.  This is due to the fact that for ConfigMgr 2012 there are now architecture-specific versions of the client (x86 & x64) and therefore architecture-specific updates as well.  The script for ConfigMgr 2007 made the assumption that there were only x86 updates since the ConfigMgr 2007 client was 32-bit only.

Since the updated script works in pretty much the same way as the original one, I will not repeat the details of the implementation that are the same.  If you are not familiar with this, please read the previous post before attempting to use this script.

The major difference between using this solution to install client updates during a task sequence in ConfigMgr 2007 and ConfigMgr 2012 is that ConfigMgr 2007 did most of the work for you in creating a client package that included the updates.  When installing the hotfix on the ConfigMgr 2007 site server, the installer actually placed and client updates directly into subfolders of the hotfix\i386 folder in the client source on the server.  The CU1 update installer for ConfigMgr 2012 does not do this.  It instead creates a Hotfix folder at the same level as the Client folder (under the Configuration Manager installation folder), creates a KB number folder under that (KB2717295 in the case of CU1), and then creates folders for the updates of the individual components under that.

 

It then creates individual update packages like this:

Unfortunately, these cannot be used to install client updates during a task sequence.  So for ConfigMgr 2012 you will have to manually create a new client package with the updates integrated in the same way that ConfigMgr 2007 would have done for you.

Use the following steps to configure this integrated client package.  I recommend creating a new client package instead of modifying the one that ConfigMgr 2012 creates upon installation.  That way any future automatic changes to that package will not impact this package.

• Create new client package source folder.
• Copy the contents of the original client package source folder into this new folder.
• Under both the i386 and x64 folders, create a hotfix folder.
• Under each hotfix folder, create a KB number folder for each client  update (KB2717295 in the case of CU1).
• Copy the MSP files from <Configuration Manager installation folder>\hotfix\<KB number folder>\Client\i386 to the i386\hotfix\<KB number folder> folder in the new client package.  So for the CU1 update and ConfigMgr installed in the default folder, these paths would be C:\Program Files\Microsoft Configuration Manager\hotfix\KB2717295\Client\i386 and i386\hotfix\KB2717295 respectively.
• Copy the MSP files from <Configuration Manager installation folder>\hotfix\<KB number folder>\Client\x64 to the x64\hotfix\<KB number folder> folder in the new client package.  So for the CU1 update and ConfigMgr installed in the default folder, these paths would be C:\Program Files\Microsoft Configuration Manager\hotfix\KB2717295\Client\x64 and x64\hotfix\KB2717295 respectively.
• Copy the updated SCCMClientHotfixPath.wsf (in Zip file download below) and ZTIUtility.vbs (from the MDT Scripts) into the root of the new package folder.

The resulting package folder structure should look like this:

 

Once that is done, use this updated package in the task sequence for the task sequence steps that require it.  Follow Chris Nackers’ great blog post, which shows how to configure this solution.

This version of the script also fixes two other issues with the previous version.  If the machine was configured with more that one partition (perhaps a BDE drive for BitLocker), the script would have the paths to the updates with the incorrect drive letter once the OS was running.  This version changes the drive letter in the paths back to C.  (Thanks to fellow Deployment Guy Dave Hornbaker and MCS Principal Consultant Tomaz Cebul for pointing this out to me a while back.)  This version also reorders the installation of the updates in KB number order, rather than file system order.  (Thanks to blog reader Mark Allcock for commenting about this issue).

While this script has been updated for ConfigMgr 2012, it should still work with ConfigMgr 2007.  I haven't had a chance to test it with ConfigMgr 2007 yet so please post a comment if you have an issue with this.

 

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use .

This post was contributed by Michael Murgolo, a Senior Consultant with Microsoft Services - U.S. East Region.

SCCMClientHotfixPath.zip

Comments

• Anonymous
  January 01, 2003
  Last October I posted an update to the script to automatically set the PATCH property used by ccmsetup

• Anonymous
  January 01, 2003
  The comment has been removed

• Anonymous
  October 12, 2012
  Have you found any creative ways to get set the patch properties for Client Push Installation?

• Anonymous
  January 23, 2013
  Daniel G - Unfortunately, you'll have to manually specify the PATCH=%path_to_MSP% property in the Client Push Installation properties while using Michael's recommendations for copying the files to the "hotfix" folder. At the time of writing this, we're only up to CU2 so at least that's not too much work right now. Now I cannot remember whether it's a comma or a semicolon as a separator in the PATCH= property...

• Anonymous
  June 06, 2013
  The comment has been removed

• Anonymous
  July 16, 2013
  Michael, you are right, it was a self created Build and Capture TS, that didn't have OSDISK set. I just tested your updated version, and that works perfectly. Thank you!!