Maintenance Windows are a nice feature in Microsoft System Center 2007 Configuration Manager (ConfigMgr) and beyond (hopefully you are beyond by now). Maintenance Windows are however often misunderstood by those new to ConfigMgr as well as experienced ConfigMgr admins. Here’s my overview of Maintenance Windows and what every admin needs to know when implementing or using them.
What Maintenance Windows “are” or “do”:
- Maintenance Windows are enforced on the client by the client agent.
- Maintenance Windows, like just about everything else that the client agent knows about and does, are delivered via the machine policy.
- There are three Maintenance Window types; each prevents the type of deployments specified:
1. All Deployments
2. Software Updates
3. Task Sequences
- Maintenance Windows prevent deployments from being enforced by the client outside of the time period(s) defined; e.g, if a Maintenance Window defines 1PM to 5PM, then deployments are prevented at all other times (and are effectively only allowed between 1Pm and 5PM).
- Maintenance Windows prevent enforcement of every deployment (of the same type as the Maintenance Window type) targeted to the clients within the collection where the Maintenance Window is set; i.e., the collection that a deployment is targeted to makes no difference and not considered by the client when enforcing Maintenance Window restrictions.
- Maintenance Windows are applicable to client auto-upgrade in addition to deployments.
What Maintenance Windows “are not” and “do not do”:
- Maintenance Windows are not Business Hours and Business Hours are not Maintenance Windows. For a detailed look at this, see the great article that Dave Randall wrote: Business Hours vs. Maintenance Windows with System Center 2012 Configuration Manager. My characterization of the difference between the two is summed up in the following table:
| Type | Who Sets | What It Applies To | When it Applies |
|---|---|---|---|
| Maintenance Window | ConfigMgr Admin | Required Deployments | After the deadline is reached |
| Business Hours | End User | Required Deployments | Before the deadline is reached |
- Maintenance Windows do not ever cause any sort of activity or action. They do not cause deployments to be enforced, systems to reboot, or any other or thing that you can think of that the client agent does.
- Maintenance Windows are not restricted to deployments targeted to the collection that the Maintenance Window is set on.
Additional Notes on Maintenance Windows
- Clients don’t know anything about the collections that they are members of or the collections that deployments are targeted at. This is part of the reason why Maintenance Windows apply to every deployment targeted to a client: clients simply don’t know anything about collections.
- Having no Maintenance Windows on a client means deployments are never prevented. Note that this is why I chose to characterize Maintenance Windows as preventing deployments instead of allowing them.
- In addition to start or open times, Maintenance Windows also have end or close times. The implication of this is that if a deployment’s maximum run time doesn’t fit within the period defined by a Maintenance Window, then the agent won’t try to enforce that deployment. The maximum run time of a deployment is defined by the maximum run time time on the User Experience tab of a Deployment Type, the Requirements tab of a Program, or the Maximum Run Time tab of a Software Update. Because a Software Update deployment can define multiple software updates, Maintenance Window evaluation for them is a bit more complicated though. This is detailed in the post Maintenance Window Calculations Explained.
- Maintenance Windows are stored as objects of the CCM_ServiceWindow client side WMI class. Note that Business Hours are also stored as objects of this type; however, they have different values in the Type attribute.
- Multiple Maintenance Windows applied to a client are simply combined together. They in no way cancel each other out.
- If a client system is never powered on during an applicable (based on deployment and Maintenance Window type) maintenance window, it won’t ever enforce any deployments. For this reason, Maintenance Windows on client OSes are often best avoided.
- Client logging of Maintenance Window evaluation is in the log named ServiceWindowManager.log although messages about Maintenance Windows will appear in other deployment related logs.
- Another way to describe Maintenance Windows is that they define open and closed periods of time. Open times are those within any applicable Maintenance Window and closed times are those not within any applicable Maintenance Window. When a deployment reaches its deadline, if the system is not within an open period, it cannot enforce the deployment and queues it for later enforcement at the start of the next available open period for that deployment type. Only the deployment is truly triggering the action.
Very good article, thanks for posting.
I have a maintenance window for all my client machines that starts at 2100 and ends at 0300 the following morning.
My ADR Evaluation runs after the software sync at 0700 on a Wednesday morning.
I make the Software Available time 12 hours later and my Installation Deadline ASAP.
Am i correct in saying that the deadline will not circumvent the maintenance window and will only attempt to install after 2100?
Deadlines don’t circumvent maintenance windows in any way. Deadlines are the time when the agent considers an update (or whatever is deployed by the deployment) to be mandatory and will schedule its installation or enforcement. If any maintenance windows exist for the system, then the agent will schedule the installation for the next available maintenance window.
I think this article needs to be updated as for now a few things have changed in 1810
– The “Software Update” Maintenance Windows is (By default) excluded from the “All Deployement” windows and therefore won’t merge with it.
– If there is no SU MW, then the All Deployement MW will be used (presumed)
The behavior can be changed in Client Settings under the Software Update tab to include SU MW in All Dep MW.
https://docs.microsoft.com/en-us/sccm/core/plan-design/changes/whats-new-in-version-1810#improvement-to-maintenance-windows-for-software-updates
You are correct that there are changes, but only if the client setting is enabled for clients. your points though are a bit confusing and I don’t think accurate. The option simply enables the use of “All Deployment” maintenance windows in the absence of “Software Update” maintenance windows.
Hi Jason,
could you clarify the case in which both WIndows Active hours and Software Center Business hours are set? Let’s say that I have enforced Active hours via Group Policy from 8am to 6pm and the customer set 7am to 7pm. When an update requires installation, when this will be done?
Thank you.
ConfigMgr doesn’t use Windows Active Hours and Business Hours are never used for anything automatically initiated by the client agent (more or less). So the answer to the question is after the restart delay configured in client settings for that system or immediately if no one is logged in (and assuming reboots aren’t suppressed on the deployment).