Manual Agent Upgrade

Any user with the necessary authorizations can upgrade an Agent to a different version.

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.

This page includes the following:

Re-Authenticating Agents After an Upgrade

If you have Agents that are already authenticated using the authentication methods LOCAL or LOCAL-REMOTE and you want to upgrade them, you have to make sure that the initalPackage is still available as you have to authenticate the Agents again after the upgrade. For more information, see Agent Authentication.

This only applies to manual Agent upgrades. When you use the Centralized Agent Upgrade (CAU), the initialPackage is included by default.

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.

Make sure that you define the properties that are required to connect to the Java communication process (JCP) and to handle the relevant certificates in the respective Agent INI file.

These following properties are relevant:

  • TCP/IP

    connection =jcphost:8443

    Default value for the JCP connection.

  • [AUTHORIZATION]

    trustedCertFolder =./certificates

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

To start after the upgrade, the TLS/SSL Agent also requires the JCP certificate (jcp.cer) to connect to the Automation Engine. Make sure the certificate is available in the folder defined in the trustedCertFolder = parameter.

This applies to the following Agents:

Non-TLS/SSL Agents, such as BS2000, NSK, OS/400, VMS and z/OS require the TLS Gateway, which allows the file transfer between TLS/SSL and non-TLS/SSL Agents.

More information:

Agent List

The manual upgrade process itself does not differ from a new agent installation. All agents available are listed below. To see the instructions on how to install them please click the relevant link.

Note: Make sure you adapt the INI file of the respective Agent when you upgrade an Agent to its TLS/SSL version.

See also:

Centralized Agent Upgrade (CAU)