Windows updates have historically been a constant annoyance for IT staff. Manual updates were a huge pain, and, while the advent of the Automatic Update feature improved the situation, it brought with it problems of its own. Specifically, Automatic Updates are simply too automatic. Automatic Updates grabs the latest updates, no matter what type, and applies them according to a schedule you set. The feature has no information and makes no judgments about service level agreements (SLAs), buggy updates, or anything else; it simply downloads and applies. While this may be acceptable for most home users, it is woefully inadequate in an enterprise.

A secondary problem with Automatic Updates is that each PC must manually download the updates from Microsoft, which can be quite demanding on your Internet link. Luckily, Microsoft once again comes to the rescue with Windows Server Update Services, otherwise known as WSUS.

What WSUS gives you, out-of-the-box, is a way to consolidate updates on one server, distribute them out to clients, and apply only approved updates from approved categories at approved times. It also includes some useful, if somewhat lacking, reporting capabilities. However, all of this still isn’t enough for a high-uptime environment, and that’s where tiering comes in.

By dividing systems into tiers and applying separate update policies to each tier, you can ensure that high-impact systems only receive a very limited set of extensively tested, approved updates, while low-impact systems (like lab systems) receive the latest updates for testing. To illustrate this concept, let’s take a look at the real-life example.

Trying it out

In this example, we are a Web hosting provider responsible for updating hundreds of servers in a very high-uptime environment. In general, our servers are configured in customer racks conforming to the following basic layout:

Example Web hosting customer rack

In this environment, you typically have hundreds of customers that conform, more or less, to this layout. Several load-balanced front-end Web servers connect to a back-end SQL cluster, while one or more test systems are used to test future site updates.

The subtleties in this environment are minimal; At least one front-end server and one SQL server should be up and available at all times, and updates should be validated on the test server(s) prior to applying them to any of the production servers.

Based on the environment, a four-tiered WSUS implementation would work pretty well if it were arranged as follows:

Tier1: Test Systems

Tier2: First node of any multi-node group, inactive node of a failover (active-passive) cluster

Tier3: Second node of any multi-node group, active node of a failover (active-passive) cluster

Tier4: Third node of any multi-node group, also Stand-alone servers

For any group that spans more than three nodes, you would start back over at Tier 2 for the fourth node.

Using our earlier example, we would arrange the systems as follows:

Tier1: The test server

Tier2: The first Web server and the inactive node of the SQL cluster

Tier3: The second Web server and the active node of the SQL cluster

Tier4: The last Web server

After dividing our servers into tiers, we then need to exercise the real power of WSUS and implement policies based on those tiers:

Tier1: Automatically approve and apply updates every Monday

Tier2: Apply only manually approved updates every Tuesday no less than one week after Tier 1 applies them

Tier3: Apply only manually approved updates every Wednesday no less than one week after Tier 2 applies them

Tier4: Apply only manually approved updates every Thursday no less than one week after Tier 3 applies them

Essentially, what this type of policy buys you is one week’s worth of testing time between each tier, while making sure the latest updates are always being tested on the testing platform. In a large hosting environment, the hundreds of servers involved pretty much ensure that you will always know about problems with an update before you reach Tier 3, which means you should never have a bad update applied to all nodes of a multi-node system.

So, now that we’ve explored the concept and benefits of using a tiered WSUS architecture, let’s take a look at the details involved in creating it.

A tiered WSUS infrastructure requires configuration in four areas:

Active Directory Groups Group Policy WSUS Groups WSUS Auto approval Policy

Let’s begin by bringing all of the pieces together for a high-level view. WSUS uses Group Policy settings to configure the client machines. Since we want slightly different settings for each tier, we will create one group policy object for each tier. We will then create separate Active Directory (AD) groups for each tier and place the systems in the correct AD groups. Next, we will modify the permissions on each tier’s GPO to allow only the appropriate AD group the "apply group policy" permission, thus ensuring that the GPO only applies to systems in the correct tier. Then, we will create the appropriate computer groups in WSUS for each tier, allowing our GPOs to place the systems in the correct WSUS computer groups. Finally, we will modify the WSUS auto approval policy to facilitate automatic approval and application of patches to the test tier, Tier 1.

If all of this sounds complex, don’t worry, its much simpler than it sounds. The total solution involves several pieces, but each piece is fairly simple on its own. Let’s dig into the details, starting with AD groups.