Microsoft

System Center Configuration Manager Feedback

Suggestion box powered by UserVoice

How can we improve Configuration Manager?

Install Servicing Stack Updates Before Other Updates

Currently, when servicing stack updates and regular updates are deployed in the same software update group, the patches do not apply in a determinant order. This leads to cases where a cumulative update that requires a new servicing stack is installed before the servicing stack itself.

While this can be worked around by separately deploying the servicing stack update before updates that require said servicing stack, it would be much more convenient if the update installation process checked if there are any servicing stack updates to be deployed and automatically installed them first

285 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Jesse Schauer shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    7 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • HoustonAU commented  ·   ·  Flag as inappropriate

        As much as I would love this, it is a far wider problem with the Servicing Stack. This should be resolved at the OS level, not the Config Mgmt level.

        They need to address the entire issue of SSU updates in general, why do we need them, why are they different from other updates, why aren't they identified as SSU in some way etc.

        Fix the updates themselves and we wont need to modify SCCM

      • gxt commented  ·   ·  Flag as inappropriate

        https://support.microsoft.com/en-us/help/4471329

        Microsoft strongly recommends you install the latest servicing stack update (SSU) for your operating system before installing the latest cumulative update (LCU). SSUs improve the reliability of the update process to mitigate potential issues while installing the LCU and applying Microsoft security fixes. For more information, see Servicing stack updates.

        If SSU's aren't installed first, they cause the:

        1. BSOD we had back in January 2018
        2. Loss of USB we had in February 2018

        "You have to get them installed first. To have them install second/or not at all can crater a machine." (credit: Patch Lady Susan)

        In my experience, the installation order in ConfigMgr is random and given the importance of having the SSU installed first, we can't just install the SSU first and then LCU after, because once the deployment deadline is passed (for example a newly built machine), we can't guarantee the order.

      • Max commented  ·   ·  Flag as inappropriate

        This is the most important/missing feature today. This is right not only for servicing stack updates but also for regular updates. Currently there is no simple/builtin way to get (some) systems fully patched using a single deployment schedule within a single window, if some updates fail during the deployment, or if some updates cause WU client to detect new updates in next scan cycle.

        The problem is that a deployment may show as compliant, let's say in the morning after patching, but later it the same deployment shows as non-compliant. This is because the re-scan or re-evaluation cycle occurs after the maintenance window ends. According to the documentation the interval between 2 scan cycles or 2 deployment re-evaluations cycles cannot be set to less than 1 day. The documentation states that if the interval is set to less than 1 day it is reset automatically to 1 day.

        There a lot of workarounds to get deployment re-scheduled again or creating multiple deployments or multiple cycles, but this get complicated and causes a an administrative overhead, instead of packing multiple cycles into a single step.

      • bdam commented  ·   ·  Flag as inappropriate

        @Hermann, I agree, integrating the SSU into the CU is the better solution but it's not one the ConfigMgr product team can do. Since the SSU updates the mechanisms used to install the CUs who knows if that's even technical possible.

        I'm not sure I understand your endless loop comment though. The loop will end when either the maintenance window finishes or all applicable updates are installed. To clarify, we're not talking about full evals after _each_ update, just after _all_ the updates have been installed.

      • Hermann commented  ·   ·  Flag as inappropriate

        Would be nice, if servicing stack update be integrated in cumulative Updates (Pre-Install), because this doesn't need any reboots. Suggestion that it starts a full evaluation after applying updates could have big negative impact on Servers (endless loops).

      • bdam commented  ·   ·  Flag as inappropriate

        The recent Servicing Stack Update released out of band in May was made a requirement for the June cumulative updates but itself did not require a reboot. This created a conundrum for organizations patching devices with maintenance windows. Because of the lack of reboot on the servicing stack update there was no option to run a full evaluation that would detect that the cumulative update was now applicable and install it within the same maintenance window.

        A few ways to solve that problem but the one that strikes me as straight forward is to modify, extend, or duplicate the "if any update in this deployment requires a system restart, run updates deployment evaluation cycle after restart" feature introduced in CB 1606 to allow it to run a full evaluation after all of the updates have installed, regardless of the reboot condition. Where maintenance windows allow this would enable the user to install updates that are newly available regardless of reboot.

        Bonus Points: Support an option that does so even if the updates fail. So many times simply retrying an install solves the problem.

      Feedback and Knowledge Base