Should we be installing Windows Security updates? [closed]

I just RDP'd into one of my companies servers, was alerted to windows updates, so I click. Then I see 62 high priority updates, with the last update (according to update history) was installed on Thursday, January 16, 2014, more than one year ago.

What actions need to be taken here?


Short answer - yes. Most of the Windows Updates are security related. Not having the patches means you're vulnerable.

Longer answer - you need a procedure that covers this sort of thing. It's more rare these days, but sometimes a patch can break things, or change behavior in such a way that it's broken as far as your company is concerned. You should be evaluating each patch when it's released (there's a monthly schedule plus some urgent ones), determine if you need the patch (probably yes), do some testing on test/staging servers to do some diligence about potential breakage, and then do the installs.

You should also exercise some care about the deployments, because OS patching often means rebooting, which often means there's service downtime, unless you've got some good HA for all your services. If you think you'll be clever and patch during the day and then postpone the reboot, that's not a great idea - some files will be updated but others won't.

Microsoft offers a free product called WSUS that can make patch management a little easier than doing approvals and deployment all one-by-one.

FYI, you should be doing this sort of thing for all classes of device you have. Network device firmware, server hardware firmware, VMware ESXi, etc. Those patches don't come out for the fun of it, almost all of them address bugs, and many of them can be security related.

Further - you should be asking someone who's more senior than you on your technical team. If you're the only admin there, you and your organization are not doing too well. Don't take that personally, we all need to start without knowing everything we should - but if this is your question, you shouldn't be the only person managing these servers.


The generic answer is it is a good practice to keep your servers updated.

But pay attention to a few things:

  1. Updates may cause the server to be sluggish during installation, or even cause some downtime if they require reboot(s). You should plan to do them out of office work hours.

  2. Updates have some risk associated. They might break your server, or cause some incompatibility. They are usually fully uninstallable, but with 62 of them you should also consider if you have a trustworthy backup (you should, anyway).

  3. Is there a reason why you are one year late on upgrades? Is this your first log in to that server in a year, or is something else broken?

  4. Pay special attention to the infamous Excel bug that comes with some December updates of Office, if your company uses Excel macros, but this probably doesn't apply to a server that shouldn't be running Office.

  5. Many sysadmins wait a few days or weeks before installing updates, just to see if anything bad comes up on the Internet regarding those updates. When deciding if you need to wait, consider security risks of leaving the server unpatched for more time.


I know mfinni beat me to the punch, but I'm just going to +1 for WSUS. Specifically:

Let's assume that you have multiple servers, including test and production. Let's also assume that test has similar hardware to production (which isn't a safe assumption, I know, but let's go with it--it's nice but not necessary). You could set up the following scenario in WSUS:

  1. Test servers in their own OU. Group policy says to install updates and reboot at some non-inconvenient time, like Sunday at 3am.
  2. Prod servers in a different OU or OUs. Group policy says to download and notify.
  3. Patches approved, and deadlined to install and reboot the servers during your scheduled maintenance window, several days or a week after the test/dev servers apply patches.

What this does, if it's not obvious, is it approves all critical/security patches for your servers, applies them to test first, and then applies them later to production. I've only seen an update critically break something once, but this would give you a chance to roll back the patch if it fails in test before it applies to prod.

As for the big pile of updates on the server in question, patching is a lower risk than not patching, but I would verify my backups before applying them all just in case because there are so many. If it's a VM, you might want to take a snapshot first.


This is entirely up to your business and the policy that you have set out for updating your servers.

At the very least you should install security updates and perform any other patches like .NET framework updates in a testing environment first before updating production servers.