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.
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.
This post was contributed by Michael Murgolo, a Senior Consultant with Microsoft Services - U.S. East Region.
Have you found any creative ways to get set the patch properties for Client Push Installation?
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...