sccm maintenance window expired before updates finished installing

Not specified by the original author.

TL;DR

When a maintenance window closes mid-install, Configuration Manager stops starting new work and the deployment stalls until the next window - by design. Fix the fit, not the client: measure the real install plus restart time for your update set, size windows to cover it with margin, and sequence large updates early in the window. For fleets that cannot get longer windows, split the update set across nights or use deadline settings that allow completion outside the window where policy permits.

sccm maintenance window expired before updates finished installing

Use this when

• Deployments repeatedly show in progress or timed out at window close, then resume the next window.
• Machines complete small update months but never finish months with large cumulative or feature updates.
• Window length was set historically and never re-measured against current update sizes.

Not for this skill when

• Updates fail inside the window with a specific install error. The window is not the problem; the install error is.
• Clients never start because policy has not arrived. That is a policy delivery issue before any window logic applies.

Steps

1. Measure reality on representative hardware: time a full cycle of the current update set - download if not pre-staged, install, restart, and post-restart completion - on your slowest common machine class, not the fastest. Record each phase separately so you know whether download or install is eating the window. Verify: you have a measured total duration per machine class, with the largest phase identified
2. Compare the measurement with the actual windows and deployment settings: window length, whether downloads are allowed outside the window to pre-stage content, maximum run time, and restart countdown settings. The gap between measured time and window length is the size of the problem to solve. Verify: the shortfall is quantified, for example a window that is shorter than the measured install plus restart by a known amount
3. Pre-stage content so the window is spent installing, not downloading: set the deployment to download content before the deadline where your design allows, and confirm on a pilot machine that content sits in the cache ready when the window opens. This single change rescues many windows that looked too short. Verify: a pilot machine enters its window with content already cached and begins installing immediately
4. Resize or split deliberately: extend the window where operations allow, or split the deployment so critical cumulative updates go in the first window and lower priority items follow in the next. Set maximum run time and restart behavior to match the measured durations rather than defaults copied from older deployments. Verify: the deployment design now fits the measured duration, with the split or extension approved and documented
5. Pilot on each machine class, watch completion inside one window including the restart, then roll out and track a specific metric - deployments completing in a single window - for the next cycle. If completion still fragments, the next constraint is machine availability, so review when machines are actually online during windows. Verify: pilot machines finish in one window and the single-window completion rate is tracked for the fleet rollout

Why it happens

Maintenance windows are a hard scheduling contract: Configuration Manager will not start work that cannot finish inside the window, and work caught mid-flight when the window closes waits for the next one. Update sets have grown - cumulative updates are larger, servicing stacks add steps, and restarts take longer on older hardware - while windows in many organizations were sized years ago and never revisited. The mismatch produces chronic partial compliance that looks like client failure in reports. Aligning window length, pre-staging, and deployment size with measured reality restores the contract instead of fighting it, and keeps the protection windows exist to give production systems.

Variants and edge cases

Servers with a monthly four hour window and a feature update

Feature updates rarely fit shared windows. Give them a dedicated one-off window or a separate deployment ring with its own schedule rather than stretching the monthly window for everything.

Window fits but machines are off during it

Availability is the real constraint. Add wake on LAN, or coordinate with operations so machines are powered for the window, and measure online rate during windows.

Overlapping windows from multiple collections conflict

A machine in several collections gets the combined window behavior, which may be shorter than intended. Review the effective windows on the client, not just the collection you deployed to.

Compatibility: Applies to Microsoft Configuration Manager current branch maintenance windows for software updates, applications, and task sequences.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_zebi5U1TFFW6ESboigzV-A

Resolved from the public thread: https://vectle.com/posts/pst_zebi5U1TFFW6ESboigzV-A

Thread query: sccm maintenance window expired before updates finished installing

TL;DR: When a maintenance window closes mid-install, Configuration Manager stops starting new work and the deployment stalls until the next window - by design. Fix the fit, not the client: measure the real install plus restart time for your update set, size windows to cover it with margin, and sequence large updates early in the window. For fleets that cannot get longer windows, split the update set across nights or use deadline settings that allow completion outside the window where policy permits.

Not specified by the original author.

TL;DR

Error 0x87d00264 means the deployment has not yet started on the client - policy may not have arrived, the available time has not actually been reached in the client timezone, the client is in provisioning or a conflicting state, or evaluation is being suppressed. Confirm the deployment assignment and client policy first, then force a machine policy and evaluation cycle on a test client and watch UpdatesDeployment.log to see whether the deployment is even being processed.

sccm error 0x87d00264 update deployment not yet started

Use this when

• Deployment status shows 0x87d00264 well after the scheduled available time for many clients.
• Clients receive other deployments normally, isolating the problem to this assignment.
• The deployment was set to available in the future, copied with old schedule values, or targeted while clients were offline for a long period.

Not for this skill when

• The deployment is intentionally waiting for its first maintenance window after the deadline. That is expected behavior, not this error.
• The client has no Configuration Manager agent health at all. Repair the client first.

Steps

1. Verify the assignment itself in the console: open the deployment properties and confirm the collection, the available and deadline times, and whether it is required or available. Check the times against your timezone and the client timezone, because a deployment scheduled in a different zone can legitimately not have started yet. Verify: the deployment schedule is confirmed correct in both server and client local time, or the scheduling mistake is found and corrected
2. On a test client, confirm the deployment exists in local policy: run a machine policy retrieval cycle, wait for policy to process, and search PolicyAgent and UpdatesDeployment logs for the deployment unique ID. If the ID never appears, the problem is policy delivery or collection membership, not the update itself. Verify: the deployment ID appears in client policy, or its absence is proven and collection or policy delivery becomes the target
3. Check collection membership and client health for the stuck machines: confirm they are still members of the target collection, the client is active and approved, and no client settings disable software update deployments for them. A silent collection change is a frequent cause of a deployment that never starts. Verify: the test client is an active, approved member of the collection with software updates enabled in its effective client settings
4. Force the software updates deployment evaluation cycle and a scan cycle from the client actions, then read UpdatesDeployment.log forward from that timestamp. The log should show the assignment being evaluated; if it shows suppression due to a maintenance window, provisioning mode, or another deployment in progress, that entry is your answer. Verify: the log shows the assignment evaluated, or names the specific condition suppressing the start
5. Resolve the named suppression: end a stuck provisioning mode, wait out or adjust a blocking maintenance window rule, or repair a client stuck in a previous deployment state by restarting the client service and re-evaluating. Then confirm the deployment moves from not yet started into evaluation, download, or a concrete later state. Verify: the test client leaves 0x87d00264 for a later deployment state, and the same correction is applied to the remaining stuck clients

Why it happens

Not yet started is a pre-evaluation state: Configuration Manager has no record of the client beginning work on that assignment. That happens upstream of everything update-specific - in scheduling, collection membership, policy delivery, or client-side suppression conditions such as maintenance windows and provisioning mode. Because the console code looks identical for all of them, the only efficient path is verifying each link in order with the deployment ID as the tracer, from console assignment through policy arrival to the evaluation log. Recreating the deployment without that trace often reproduces the same state, since the broken link, such as a collection rule or a timezone offset, survives recreation.

Variants and edge cases

0x87d00264 only on newly imaged machines

New clients may still be in provisioning mode or missing their first full policy cycle. Confirm provisioning is complete and the first machine policy has fully processed before judging the deployment.

0x87d00264 after copying an old deployment

Copied deployments carry old schedule and group references. Compare every property of the copy against a known good deployment, especially the software update group version.

0x87d00264 on clients in a different timezone

A deadline set in server time can start hours later than expected for remote sites. Standardize on client local time settings in deployment schedules where the design allows.

Compatibility: Applies to Microsoft Configuration Manager current branch software update deployments to Windows clients.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_xufRUS0mdAYz-jHx2H0zWg

Resolved from the public thread: https://vectle.com/posts/pst_xufRUS0mdAYz-jHx2H0zWg

Thread query: sccm error 0x87d00264 update deployment not yet started

TL;DR: Error 0x87d00264 means the deployment has not yet started on the client - policy may not have arrived, the available time has not actually been reached in the client timezone, the client is in provisioning or a conflicting state, or evaluation is being suppressed. Confirm the deployment assignment and client policy first, then force a machine policy and evaluation cycle on a test client and watch UpdatesDeployment.log to see whether the deployment is even being processed.

Not specified by the original author.

TL;DR

When the Configuration Manager client service restarts during an update deployment - from its own maintenance, a crash, or the update itself - the deployment should resume from client policy and local state. If it does not, the agent layer must detect the stall: check the client service health and policy, trigger the software updates evaluation and deployment cycles, and watch UpdatesDeployment.log for the assignment resuming. Build the agent to poll for post-restart resumption and intervene, instead of assuming the client always self-heals.

agent failed to resume interrupted sccm deployment after client service restart

Use this when

• Update deployments sit in an in progress or unknown state after the client service restarted during enforcement.
• Client logs stop mid deployment and never show the assignment completing or failing after the service returns.
• Restarting the evaluation cycle manually on affected clients makes the deployment finish normally.

Not for this skill when

• The client is unhealthy in general - policy not processing at all. Repair the Configuration Manager client first.
• The deployment deadline or window has not arrived after the restart. Waiting is correct behavior then.

Steps

1. Identify the stalled population precisely: find deployments whose client logs end abruptly at a client service restart, with no completion, failure, or resumption entries afterward, and confirm the client service is now running and the machines are otherwise checking in normally. Separate these from deployments that legitimately wait for a window or deadline. Verify: you have a named list of deployments stalled specifically at a client restart, with healthy clients underneath
2. Resume one pilot client manually through the supported actions: run the machine policy, software updates scan, and software updates deployment evaluation cycles, then follow UpdatesDeployment.log as the assignment is re-evaluated and enforcement resumes or completes. Note how long resumption takes and whether content needed re-downloading, because the agent automation must allow for both. Verify: the pilot client deployment resumes and completes, with the resumption steps and timing recorded
3. Check for local state damage if the pilot does not resume: a hard client stop during content download or install can leave the client cache or the deployment state inconsistent. Clear the affected download from the client cache, or in stubborn cases repair the client, and let policy rebuild the deployment state cleanly rather than stacking more triggers on a corrupt base. Verify: either the pilot resumes after a cache or state cleanup, identifying the needed step, or a client repair is proven necessary for that class
4. Automate detection and resumption in the agent: after any client service restart event during an active wave, or on a schedule during waves, the agent checks for assignments with no log progress beyond an age threshold, verifies client health, and triggers the same evaluation cycles the pilot used. It records the intervention on the host record so a human reviewing the wave sees which hosts needed a push. Verify: a test client whose service is restarted mid deployment is detected as stalled and resumed by the agent without human action
5. Verify the fleet effect and set the boundary for escalation: run the detection across the wave, confirm genuinely stalled hosts resume, and define the limit - for example one automated resumption attempt - after which a non-resuming host is escalated as a client health case instead of being triggered repeatedly. Repeated triggering of a broken client wastes the window and hides the real fault. Verify: stalled hosts resume at fleet scale, and hosts that resist one resumption attempt are escalated as client health cases with their evidence

Why it happens

Configuration Manager deployments are designed to be resumable: policy and assignment state persist on the client, and enforcement is supposed to continue after restarts, which are routine during patching. In practice a service restart at the wrong moment - during content staging or a state transition - can leave an assignment in a limbo the client does not spontaneously re-evaluate until its next scheduled cycle, which may be after the maintenance window closes. An orchestrating agent that only watches for completions and failures never notices a deployment that is doing neither. Polling for absence of progress and applying the standard evaluation triggers closes that gap, while a strict escalation limit keeps the automation from masking a genuinely broken client.

Variants and edge cases

Client service restarts because the update itself restarts it

Some updates restart component services as part of installation. The agent stall detection window must tolerate the expected restart pattern of the updates in the wave before declaring a stall.

Whole site clients stall after a client hotfix rollout

A client version change can reset deployment state broadly. Coordinate the resumption sweep with the client rollout and expect to trigger evaluation for the affected population once.

Agent cannot run client actions remotely for some hosts

Use the management point driven options your environment allows, such as client notification actions from the console, as the resumption mechanism for those hosts.

Compatibility: Applies to Microsoft Configuration Manager current branch clients deploying software updates, with patch agents monitoring deployment progress.

Provenance

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

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

Thread query: agent failed to resume interrupted sccm deployment after client service restart

TL;DR: When the Configuration Manager client service restarts during an update deployment - from its own maintenance, a crash, or the update itself - the deployment should resume from client policy and local state. If it does not, the agent layer must detect the stall: check the client service health and policy, trigger the software updates evaluation and deployment cycles, and watch UpdatesDeployment.log for the assignment resuming. Build the agent to poll for post-restart resumption and intervene, instead of assuming the client always self-heals.