Dear all,
I don't see what I am doing wrong:
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
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.
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?
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 --
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".
delete
