[Solved] - Version check through registry keys. I don't really understand...

Topics: Misc.
Nov 12, 2014 at 6:10 PM
Edited Nov 12, 2014 at 7:15 PM
Why is this reg_sz version check thing as an option in the WPP-detection rules limited to four part version strings? It is really impossible to check for example a two or three part version string in a key like "DisplayVersion" for example with the data "33.1" for "greater or equal values" because it's got only two "segments", the 33 and the 1? I want to use this for version check of Firefox and many other programs. I can't believe that.

Edit: After all it seems to work now. It seems it's possible to use less than four string parts and kust leave the missing ones to the default zero values. I've tested it by changing the registry value manually from 33.1 to 33.0 and then wuapp.exe finds the update as expected by the used reg_sz version rule design. The problem was, that Firefox uninstaller has left this keys back in the registry after uninstalling Firefox manually, so the update was not found by wuapp.exe while the keys still exists in registry.
Coordinator
Nov 12, 2014 at 7:50 PM
This is unacceptable :-)

I have made two updates with the same "IsInstalled" Rule :
  • Reg_SZ To Version = 33.1.0.0 and a registry Value : DisplayVersion = 33.1
In first update, the rule was put at update level. In the second update, the rule was put at package level.
After triggering a manual detection. This is what I can see in WindowsUpdate.log :
  • For the first update :
EEHndlr EE: Evaluating RegSzToVersion: Subkey=SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Test, value=DisplayVersion, version=33.1.0.0
EEHndlr RegSzToVersion: Successfully opened Subkey SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Test
EEHndlr RegSzToVersion: Successfully queried value DisplayVersion: data: 33.1
EEHndlr EE: RegSzToVersion evaluated to False, return hr=0
  • For the second update :
EE: Evaluating RegSzToVersion: Subkey=SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Test, value=DisplayVersion, version=33.1.0.0
EEHndlr RegSzToVersion: Successfully opened Subkey SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Test
EEHndlr RegSzToVersion: Successfully queried value DisplayVersion: data: 33.1
EEHndlr EE: RegSzToVersion evaluated to True, return hr=0

Don't ask me why, but the same rule is not evaluated the same way if it be in Update Level or Package Level.

Put your rule at package level, and compare 33.1.0.0 with the registry Data.
Marked as answer by DCourtel on 12/3/2014 at 1:30 PM
Nov 12, 2014 at 8:44 PM
I'm working now for some month with your really great tool but I 've never understood the difference between update and package level. ;) Maybe you can explain it?
First i thought that the update level rules will be applied if the update type is set to "update" and the package level rules will be used for updates approved as "application" type updates. But I think this is maybe very wrong ;)
Second possibility is for me, that the update level rules AND the package level rules will be applied for any wpp published updates and if package level rules are defined than they will overwrite some rules that are however defined in the packaged msi or exe setup files or stored in a mst file maybe? I've also read in some documentations to disable the "Package rules" but not WHY to do so and how someone can see if there are some predefined rules that have to be disabled and why?
Coordinator
Nov 13, 2014 at 3:44 PM
First, I must admit that I'm not a Wsus expert.
Wsus is a pretty much well documented role (for a Microsoft product :-) )

This is what we can learn from MSDN :
  • There are three core applicability rules, IsInstalled, IsSuperseded, and IsInstallable. These applicability rules appear under the InstallableItem.ApplicabilityRules element under the SoftwareDistributionPackage element (Update Level). The IsInstallable and IsInstalled rules can also be specified at the top level of the SoftwareDistributionPackage element (Package Level). If they are specified in both places, the expressions are combined (using the Boolean AND operator) to form a composite applicability rule for the package.
I have read somewhere an explication for why there are two type of rules (update and package level).
At first, when Microsoft started to think about Wsus, they have imagined that a package can contains more than one update (InstallableItem). So, they have designed a package-level rule and an Update-Level rule. Each InstallableItem should have his own update-Level rule.
Imagines a package to install Office. One InstallableItem contains the main file for Office, a second InstallableItem contains a patch to apply if Windows is installed in French, another InstallableItem contains the same patch for the English version and so on....