Best practices for restarting DNS servers.

Tags:
DHCP
DNS
Microsoft Windows
Networking services
Because of personnel changes, I find myself temporarily managing a couple of racks of Windows servers. They run Exchange, SQL, DNS, and so forth. Can anyone direct me to a source of information on how often a given server should be rebooted? I know that the vendors always say never, but reality is usually something different. Thanks, Clark

Answer Wiki

Thanks. We'll let you know when a new response is added.

The general rule is “Only when necessary”.

One of the key debates around the stability of Windows vs. *nix platforms derives from the fact that Windows systems started as desktop machines – and as such were subject to many changes, viruses, etc. so that they NEEDED periodic rebooting.

Much as I favor *nix for servers, the fact is that a properly configured Windows server can run for months or longer without needing a reboot.

The only time they are likely to NEED rebooting would be after applying patches that are part of the boot configuration.

Bob

Discuss This Question: 6  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • DrillO
    I agree 100% with Bob....generally a WIN machine will tell you when it needs rebooting. One thing though, try to do it when it impacts your users the least. Trust me on that one. Aside from some maintenance issues that Bob mentioned, (patches etc.)I have never rebooted my WIN servers. Watch the patch and update schedule though. Best, Paul
    15 pointsBadges:
    report
  • HumbleNetAdmin
    I agree with Bob and Paul regarding windows servers can run for months without the need to reboot, and should be able to. I have heard tells of WIN servers running for more than a year without restarts (Kind of silly and risky with the number of patches and fixes that are forever needed to be applied). However this is usually not the case and WIN servers will only give you this kind of uptime in a near perfect environment. Generally when windows server needs rebooting due to a problem, some aspect of that server serving a business need will have failed and that is why the need to reboot has come to your attention. The environment that a server is in and the role it plays will more often then not dictate how often it produces a need to be rebooted. IE.. a webserver that is just there, and is hardly ever updated may run for months. On the other hand, if the web pages are updated frequently, has heavy traffic (and depending on the type of web applications it is running) all add into the mix to increase the possibility that something will not play fairly and cause the need to reboot to occur. There are numerous reasons that can crop up that might cause a desire or need to reboot. I have 17 servers in my arsenal that I manage. All of these servers run a variety of applications and processes. 4 webservers (two that actively serve webpages to the world) the others are standbys with one that serves as a kind of intranet and our remote tech support software. One of the live webservers was rebooted this morning, not that it was not server the role that it was intended to, but because the activity of client connections was not showing up in the status of components of Component Services. I have two domain controllers, one is a 2000 server and the other is a 2003 server. The 2000 server is just a domain controller and file server. The 2003 Domain controller is unfortunately a Exchange server, SQL server and the parent backup server. The 2000 DC has been running for months without a reboot since the last scheduled maintenance reboot. The 2003 DC needed reboot yester because the management console for the backup software suddenly decided to cooperate and refused to start and I could not manage the backups. I have three win2k3 servers that are terminal servers, they pretty much run with out the need for reboots, except that on occasion errors had popped that had to be resolved. I have three NAS servers running Win2k3 Storage Addition, never need rebooting. I have two BIND DNS servers on SuSE Linux boxes. Never need rebooting with the exception that once with the Parent DNS server, it suddenly decided to not send updates to our ISP?s DNS server that is hosting our DNS. I have two other Linux servers. One is going to be a data base server connected to a DAS RAID array and has not needed a reboot in months since its install (although it is not doing much at the moment). The other Linux server is being used as NAS server for archiving and has once caused a problem when attempting to restore data from tapes to it, it just suddenly decided not to be accessed in any way. When on the console you got a black screen and would not respond to any form of remote communication. I have two SNAP servers that never need rebooting and have been running now for maybe six months. With all that said. There is no recommended rebooting schedule for windows servers that I am aware except for the one you create. Which I recommend that you do, the General Rule of only rebooting when necessary may be true, however will not apply in every shop and the necessary part should fall into periodically scheduled maintenance reboots. Better to control your down time on a server beat you can then having it control you. I do schedule all servers for regular scheduled maintenance reboots,. I try to do this every other month. Some servers will get rebooted the next coming 3rd Monday of the month and then the rest the following. The exception is the Linux server that is a database server and (the server that I did not mention) is the Solaris Database server that the Linux is replacing. During these scheduled maintenance periods, I patch part of the servers and reboot them and then reboot other servers that are not getting the patches. They will get the patches next maintenance. I don?t patch all servers at once. For instance, since my terminal servers and web server traffic is loaded balanced, I can take one or two servers offline switching its traffic to another server, and then patching/rebooting the server I took offline in the load balancer. The following month I get the one I skipped if the patched server does not show a dislike for the patch. Also in my scheduled maintenance reboot is that of switches, routers and firewalls. I have duel redundant firewalls and load balancers. So I shutdown the live device and allow it to failover to the secondary. I have two routers, one hot and a cold spare. I switch them out every month. My switches get a reboot every month. I have found that on occasion a switch, after having been in service for many moons (like a year) may need a reboot. Rebooting on a scheduled maintenance plan is just good preventive maintenance. If a server is up and running for months on end with out being shutdown or restarted problems could develop that you are not aware of. One such problem that I had; was a server that had been up sometime without failure. I took it down after performing a patch on it and discovered that it had a bad hard dirve. The SCSI hard drive was fine until it spun down and then did not have the guts to spin it self backup any longer. Your environment may not be like mine where it is easy to schedule down time for scheduled server reboots. My network is ?an absolutely has to be available 24x7? operation. So I have redundancy built in were ever I can. Fortunately that also allows for flexibility in scheduling maintenance, and often allows me to detect problems on a server (that has been removed from a critical need role temporarily for maintenance) before the problem turns into a catastrophic failure causing unplanned down time and loss of services to our clients Excuse the long rant and hope it helps The HumbleNetAdmin
    0 pointsBadges:
    report
  • Amigus
    I'll throw in my $0.02 and say that I agree with everyone else. Unless you need to reboot, don't. Generally the only time I reboot computers is when patches are installed that require it. I said computers instead of servers because I in fact hold the same assertion for workstations and commonly have uptimes of over 30 days on both.
    0 pointsBadges:
    report
  • Sonyfreek
    I only reboot both Windows and *nix servers when necessary (patches require it or there's an abnormality on the system that cannot be solved in any other way). The software typically does well, but the hardware is typically the problem when it's been constantly running. I've relocated servers that were running for years on end without being shut off and after it's cooled off during the move, it's not coming back due to a power supply or other hardware failure. I'm no expert on it, but the hardware seems to fail from something like the solder cooling or blows out when you reapply power to it. The best solution to that is to keep spare parts around or keep the systems under some type of warrantee.
    0 pointsBadges:
    report
  • Johncduffy
    Hi i'll put in my two bobs worth. In all my years working in manufacturing and talking to hardware vendors it is my opinion that servers should be taken as always on. I don't agree with scheduled reboots, only reboot as a few have said when patches or fixes require it. The only time we reboot other than that is when Backup exec management console freezes. A well configured server (we use win2003) could have an uptime of at least 5-8 months.
    0 pointsBadges:
    report
  • ClarkSysCoord
    Thanks for all of the replies. I figured I would get most of the "don't unless you need to" response, and that is my preference. However, I thought it was funny that the responses I got from Microsoft and Dell on a couple of quirky issues (quirky to me anyway) were the basic "so when did you reboot last" variety.
    0 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following