When attempting to deploy a robot to a discovered system in USM, the deployment may appear to halt at 50% and never recover.
Checking the remote server, the robot deployment may actually have succeeded, but USM does not acknowledge completion.
The cause of this is a corrupted file or files in the ADE folder structure which prevents deployment status from being updated appropriately.
The primary ADE sends the jobs to the remote ADE. The remote ADE keeps track of the job status, and also the primary ADE keeps track of the job status as well. The status is kept in the automated_deployment_engine.h2.db file on each ADE.
In this case the primary ADE's h2.db files had been corrupted and the ADE probe was not properly recording the status of the job, which caused USM to get stuck on 50% deployment even though robot was getting deployed.
The steps which we took to solve this problem can be taken again if the problem occurs again but we do not expect it to.
The steps are:
1. Stop the ADE probe on the remote hub and also the primary hub.
2. Open RDP sessions to the remote hub and also the primary hub.
3. Delete the following files -- some of them may not exist and that is OK but please delete all the ones which exist.
\Program Files(x86)\Nimsoft\probes\service\automated_deployment_engine\automated_deployment_engine.h2.db
\Program Files(x86)\Nimsoft\probes\service\automated_deployment_engine\automated_deployment_engine.h2.lock
\Program Files(x86)\Nimsoft\probes\service\automated_deployment_engine\automated_deployment_engine.h2.db (robot)
(In the case of Linux hubs, the files will have the same names, but be located in /opt/nimsoft/probes/service/automated_deployment_engine/)
After deleting all the files, start up the ADE probes and try the deployment again.
Note that this will remove the display of the previous deployment history in USM.
The first deployment after performing this operation may take an extra several minutes as the ADE probes re-sync their package data.