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
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?
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
Mattias melkersen commented
Download the patches as cab files and apply them online using dism max 50 piece at a time. Download all double restart patches and inject them offline using dism as well or the mdt step. I will soon create a post where this all is explained and creating reference image in configmgr no matter version will not be a problem anymore. Follow me on Twitter mmelkersen
Ozzie Santiago commented
I'm running to this issue exactly. This is super terrible to troubleshoot and worse when you have to explain to a customer.
I have a similar problem on Windows 10 Stuck at 44 of 66 updates
Got the same Problem as James. You can see in the windows update log, that the updates have been correctly installed, but the TS agent does not seem to recognize this. Using SCCM 2012 R2 SP1 CU1.
James Jankowski commented
Not sure if its related, but the "Software Update" task started to hang (stop) when we added in the January 2016 updates. The task stops at Office update (KB3054785). We tried taking the update out but then the task hung at update KB3114486 (another Office update). All signs point to the task just stopping like we would see if we had 150+ updates. Total number of updates being installed by the task is 59. Thoughts? Any viable alternatives to using the "Software Update" task?
Update via SCCM or Microsoft Update option
Daniel Clemow commented
This is getting ridiculous - With Windows 8.1, .Net (various versions) and Office 2013 etc etc etc, there are around 300 updates. I thought it was doing well to *finally* install 200+ updates during install and capture, but then deployed this image to a test computer, and still has another 100+ updates to install after deploy task. Grrrr!!!! Wasting sooo much time with this.