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.