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.
I’m updating the status. For 1606 we’ve made some changes, listed below.
As more are added we’ll update what Tech Preview/Release they appear in.
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
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
Mark ter Weele commented
I have the same problem with my SCCM environment with Build 1702.
Thanks for your reply. Interestingly in my customers environment I am seeing 1702 clients deploy and not lay down the SU settings in the registry which CM has always done to not require anything else doing this. Has anyone else seen this or just me?
It is the tip of an ice berg in a multi domain SUP headache I am currently working through :(
Joseph Vartanian commented
I'm giving my build and capture machine 4 processors and 8 GB in Hyper-V. It did clear up the problem instantly. I originally had 1 processor with 4 GB. I haven't yet checked what the minimum would be, so I don't know if say 2 processors and 4 GB would have been enough. At this moment I'm just happy that this month's builds worked in 1702. I do new scripted builds with the latest updates monthly, and was still using an old 2012 R2 site we have when doing my builds, since 2012 R2 didn't have this issue. I plan to go back and get all the details of exactly what's going on when I get some time, but I'm guessing Dr. Michael Kischel had it right. I need to buy him a beer.
What sort of virtual resources did you throw at this? I gave up in a B&C environment for now thinking a normal OSD would be fine and it seems to be struggling here aswell
Joseph Vartanian commented
It's been failing to apply updates during a task sequence on my 1702 site, but the exact same process which I use still works fine on an old 2012 R2 site that I have sitting around. I just tried Dr. Michael Kischel's solution of throwing more processors at the VM (Hyper-V in my case), and that resolved the problem instantly. So I can verify that it is indeed a performance issue on my side as well.
I would like to add a comment to this Thread.
I have previously done this successfully in the past however a 1703 Build and Capture on ConfigMgr 1702 I am seeing the timeout issue.
I have SMSMP specificed
Worked of IP Range Boundary
Tried WMIC Commands
Regardless of any combination of options the 30min timeout is triggered. I have a SUG with 12 updates contained (mix of x86 & x64) so there should not be a reason it is getting anywhere near the 30min mark.
Does anyone else still have this issue?
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