Checking for Incompatibilities between Version 21.0.9 and 24.0.0

As a system administrator, you need to check incompatibilities between consecutive versions before upgrading your system.

The tables below lists new features that might lead to compatibility issues or should be taken care of when upgrading; they do not list all new features of this AE version. New features are described in full in the Release Highlights and Release Notes.

More information:

To provide a better overview, the tables are categorized by the severity of the issue. There are three different categories:

Critical: Issues that must be addressed, otherwise the system will not work
Behavior change: Functionality changes in existing features that might have an impact on your system
Advisory: Different issues you should be aware of but might not have an impact on your system

The columns display the following information:

Topic: Name of the general topic or new feature
Changed behavior: What has been changed
Possible incompatibilities: Impact the change may have
Actions/Countermeasures: What can be done to identify and/or remove possible incompatibilities

This page includes the following:

Compatibility Issues

Important! This version of Automic Automation introduces full Unicode / UTF-8 support. This implementation requires you to consider the following issues before upgrading:

ZDU is not supported for a first upgrade to version 24. You need to upgrade your system manually, see Upgrading an Automation Engine System Manually.
The AE DB must be migrated to UTF-8 before upgrading to version 24. Opting our is not possible, see Migrating the AE DB to UTF-8.

Note: If you use an MSSQL AE DB, make sure that the source database version is MSSQL Server 2017 or higher before migrating it. The Migration Action Pack does not support versions lower than 2017. The destination database has to be on version 2019 or higher to support UTF-8.
Before upgrading, all AE DB connection string encoding in the INI files must be adapted accordingly, see Automation Engine INI File.

Automic Automation

Critical

Topic	Changed Behavior	Possible Incompatibilities	Actions/Countermeasures
AE server processes and utilities check if AE DB is UTF-8 enabled	Version 24 requires a UTF-8 enabled AE database.	The server processes and utilities check if the encoding of the DB connection string in their INI file and the target database are properly configured for UTF-8. If not, they shut down immediately and a corresponding message is written into the log.	Make sure your database is UTF-8 enabled, see Migrating the AE DB to UTF-8

Behavior Change

Topic	Changed Behavior	Possible Incompatibilities	Actions/Countermeasures
UTF-8: New default for UC_HOST_CODE parameter definition	The default definition of the UC_HOST_CODE parameter in the INI file of the Windows and x64 Linux agents is UTF-8.	Using the wrong definition can cause data to be interpreted incorrectly.	Make sure you have the required definition. If you install a new Agent (with a new INI file) and your system requires you to keep using UC_CODE, make sure to change the new default value.
UTF-8: Variable names using "§"	In UTF-8, the "§" character is now a two-byte character.	Variable names including "§" might exceed the maximum length allowed and are no longer accepted as a valid script variable name.	Make sure that the variable name does not exceed the maximum length allowed.
UTF-8: UC_CRLF() script function	UC_CRLF() is handled as one UTF-8 character.	The UC_CRLF() script function returns a different value in UTF-8 than in a previous encoding.	Follow the instructions on the UC_CRLF script function documentation to derive CR and LF as single characters, see UC_CRLF.
UTF-8: PREP_PROCESS_FILE and WRITE_PROCESS script functions	Extended with a new encoding parameter for UTF-8.	These script functions have been extended with a new encoding parameter and might not lead to the expected results.	Check that these function have the intended setting and/or if the default setting still leads to the intended results, see PREP_PROCESS_FILE and WRITE_PROCESS.
TLS is default for the LDAP connection	Previously it was possible to configure whether a C-Modul or the JWP was used to enable LDAP logins. Now this is not configurable any longer and the JWP is always used by default. This is why the default value for TLS in UC_LDAP_EXAMPLE is Y now.	In installations that are using a non-TLS LDAP connection, LDAP does not work.	If you have a non-TLS LDAP connection, before upgrading, check your configuration in the TLS key in your UC_LDAP_EXAMPLE variable and add TLS=N if it does not already exist. See UC_LDAP_EXAMPLE - LDAP Connection Variable.
Java-based OS UNIX Agents	Job execution and folder permission	When performing an in-place upgrade of an OS Agent to a Java-based OS Agent, make sure that the permissions of the folder ./security are set correctly so that the user who executes the Agent has full access (R+W). Additionally, the user must have execute permission for all Agent's binaries. During a manual upgrade of an OS Agent (for example, V21 to V24) Java-based OS Agent no JOBS should be executed. Make sure no job is running when shutting down the "old" Agent.	Adapt permissions for folder and binary files Make sure that no job is executed before manually upgrading the Agent
New x64 Linux and Windows Java-based Agents	Passwords (keyPassword parameter of the [AUTHORIZATION] section of the INI file) are not obfuscated automatically when specified in clear text.	Passwords must be obfuscated manually.	Make sure you use the Utility to obfuscate the passwords. For more information, see Obfuscating Passwords.

Advisory

Topic	Changed Behavior	Possible Incompatibilities	Actions/Countermeasures
General DB change Note: Information and the checking instructions apply to all versions, between your existing installation and the latest you want to upgrade to, respectively.	The DB scheme/structure has been changed.	Custom SQL queries on AE DB do not work anymore.	Check and adapt relevant SQL/SQLI/SQLJOBS objects accordingly Check and adapt relevant DB queries used in external tools/programs
MSSQL Server version before AE DB Migration	The AE DB Migration Action Pack does not support MSSQL Server versions lower than 2017. The destination AE DB has to be on version 2019 or higher to support UTF-8.	If the source database is not version 2017 or higher, you cannot use the migration Action Pack.	Upgrade your existing MSSQL database to version 2017 or higher before migration. The destination database must be 2019 or higher to support UTF-8.
AIX 64 bit LibC runtime version	AIX 64 bit requires version 8 LibC runtime system libraries (libgcc8, libgomp8, libstdc++8)	If version 8 is not used, AIX does not work.	Make sure you are using version 8 LibC runtime system libraries.

Topic

Changed Behavior

Possible Incompatibilities

Actions/Countermeasures

General DB change

Note: Information and the checking instructions apply to all versions, between your existing installation and the latest you want to upgrade to, respectively.

The DB scheme/structure has been changed.

Custom SQL queries on AE DB do not work anymore.

Check and adapt relevant SQL/SQLI/SQLJOBS objects accordingly
Check and adapt relevant DB queries used in external tools/programs

MSSQL Server version before AE DB Migration

The AE DB Migration Action Pack does not support MSSQL Server versions lower than 2017.

The destination AE DB has to be on version 2019 or higher to support UTF-8.

If the source database is not version 2017 or higher, you cannot use the migration Action Pack.

Upgrade your existing MSSQL database to version 2017 or higher before migration.

The destination database must be 2019 or higher to support UTF-8.

AIX 64 bit LibC runtime version

AIX 64 bit requires version 8 LibC runtime system libraries (libgcc8, libgomp8, libstdc++8)

If version 8 is not used, AIX does not work.

Make sure you are using version 8 LibC runtime system libraries.

Automic Automation Kubernetes Edition

Critical

Topic	Changed Behavior	Possible Incompatibilities	Actions/Countermeasures
AE DB migration to UTF-8	When upgrading an AAKE instance, the DB secret containing the connection string has to be exchanged. This is required because a UTF-8 enabled database uses a different client encoding setting.	A UTF-8 enabled database might be connected using a non-UTF-8 encoding, which can cause data to be interpreted incorrectly. In case data is written, the data in the database might end up in a mixed and/or corrupt state.	Make sure you replace the corresponding AAKE secrets in your Kubernetes cluster before you upgrade your instance.