This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

3rd Party Update Applicability Rules

I am currently trying to deploy version 11.1.102.55 of the Flashplayer ActiveX control, I am encountering a problem with the applicability rules where the update is classed as Not Applicable because the target laptop has version '9.0.1.x' and the this appears to be evaluated as greater than '11.1.102.55'.  I know this is because as a true string comparison "9.0" is greater than "11."

I have tried creating my own rule selecting 'Registry Version as String' for the rule type but appears to be exactly the same as Registry String Value and that is what the wizard ultimately saves the rule as.

Has anyone encountered this problem and if so how did you workaround it, my only idea so far is to change the version check to be NOT Equal to 11.1.102.55 but if any of my users have manaully upgrade past this version I will downgrade them to my version which I don't want to do.

Any help or ideas would be greatly appreciated as this is now beginning to drive me mad.

  • Greetings Alan.

    A couple of questions to get us started.

    Is this an evaluation installation or a full installation of Patch Manager?

    What version of Patch Manager are you using?

    Also relevant, what installer type are you using (MSI or EXE)?

    Finally, from the questions-to-ask list: Is this the SolarWinds provided instance of the Flash ActiveX v11.1.102.55 package, or a custom package?

    if a custom package, have you tried using the provided package -- which shouldn't have any issues upgrading a Flash v9 installation at all (and if it does, I certainly want to know).

    Generally speaking, File Version comparisons are not string comparisons, they are numerical comparisons. So 11.1.102.55 will never be greater than 9.x.x.x.  The only exception to this would be if the version data was stored in a registry STRING value -- but, for that case, the ruleset does provide the Registry Version as String rule, which you've already noted. Now, it's also worthy of note that the more reliable means for making applicability check is by checking the FILE that is going to be updated. In the case of the ActiveX control for v11.1.102.55, that file is named Flash11e.ocx and will be found in the %windir%\system32\macromed\folder, and a simple test for File NOT Exist is a pretty authoritative indication that this version of Flash is NotInstalled.

    The rest of that test would be done with an Installed Rule that checks to see if the File DOES EXIST - -and if it does, then the update isInstalled, and will be reported as Installed -- and the Applicability Rules are irrelevant.

  • Hi Lawrence

    Thanks for the quick reply, my answers to your questions are below: -

    Is this an evaluation installation or a full installation of Patch Manager?
    This is a full installation of patch Manager.


    What version of Patch Manager are you using?
    1.72.218.2


    Also relevant, what installer type are you using (MSI or EXE)?
    I am using the MSI installer for 32bit Upgrade.  This has since ben expired but we are testing our configuration of Patch Manager in conjunction with our desktop estate.


    Finally, from the questions-to-ask list: Is this the SolarWinds provided instance of the Flash ActiveX v11.1.102.55 package, or a custom package?
    if a custom package, have you tried using the provided package -- which shouldn't have any issues upgrading a Flash v9 installation at all (and if it does, I certainly want to know).
    We are using a hybrid of a copy of the SolarWinds package in Software Publishing using the standard MSI but with a transform applied to suppress the autoupdate function at installation, having read a bit more on the 3rd party publishing I could probably have done this with a package boot command of some sort in the post-installation section(??)


    The issue appears to be that the installation is not even attempted as the applicability checks fail, it look as though the Solarwinds package has been designed to upgrade in sequence without skipping versions although I can't be certain.
    On my test laptop with version 9 Flash I have a registry key of HKLM\SOFTWARE\Macromedia\FlashPlayer whilst the package checks for key HKLM\SOFTWARE\Macromedia\FlashPlayerActiveX.  I don't know for sure that the installation of v9 is standard but I know that in my legacy environement this registry key check is causing the problem.  I am going to add another group of tests for version 9 in the applicability rules and see if the statistics on the updates server change.  At present 500+ machines are not applicable for v11 but when I check a random sample some have got v9 and should be upgraded, if my new group of rules work then this number should reduce.

    Any comments or advice you could give me would be great.

  • Your observation on the registry keys is quite likely the issue. We design this package to ensure that Flash is installed, but we have to base that on the current behaviors of Flash -- and that would be the FlashPlayerActiveX key.

    I would remove that RegistryVersionInString test from the package. The FileVersion test will still validate that the current version of FlashActiveX is not installed. If you want to retain the "upgrade only" behavior of the package, make a duplicate exprssly for upgrading from v9, and set the test to the regKey that is present for v9.

    The other option is to use the FULL installation package, identify your Flash v9 systems, put them in a special target group, and approve the FULL installer only for known v9 systems.

  • Thanks Lawrence,

    I think the option of using full install is probably my best option, the msi used is still the same so I can apply our transform and the applicability rules appear to show all of our estate with version 9 will be updated.