Generally though our Windows servers are patched on a monthly / every other month schedule so anything from 30 to 60 days between restarts is about right for us.

As someone has said, it shouldn’t be the total amount of up time you’re looking at but the amount of *unscheduled* down time over a period (week / month / year / decade). I’m very much in this group and would happily reboot my Windows machines on a weekly basis if it helped with service uptime etc.

Of course you’ve also got suck fun things as *nix and BSD machines or even switches to think about. I’ve got switches that haven’t had a moment of unscheduled downtime for years but have been off twice in the last six months due to power maintenance in the building over a long weekend (no point running the ups all weekend just for them).
*nix machines are also interesting in that regard as without exception all of mine simply sit there and get on with their job. After a major office migration I’ve yet to turn some of them off even through their patching schedule.

I suppose that’s something else to think about – the impact of patching on an infrastructure’s availability.

I’m always amazed that major institutions like banks and Microsoft have so much “planned downtime” for certain services. Why should my bank’s website be down, ever? They make billions of dollars. They can’t afford the systems necessary for service availability through patches or is there more complexity involved that I’m not aware of? Hmmm.

Colour me paranoid, but even with a server that is ostensibly locked away from the world, I don’t trust them to be safe. If there is an exploit available for the box, I want it patched and safe. You should never, ever, rely on other bits of security just for the sake of a kernel patch and reboot.
Several years ago I was working for a large ISP / Hosting company. For one of our main web clusters the servers were locked away from the world nicely hidden behind firewalls and load balancers. Taking advantage of a 0 day exploits, a hacker got on through an XSS attack, exploited up to root and started trashing the system. Luckily quirks of the platform squashed them and their actions within about 5 minutes. Enough time to do some damage, but not irreparably so. If we’d unintentionally got another box they could have accessed from there, they could possibly have exploited that, and so on. It just doesn’t pay to run un-patched machines.

If you can’t reboot a server at any time without disrupting service, you’ve got work that needs done to mitigate that problem. It shouldn’t even be necessary to post a maintenance window notice (though you always should). Ideally no one should ever notice a server has been or is being rebooted.

tcsh-[110]% uptime
8:18am up 8125 day(s), 12:19, 2 users, load average: 0.00, 0.00, 0.00

Fully patched, and current, too. :)

Yes, I usually have a change log page for each server in my wiki, but once in a while I get lazy.

Famous last words, I know.

In FreeBSD-land we’ve had several kernel-land locally exploitable privilege-escalation issues in the last 8 years (to say nothing about the panic()-inducing DoS-type bugs that have been fixed). Not making sure your systems are up to date with those patches (which can’t be applied without rebooting) is pretty much gross negligence in my book.

All that being said I feel any machine with an uptime over one year should only be rebooted with the most extreme caution: As mentioned a few times above you never know what config changes have been made which will bite you on reboot. (My favorite example was a machine that got renumbered: The admin changed the running IP configuration (via ifconfig), but not the startup configuration files. On reboot the machine reverted to its old IPs. Hilarity (insanity) ensued.)