Moving to Supersedence Software Update Model
Starting December 28, 2018, we are moving to a supersedence model for software updates in our third-party software update catalog. Before this change, we would mark previous versions of software updates as expired.
Topics covered in this article:
Why are We Making this Change?
With the Third-Party Software Update Catalogs feature in Configuration Manager 1806+, all third-party updates in a catalog are published. When we expired previous updates in our catalog, those previous versions were immediately marked expired when a new update is released. When an update is marked as expired, it can’t be deployed in Configuration Manager. The immediate expiring of updates could cause issues where customers don’t have enough time to fully deploy updates through all testing cycles for products where new updates are released frequently.
What’s the Supersedence Model Look Like?
By moving to a supersedence model, you will have complete control over how long you want to keep previous versions available for deployment that have been superseded.
You can control whether you want superseded updates to be immediately expired or delay expiring superseded updates for a certain number of months using the Supersedence Rules option on your software update point. In the example below, configuration manager won’t expire superseded updates until they have been superseded for 1 month.
In today’s catalog update in our lab, we can see the previous versions of applications are superseded and not expired. This change will allow the superseded application updates to continue being deployed for an additional month in our configuration.
If you are not expiring superseded immediately and using automatic deployment rules, you will want to ensure that you exclude superseded updates in your criteria to ensure your ADR’s only deploy the latest updates.
