AEM 6.4 to 6.5

What: Process to upgrade from 6.4 to 6.5

When: Performed at the request of the front-end team

Adobe Documentation

• Top-level Upgrade Procedure

Prior to Upgrade

• [x] Filesystem Backup
• [x] Refresh Procedure if upgrading non-prod tiers so that you stay in sync with prod tier

The overall upgrade process in a diagram:

First of all, run the Pre-Upgrade Maintenance Tasks.

Step-by-step guide (Just key steps)

Configure Workflow and Audit Log Purging

The WorkflowPurgeTask and com.day.cq.audit.impl.AuditLogMaintenanceTask tasks require separate OSGi configurations and cannot work without them. If they fail during pre-upgrade task execution, missing configurations is the most likely reason. Therefore, make sure to add OSGi configurations for these tasks or remove them altogether from the pre-upgrade optimization tasks list if you do not wish to run them. Documentation for configuring workflow purging tasks can be found at Administering Workflow Instances and audit log maintenance task configuration can be found at Audit Log Maintenance in AEM 6.

Install, Configure, and Run The Pre-Upgrade Tasks

Pre-upgrade maintenance tasks are currently spread over various interfaces which are partially or entirely performed manually. The pre-upgrade maintenance optimization introduced in AEM 6.3 enables a unified way to trigger these tasks and be able to inspect their result on demand.

In AEM 6.3 and later, the pre-upgrade maintenance optimization tasks come included in the quickstart jar.

How to Use It

The PreUpgradeTasksMBean OSGI component comes preconfigured with a list of pre-upgrade maintenance tasks that can be run all at once. You can configure the tasks by following the below procedure:

1. Go to the Web Console by browsing to https://serveraddress:serverport/system/console/configMgr
2. Search for “preupgradetasks”, then click the first matching component. The full name of the component is com.adobe.aem.upgrade.prechecks.mbean.impl.PreUpgradeTasksMBeanImpl
3. Modify the list of maintenance tasks that must be run as shown below:

Finally, save the changes.

Default Configuration of the Pre-Upgrade Health Checks

The PreUpgradeTasksMBeanImpl OSGI component comes pre-configured with a list of pre-upgrade health check tags to execute when the runAllPreUpgradeHealthChecks method is called:

1. system - the tag used by the granite maintenance health checks
2. pre-upgrade - a custom tag that could be added to all the health checks that you can set to run before an upgrade

The list is editable. You can use the plus (+) and minus (-) buttons besides the tags to add more custom tags, or remove the default ones.

Run RevisionCleanUpTask and AuditLogMaintenaceTask

As shown below on the diagram, run thess two tasks (Workflow Purge and AuditLog Maintenance Task) by clicking on the run

This can be accessed under weekly maintenance, for example URL: https://cmsa-dvlp-01.db.vt.edu/libs/granite/operations/content/maintenanceWindow.html/apps/settings/granite/operations/maintenance/granite_weekly

If any of these fails, do this:

Workflow Purge Issue:

Go to the Workflow Purge configuration page and configure it as shown on the screenshot below: (DVLP example URL: https://cmsa-test-a-01.db.vt.edu/system/console/configMgr/com.adobe.granite.workflow.purge.Scheduler)

Save the changes, and then go back and run the task again.

AuditLogMaintenaceTask Issue

Go to the AuditLog Maintenance Task configuration page and configure it as shown on the screenshot below: (DVLP example URL: https://cmsa-test-a-01.db.vt.edu/system/console/configMgr/com.adobe.cq.audit.purge.Pages)

Save the changes, and then go back and run the task again.

Execute Offline Revision Cleanup

Note: This step is only necessary for TarMK installations

If using TarMK, you should run Offline Revision Cleanup before upgrading. Doing so makes the repository migration step and subsequent upgrade tasks execute much faster and helps to ensure that Online Revision Cleanup can execute successfully after the upgrade has completed. For information on running Offline Revision Cleanup, see Performing Offline Revision Cleanup.

Run Pre-upgrade Healthcheck

The managed bean functionality can be accessed using the JMX Console.

Before runnning this pre-upgrade healthcheck, make sure you have disabled all replication agents otherwise, it is going to fail.

You can access the MBeans by:

1. Going to the JMX Console at https://serveraddress:serverport/system/console/jmx (example URL: )
2. Search for PreUpgradeTasks and click the result (example URL: https://cmsa-dvlp-01.db.vt.edu/system/console/jmx/com.adobe.aem.upgrade.prechecks%3Atype%3DPreUpgradeTasks)
3. Select runAllPreUpgradeHealthChecks from the Operations section and select Invoke in the following window.

A successful healthcheck run should show all successful shown above. This will output this file, preUpgradeHCStatus.properties, in the root directory of the crx-quickstart directory with the following content:

Note: It is very important to get a 'true' value on the healthcheck run to ensure that AEM upgrades successfully and smoothly.

Performing an In-Place Upgrade

Migration Prerequisites

1. Minimum Required Java version: The migration tool only works with Java versions 7 and up. Note that for AEM 6.3 and up, Oracle’s JRE 8 and IBM’s JRE 7 & 8 are the only supported versions.
2. Upgraded Instance: If you are upgrading from a version older than 5.6, make sure that you have performed an in-place upgrade to AEM 6.0 by following the procedure described in the 6.0 version of the Upgrade documentation.

Preparation of the AEM Quickstart jar file

1. Stop the instance if it is running.
2. Download the new AEM jar file and use it to replace the old one outside the crx-quickstart folder.

3. Unpack the new quickstart jar by running:

   java -Xmx4096m -jar aem-quickstart.jar -unpack

Performing The Upgrade

Determining the correct upgrade start command

To execute the upgrade, it is important to start AEM using the jar file to bring up the instance. For upgrading to 6.5, please also see other content restructuring and migration options in Lazy Content Migration that you can choose with the upgrade command.

Note that starting AEM from the start script will not start the upgrade. Most customers start AEM using the start script and have customized this start script to include switches for environment configurations such as memory settings, security certificates, etc. For this reason, Adobe recommends following this procedure to determine the proper upgrade command:

1. On a running AEM instance, execute the following from the command line: ps -ef | grep java
2. Look for the AEM process. It will look something like: /usr/bin/java -server -Xmx1024m -Djava.awt.headless=true -Dsling.run.modes=author,crx3,crx3tar -jar crx-quickstart/app/cq-quickstart-6.5.0-standalone-quickstart.jar start -c crx-quickstart -i launchpad -p 4502 -Dsling.properties=conf/sling.properties
3. Modify the command by replacing the path to the existing jar ( crx-quickstart/app/aem-quickstart*.jar in this case) with the new jar that is a sibling of the crx-quickstart folder. Using our previous command as an example, our command would be: /usr/bin/java -server -Xmx1024m -Djava.awt.headless=true -Dsling.run.modes=author,crx3,crx3tar -jar cq-quickstart-6.5.0.jar -c crx-quickstart -p 4502 -Dsling.properties=conf/sling.properties

This will ensure that all proper memory settings, custom runmodes, and other environmental parameters are applied for the upgrade. After the upgrade has completed, the instance may be started from the start script on future startups.

Post Upgrade Checks and Troubleshooting

Use this link for post upgrade checks and troubleshooting.

NOTE: From AEM 6.5, you should access or log into the CRX/DE dashboard through this URL: /libs/granite/security/content/truststore.html. For example URL: https://cmsa-dvlp-01.db.vt.edu/libs/granite/security/content/truststore.html