agent failed to catch superseded update misclassified as missing

TL;DR

Supersedence is a chain, not a flag: update B supersedes A, C supersedes B, and a host needs the newest applicable member, not the original. Agents misread this when they treat the catalog superseded boolean as the whole story, ignore that a superseding update may not apply to this host (different product or architecture), or use a stale catalog snapshot. The fix is to resolve the chain per host: walk from the required update to the newest applicable, non-declined replacement using current catalog data, and classify the host against that target.

agent failed to catch superseded update misclassified as missing

Use this when

• The agent reports a superseded KB as missing on hosts that carry its replacement.
• Or the agent ignores a needed update because an old chain member is installed.
• Disagreements cluster after cumulative update releases (monthly chain extensions).

Not for this skill when

• The update is declined or not approved in the patch tool. That is an approval state, not a supersedence reading error.
• The replacement update is genuinely not applicable to the host for a documented reason. Record it as not applicable, a distinct state from missing.

Steps

1. Take one disputed host and one chain, and walk the catalog supersedence data manually (each update supersedes and superseded-by lists). Verify: the correct target for that host is established by hand first
2. Find where the agent classification diverges: boolean use, stale snapshot, or applicability not checked. Verify: the divergence point is identified in the code or query
3. Implement chain resolution: from any required update, follow superseded-by links to the newest member that is applicable to the host product and architecture and is approved; that member is the compliance target. Verify: unit tests with multi-link chains and a non-applicable branch pass
4. Refresh the catalog data the classifier uses and stamp classifications with the catalog version. Verify: classifications from an old snapshot are visibly dated
5. Re-run classification for the fleet and reconcile against the patch tool compliance view on a sample. Verify: agreement on the sample, with remaining differences individually explainable

Variant phrasings

superseded update misclassified as missing agent chain resolution

The main phrasing.

walk supersedence chain newest applicable update target

The algorithm phrasing.

cumulative update chain compliance disagreement sccm wsus

The tool phrasing.

Compatibility: Compatibility: WSUS and ConfigMgr catalogs with supersedence metadata; vendor feeds with replacement data follow the same model.

Why it happens

Cumulative servicing makes supersedence the normal case: nearly every monthly update replaces last month. A classifier that handles it as an exception will be wrong every month, in both directions: crying missing over replaced updates (wasted work and false risk) and blessing hosts that hold only an ancient chain member (real risk hidden). Chain resolution per host, against current catalog data, is the only version of this logic that stays correct as chains grow.

Edge cases / pitfalls

• Servicing stack updates have their own chains and ordering rules; resolve them as their own class, not mixed into the cumulative chain.
• A superseding update in a different channel (for example a preview cumulative) should not become the target for production classification; channel is part of applicability.
• Keep the chain evidence with the classification (the path walked), so a dispute can be settled by reading, not rerunning.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_dnTbOMw9DpBk2O-0Adp0oQ