3 Replies Latest reply on May 23, 2012 4:05 PM by historicalshavlikemployee

    Hyper-V patch installs very slow

    Master
      Folks,
         I am using VMware vCenter Protect Essentials Government 8.0.0, Build 3878 to patch a Windows Server 2003 virtual machine (Hyper-V). The scan and deployment went fine but the actual patch installation is taking a looooong time. I started at 8:30 am yesterday and the patches are still installing. I have looked at the dplyevets.log file and found the following messages. How would you suggest I troubleshoot this?

           2012-05-22T11:38:42.9476250Z 086c E HttpDownload.cpp:990 Failed in SendRequest, error: Please verify your proxy setup is correct.
           Download with Proxy -  SendRequest failed with a return code of 12029
           Reason: Unknown error: 12029  If there are still questions please send log files to VMware support.
           2012-05-22T11:38:42.9476250Z 086c E HttpDownload.cpp:431 AttemptIEProxySession failed: . AttemptStraightSession failed: Please verify your proxy setup is correct.
           Download with Proxy -  SendRequest failed with a return code of 12029
           Reason: Unknown error: 12029  If there are still questions please send log files to VMware support.
           2012-05-22T11:38:42.9632500Z 086c E DplyEvts.cpp:99 class STWin32::CWin32Exception at PingBack.cpp:120: Please verify your proxy setup is correct.
           Download with Proxy -  SendRequest failed with a return code of 12029
           Reason: Unknown error: 12029  If there are still questions please send log files to VMware support: Unknown error: 12029
           2012-05-22T11:38:42.9632500Z 086c I DplyEvts.cpp:90 PingBack updates - tracker(https://150.101.60.198:3121/ST/Console/Deployment/Tracker/TrackerService) id(201) status(6).
           2012-05-22T11:38:42.9632500Z 086c W HttpDownload.cpp:498 IE Proxy not found - 2.

            



        • 1. Re: Hyper-V patch installs very slow
          Master
          If you are attempting to use a Distribution Server for the deployment, then the target machine will need to be able to successfully download the update files from the specified source. You may need to confirm the settings of the Distribution Server, including the credentials assigned in the 'Target machine connection to Distribution Server' section. You may also need to confirm that the target machine's Internet Options and WinHttp settings are correct (particularly if you have a Proxy server within the environment).

          We would also urge you to contact support directly for more immediate assistance with this issue. Support can be contacted via any of the methods indicated on the following page:

          http://www.shavlik.com/contact.aspx
          • 2. Re: Hyper-V patch installs very slow
            Master
            I am not using a Distribution Server. A laptop with VMware vCenter Protect Essentials sits on the network with the patches already downloaded from the internet. The patch files are sent to the VM and the patch process begins. It is just taking a long time for the patches to finish installation (started almost 32 hours ago and still running).

            The laptop and VMs do not have a proxy, just an ip address and subnet mask, this is an industrial control system with no internet access.

            Thanks
            • 3. Re: Hyper-V patch installs very slow
              Master

                   Again, we would urge you to contact support directly for more immediate assistance with this issue. This will allow us to collect important details regarding the issue, to aid in the collection and analysis of appropriate log data, and to assist you most effectively.

                   The question to answer is 'what indicator is being used to determine that the installations are not completing (or are delayed)'?

                   In an agentless deployment, once the console has successfully scheduled the deployment (as indicated on the console at the time of scheduling), the target machine processes the rest of the deployment job independently (the console does not 'actively monitor' the deployment). As the target machine processes the deployment, status updates are periodically sent to the console machine (via TCP 3121). If the key indicator is the statuses received by the console (or lack therof), this may be due to a communications or networking issue between the console and the target machine.

                   The updates are executed by the target machine's System account in an unattended mode. If a particular update fails during execution, no details will be displayed on-screen. If the update fails such that it does not end or abort correctly, it may also fail to return control to the deployment job (thus causing the job to stop processing). This typically requires identifying the 'problem' update, and executing it manually on the target in order to fully identify the reason for the failure.