Building off the concepts learned in my previous post on rulesets, we can now use this information to diagnose unexpected behaviors in custom packages, or pre-packaged vendor packages. In this article we'll look at the two most common misbehaviors: An update that fails to detect as Installed when it should, and an update that fails to detect as Not Installed when it should.

Update not reported as Installed when expected to

There are a couple of scenarios in which an update can fail to report as Installed, one of which is related to the update package, the other related to the target system of the update, and it's important to make this distinction before trying to diagnose a perceived package defect.

Failing to install

The first scenario is when an update has been properly detected as Not Installed, but fails to successfully install. This behavior will manifest on the WSUS server as an update that fails to report as Installed. It will also manifest as an update that reports as Failed, but I have seen many scenarios in which this is exactly what was happening, but it was not recognized as an installation failure. An update that fails to install will continue to attempt to install at every scheduled installation event until either the cause of the installation failure is remediated, or the update becomes Not Applicable.

Failing to report as Installed

So an update that successfully installs, but fails to report as Installed is our focus in this post. When this behavior occurs, it is because the Installed ruleset has not been properly specified. One or more of the rules in the Installed ruleset is returning a value of FALSE, resulting in the ruleset returning a value of isInstalled=FALSE. The key is to determine which rule is returning false. There are two ways you can approach this, and using both ways is the best solution.

 

First, visually verify the truth of each rule in the ruleset. "Impersonate" the Windows Update Agent with Windows Explorer and Registry Editor and check the file and registry resources defined in the rules to see that they do exist, that the file versions are exactly a match, and that the registry values defined are identical.

 

Second, build and publish Metadata Only test versions of the package for each of the rules in the ruleset, and let the Windows Update Agent evaluate the packages. Do all packages detect as Installed? At least one should not, and that will identify the errant rule in the ruleset. Fix the ruleset in the original package and republish the package.

Failing to report as Not Installed

This is an update that reports as Not Applicable when it should be detected as needed. The techniques for diagnosing the problem are identical to the techniques just described in the previous paragraphs, except now you have two rulesets to troubleshoot -- the Prerequisite Ruleset and the Applicability Ruleset. However, we can take advantage of the fact that the PreRequisite Ruleset is actually optional (the Applicability Ruleset is not). So after visually verifying each and every rule (and presuming you've not already identified the errant rule), create test packages as before, except populate each rule in to the Applicability Ruleset only. At least one package will detect as Not Applicable, and that will identify the errant rule. Fix the appropriate ruleset in the original package and republish the package.

 

Understanding these behaviors can be very helpful when building your own custom packages, which I discuss in the next post.