none
Supersedence Behaviour when Previous Version is left as 'Required' RRS feed

  • Question

  • Hi,

    Could somebody clarify what the expected behaviour would be in this scenario:

    • Version 1.0 of an SCCM application is deployed to a set of users as 'Available' in Application Catalog (so a self-service install), and to a set of workstations as 'Required' (because we know a subset of our PCs need this application).
    • A new version 2.0 of the application is later created as a supersedence of v1.0 (without ticking 'update all clients'), but since it is only needed under specific circumstances we don't want to push it out as 'Required' and force a re-install everywhere, we want only for users to be able to run it as needed. So we deploy it only to users as 'Available' and leave the old 'Required' deployment in place for v1.0.
    • I should have mentioned that v2.0 overwrites the detection rule for v1.0 (because the rule is based on a registry value holding the version number, 1 or 2)

    What then happens if a user installs v2.0 from App Catalog on a workstation that still has v1.0 pushed to it as 'Required'?

    Is SCCM smart enough to go "I no longer meet the detection rule for v1.0 which is a required app, so I need to install it again.....but hang on, I actually have a superseded version installed already so that's cool already"?

    The same question arises if you have two workstation collections and you push a superseded version of a required app to only one of them, but (accidentally or otherwise) you have a workstation in both collections. Will it get only the newest version or will they 'fight' and try to overwrite each other constantly?


    Tuesday, June 9, 2020 3:02 PM

All replies

  • Hi,


    When the option to uninstall the superseded deployment type is selected, a deployment type cannot be superseded by a deployment type that was deployed to a different collection type. For example, a deployment type that was deployed to a device collection cannot be superseded by a deployment type that was deployed to a user collection if the option to uninstall the superseded deployment type is selected.
    If you want to update to a newer version of the same application (with the same application ID), do not check Uninstall.
    By default, the new deployment type doesn't uninstall the deployment type of the superseded application. This scenario is commonly used when you want to deploy an upgrade to an existing application. Select Uninstall to remove the existing deployment type before the new deployment type is installed. If you decide to upgrade an application, make sure that you test this in a lab environment first.


    Hope it helps.


    Best regards,
    Larry

    Please remember to mark the replies as answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, June 10, 2020 8:45 AM
  • Thank you for taking the time to reply, but I'm afraid this does not address the question. It is complex to explain so I'll try to give a more straightforward example.

    You have App v1 deployed as Required to two workstation collections, let's say "Office PCs" and "Workshop PCs".

    You then create App v2 as a supersedence but deploy this only to "Office PCs".

    All other things being correct, are we agreed the net result would be that "Office PCs" get the upgraded version and "Workshop PCs" do not?

    My question then is what happens to a PC that's in both collections?  It will get v2 via one route but it's still getting v1 applied via the other. SCCM will notice that v1 is missing when it next does an evaluation and in theory would try to reinstall it - But is it smart enough to realise that is has another app instead that supersedes the first, therefore stick with that one?   If not, it's going to constantly bounce between versions as each overwrites the detection rule for the other.

    Thanks again

    Wednesday, June 10, 2020 3:56 PM
  • When an application has supercedence set against an older version once the new version becomes applicable then the older version is no longer relevant.The older version will no longer be in software center and will never try to be installed again until you remove the newer version of said app.

    There is no fighting, just the original application is no longer applicable, its like you never deployed it to the device \ user.

    hope that helps.


    Richard Knight | Collection Refresh Manager | Automate detection rules for patch \ msp files | Twitter


    Wednesday, June 10, 2020 4:53 PM
  • Thank you Richard, in my experience the old revision still applies in cases where it's still the only revision deployed to a particular collection. I don't think that contradicts what you've stated, because you said "once the new versionbecomes applicable...".   So I fully agree with that. The new version is not applicable to machines to which it has not yet been deployed.

    We quite often make use of this for testing. When we supersede an application, initially nothing happens. We deploy it then to an empty collection and then we gradually start tossing PCs into that collection. Only those to which it is deployed get the new revision.

    Whilst typing this I realise I may have answered my own question - when we put PCs in the test collection in the above scenario, some/all of them will still be in other collections that have the old revision still applied, and they DON'T keep rolling back, otherwise we'd notice our tests are all broken!

    So I think my assumption is correct: SCCM goes "I have a required app missing because I'm in collection A, but actually I have a newer revision already via collection B, so ignore that requirement (don't try to install the older one again)"

    Thursday, June 11, 2020 8:48 AM
  • Hi,


    Thanks for posting in TechNet and we're glad that the question is solved now. If you have any questions in future, we warmly welcome you to post in this forum again.

    Have a nice day!


    Best regards,
    Larry

    Please remember to mark the replies as answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, June 11, 2020 9:01 AM