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,740 votes
Sign in
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Justin King shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    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

    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
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      • 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?

      • Dr. Michael Kischel commented  ·   ·  Flag as inappropriate

        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.

      • DOH commented  ·   ·  Flag as inappropriate

        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.

      • DOH commented  ·   ·  Flag as inappropriate

        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.

      ← Previous 1 3

      Feedback and Knowledge Base