patch agent applied out of band update out of order breaking servicing stack dependency

TL;DR

Out of band updates still have prerequisites: many require a minimum servicing stack or a specific cumulative update level first, and installing them out of order can fail or leave servicing unable to proceed. Make the agent resolve prerequisites from the update metadata for every update - out of band included - and order the wave as stack, then cumulative base, then the out of band update, verifying each layer before the next. Emergency pressure shortens windows; it does not repeal dependency order.

patch agent applied out of band update out of order breaking servicing stack dependency

Use this when

• An out of band update failed to install, or installed and subsequent updates began failing, on agent-managed hosts.
• The agent treated the out of band release as a single urgent item and skipped its normal prerequisite checks.
• Vendor guidance for the update names a required servicing stack or cumulative update level.

Not for this skill when

• The out of band update has no prerequisites and failed for its own defect. Escalate the defective update to the vendor.
• A human deliberately sequenced the update for a documented exception. Review that decision record rather than the agent ordering logic.

Steps

1. Stabilize affected hosts first: check their servicing health with DISM CheckHealth, confirm whether the out of order install left the stack or the target update in a pending or failed state, and record which hosts took the out of band update without its prerequisites. Hosts with a pending state need that state completed or backed out cleanly before any new sequence is attempted. Verify: affected hosts are inventoried with their servicing state, and any pending operations are identified for clean resolution
2. Establish the correct order from vendor evidence: for the out of band update, read its release notes and catalog metadata for prerequisite servicing stack and cumulative levels, and check a healthy host that installed it successfully, if one exists, to confirm the working sequence. Write the order down as the wave plan rather than holding it in the operator head. Verify: the prerequisite chain for the update is documented with its source, including exact stack and cumulative levels
3. Repair hosts in the correct order: install or verify the servicing stack first, reboot if the stack requires it, then the prerequisite cumulative update, then the out of band update, verifying each layer installed and the machine is healthy before the next. If the out of order attempt corrupted servicing, run the DISM and SFC repair sequence before starting the chain. Verify: a test affected host completes the chain in order and ends with the out of band update installed and servicing reporting healthy
4. Encode prerequisite resolution in the agent for all updates, with no emergency bypass: at wave build, the agent reads each update prerequisites, topologically orders the wave items per host based on what that host already has, and refuses to schedule an item whose prerequisites are neither present nor scheduled earlier in the same wave. Out of band items go through exactly the same path, just with an expedited window. Verify: a test wave containing an out of band item is ordered correctly per host, and removing its prerequisite from the plan makes the agent refuse the schedule with a clear reason
5. Review the emergency process that created the bypass: the post-incident fix should give urgent updates a faster approval and window path inside the normal ordering system, so the next emergency does not tempt anyone to skip dependency resolution again. Record the incident cost - hosts repaired, windows used - as the justification. Verify: the expedited path is documented and the next out of band release runs through it with ordering intact

Why it happens

Servicing dependencies are physical, not bureaucratic: an out of band update packages changes against components that a servicing stack or cumulative update delivers, and its installer assumes those components exist at the expected versions. Installing early makes the update fail, or worse, partially apply against mismatched components and leave the servicing store inconsistent for everything that follows. Agents create this failure when urgency is implemented as a shortcut around the normal planning path, because the dependency logic usually lives in that path. Keeping one ordering pipeline and making it faster under pressure, rather than bypassable, preserves both the urgency and the correctness the fleet needs.

Variants and edge cases

Out of band update for one product, stack for the whole OS

Cross-scope prerequisites are easy to miss because they live in different catalogs. The agent prerequisite check must span the operating system servicing chain, not just the product own updates.

Prerequisite is itself superseded by a newer cumulative

Order against levels, not exact KB identity: a host already beyond the prerequisite cumulative level satisfies it, and the agent should record satisfied by supersession rather than demanding the old package.

Vendor releases an out of band fix for the ordering bug itself

Occasionally the fix for a bad sequence is another update. Handle it as a manual, human-driven repair on affected hosts with vendor guidance open, not as a normal wave item.

Compatibility: Applies to patch agents deploying Windows out of band updates through WSUS, Configuration Manager, or vendor catalogs, with analogous dependency ordering for Linux package managers.

Provenance

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