Known issues

This topic describes the known issues and limitations for Deployment Automation.

Install and upgrade

Upgrading agents on Java 6 or 7 isn't supported from the user interface.

Deployment Automation doesn't support the upgrade of Java 6 and 7 agents from the user interface.

Workaround: Use the 6.3.2 server to upgrade agents and agent JREs, or contact Support for assistance.

Agent installer stops responding on AIX when finished.

When installing an agent in silent or console mode on an AIX system, the installer may stop responding when finished.

Solution: You can safely close/stop the installer. Your agent installation is complete.

Server installer stops responding on AIX when finished.

When you run the DA server installer on a heavily loaded AIX system, the installation wizard may not finish cleanly and may stop responding while displaying this message:

The InstallShield Wizard has successfully installed Deployment Automation. Choose Finish to exit the wizard. Press 3 to Finish or 5 to Redisplay [3]

Solution: Ignore the message and close/stop the installer. Your server installation is complete.

Upgrade to Deployment Automation 6.3.3 or later: Agent relays may be displayed with incorrect status and version after upgrade.

After you upgrade the server to version 6.3.3 or later using the interactive installer, the agent relay may be displayed with the incorrect status and version in the Deployment Automation user interface.

Solution: After upgrading the server, ensure that the agent relay is stopped, upgrade the relay, and start it. Then restart Common Tomcat.

Server upgrade from 6.3.1 to 6.3.2 and then to 6.3.3 or later on Windows: Common Tomcat may become corrupted because of extra comment tags in server.xml.

If you upgraded the server from 6.3.1 to 6.3.2 and then to 6.3.3 or later on Windows using the interactive installer, Common Tomcat may become corrupted because of duplicate comment tags in the server.xml file.

Solution: After upgrading to 6.3.3 or later, remove extra comment tags next to the connector port 8409 block in server.xml. Change the opening tag from <!-- <!-- to <!-- and the closing tag from --> --> to -->. Save the changes and restart Common Tomcat.

32-bit Windows NT 5.2 or earlier: Agents do not run with JRE 1.8.0_251 or later.

Deployment Automation 6.3.3: On 32-bit Windows NT 5.2 or earlier, Deployment Automation agents do not work with JRE 1.8.0_251 or later because of Java limitations. The agent's JRE cannot be upgraded to use JRE 1.8.0_265 bundled with the installation files.

Solution: Use JRE 1.8.0_250 or earlier.

Running Deployment Automation installer on CentOS.

To run the DA installer on a minimal CentOS, run this command in a terminal:

yum install bc

z/OS agent cannot be upgraded from server. The z/OS agent cannot be upgraded from the Deployment Automation server.
Deployment Automation 6.1.1 and later: Agents may not come back online after server upgrade.

Due to changes to supported security protocols starting in version 6.1.1, Deployment Automation agents using earlier versions of Java, such as Java 6, may not be allowed to connect to the server after the upgrade.

If your agents do not come online after the server upgrade, upgrade them by following the instructions in Knowledge Base item S141622.

Installer page disappears when installing the agent on RedHat 7.3 that uses the Adwaita theme. If you are using the RedHat 7.3 with the Adwaita theme and try to install the Deployment Automation agent, the installer page disappears and you cannot complete the installation. This is due to the fact that the Adwaita theme is missing some objects used by installer. This works fine with other themes, such as Oxygen. For details on changing the theme, see Knowledge Base item S142064.

Back to top

General functionality

Deployment Automation 6.3.4 on UNIX: The server doesn't start if Common Tomcat is started from the root directory.

The Deployment Automation 6.3.4 server on UNIX doesn't start if you attempt to start the stopped server service from the root directory.

Workaround: Change to the Common Tomcat's /bin directory and run the startup script: startup.sh.

AIX agent installed with the Use Existing Java option may fail processes with parallel steps of the same plugin.

If you install an AIX agent 6.3.3 or later with the Use Existing Java option (java 1.8.0_181), and employ the agent to run a process that contains parallel steps of the same plugin, the process may stop responding, and large dump files may be created in the <agent>/core/var/work directory as a result.

Solution: Remove dump files and rerun the process. To avoid the issue, we recommend using the Java version bundled with your version of the Deployment Automation agent.

Version import for Nexus Sonatype components is no longer working.

In Deployment Automation 6.3.2 and later, Nexus Sonatype no longer cuts off parts of the server URL. If you have used a URL with a relative path, the relative part now remains intact.

For example, in earlier versions, Nexus Sonatype converted the http://localhost:8080/nexus path into http://localhost:8080.

After upgrading to version 6.3.2 or later, you may need to reconfigure the components that use Nexus Sonatype as a source config type.

Replication import may fail on Oracle.

If replication import fails on Oracle with the error ORA-01000, the maximum open cursors limit has been exceeded. To change the limit on the database side, run this SQL query:

alter system set open_cursors = <limit_number>;

uBuild source configuration type not supported.

Starting from Deployment Automation 6.3, uBuild is no longer supported.

Workaround: Use the Deployment Automation API to develop your own plugin for uBuild.

Back to top

Plugins

ChangeMan ZMF and WL Deploy plugins not supported with Java 11.

Agents on JRE 11 do not support the ChangeMan ZMF plugin and Oracle WebLogic WLDeploy plugin.

Workaround: To run processes with ChangeMan ZMF and WL Deploy plugin steps, use a JRE 8 agent, or contact Support for assistance.

Back to top

Integrations

Deployment Automation 6.3.4 and SBM 11.8/12.0: SBM SSO logout error when logging out of Deployment Automation.

When you log out of Deployment Automation 6.3.4 as an SBM 11.8 or 12.0 SSO user, the logout from SBM may fail.

For an SBM 12.0 SSO user, the following SBM error may be displayed:

CSRF token from HTTP request does not match with expected value

Workaround for SBM 12.0 SSO: Disable the CSRF token requirement in the fedsvr-core-config.xml file in your SBM 12.0 installation location:

  1. Open the fedsvr-core-config.xml file in the SBM Tomcat's WEB-INF\conf directory, for example:

    <SBM installation location>\Common\tomcat\server\default\webapps\idp\WEB-INF\conf\fedsvr-core-config.xml

  2. In the fedsvr-core-config.xml file, disable the CSRF token requirement by changing the AllowLogoutWithoutCSRFToken parameter to true.

  3. Restart SBM Tomcat.

Error configuring the ALM Solutions Connector 6.1.3 services when running encrypt.cmd to encrypt the almsernet properties.

When configuring the ALM Solutions Connector almsernet service, if you run encrypt.cmd to encrypt the almsernet_resource.properties files, the following error message is displayed:

Could not find or load main class com.serena.sernet.httpserver.util.Encrypt

Workaround: Edit the ..\webapps\almsernet\WEB-INF\encrypt.cmd file and change almsernet-8.1.0.jar to almsernet-8.1.2.jar.

Back to top

Browsers

Deployment Automation 6.3.3: Internet Explorer 11 displays HTTP error messages as generic friendly error messages.

If an HTTP error message is short, Internet Explorer 11 displays it as a generic friendly error message, making it difficult to troubleshoot the issue.

Solution: Disable the Show friendly HTTP error messages option in Internet Explorer's Internet Options > Advanced.

The user interface is not updated in Internet Explorer 11 after server upgrade.

When you have upgraded the server from version 6.2.2 or earlier to version 6.3.0 or later using the interactive or silent installation methods, and you open Deployment Automation in Internet Explorer 11, an old version of the user interface is displayed.

Solution: Refresh the page to update the user interface.

Back to top

Connection issues

Connecting Java 8 agents to the 6.4 server using the TLS 1.3 protocol.

To connect a Java 8 agent to the latest server via the TLS 1.3 protocol, ensure that the agent uses Java version 8_371 or later. Earlier Java 8 versions do not support TLS 1.3.

Connecting a 4.5.1 agent to aDA server 6.3.2 or later through HTTPS.

To connect a 4.5.1 agent to a 6.3.2 server through HTTPS, first manually upgrade the agent's JRE to version 1.8.

If the agent was installed with the bundled JRE, open the /jvm directory on your agent and replace all its contents with JRE 1.8 files.

Deployment Automation has limited support for IPv6 IP addresses.

If you are using IPv6 IP addresses on your network, you must use host name instead of IP address in Deployment Automation agent or agent relay configuration.

The following known issues exist for IPv6 addresses:

  • If you use IPv6 IP addresses in agent or agent relay configurations, you must use brackets around the address and with the colon character (:) escaped with a backward slash (\), for example, [fc00\:\:a1f\:2007].

    If you do not do this, the agent or relay does not connect and an error similar to the following message is displayed in the log:

    java.lang.IllegalArgumentException: hostname can't be null

  • If you run a process using the agent or agent relay configured using an IPv6 address, the process fails.
When a large number of agents are moved from one unidirectional agent relay to another, agents 6.1.1 and earlier may not automatically appear online.

When a large number of agents are changed to point to a different unidirectional agent relay, agents 6.1.1 and earlier may not come online automatically. They may be listed as CONNECTED or OFFLINE.

Solution: To bring agents online, click the Test icon in the Agents / Pools pane, or restart the agents.

Back to top

See also: