Wednesday, April 30, 2014

Weekly Lab Patching Task Sequence

We use Deep Freeze and SCCM to manage our computer labs. Previously I wrote up an overview of how we do this. With this post I will explain how we use a task sequence to deploy updates and software during a maintenance time, which allows greater control over what order applications and updates are actually installed. I find this is more desirable when under a tight time schedule like our maintenance times. Here is an example of the task sequence I use.


We run software updates from our WSUS server before we install 3rd party patches or software. You could do it the other way around, depending on what your priority's are, but since I also set every step in the task sequence to continue on error, if the Software Updates fail the TS will still make it to the 3rd party patches and additional software installs. We run three install update cycles, forcing a reboot and update scan between each to catch those updates that need an update.

Pre Patch Actions

Here is where any commands or scripts would be added that needed to be run before the start of patching.

Install Updates I, II, or III

Install Software Updates I, II, or III
A straight forward "Install Software Updates" step. Since our updates are deployed as "Available" to the update collection we want to choose All Software Updates here and not Mandatory Software Updates. We deploy them as "Available" so that the TS will install them and not be interfered with by the normal patching mechanism which would otherwise install "Required" updates during the maintenance time.

Restart Computer
A straight forward restart. The TS will pick back up after the computer restarts and the Configmgr client is ready.


Install Updates II

Scan for Updates II, III

 Here we run a command so the client will do a delta scan for any updates it is missing after the previous round of updates.
WMIC /namespace:\\root\ccm path sms_client CALL TriggerSchedule "{00000000-0000-0000-0000-000000000113}" /NOINTERACTIVE

Or (and I haven't experimented with this) you could run a full scan with the command:
WMIC /namespace:\\root\ccm\invagt path inventoryActionStatus where
InventoryActionID="{00000000-0000-0000-0000-000000000113}" DELETE
Wait for Scan to Finish II, III
Here we run a powershell command to wait 300 seconds between initiating the scan and running the software updates.
Powershell.exe -command start-sleep 300

 Install 3rd Party Updates

Next we have Install Application steps to patch or install 3rd party software. In this example we are installing the current versions of Flash player and a Hotfix rollup during the weekly maintenance window. I know the MS hotfix rollup is in the wrong category and is not a 3rd party update, but it gets the job done and I was on vacation that week =P

Install Additional Software

This space holder is for installing new software.

Agent Maintenance, SCEP Update

 Space holders for patches to the Configmgr client,  WU agent, or SCEP.

Post Patch Actions

 Run Hardware Inventory
We want our lab clients to report their new software installs in after each maintenance period so we can view reports to verify the installs the next morning. Its important for a classroom lab that if you need a specific version of software to perform instruction, that all computers in that lab are on the correct version. So we force a hardware inventory at the end of the Task Sequence.

WMIC /namespace:\\root\ccm\invagt path inventoryActionStatus where InventoryActionID="{00000000-0000-0000-0000-000000000001}" DELETE /NOINTERACTIVE
Wait for Scan to Finish
Our typical lab has many software titles, so I give the machines 600 seconds to finish reporting in hardware inventory.
Powershell.exe -command start-sleep 600
Restart Computer
And finally, one last reboot to clear up any pending restarts before our Deep Freeze program freezes the machines and shuts them down.



I have found that if you make changes to the TS or packages it references mid week before the TS runs, it may run and use an old copy of the TS instead of the current one. I believe this is because the machines were frozen when the client checks in so the machine "forgets" about the updated TS, then when it boots during the maintenance window it runs the old TS before it has time to check for updates. I am looking for a solution to this problem. I believe that running a check for changes at the beginning of the TS will fix this issue. If anyone has any idea's please share. I am wondering if forcing a "Machine Policy Retrieval & Evaluation Cycle" will cause the client to update its local cache of the TS and packages associated before running but I have not yet found any information that this action does that.


  1. Did you ever find a working solution to your problem?

    1. No, I have not found a solution to it always running a task sequence that is one week late. I am going to stop using the task sequence method to update during our maintenance times soon because I have found another way to handle the double reboots that happen with some patches. I am either going to use powershell to add a reboot to the Task Scheduler of each machine, or use the Scheduler that is built into Deep Freeze to send a reboot command. This command will happen outside of the Configmgr maintenance time, and before Deep Freeze refreezes the computer.