10 Replies Latest reply on Jun 14, 2012 3:30 PM by SolarWinds Community Team

    Installed rule behaves different than expected

    SolarWinds Community Team

       

      Dear all,

      I don't see what I am doing wrong:

      • My "Appliicability Rule" says "Greater than or equal to 5".
      • My "Installed Rule" says "NOT File Exists C:\ProgramData\Microsoft\Windows\Start Menu\Programs\EminentWare WMI Providers\Uninstall EminentWare WMI Providers.lnk" (Common Paths not used, no other restrictions).

      My expectation is that if the shortcut exists the package would see itself aa not installed and triggers.

      Fact is that no matter if the shortcut exists or not the package triggers.

      Can you please explain why it always result in status "not installed"?

      Thank you very much for your support

        • Re: Thank you!  I found it.
          SolarWinds Community Team

           

          A bit of context would help, e.g. what, specifically, are you trying to accomplish, and what are all of the rules configured in the rulesets.

          Testing for a LNK file is somewhat unorthodox, and testing for the ABSENCE of a file to determine if a product IS INSTALLED, is exactly the opposite of what you would want to do.

          To test if the WMI Providers are installed, I would suggest testing for FILE WUAProvider.EXE EXISTS. If TRUE, the providers are installed; if false, they are not.

          btw.. the WMI Providers are already built into the 3rd party catalog, ready to be used.

            • Re: Thank you!  I found it.
              SolarWinds Community Team

               

              Sorry for not explaining the context.

              In our corporate environemtn we avoid having Program Groups in the Start Menu that are of no relevance for our user community and the "Eminentware WMI Provider" with an uninstall shortcut that neither could nor should be used is such an item. Therefore I have made a package that deletes the shortcut if it exists.

              So the package should apply if the shortcut is there, and delete it. Opposite of that if there is no shortcut, then the package does not apply.

              I did some further testing and if I take out the "NOT" flag from the Installed rule, then it behaves like expected. But when using the NOT flag it fails.

              I would appreciate if you could try to verify this on your side, even if you do not approve of the reason we are using this approach. Technically it should be possible, right?

                • Re: Thank you!  I found it.
                  SolarWinds Community Team

                   

                  Thank you. The context is very helpful, particularly in this unusual scenario.

                  The NOT File Exists rule should be returning TRUE in the Installed Ruleset if the LNK file is not present, and if the Installed Ruleset returns TRUE, then the package should be reported as Installed (the Applicability Ruleset becomes functionally irrelevant in this instance). If the Installed Ruleset returns FALSE, then the state (and behavior of the package) is driven exclusively by the result of the Applicability Rules. I'm curious what you mean by "it behaves like expected", when you take out the NOT flag. Removing that option should cause exactly the opposite behavior -- e.g. the package is reported as Installed and does not execute when the LNK is present, and is reported as NotInstalled or NotApplicable when the LNK is removed.

                  If it's not critical that the package that removes the link is actually reported as Installed, and it would be sufficient if the package is merely reported as NotApplicable or NotInstalled -- the former meaning the link has been removed (or the WMI Providers are not installed), the latter meaning that the link is presence and has not yet been removed -- then you can choose to ignore the Installed Ruleset.

                  In the Applicability Ruleset --

                  • Test to see if the WMI Providers are installed, e.g. File Exists %ProgramFiles%\EminentWare\WMI Providers\EminentWareExtensionProvider.EXE. Note, also, you'll need to build conditional logic to deal with x86 and x64 systems, as x64 systems will need to be backpathed from %ProgramFiles% to get to ~\Program Files (x86).
                  • Also test with a File Exists rule on the LNK file.

                  Ergo, if the providers are installed and the LNK file exists, then the package should be applied (and the link removed), and it will be reported as NotInstalled.

                  If either the providers are not installed, or the LNK file is not present, then the package will be reported as NotApplicable.

                  In this instance the package will never be reported as Installed.

                  If you need to have the Installed status reported, and the NOT File Exists rule is not behaving as expected, another alternative is to have the package create a marker file someplace safe in the filesystem, and then test for the presence of that marker file in the Installed Ruleset. This would be the equivalent of any other package placing a file on a system to "install a patch".

                      • Re: Thank you!  I found it.
                        SolarWinds Community Team

                         

                        Thank you Lawrence.

                        And sorry for this break in communication, I was on an Easter leave.

                        I am very sure that something is not working as supposed to. Let me describe the package I have made in detail so that you can better investigate it and the others interested see what I woulld like to achieve.

                        • Package Titel & Description: ShortcutDelete.Eminentware 1.0
                        • Classification: Tools
                        • Vendor: DGF-IT
                        • Product: Shortcuts
                        • Severity: Moderate
                        • Impact: Normal
                        • Reboot behaviour: Never reboot
                        • Prerequisite rules: None
                        • Package: Command Line installer (.exe)
                        • Package: DeleteSC.exe (AutoIt executable that deletes "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\EminentWare WMI Providers\Uninstall EminentWare WMI Providers.lnk")
                        • Download location: source share
                        • Binary language: English
                        • Success Code: 0
                        • Applicability Rule: Windows Version >= 5
                        • Installed Rule: NOT file exists C:\ProgramData\Microsoft\Windows\Start Menu\Programs\EminentWare WMI Providers\Uninstall EminentWare WMI Providers.lnk
                        Expected behaviour:
                        • If WMI Provider is installed and Shortcut is at the default location, the package triggers, executes and deletes the shortcut
                        • IF WMI Provider is installed and Shortcut is deleted, the packages assumes to be installed
                        Real behaviour:
                        • If WMI Provider is installed and Shortcut is at the default location, the package triggers, executes and deletes the shortcut   --> as expected
                        • IF WMI Provider is installed and Shortcut is deleted, the packages assumes to be installed  --> not as expected: the package does not see itself installed and therefore appears again forever, although the shortcut is truely gone.

                        Although I can't remember the details, I had another issue with a "not file exists" rule.

                        Thank you very much for your support.

                        Martin

                         

                          • Re: Thank you!  I found it.
                            SolarWinds Community Team

                             

                            • Applicability Rule: Windows Version >= 5
                            You're going to need to write a more functional Applicability Ruleset than this. This ruleset is defective, will always return TRUE, and as such will cause problems on systems that do not have the WMI Providers installed. I described in my previous post the appropriate logic to be used in an effective Applicability Ruleset.

                            Also, because you're not using Environment Variables -- your reference to C:\ProgramData is inconsistent with version 5 operating systems, since C:\ProgramData did not exist until Windows Vista. The link is located elsewhere on Windows XP and Windows Server 2003 systems. At a minimum this package should be validating  (in the Prerequisite Rules) that Windows Version >= 6.0. Alternatively you'll need to build conditional logic into your ruleset to account for the differences in operating systems.

                            Please refer to the resources available on the EminentWare website for additional information in ruleset development:

                            And to the Local Publishing Administration Guide available on the SolarWinds website.

                             

                            Message was edited by: Lawrence Garvin (6/15/2012) to update links to product documentation.

                              • Re: Thank you!  I found it.
                                SolarWinds Community Team

                                 

                                This system is dedicated to a group of Desktop and Laptops with Windows 7 - no server, no XP, no 64 bit.

                                I did as you said:

                                1. Killed the installed ruleset
                                2. Changed the applicability ruleset to:

                                <sdp:ApplicabilityRule SchemaVersion="1.0">
                                  <lar:And>
                                    <bar:FileExists Path="EminentWare\WMI Providers\EminentWareExtensionProvider.exe"Csidl="38"/>
                                    <bar:FileExists Path="C:\ProgramData\Microsoft\Windows\Start Menu\Programs\EminentWare WMI Providers\Uninstall EminentWare WMI Providers.lnk"/>
                                  </lar:And>
                                </sdp:ApplicabilityRule>

                                 

                                 

                                Expected behaviour:

                                • If WMI Provider is installed and Shortcut is at the default location, the package triggers, executes and deletes the shortcut
                                • IF WMI Provider is installed and Shortcut is deleted, the packages assumes to be installed
                                Real behaviour:
                                • This package never triggers, no matter if there is a shortcut or not
                                  • Re: Thank you!  I found it.
                                    SolarWinds Community Team

                                     

                                    <sdp:ApplicabilityRule SchemaVersion="1.0">
                                      <lar:And>
                                        <bar:FileExists Path="EminentWare\WMI Providers\EminentWareExtensionProvider.exe"Csidl="38"/>
                                        <bar:FileExists Path="C:\ProgramData\Microsoft\Windows\Start Menu\Programs\EminentWare WMI Providers\Uninstall EminentWare WMI Providers.lnk"/>
                                      </lar:And>
                                    </sdp:ApplicabilityRule>

                                     

                                     

                                    So, the first step is to figure out which of these two rules is not returning the expected value. Also, for diagnostic purposes, it would be useful to guarantee that the Installed Rules always returns FALSE, so for testing, add a simple rule to the Installed Ruleset that you know will always return FALSE (e.g. Architecture = iA64).

                                     

                                    Then, define the Applicability Ruleset with one of these rules at a time. If the providers are installed and the link exists, the package should be reported as NotInstalled.  The objective here is to determine which of the above applicability rules is not behaving as expected.

                                     

                                    Also, be sure you're using current reported state to make these determinations. My suggestion would be to use the Computer Explorer | Windows Update Scan to test the client, then you don't have to be bogged down in detection/reporting/refresh cycles on the console. The absence of the package in the scan results is interpreted as a NotApplicable state; the presence of the package will report either NotInstalled or Installed.

                                     

                                    Finally, something I'll throw out here as a possibility -- I do not know that the FileExists rule treats LNK 'files' the same way it treats other files, and this may be the source of the issue. This thread, from a very long time ago, demonstrated an issue using the File.Exists() method in some C# code trying to validate the existing of a LNK file. http://bytes.com/topic/c-sharp/answers/737610-file-exists