6 Replies Latest reply on Oct 10, 2012 3:59 AM by VáclavSáblík

    WMI Providers upgrade/new install fails after 1.80.785.0 upgrade

    russo1203

      We just upgraded our servers to Patch Mnager 1.80 and since have not been able to upgrade the WMI providers nor do a new automatic installation. I have verified that automatically installing is configured. When attempting to connect to a computer via Computer Explorer, the following is received:

       

      Source: Data Grid Server (PMServer)

      Device: machine.name.com

      Details: Although we successfully connected to machine.name.com, we were unable to install the EminentWare WMI providers.

      Details: Field not found: 'EminentWare.RemoteInstallationClient.Installer.eOPT_INSTALL'.

      Exception occurred at 10/8/2012 4:46:54 PM: Field not found: 'EminentWare.RemoteInstallationClient.Installer.eOPT_INSTALL'.

       

      As mentioned in the error, the connection is made and the results are provided, Installed Software in this case, but the upgrade/install fails.

       

      The account used has the correct access and again I have confimred auto install is enabled.

       

      Thank you.

        • Re: WMI Providers upgrade/new install fails after 1.80.785.0 upgrade
          VáclavSáblík

          Hello,

          This issue is very strange and frankly I'm surprised with this kind of exception related to this particular functionality. There is, however, not enough details that would allow us to get to the root cause from your description.

           

          Please go ahead and open a support ticket. Also I'd be interested if re-installing providers manually on the device would allow computer explorer to connect.

           

          Thanks,

          Vaclav

          • Re: WMI Providers upgrade/new install fails after 1.80.785.0 upgrade
            russo1203

            Update... After further investigation I have found that our Primary Application Server is unable to communicate with the Application Server resposible for our Secondary Mangement Group.

             

            • When viewing the Management and Application Server Monitoring Tab under the Patch Manager System Configuration> Patch Manager Servers> ApplicationsServers node, there is an access denied message.
            • Additionally, errors are received when attempting to view Managed Computers from the PAS, message received is that there are no Management Servers available for Management Group.
            • I also found that the certs do not match on the 2 servers, the PAS has 2 2048 bit certs with a validity date starting on the day of the upgrade, and the Secondary still shows 512 bit certs.
            • However, the logs on the Secondary server shows that the certs were added and ACLed.
            • I have also verified that machines reporting into the PAS are being updated with the correct providers.

            So, I believe my issues are all related. So my new questions is, what is the best way to update the certs on the Secondary Server?

            Can they be exported and imported?

            Should the server be removed and readded?

            I did attempt to run setuphelper /reprovsioncertificates, but this failed. The message received advised that it was not a valid command.

             

            Any assistance would be greatly appriciated.

              • Re: WMI Providers upgrade/new install fails after 1.80.785.0 upgrade
                VáclavSáblík

                Running the command "setuphelper.exe /reprovsioncertificates" on the secondary application server is correct approach.

                 

                I see three possible problems here:

                 

                1) You have a typo on you command line statement but it might be wrong just in this post, if so that skip #1.

                2) Can you confirm you've run update package on the SAS manually and did not used push install to update the infrastructure at once? Since there is a certificate reprovisioning this option is not available for this particular update. If you've run update package manually on PAS and then on all other servers skip #2

                3) If setup helper does not know this option (on SAS), it might be that update went wrong and binaries are not correct. Can you double check file version of SetupHelper.exe? It should be 1.80.785.0.

                 

                If binaries version are wrong, I'd run the update package (on SAS) and check to force file copy. Then in the end, scroll the messages list and take a look if certificates provisioning succeeded.

                  • Re: WMI Providers upgrade/new install fails after 1.80.785.0 upgrade
                    russo1203


                    Thank you for the reply.

                     

                    1. Yes, that was a typo in my post.

                    2. Yes, the updates were run manually on both servers.

                    3. The version for the SetupHelper.exe is 1.71.201.0

                     

                    I attempted to rerun the update package as you suggested but received the attached message.

                     

                    Thank you again.

                      • Re: WMI Providers upgrade/new install fails after 1.80.785.0 upgrade
                        russo1203

                        I located the correct version of the setuphelper file and ran the command, however, it was in the Console directory, not the Server directory.

                        The following appears in the log:

                        Reprovisioning EminentWare Server with PAS called ProvisionSoftware and succeeded
                        2012/10/09 13:10:52:373 PID: 6808 TID: 5276 Reprovisioning EminentWare Server with PAS CA deviceid is: 4434d1c9-a0ce-4249-bb0a-d06fda6fc132
                        2012/10/09 13:10:52:373 PID: 6808 TID: 5276 Reprovisioning - Opened store for local machine to add EminentWare CA certificate.
                        2012/10/09 13:10:52:389 PID: 6808 TID: 5276 Reprovisioning - Opened store for local machine and added successfully the EminentWare CA certificate with ID: 4434d1c9-a0ce-4249-bb0a-d06fda6fc132
                        2012/10/09 13:10:52:389 PID: 6808 TID: 5276 Reprovisioning - Successfully wrote the EminentWare CA certificate with ID: 4434d1c9-a0ce-4249-bb0a-d06fda6fc132 to the registry.
                        2012/10/09 13:12:00:751 PID: 6808 TID: 5276 An error occurred while trying to provision the Patch Manager software.

                        The specified network password is not correct.

                         

                        Is it possible that I do not have appropriate permissions?

                        I am an administrator on both servers.

                        My account is also an EminentWare Enterprise Administrators role.

                        Can I not manually import the certs?

                        Thank you.

                          • Re: WMI Providers upgrade/new install fails after 1.80.785.0 upgrade
                            VáclavSáblík

                            The version 1.71.201.0 is wrong and it means this file was not replaced by update. I can't tell why but from the screen you've posted it seems like registry value claims already updated version. Running setup helper from console directory will not fix the problem since it is the server you need to provision.

                             

                            I assume you've been running the full installer that gives you just uninstall option when up-to-date version is detected. However, if you will download just the update package from customer portal, that one I was referring to. This package will let you to force the update and should correct file versions and certificates.

                             

                            Regardless of what I've said I would strongly recommend to contact SolarWinds support because your installation seems to be inconsistent and there can be more issues hiding under the surface. I'm sure that our support will be happy to assist you with getting you environment corrected.

                             

                            Thanks,

                            Vaclav