patch superseded error sccm how to fix

TL;DR

In ConfigMgr, a superseded update is replaced by a newer one and should normally drop out of deployments automatically once the newer update is present and the supersedence rules run. Problems come from deployments built on software update groups that still list the old update, supersedence behavior set to not expire, or clients evaluating against an old group. Rebuild the update group with current updates, check the supersedence rules in the SUP settings, and let clients re-evaluate.

patch superseded error sccm how to fix

Use this when

• A deployment reports failures or required state for an update that has a newer replacement.
• Compliance reports list superseded updates as missing on many machines.
• A software update group was built months ago and reused every cycle.

Not for this skill when

• The update shows as Expired, not Superseded. Expired updates come from catalog sync and need removal, not supersedence handling.
• The newer update is not yet synchronized to the SUP. Sync first; supersedence cannot resolve to an update you do not have.

Steps

1. Identify the superseding update for the problem item in the console (its properties list superseded and superseding updates). Verify: the replacement update is named and is synchronized
2. Check the SUP component properties supersedence rules: whether superseded updates expire immediately or after a period, and that the newer update is not itself superseded. Verify: the rule matches your intended behavior
3. Remove the superseded update from the software update group and add its replacement, or rebuild the group from a current search. Verify: the group membership is current
4. Redeploy or let the existing deployment pick up the changed group, and refresh policy on sample clients. Verify: clients evaluate the new group membership
5. Re-run compliance summarization and check reports. Verify: superseded items no longer appear as required or failed

Variant phrasings

sccm superseded update still required deployment fix

The main phrasing.

software update group stale superseded updates cleanup

The group-hygiene phrasing.

sup component supersedence rules expire setting

The settings phrasing.

Compatibility: Compatibility: Configuration Manager current branch with a WSUS-backed software update point.

Why it happens

Microsoft publishes cumulative updates as chains: each new cumulative supersedes the previous. ConfigMgr mirrors that metadata, but deployments are snapshots of administrator intent. Static update groups keep pointing at the old link in the chain, and depending on supersedence settings the old update stays deployable and reportable long after its replacement exists, producing noise that looks like failure.

Edge cases / pitfalls

• Automatically created update groups from ADRs handle supersedence far better than hand-maintained groups; prefer ADR-managed groups for monthly cycles.
• Some LCU chains require the servicing stack update first; a superseded SSU in the group has different handling than a superseded LCU.
• Do not decline superseded updates in the underlying WSUS manually if ConfigMgr manages it; let the SUP rules do it so the two stay consistent.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst8PdPwjSgCgvHOn11WcA