Maintenance windows are the main reason a required deployment in Configuration Manager (often still called SCCM) sits past its deadline and never installs. The client isn't broken: it's waiting for a window that is too short, of the wrong type, or never arrives. In this post I'll show how to see the windows exactly as the client sees them, find the rule that's blocking the deployment, and fix it without opening the floodgates.
Errors this guide fixes
No current or future service window exists to install software updatesMonitoring › Deployments (deployment status)0x87D00667Monitoring › Deployments (deployment status)No current service window available to run updates assignmentUpdatesDeployment.log+1 more guidewill be retried once the service window is availableUpdatesDeployment.log
Symptoms#
- A required application, package, task sequence or software update deployment passes its deadline, but nothing installs.
- Deployment status under Monitoring › Deployments reports
No current or future service window exists to install software updates; admins report the code0x87D00667with it, even for application deployments. UpdatesDeployment.logon the client keeps postponing the assignment:
No current service window available to run updates assignment with time required = 3600
This assignment ({GUID}) will be retried once the service window is available.- Software Center's Installation status tab shows the next maintenance window far in the future, or the deployment stays scheduled.
Why it happens#
Every maintenance window on every collection a device belongs to applies to that device, and Microsoft documents a few rules that decide whether a deployment may start:
- The run time must fit. A deployment runs only if its maximum allowed run time doesn't exceed the window's duration. If it can't run, the client tries again in the next window that has enough time.
- Separate windows don't add up. Overlapping windows merge into one long window, but windows that don't overlap stay independent, so two 60-minute windows never fit a 120-minute deployment.
- Type matters. A window applies to All deployments, Software updates or Task sequences. By default, when a device has a software update window, updates install only in that window and the client ignores its All deployments windows; the same applies to task sequence windows.
- Restarts are held too. Restarts caused by a deployment aren't allowed outside a window unless you allow them on the deployment.
- Time zones shift. With the UTC option, every device uses the same absolute time. Microsoft also documents that UTC windows calculate local time from the bias that was active on the window's effective date, so they can open an hour early or late after a daylight saving change.
Business hours that users set in Software Center are a separate mechanism: a required application that reaches its deadline during the user's non-business hours installs then.
How to fix it#
1. See the windows the client sees#
Don't guess from collection names: ask the client. The CCM_ServiceWindow class lists upcoming windows with their start, end, duration (in seconds) and type:
Get-CimInstance -Namespace root\ccm\ClientSDK -ClassName CCM_ServiceWindow |
Sort-Object StartTime | Select-Object StartTime, EndTime, Duration, Type| Type | Meaning |
|---|---|
| 1 | All deployments window |
| 2 | Program window |
| 3 | Reboot required window |
| 4 | Software updates window |
| 5 | Task sequences window |
| 6 | Non-working hours (Software Center business hours) |
No rows of types 1, 4 or 5 means the device has no maintenance window at all, so the cause lies elsewhere. A window of the right type that's shorter than the deployment's run time is your culprit.
2. Read the client logs around the deadline#
In C:\Windows\CCM\Logs, ServiceWindowManager.log records every check the client makes: the run time a deployment asked for, the window type it needs and whether a suitable window exists. Match its timestamps with UpdatesDeployment.log for software updates, or execmgr.log for packages and task sequences.
3. Compare run time with window length#
- Applications: the deployment type's Maximum allowed run time (minutes) on its User Experience tab; the default is 120 minutes, which already exceeds a one-hour window.
- Software updates: each update's maximum run time, shown in its properties. Feature updates and large cumulative updates need long windows.
- Task sequences: the maximum allowed run time in the task sequence properties.
Either lengthen the window (from five minutes up to 24 hours) or set a realistic run time. Don't shrink the run time below what the install really needs just to make it fit: the client uses it to decide whether the job fits, so an underestimate lets long installs run past the end of the window.
4. Fix type conflicts#
Open the collection properties (Assets and Compliance › Device Collections › Properties › Maintenance Windows) for every collection the device is in, and check the Apply this schedule to value. If a short software updates window hides a long All deployments window, either lengthen the software updates window or enable the client setting Enable installation of software updates in "All deployments" maintenance window when "Software Update" maintenance window is available in the Software updates group. You can also review windows in PowerShell from a console session:
Get-CMMaintenanceWindow -CollectionName 'Servers - Patch Group A' |
Select-Object Name, Description, IsEnabled, IsGMT5. Allow urgent work outside the window#
For a zero-day update or a critical application, use the deployment's deadline behavior options on its User Experience page to allow software installation, and if needed the system restart, outside the maintenance window. Use a separate, tightly scoped deployment for this so routine patching keeps respecting the windows.
6. Re-check UTC windows after daylight saving changes#
If a UTC window suddenly opens an hour early or late, the effective-date bias described above is the likely reason. Where windows must follow local business time, clear the UTC option so each device uses its own time zone, and review UTC windows after each daylight saving change.
Verify the fix#
- Run Machine Policy Retrieval & Evaluation Cycle on a test device, then query
CCM_ServiceWindowagain: the window has the type and duration you expect. - Software Center's Installation status tab shows the correct next maintenance window.
- When the window opens,
ServiceWindowManager.logfinds a suitable window and the install starts (UpdatesDeployment.log,AppEnforce.logorexecmgr.log). - Deployment status moves from the service-window error to success or compliant.
Prevent it next time#
- Size windows for the slowest item plus its restart, not for the average.
- Keep one window type per purpose and document which collections carry windows; overlapping memberships surprise people.
- Since version 2207, monthly windows can be offset from Patch Tuesday (for example two days after the second Tuesday); the last-week-of-month scheduling issue was fixed in 2503.
- You can't add maintenance windows to the All Systems collection, so set them on purpose-built collections.
- Pair windows with ring-based patching: see automatic deployment rules for Patch Tuesday and, for scan or install errors, updates not installing from Configuration Manager.
