Except that it is not really a question for many of us. We either do because that’s what we’ve always done and it’s worked out okay so far, or we don’t because the very idea is an affront to our technical sensibilities. Odds are the audience is going to split about evenly on this, so let’s see. Quick show of hands please. How many of you still schedule reboots of your Windows servers? 10, 20, 100, 2947, oops, sorry missed you there in the red shirt. 2948 of you? Wow, that’s a lot of rebooting going on. So, why? Why are you doing that? Is it because it’s just the way it’s always been and therefore now it’s just SOP? Or is there a real reason for it? In today’s post I want to talk about why it hasn’t been a good idea to reboot servers on a regular basis in years/versions, and if you’re still doing it, why you should stop. And if there’s something else really going on that makes this a necessity, what you can do to try to help with that.

For your consideration

Search your favourite search engine on how to reboot a Windows server automatically and you will find millions of hits. Search for why, and while you will get a lot of hits, you won’t get any real results unless they date from the late 90’s to early 2000’s. Try to find anything from Microsoft on reasons to regularly reboot servers. If you do, please leave a comment below, because I searched extensively and never found anything other than some old community posts with entries NOT from Microsoft themselves.

Why do we reboot?

Once, a very long time ago, operating systems were 32 bit, with lots of bugs and buggy processes, and there were frequent things that could crash, chew up limited resources without spitting them back out, and otherwise just kind of hang without any clear indication of what went wrong. While hung processes are still a thing, and rebooting is the “simple” way to clear them out, the only real problem tended to be with non-paged pool memory (NPP) on 32bit operating systems. In 32bit versions of Windows, NPP was limited to X and could become exhausted by any number of causes, including accessing PSTs on network shares and bad hardware drivers. In a 32bit system, NPP is limited to the greater of 75% of physical memory, or 2GB, and when it’s gone, it’s gone. Rebooting was the only way to get that back, and in a time when drivers were not always so well written, and both user and application actions could chew up NPP, reboots became a necessary evil. I mean, seriously, try rewriting a bad driver, let alone getting a user to give up putting PSTs in their H: drive!

When do we really have to reboot?

In 64bit Windows, there is still the 75% high water mark, but the maximum that can be allocated is 128GB, if you have that much which is possible in today’s hardware, but even with less, 75% is likely to still be much higher than 2GB. Add to that a couple of changes in user behaviour (they don’t need PSTs if they have larger mailboxes, and hopefully you’ve learned to block them) and that 64bit drivers are generally much better written and the operating systems are much better at blocking poorly behaving apps from overconsuming resources, so these problems are largely gone. So when do we really have to reboot?

  1. When you install a patch or update that requires you to reboot.
  2. When you add a feature that requires you to reboot.

What can we do instead?

To avoid scheduling regular reboots, there are several things you can do instead.

  1. Realize that this is a behaviour that is not required or recommended
  2. Use 64bit versions of the operating system on all servers
  3. Keep things patched and up to date*
  4. Use only signed drivers and hardware on the Windows Hardware Compatibility List. Seriously, you have to go pretty far out of your way to not do that these days, as even the discount hardware you might use to build a generic server probably has good drivers and is on the HCL.

*One can certainly argue that if you patch on a regular basis, then you are rebooting at least once a month. That’s true, and totally worth doing, but you’re not rebooting because you want/need/believe you should reboot just to reboot, you’re applying updates. Any little bits of flotsam and jetsam floating around in memory will get cleaned out that way, so #winning for all.

At the end of the day, if you’re still scheduling regular reboots of your Windows servers, ask yourself why. Go further, and take a look at available resources on that server a few minutes before the scheduled reboot, and then look at the same resources after the reboot is complete, and see what difference it made. My bet is the differences will be so insignificant as to convince you this is an old practice that can go the same route as backing up autoexec.bat and config.sys.

But maybe not. If you are still rebooting regularly and have a good reason for it, please leave a comment below and let us know. Worst case scenario, you school me on something I need to know. Best case, someone else might read what you’re doing and offer a fix!






Searching test? Learn about storytelling podcasts. Short fiction for you.

Get your free 30-day GFI LanGuard trial

Get immediate results. Identify where you’re vulnerable with your first scan on your first day of a 30-day trial. Take the necessary steps to fix all issues.