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