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, "http://www-01.ibm.com/support/docview.wss?uid=swg24027857" 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 JavaTM 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:
select WSID , SIID , TNSID , TNAME , TIX, count(*)from <SCHEMA>.ICMSTJCRLINKSgroup by WSID , SIID , TNSID , TNAME , TIX having count(*) > 1If 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.
- 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
<WAS_PROFILE_ROOT>\ConfigEngine\ConfigEngine.sh validate-database -DtransferDomainList=jcr(where “jcr” is the new Domain name used on the 7.0 server, which is copied over from 6.0.x.) <WAS_PROFILE_ROOT>\ConfigEngine\ConfigEngine.sh connect-database-jcr-migration <WAS_PROFILE_ROOT>\ConfigEngine\ConfigEngine.sh upgrade-jcr-datastore-601x-to-6100-jcrWhile 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:
db2 terminate db2 connect to jcrDB (this is the newly copied database from 6.0.x to 7.0)db2 bind <path>\db2schema.bnd blocking all grant public sqlerror continuedb2 terminate Substitute
“<path>”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:
<WAS_PROFILE_ROOT>\config\cells\<cell_name>\security.xml: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:
<authDataEntries xmi:id="JAASAuthData_1296387511109"alias="jcrdbDSJAASAuth" userId="db2admin" password="setPasswordHere”description="JAAS Alias for DataSource jcrdbDS"/><WAS_PROFILE_ROOT>\ConfigEngine\ConfigEngine.sh configure-wcm-migration<WAS_PROFILE_ROOT>\ConfigEngine\ConfigEngine.sh configure-wcm-remote-admin<WAS_PROFILE_ROOT>\ConfigEngine\ConfigEngine.sh action-create-schema-applyMIG7000-wp.migration.jcr.db -DPreviousPortalVersion=6.0.1.1 -DCurrentPortalVersion=7.0.0.0 -DWasPassword=<pwd> -DPortalAdminPwd=<pwd><WAS_PROFILE_ROOT>\ConfigEngine\ConfigEngine.sh wcm-post-migration-data-update-DPortalAdminPwd=xxx -DWasPassword=xxx -DPreviousPortalVersion=6.1.0.0-DtransferDomainList=jcr (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
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:
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,
"http://www-10.lotus.com/ldd/portalwiki.nsf/dx/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:
<WAS_PROFILE_ROOT>\ConfigEngine.bat run-wcm-admin-task-update-security -DWasPassword=password -Dlibrary=MyLibrary -DremoveExistingPerms=true -DinheritPerms=apply -DrestrictOn=Content -DpreserveDates=true -DlibSecurity=true Review the Product Documentation topic, “http://www-10.lotus.com/ldd/portalwiki.nsf/page.xsp?documentId=957132DA723044618525781A007D1A24&action=openDocument&mode=original,” 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.
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.
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
<WAS_PROFILE_ROOT>\ConfigEngine\ConfigEngine.sh validate-database-DTransferDomainList=jcr(where “jcr” is the new Domain name used on the 7.0 server, which is copied over from 6.1.0.x)
<WAS_PROFILE_ROOT>\ConfigEngine\ConfigEngine.sh connect-database-jcr-migration<WAS_PROFILE_ROOT>\ConfigEngine\ConfigEngine.sh configure-wcm-migration<WAS_PROFILE_ROOT>\ConfigEngine\ConfigEngine.sh configure-wcm-remote-admin<WAS_PROFILE_ROOT>\ConfigEngine\ConfigEngine.sh action-create-schema-applyMIG7000-wp.migration.jcr.db -DPreviousPortalVersion=6.1.0.3 -DCurrentPortalVersion=7.0.0.0 -DWasPassword=<pwd> -DPortalAdminPwd=<pwd><WAS_PROFILE_ROOT>\ConfigEngine\ConfigEngine.sh wcm-post-migration-data-update-DPortalAdminPwd=xxx -DWasPassword=xxx -DPreviousPortalVersion=6.1.0.3-DTransferDomainList=jcr(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,
"http://www-10.lotus.com/ldd/portalwiki.nsf/dx/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:
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:
<WAS_PROFILE_ROOT>\ConfigEngine.bat run-wcm-admin-task-update-security -DWasPassword=password -Dlibrary=MyLibrary -DremoveExistingPerms=true -DinheritPerms=apply -DrestrictOn=Content -DpreserveDates=true -DlibSecurity=true For more details on this task and how best to use it for your security configuration, refer to the Product Documentation topic,
"http://www-10.lotus.com/ldd/portalwiki.nsf/page.xsp?documentId=957132DA723044618525781A007D1A24&action=openDocument&mode=original."
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.
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
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
<?xml version="1.0" encoding="UTF-8"?><plugin id="com.ibm.workplace.wcm.sample.customworkflowaction" name="Sample Custom Workflow Action Factory"version="1.0.0"provider-name="IBM"> <extensionpoint="com.ibm.workplace.wcm.api.CustomWorkflowActionFactory" id="SimpleCustomWorkflowActionFactory"><provider class="com.ibm.workplace.wcm.sample.customworkflowaction.SimpleCustomWorkflowActionFactory"/></extension> </plugin>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
..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.
Note: If you are running into issues after completing the above steps, please refer to this technote:
http://www-01.ibm.com/support/docview.wss?rs=688&uid=swg21571603
No comments:
Post a Comment