This is the first in a series of blog posts that are focused on best practice tips in an effort to encourage IT professionals to use best practices in their system design and configuration where ever possible.
This best practice tip is focused on:
Configuration Manager Maintenance Windows
Maintenance windows are incredibly useful and allow ConfigMgr administrators to protect the business from software deployments and system restarts occurring during business hours. While this protection exists at a certain level because we can design our deployments to occur outside of business hours, due to the nature of how deadlines work, we can’t always guarantee with ConfigMgr that a system will be able to execute the deployment at the specified time. In this instance a system will execute the deployment the next time it comes on-line.
Maintenance windows offer that additional level of protection to both the business and the administrator (because no administrator wants to be responsible for causing environment wide restarts of servers or desktops)
For Example:
This is only applicable to deployments that have not been configured to ignore maintenance windows
If maintenance windows overlap then they form a single larger maintenance window, if they do not overlap the device effectively has two maintenance windows.
Because maintenance windows stack cumulatively, it is a best practice recommendation to use dedicated collections for your maintenance windows and only apply maintenance windows to these collections. By doing so ConfigMgr administrators can accurately and predictably track what devices have what maintenance windows applied.
Example of a recommended maintenance window collection structure
It’s generally good practice to have a recurring maintenance window for all devices, the schedule for these recurring windows will likely differ for different types of clients. By having a recurring maintenance window you have a predictable and scheduled time where deployments will execute on clients. This provides security to the business and sets expectations for when software maintenance will occur.
Nice tips
But how to use it after for a deployment software ?
Can you give us an exemple ?
Thx