4 Replies Latest reply on Nov 7, 2013 11:18 AM by Lawrence Garvin

    Installed rule fails to evaluate

    jkerrigan


      I am trying to deploy an Update to Verizon Access Manager to Machines in my Domain.  However I'm getting an update loop, and the windowsupdate.log is telling me "WARNING: Failed to evaluate Installed rule, updateId = {1C1CBC09-51F5-428C-A86E-20B2FB0EC25E}.2, hr = 80070002".

       

      Here are my rules. ( I'm Trying to get in working on x86 then will add rules for x64)

      prerequisite rule.PNG

       

      Applicability.PNG

      installed rules.PNG

      and here is the inventory on the machine showing it installed.

      installed.PNG

        • Re: Installed rule fails to evaluate
          David Di Blasio

          Try running through the following on your test machine, and see if the same error reproduces.

           

          1. Stop the Automatic Updates service.

          2. Rename the %windir%\SoftwareDistribution folder to SoftwareDistribution.OLD

          3. Restart the Automatic Updates service.

          4. Run wuauclt /resetauthorization /detectnow and observe the results.

          • Re: Installed rule fails to evaluate
            Lawrence Garvin
            >> However I'm getting an update loop, and the windowsupdate.log is telling me "WARNING: Failed to evaluate Installed rule, updateId = {1C1CBC09-51F5-428C-A86E-20B2FB0EC25E}.2, hr = 80070002".

            These two behaviors are congruent with one another and suggest a fatal defect in your Installed ruleset. The failure to evaluate the rule in the Installed Ruleset prevents the WUAgent from determining that the update isInstalled and thus continues to evaluate it as notInstalled, and thus you see your continuous update loop. I would also point out that a deficiency in your Applicability Ruleset is also contributing to this loop, because a well crafted Applicability Ruleset should return an update as notApplicable when it is, in fact, installed.

             

            To be specific...

            In the InstalledRule, it appears you're looking for a file in C:\Program Files\Verizon Wireless

            but in the ApplicabilityRule, you're looking for the file in C:\Program Files (x86)\Verizon Wireless

            My guess would be that the InstalledRule is failing because the folder C:\Program Files\Verizon Wireless does not exist.

             

            Also, I cannot emphasize enough the importance of using COMMON PATHS when definining a package.

            To reference the "Program Files (x86)" folder, use the PROGRAM_FILES common path, and then backpath the "Path" value, e.g.

            Common Path: PROGRAM_FILES

            Path: ..\Program Files (x86)\Verizon Wireless\

             

            If you use the COMMON PATH in this manner, your InstalledRule XML will look like this:

            <sdp:InstalledRule SchemaVersion="1.0">
              <bar:FileVersion Path="..\Program Files (x86)\Verizon Wireless\VZAccess Manager\VZAccess Manager.EXE" Csidl="38" Comparison="EqualTo" Version="7.10.0.0" />
            </sdp:InstalledRule>

            • Re: Installed rule fails to evaluate
              Lawrence Garvin

              Beyond the immediate fatal issue with the Installed Ruleset...  I'm also seeing some creative, and potentially overcomplicated, logic in the Applicability Ruleset.

               

              An OR block testing for one of the following:

              FileVersion Path="Program Files (x86)\Verizon Wireless\VZAccess Manager\VZAccess Manager.exe" LESS THAN 7.10.0.0

              FileVersion CommonPath=PROGRAM_FILES Path="Verizon Wireless\VZAccess Manager\VZAccess Manager.exe LESS THAN 7.10.0.0

               

              If this truly is a 32-bit application installed to a 64-bit system, BOTH of the above rules will always FAIL. In the first rule, you've specified an invalid path (no drive specification on an absolute pathname).

              In the second rule, that will work on a 32-bit system, but it will fail for a 32-bit application installed on a 64-bit system because the folder would not exist in PROGRAM_FILES.

               

              You also have two NOT FileExists rules, which also have the same invalid path issue as the File Version rule, but more significantly is 100% redundant with the use of the FileVersion rules above (assuming they have valid syntax), so I would suggest simply removing the NOT FileExists rule. The FileVersion rule will return a TRUE result if the file being tested is NOT present (effectively the version of a non-existent file is, in fact, less than whatever actual value is being tested against). You can see hundreds of examples of the use of the FileVersion rule in this manner in the packages provided in the SolarWinds catalog.

               

              The best logic to use involves the use of the ProcessorArchitecture rule, and you can see these examples in the Applicabilty Ruleset for the Flash ActiveX package.

               

              When ANY of the following...

                When ALL of the following...

                  ProcessorArchitecture=X86

                  FileVersion CommonPath=PROGRAM_FILES Path="Verizon Wireless\VZAccess Manager\VZAccess Manager.EXE" LESS THAN 7.10.0.0

                When ALL of the following...

                  ProcessorArchitecture=X64

                  FileVersion CommonPath=PROGRAM_FILES Path="..\Program Files (x86)\Verizon Wireless\VZAccess Manager\VZAccess Manager.EXE" LESS THAN 7.10.0.0

               

              In the first ALL block we're looking at a 32-bit application installed on a 32-bit system which will always be in PROGRAM_FILES\Verizon Wireless\...

              In the second ALL block we're looking at a 32-bit application installed on a 64-bit system (which will always be in C:\Program Files (x86)) referenced as PROGRAM_FILES\..\Program Files (x86)\Verizon Wireless\...