Reboot Strategy

Given the importance of reboots and the pain that our users often feel when computers must be rebooted, every organization should have a reboot strategy. Hopefully we can minimize the pain in some ways, but at least some predictability will allow the users to know what to expect. As administrators, we can be sure we’re optimally accomplishing what we need to cater to both the needs of the business and those of the end user.

A 2015 independent survey of 100 organizations, 65% did have a reboot strategy. 66% reboot as needed, and 70% of those that forced reboots, forced them within a day of installing patches.

In addition to having such policies, you should define when you will force reboots:

  • To mitigate zero-day vulnerabilities?
  • For critical or more serious updates?
  • Every Saturday, just in case?

As you define your reboot strategy, you should review the technologies involved in your rebooting. Microsoft Windows, the applications running on your computers, your hardware, and possibly System Center Configuration Manager and third party tools can be relevant. Each have options that could be better used or configured. Our “Improve Security by Optimizing Your Reboot Strategy” whitepaper helps you to identify and understand your options.

Similarly, you should define the relevant stakeholders, such as your security team, end-user experience team, and management. Involve them in the process so that all points of view are represented.

Your strategy might include a user education campaign. If users understand why reboots are needed, their significance for the organization’s security, and begin to perceive better service as a result, they should be more cooperative.

You can leave at least some reboots to end-user discretion but that can be a challenge to security in two ways:

  1. Your computers remain vulnerable to security attacks until the reboots occur
  2. You cannot verify success of a security change (such as an update deployment) until a large fraction of your users have rebooted their computers

There is a lot to consider in developing or refining your reboot strategy. Our whitepaper helps.

Optimize Reboots, Improve Security Learn More About NightWatchman

Paul Thomsen
Paul Thomsen has been a Product Manager at 1E since August 2014. Current responsibilities include NightWatchman product management and special projects. That followed two and a half years at the company as a Solutions Engineer working directly with many organizations of all sizes. Prior to that Paul worked at Microsoft for 12 years, eight of which were as a senior ConfigMgr Engineer for the teams serving Microsoft IT (300,000 clients) and others. That included “dogfooding” many versions of ConfigMgr. For his first few years at Microsoft, Paul was a technical writer on the ConfigMgr (SCCM) product team. His career has been primarily IT-focused but has included several years as an application developer. Paul has been active in the ConfigMgr community for over 15 years, including presenting at many conferences, blogging at, writing the SMS column for BackOffice magazine for three years, and contributing to several SMS/ConfigMgr books.