SCCM Dependency: Supersedence Rule in Application Packaging - Bug or Feature?
If we were to manually install and manage software on a large number of target devices, the process would be very expensive and complicated. To avoid that hassle, enterprises use software deployment tools to simplify these tasks.
When it comes to distributing software, the Configuration Manager (SCCM) is the most known and widely used tool.
Reminder: Microsoft releases Configuration Manager updates three times per year; each update version is supported for 18 months starting from its release date: four months for security and critical updates and another 14 months for security updates only. Each newly released version comes with new features. You can keep yourself up-to-date with the latest feature release notes by taking a look here.
As an application packager, there are two features that I find particularly helpful in the Configuration Manager because (when used correctly) they take a huge burden off my shoulders when managing packaged applications:
- The first one relates to the application dependencies and how they are handled using the Configuration Manager Console.
- The second one refers to software upgrades and how to easily upgrade from one version of your software to another.
In this article, we will be diving into these features and getting a wider overview of what happens when the deployment of your new dependency gets blocked by SCCM after you've superseded the old version. Is this a bug or a feature?
Let's sort it out.
How to handle application dependencies in the Configuration Manager Console
With Configuration Manager, you can set one or more dependencies for each deployment type of your application. You can make a selection from a list of deployment types for other available applications.
In scenarios where a deployment type is dependent on another deployment type that also has dependencies, you must remember that the maximum number of dependencies supported in the chain is 5.
Each dependency must be added to a “Dependency group”, either alone or with other dependencies. If multiple dependencies are added to the same “Dependency group” and one of them is present on a device, then that specific “Dependency group” is considered fulfilled for that device.
If you have multiple dependencies, you can increase or decrease which one you prioritize. This gives you the capability to control the order in which the Configuration Manager client evaluates the dependency.
Application dependencies do not need to be deployed separately; you can set the Configuration Manager client to automatically install them along with the main application.
Note: You can find more details on dependencies here.
Application Supersedence rule in Configuration Manager: replacing an old application with a new version
For each application you create, the Configuration Manager offers the option to configure the deployment type of one or more applications. This is helpful when you want to update your application or replace it with a new deployment type. You can set up a new version of an application to upgrade or replace the old one.
If the “Uninstall” box is checked, then the Configuration Manager will automatically uninstall the superseded version of the application before it installs the newly created version.
If you set a deployment type to automatically “Uninstall” another deployment type, then both deployment types must be deployed to the same type of collection - either user or device collections.
Note: You can find more details on supersedence here.
Was SCCM blocking the deployment of your new version of the dependency?
You might think something is wrong if SCCM has blocked your deployment of a new version of a dependency. Some people see this as a bug, but I think it is actually a feature.
Let’s suppose you have an application that is dependent on another application; a new version has just been released for the latter, and you want to upgrade it.
If you have the “dependency” and “supersedence” relationship set up between them like in the screenshots above, then you will notice that if you are trying to deploy the new version of the dependency to the same target device where the old version is installed, the Configuration Manager will not be able to remove the old version.
The trick is in the AppIntentEval.log
Also, if you check the Deployment Status for the corresponding collection in the Configuration Manager Console, you will see the following error message showing that the supersedence rule is conflicting with the dependency one.
What is actually going on?
You could break the “dependency” and/or “supersedence” relationships, but if you do this, you'll miss out on the benefits of these two Configuration Manager features.
Because of how the Configuration Manager works behind the scenes, the solution is very simple.
All you need to do is add both versions of the dependency application to the same “Dependency Group.”. This way, you tell Configuration Manager that your application needs just one of the two versions of the dependency application to be installed on the target device. The immediate effect of taking that route is that it will allow the old version of the dependency to be replaced with the new version on the target device.
As mentioned before, this conflict between the “dependency” and the “supersedence” relationship is often seen as a bug in Configuration Manager. However, in reality, it is a feature. It’s there by design, and its role is to prevent a dependency from getting uninstalled if it's superseded accidentally.
Dependencies and supersedence relationships are very helpful features in Configuration Manager (SCCM) - they allow for a more seamless process in our work.
The fact that you get an error when trying to supersede the old version of your dependency doesn't mean it's a bug - it's actually an option that requires that you let Configuration Manager know that you need any of the versions of the dependency to be installed in order for your application to work properly.
Have you encountered this situation? Do you consider it a bug or a feature? Let us know in the comments.