Thoughts on Windows Updates for Servers

Over the past 15 years of working with Windows Servers, I have seen and heard of many different approaches to the Windows updates Microsoft provides on “Patch Tuesdays”.  Some companies set their servers to download and install patches as soon as they become available.  Some roll out patches to development or test servers first.  Some actually prefer to never run any patches at all.
There are a number of programs available to patch both servers and workstations.  There are third party tools such as Kace, Kaseya, SolarWinds etc.  Microsoft provides the very popular and free Windows Server Update Services or WSUS.  All of these tools have their merits and drawbacks.  For a small company, the use of Group Policies and WSUS may work fine.  A larger organization may opt for the granularity that third party programs provide, albeit at a potentially higher cost.
Most of the clients I have worked with have had three constraints that really limited how and when servers get patched:

1.  No development or test environment that mirrored the production environment close enough to really test patches.
2. A very limited “maintenance window” to allow for patching.  Most businesses that I have worked with allowed for one weekend a month with a seven or eight hour window, usually in the middle of the night, when patches could be applied and servers rebooted.
3. Some servers are not domain joined.

Based on these constraints, I had to develop a process so that servers could download, install updates, and reboot within a specific time window.  If WSUS is setup, you can choose what updates to approve and when you approve them.  This is great for controlling what is approved, but the when becomes a little more difficult.  There is no scheduling feature to tell servers to download approved updates, wait for a specific time, install and reboot.  The same thing goes for controlling update behavior manually or via Group Policies.  I can tell Windows to check and install every day or even every week at a particular time, but not the third Saturday of each month at 2am!
The procedure I ended up using in most cases is a combination of Group Policy setting, WSUS if available, scripting, and scheduled tasks:

1.  Configure Group Policy for domain joined servers. My preferred settings:
   1. Set Servers to look for a WSUS server if one was setup, otherwise download direct from Microsoft.
   2. Download updates overnight and notify for install.
   3. Allow immediate installation for updates that don’t require a reboot or interrupt Windows.
   4. Prevent non-administrators from receiving update notifications.
   5.  If not using WSUS, login to each server and install Microsoft update so you get patches for MS Office and other Microsoft products.  Hide patches you don’t want to install (Internet Explorer 11 or Silverlight for example).
   6. Setup a script via the Task Scheduler to install updates at the beginning of the maintenance window.
   7. Setup a task to reboot Servers within the maintenance window, but in a staggered fashion so they all aren’t rebooting at the same time.

The most important part of this process is to get the script to do what you want.  I want the script to install the downloaded updates, skip the hidden updates, and not automatically reboot the server.  There are VB scripts and PowerShell scripts out there which can easily be found by a little googling, but the one I chose and modified was from here.
Some of the modifications I usually make:

1. Change the location of the log files (which has to be created before the script will run).
2. If WSUS is not being used, I modify line 126 to remove the ISAssigned=1 variable so that all non hidden updates get installed.
3. Comment the beginning of the script with relevant info so that anyone in the future can easily understand exactly what the script is supposed to do.

In an ideal situation, I would prefer to have a test environment running every piece of software a company uses, and install updates there first before approving updates for production.  If Servers could be rebooted each night or even once a week, I would just use Group Policy to download and install overnight.  The constraints I listed seem to be the norm, rather than the exception.  In my experience, the process I have outlined has been an acceptable solution that balances the risk of delayed patching with downtime predictability.