Deploying Windows robots from UIM - key notes and tips
Article ID: 130845
Updated On:
Products
DX Infrastructure Management
NIMSOFT PROBES
Issue/Introduction
Need guidance on how to successfully deploy Windows robots to hubs/customer hubs
Cause
- Environmental considerations/configuration
Environment
- UIM 8.5.1 or higher
Resolution
To install a Robot to a Windows system with ADE, the automated_deployment_engine (ADE) must be installed on a Windows OS. The recommended solution is that ADE be installed on a Windows hub that the robot reports to.
To use ADE from UMP USM portlet, ADE must installed on the remote hub that the robot will be reporting to.
***Note that If the target machine is a Windows box, then the hub MUST be a Windows HUB as well.***
If ADE is installed on a Windows robot you can use the xml file on the ADE server to deploy to Windows servers.
Please review the help documentation below:
https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/it-operations-management/unified-infrastructure-management/9-0-2/installing/deploy-robots/bulk-robot-deployment-with-an-xml-file.html
The ADE probe on the Primary hub 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.
If the Primary ADE's h2.db files become corrupted and the ADE probe was not properly recording the status of the job, this may cause USM to get stuck on ~50% deployment even though robot could be getting deployed.
To try and resolve this 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)
After deleting all the files, start up the ADE probes and try the deployment again.
To use ADE from UMP USM portlet, ADE must installed on the remote hub that the robot will be reporting to.
***Note that If the target machine is a Windows box, then the hub MUST be a Windows HUB as well.***
If ADE is installed on a Windows robot you can use the xml file on the ADE server to deploy to Windows servers.
Please review the help documentation below:
https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/it-operations-management/unified-infrastructure-management/9-0-2/installing/deploy-robots/bulk-robot-deployment-with-an-xml-file.html
The ADE probe on the Primary hub 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.
If the Primary ADE's h2.db files become corrupted and the ADE probe was not properly recording the status of the job, this may cause USM to get stuck on ~50% deployment even though robot could be getting deployed.
To try and resolve this 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)
After deleting all the files, start up the ADE probes and try the deployment again.
Additional Information
- All appropriate firewall ports and Windows shares must be configured to allow remote WMI and DCOM connections. These ports are normally open and available on a default Microsoft Server installation.
- Robots for Windows systems must be deployed from Hubs running Windows. Installing a Windows Robot from a Linux hub is NOT supported. You cannot deploy a robot to a Windows system from a Linux hub. If you deploy a Windows hub and then deploy a Windows Robot, if necessary you can move it into another hub/origin, e.g., Linux hub.
Please refer to:
Deploy Windows robot from Linux hub
https://knowledge.broadcom.com/external/article?articleId=74014
- The source system and target systems MUST also be in the SAME Windows DOMAIN, unless the target systems are in the default Windows domain 'workgroup.'
- You must have local administrative privileges on the target systems. In addition, the user who is listed in the host-profiles.xml for your target Windows systems must have remote access and remote execution privileges. We recommend that this user is an administrator.
- Make sure the password is correct for the remote Windows system in the XML file for the administrator user
- In the XML file, make sure the hubname matches the actual hub name and note that it is case-sensitive.
Notes on the ADE probe queue:
- You don't need to manually create the queue for ADE.
- The messages will be processed in temp queues if needed. The ADE_archive_sync Subject is used on the backend. Queues for this subject do not need to be manually generated.
Please refer to:
Manually created queue for AutomatedDeployment subject
https://knowledge.broadcom.com/external/article?articleId=124382
- Robots for Windows systems must be deployed from Hubs running Windows. Installing a Windows Robot from a Linux hub is NOT supported. You cannot deploy a robot to a Windows system from a Linux hub. If you deploy a Windows hub and then deploy a Windows Robot, if necessary you can move it into another hub/origin, e.g., Linux hub.
Please refer to:
Deploy Windows robot from Linux hub
https://knowledge.broadcom.com/external/article?articleId=74014
- The source system and target systems MUST also be in the SAME Windows DOMAIN, unless the target systems are in the default Windows domain 'workgroup.'
- You must have local administrative privileges on the target systems. In addition, the user who is listed in the host-profiles.xml for your target Windows systems must have remote access and remote execution privileges. We recommend that this user is an administrator.
- Make sure the password is correct for the remote Windows system in the XML file for the administrator user
- In the XML file, make sure the hubname matches the actual hub name and note that it is case-sensitive.
Notes on the ADE probe queue:
- You don't need to manually create the queue for ADE.
- The messages will be processed in temp queues if needed. The ADE_archive_sync Subject is used on the backend. Queues for this subject do not need to be manually generated.
Please refer to:
Manually created queue for AutomatedDeployment subject
https://knowledge.broadcom.com/external/article?articleId=124382
Feedback
Yes
No
Powered by
