Sounds like a detection logic issue with the package. I notice the package as well, but I have not approved it yet for our computers. I spot checked several computers and show that the SolarWinds WMI Providers 1.80.785.0 is already installed on several computers already. The published package however, still shows that the computer needs the SolarWinds WMI Providers 1.80.785.0. I am sure once the detection logic is corrected then it should show the computers that already have the package installed will be detected as having it installed.
The current detection logic for installed SolarWinds WMI Providers 1.80.785.0 shows
HKEY_LOCAL_MACHINE\SOFTWARE\EminentWare\WMI Providers for the registry key for TargetDir
TargetDir is C:\Program Files\SolarWinds\Patch Manager\ on the workstations where the WMI is already installed.
The TargetDir should probably be C:\Program Files\SolarWinds\Patch Manager\WMI Providers since that is the location of the EminentWareExtensionProvider.exe
It should get updated shortly, I would not approve for more than your test group until the detection logic for installed rules gets squared away.
We are investigating the package specifications. Preliminary investigation suggests that we changed the physical installation location of the WMI Providers for v1.8, but did not properly set the corresponding registry value 'TargetDir' in HKLM\Software\EminentWare\WMI Providers. That value is initialized to %ProgramFiles%\SolarWinds\Patch Manager, but should be %ProgramFiles%\SolarWinds\Patch Manager\WMI Providers.
The syntactically correct 'fix' would be to update the registry key with the correct pathname. This has been tested in at least one installation and did provide the expected behavior, but this is not a practical solution across an entire enterprise of clients.
The other interim option is to duplicate the package and edit the SubPath value to be WMI Providers\EminentWareExtensionProvider.exe, and publish the modified package. I imagine this is the 'fix' we will implement and a corrected package should be available in the catalog soon.
Thank you for your quick reply. Has it is a minor change on the package specifications, I will wait for you Catalog update, which I except will be done on the next few days.
One other issue, the WMI provider is not uninstalling the "EminentWare" version 1.72.
The updated package was published to the catalog at 6:30pm CT yesterday.
I will check on the uninstallation of the previous version issue.
We seem to be having the same issue with this. All of our workstations are stuck re-installing the updated version of the WMI provider over and over again. It's creating a lot of email alerts and logs.
I see mention that an updated package was made available yesterday, but I'm not seeing anything yet. Should it show up as the same name/version number, or will it be a new package in the Solarwinds catalog?
One other thing somewhat related to this. I applied the Patch Manager to version 1.8 last week. I see mention here, and while setting up the WMI provider package for 1.8 of folders that do not exist on our server. Specifically, when looking for the package to upload to the server, the application tried to point me to C:\ProgramFiles\SolarWinds\Patch Manager\Server\Packages\Eminentware. However, I don't have a folder called SolarWinds at all under ProgramFiles. Everything on the system is still called Eminentware Extension Pack Console. Finding the executable files for the WMI installers was instead found under C:\Program Files\Eminentware\Server\packages\Eminentware.
Even the screenshots shown on the site look nothing like what we have. It looks like we started with version 184.108.40.206, and it still looks the same today as it did last spring when we initially installed. And like I said, I just ran the Patch Manager 1.8 updater last week.
Something doesn't seem right, and I'm wondering if it's part of the reason why I'm not seeing an updated version of the WMI Provider today. Any thoughts?
If you've synchronized since 7pm CT last night (9/19), you should have the newer package. You can confirm the package is the newest by inspecting the Installed Ruleset rule and confirming that the SubPath = 'WMI Providers\EminentWareExtensionProvider.exe'
Publish the revised package to WSUS, ensure the Revision is properly approved, and then launch a DetectNow from the clients with the installation issue.
Yes, I've synchronized a few times since last night. Looking at the package, it appears to have been updated, as can be seen in the screenshot attached.
However... it's still not working properly. It's reinstalling on every workstation. I completely removed the package and re-uploaded and approved it, with no luck.
Also, I still don't think the upgrade to 1.8 worked properly:
While at the same time:
Any thoughts on what I can try next?
Until the client systems actually execute a detection and see the revised package in WSUS, the behavior will not change -- so Approving the update is still early in the full cycle of remediation. Once the WUAgent sees the revised package, it should cache the revision and apply that logic and report the package as installed. This, of course, does presume that the package did successfully install. As is always the case, if the installation is failing, then the installation will continue to recur, so part of the process is confirming that there aren't any installation failures as part of the mix.
The revision number that is being evaluated can be identified in the WindowsUpdate.log. Obtain the UpdateID from the Patch Manager console Update Details tab, and search the WindowsUpdate.log for the UpdateID. The number to the right of the decimal after the UpdateID represents the Revision Number. For locally published updates, these are single-digit values starting with '1' and incrementing.
As for the Help -> About screen -- this is a known deficiency in the MMC, and the reliable way to get the product version is to use the "Version" link in the Actions Pane of the root node of the MMC console, as you've observed. This is discussed in this KB article: http://knowledgebase.solarwinds.com/kb/questions/4107
[LG Mod 9/21 @ 5:
15pm CT] I have edited this post to more accurately reflect reality. I made some assumptions in my original response that were not accurate, and I have deleted those incorrect statements from this post so as not to confuse any other persons who may read this at some point in the future.]
I did some further research on this issue, and discovered that the upgrade scenario for the WMI Provider package is problematic. The package, as written, or as revised, has some issues
in a scenario where Patch Manager has been upgraded from v1.7 to v1.8. When a v1.7 system is upgraded to v1.8, the installation folder is not migrated from %ProgramFiles%\EminentWare to %ProgramFiles%\SolarWinds\Patch Manager. As a result the WMI Providers package has an incorrect 'file download' location. A number of things are in the works to remediate this issue, and I should have additional information on this early next week.
Regarding the WMI Providers package, we've run the current package through a battery of test scenarios and my original assumptions about how the registry value impacted the package were incorrect, and we have not been able to reproduce any issues with Installation detection, or repeated reinstallations.
To that point, @blaing, we'd like for you to open a support ticket via the Customer Portal so that we can set up a GTM and get better detail on exactly what is occuring in your environment, because based on what I now know -- your observations are not expected behaviors of the package.
In versions 1.7x and earlier, the WMI Providers are installed to %ProgramFiles%\EminentWare\WMI Providers
In version 1.8, the WMI Providers are installed to %ProgramFiles%\SolarWinds\Patch Manager\WMI Providers
The above two statements are factual; however, my original explanation of what was happening wiith the package were incorrect. Here is a better assessment of what should be happening:
The Applicability Rules retrieve the installation folder of the current WMI Providers from the value "TargetDIr" in HKLM\Software\EminentWare\WMI Providers.
- If there are no WMI Providers installed then this key does not exist, the File Version rule passes (the file is less than the specified version), and Applicability Rules return TRUE (the package is needed).
- If the v1.7 WMI Providers are installed, the registry value returns C:\Program Files\EminentWare\WMI Providers, and the File Version rule passes, albeit not for the reasons we would expect, but because the file it's looking for: C:\Program Files\EminentWare\WMI Providers\WMI Providers\EminentWareExtensionProvider.exe is not there. So just as the package is needed when the WMI providers are not installed, they'll also be reported as needed in this case. The Applicability Rules return TRUE (the package is needed).
The package is then installed, and in the process of installing the v1.8 WMI Providers, the "TargetDir" is updated to C:\Program Files\SolarWinds\Patch Manager, semantically not the right folder, but we've now accounted for this anomaly in the revised package released on 9/20.
The Installed Rules retrieve the installation folder from "TargetDir" and because the v1.8 WMI Providers are installed in that tree (at C:\Program Files\SolarWinds\Patch Manager\WMI Providers\EminentWareExtensionProvider.exe), the Installed Rules should return TRUE and the package is reported as installed.
Ergo the fresh install vs upgrade scenario is not impacted by the WMI Provider installation itself, but that scenario does impact the fact that the package points to the wrong source location for the WMI Provider installer when upgrading from v1.7 to v1.8, as blaing observed.
Message was edited by: Lawrence Garvin 9/21/2012
For what it is worth, after the update it looks like it is now showing up correctly in our environment.
I still have the problem that first made me open this thread and I agree with LGarvin, this issue needs further investigation. Should I open a support ticket via the Customer Portal?
1 of 1 people found this helpful
Regarding the apparent uninstallation of the older providers:
The providers are being uninstalled (in fact, it's impossible for multiple versions to co-exist on the same system), but a defect in the InstallAware that is being used for v1.8 fails to remove this item from the installed list. If you click on the entry in ARP or P&F, it will recognize the product is not installed and remove the entry from the list.
You can also do this across the enterprise by launching an Uninstall Program action from Computer Explorer | Installed Software.