Fix the Software Update Task Sequence (built-in TS patching during OSD)
How is this still a problem? Ask any MVP and they all agree: the built-in task sequence for patching during OSD doesn't work. It doesn't survive double reboots, it has a upper patch limit before it crashes ... it's basically garbage. I don't mind making golden images in MDT, but I shouldn't _have_ to ... and yet I do. I makes SCCM feel less like a singular solution.
Thanks for all your suggestions and feedback, updating status to completed.
SCCM 1902 fast Ring released today
Updates added to the previous response, these documents are the first iteration and we’ll continue to add and improve.
We’d ask if you encounter issues with the Install Updates step to file a bug or engage support so we have logs etc. to work with to help diagnose and solve your issues. Also, if there’s specific asks for additions to the feature or documentation please open additional User Voice items.
Today we published a new article and related flowchart to provide some insight and guidance for using the Install Software Updates task sequence step.
- Flowcharts; the install updates proved popular. We’ve had asks for the same for Peer Cache, Task Sequence Pre-cache, Software Distribution Troubleshooting and more. These are all on User Voice too, also if you’ve suggestions for flowchart please open a User Voice item.
- Task Sequence Variable SMSTSWaitForSecondReboot. I’ve this in my notes to add, this variable helps with 2nd reboot and will be added to core docs. This also works with applications that cause a second reboot. See https://support.microsoft.com/en-us/help/2894518/ for more.
- Hardware guidance for capture. I’ve run some tests on various hardware, though seems from the comments below Dr. Michael Kischel’s guidance is working.
- Image Capture. Asks for scripts to address removing Appx and performing other customizations. If there’s more please add.
Previous code changes
Timeout scan is now configurable
We added a new task sequence variable to allow a configurable timeout for scan. Variable name is SMSTSSoftwareUpdateScanTimeout, default is 30 minutes. Value is set in seconds so an hour is 60×60=3600
Note: We took a further change after making this configurable to set the default to 60 minutes based on feedback and findings from support cases.
In the SMSTS.log we list the log files to check for updates download and evaluation.
These are UpdateDeployment.log, UpdatesHandler.log, WUAHandler.log and WindowsUpdate.log
New Option for full scan
There’s a new checkbox added to the Install Updates step – ‘Evaluate software updates from cached scan results’
If the checkbox is on we use cached results, if the checkbox is off we do a full scan
Task Sequences that are upgraded will have this option checked on – this is parity with the existing behavior
Power management changes
Clients maintain active power state during OS deployment Software Updates tasks.
Some devices (Surface Pro 3 for example) were going into Connected Standby state preventing completion of deployment, this was occurring in the Install Updates step
Windows upgrade roll ups
These are now filtered from the list of applicable updates
Dr. Michael Kischel commented
An update to my comment from April 11, 2017.
The problem with patching in a task sequence could be solved. It was observed on Windows 8.1 and Windows 10. Even after increasing the timeout with the variable SMSTSSoftwareUpdateScanTimeout to 6 h the problems were still there.
Investigating the processes on the client showed that a svchost (netsvcs) process had a very high CPU usage witch results in total usage of 100%. Analyzing the bits jobs with bitsadmin showed, that all the bits jobs on the client got stuck. Only a few bites every five minutes were transferred.
For the deployment of the task sequence I used VMware virtual machines. I assigned 1 processor and 2 GB RAM to each machine. After assigning 2 processors to the machines the problem was solved and the clients were patched without changing any other parameter. Resetting to 1 processor reproduced the problem again.
Finally it was a performance issue. I hope that this will help other users with the same problem.
You shouldn't have mentioned that the updates still worked in MDT.. because they used to. But Microsoft probably read this comment and thought. WHAT... UPDATES STILL WORK IN MDT.. WE CAN BREAK THAT. And they did. As of Windows10 1607 we also could no longer inject updates with MDT.
Here's an idea.
Make ONE update every 2 years that actually works. Instead of 20 broken updates every year.
All I'm doing is waiting for a hotfixxes that'll fix something that was broken in the last update.
At this point I don't know what's broken more SCCM 1610 or Windows 10 1607.
Anyways... we'll all be out of jobs soon... thanks for nothing.
I could make a f*cking batchfile that would install these updates just fine.
MAKE IT WORK.
When I start to update from 1602 to 1702 I get this error 0x80240020(-2145124320)
Jim Jankowski commented
+1 Sadness. ;-(
Dr. Michael Kischel commented
Using SCCM 1702 my OS deployment of a Windows 10 64Bit 1607 images finishes with the error “Timedout waiting for updates refresh complete notification. The operating system reported error 2147943860: This operation returned because the timeout period expired”. There are no hints to an error in the UpdatesDeployment.log, UpdatesHandler.log, UpdatesStore.log, wuahandler.log, WindowsUpdate.log or ScanAgent.log. In the smsts.log you can find the last entry “Waiting for RefreshUpdates complete notification from Updates Deployment Agent”. Nothing happened for 20 min in all the log-files mentioned above. After that the timeout is reached and the error occurs. There were only 6 updates found for installation.
Please fix this bug in the install updates task in the task sequence. The new features mentioned by djam will not help to prevent this error.
mike d commented
The Documentation here: https://docs.microsoft.com/en-us/sccm/osd/understand/task-sequence-built-in-variables
for this variable gives no indication that the value should be set in seconds, as opposed to minutes.
Jay Foreman commented
The process used to work OK for us, but I can only gather it decided to stop when the number of patches grew over time (we have not updated our base image in some time)? A newly built server, scanned with Shavlik, now needs 120+ updates. Our plan is to update the base image more often, but as has been stated by others this is frustrating. Why does this critical feature not work? And why has Microsoft not (after all this time) either fixed or posted a KB article with explanation and workaround information?
B Chadbourne commented
Not sure why I ever agreed to go to SCCM. It has been a consistent fight to get the thing to install updates. A 3 year old could write a more reliable product. Running SCCM 1610 and all it will do is hang during the software update scan. Does not matter if it is a full scan or from cache. Just hangs. I have changed the timeout to 3 hours and it just hangs. At some point you would hope they would fix this.
Phil Schwan commented
@HBacon seeing the same in 1610 and TP1701. Most basic B&C setup is no longer functional for installing updates and fails at 30 min. Only 1200 total updates visible in the SUP, and only a handful in actual available deployment, yet it's hitting the timeout regardless of whether I use wmic to initiate scan or let updated TS step initiate full scan. Not helping either that WindowsUpdate.log is no longer easily accessible.
We are running SCCM 1610 and after upgrading we have a problem that the default action “install software updates” in a build & capture task sequence failed to run. This operation returns error because the timeout period expired. The Error code: 800705B4 source windows.
We upgrade from SCCM 2012 R2 SP1 where this was not a problem. This does not help when you want to deploy Windows 10 to your organization!
Anybody a suggestions?
Ask any MVP and they all agree: the built-in task sequence for patching during OSD doesn't work. It doesn't survive double reboots, it has a upper patch limit before it crashes ... it's basically garbage. I don't mind making golden images in MDT, but I shouldn't _have_ to ... and yet I do. I makes SCCM feel less like a singular solution.
I have a Surface Pro 4, when running TS without Office it goes right through the update steps.
When I run it again with either Office 2013 or 2016 it gets stuck on some office update and the SMSTS.log states multiple Waiting for job status notification ...
The UI shows its installing updates and the task sequence just sits there and does noting, not even fails after 20hours+
We have the same problem With SCCM 1606 and Windows 10 Task Sequence
I still have this exact same problem with SCCM 1606... what is weird is that it does not seem to affect MDT (when used alone). I just can't understand why what has been working for years with MDT still does not work reliably with SCCM...
If anyone has a workaround :)
Frode Langeland commented
we have been stuggling With this for what seems ages.
Would be so Nice With a rework of the Install software updates step so that it is more stable.
Im seeing the same exact issues @MERIGOT.
Microsoft does know about these issues. I reported them 3 weeks ago throught premiere support. And all they told me is they are working on a fix.
An alternative is to use the office updates folder. But that workaround stinks as it just adds another thing i need to maintain.
I've just reproduced this issue on my brand new TS for Win10(Build1511).
I have SCCM with Build 1511.
During this step, the download step work fine.
The TS stuck after during the installation process. 51 Patches to install. 8 have been installed ... Stuck on the nineth (Office 2013).
Smsts.log repeat always the same thing "Waiting for job status notification".
One thing I discovered. The computer has an IP address and I can ping the MP/DP.
But when I try to ping the computer (with IP address) from my primary server.. it's a failure.
If I remove this step (install patch) in my TS, this one work like a sharme.
Timothy Kress commented
The Install Software Updates task does take a VERY long time to run and often hangs at times (while not showing the task sequence UI, which can be confusing). In general it takes much longer (about 3x per my testing) than using the Windows Update task (i.e. ZTIWindowsUpdate.wsf script) via MDT. It would be great to get the Install Software Updates task solution to work reliably and efficiently via the task sequence as it would simplify administration of patches each month, as we currently deploy patches via Software Updates to existing PCs in our environment.
Ian Burnell commented
Agree. Generally it works fine during build but my beef is the TIME it takes to run - can add up to 20-30 minutes to the Task Sequence. Its hard enough selling SCCM to management without having to explain it takes some 90 minutes to build a machine. You need to have an install updates offline like MDT than can run in tandem with the build process. I also don't understand why it needs to install the SCCM client when it is build into the captured WIM - at the very least it should only need to be activated rather than a complete install of client which adds another 5 minutes to the build