The Dependency - Supersedence Rule in Configuration Manager - Bug or Feature?

Written by Horatiu Vladasel · November 11th, 2020

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, Configuration Manager (SCCM) is the most known and widely used tool.

Reminder: Microsoft releases updates for Configuration Manager three times per year – each update version is supported for 18 months starting from its released 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 having 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:

  • 1. The first one refers to the dependencies and how they can be handled using the Configuration Manager Console.
  • 2. The second one refers to software upgrades and how to easily upgrade from a version of your software to another.

In this article, we will be diving into these features and get 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 dependencies in Configuration Manager Console

For each deployment type of your application, with Configuration Manager you can set one or more dependencies from a list of deployment types of other available applications.

Each dependency must be added into a “Dependency group”, either alone or with other dependencies. If multiple dependencies are added into the same “Dependency group” and one of them is present on a device, then that specific “Dependency group” is considered fulfilled for that device.

Note: You can find more details on dependencies here.

Supersedence: replacing an old application with a new version

For each application you create, Configuration Manager offers the capability to configure the deployment type of one or more applications that you want to update or replace by the new deployment type of your application when it's ready. So, you can set up the new version of the application to replace the old application.

If the “Uninstall” box is checked, then Configuration Manager will uninstall the superseded version of the application before it installs the newly created version.

Note: You can find more details on supersedence here.

Was the deployment of your new version of the dependency blocked by SCCM?

Some people see this as a bug, while 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.

SCCM Dependency diagram
SCCM Supersedence diagram

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, Configuration Manager will not be able to remove the old version.

The hint 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.

SCCM Error 0x80040322 - Rule is in conflict with other rules

What is actually going on?

Of course, you could break the “dependency“ and/or “supersedence“ relationships but if you do this, you will not be able to take advantage of the benefits of these two Configuration Manager features.

Because of how Configuration Manager works behind the scene, the solution is very simple.

SCCM Dependency diagram

All you need to do is to add both versions of the dependency application to the same “Dependency group”. This way, you basically tell Configuration Manager that your application needs both of the 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 application to be replaced with the new version on the target device.

SCCM Dependency Group setting

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 was superseded accidentally.


The dependencies and supersedence relationships are very helpful features in Configuration Manager (SCCM) - they allow for a more seamless process in our work.

And 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 both 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.