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
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.
Yeah, make it work guys
Jeppe Nielsen commented
Fix the issue please... ;)
Paul Cunningham commented
This problem has been around since CM 2007 RTM !!!! 8 years later and we are still talking about this. This shouldn't even need to be a suggestion. Get it fixed!
David O'Neil commented
An additional comment to add (not related to patches needing a double reboot). I would like to see a new feature for SCCM packages and applications to also be able to handle double reboots. For example, in an OSD task sequence I would like to use DISM to convert the Windows Edition to a higher level if needed. After running the DISM command to do this, a double reboot is required and later breaks the task sequence completely. I know that a double reboot is also sometimes required when installing certain Roles and/or Features within the Windows OS. Not sure how to get around this.
Bram Vlasblom commented
This issue is for our organization also a pain point. A build and capture task sequence with Windows 7 SP1 out of the box, some middleware and runtimes does not install all updates. Even when multiple update steps are used. Triggering a software update scan with PowerShell in between does not solve the problem either. Building images is one of the key features that are needed for a deployment of our devices. Every month the image must be regenerated. It is very frustrating that it does not work properly. We have a filed support case with number 11506081282209.
Last weekend we tested this feature again with CU1 on SCCM 2012 R2 SP1, still the same issues.
I find the same frustration. Having to add several software update steps to make sure the build and capture works. Also double reboots cause task sequences to bug out.
Stephen Owen commented
Totally agreed, this is a big pain point, and I'd love to see it addressed.
The link below does not work for some reason. This one does https://support.microsoft.com/en-us/kb/2894518
Aaron - Your comment implies that this is not a well known/established problem, a quick search online of blogs and SC communities confirms this is a known issue, which the majority of users must work around.
When I logged this with premier support, the response was to enable continue on error on the software update step (!) and to put in multiple software update steps. This prevents the TS from failing, but renders that (critical) process unreliable. Updates performing multiple reboots also causes the process to fail as per https://support.microsoft.com/en-gb/kb/2894518
Ultimately, this seems to stem from the insistence to integrate with WSUS, I can totally understand the logic behind that decision, but perhaps the priority should be reliability. The MDT approach to point at a folder full of MSUs is a simpler one and therefore more reliable.
Thomas Forsmark Soerensen commented
I will be glad to explain what I am experiencing.
1. General patching with the “Install Software Updates” task is very slow. It takes 10-15 minutes saying “Installing Software Updates” before it starts to install the actual updates.
2. After installing the last update it stays for along time at “Installing update x og x updates”
3. When installing a large number of updates it will break the TS. A large number of updates will be 160+ updates. If I do this it will break the “Prepare Configuration Manager Client” step as explained here https://social.technet.microsoft.com/Forums/en-US/8140c022-5ca2-4bac-b8fc-f8b686566e44/build-and-capture-ts-fails-in-prepare-configuration-manager-client-task?forum=configmanagerosd
4. Having more than one “Install Software Updates” tasks in the TS can break the TS like in 3. Removing tasks so there is only one left will make the TS run through if there are not too many updates to be installed.
AdminAaron Czechowski [ConfigMgr Product Team] (Content Developer, System Center Configuration Manager) commented
Justin/Thomas - can you please expand on this with some more details? Have you filed support cases or Connect feedback on these issues? What OS are you deploying when you encounter these problems? How many updates are you deploying?
Thomas Forsmark Soerensen commented
I couldn't agree more. The multiple reboot problem might be fixed in the SP1 for SCCM 2012 R2 but the unstable "install Software Updates" task that cannot handle a lot of updates is making patching in a TS unusable. Please fix this.