Update package definitions for WSUS can be built from a very rich set of rules -- 24 different rule types in fact -- but as a matter of practicality, almost every package you will ever build can be defined from one of only five rules. In this article we're going to discuss those five rules, where they should be used, and why. The five rules you need to know are:

  • Processor Architecture
  • Windows Version
  • Windows Language
  • Registry Key Exists
  • File Version

 

The first four of these rules are used, almost exclusively, in the Prerequisite Ruleset. The File Version rule is used in the Applicability Ruleset and the Installed Ruleset. (For background on the function of these three rulesets, see the previous articles How the Windows Update Agent Determines the Status of an Update and How to Troubleshoot Update Misbehavior Caused by Defective Rules.)

 

Processor Architecture

Just about every network in existence today has only two processor architectures in use: x86 and x64. But those are not the only processor architectures in existence. There is still a version of Windows Server 2008 for the Itanium; theoretically (but not yet in reality), the new Windows RT tablets on ARM, could, someday, become WSUS clients (not likely, but could!), and taking a page from the Year2000 lessons of yesteryear... x86 and x64 are not likely to be the only server platforms forever.

 

Any given update installer likely comes in one of three flavors:

  • Architecture dependent, either x86 or x64, with separate installers for each. Most software vendors have moved away from this technique, but some do still exist. It is critical that your package properly identify the processor architecture that the installer can be used with.
  • Architecture independent, with qualifications. The installer self-detects the x86 or x64 environment, but other processor-dependent requirements may exist. Most commonly this occurs on Windows XP systems, where the x86 installer requires Windows XP Service Pack 3, but the x64 installer only requires Windows XP Service Pack 2 (because there isn't a SP3 for x64).
  • Architecture independent, the installer self-detects the x86 or x64 environment and installs the proper files in the proper locations.

 

Windows Version

Most commonly the Windows Version rule is used to define the minimum operating system requirement for the installation, but it can also be used to exclude certain operating systems (e.g. a Flash Active X upgrade will never be applicable on Windows 8), and can also be used to restrict applicability to only workstation operating systems (WinXP/Vista/Win7/Win8) or only server operating systems (Win2003/2008/2008R2/2012).

 

Windows Language

Many installation packages, particularly updates, are language-agnostic, so it may seem that defining a language rule is unnecessary, particularly if you only have one language in your environment. But don't be too confident, as we're all but one acquisition, or one act of the legislature, away from having to support a second language overnight. Another lesson from the Year2000 collection -- if you only have English-language systems, and you're only considering your package in the space of English-language systems, then make sure your package is only detected by English-language systems until you're ready to test it on systems using other languages.

 

Registry Key Exists

This rule is particularly useful for qualifying updates as not applicable to any given system. A fundamental requirement of an update package is that the product is actually installed on a given system. Quite often a simple and reliable check for the absence of a product is to evaluate whether the correct vendor and/or product registry key exists in HKLM\Software. If the key is not present, the software is not installed (or it's a corrupted installation, in which case you still don't want to install the update).

 

File Version

This is the rule that does almost all of the heavy lifting in an update package. Since an update package is, generally speaking, a collection of one or more files to be replaced on a target system, the basis for whether any of those files needs to be replaced is the File Version attribute of each individual file.

 

In the Applicability Ruleset, we are interested in determining whether the file that currently exists on the target system is older than the file in the update package. If the current file is older, then it needs to be replaced; if not, then it does not need to be replaced. Therefore, in the Applicability Rules, we will always define a File Version rule with a LESS THAN operator, and compare it to the version of the file in the update package. You may need to define more than one File Version rules, if you are updating more than one file in the package.

 

In the Installed Ruleset, we are interested in determining only whether the file in the update package is already on the target machine. If the file on the machine is the same as the file in the package, then the package is not needed. As such, in the Installed Ruleset we will use the File Version rule with the EQUALS operator. (You can also use the File Exists rule and specify the file version attribute -- but who needs a 6th rule to learn, when 5 rules does just as good, eh? )

 

If you're interested in exploring the ability to create your own update packages for WSUS, download the 30-day trial of SolarWinds Patch Manager.