Solarwinds WMI Provider 1.80.785.0 strange behavior

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.

Hi Garvin,

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.

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.

Here's a link to a KB article that describes the issue and Lawrence's workaround in more detail: http://knowledgebase.solarwinds.com/kb/questions/4238/.

Thanks.

Phil

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 1.72.218.2, 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