Our main RIS server is a Windows 2000 box running on ESX. Since we deployed ESX, we have experienced far less downtime. This is attributed to multiple things, two being new, quality server hardware, and snapshots, so we can undo a risky change safely and quickly.

Interestingly enough, sometimes when things run too good, it is a bad thing. That reminds me of a situation I had many years ago, as an entry tech. I was tasked with changing a simple network setting in a company’s main server, however with NT4, it required a restart. This was acceptable, a quick 5 minute outage was planned. The trouble is, once the system rebooted, there was not networking at all. Being new, it took me a good (andhighly tense) 10-15 minutes to determine my config change was not at fault…that the network card simply had died. It turns out, this was the first reboot of the server in 3 or 4 years… and the NIC apparently was ready to fail upon the next power cycle. A new NIC was acquired, and a 5 minute “coffee break” turned into an hour outage.

A similar situation just presented itself on our RIS box. It had ran for a good 6 months without a reboot… humming away. ESX, as good as it is, still cannot manage disk space superbly on the fly, so we had to take the server offline to do some storage adjustments. Upon starting up, it acted very strangely… not showing the Disk Manager to the user, amongst other things (which is rather frightening immediately after doing storage maintanence). Other symptoms were that it was slow to boot, and the Server service (and dependancies Computer Browser and Distributed File System) would fail to start.

It turned out to be a very simple issue… we were able to determine that the Print Spooler service was causing issues with those other services, and that we could no longer view printers from the control panel (even with the Spooler service started and restarted). About 6 months ago, a tech had changed the 10 or so printers to keep printed documents. Well this server handles our label printing, so in those 6 months, over 300,000 print jobs were handled. All of these files hanging around inside the SPOOL folder were the root cause of the issue. Cleaning them up returned everything to normal.

Lucky for us, the system was able to run fine, it was simply the reboot that highlighted the growing problem. I know that people like to brag that their servers run for years rock solid without a reboot, and it is true that rebooting stresses the electrical components of a computer, but I am a firm believer in running scheduled reboots periodically (and monitoring the results). I would rather a problem surface during a maintenance window rather than during peak hours, when staff is away on vacation, as a result of a unexpected reboot or similar situation.

Bookmark to: