Conventional wisdom would have it that a Windows system needs to be rebooted every time you play a tough game, every time the kids hit a new Web site, and every time Law and Order is on the tube. Its really an exaggerated reputation.
I know of Windows servers, especially Windows 2000 servers, that have been up for months and even years. When you have a server that performs a small number of tasks and you dont mess with it—for example, foregoing installations of random shareware—its not unreasonable to think it will go on forever. Most of the long-running servers I hear about are backup domain controllers (BDCs in NT-speak) or print servers or simple file servers. At the same time, I know of an Internet cafe that uses an Windows NT4 server as the main domain controller, print server and file server—and the thing never goes down.
Of course, one of the most common reasons to have to reboot a Windows system is to install a security patch. So if you find a Windows system that has been up and running for years, you have to wonder how many gaping, famous, unpatched security holes are sitting there on the system.
I was especially surprised to see in the latest news from Netcraft that the Baltimore Technologies Web site has been up working without a reboot for more than two years now, making it the Cal Ripkin of Windows 2000 Web servers.
Baltimore Technologies is a security company, long a player in the enterprise public key infrastructure (PKI) business. One would think that a security company would be conscious enough of security issues that they would apply patch every now and then.
Not only does it appear that Baltimore Technologies hasnt applied these patches—because quite a few of them do require reboots—but it appears that they have gotten away with it. As the Netcraft article says, in two years even a not-so-famous company like this would have had a serious amount of traffic on their Web site. And theyre still running. I suppose its possible that the site was hacked and Baltimore doesnt know it, but thats very doubtful.
When I asked Netcraft about it, I think they shared my sense of incredulity at the situation. Still, they pointed out that not every function of Windows and IIS is open to attack. If a server did not use any of the usually affected technologies, for example by offering WebDAV services or running SQL Server or leaving Port 35 open to the Internet, theres no really critical problem that a 2-year old version of Windows 2000 Server would be subject to attack. Baltimores site appears to be a testament to Microsofts work to remove memory leaks from the basic Windows kernel and IIS.
Baltimore Technologies agreed, according to the Netcraft article. "The Web sites reliability is enabled by a stable power source, good physical security, a webmaster who cooperates with the networks team and a proper screening firewall, said Keith OByrne, a network engineer with Baltimore Technologies." So its not just Windows 2000, but the good work of Baltimore staff thats responsible.
Stories like this make you wonder. Is it worth applying security patches as a matter of course, or better to scrutinize the patch to make sure that its relevant to a function youre actually running? Both approaches could be called "conservative," because examining patches follows the "dont fix it if it aint broke" maxim. But my own preference is "better safe than sorry," also a conservative track.
Yet a better question to ask would be: "Who cares about uptime, per se"?
As long as the server isnt being rebooted because of a memory leak or because some malfunctioning app refuses to quit, its just a minor hassle. Most sites can afford to be down, or serve content from external caches, for the few minutes it takes to reboot. Besides, if a site is so busy that it cant afford such downtime, it probably needs some redundancy anyway.
So its best to skip Baltimore Technologies as an example of usual practice. For most of us, running a 2 year old Windows isnt worth the risk.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
More from Larry Seltzer