8 Replies Latest reply on Mar 29, 2013 8:19 AM by Lawrence Garvin

    WARNING: Failed to evaluate Installed rule


      OK. Back up and running on PM 1.85.490.0 and I've continued with my custom package to deploy the mms.cfg file. The deployment is working but it keeps deploying. I check the WindowsUpdate.log and can see this error.


      WARNING: Failed to evaluate Installed rule, updateId = {F530906C-E1A3-424F-8796-A9C7941184D2}.1, hr = 80070002


      The fact that it's failing to evaluate the rule appears to be the reason why the deployment keeps occuring. So I tried a few variations of the Installed rule but with no success. Here's my Installed rule.


      File Exists: Path=C:\Windows\System32\Macromed\Flash\mms.cfg Common Path=NONE Version= Size=N/A Modified Date=20/02/2013 11:29:02 AM Creation Date=N/A Language=Language Neutral.


      The Date Modified according to Windows file properties is Wednesday, 20 February 2013, 11:29:02 AM. So my assumption is that this patch should find the file, see that the modified date is as expected when installed and therefore flag as already installed.


      Any help appreciated.

        • Re: WARNING: Failed to evaluate Installed rule

          I tried the following to isolate the problem but...


          I duplicated the package and changed it slightly to cater for 32 bit version.

          The package installs without error.

          Then about 2 seconds after its installed, it wants to re-install again.


          I've tried many variations of the FileExists rule and the FileModified rule under the Installed Rule area and I can't get them to work at all. Even if I remove the dates completely from the FileExists rule.


          So in summary I still have a package that repeatedly installs the C:\Windows\System32\Macromed\Flash\mms.cfg file even though the Installed rule is

          FileExists Path="C:\Windows\System32\Macromed\Flash\mms.cfg"


          I would appreciate some help here. Has anyone successfully used just one FileExists rule in the Installed rule area ?

            • Re: WARNING: Failed to evaluate Installed rule

              I've used File Exists rules as an installed rule for several packages but I was always checking version numbers not modified date. I would guess that the problem lies somewhere with the date and time check.

              • Re: WARNING: Failed to evaluate Installed rule
                Andrew M

                When you removed the date parameters from your package, did you expire the old version before republishing it? It's possible that your test workstation has cached the original package with the date rule and continues to apply it. Try expiring the package, allow the workstation to detect that it has been expired so that it will be deleted from cache, then publish the new one with the date parameters unspecified.


                Edit 3/25:

                I've also found this Technet article to be an invaluable resource for the specifics of the update rules: Basic Rules

                  • Re: WARNING: Failed to evaluate Installed rule

                    I was hopeful that this was the answer, because I'd been declining the packages and not expiring them.

                    I expired all of the previously declined packages and deleted them. I also cleared the SoftwareDistribution\Downloads folder.

                    With each test variation, I'm duplicating the package so it gets a new update id.


                    This fixed the repeated installation for the package with no modified date checks. So now I have a package that just checks for the existance of the file and if it's there then the package does not repeat installation.


                    I have also raised this with SolarWinds as a support case. They contacted me during this time and advised that the FileExists rule requires a UTC date and time.

                    So I tried the package again with the UTC date and time. I also tried the FileExists and the ModifiedDate rules seperately but both of these variations still did not eliminate the repetitions.

                • Re: WARNING: Failed to evaluate Installed rule

                  I’ve got this working now.

                  This is the rule that I used.

                    -<sdp:InstalledRule SchemaVersion="1.0">

                    <bar:FileExists Path="System32\Macromed\Flash\mms.cfg"Csidl="36"Modified="2013-02-20T03:29:02"/>



                  The date/time stamp is what's been causing the problems.

                  The date stamp;

                  • at the source is 20/02/2013 11:29:00 AM
                  • on the Patch Manager server is 20/02/2013 11:29:00 AM
                  • on the WSUS server the date and time stamp changes 20/02/2013 11:29:02 AM
                  • on the deployed PC is 20/02/2013 11:29:02 AM


                  I was checking that the time stamp was the same as the source when in-fact it was 2 sec's different. I’m not sure how the 2 second difference is introduced, but all 4 files in the package are 2 sec's older than their source files at the time of creating the package.This was easy to reproduce in another package.


                  Can someone else check to see if this is a bug. This is the process i followed to reproduce the issue.

                  • Create a new package and fill out the mandatory info on the package information screen
                  • Don't bother with a Prerequisite rule, just click next.
                  • Select 'I already have the content...' and download an exe file. (i used an inert executable)
                  • Tick 'include additional files...' and add another file (i added mms.cfg)
                  • Click Next to finish the wizard and save the package, ignoring the errors about not having any rules. (add rules if you want but they're not important)
                  • Now check the date and time stamp of the 2 files you added to the package from both the upload source and in the Content tab of the package details.
                  • The date and times match.
                  • Now publish the package to your WSUS server.
                  • Browse to the deployed test package in WSUS and get the file URI from the File Information tab.
                  • Open the cab file by pasting the URI into explorer.
                  • Extract the 2 files from the cab and check the date and time stamp. For me they are 2 seconds older.


                  I'm running Patch Manager Version 1.85.490.0


                  1 of 1 people found this helpful
                    • Re: WARNING: Failed to evaluate Installed rule
                      Lawrence Garvin

                      Whether there might be a 'bug in how the timestamps are handled when a CAB file is created is really beyond the scope of SolarWinds or Patch Manager, as that's a Microsoft specification, a Microsoft tool, and a Microsoft product where the CAB file was built. (Patch Manager does not build the CAB file; the WSUS API actually does that part of the process.)


                      Phil, fundamentally there is nothing wrong with the process that you used, except that you need to base your ruleset off of client-side post-deployment data, not pre-deployment data, particularly when defining the *Installed* rules.


                      So, the important takeaway from this thread is that it is critically important to build rules from the actual data contained on the CLIENT. Specifically Installation Rules must be built from the actual state of reality on a client where the product is installed, not the expected results of that installation. (Things change; stuff happens.)


                      I have a curriculum I wrote on "Local Publishing" a few years ago, which I'm in the process of re-purposing into blog articles for PatchZone.

                      One of the tenets of that curriculum was this comprehensive approach to package creation:

                      1. Document the state of a reference system PRIOR to the installation of the update. This is the basis for your Prerequisite and Applicability Rules.

                      2. Install the update on that reference system using the vendor supplied installer. Part of this will be the basis for your Installation File specifications.

                      3. Document the state of the reference system AFTER the installation of the update. This is the basis for your Installed Rules.

                      4. Build the package based on the information obtained in Steps #1 through #3.

                      5. Publish, approve, and deploy the package to a system configured exactly as the refernence system in Step #1.

                      6. If the behavior at the conclusion of Step #5 is different from that observed at the end of Step #3, revisit the data obtained from Step #3.