Portal V6.1.x on application server V6.1 stand-alone: Web content post migration steps

Once you have completed the WebSphere Portal migration steps, perform these additional steps to complete the web content migration.

JSP files and Web content plug-ins

• Any JSP files used on the old system will need to be manually copied to the new system.

• Any Web content plug-ins used on the old system, such as custom workflows, will need to be manually copied to the new system and enabled.

Search Indexes

Before you migrated the search components, you exported the search collections as XML files and deleted the search collections from the Manage Search portlet. After migrating to the current version of WebSphere Portal, we can rebuild your search indexes.

1. Create the new search collections.

2. Import the backed up configuration information for each of the search collections.

3. Check if the URLs for the crawlers are still valid.

4. Stop the WebSphere Portal server.

5. If the schedules have not been set, start the crawlers manually.

   Ignore this step if schedules have been set. When schedules are set, the crawlers update the search collections.

Syndication

Automatic syndication is disabled during migration. If we use automatic syndication enable it after migration. To do this, change the connect.moduleconfig.syndication.inittasks setting to true in the WCM WCMConfigService service using the WAS admin console.

If the migrated server is to be a syndicator, also set the deployment.subscriberOnly property to false.

Local rendering portlets based on the IBM Portlet API

The traditional rendering portlets that are provided for earlier versions of WCM are based on the IBM Portlet API. If you migrate any traditional local rendering portlets, update the permissions on the portlets by running the following configuration

./ConfigEngine.sh action-set-wcm-legacy-localrender-permissions -DWasPassword=foo -DPortalAdminPwd=foo

The IBM Portlet API web content viewer is deprecated and no longer available with the default installation. Wherever possible IBM recommends that you adapt the web content environment to use the JSR 286 web content viewer to ensure future compatibility.

Remote rendering portlets based on the IBM Portlet API

The traditional rendering portlets that are provided for earlier versions of WCM are based on the IBM Portlet API. If you migrate any traditional remote rendering portlets, update these portlets to v8.0.

If you fail to update the migrated remote rendering portlets as described here, some basic features, such as previewing, are not functional in Web Content Manager.

1. Update the portlet WAR file.

   1. Log in to the migrated server as an administrator.

   2. Go to the Administration view and then Portlet Management.

   3. Select Web Modules.

   4. Click Update.

   5. Click Browse.

   6. Select the file called ilwwcm-remoterendering-portlet.war from the PORTAL_HOME/pzn.ext/portlet.remoterendering/remoterendering.war/installableApps directory of the v8.0 server. This must be a content server installation as this file is not installed on an administration server installation.

   7. Click Open.

   8. Click Next.

   9. Click Finish.

2. Remove the ilwwcm-wcmimport application.

   1. Log in to the WAS admin console as an administrator.

   2. Click Applications > WebSphere enterprise applications.

   3. Select the ilwwcm-wcmimport application, and click Uninstall.

   4. Save the changes.

3. Register the remote rendering portlet again.

   1. On the migrated server, delete the PORTAL_HOME/temp/node_name/WebSphere_Portal/_extensionregistry directory.

   2. Delete the PORTAL_HOME/configuration directory.

   3. Run the osgiCfgInit command from the PORTAL_HOME/bin directory:
      ./osgiCfgInit.sh

   4. Restart the portal server.

The configuration settings of the remote rendering portlets on remote servers will be unchanged after you have migrated the servers. If the migrated servers use the same naming conventions as the old servers, then you will not have to re-configure the remote rendering portlets. If you have changed the naming conventions of the migrated server, such as giving the migrated cluster a different name than your old server cluster, then you will have to re-configure the remote rendering portlets.

If you have a small number of remote rendering portlets, we can edit the configuration settings of the remote rendering portlets manually. If you have a large number of remote rendering portlets, then we can use xmlaccess.sh to re-configure the remote rendering portlets. To do this you will have to export the pages containing the remote rendering portlets:

• We can use xmlaccess.sh to export the remote rendering portlet web application and all related portal pages.

• We can also use the Export Pages portlet in the portal's administration to export the entire page hierarchy containing the remote rendering portlets.

Once exported, change the value of the WCM_REMOTE_HOST_BASE_PATH variable for all the portlets to v8.0 servers. This updated XML file can then be imported using the xmlaccess command or the Import XML portlet.

The IBM Portlet API web content viewer is deprecated and no longer available with the default installation. Wherever possible IBM recommends that you adapt the web content environment to use the JSR 286 web content viewer to ensure future compatibility.

Parent: Portal V6.1.x on application server V6.1: stand-alone environment
Related:
Set up search collections
Search and crawl portal and other sites
Related:
Portal V6.1.x on application server V6.1: Migrating search components
Start and stop servers, dmgrs, and node agents