Upgrade Considerations

Invalid Configuration Manager screens

When upgrading to LiveCycle ES4 from LiveCycle ES2, you can ignore the following Configuration Manager screens as they are no longer valid:

  • Copy crypto jars

  • Migrate ECM form templates

  • Migrate ECM form templates (Contd.)

Error when connecting to the database server

When upgrading to LiveCycle ES4 from LiveCycle ES2, clicking the Verify Connection button on the Adobe LiveCycle ES4 Database screen might return the following error:

Unable to connect to the database server. Communication link failure.Last packet sent to the server was 0 ms ago.

In this case, start the database manually and re-run LiveCycle Configuration Manager.

GDS directory not detected

If you are upgrading to LiveCycle ES4 using command-line interface, the upgrade-migrateGDS command may not detect the default GDS directory from your previous LiveCycle installation.

In this case, copy the GDS contents manually to the default GDS directory of your LiveCycle ES4 installation.

Content Services (deprecated) EAR fails to deploy during upgrade

Note: Adobe is migrating Adobe® LiveCycle® Content Services ES customers to the Content Repository built on the modern, modular CRX architecture, acquired during the Adobe acquisition of Day Software. The Content Repository is provided with LiveCycle Foundation and is available as of the LiveCycle ES4 release.

While upgrading to LiveCycle, deployment of the Adobe® LiveCycle® Content Services 9 (deprecated) EAR may fail with the following exception message:

SchemaBootstr E org.alfresco.util.LogUtil error Schema auto-update failed org.alfresco.error.AlfrescoRuntimeException: A previous schema upgrade failed or was not completed. Revert to the original database before attempting the upgrade again.

This issue occurs when the ALF_BOOTSTRAP_LOCK table is present in the LiveCycle database.

EAR deployment failure due to high WebSphere resource utilization

Content Services deployment may fail during upgrade if the WebSphere application server resource utilization is high.

To resolve this issue, perform the following procedures.

Restoring the contents of lccs_data and the database from backup

  1. Revert to the original Content Services database by restoring the tables beginning with alf and avm from the backup copy of the database.

  2. Restore the contents of the Content Store root location from the backup copy.

Increasing the total transaction lifetime timeout value

  1. In the WebSphere Administrative Console, click Servers > Server Types > WebSphere application servers and then click the server name.

  2. Click Container Settings > Container Services > Transaction Service.

  3. On the Configuration tab, set the value of the Total transaction lifetime timeout setting to 900 seconds.

  4. Click Apply or OK.

  5. Restart the application server.

Deploying the EARs in a different order

Initiate the upgrade again. Now, in Configuration Manager, deploy the Content Services EAR before deploying the other EARs.

  1. On the Deploy LiveCycle EARs screen, select adobe-contentservices.ear and then click Deploy.

  2. Once the Content Services EAR has deployed successfully, deselect adobe-contentservices.ear, select the other EARs, and click Deploy.

EAR deployment failure due to the ALF_BOOTSTRAP_LOCK database table

If the ALF_BOOTSTRAP_LOCK table is present in the LiveCycle database, Content Services EAR deployment may fail during upgrade.

To resolve this issue, follow these steps:

  1. Restore the contents of lccs_data and the database from backup. See EAR deployment failure due to high WebSphere resource utilization.

  2. Delete the ALF_BOOTSTRAP_LOCK table from the LiveCycle database and reinitiate the upgrade.

  3. Deploy the Content Services EAR and then deploy the other EARs. See EAR deployment failure due to high WebSphere resource utilization.

Content Services (deprecated) EAR file is not deployed to all nodes during upgrade

When upgrading to Content Services on a cluster, the Content Services EAR file is deployed to the first node but not to the other cluster nodes. The following two workarounds resolve this issue, but each has its drawbacks. Review each workaround to determine which is the best solution for your environment.

  • During upgrade, while configuring the Content Services EAR file using Configuration Manager, point the Index Root directory for LiveCycle to a location different from what was specified for the previous version of LiveCycle. This workaround allows you to start all the nodes in the cluster.

    Note: With this option, the LiveCycle server can take a long time to start up if you have a lot of content saved in the Content Services repository. This is because each node of the cluster attempts to recreate the indexes.
  • While deploying the EAR files, make sure that only one of the nodes of the cluster is started and specify the details pertaining to only that node during the entire upgrade process. This step ensures that the LiveCycle server only updates the indexes rather than recreating them.

    Once the node starts successfully, manually copy the indexes directory from that node to the other nodes of the cluster where you do not plan to run Configuration Manager. Now, start the other nodes of the cluster. The Content Services EAR file will now be successfully deployed to all cluster nodes.

    Note: Although this workaround is time-consuming to implement, it ensures minimal server downtime during startup.

LiveCycle ES4 Service Pack 1 fails to install

On upgrading from LiveCycle ES2 SP2 to LiveCycle ES4 SP1, LiveCycle configuration manager (LCM) encounters following errors

  • com.adobe.workflow.initializer.WorkflowInitializerException: java.lang.IllegalArgumentException: Comparison method violates its general contract!

  • java.lang.IllegalArgumentException: Comparison method violates its general contract!

To resolve the issue, add the following JVM argument in the generic JVM argument list of application server:


// Ethnio survey code removed