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,829 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 →
    started  ·  Admindjam (Admin, System Center Configuration Manager) responded  · 

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

      • Anonymous commented  ·   ·  Flag as inappropriate

        Hi Gents,

        When I start to update from 1602 to 1702 I get this error 0x80240020(-2145124320)

      • Dr. Michael Kischel commented  ·   ·  Flag as inappropriate

        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.

      • Jay Foreman commented  ·   ·  Flag as inappropriate

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

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

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

      • HBacon commented  ·   ·  Flag as inappropriate

        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?

      • Gokulnath commented  ·   ·  Flag as inappropriate

        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.

      • Steffen commented  ·   ·  Flag as inappropriate

        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+

      • PH commented  ·   ·  Flag as inappropriate

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

        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.

      • Alslinet commented  ·   ·  Flag as inappropriate

        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.

      • MERIGOT commented  ·   ·  Flag as inappropriate

        Hi there,

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

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

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

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

        I'm running to this issue exactly. This is super terrible to troubleshoot and worse when you have to explain to a customer.

      Feedback and Knowledge Base