In the partner SBSC newsgroup, one of the guys asked if it was normal for a SBS server to be rebooted nightly. He didn’t think so, but the consultant that came before him had set up a nightly reboot . (Needless to say it was causing issues with Exchange complaining about not be shut down properly).
He said that coming from an Enterprise background that he was NOT used to rebooting servers nightly and in fact the Enterprise servers he was used to many times went months without rebooting.
First off the general rule of thumb for ANY server, whether Enterprise or Small Business is that they really and truly only need to be rebooted if a Security patch demands it. In a SBS network, due to the fact that we have a fair number of applications on our server, the chances are good that every second Tuesday of every month (that’s Patch Tuesday) there will be at least one patch offered to a SBS box that needs a reboot. If a patch needs to reboot, you need to reboot. The reason for this is that dlls in use may not be updated until a reboot is complete, so you may not be fully protected if you merely install the update and don’t reboot. Also a mismatch of dlls may leave the server to do weird things (event logs wackoness) that doesn’t clear up until a reboot.
Rule one: if the patch wants a reboot, reboot the server.
That doesn’t mean necessarily you HAVE to reboot if you don’t apply the patch in question. Case in point, I have not updated my server for the post sp2, kill off RSS/TOE Advanced networking crud of SP2 because I already followed the guidance in www.sbsbpa.com and shut it off in the registry. That patch demands a reboot. Since I don’t NEED to install that patch, since it’s not a SECURITY patch, I’m now with a two month uptime because I didn’t install any patches in March on the server that demanded a reboot. Then I also decide WHEN to patch. My goal, my job is to buy time. If I’m having to run to the server at noon on Patch Tuesday screaming “Patch now, we’re rebooting the server because we’re sooo at risk we’re screwed”, I haven’t done my job of risk management. All patches ultimately get installed. I just determine the best time to install them.
Rule two: Just because a patch is offered, doesn’t mean you HAVE to install it right then and there.
If your prior consultant is staging a nightly reboot of the server, go fire that consultant. He or she is probably doing that for several reasons:
There’s a sucky line of business application on that server sucking up memory and the App developer, nor the consultant hasn’t a clue how to tune memory to work on a server.
There’s a SQL instance on that box sucking up all memory and the consultant hasn’t googled for “Allocated memory alert
” and hit my umpteen blog posts on how to fix this.
He or she sees how Exchange uses up all free memory and doesn’t realize that it releases it to other apps when needed.
Rule three: There is no reason that makes any logical sense to reboot a box nightly.
Let me restate that for the folks in the back of the blogosphere reading all of those dumb April fools jokes today:
There is no reason to reboot a box nightly. If your consultant is saying this is a best practice he or she does, that is one of the worst best practices in my book, short of running the server with no firewall and all ports open. If they are doing this they are probably doing so to mask a problem that they haven’t fixed. If they are doing this because it fixes something else, go fix the something else first.
Rule four: Fix the real issue, don’t use rebooting as a bandaid.
We sometimes have a problem where servers don’t reboot AFTER a patch as the Remote Desktop Protocol doesn’t come back as it should (see Handy Andy’s blog for his recent discussion on this issue). Thus to stage a nightly reboot like this is putting a lot of risk of loss of access to that server. It’s not normal for servers to BSOD (blue screen of death), it’s normally a driver issue, it’s not normal for servers to demand a reboot each night, and while it’s not normal to lose Remote Desktop access to the server, it can happen to be prepared.
Rule five: Rebooting may impact remote access, if you plan for an alternative strategy to get that server back to full remote access, you will save yourself a lot of unplanned trips to the office.