ShowTable of Contents
During migration we faced many issues – some due to incorrect info on wiki, some due to scattered info. This article consolidates all these issues; however, it does not cover step-by-step process of migration because that is already presented in the product documentation.
To get the most from this article, you should be well versed in Lotus Quickr for WebSphere Portal 8.1.x, AIX, and IBM WebSphere Application Server (WAS). Hereafter we refer to Quickr 8.1.1.x as the source system and Quickr 8.5 as the target system.
Planning is critical for a successful migration. There are many points to consider before starting the migration process, the most important of which is that you must ensure your client will not lose any content that is created during migration process. Plan your migration during production downtime . Once migration completed point your client to newly migrated.
We followed the instructions in the “Migrating: qp85
” topic in the Product Documentation, to complete the migration activity.
Here are some points to consider in the planning process:
This involves checking for known issues before starting migration and verifying the
target standalone-system readiness.
Down time is very important for migration activity. Your source system is in production, so you need to be very careful to upgrade the source system to make it migration ready, as well as ensure you don't loose any new content. So basically you must plan for down time for
Source and target system readiness.
- the source system upgrade
- exporting the source data for migration
We followed the Product Documentation topics, “Preparing the source environment: p85
,” and “Preparing the target environment,
” to ensure readiness.
Check for known issues before starting migration.
Refer to the IBM Support Search site, “Organizational Productivity, Portals & Collaboration,”
for a list of helpful resources that identify known issues, including IBM Support Technote #1433365, “Out of memory error during migration export process on the Lotus Quickr 126.96.36.199 server.
” We actually faced this issue, so make sure you have your system ready per the instructions in this Technote.
In this section we describe the issues we faced during an actual migration. Keep in mind that these are specific to an AIX environment and might not apply to other operating systems.
Basically there are four phases to migration:
- Target system readiness
- Source system readiness for migration
- Exporting and importing of data (Places and Database)
- Post-migration issue resolution
Let's now discuss the issues associated with each phase.
Target system readiness
To Install Lotus Quickr 8.5, follow the instructions in the Lotus 8.5 for WebSphere Portal product documentation topic, “Preparing the target environment: qp85
Here we focus mainly on the problems that we faced during or before installation of Lotus Quickr 8.5 standalone single-server installation on AIX 6.1. First, check the /etc/hosts directory; the FQDN should be present in the host file.
There was no loopback entry (localhost loopback) in the host file. Basically every host file should have this as its first entry, but in our case it was not there. In this case we added the entry of 127.0.0.1, to resolve the issue.
When we started the installation of Quickr 8.5, it ran smoothly for a couple of hours but then failed because port 10008 was being occupied by some other process.
There is a daemon named srcmstr that occupies port 10008 in AIX. After some research we found that in /etc/inittab this daemon runs during system startup. To resolve the problem, you must comment out the line to disable the daemon, or change the configuration port for this process.
However, be careful when the LPAR is started up and check that 10008 port is not listening by running:
netstat -Aan | grep 10008 | grep LISTENProblem #3:
The ulimit for 64-bit AIX is set to unlimited, but during installation startup we had set the ulimit to 40000.
If the ulimit is set to unlimited still while the installation is started using GUI, you can reset the property to 40000, using:
ulimit -n 40000
at runtime for xterm windows (X-Window basically)
During Quickr 8.5 installation, the IBM DB2® 9.5 FP5 installation fails to create the DB2 instance.
In this case, it tried to create some files in /tmp but failed because it does not have access. So ensure that before you start the installation, give access to /tmp, using:
chmod -R 777 /tmp (we hope 755 also suffices).
Also, in our case the oslevel was 6100-06-00-0000.
For DB2 9.5 FP5 you must have Service Pack 2 installed before starting the installation, per Support Technote #1165448, “Known issues for DB2 on AIX 5.2, 5.3, 6.1, and 7.1
Follow these steps to prepare your source system:
1. Refer to the “Upgrading to 188.8.131.52
” topic in the product documentation. If you have an earlier version of Lotus Quickr, you must upgrade to version 184.108.40.206 before you can migrate to version 8.5.
3. Follow the instructions in the topic, “Completing the source preparation:qp85
,” before exporting the source data. The export captures the places for migration; however, any templates you have will not migrate. Template migration is a separate, manual step.
NOTE: In Step 1(b) of this topic, we encountered one issue. The step begins as follows:
“On the source WebSphere® Portal server, enable scripting. If the source server is part of a cluster, the changes must be made to the primary node....
It continues by stating to update libraries.xml, adding:
However, when we followed this step our export command “portal-pre-upgrade
” failed; specifically, when the task ran, we received a “Build Successful” message, but there were errors in the SystemOut log file and no applications were created in the <source_backup_dir>/wp.migrate.ai/application folder.
The SystemOut.log below shows the error:
00000082 WPScriptMBean E com.ibm.wps.scripting.server.WPScriptMBean executeCommand EJPXC0029E: Remote exception.
java.security.PrivilegedActionException: java.lang.ClassNotFoundException: com.ibm.wps.scripting.cmdifce.app.FindApplicationsCommand
at java.security.AccessController.doPrivileged1(Native Method)
at java.security.AccessController.doPrivileged(AccessController.java(Compiled Code))
We found that, when we added the above-cited class paths, it created a WAS entry under Environment – Shared libraries – WPSlib, like this:
The leading “\” character causes the source export script to fail.
To resolve the issue, remove the “\” at the WAS console, synchronize your environment, and then restart the Quickr environment.
The remainder of the steps from Place and Database export and import ran fine.
Exporting and importing of data (Places and database)
We followed the steps in the topics, “ Exporting source data: qp85,
and had no problems.
Exporting places (portal-pre-upgrade task) doesn't take much time if you don't have many places; in this case, there were about 20 places, which took less than 10 minutes to complete portal-pre-upgrade task.
Exporting of the database normally doesn't take long; however, in this case we needed to make a DB2 image copy of the JavaTM
Content Repository (JCR) and the customization database.
Importing (restore) of database doesn't take much time if you have small amount of data; in our case, it was around 4 GB in size and took less than 30 minutes.
Importing of Places took about 90 minutes, but as mentioned above we only had about 20 places.
Post-migration issue resolution
(1) JCR content not accessible for users.
We have configured Quickr 8.5 with a Novell Directory Server (LDAP) and users exist in the LDAP, but users with non-admin rights were not able to see the JCR content (blogs, wikis, documents).
The problem occurred because the log-in mechanism in our case used “cn” as the log-in property. So we had to give a filter in the WAS console:
user.fbadefault.filter = cn
For more details on configuring this property in the WAS console, refer to Technote # 1295975, “Different login and PUMA lookup values causes Web Content Management content rendering to fail
(2) Themes are not transferring properly for the newly migrated places.
When users access the migrated places, they receive a Java Server Pages (JSP) error, and the UI of the place returns a JSP compilation error.
We browsed to Portal Admin console – Themes, and found that during the migration process, old themes from the source system got migrated to the new target system. To resolve the problem:
a) Manually delete the themes from the Portal admin console.
b) Update the theme reference in the migrated places and apply a new theme.
c) Clear the wp_profile/temp directory.
Do not apply any themes that were migrated from the source server onto the target Quickr 8.5 server; otherwise, you'll get a JSP compilation error.
Although this document described the issues we faced during one customer's migration of Lotus Quickr 8.1.x to 8.5 on AIX, our hope is that it should be useful for anyone wanting to perform this migration.
developerWorks® Lotus Quickr product page:
Lotus Quickr Forum:
Quickr wiki article, “Planning a migration to IBM Lotus Quickr 8.5 for WebSphere Portal”:
About the authors
works in Lotus Lab Services, IBM India Software Labs, based in Pune, India. He specializes in Enterprise Portal and content management solutions, Web 2.0 technology, and Enterprise Collaboration platforms including WebSphere Portal, IBM Web Content Manager, and Lotus Quickr.
works in Lotus Lab Services, IBM India Software Labs, Pune. His expertise is in the WebSphere Portal Server, WebSphere Application Server, and Lotus Quickr products, focusing on infrastructure, installation/configuration/integration, performance tuning, and migration.