Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials

File Version Applicability Rules Not Working

I am installing a custom .exe I made that installs a MS hotfix using DISM. However, the delivery method I am attempting is WSUS through Patch Manager is not working. Here are my app and installed rules. When I remove the file version rule, they start working.

The end goal is to detect if a KB is installed from the WMI, and then make sure the file version of the dll is one that is affected in the KB.

Any ideas?

The wsus log shows WARNING: Failed to evaluate Installable rule, updateID={updateid} .1, hr = 80070002

I have expired all previous versions in between attempts and created a copy of the update and published it just in case. Permissions on the file "c:\windows\system32\advapi.dll are the same on all computers. All target OS's are Server 2008 R2 SP1 datacenter.

-<sdp:ApplicabilityRule SchemaVersion="1.0">

-<lar:And>

<bar:WmiQuery Namespace="root\cimv2"WqlQuery="select * from Win32_QuickFixEngineering where HotFixID="KB2775511""/>

<bar:FileVersion Path="C:\Windows\System32\advapi32.dll"Csidl="0"Comparison="EqualTo"Version="6.1.7601.22137"/>

</lar:And>

</sdp:ApplicabilityRule>

-<sdp:InstalledRule SchemaVersion="1.0">

-<lar:And>

<bar:WmiQuery Namespace="root\cimv2"WqlQuery="select * from Win32_QuickFixEngineering where HotFixID="KB2878378""/>

<bar:FileVersion Path="C:\Windows\System32\advapi32.dll"Csidl="0"Comparison="EqualTo"Version="6.1.7601.22477"/>

</lar:And>

</sdp:InstalledRule>

Find more posts tagged with

Accepted answers

LGarvin

I did not include pre-req rules because I am trying to narrow down the cause. Right now it's just OS = x64.

Cool. Thank you for clarifying.

but I am not testing installed rules just yet, it's the applicability rules that are failing to evaluate in the log.

Understood, but it's also important to note that the success or failure of the Applicability Rules can be impacted by the evaluation of the Installed Rules. If you're wanting to isolate the Installed Rules from impacting the result, put a single rule that ALWAYS evaluates to FALSE in the Installed Ruleset so you can be sure to get only Not Installed or Not Applicable results from the Applicability Rules.

I am testing for two different KB's because:

I think, in general, this logic flow is too complex, and is likely to encounter an uphill battle all the way around.

I would have loved to use common path, but I did not see a system32.

It's there. The COMMON_PATH values are documented here.

I really recommend watching the two webcasts I cited previously. They will help with understanding these concepts.

All comments

ak00

Two questions and a suggestion:

How do you know that the file version you have is the correct one? For example, I have seen some publishers list the version as 11.0.5, but the actual check is 11.0.05.

Have you tried changing the EqualTo to GreaterThanorEqualTo and then changing the Version to something like 6.1.7601.1 ?

Instead of expiring the versions, try deleting the item entirely (from the WSUS store), and copy the source package to edit, and use that one going forward.

LGarvin

For example, I have seen some publishers list the version as 11.0.5, but the actual check is 11.0.05.

Before I answer the original post... a pedantic point, but sometimes a very important one... ALL version numbers specified in rules must be FOUR-part numbers, so both 11.0.5 and 11.0.05 as listed here would be invalid version numbers. What that brings to the table is first, whether the vendor has properly defined a four-part version number on the file, and second what it actually is. Furthermore, not only are there sometimes just minor variations (like the inserted zero above), but sometimes the file version number has absolutely nothing to do with the product version number.

In the instance case, though, I suspect that the version number specified in the Installed Rule is correct, and the *rule* being used in the Applicability Rules is incorrect, both on how it does the comparison and what it's comparing to.

LGarvin

Notably missing from the above rules collection is the Prerequsite Ruleset. What's defined in that?

When I remove the file version rule, they start working.

WHICH File version rule? You have one defined in EACH ruleset! Is is the Applicability Rules that are defective, or the Installed Rules. I see apparent defects in both rulesets.

Why does the Applicability Ruleset and the Installer Ruleset test for a DIFFERENT KB article number in the WMI Query?

Either you're deploying KB2775511, in which case that's what you should be testing for, or you're deploying KB2878378, in which case that's what you should be testing for.

<bar:FileVersion Path="C:\Windows\System32\advapi32.dll"Csidl="0"Comparison="EqualTo"Version="6.1.7601.22137"/>

Applicability Rules should never test with an EQUAL TO comparision, rather you should test for a LESS THAN comparison (which will also effectively test for the absence of the file) using the same version number as the file IN the package (e.g. 6.1.7601.22477). The way this rule has been defined, the package will only be installable IF the advapi32.dll is v6.1.7601.22137, but not if that file is any other version. Since I know for a fact that this file has been patched several times, there's a strong possibility that some or all of your machines do not have that version of advapi32.dll installed. Nonetheless, the only relevant point is that the desired version of the file is not installed, thus the proper test is for LESS THAN 6.1.7601.22477, and nothing else matters.

Also you should never hardcode the system pathnames. Doing so assumes that Windows is always installed on the C: drive and always installed in a folder named \WINDOWS. While generally true these days, it is not a guarantee. Use the proper COMMON_PATH declaration for the SYSTEM32 folder in the Rule Editor (which will populate the CSIDL with the correct value and PATH will have the relative path within the SYSTEM32 folder, which in this case will be ".\advapi32.dll").

In addition, if you're already testing for the File Version of a file being replaced by the package, it is totally unnecessary (and frankly, somewhat resource intensive) to conduct a WMI Query that does functionally the same thing. If the file is not updated, install the package; if it is, don't.

I discuss all of these fundamental principles of package building in the two webcasts we presented and recorded last summer.

Package Creation Fundamentals

Creating Packages with Patch Manager

ak00

Yes, very good point. Better example would have been 6.1.7601.22477 and 6.01.7601.22477.

LGarvin

FWIW... I was just edified to this bit of trivia as well:

Refer the warning given in the SMS_DEF.MOF file below.

“DO NOT: Enable the Win32_QuickFixEngineering class unless you have installed the QFE for Q279225. Enabling this class without the QFE will result in inventory cycles taking a very long time to complete on the client and the WINMGMT service using 99% to 100% CPU time and leaking memory.”

rmartin1

To clarify. I did not include pre-req rules because I am trying to narrow down the cause. Right now it's just OS = x64.

In my testing, I removed both, but I am not testing installed rules just yet, it's the applicability rules that are failing to evaluate in the log. So, wmi is working, file version is not.

I am testing for two different KB's because:

1. KB2775511 is an enterprise HRP for Win7/2008 R2 containing a bunch of hotfixes. However, three that were included in SP1 are regressed after it's installation.

2. KB2878378 is one of those regressed hotfixes. I have packaged this in an .exe that will extract the .cab files from the .msu, and install the hotfix package via DISM.

3. KB2878378 is only applicable in my environment if KB2775511 is installed. In the detail for the hotfix, it references affected file versions.. hence the applicability rule for file versions as well.

4. 6.1.7600.21271 6.1.7601.22056 6.1.7601.22119 6.1.7601.22137

5. 6.1.7600.22477 is the correct file version after the hotfix KB2878378 (this package) has been installed so that is why I chose the file version rule

6. The combo between the file version and wmi query is to account for say a SP2 that might change the file version newer, even after the HRP is installed.

The machines I'm testing on, do have that file version. In fact, all of my win 7 and server 2008 r2 machines, have that exact file version because we just rolled out that HRP. While I intend to test against those three other versions, I am limiting the scope to try to figure out which piece is not working.

I would have loved to use common path, but I did not see a system32. In our case, every machine's path would work just fine with that path.

And yes.. I would like to get away from using wmi completely.. but I'm trying to find something that will actually work..

So you are saying I should specify a range? I guess I'm reading their KB and just identifying exact versions that have this problem, not a range. I'm also not following what you guys are saying about the version numbers. If this is the not the version number, how do I find it? If that is not the right format, then what is?

LGarvin

I did not include pre-req rules because I am trying to narrow down the cause. Right now it's just OS = x64.

Cool. Thank you for clarifying.

but I am not testing installed rules just yet, it's the applicability rules that are failing to evaluate in the log.

I am testing for two different KB's because:

I think, in general, this logic flow is too complex, and is likely to encounter an uphill battle all the way around.

I would have loved to use common path, but I did not see a system32.

It's there. The COMMON_PATH values are documented here.

I really recommend watching the two webcasts I cited previously. They will help with understanding these concepts.