Migrating IBM Lotus Web Content Management content from versions 6.x to 7.0

Preparing to migrate

Before starting the migration, go through this checklist:

• Apply the latest cumulative fixpack on the 7.0 server. Refer to the IBM Support document, “Recommended Updates for WebSphere Portal and Web Content Management V7.0,” for more details.

• Both the 6.x and 7.x servers should be using IBM DB2®. We tested these steps using DB2, but you can try the same with other relational databases (CloudScape is not supported).

• Back up the Java^TM Content Repository (JCR) database on the 6.x server, and back up all the databases on the 7.0 server. So, in case there is a problem, you can restore the 7.0 databases to their previous working state and start over.

• Verify that database-related properties in the Wkplc properties files on the 7.0 server have the correct information on all current databases being used besides the JCR database (JCRDB).

• Delete the subscriber and syndicator pairs from the 6.x server before attempting the migration.

• Check for any duplicate entries in the JCRSTLINKS table using following query:

If you get any results from the above query, find the content with the name in TNAME column and delete it from the Authoring UI before backing up the 6.x database.

Migrating WCM content from 6.0.x versions to 7.0

Here are the steps to migrate WCM content from 6.0.x versions to version 7.0:

1. Make a copy of the 6.0.x version of the JCRDB.

2. Restore the JCR database from the 6.0.x server to the 7.0 JCRDB.

3. Update the following files in the 7.0 configEngine with the new JCR database properties:

• wp_profile_root/ConfigEngine/properties/wkplc.properties. Make sure WasPassword and PortalAdminPwd are set correctly.

• wp_profile_root/ConfigEngine/properties/wkplc_dbdomain.properties.

• jcr.DbName=jcrdb. This is the new name of the restored database on 7.0.

• jcr.DbSchema=jcr. This is the new schema copied over to 7.0 DB.

• jcr.DbUrl=jdbc:db2://localhost:50000/jcrdb:returnAlias=0; Make sure the database is updated in this URL and that the JCR DB DbUser and DBPassword are correct in this file.

• wp_profile_root/ConfigEngine/properties/wkplc_dbtype.properties. Make sure the Type 4 DB2 driver is being used, since both the databases are using DB2.

4. Update the following properties in the wp_profile_root/PortalServer/jcr/lib/com/ibm/icm/icm.properties file:

• jcr.database.name=jcrdb (where jcrdb is the new DB name of the restored DB on 7.0)

• jcr.database.schema=jcr (where jcr is the new schema copied over to 7.0 DB)

• jcr.database.userid=db2admin

• jcr.database.password=xxxxxx

Run the configEngine tasks

While running the next task listed in Step 4 below, we received the following error (logged in the Migration.log file):

MigrationSQLExecutor: ERROR ->DB2 SQL error: SQLCODE: -204, SQLSTATE: 42704,
SQLERRMC: JCR.ICMSTJCRNODELOCKSX

You can resolve the issue by binding the JCRDB, executing the following commands from a DB2 command line window:

Substitute with the install path for your DB2, and make sure you find the db2schema.bnd in the path before running the command.

Also, verify that all the Datasource passwords are correct before running the next task. You can verify this in the security.xml at cell scope:

Find this entry for the JCR datasource and make sure the encrypted password is the same as the other datasources; if not, set it to the clear text password, and it will be encrypted at the next restart:



(where “jcr” is the new Domain name used on the 7.0 server, which is copied over from 6.0.x)

After the above tasks are complete you'll find that, when accessing WebSphere Portal, the Page Builder theme is not loading anymore, but you can restore it by running following task:

ConfigEngine configure-common-component-resources -DWasPassword=password
-DportalAdminPwd=password

Run Member Fixer after this, if your LDAP is different from the 6.0 server. Refer to the Product Documentation topic, “Using the web content member fixer task: wp7,” for the task syntax.

In version 7.0, access permissions that are set on the library are by default automatically inherited by each new item created in the library; whereas, in 6.0, access permissions were not automatically inherited by new library items.

When you migrate content to a version 7.0 server, the access permissions inheritance on migrated items will not have changed. If you decide that you want to enable automatically inherited access permissions, you can use the update security task to apply inherited access permissions and remove existing item access permissions.

For example, the following task removes existing item access permissions and applies inherited access permissions to Content in the library called “MyLibrary” while preserving the last modified dates of the items:

Review the Product Documentation topic, “Using the Update Security task: lwcm7,” for more details on this task and how best to use it for your security configuration.

5. Restart WebSphere Portal server. You should now be able to access the WCM authoring portlet on the 7.0 server and work with the migrated content from 6.0.x.

Migrating WCM content from 6.1.0.x to 7.0

To do this:

1. Make a copy of the JCRDB from the 6.1.0.x version.

2. Restore the JCRDB from the 6.1.0.x server to the 7.0 JCRDB.

3. Update the following files in 7.0 configEngine, with the new JCRDB properties:

• wp_profile_root/ConfigEngine/properties/wkplc.properties. Make sure WasPassword and PortalAdminPwd are set correctly.

• wp_profile_root/ConfigEngine/properties/wkplc_dbdomain.properties.

• jcr.DbName=jcrdb. This is the new name of the restored database on 7.0.

• jcr.DbSchema=jcr. This is the new schema copied over to the 7.0 database.

• jcr.DbUrl=jdbc:db2://localhost:50000/jcrdb:returnAlias=0; Make sure the database is updated in this URL, and make sure the JCR DB DbUser and DBPassword are correct in this file.

• wp_profile_root/ConfigEngine/properties/wkplc_dbtype.properties. Make sure the Type 4 DB2 driver is being used, since both the databases are using DB2.

4. Update the following properties in the wp_profile_root/PortalServer/jcr/lib/com/ibm/icm/icm.properties file:

• jcr.database.name=jcrdb (where jcrdb is the new name of the restored database on 7.0)

• jcr.database.schema=jcr (where jcr is the new schema copied over to the 7.0 database)

• jcr.database.userid=db2admin

• jcr.database.password=xxxxxx

Run the configEngine tasks

(where “jcr” is the new Domain name used on the 7.0 server, which is copied over from 6.1.0.x)




(where “PreviousPortalVersion” is the version of the 6.1.0.x server that is being migrated)

Page Builder theme is not accessible after this, so we need to restore it by running following tasks:

• ConfigEngine.bat action-create-ear-wp.mashup.cc.theme -DWasPassword=wpsadmin -DportalAdminPwd=wpsadmin

• ConfigEngine.bat configure-common-component-resources -DWasPassword=wpsadmin -DPortalAdminPwd=wpsadmin

4. Now run Member Fixer, if your LDAP is different from the 6.1 server. Refer to the Product Documentation topic, “Using the web content member fixer task: wp7,” for the task syntax.

5. (Optional) If inheritance is not already enabled on your 6.1 libraries, you can use the Update Security task to apply inherited access permissions and remove existing item access permissions. Review your security configuration to make sure this is required for your content security configuration.

The following task removes existing item access permissions and applies inherited access permissions to Content in the MyLibrary library while preserving the last modified dates of the items:

For more details on this task and how best to use it for your security configuration, refer to the Product Documentation topic, “Using the Update Security task: lwcm7.”

6. Restart WebSphere Portal server. You should now be able to access the WCM authoring portlet on the 7.0 server and work with the migrated content from 6.1.0.x.

Migrating custom workflow actions from 6.1.0.x to 7.0.0.x

To do this:

1. Extract the Customer workflow action EAR file.

2. Open the plugin.xml file located under the WEB-INF folder.

3. Change the extension point package from:

point= "com.ibm.workplace.wcm.api.custom.CustomWorkflowActionFactory"

to

point= "com.ibm.workplace.wcm.api.CustomWorkflowActionFactory"

Listing 1 shows a sample plugin.xml file for a workflow action named “Sample Custom Workflow Action Factory":

Listing 1. Sample plugin.xml file
4. Package the Custom workflow action EAR file again, and install this updated EAR file from the WebSphere Admin console.

5. Restart the WebSphere Portal server, and confirm that the new custom workflow action application starts without any exceptions, and the class provider class specified in plugin.xml has the Extension Point, com.ibm.workplace.wcm.api.CustomWorkflowActionFactory.

6. Look for following message in the WebSphere Portal server's systemOut.log upon startup:

WSVR0200I: Starting application: SimpleCustomWorkflowActionEAR
WSVR0204I: Application: SimpleCustomWorkflowActionEAR Application build level: Unknown
CWXRS0034I: Extension com.ibm.workplace.wcm.sample.customworkflowaction.SimpleCustomWorkflowActionFactory connected with Extension Point com.ibm.workplace.wcm.api.CustomWorkflowActionFactory
..
WSVR0221I: Application started: SimpleCustomWorkflowActionEAR
WSVR0191I: Composition unit WebSphere:cuname=SimpleCustomWorkflowActionEAR in BLA WebSphere:blaname=SimpleCustomWorkflowActionEAR started.

7. Confirm you are able to select the newly deployed custom workflow action while creating a new custom workflow action from the WCM authoring UI.

8. Repeat the above steps for all custom workflow actions that you want to migrate from WebSphere Portal Server 6.1.0.x to 7.0.0.x.

Known issues with Oracle JCRDB migration

Here are a few issues noticed while migrating JCRDB from 6.0 to 7.0:

• ORA-01652: unable to extend temp segment by 1024 in tablespace ICMLSNDX
  Tablespace ICMLSNDX was not large enough for the indexes that were bring created.

To resolve the issue, increase the tablespace size.

• java.sql.SQLException: ORA-00257: archiver error. Connect internal only, until freed.

In this case, archive logging was running on the Oracle instance while performing the migration. Turn off archive logging to resolve the issue.

• ORA-30036: unable to extend segment by 8 in undo tablespace 'UNDO'

Here, tablespace was not set to auto-extend, and ran out of space. Increase the UNDO tablespace to resolve the issue.

About the authors

Anuradha Chitta is an Advisory Software Engineer working with the Web Content Management team at IBM’s Pune, India, facility for the past 3 years. Anu holds a Masters degree in Computer Science from LSU, and is an IBM Certified WebSphere ND 6.1 and Portal V6.0 System Administrator. She has been with IBM for over 10 years.

Bhargav Thakker is a Staff Software Engineer on the WebSphere Portal / Web Content Management team, working out of IBM’s Pune, India, facility for the past four years. He has extensive knowledge of the WCM product and is currently the Team Lead for the WCM Level 2 Support team. He is a WCM Certified Developer and holds a degree in Computer Engineering.