13 Replies Latest reply on Sep 28, 2012 9:35 AM by IGFCSS.DSI

    Solarwinds WMI Provider 1.80.785.0 strange behavior



      Yesterday I've upgraded my Patch Manager version to 1.80.785 with success. After that I've tried to upgrade the WMI Provider to the new version on my computer and another "Beta Tester" computer. I've published the update from the Solarwinds Catalog, declined the previous version and approved the new one to my test group. Run a wuauclt /detectnow on the computer and tried to install. It didn't...

      Tried to use "Update Management" to run the task, same result... Tried to use the "Check and Manage Computer Connectivity" and also the same result...


      The strange behavior is that the WMI Provider actually installed on one of my attempts (not sure which one) and is installed (SEE ATTACH FILE) but the computer is still trying to install it and is not installing other needed update (ex: Mozilla Firefox 15.0.1).


      Any ideas?


      PS: The print-screen show the "Control Panel -> Add and Remove Programs" where you can see that the WMI Provider is installed (small windows show version) and also shows the Windows Update Agent installation wizard trying to install it again.

        • Re: 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.

            • Re: Solarwinds WMI Provider 1.80.785.0 strange behavior
              Lawrence Garvin

              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.

                • Re: Solarwinds WMI Provider 1.80.785.0 strange behavior

                  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.

                    • Re: Solarwinds WMI Provider 1.80.785.0 strange behavior
                      Lawrence Garvin

                      The updated package was published to the catalog at 6:30pm CT yesterday.


                      I will check on the uninstallation of the previous version issue.

                        • Re: Solarwinds WMI Provider 1.80.785.0 strange behavior

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

                            • Re: Solarwinds WMI Provider 1.80.785.0 strange behavior
                              Lawrence Garvin

                              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.

                                • Re: Solarwinds WMI Provider 1.80.785.0 strange behavior

                                  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?

                                    • Re: Solarwinds WMI Provider 1.80.785.0 strange behavior
                                      Lawrence Garvin

                                      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

                                  • Re: Solarwinds WMI Provider 1.80.785.0 strange behavior
                                    Lawrence Garvin

                                    [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

                                • Re: Solarwinds WMI Provider 1.80.785.0 strange behavior
                                  Lawrence Garvin

                                  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.


                                  1 of 1 people found this helpful
                                  • Re: Solarwinds WMI Provider 1.80.785.0 strange behavior

                                    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/.





                                    1 of 1 people found this helpful