Centralized Agent Upgrade (CAU)

The Centralized Agent Upgrade (CAU) is an automatic, easy to use upgrade solution that allows you to upgrade your Agents to a different version.

If you need help, contact our support team. Our consultants are experts in upgrading AE systems and will be pleased to assist you whenever it is necessary. For more information, see Support.

This page includes the following:


Any user with the necessary authorizations can carry out a Centralized Agent Upgrade (CAU) in any Client of your system for the following Agents:

  • Windows


  • SAP

  • SQL

  • PeopleSoft

  • Rapid Automation (RA)

  • Intelligent Automation (IA)

  • TLS Gateway

For more information, see Installing the Agents Manually.

Since there is a switch between Agent versions at one point of the process, a real zero downtime is not possible.

The Agent resources (binaries) required for the CAU are attached to and delivered with Storage (STORE) objects. These Storage objects are delivered in Packs and are available for each released Agent version. You can download them from https://marketplace.automic.com/.


  • To import CAU pack versions older than the installed ones, make sure you delete the current CAU pack version first.

  • Make sure you also download Packs for the version from which you are upgrading, just in case you need to revert to it.

You can define a maximum size allowed for Packs using the PM_MAX_PACK_SIZE_MB key either in the UC_CLIENT_SETTINGS or in the UC_SYSTEM_SETTINGS variables. The value defined in the UC_CLIENT_SETTINGS variable overrides the value defined in the UC_SYSTEM_SETTINGS variable.

Once you have downloaded the relevant Packs, you have to install them in Client 0. You can install them from the Packs page in the Administration perspective which is only visible if the Plugin Manager is installed.

More information:


  • Make sure that the Packs you download and install for the CAU are from trusted sources. Users that have the authorization to conduct a CAU are potentially able to import malicious files as well.

  • Do not change the names of the objects that you download and install. The specific name pattern is used to identify the types and versions of the resources.

    If the names of these objects do not match the pattern, the Agent version is not displayed in the update list.

  • Do not change the content of the Agent resources (binaries). It is released by CA Automic and must not be altered.


  • It is not possible to carry out a Centralized Agent Upgrade (CAU) parallel to a Zero Downtime Upgrade.

  • Once an Agent is configured for a Centralized Agent Upgrade (CAU), it is no longer possible to upgrade it manually. After changing the version of an Agent manually, the Agent (together with the ServiceManager) updates/rolls back to the target version defined.

  • Please contact our support department if you need help reverting the status of an Agent after a CAU or perform a CAU to the latest version to avoid continuously repairing the Agent. For more information, see Support.

Upgrading from GSS to TLS/SSL Agents

As of this version, the communication between the AE and AWI as well as between the AE and the Windows, UNIX and Java Agents uses TLS/SSL through a secure WebSocket (WSS). These components establish a connection with the new Java communication process (JCP).

The Java communication process (JCP) uses trusted certificates to prove its identity to other communication partners and requires a keystore to work with these certificates. Therefore, you have to install and configure the new Java communication process (JCP) and make sure you have the required certificates.

The Windows, UNIX and Java agents can use different parameters in their corresponding INI file to define how to handle the certificates.

Note: The TLS/SSL implementation does not apply to the HP-UX and 32 bit ZLINUX Agents, as they are no longer supported in this version.

More information:

During the Centralized Agent Upgrade (CAU), the system adds additional properties to the respective Agent INI file, which are required to connect to the Java communication process (JCP) and to handle the relevant certificates.

The following properties are added:

  • TCP/IP

    connection = jcphost:8443

    Default value for the JCP connection.


    trustedCertFolder = ./certificates

    Path to the folder in which the trusted certificates are stored.

During the Centralized Agent Upgrade (CAU), the configuration value for the old cp= parameter (cp = host:port) is not removed from the INI file in case you have to perform a rollback. You can either ignore this parameter or remove it manually from the INI file.

To start a TLS/SSL Agent after the Centralized Agent Upgrade (CAU), the Agent also requires the JCP certificate (jcp.cer) to connect to the Automation Engine. This certificate is not part of the CAU Storage object but is added dynamically to the upgrade resources by the server. Upon starting, TLS/SSL Agents check the certificate folder defined in the trustedCertFolder = parameter, create the directory and move the jcp.cer certificate to that folder.

In the Automic Automation Kubernetes Edition, the JCP by default uses a generated, self-signed certificate within the Kubernetes cluster. When you migrate from an on-premises installation to AAKE and use the CAU to upgrade your Agents, they automatically receive the certificates from the JCP within the cluster. This means that the Agents cannot establish the connection to the cluster because they need to connect to an HTTPS load balancer and not the JCP directly. For more information, see Connecting to AWI, the JCP and REST Processes Using an Ingress.

However, you can use the CAU_INCLUDE_SERVER_CERTIFICATES parameter in the UC_SYSTEM_SETTINGS variable to stop the Automation Engine from automatically sending the server certificates to the Agents during CAU. For more information, see CAU_INCLUDE_SERVER_CERTIFICATES.

This applies to the following Agents:

For Agents not mentioned in the list above, see TLS Gateway and Installing the TLS Gateway.

See also: