Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

If you were running a 24/7 website on Windows Server 2003 (IIS6). Would you leave the Windows automatic update feature enabled or would you turn it off?

When enabled, you always get the latest security patches and bug fixes automatically as soon as they're available, which is the most secure choice. However, the machine will sometimes get automatically rebooted to apply the updates leading to a couple of minutes of downtime in the middle of the night. Also, I've seen rare occasions where the machine does not restart correctly resulting in further downtime.

If auto updates are off, when do you apply the patches? I guess you have to use a load balancer with multiple web servers and rotate them out of the production site, apply patches manually, and put them back in. This can be logistically inconvenient when the load balancer is managed by a hosting company. You will also have machines in production that don't always have the latest security patches and you have to routinely spend time deciding which patches to apply and when.

share|improve this question
add comment

migrated from stackoverflow.com Apr 17 '10 at 11:14

This question came from our site for professional and enthusiast programmers.

11 Answers

Short answer, no.

In a best case scenario, you should at least have another box/vm/guinea pig to test the patch to make sure it doesn't destroy your world.

In worst case, I would let it download the patches but not install, so I can review what's getting installed. But I'm just a control freak that way.

share|improve this answer
    
Worth noting that it's probably a really good idea not to install them, as it can cause your web server to spontaneously reboot, which is probably a bad thing from the point of view of people visiting your site. –  Kibbee Feb 25 '09 at 15:04
    
Not to automatically install them that is. Best to have (at least) 2 machines and bring them down in a controlled fashion, one at a time, so as not to disturb the users. –  Kibbee Feb 25 '09 at 15:04
add comment

For a production Windows server I would not recommend setting Windows Update to download and install updates automatically. A better approach is to download updates automatically but manually install them.

The benefits of this approach are:

  1. You can review the proposed updates prior to installation and where necessary, research the implications of installing the update. This may seem like more work - it is! but at least you will be in control. Microsoft also offers a free mailing list that gives you early notification of the type of updates to be released in the next batch of Windows Updates.
  2. You can decide a reboot time that has minimum impact on the visitors to your website. It would seem your website runs from a single server, so it might be useful to display a banner on your website that warns your visitors of an impending reboot. I have implemented something similar that appears one hour before a reboot and displays a message saying 'The website will close in x minutes for maintenance. Maintenance should take no longer than 10 minutes'
  3. Because you have manually initiated a reboot of the server, you can check that the server has come back up successfully after the reboot. If it hasn't, you can speak to your hosting provider and deal with the problem.

Basically it's all about control and with automatic downloads and automatic installation, you don't get much!!

share|improve this answer
add comment

I'm afraid I have to disagree with the consensus.

Anybody who says that "human intervention is required" is not thinking progressively enough.

Automate everything.

Maybe this means turning on automatic update (I do this in my low-consequence environments).

Maybe it means something more rigorous (where you automatically update a staging environment, have it automatically validated for correct operation, then trigger the automatic update in the production environment). Reports or e-mail notification should be used so that administrators have visibility into the status of the process.

There are a number of ways to accomplish this automation, from powershell scripts to Software Update Services (SUS)... and especially since you asked this question on stackoverflow and not serverfault, I would recommend that you develop routines to automate as much of the update process as possible.

Failing to do so puts yourself at risk of not applying updates or applying them improperly. Also, if you're anything like me, you would prefer to wake up at 3am once in a blue moon when updates fail (and you're paged by your update routines), and not wake up at 3am every month to install the updates during low-consequence hours.

Of course, YMMV. Design a process that works best for you, but try not to make too much unnecessary work for yourself.

share|improve this answer
add comment

As everyone else here has already answered: NO! We use Systems Centers Essentials to push updates to production web servers, only AFTER they've been installed on test servers.

We also get the monthly update emails from MS so that we know exactly what each update is and what its for. It makes it much easier to troubleshoot if you know exactly what got updated and when.

share|improve this answer
add comment

I allow automatic updates, but do so via WSUS. This enables you to pick and choose the class of updates you want applied automatically so that you don't get interruptions for trivia you don't care about but you do get patches for Day 0 exploits as soon as possible.

I don't think it's a matter of "allow updates" and "don't allow them" being right or wrong, by the way, it's simply a matter of picking what risks and inconveniences you are prepared to take. There are risks for allowing updates to go on automatically and there are risks if you don't. Balance them out and make an informed choice.

You could consider a staged rollout - patches released on tuesday are installed straight away on a test environment and scheduled to be installed thursday on the production servers, say, giving you two days for problems to show up in the test environment that point to blocking or delaying a particular patch.

If high availability is that much of an issue then you should be using clustering or load balancing as appropriate anyway, which should cover for downtime due to patching anyway. After all, why is downtime due to patches somehow magically worse than the hardware failures that can occur on any one box at any time?

share|improve this answer
add comment

We never enable Automatic Updates on our server. It's hosted at a data center, so what we did was watch stats in Google Analytics to see at what time traffic was at its lowest, then scheduled the techs to install updates at that time on-site. That way, if a reboot was required, or something went terribly wrong, it wouldn't affect as many people as if Windows had downloaded an update in the middle of the day.

share|improve this answer
add comment

Definitely not. Been taught the hard way too many times not to let this nonsense happen. Unfortunately, it does mean that one is a bit lazier about applying patches and updates. But so far, I've yet to have a server broken into because I didn't apply some particular patch right away, but I have had a great many headaches caused by a server rebooting at an inconvenient time, or by rebooting and failing to start some essential service after installing a patch.

On a sidenote, we just got a new cluster of five machines via our service provider, a very large and well-known ISP from this part of the world. When we got the administrator accounts and could log in and start setting up our software, I was quite pleased to see that this usual first task was already taken care for me by the network sysadmins. :)

share|improve this answer
add comment

Applying updates == random reboots of your system, not under your control. This gives SA's hives. In addition, there have been incidents of breaking patches in the past, so you rarely want them applied if you haven't tried them in the past.

One approach that I've been looking into is moving to a virtualized hosting environment. This allows you to trial the update on a non-production instance, or even apply an update to an offline instance and swap it into production once you're sure it's good to go.

share|improve this answer
add comment

Absolutely not. Updates should be applied to servers during off-hours, and with contingency plans in place -- meaning enough time to roll back the update if it fails.

As a sysadmin you want to have as many variables as possible under your control. It's hard enough without arriving in the morning to a dead server! ;-)

share|improve this answer
add comment

Note that it's possible to set a specific time for updates to take place, and that most updates comes on Tuesdays. That way you can schedule time to review coming and downloaded updates, and know when any potential problems will come up.

share|improve this answer
add comment

A good question to ask yourself is if something screws up what is my VP/CIO/etc going to say to me? Automating it may make your life easier but if there is a problem your going to be the one raked over the coals and this could make things a lot harder.

I automate the heck out of the PCs, with a few hundred you have to. Servers though I schedule it up and get it authorized so if anything goes wrong my @$$ is covered. Remember we are working with other peoples data and with the companies resources, they should always be kept aware of the risks.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.