Microsoft

System Center Configuration Manager Feedback

Suggestion box powered by UserVoice

How can we improve Configuration Manager?

Fix Supercedence behavior

This is definitely in the catagory of a bug or design change.

Consider this scenario:
* app A deployed to a number of machines via required deployment
* app a Version 2.0 comes out, we create a supersedence for the old app
* deploy Version 2.0 to a small collection with an 'Available' Deployment
* witness in horror as machines automatically begin applying the updated version
* check the deployment after the fact and discover that a check box of ''Automatically upgrade any superceded versions of this application' has now appeared in the deployment, and is forced checked.

No where in SCCM is this behavior explained or documented and I've seen this bite SCCM Admins at two separate customers now.

The workaround for controling this behavior is to make a deployment of Version 2.0 first, THEN create the supercedence, which will add the checkbox to the deployment but NOT check it.

Very very strange and puzzling behavior here.

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

    49 comments

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

        We just need that box to be available for us to check and uncheck and for it to work as it is labeled. For instance, I am in a higher ed environment and we want to make Office 2016 available to our users for them to upgrade at their own convenience. If I use supersedence to control the removal of office 2013, then it will upgrade them at the next maintenance window, regardless of the work-around mentioned above.

        So instead, I am forced to script the removal of office 2013 during the installation of 2016.
        (Of course of the removal of previous versions actually worked in the office configuration tool, then this would be a non-issue but that is another thread.)

        Supersedence needs to be fixed, please.

      • Anonymous commented  ·   ·  Flag as inappropriate

        This really does need to be fixed. Making packages available is how we deploy to laptops (so that they can install at a time convenient to them.

        I tried the workaround which worked for 90% of devices but the other 10% still automatically installed the software!

      • Stephen commented  ·   ·  Flag as inappropriate

        I voted that this does need to be fixed. However, I am disappointed that the workaround still behaves the same way for me and machines still automatically upgrade the superseded application regardless of that box being un-checked.

      • Andrew commented  ·   ·  Flag as inappropriate

        Given that the official documentation here (https://technet.microsoft.com/en-us/library/gg682071.aspx) states "When you supersede an application, this applies to all future deployments and Application Catalog requests. This will not affect the existing installations of the application." this "feature" is beyond unsettling.

        It would seem that even MS's own support team needed to set up a lab with multiple scenarios to determine how this "feature" would behave (see https://blogs.technet.microsoft.com/umairkhan/2014/03/07/configmgr-2012-application-supersedence-behavior-with-task-sequence-deployments/) as this behavior was not documented in any way (?!?!!?)

        This, combined with the total lack of this option being visible in the deployment wizard *AND* being unavailable to change after the deployment *AS THE BEHAVIOR IS DETERMINED BY SCCM AND NOT THE ADMINISTRATOR* runs completely counter to the philosophy of SMS/SCCM - "always a client side decision, never server side" (see client notification if you don't understand the reference/history). How this can even be documented anywhere as "by design" should be an embarrassment to all involved in this "feature".

      • Jeremiah Abbott commented  ·   ·  Flag as inappropriate

        Supersedence is a great feature, but this coupled with the fact that referencing a superseded Application in a Task Sequence deployment can cause unexpected deployment of the Superseding application makes me a bit leery of recommending its usage unless someone fully understands the ramifications of what supersedence does in client policy.

      • HoustonAU commented  ·   ·  Flag as inappropriate

        I will agree with this improvement. Especially with larger applications that have longer installs, it's often worthwhile to give users the option to do the installation when convenient.

      • Ryan Steele commented  ·   ·  Flag as inappropriate

        When deploying an Application as "available", if it supersedes an application that is already installed on a targeted client, it will be installed automatically. It should be possible to deploy a superseding application as "available" without it automatically installing on any client with the superseded application installed.

        As a workaround, you can set the "Installation deadline to upgrade users or devices that have the superseded application installed" to a date far in the future, but I believe this will only be effective if the "work hours" option hasn't been enabled in the Software Center.

      1 3 Next →

      Feedback and Knowledge Base