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.

Custom Package Not Applicable

I created a custom package to install Altaro Hyper-V backup version 4.1.20.0 with the following properties:

Pre-reqs: None. I was hoping leaving this blank would just ignore pre-reqs and go straight to the applicability condition, which it seems like it does.

Applicability: C:\Program Files\Altaro\Altaro Hyper-V Backup\Altaro Hyper-V Backup.exe version less than 4.1.20.0

Installed: C:\Program Files\Altaro\Altaro Hyper-V Backup\Altaro Hyper-V Backup.exe version  equal to 4.1.20.0

Certain systems without Altaro Hyper-V Backup.exe report the patch as applicable. Is this because the file version is technically below 4.1.20.0, even though the file doesn't exist?

That would make sense, but the thing that doesn't is that there are systems on which the file exists and clearly has a lower version, but are not reporting the patch as applicable (see below).

Any ideas why this is happening?

AltaroNotApplicable.jpg

  • Certain systems without Altaro Hyper-V Backup.exe report the patch as applicable. Is this because the file version is technically below 4.1.20.0, even though the file doesn't exist?


    Yes, because you're using a File Version rule which also returns TRUE if the file is non-existant.

    To specify an UPGRADE-ONLY scenario, you'll need a second rule that confirms the product is installed.

    The SolarWinds Catalog is full of examples of how to do this.


    Also... your Installed Rule is designed incorrectly. Installed Rules should be EQUAL TO ONLY tests.

  • You are correct in assuming that if a file does not exist that it reports as less than the specified version. To create an upgrade package you would need to do the version check as well as a "file exists" check.

    Your installed rule should only be "C:\Program Files\Altaro\Altaro Hyper-V Backup\Altaro Hyper-V Backup.exe version equal to 4.1.20.0". I would also recommend reading the install path from a registry key if it is available. If the path is not present in the registry at least use environment variables. This may mean more rules to accommodate x86 and x64 machines but results in more accurate detection.

    Beyond that, you can post the full xml of the package and I will see if I find anything else that may be causing an issue.

  • Sorry, I posted the install rule incorrectly.  I corrected it to how I actually have it configured.

    Lawrence, I do want to do an upgrade, but rather than making more rules, I have an "Altaro" WSUS group with only the systems I want to install on, so that should accomplish the same thing.

    Where can I local the .xml of the package? I don't see an export option.

    Thanks for the help!

  • You can select the package and click 'Export Catalog'. You will get a cab that contains the xml.

  • I have an "Altaro" WSUS group with only the systems I want to install on, so that should accomplish the same thing.

    And yet, your primary issue here is that systems that do not have the product installed are getting updated.


    The proper way to prevent that behavior is to configure the package so that it can never be installed where it shouldn't, rather than trusting deployment practices to properly identify all, and only, the systems that should get the update.

  • Attached is the .xml file.

    Seconding what Justin posted, you should be using a Registry Value to obtain the installation pathname... most likely this value will be contained at HKLM\Software\Altaro. If not a registry value (best), then at a minimum you should be using the CommonPath = PROGRAM_FILES declaration, rather than hardcoding the full pathname.

  • Aside from the best practice changes Lawrence and I have already recommended, the package looks sound as long as your paths and version numbers are correct. I have seen some clients detection work improperly until the Windows Update cache was cleared.

  • No system without the product is receiving it since I don't put those in the Altaro WSUS group.  They are only reporting it as applicable (which is fine, since we understand why it's happening. i.e., because the version is technically below the condition value).

    The primary issue is that systems which satisfy the applicability conditions are not reporting the patch as applicable. This is troubling since we don't know why it's occurring.  I will test using a registry value instead, but if that fixes the problem I would still wonder why hard coding the path doesn't work: it's included as a valid option to use.

  • if that fixes the problem I would still wonder why hard coding the path doesn't work: it's included as a valid option to use.

    Because, aside from the 'best practice' of using the common paths to begin with, as it happens, hard-coding the path causes the Package Wizard to create an invalid value for the CSIDL, which causes the rule to be evaluated incorrectly. We only discovered this in the past few days.

    <bar:FileVersion xmlns:bar="http://schemas.microsoft.com/wsus/2005/04/CorporatePublishing/BaseApplicabilityRules.xsd" Version="4.1.20.0" Comparison="EqualTo" Csidl="0" Path="c:\Program Files\Altaro\Altaro Hyper-V Backup\Altaro Hyper-V Backup.exe"/>