This question has recently come up a few times on Reddit and it’s something I initially struggled with as well. It’s one of those things that should be dead simple but in reality takes a lot of tribal knowledge to pull off.
Wait! A TS Step Not Working As Advertised? Say It Ain’t So!
Alas, yes my dear administrators … not all task sequence steps were created equal. There are some steps that just love to watch the world burn and Install Software Updates is their king. Don’t just take my word for it either, the users have spoken: Fix the Software Update Task Sequence. It is not by chance that this is currently the second most popular User Voice item with 1,421 votes. It’s been so bad for so long that many places have just given up entirely and use MDT solely for their build and captures. Speaking of build and captures…
To B&C or Not To B&C. That is the Question.
What I outline below is going to apply most directly to build and captures for legacy operating systems that you should be migrating away from. As you move to Windows 10 and Office 365 it’s probably worth taking a step back and asking if doing B&Cs is still necessary. With the release cadence of those products we will never see the multi-year backlog of updates that their predecessors had. Furthermore, both products have used a cumulative update model from the start. If you’re doing B&Cs primarily for software updates they will still save you some deployment time but ask yourself how much and if doing so is still worth it. I see a lot of ‘I shaved X minutes off my deployment by doing Y’ talk in the community. While such tricks are cool from a technical perspective I don’t always understand the practical value. In my organization the techs kick off a bunch of devices and then check back … eventually. A 15 minute OS deployment doesn’t save anyone time if the tech doesn’t come back for four hours. As always, your requirements and therefore mileage may vary.
Twelve Steps to Recovery
Below I’m going to outline the steps I took to install updates at least semi-reliably during task sequences. Some of this information might already be dated and unnecessary due to product enhancements. However, it’s what I’m using in production right now so I’m sticking to it. There’s thousands of ways for update installation to fail meaning there’s no silver bullet but this is what took me from something broken to something usable.
Deploying Updates to Unknown Devices
This is a simple step but it’s one I see many people miss and I can’t find it documented anywhere by Microsoft (note to self: fix that). In order for clients to install updates they must be deployed to them. As that applies to devices running OSD task sequences it means deploying to the two unknown computer objects. The easiest way to do that is to use the ‘All Unknown Computers’ collection. Whatever your patching strategy is, make sure that it includes deploying updates to those two devices. My ADRs all have a deployment specifically for this purpose with a deadline that matches my final production rollout. That ensures that when the whole organization gets the patches so do any newly imaged devices.
Provide Adequate Memory, CPU, and Disk Resources
This primarily applies to virtual machines and doubly so during during build a captures for legacy operating systems. If you try and update Windows 7 from the ‘latest’ ISO using a VM with one CPU, a couple GBs of memory, and 20 Gb of disk … things will not turn out well for you. Below I’ll outline strategies to lower the resources required but my standard is a VM with four CPU cores, 8 GB of memory, and 64 GB of disk. When I tried using VMs with half those resources it would timeout (described below), run out of memory (0x8007000E), or run out of disk space (0x80070070). Please, do not try to solve this problem using physical devices … you don’t want to capture drivers in your base image. I’ll admit to bending this rule for VMWare drivers which are very small and unlikely to conflict with physical devices.
Apply The Convenience Rollups
In 2016 Microsoft released Convenience rollup update for Windows 7 SP1 and Windows Server 2008 R2 SP1 (KB3125574) specifically to make build and captures easier. Building this into your image before you run the Install Software Updates step will greatly reduce the number of applicable updates. Keep in mind though that to install this rollup you need to install the April 2015 servicing stack update for Windows 7 and Windows Server 2008 R2 (KB3020369) first. I accomplish this by creating a package for each update, creating a program that uses WUSA to install the updates (ex. wusa.exe Windows6.1-KB3020369-x64.msu /quiet /norestart) , and then using the Install Package task sequence step.
If you use VMWare in your organization take special note of the first known issue listed for the rollup. I kid you not, the official solution from Microsoft is to run the provided VB script right before or after the update is installed. I included the script in that update’s package, added a second program to run it, and called it in the task sequence.
Maintain Software Updates To Minimize Your Update Catalog
I wrote on this at length here: Software Update Maintenance: It’s a Thing. That You Should Do. When the Install Software Updates step runs it first needs to know which updates are applicable to the device. That means doing a software update scan which, since the device is unknown, is going to be the first scan the device has ever done. Scanning against three thousand updates rather than ten thousand makes a real difference. As I’ll discuss below, it could mean the difference between success and failure.
Update the Windows Update Agent (WUA)
The flip side of minimizing your update catalog is to make sure you have a recent, if not latest, version of the Windows Update Agent which has to consume it. Back in 2015 and 2016 Microsoft released a whole bunch of updates to the WUA to just keep things afloat for Windows 7. Apparently ‘efficiency’ wasn’t part of the initial WUA design and it took them several releases to reign in the agent from snarfing up all the CPU and memory you threw at it. At the time, the agent was simply consuming more memory than 32-bit versions of the OS could support. In my current build and capture I am installing Windows Update Client for Windows 7 and Windows Server 2008 R2: March 2016 (KB3138612) to do this. As above, I make a package and install it before the Install Software Update Step.
Increase the Scan Timeout Value using SMSTSSoftwareUpdateScanTimeout
One of the biggest problems with the Install Software Update step is that the update scan will timeout. This step historically has had an arbitrary hard coded timeout value of 30 minutes at which point it will just fail. Now, if you’ve done everything above you probably aren’t going to hit that timeout. In Current Branch 1606 the team added the SMSTSSoftwareUpdateScanTimeout variable to allow you to control this value in seconds. Just to be safe I set it to an hour (3,600 seconds).
As an aside, this is one of the beefs I have with how the product team solves certain issues. They create a new variable, maybe mention it in the release notes, and eventually document it. So they ‘fix the problem’ but leave it as an exercise for the new admin to come across the issue, bang their head for a few days, and then find some reference about it on the internet. I understand the concern for breaking existing workflows but this just seems designed to frustrate new users of the product and encourage them to give up. Why did I have to spend three weeks of my life tweaking the default task sequence to get it to do what is says it does?
Handle Multi-Reboot Updates Using SMSTSWaitForSecondReboot
It’s not a frequent occurrence but some updates require two reboots to install successfully. When that happens during a task sequence the first reboot is initiated by the task sequence engine but the second one is not which means the task sequence environment is not properly saved and the sequences fails with ‘Task Sequence environment not found’. In Current Branch 1602 (and CU3 for 2012 versions) the team added the SMSTSWaitForSecondReboot variable which will allow you to set a value in seconds to wait for that second reboot. My experiences suggests that this is a hard wait and the sequence will always pause for the specified length for every subsequent reboot. I set this to ten minutes (600 seconds) in all of my OSD task sequences. In my deployment task sequences I turn it back down to zero after updates are installed so that subsequent restarts don’t needlessly wait.
More details on this issue here: Task sequence fails in Configuration Manager if software updates require multiple restarts
By Repeating Yourself You Will Convince It
A single Install Software Updates step is never going to install all applicable updates. There’s so many inter-dependencies between them all for that to ever be the case. When Microsoft moved to the cumulative update model the promise was that they would become fully cumulative to the latest ISO by June 2017. I think it’s safe to say that they missed that date and I wouldn’t hold my breath for it to happen at this point. In any case, the solution to this is to repeat the step numerous times. However, simply lining them up in a neat row doesn’t seem to work. What I settled on was repeating the following steps three times:
- Check for Updates
- Install Software Updates
- Reboot Computer
The check for updates step above is a Run Command Line task sequence step that runs the command line below. This triggers the client to scan for software updates. I’ve seen some people recommend putting a wait step after the scan since it runs asynchronously but I haven’t found that to be necessary.
cmd.exe /c wmic /namespace:\\root\ccm path sms_client CALL triggerSchedule "{00000000-0000-0000-0000-000000000113}" /NOINTERACTIVE
Putting It All Together
Ok, so I lied. I only made it to eight steps. Feel free to admit that this step has a problem and that it needs a power greater than itself. Then, work to remove its shortcomings and have it make amends to the devices it has harmed.
Putting everything together, here is what installing software updates looks like in my Windows 7 build and capture task sequence:
Late in the game of writing this I came across this relevant MS blog post which is worth a read: Building Windows 7 Images in 2017
Any chance you could do a post on using Task Sequence to apply all prerequisite ESU patches for 2008??? I’m really trying to get that route going so we can deploy all required patches for ESU keys in one maintenance window. These are for systems that already are deployed and in production. Any help would be greatly appreciated!
Deploying Updates to Unknown Devices as Required or Available ? & what option to select in Install Software Update step in TS Required or Available ??
That really depends on your patching strategy. During a TS do you want to only install updates deployed as required and past their deadlines or also include updates that have been deployed for optional installation (available) or have not yet reached their deadline. It’s personal preference though I usually use required on the thought process that if we haven’t fully rolled these out to my org I don’t want them possibly messing up my TS.
Hi, not sure if you are still paying attention to this or not, but we’re running into some issues as well with updates via OSD. When you say to deploy updates to “unknown computers”, I get that, but are they always “unknown”? What happens when a machine is reimaged? Is it “unknown” again? We were deploying our updates to a device collection called “osd updates” and then adding the computer to that collection via command line. Now with some sccm upgrade and win 10 1803 it doesn’t seem to work.
To be honest, I’m a bit fuzzy on when _exactly_ a device becomes known because I haven’t taken the time to test it extensively. It’s my understanding/belief that a device is unknown until it’s brought out of provisioning mode which is one of the very last things that happens in an OSD task sequence. Similarly, I haven’t tested this but I believe that in the re-image scenario it does create a new unknown computer object and there’s some reconciliation process that combines to two later.
Hi,
can you please provide a screenshot of task sequence step “set Wait for Second Reboot – 10 min”. I am doing probably something wrong when the task sequence break due to second reboot even if SMSTSWaitForSecondReboot is set
To describe the TS:
– set SMSTSWaitForSecondReboot to 600
– Add-WindowsFeature Hyper-V
– Restart Computer
– first restart
– blue background – Windows configuring new features
– second restart
– Task Sequence is broken
I no longer B&C for Windows 10 but the Install Software Updates step will hang for about 1/2 the deployments and this is with a well maintained update catalog (~3000). The OS is kept up to date with offline servicing so the updates step is merely dealing with Office 2016.
I’m actually considering revisiting the B&C route.