Installing the Agents Manually

This section guides you through the manual installation of on-premises agents. These agents can be used either for an on-premises Automic Automation system or an Automic Automic Automation Kubernetes Edition system.

Tip! This section contains information relevant for manually installed on-premises agents. If you are searching for information relevant to the containerized agent installation, see Installing Containerized Agents.

Overview

The Automation Engine and the Windows, UNIX, and Java Agents communicate using TLS/SSL. These agents establish a connection with the Java communication process (JCP), which uses trusted certificates to prove their identity to other communication partners.

Important! Make sure you are familiar with the TLS/SSL and certificate implementation before installing and/or upgrading the respective component. For more information, see:

When you used certificates signed by a CA, the certificates are stored in the respective Java or OS store by default; that is the Java trust store for Java components and Java Agents, the Windows OS store for Windows Agents, or the TLS/SSL store for UNIX Agents. In this case, you only have to check that the root certificates already are in the respective store.

If the relevant certificates are not there and you want to import them, you can use OS or Java specific tools for that purpose, such as Keytool, cert-manager, OpenSSL and such. For more information on how to use those tools, please refer to the respective product documentation.

If you do not want to use the default locations for the components and Agents listed above, make sure you use the trustedCertFolder=, agentSecurityFolder=, and keyPassword= parameters (if applicable) in the respective configuration (INI) file to define the path to the folder where the trusted certificates are stored.

Non-TLS/SSL Agents, such as BS2000, NSK, OS/400, VMS and z/OS, still connect to a communication process (CP) and use non-TLS/SSL encryption. The communication between a TLS/SSL and a non-TLS/SSL Agent can be established using the TLS Gateway.

More information:

Important! TLS/SSL Agents (in containers and on-premises) as well as the TLS Gateway, when used for the Automic Automation Kubernetes Edition, establish a connection to an ingress / HTTPS load balancer, which requires a certificate for authentication.

Make sure that address of the load balancer is defined on both sides: the Automation Engine and the Agent / TLS Gateway and that your HTTPS load balancer has the required certificates in place. For more information, see Connecting to AWI, the JCP and REST Processes Using an Ingress.

Non-TLS/SSL Agents, when used for the Automic Automation Kubernetes Edition, establish a connection to a TCP load balancer, which must be reachable for the Agent. The address of the load balancer must be defined on both sides: the Automation Engine and the Agent.

Notes:

  • Do not use blank spaces when naming the directories for the Automation Engine and the Agents. For more information, see https://support.microsoft.com/en-us/help/102739/long-filenames-or-paths-with-spaces-require-quotation-marks.

  • Check the compatibility matrix to see which version is compatible with your system. For more information, see Compatibility Information.

  • Agents running on Windows Server 2012 and higher versions: To avoid problems while executing actions (access denied), you should change the value of User Account Control: Run all administrators in Admin Approval Mode to Disabled in the Security Settings / Local Policies / Security Options section of the Local Security Policy application (secpol.msc). This ensures that the Windows Agent using the local Windows administrator account (although in the administrator group) can execute actions properly.

  • Additional installation steps are required before the Agent can be started and used if you intend to use one of the available authentication methods. For more information, see Agent Authentication.

This section includes the following pages: