This article is contributed. See the original author and article here.

Typically, a software update that supersedes another software update does one or more of the following actions:



  • Enhances, improves, or updates the fix that was provided by one or more previously released updates.

  • Improves the efficiency of the superseded update file package, which is installed on clients if the update is approved for installation. For example, the superseded update might contain files that are no longer relevant to the fix or to the operating systems that are supported by the new update. Those files aren’t included in the superseding file package of the update.

  • Updates newer versions of a product. In other words, it updates versions that are no longer applicable to older versions or configurations of a product. Updates can also supersede other updates if modifications were made to expand language support. For example, a later revision of a product update for Microsoft 365 Apps might remove the support for an older OS, but it might add additional support for new languages in the initial update release.


Consider the following scenarios in which you might need to deploy a superseded software update:



  • A superseding software update supports only newer versions of an OS. Some of your client computers run earlier versions of the OS.

  • A superseding software update has more restricted applicability than the software update it supersedes. This behavior would make it inappropriate for some clients.

  • If a superseding software update wasn’t approved for deployment in your production environment.


Microsoft Endpoint Configuration Manager current branch provides control for how superseded software updates are handled. Supersedence rules allow you to decide if superseded software updates are immediately expired or expired after a defined period. “Expired” software updates in the context of Configuration Manager are no longer deployable. They can’t be added to new deployments and will also be removed from any existing deployments.


 


Supersedence rules default to waiting 3 months before superseded updates are expired. It is recommended that you do not assume that superseded updates should be immediately expired in favor of the new, superseding updates. As noted above, there is no guarantee that supersedence is absolute. You should allow enough time to make sure superseded updates are no longer needed by any of your client computers.


 


Recovering an Expired Update


If you need to deploy a superseded update that has been marked as expired in Configuration Manager, follow the steps below.



  1. Change the Months to wait before a superseded software update is expired value on the Supersedence Rules tab of the Software Update Point Component properties page, to an interval that is greater than the supersedence age for the update. For example, if the update marked as expired was superseded six months ago, the months to wait interval would need to be greater than six months.







    NOTE: If the “Decline expired updates in WSUS according to supersedence rulesoption is enabled, the software update(s) may need to be reinstated prior to synchronizing software updates. Also, the interval change is global, meaning any expired update meeting the changed criteria could result in a state change, not just the desired software update(s).


  2. Synchronize software updates (scheduled or manual). See Synchronize software updates for more information.


References


Supersedence Rules


Expired Icon


Superseded Icon

Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.

%d bloggers like this: