I understand that it is good practice to NOT automatically install Windows Updates on servers. My questions is, how does one go about vetting which updates should be installed and which to avoid?

In my case, I am running Windows Server 2012 R2.

3 Spice ups

There are two main reasons to not auto update.

  1. It will reboot your server unexpectedly
  2. An update may cause problems for you

For number 2, you need to test. Install on one Server first, see how it goes. If all is well, install on the rest.

if you can have a test virtual environment so you can apply the patches there first and see if anything doesn’t work the way it should

1 Spice up

We always install on a few non-critical servers first, typically backup and suchlike. The only problem with that is that you often find 2 completely identical servers react differently to the updates.

We have 5 file servers, 2 of them are often a problem despite all 5 being identical virtual servers and all created on the same day by the same person.

Ghosts in the machine I guess.

Installing automatically is fine, not knowing what it’s installing or when it’s installing is the problem.

Use WSUS and set a policy so updates fire at a known time on a known day and that way only the ones you approve will be installed.

This certainly used to be a concern, but my experience has been that over the last few years Windows Updates have got very reliable as far as core OS updates are concerned. I haven’t had a box fail an update or crash as a result of one for several years. Touch wood!

Of course, you still MUST test updates on a non-critical server first, especially any application patches like SQL or Exchange. We typically do those manually still so that they’re more controlled, not least because something like an Exchange CU can take a long time to install. But standard OS patches can be automatically installed fairly safely these days after testing, and we happily roll them out overnight a couple of weeks after Patch Tuesday.

The main trick is to stagger the schedule so that you don’t have everything going down at once. We typically set up two or three schedules - Tuesday, Wednesday, Thursday - firstly so that it’s more controlled and secondly so that we can catch any faulty patches after the first night and prevent them from going out to subsequent boxes.

As of last month Microsoft changed the patch model. They are now releasing two updates every month. One for critical and security and the other for optional. If you’re a small one or two (or even up to 5 or 6) server shop testing, while great in theory isn’t always easy in practice. Of course if you can then do so. But if not I make sure you have full backups and then apply the updates AT LEAST 2 weeks after release (but no more than 4 weeks). If there are any major problems they are usually discovered by then by others and if they are Really major, MS should pull them back our issue an updated one to address the issues. For good measure, before applying them now, Google their KB number and see if there are any reports of issues.

MultiverseIT, good advice. We are a small facility with about 10 servers. Do you actively test the updates, or install them after a couple of weeks and see if any issues arise? Also, which option would you recommend for a server?

Install updates automatically

Download updates but let me choose whether to install them

Check for updates but let me choose whether to download and install them (I’m thinking this one)

Never check for updates

How about on client machines (Windows 7 pro)? We ran into a couple of big problems effecting group policy and printers which were caused by windows updates.

Thanks

Got some new info yesterday - My new recommendation is to perform patching BETWEEN the 1st and 2nd Tuesday of the month. NO LATER than the Monday before the Second Tuesday. In my opinion that will be the safest time to apply patches/ensure updates don’t cause problems because if they did, others would have discovered them first.

All patches are cumulative and security patches are issued 2nd Tuesday.