agent timed out waiting for windows update service to restart after servicing stack update

TL;DR

After a servicing stack update, the Windows Update service restart is not a normal service restart - the stack replaces servicing components and the service can take far longer to return, or return only after a reboot. Fix the agent wait logic: poll the service and a real scan capability check instead of a fixed short timeout, treat stack updates as their own wave step with a reboot where required, and extend the timeout for this step specifically based on measured fleet timings. Never mark the host failed while its servicing stack is mid-replacement.

agent timed out waiting for windows update service to restart after servicing stack update

Use this when

• Waves stall or fail hosts at the servicing stack update step with agent timeout errors, while the hosts later turn out healthy.
• The Windows Update service shows start pending or is temporarily absent during the stack update window.
• Hosts that the agent timed out on complete their updates fine when a human retries later.

Not for this skill when

• The Windows Update service never returns even after a reboot. That is a damaged service or store; use the service repair skills.
• The timeout is on a normal update install, not the stack step. That is a general remote execution timeout problem.

Steps

1. Measure the real duration on your fleet: from recent stack update installs, collect how long the Windows Update service was unavailable or unresponsive, per machine class, including whether a reboot was required before it answered a scan. Compare those figures with the agent current timeout for the step, and quantify how many timed out hosts were simply slower than the timeout. Verify: you have measured service return times and the gap between them and the agent timeout is documented
2. Separate the stack update into its own wave phase: the agent installs the servicing stack update, then enters a dedicated wait-for-servicing phase that does not dispatch any other update work to that host. Other updates for the host queue behind this phase instead of racing a service that is being replaced underneath them. Verify: a test host shows no other update activity attempted while its servicing phase is in progress
3. Replace the fixed sleep or short timeout with capability polling: the agent polls the service state and then proves readiness by issuing a lightweight update scan query and waiting for a valid response, with a generous ceiling based on your measured times plus margin. A service that reports running but cannot scan yet is not ready, and the poll must catch that distinction. Verify: the agent waits through a slow stack recovery in testing and proceeds only when a scan query actually answers
4. Handle the reboot-required outcome explicitly: if the stack update sets a pending reboot, the agent records the host as awaiting reboot in the wave tracker, triggers or schedules the reboot per wave policy, and resumes the host remaining updates after the reboot and a fresh capability check, rather than timing out and failing the host. Verify: a host whose stack update requires reboot is tracked through reboot and resumes its updates without a failure mark
5. Tune and monitor the phase as its own metric: report stack phase duration and timeout counts per wave, and revisit the ceiling when a new stack generation changes the timings. If timeouts persist at the generous ceiling, treat them as real servicing faults on those hosts and route them to DISM and service health checks instead of extending the wait forever. Verify: stack phase timings appear in wave reports and hosts exceeding the ceiling are routed to servicing repair with their records attached

Why it happens

Servicing stack updates replace the very components that install updates, including parts of the service the agent is waiting on. During that replacement the service can stop, linger in start pending, or come back before its catalog is ready to answer scans, and the whole process scales with store size and disk speed. An agent timeout written for ordinary service restarts - seconds to a minute or two - is simply the wrong model for this step, so it declares healthy hosts failed mid-recovery and, worse, may retry in ways that collide with the still-running stack install. Modeling the stack update as a distinct phase with capability-based readiness matches the agent behavior to how servicing actually works.

Variants and edge cases

Stack update delivered through Configuration Manager or WSUS

The same wait applies, but readiness evidence should come from the client scan result in the management tool as well as the local service check, since the two can disagree briefly.

Agent timeout is global and cannot be set per step

Wrap the stack step in its own sub-workflow with its own timing configuration, or pre-stage stack updates in a separate earlier wave so the main wave never contains the step.

Host service returns but scans fail with a store error

Readiness polling has done its job by surfacing a real fault. Move the host to the servicing repair workflow instead of looping the wait.

Compatibility: Applies to patch agents installing Windows servicing stack updates on Windows 10, Windows 11, and Windows Server 2016 and later.

Provenance

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