Automatically Populate the PATCH Property for the ConfigMgr 2007 Client Installation

29 Aug 2010 Update – I must apologize to all of you who attempted to use this as originally posted.  I wrote this script around two years ago and was posting it now because another MCS consultant needed.  Unfortunately, while I was trying to remember how I did this, I left out an important detail.  In my original implementation, I had used an MDT custom variable to hold the client installation properties.  The script then changed that variable and this custom variable was placed in the Installation Properties field of the Setup Windows and ConfigMgr step.

Luckily, an astute reader, Chris Nackers of Catapult Systems Inc., noticed this and contacted me.  He had created his own fix.  While discussing this via email with Chris, I realized that I should have just made the script set the SMSClientInstallProperties task sequence variable directly (which is what I thought I had done when write the post).  So I updated the script to do just that and have updated the attachment with the latest version.  Be sure that you are using at least version 1.0.2 of the script for this to work as described below.

Chris was kind enough to test the updated script for me.  Chris has also created a great visual “how to” post on his blog for using this script.  Thanks again Chris!


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


During a System Center Configuration Manager 2007 Operating System Deployment task sequence a step called Setup Windows and ConfigMgr stages the ConfigMgr client for installation.  The task sequence editor for this step provides a field called Installation Properties that allows you to specify Configuration Manager Client Installation Properties.  The client installation properties can also be specified using the SMSClientInstallProperties task sequence variable.

Client hotfixes are stored in subfolders of the i386\hotfix folder in the client installation folder similar to the picture below.


When client hotfixes must be installed during the client installation, the PATCH property should be used.  The PATCH property must contain a semicolon-separated list of the paths to the hotfix MSP files.  Unfortunately, these paths must be specified as fully qualified paths like this example from KB977203:


They cannot be relative paths.  This means hard coding the client files package ID (and of course the rest of the path) into the property.  Therefore, the property must be updated any time a new hotfix is added or removed.  To prevent having to do this maintenance, I created a script called SCCMClientHotfixPath.wsf that will create the PATCH property on the fly during the task sequence.

This script must be used with an MDT-integrated OSD task sequence.  When you use this script, do not place the text of the client properties in the Installation Properties field of the Setup Windows and ConfigMgr step.  You must instead use the SMSClientInstallProperties variable (either using a Set Task Sequence Variable step or CustomSettings.ini) somewhere before Setup Windows and ConfigMgr step.  When you do this, specify the client properties required except the PATCH property.  The script will add this property to the SMSClientInstallProperties variable for you.

Copy SCCMClientHotfixPath.wsf and ZTIUtility.vbs (included with MDT in the Scripts folder) to the root of the client files package (i.e. in the same folder as ccmsetup.exe).  Then add a Run Command Line step just before the Setup Windows and ConfigMgr step (but after the place where the SMSClientInstallProperties variable is set).  Add a reference to the client files package to this step.  The command line for this step should be:

cscript.exe SCCMClientHotfixPath.wsf

When this script runs it does the following tasks:

  • If it is running in an online (not from media) task sequence, it will copy the hotfix folder to %DeployRoot% so that its location is fixed.
  • It will examine all subfolders of the hotfix folder, enumerate all the MSP files, and construct the PATCH=… string using the absolute file paths.  If there are no MSP files found, it will exit.
  • If MSP files were found, it will add the PATCH string to SMSClientInstallProperties variable.

The only drawback to using this technique is that when using download and execute, the client files package will be downloaded an extra time.  My custom preferred this to having to manually maintain the PATCH property in their task sequences.


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.

Comments (9)
  1. Anonymous says:

    I had previously blogged about a script created by Michael Murgolo over on TechNet . I wanted to now

  2. Anonymous says:

    Another great post by Michael Murgolo over on TechNet for automating the ConfigMgr client PATCH property

  3. Anonymous says:

    I had previously blogged about a script created by Michael Murgolo over on TechNet . I wanted to now

  4. Markus,

    You would need to add logic to the script to either detect the conditions when this happens (i.e. partition configuration, etc.) or set a task sequence variable on refresh and then change the drive letter in the PATCH property or move the files so that it's correct when the OS is up and running.

    Unfortunately, I don't have the time to solve this problem now.  If you find a solution that works for you, post a comment back here.

    Michael Murgolo

  5. Markus Lindgren says:

    This works fine for me when running in New Computer scenario (F12 to PXE boot and run task sequence). When doing a Refresh scenario and starting the task sequence from an OS, the patches are downloaded to the d: drive and the PATCH property points to d: path. The SCCM client installation task sequence step reboots the computer automatically and installs the SCCM client from c: drive. The d: path where the PATCH property points to is not found. Any suggestions on how to fix this?

  6. Mark Allcock says:

    Hi Michael

    I've been using this script for a while now and I have to tell you it's saved me so much aggrevation when trying to populate the PATCH property by hand. It’s very dynamic too just in case you install more hotfixes in Configuration Manager.

    I have, however, stumbled across a problem with the order in which the hotfixes are detected…

    We deploy the following hotfixes to our client systems:

    • KB977203

    • KB977384

    • KB978754

    • KB979199

    • KB2444668

    Your script populates the PATCH property in the following order because of the way Windows sorts the hotfix folder structure:

    KB2444668, KB977203, KB977384, KB978754, KB979199

    CCMSETUP fails to install with an error 1635 and ‘Client.msi.Log’ reports “ERROR: Attempting to install downlevel patch for feature SmsInventory. Rejecting patch and aborting install.”.

    Clearly, two hotfixes replace the same SCCM component and the older one (KB979199, I assume) cannot overwrite the newer (KB2444668, I assume).

    If I specify the PATCH property in the following order, it works!

    KB977203, KB977384, KB978754, KB979199, KB2444668

    I know you are limited in your available time, so a colleague and I are going to edit the script to present a logical order to the PATCH property so that recent KB2xxxxxx (7 digit) hotfixes appear nearer the end in their order of release. I will get back to you with results if successful.

    Mark Allcock

  7. Todd Miller says:

    Might as well link to the updated community WSF that puts the patches in the correct order……/automatically-populate-the-sccm-client-patch-property-during-osd.aspx

  8. Ian Broadbent says:

    Thanks for the script, it's much better than having to manually specify each hotfix . I found though, that the script is configured to look on the server for all available patches (I had applied a dozen or so patches to the server, some superceded others). This caused me an issue because of the same files being updated by different hotfixes as described by Mark above. I only wanted a few client hotfixes that I had in my client file-set to apply. So I just commented out the four lines below in the script  to stop it looking on the server (for the dozen or so hotfixes I had applied):

    '    ElseIf UCase(oEnvironment.Item("_SMSTSMediaType")) <> UCase("FullMedia") then

    '        sHotFixFolder = oEnvironment.Item("DeployRoot") & "hotfix"

    '        bCopyFolder = True

    '        oLogging.CreateEntry "Running in ConfigMgr OSD Online, SCCM… hotfixes copied to : " & sHotFixFolder, LogTypeInfo

    The script then successfully applied the four hotfixes I had in the client file-set which were, for the record:

    KB2750782  (Client-side update is KB2698619) – supersedes KB977384

    KB2659258  Asset Intelligence roll-up

    KB2815223  Fix for boot image error

    KB2509007  Fix for many updates stops Task Sequence

  9. Anonymous says:

    Install CM2007 client updates during OSD (using PATCH Property)

Comments are closed.

Skip to main content