Deferal "breaks" SCCM supersedense?!?

Hi everybody,

we’re using PSADT with Configuration Manager and we’re very happy. There is only one nasty thing where I wanted to hear if anybody else has solved this already:

We have an application XYZ Ver 1.0 and XYZ Ver 2.0 - both using PSADT. Installation is mandatory but we allow users to defer the installation 8 times. In Configuration Manager XYZ 2.0 supersedes XYZ 1.0 with auto-uninstall of XYZ 1.0.

When we now deploy XYZ 2.0 to a client, that has XYZ 1.0 installed, the uninstallation of XYZ 1.0 starts immediately and then the Welcome Screen with deferral for XYZ 2.0 comes up. If the user decides to defer - he’s left with no version of XYZ on his computer at all… Any idea how to either avoid, that XYZ 1.0 gets uninstalled or how we can inform the user that the uninstallation is necessary because we want to install a newer version?

Thanks a lot in advance!
Stefan

We have completely ditched SCCM supersedence in my company. We don’t use it because it causes more problems than it solves.

Instead we do this for every application:

  1. Show welcome dialog
  2. Uninstall previous version, delete the installation directory and other files and registry entries if still leftover. This includes cleanup after the current version (the one youre about to install)
  3. Install new version
  4. Copy any additional configuration/registry entries/custom SCCM detection
  5. Exit

This way we dont have to worry about supercedence or upgrading. It would also fix your problem. Nothing would happen if they didnt go through the Welcome dialog. Its also a one application deployment.

Since the uninstall via supersedence runs prior to the xyz 2.0 application running, there’s no method via supersedence to prevent that situation. To help mitigate the impact, you could add verbiage to the welcome/deferal dialog that any old versions have been removed to ensure the end user is aware that they’re now running without xyz 1.0.

As for luki1412’s suggestion, that is definitely one way of doing it, but you’d have to ensure you remove any allocations to the old deployment(s) before deploying the upgrade. Whether that’s via an added exclude collection for the old collection against the new one or otherwise deallocating it. Otherwise, there may be some yo-yoing or failed attempts to reinstall the old version.

That’s one plus with supersedence, it handles the old deployments automatically.