search cancel

One way to approach Disaster Recovery - Managing IP changes to the Automation Engine


Article ID: 89413


Updated On:


CA Automic Workload Automation - Automation Engine


One way to approach Disaster Recovery - Managing IP changes to the Automation Engine


Detailed Description and Symptoms

DISCLAIMER: The following article contains SQL statements.  Updating directly to or deleting directly from the Automic database is neither encouraged nor is it supported.  The running of queries against a production Automic system database is to be done at your own risk.  The queries in this article are to be run at your own risk and should not be run in a product Automic system without first knowing all consequences that may occur.   Automic is not responsible for any consequences that occur from running these statements.

A question that is asked a lot when considering Disaster Recovery or moving a data center where the Automation Engine application server is located is what needs to be changed in order for the agents and UserInterface to be able to re-connect to the system gracefully without much down time in the transition.  Below is one way of being sure that this can be done.


This assumes that fully qualified DNS names can be used and that the switchover is just a change of the DNS server pointing the name to a different IP address.
1) Since the DNS servers will be pointing to a different IP address for the server components, you will need to confirm that the DNS name is being used for the server components rather than an IP address.  You can find this by running the following query agains the database:
 select MQSRV_NAME, MQSRV_TCPIPADDR from mqsrv where mqsrv_type = 1;
MQSRV_TCPIPADDR should be a DNS name rather than an IP address. 
If they are a DNS name, only the UserInterface and Agent ini/config files will need to be checked (sections 3 and 4 below)
2) If they point to an IP address and those IP addresses become unavailable, the agents and UIs will be unable to re-connect to the system. 
The best way around this is to use the hostname= setting in the ucsrv.ini file(s).  More information on the hostname= setting can be found in the Automic documentation under Administration Guide, Configuration, Structure of the Configuration Files, Automic Automation Engines, Structure of the INI file.  When that change has been made, all WPs and CPs will need to be restarted (this can be done as a rolling restart, starting each process individually). 
3) Next, all agents will need to be checked to see if they have IP addresses in their [CP_LIST] section.  If so, they will need to be stopped, their [CP_LIST] section cleared out and then have them restart again.  Their ini files will also need to have their cp= setting changed to the DNS name if it is not already.  Their CP_LIST sections will be rebuilt at next startup of the agent (after the hostname= switch).
4) The same thing will need to be done for any UI connections via the uc4config.xml file.  They will need to be checked for ip addresses instead of DNS names and any IP addresses cleared out.  For example, the following entry would show IP addresses:
 <connection name="UC4_PROD" system="UC4_PROD">
   <cp ip="" port="2217"/>
   <cp ip="" port="2220"/>
   <cp ip="" port="2219"/>
   <cp ip="" port="2218"/>
the easiest way would be to change this to:
 <connection name="UC4_PROD" system="UC4_PROD">
   <cp ip="" port="2217"/>
This will be updated with a full list again at next connection to the system (after the hostname= change is made on the ucsrv.ini file) and should include only DNS names.