Microsoft

System Center Configuration Manager Feedback

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.

702 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Stephen OwenStephen Owen shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
    Noted  · 

    32 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • BrachusBrachus commented  ·   ·  Flag as inappropriate

        I'd like to see some better intelligence with this process. We use Mimecast for Outlook and distribute it via CM. When a new version is released, it comes out with a new product code. So if someone installs the update ahead of us deploying the new version, CM will downgrade them back to the older one.

      • GAGA commented  ·   ·  Flag as inappropriate

        Considering the risk posed if a deployment triggers unintentionally, this really should be a high priority.

      • GAGA commented  ·   ·  Flag as inappropriate

        This should really be a high priority given how seriously it can negatively affect existing setups.

      • Roth, ChaseRoth, Chase commented  ·   ·  Flag as inappropriate

        I tried some of the work-arounds for deploying in a particular order. It still didn't seem to work for me. This just needs to be fixed without excusing the shortcomings. I should be able to chose: to uninstall previous or not (I can) as well as required or not (I can't). Simply if the app is "Available" should not trigger installs.

      • bdambdam commented  ·   ·  Flag as inappropriate

        @Edward Perkins, the problem here is a feature defaulting to enabled when deployments are made. So the workaround is to not create deployments when the update is superseded. Deploy the app first then add the supersedence relationship.

      • Chris WrotenChris Wroten commented  ·   ·  Flag as inappropriate

        From my point of view, supercedence is an excellent way to manage an Application's Lifecycle within your organization. For now, the only real 'workarounds' seem troublesome and the mix of behaviors between User deployments and Device deployments makes it very very frustrating. The only alternative currently is to ignore this feature all together and make use of planned rollouts, hoping that an old version's deployments are removed at the same time the new version is available.

      • Edward PerkinsEdward Perkins commented  ·   ·  Flag as inappropriate

        When you say "make a deployment of Version 2.0 first" do you mean the application needs to be deployed to a collection? Or would it suffice to simply create the version 2.0 application first without an actual advertised deployment. I'm going to assume that you mean it has to be deployed to a collection before proceeding. Thanks for the tips, I was about to hit the switch when I came across your article, slightly aged as it may be. Thank you!

      • JohnJohn commented  ·   ·  Flag as inappropriate

        Thanks for the workaround! I agree it is a very annoying behavior. I only experienced it in a test environment, but was certainly caught off guard when I saw it happen.

      • Roth, ChaseRoth, Chase commented  ·   ·  Flag as inappropriate

        This really is a broken feature. I have many situations where we'd like to use supersedence, but haven't been able to. Like many others we tried using this feature when first available in 2012, and deployed a new version of SMARTBoard to EVERY computer that had the old version of the software installed, even though BOTH of the deployments were AVAILABLE and NOT REQUIRED.

        Please please fix it! We really need this ability. There is no other way to say "before you can install this application, that application needs to be uninstalled." I'd like to be able to say as a dependency a certain application CANNOT be installed and it would have the option to uninstall it, but I can see that that sort of functionality really is more appropriately suited as a supersedence and not really a dependency.

      • Kyle EricsonKyle Ericson commented  ·   ·  Flag as inappropriate

        Yeah we went to deploy Solidworks 2017 with this bug and everyone got it. Caused us a ton of down time this needs to be fixed.

      • GAGA commented  ·   ·  Flag as inappropriate

        Tested in SCCM 1702. This has not been fixed for deployments to device collections.

      • bdambdam commented  ·   ·  Flag as inappropriate

        This appears fixed in 1702 for new user deployments. You can't change existing deployments so you would need to recreate them. Device deployments still have the old behavior. When creating a new user deployment for a superseded application the 'Automatically upgrade any superseded versions of this application' is now enabled and defaults to unselected.

      • John HalversonJohn Halverson commented  ·   ·  Flag as inappropriate

        We observed this happening with an Office Suite deployment. Our entire enterprise got upgraded in a non-controlled fashion. We called Microsoft. They initially told us that unless there was a "Required" deployment, that the systems could not automatically update. Then, we were told that if we had an application with a supersedence that was also part of a Task Sequence, that would cause it. That didn't make sense either. I eventually found out how this was happening through research. There should never be a way that automatically deploys anything that is not fully controlled. Period.

      • Qasim MashwaniQasim Mashwani commented  ·   ·  Flag as inappropriate

        Superseded Application runs in the context defined by the Deployment Type of the Current Application.

        An addition to this request, when configuring supersedence consider the following:

        1. Current Application contains a Deployment Type which has Installation Behavior set to "Install for user" and is targeted to a machine. It also contains a Deployment Type which has Installation Behavior set to "Install for system".
        2. The Deployment Type which installs for system is Priority 1 and the Deployment Type which install for user is Priority 2.
        3. Superseded Application contains a Deployment Type which has Installation Behavior set to "Install for system if resource is device, otherwise install for user".
        4. Supersedence is configured so the Old Deployment Type maps to the Replacment Deployment type which is Priority 1.
        5. Current Application install is attempted on the client and it fails because the Superseded Application uninstall runs in the User context. The user does not have sufficient rights to run the defined uninstall program successfully for the Superseded Application so the Current Application install cannot run.

        Conclusion and Suggestions:

        Logic follows that the Old Deployment Type Uninstall selection will result in the Uninstall program running in the System context.

        In practice the Uninstall program actually runs in the user context even though both applications are targeted to machines, and the Replacement Deployment Type is configured to run in the System Context. The prescense of a Deployment Type which runs as user in the Current Applicaiton alters the intended behavior of the Superseded Application causing it to run in the wrong context.

        Update the code so that the Superseded Application runs in the context defined in its Deployment Types not in that of the Current Application.

      • bdambdam commented  ·   ·  Flag as inappropriate

        FWIW: I just tested this in 1610 and the issue is still present.

      • Mads Nyberg HansenMads Nyberg Hansen commented  ·   ·  Flag as inappropriate

        Another possible work-around is to create a task sequence containing only the superseding application and deploy this as "Available". This will not force the superseded application to update (tested in 1606).

      ← Previous 1

      Feedback and Knowledge Base