Transitioning to Automic SaaS - Existing Agents

Transitioning from Automic Automation on-premises to Automic SaaS involves several steps. One of them is converting an existing Agent on your Automic Automation on-premises system to Automic SaaS. Converting an existing Agent allows you to retain custom settings in the INI file while successfully reconnecting the Agent. This topic explains how to do it and provides links to additional content on this subject.

The following list provides a high-level description of the procedure:

You have an Agent currently connected to your on-premises Automation Engine. Stop and disconnect it locally.
Reconnect the Agent to the SaaS environment so that operations can continue.
Modify some settings in the INI file manually.
Re-authenticate the Agent using the original Agent authentication key package so that the Agent can connect to the JCP.

This page guides you through the process of transitioning, re-authenticating and reconnecting your Agents.

Important!

You can use TLS/SSL Agents version 21 and higher with Automic SaaS, see Installing and Configuring Agents for Container-Based Systems.
To use GSS Agents, which are older Agents that are not TLS/SSL enabled, you must install the TLS Gateway to reach the JCP in the Kubernetes cluster through a TCP load balancer ,see TLS Gateway.
All systems hosting TLS/SSL Agents and the TLS Gateway require Java to support the TLS/SSL certificate based encryption and authentication and to support the Java version of the Linux x64 and Windows Agent, see Securing Connections to the AE (TLS/SSL), Installing the Agent for IBM AIX, Linux x64, and PowerPC 64 LE (Java), and Installing the Agent for Windows (Java).
For Automic SaaS, only the LOCAL authentication method is available, see Agent Authentication.

This page includes the following:

Converting an Agent from an On-Premises to a SaaS Environment

Transitioning existing Agents to SaaS,Transition process

Follow the process outlined in this section to successfully transition, re-authenticate and reconnect your Agents.

Create a new Agent object in Client 0 on the SaaS environment with the exact same name as the one on the on-premises environment so that you can later download the authentication key and authenticate the converted Agents. For more information, see Installing the Agents from the Automic Web Interface.

If you use the AE REST API, you do not need to create the new Agent in AWI.
Download the authentication key package, see Authenticating Agents and Withdrawing the Authentication.

When transitioning an existing Agent, one of the most important steps is getting the original authentication key package; otherwise, the Agent will not be able to connect to the JCP in the SaaS environment.

You will find the package in your download folder and you can store it anywhere in your system; you only need for the first connection.

Once the authentication key package is downloaded, you can remove the new Agent from the Administration perspective. You can, but you do not have to, as the converted Agent makes that connection automatically.

Note: As long as the AUTHENTICATION key of the UC_AS_SETTINGS variable is set to LOCAL, you can get the authentication key package using the authentication_package endpoint of the AE REST API. Since only the LOCAL authentication method is available for Automic SaaS, this should be the case. For more information, see UC_AS_SETTINGS - Advanced Security.

You can copy the strings that the endpoint returns to a text file called package.txt file. Make sure you remove the double quotes and substitute the \n with returns to have a clean block of text. Then place the file in the bin directory of the Agents and reference it in the INI files. You can use the same file for all Agents authorized for the Client.
Reconfigure the INI file. These are the parameters that you need to modify manually:
- system= : Set the name to the SaaS system name provided in the onboarding email.
- cp= : Clear the content of this parameter.
- connection= : Set the SaaS JCP endpoint provided in the onboarding email.
- initialPackage= : Set the path to new key package for the first connection.
- trustedCertFolder= : Clear the content of this parameter.
- keyPassword= : Clear the content of this parameter.
- [JCPLIST]/JCP1= : Set the SaaS JCP endpoint.
Important!
- Do not change the Agent name.
- Make sure that you change the system name to your Automic SaaS system name. For information about the relevance of the system name and the implications of changing it, see Getting Started with Automic SaaS for Administrators.
- Remove all references to CP connections as this might cause issues when connecting to SaaS.
Clear the bin/security directory. This directory contains certificate information. Make sure you remove all the files in the directory.

Once the Agent has been converted and authenticated, the TLS certificates will be generated to establish the connection.
Stop and disconnect the Agent in your on-premises instance and start the Agent in Automic SaaS, see Working with Agents.
You can either move the Agent to the non-zero Client now, or see if the transition was successful in Client 0 and then move it.
Re-authenticate the Agent, see Authenticating Agents and Withdrawing the Authentication.

Education

The Broadcom Software Academy provides a wide range of free online trainings. For information about how to navigate through the Academy and on how to register for courses, see Free Online Courses.

The following course(s) are associated with this topic:

Transitioning from Automic Automation On-Premises to Automic SaaS

Watch the Video

This course contains several videos. The following video within the course demonstrates how to convert an Agent from an on-premises environment to Automic SaaS: Watch the video: Transitioning from Automic Automation On-Premises to Automic SaaS - Existing Agents.