System Center Configuration Manager Feedback

Suggestion box powered by UserVoice

How can we improve Configuration Manager?

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.

1,838 votes
Sign in
Sign in with: Facebook Google
Signed in as (Sign out)
You have left! (?) (thinking…)
Justin King shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

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.


Link to document:

Flowchart at full size

- 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 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.

Logging changes
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


Sign in
Sign in with: Facebook Google
Signed in as (Sign out)
  • John commented  ·   ·  Flag as inappropriate

    1810 still broken - can't install updates in TS
    Bring back Windowsupdate.log file as plain text...

  • Rahamim commented  ·   ·  Flag as inappropriate

    1810 and still not good enough I don't even get to the scond reboot just stuck on downloading.

    It would be also great to see windows update service logs on real time and not needing to run get-windowsupdatelog command

    I am trying to test this option and it's hard to find the problems where the only way to check a log is by exporting it.

  • Fred commented  ·   ·  Flag as inappropriate

    @Stefan: I've stopped with captures alltogether for Windows 10 and recommend downloading a new base image from msdn/vl portal when needed (as these seem to be updated on a regular basis by MS directly) and deploying quality updates per usual process.
    Having customers still using Windows 7, it's even worse not one single workaround (even the one's posted by PFEs on MS Blogs) works. I've gone ahead and simply create a TS which installs the base image, then I install updates via the normal Software Center process and finally start a capture only TS from within Windows to captures the then perfectly updated Windows... I'm basically done with the TS patch process :-(

  • Steve commented  ·   ·  Flag as inappropriate

    This works a lot better (1802) than it used to (2012R2) - but it's still far more temperamental than it should be, not to mention incredibly slow relative to full-OS install speed. Please can this be improved, as others have mentioned, it should be possible to have a 100% completely built machine ready for an end-user without them needing to very shortly after receipt need to install more updates.

  • Ivan commented  ·   ·  Flag as inappropriate

    I've tried putting a script based action into the Task Sequence that invokes the InstallUpdates for CCM_SoftwareUpdatesManager class. What I've noticed is that when I run the Task Sequence the updates go into "Waiting to Install" state (EvaluationState is 6) and stay like that forever. I suspect that this is because they're waiting for Task Sequence to complete. Can someone prove if that's the case and if so, is there a way to workaround it?

  • Stefan Röll commented  ·   ·  Flag as inappropriate

    @Fred: How many Updates are deployed to the Client in question?
    The PS Script below should give you the answer. Replace "COMPUTERNAME" with the correct name

    $Deployments = Get-CMDevice -Name "COMPUTERNAME" | Get-CMResultantDeployment
    $i = 0
    foreach ($Deployment in $Deployments)
    $SUG = Get-CMSoftwareUpdateGroup -Name $Deployment.ApplicationName -ErrorAction SilentlyContinue
    $i += $SUG.NumberOfUpdates

  • Fred commented  ·   ·  Flag as inappropriate

    This is a farce... every possible workaround I've found has been tested and nothing works (set reg keys to suppress contacting MS online, more CPUs for VM, more RAM for VM, higher timeout value). I'm still getting a timeout for each and every update step using CB 1710 with all hotfixes installed, capturing Win 10 1709 with nothing but updates. Nothing works! Nothing!

  • Ivan commented  ·   ·  Flag as inappropriate

    Hi! I'm currently running SCCM 1706 and am using a custom TS for regular maintenance on our servers contain 4 repetitions with the following steps:
    1. Scan for updates (WMIC /namespace:\\root\ccm path sms_client CALL TriggerSchedule "{00000000-0000-0000-0000-000000000113}" /NOINTERACTIVE)
    2. Wait 1 minute
    3. Install Software Updates (Available for Installation - All software updates)
    4. Request Machine Assignments (WMIC /namespace:\\root\ccm path sms_client CALL TriggerSchedule "{00000000-0000-0000-0000-000000000021}" /NOINTERACTIVE)
    5. Wait 1 minute
    6. Machine policy evaluations (WMIC /namespace:\\root\ccm path sms_client CALL TriggerSchedule "{00000000-0000-0000-0000-000000000022}" /NOINTERACTIVE)
    7. Wait 1 minute

    Before deploying the TS, I'm also pushing out a new SUG to the machines in advance. This used to be very handy in the past when patching new servers built from RTM image (when certain patches become required only after some pre-requisite patches were installed first and machine was rebooted). However with the recent changes in the servicing model, I'm wondering if there's a better way to do this? In the past, this TS used to be working relatively quickly (usually it would complete within 3 hour window), but I've noticed that it takes longer and longer to every month (now it runs over 6 hours). Looking closer at the Task Sequence status messages, I'm seeing that the time it takes to execute the 'Install Software Updates' steps (on servers that are patched month to month) takes pretty much the same time for all the 4 runs (or subsequent runs take longer), however during the first run it does install all the updates and performs a reboot, and usually it has no updates left to be installed during the remaining three runs (and the action is configured with the ‘Evaluate software updates from cached scan results’ checkbox ticked). Is there any risk of consolidating these 4 runs down to just one (or maybe two)? Would switching to Full scan instead of using the cache help to reduce the time of execution?

    Installing all the available updates via the Software Center manually runs a lot quicker and usually takes less time than it would take to run the TS with the 'Install Software Updates' step. But I need to do it in TS, because apart from installing updates, it has some additional pre- and post- maintenance steps and because I don't always have the possibility (and/or the desire) to touch every machine during patching. An alternate approach that I'm currently considering is to have a custom script that would just invoke InstallUpdates method of CCM_SoftwareUpdatesManager class and keep waiting for completion (say, until the value of the EvaluationState property for all the updates become greater than 7)

  • Marc Westerink commented  ·   ·  Flag as inappropriate

    I've been able to successfully download and install updates after increasing the number of CPU's from 1 to 4 and from 4 GB to 8 GB RAM on the virtual machine used for Image Building of a Windows 10 1709 image on a ConfigMgr 1710 site based on Dr. Michael Kischel's comment.

    This makes me wonder how the Product Team test this behavior. While it is OK to figure out what to do to make this work, I'd appreciate it if the Product Team would define the system requirements that have to be in place to make the 'Install Software Updates' task work.

    We shouldn't have to work around issues to make things work or use alternative strategies due to lack of documentation. Microsoft, please specify the requirements to make this work.

    Nevertheless, I prefer to use MDT for image building but some customers simply don't want to have duplicate environments just because of these anomalies...

  • Dominik commented  ·   ·  Flag as inappropriate

    Is there any status update in this? it is very annoying to wait after OSD Task sequence is completed, until the recent updates are installed. Of course most of them are integrated in the OS Image, but this is never 100%. Also this is a issue for Office 2013 / 2016, since update integration is a pain ********** there. The goal of a OSD Task sequence should be to have completely finished machine at the end. Other software deployment tools are able to do this.

  • David W commented  ·   ·  Flag as inappropriate

    How about the ability to deploy directly from a selected list of Update Groups instead of having to have an active software update deployment?

  • Timothy commented  ·   ·  Flag as inappropriate

    When currently having the Install Software Updates step in the task sequence, together with enabling Bitlocker, it will trigger the requirement to fill out the bitlocker key while booting, after (some) updates have been installed by this step. Tested on Windows 10 v1703 Enterprise.

  • Paul Faulkner commented  ·   ·  Flag as inappropriate

    For people having software update scan issues running a build and capture on Windows 10 1703 and above....

    It seems that from 1703 onwards, clients during a build and capture task sequence (in MDT or SCCM) will try to download the update catalog directly over the internet from Windows Update.

    The timeout occurs (even if you increase to 5 hours) as the client obviously can't connect to the internet during a B&C. So you need to add some registry entries to the task sequence to prevent it talking to Windows Update.

    There's a great article here that explains it in detail....

  • LPM commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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.

  • LPM commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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.

  • LPM commented  ·   ·  Flag as inappropriate

    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
    Added restarts

    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?

← Previous 1 3

Feedback and Knowledge Base