UrbanCode Deploy agent must run as the root user and all scripts run as the root user
LDAP support limited to Tivoli Directory Server
In general, the process cannot be restarted (should always create a snapshot of the VMs before running any UrbanCode Deploy process)
Only one environment can be connected to a database server; otherwise, name conflicts and UrbanCode Deploy process concurrency issues can occur
Will not support multiple instances of any application
The context root of the CLM or CE application's URL cannot be changed from the default
All CLM and CE application tags are expected to match the context route of their URL
Known issues
In CLM 6.0 scripted JTS Setup fails intermittently when attempting to register TRS providers with LQE. If this happens then JTS Setup will need to be completed from the web UI at ../jts/admin.
If the SCP utility fails to copy files from the IHS server to any of the WAS servers then the QD script that runs SCP may fail without an error.
User must always run the Change Default User Parameters and Change Default LDAP Parameters process on each environment before running the Install Applications process. However, now the user can save their parameters for future use by following - Updating the Rational_QD_SystemPre-Requisite_60x* component
DB2 user name restrictions are not enforced by the Change Default User Parameters process
The Rational Requirements Management (RM) Converter application that renders the read-only view of RM graphical artifacts is installed but not configured. There was an issue discovered when deployed on RHEL 7+ so the war file will be present on the server but will not be configured in the WebSphere Application Server. Read tech note Requirements Management (RM) Converter application configuration and troubleshooting guide for detailed configuration instructions.
Under very specific conditions running a command as the db2inst1 user from within a UCD process can stop the DB2 database server when the UCD process step completes. We have seen this happen under the following conditions. For more details see section DB2 stopped examples.
The OS where the DB2 database server runs is RHEL 7.x
The Rhapsody/DM prerequisites and their dependencies have been installed
The UCD agent on the DB2 database server machine is running as a service instead of from the command line
DB2 stopped examples
Example 1
The QD UCD application process Install Applications is used to install the full package including DB2
The DBA needs to perform maintenance on the DB2 database server from the command line so the database is stopped and then started from the command line
Sometime later a process is run from UCD that does an su to the db2inst1 user and executes a command
The DB2 database server process will be stopped when the UCD step completes
Example 1 workaround
Either do not use UCD to manage the DB2 database server after the initial deployment or run the UCD agent on the DB2 database server machine from the command line and not as a service.
Example 2
The QD UCD application process Install Applications is used with a customer supplied DB2 database server.
If the DB2 database server process was started from the command line then it will be stopped after the Create Database DB2 step of the Install Applications process and the process will fail later on the Configure App step.
Example 2 workaround
The UCD agent on the DB2 database server machine must be run from the command line and not as a service.
Miscellaneous
Notes:
Throughout the IBM Quick Deployer wiki the screen captures are for reference only. In some cases if the functionality they display has not changed in the latest release they will be from a previous release
Deployment.IBMQuickDeployerLimitationsKnownIssuesOld moved from Deployment.IBMQuickDeployerLimitationsKnownIssues on 2017-08-04 - 14:28 by Main.ktessier -