Patch ConfigMgr 2012 x86 and x64 clients during a task sequence using the PATCH property


In this post, I'm go to show a method to patch the client during a task sequence using the PATCH property in the Setup Windows and Configuration Manager step.

Step 1. Create a folder for a new package. This package will be used to store any hotfixes you would like to deploy during a task sequence. In my lab, I used \\cm12pr1\Sources\Operating System Deployment\CCMHotfixes for my source folder.

image

Step 2. Copy the client hotfixes (.MSP Files) you want to install from the hotfix folder on the site server <InstallDirectory>\hotfix\<KBNumber>\Client into the CCMHotfixes folder.

image

Step 3. Create a package that references the folder you created. You do not need to create any programs for this package.

image

Step 4. Add a run command line step in the task sequence directly before the Setup Windows and Configuration Manager. Ensure you reference the ClientPatches package in this step.

Use the following command line:

cmd /c xcopy *.* %OSDTargetSystemDrive%\windows\CCMHotfixes /E /H /C /I /Q /Y

This command will copy the patches (.MSP Files) to %WinDir%\CCMHotfixes.

image

Step 5. Add the PATCH command in the Setup Windows and ConfigMgr Step. Here’s a few examples:

ConfigMgr 2012 R2 Cumulative Update 5 x64:

PATCH="C:\windows\CCMHotfixes\configmgr2012ac-r2-kb3054451-x64.msp"

ConfigMgr 2012 R2 Cumulative Update 5 x86:

PATCH="C:\windows\CCMHotfixes\configmgr2012ac-r2-kb3054451-i386.msp"

image

You will need to change the filename as appropriate based on the update you are applying. If you add additional patches for a future hotfix, don’t forget to update the distribution point for the ClientPatches package.

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 any included script samples are subject to the terms specified in the Terms of Use

Comments (4)

  1. Yes, I have tested it.

  2. mikec says:

    I don't think that the %PROCESSOR_ARCHITECTURE% variable works in an SCCM task sequence? I tested using it in a batch file in a legacy package and it does not resolve.

    Have you tested and verified this works with SCCM 2012?

  3. JWeinberg says:

    Great information. Quite saved me from a issue that has been plaguing me with a Windows Embedded 7 deployment with EWF turned on.

    I'll describe my issue and also something that will save people a lot of headaches if they are selecting to use the content from the DP instead of copying locally.

    Issue!
    I am using SCCM 2012r2 and including CU4 with the method described here :
    http://blogs.technet.com/b/ryanan/archive/2014/01/31/applying-a-configmgr-hotfix-during-the-client-installation-of-an-os-deployment.aspx .

    Previous to CU4 I had been at CU2 and has no issues with this method (using _SMSTaskSequence and storing the MSP there for the update via PATCH= parameter).

    In my logs, after it was all wrapped up, the client would be alright for a bit, but would fail a WMI self test, and trigger a repair, then fail miserably when it could no longer find the Patch MSP. Resulting in a useless client, or no client at all.

    With CU4, there seems to be a need for reboot either after the Client installs, or after the patch is installed via the PATCH= parameter. Not sure which yet.

    Resolution!
    After the Client Install step I put in a sleep for 180 seconds via: " Powershell.exe -ExecutionPolicy Bypass -Command "Start-Sleep -S 180" ". Followed by " Powershell.exe -NoProfile -Command "Write-Output Test; Exit 3010" " to ask the TSManager to reboot.

    The Thin Client is pushed into EWF with a _SMSTSPostAction triggering a PowerShell script.

    In my logs, after it was all wrapped up, the client would be alright, but would fail a WMI test, and trigger a repair, then fail miserably when it could no longer find the Patch MSP. Now, thanks to this method, things seems to be solid and just like normal
    (CU2).

    Tip!
    Now, something you should note is that I, probably like many others see no issue with your command line of:

    "cmd /c xcopy *.* %OSDTargetSystemDrive%windowsCCMHotfixes /E /H /C /I /Q /Y"

    Normally, this would work fine. However, if you have selected to "Access content directly from a DP when needed..." in your deployment of the Task Sequence you are going to bad time (as you have to if you want to work with intensely space limited Thin Clients).

    CMD.exe does not support UNC paths!

    So, in your destination folder you'll get a copy of WindowsSystem32! DOH!

    Just use the command line along the lines of:
    "xcopy.exe ".*.msp" "%OSDTargetSystemDrive%windowsCCMHotfixes" /D /E /C /I /Q /H /R /Y /S

    You'll be right as rain!

    Credits to "anyweb" from WindowsNoob via many Google searches for helping me understand why this happens:

    http://www.windows-noob.com/forums/index.php?/topic/2758-how-can-i-copy-files-from-a-package (you are running the command from the UNC path, which CMD.exe does not support, forcing it to default to c:windowssystem32)

    Also thanks to Matkins in an awesome Slack SCCM group I'm a part of for thinking up how to easily ask for a Exit 3010 reboot!

    Jonathan Weinberg
    https://www.linkedin.com/in/jonathandavidweinberg
    https://twitter.com/slippyfox

  4. BElam says:

    This is working great for devices that are newly imaged but I am having an issue with devices being reimaged that will not get the patch installed unless I first remove the device from SCCM. I watch the task sequence and the steps run the way they are
    supposed to but when the image is complete, the version is still 5.00.8239.1000 instead of 5.00.7958.1501 for the CU4 patch.

    Any ideas as to why this might be happening?

Skip to main content