+

Search Tips   |   Advanced Search

Update WCM data after migration

After you have migrated to v8.0 and successfully tested it, update the v8.0 data with the latest version data from the source environment. When performing a post migration data update you will lose any changes you have made to the data you initially migrated. For more info, see the Wiki.

Updating data with wcm-post-migration-data-update must be done before enabling managed pages and migrating virtual portals

  1. If you modified any resources in WebDAV, such as theme resources, back up these resources before running the wcm-post-migration-data-update task below. Restore the resources after the task is complete. Connect your WebDAV client to...

      http://host_name:port_number/wps/mycontenthandler/dav

    Copy all folders to a temporary location.

  2. Stop the portal server on both the source and target environments.

  3. Make a new copy of the source Portal JCR domain for the most up-to-date content.

    If the copy is not restored over the existing v8.0 database, set jcr.* database properties to point to copy in ...

      WP_PROFILE/ConfigEngine/properties/wkplc_dbdomain.properties

  4. Run connect-database... 
     
./ConfigEngine.sh connect-database 
                  -DPortalAdminPwd=foo 
                  -DWasPassword=foo 
                  -DTransferDomainList=jcr

  5. Run the wcm-post-migration-data-update of the 8.0 system. 
     
./ConfigEngine.sh wcm-post-migration-data-update 
                  -DPortalAdminPwd=foo 
                  -DWasPassword=foo 
                  -DPreviousPortalVersion=previous_portal_version

    ...where previous_portal_version is the version of the previous portal (for example, 6.1.0.6 or 7.0.0.2). This value can be found in...

      PORTAL_HOME/wps.properties

  6. If managed pages were enabled before performing the data update, re-enable.

  7. For clusters only, compare the icm.properties file on all secondary nodes with the version of the file on the primary node, and ensure that all instances of the file are identical to that on the primary node. If the files are not identical, copy icm.properties from the primary node on which you ran the database-transfer task to the secondary node.

    1. Stop the portal server on the secondary nodes.

    2. Copy...

        WP_PROFILE/PortalServer/jcr/lib/com/ibm/icm/icm.properties

      ...from the primary node and replace icm.properties on the secondary nodes.

    3. Start the portal server on the secondary node.

  8. If users have been updated on the source environment since the original migration, run the member fixer tool on the target environment after migrating the updated data.

  9. Reset the event log to ensure that items are syndicated correctly when syndication is enabled.

  10. Syndicate the updated data from the v8.0 primary server to the other servers in the system.

  11. If you backed up WebDAV folders before performing the web content update, connect to the WebDAV client again, and restore the copied folders.


Enable automatic synchronization

Before starting with migration, you disabled automatic synchronization to avoid nodes getting out of sync. Non that you have completed migration, it is safe to enable this feature again.

  1. Enable the synchronization service at startup...

      System Administration | Node Agents nodeagent | Additional Properties | File Synchronization Service | Enable service at server startup

  2. Enable automatic synchronization feature...

      System Administration | Node Agents nodeagent | Additional Properties | File Synchronization Service | Automatic Synchronization

  3. Click OK and Save.

  4. Repeat these steps for all remaining nodes.

  5. Select...

      System Administration | Node Agents | primary node | node agent | Restart


Migration consideration for Tivoli Access Manager integration

The IBM WebSphere Portal migration process migrates the security configurations. However, there is no provision for the automatic migration of any junction definitions that exist for the previous version of WebSphere Portal in WebSEAL. You must replace the old junction definitions with the new virtual host junction definitions.

The migration process migrates security configurations such as the user registry, VMM settings, and the IBM WAS security setup including any Trust Association Interceptor (TAI) configurations. Install the latest version of TAI on the current version of WebSphere Portal server. This installation configures the new WebSphere Portal instance for integration with Tivoli Access Manager WebSEAL.

The WebSphere Portal migration process cannot change the junction definitions in WebSEAL to point to the new server or to switch from standard non-transparent or transparent junctions to the new virtual host junctions. You must manually run these tasks within TAM. The TAM administrator staff often runs these tasks, which might be separate from the WebSphere Portal administrative staff. The following steps should be complete in conjunction with the instructions in the TAM e-Business WebSEAL Administrative Guide:

  1. Complete the following steps on the previous instance of WebSphere Portal:

    1. Open the WebSEAL configuration file.

    2. Search the file for stanzas that define the junctions; for example: [junction:junction_name].

    3. Write down the configuration value for each junction for future reference.

    4. Save a backup copy of the WebSEAL configuration file.

  2. To create the new virtual host junctions based on the junctions from the previous instance, run...

      server task WebSEAL-instance_name -webseald-WebSEAL-HostName virtualhost create -t type -h hostname [options] vhost-label

    ...where...

      vhost-label Name for the virtual host junction. Always mounted at the root of the WebSEAL object space (Web Portal Manager). Use this junction label when running pdadmin. The label must be unique within each instance of WebSEAL. Because the label represents virtual host junctions in the protected object space, the label name must not contain the forward slash character (/).
      -t type Defines whether the junction is encrypted (-t ssl) or not encrypted (-t tcp).
      -h hostname Back end server to which the junction connects. In most situations, host name is the HTTP server that sits in front of WebSphere Portal. Required

      -p port Port number for the back end server to which the junction connects. If not specified, the default value is 80 for HTTP or 443 for HTTPS.
      -v vhost_name[:port] Virtual host name and port number that defines the junction. WebSEAL maps incoming requests to this host name and port to this junction. If not specified, the values default to the -h hostname and -p port values.
      -c credential-generation Generate the credential information.
      -A Enable LTPA cookies
      -F key file Full path name location on the WebSEAL server of the key file used to encrypt the shared key that is originally created on the WAS server and copied securely to the WebSEAL server. Verify the automatic LTPA Key generation is disabled.
      -Z keyfile-password Password required to open the key file.

  3. Delete the old junctions using the appropriate administration commands, such as server task instance_name -webseal-host_name delete junction_point.

These steps just described recommend creating the new virtual host junction before deleting the old junctions. This approach assumes there are no detected conflicto that would prevent the new junction from coexisting with the old junctions. A conflict might arise if the vhost_label value is the same between the new and old junctions. These conflicts should be avoided or worked around. If we cannot avoid the conflict, delete the old junction before creating the new virtual host junction. Create a backup copy of the WebSEAL configuration file first so we can refer to it if necessary.
Related
Configure TAM to perform authentication only
Configure TAM for authentication, authorization, and the Credential Vault
TAM for e-business


Virtual Portal post migration steps

Virtual Portal Manager portlet v6.1.x

If we are migrating from WebSphere Portal 6.1.x, and we use the Virtual Portal Manager portlet, update the shared setting for this portlet.

  1. Go to...

  2. Note the XML file in the script to create virtual portal content tree: field. Edit this value to point to the migrated script.

    For example, if the value is MyVirtScript.xml the new value would be...

      WebSphere:assetname=MigratedVirtualPortal.zip:MyVirtScript.xml

    As part of the migration process the virtual portal scripts are removed from the wps.ear and moved to a compressed file asset named MigratedVirtualPortal.zip.


Default Virtual Portal Content

To create new virtual portals with the same content as in the system you migrated from, pre-configure the default content for virtual portal creation. This configuration is done by registering the filename.xml file we used in the system you migrated from. Be aware of the face that the name of the file might change based on the release and editions of portal we are using.

Examples of the used names:


Manage Seed List portlet

If you migrate from WebSphere Portal 6.1.x, the script can contain references to Manage Seed List portlet. This portlet is no longer available and any reference to this portlet will cause the script to fail.

Use the WAS admin console to update the virtual portal XML scripts to remove references to Manage Seed List portlet.

For example:

Make sure to remove those lines. Note that the object ids, portletrefs, sharerefs and other references in the example may vary in the installation.


Migrated Virtual Portal pages with old features

When you migrate a virtual portal, WebSphere Portal treats all pages in the portal as custom, customer-created content. As a result, if the virtual portal contains pages associated with features that are not available in the new installed version, WebSphere Portal migrates those pages regardless.

For example, if you migrate a virtual portal containing a Document Libraries page, WebSphere Portal preserver that page even though document libraries were removed from WebSphere Portal starting with Version 6.1. We can remove these pages manually, after migrating the virtual portal.


Update Web Content Manager pages theme

Change the theme of the hidden Web Content Manager authoring portlet to Portal 8.0 theme, otherwise Web Content Manager related portlets do not work properly.

  1. Log in to Portal as an administrator and go to...

  2. In the Search by menu select...

      Unique name contains

    ...and search for...

      com.ibm.wps.hiddenpage.wcm.Authoring_Portlet

  3. Select...

      Web Content Manager page | Edit Page Properties | Theme field | Portal 8.0 | OK


Web Content Manager WCI pages

To use WCI portlets after migration, add WCI pages and portlets manually.

  1. Log in to Portal as an administrator and go to...

      Administration | Manage Pages | Content Root | Administration | WebSphere Portal | Portal Content

  2. Create two new pages, one named Feed Configurations and the other Feed Jobs.

  3. Edit Page Layout of the Feed Configurations page, add the portlet named Feed Configurations and click OK.

  4. Edit Page Layout of the Feed Jobs page, add the portlet named Feed Schedules and click OK.

See also: Administer virtual portals


Mashup Integration Post Migration steps

Mashup Integration feature was removed in WebSphere Portal v8.0. This step is an optional if you actively used this feature in previous releases and you still want to continue using it in Websphere portal v8.0, you need to manually enable Mashup Integration after migration.

In previous versions of WebSphere Portal, the MashupMaker_Integration.ear was registered with the system in all cases. Even when it was only required in cases where the Mashup Integration feature was used actively in the system. To remove system overhead, the .ear file was removed from the portal configuration during migration.

If we used Mashup Integration in previous releases and you still want to continue using it in portal V 80 (and only in this case), register the .ear file with the following command:


Blogs and wikis post migration steps

After migrating from WebSphere Portal v7.0 to v8.0, you must run a configuration task to update the presentation templates used by blogs and wikis to apply the correct styling. You must run this task for content in the blogs and wikis to render properly.

  1. cd WP_PROFILE/ConfigEngine
    ./ConfigEngine.sh configure-blog -DPortalAdminPwd=foo -DWasPassword=foo

  2. RestartWebSphere Portal.

  3. Verify the presentation templates have been updated by accessing Administration > WebSphere Portal > Portal Content | Web Content Libraries..


Update custom theme Dojo references

The default Dojo context root is...

We can find the value of WpsContextRoot in...

You might find that migrated Portal Web2 and Enhanced themes have references to /portal_dojo without the WpsContextRoot prefix.

Look for these references in both the WAR file and in the WebDAV storage for the theme and update if needed.


Analytics post migration steps

If we use site analytics on your migrated WebSphere Portal, create the analytics tag root label. 

 
cd PORTAL_HOME/bin
./xmlaccess.sh -url http://example_server.com:port/wps/config
               -user wpsadmin -password foo 
               -in PORTAL_HOME/base/wp.asa.server.impl/config/templates/create_asa_tag_root.xml
               -out results.xml

As an alternative, we can also use the portal administration portlet Import XML to perform this import.

After the request has been processed, verify the import process has returned the following message:

Your site analytics tags are now ready for you to work.


Portlets no longer available

Some portlets that used to be available on previous releases of WebSphere Portal are no longer including in v8.0. These portlets are not migrated as part of the WebSphere Portal migration process.

Many of these portlets are now available for download from the IBM Lotus and WebSphere Portal Business Solutions Catalog. If these portlets are still required, installation and deployment instructions are provided with the portlet download.
Related
What's new
What's changed
Unsupported and deprecated features
IBM Lotus and WebSphere Portal Business Solutions Catalog


Set up Tag Center page

If the target environment does not have a Tag Center page create one along with all the associated portlets.

Deploy the portlets and create the Tag Center page s:


Remove Person Tag hidden pages

Remove Person Tag hidden pages from migrated environments where Search for Portal Site was previously configured.

You may find errors captured in the systemOut.log file if the migrated system has Search for Portal Site configured and crawling runs. The following excerpt is provided as an example. 

00000052 PortletContai E com.ibm.wps.pe.pc.legacy.PortletContainerImpl 
         performBeginEvents EJPPG1122E: 
         
         An error occurred during portlet event processing.
             javax.portlet.PortletException: javax.servlet.UnavailableException: SRVE0200E: 
         
         Servlet [com.ibm.wkplc.people.portal.portlet.dynamicpersontag.DynamicPersonTagPortlet]: Could not 
         find  required class -  class java.lang.ClassNotFoundException: com.ibm.wkplc.people.portal.portlet.
         dynamicpersontag.DynamicPersonTagPortlet
                
         at com.ibm.wps.pe.pc.legacy.PortletContainerImpl.callPortletMethod(PortletContainerImpl.java:1308)

Remove the hidden pages to avoid these errors in the systemOut.log.

  1. Log in to Portal as an Administrator and go to...

      Administration | Manage Pages | Context Root | Hiden Pages

  2. Look for Person Tag with unique name ibm.portal.Person.Tag.

  3. Delete this page.


Parent: Post-migration activities


Update WCM data after migration

After you have migrated to v8.0 and successfully tested it, update the v8.0 data with the latest version data from the source environment. When performing a post migration data update you will lose any changes you have made to the data you initially migrated. For more info, see the Wiki.

Updating data with wcm-post-migration-data-update must be done before enabling managed pages and migrating virtual portals

  1. If you modified any resources in WebDAV, such as theme resources, back up these resources before running the wcm-post-migration-data-update task below. Restore the resources after the task is complete. Connect your WebDAV client to...

      http://host_name:port_number/wps/mycontenthandler/dav

    Copy all folders to a temporary location.

  2. Stop the portal server on both the source and target environments.

  3. Make a new copy of the source Portal JCR domain for the most up-to-date content.

    If the copy is not restored over the existing v8.0 database, set jcr.* database properties to point to copy in ...

      WP_PROFILE/ConfigEngine/properties/wkplc_dbdomain.properties

  4. Run connect-database... 
     
./ConfigEngine.sh connect-database 
                  -DPortalAdminPwd=foo 
                  -DWasPassword=foo 
                  -DTransferDomainList=jcr

  5. Run the wcm-post-migration-data-update of the 8.0 system. 
     
./ConfigEngine.sh wcm-post-migration-data-update 
                  -DPortalAdminPwd=foo 
                  -DWasPassword=foo 
                  -DPreviousPortalVersion=previous_portal_version

    ...where previous_portal_version is the version of the previous portal (for example, 6.1.0.6 or 7.0.0.2). This value can be found in...

      PORTAL_HOME/wps.properties

  6. If managed pages were enabled before performing the data update, re-enable.

  7. For clusters only, compare the icm.properties file on all secondary nodes with the version of the file on the primary node, and ensure that all instances of the file are identical to that on the primary node. If the files are not identical, copy icm.properties from the primary node on which you ran the database-transfer task to the secondary node.

    1. Stop the portal server on the secondary nodes.

    2. Copy...

        WP_PROFILE/PortalServer/jcr/lib/com/ibm/icm/icm.properties

      ...from the primary node and replace icm.properties on the secondary nodes.

    3. Start the portal server on the secondary node.

  8. If users have been updated on the source environment since the original migration, run the member fixer tool on the target environment after migrating the updated data.

  9. Reset the event log to ensure that items are syndicated correctly when syndication is enabled.

  10. Syndicate the updated data from the v8.0 primary server to the other servers in the system.

  11. If you backed up WebDAV folders before performing the web content update, connect to the WebDAV client again, and restore the copied folders.


Parent: Post-migration activities


Enable automatic synchronization

Before starting with migration, you disabled automatic synchronization to avoid nodes getting out of sync. Non that you have completed migration, it is safe to enable this feature again.

  1. Launch the WAS admin console.

  2. Select System Administration > Node Agents in the navigation tree.

  3. Click nodeagent for the required node.

  4. Click File Synchronization Service under the Additional Properties section.

  5. Select the Enable service at server startup check box selection to enable the synchronization service at startup.

  6. Select the Automatic Synchronization check box selection to enable automatic synchronization feature.

  7. Click OK and Save.

  8. Repeat these steps for all remaining nodes.

  9. Select System Administration > Node Agents in the navigation tree.

  10. For the primary node, select the node agent and click Restart.


Parent: Post-migration activities


Migration consideration for Tivoli Access Manager integration

The IBM WebSphere Portal migration process migrates the security configurations. However, there is no provision for the automatic migration of any junction definitions that exist for the previous version of WebSphere Portal in WebSEAL. You must replace the old junction definitions with the new virtual host junction definitions.

The migration process migrates security configurations such as the user registry, VMM settings, and the IBM WAS security setup including any Trust Association Interceptor (TAI) configurations. Install the latest version of TAI on the current version of WebSphere Portal server. This installation configures the new WebSphere Portal instance for integration with Tivoli Access Manager WebSEAL.

The WebSphere Portal migration process cannot change the junction definitions in WebSEAL to point to the new server or to switch from standard non-transparent or transparent junctions to the new virtual host junctions. You must manually run these tasks within Tivoli Access Manager. The Tivoli Access Manager administrator staff often runs these tasks, which might be separate from the WebSphere Portal administrative staff. The following steps should be complete in conjunction with the instructions in the Tivoli Access Manager e-Business WebSEAL Administrative Guide:

  1. Complete the following steps on the previous instance of WebSphere Portal:

    1. Open the WebSEAL configuration file.

    2. Search the file for stanzas that define the junctions; for example: [junction:junction_name].

    3. Write down the configuration value for each junction for future reference.

    4. Save a backup copy of the WebSEAL configuration file.

  2. To create the new virtual host junctions based on the junctions from the previous instance, run...

      server task WebSEAL-instance_name -webseald-WebSEAL-HostName virtualhost create -t type -h hostname [options] vhost-label

    ...where...

      vhost-label Name for the virtual host junction. Always mounted at the root of the WebSEAL object space (Web Portal Manager). Use this junction label when running pdadmin. The label must be unique within each instance of WebSEAL. Because the label represents virtual host junctions in the protected object space, the label name must not contain the forward slash character (/).
      -t type Defines whether the junction is encrypted (-t ssl) or not encrypted (-t tcp).
      -h hostname Back end server to which the junction connects. In most situations, host name is the HTTP server that sits in front of WebSphere Portal. Required

      -p port Port number for the back end server to which the junction connects. If not specified, the default value is 80 for HTTP or 443 for HTTPS.
      -v vhost_name[:port] Virtual host name and port number that defines the junction. WebSEAL maps incoming requests to this host name and port to this junction. If not specified, the values default to the -h hostname and -p port values.
      -c credential-generation Generate the credential information.
      -A Enable LTPA cookies
      -F key file Full path name location on the WebSEAL server of the key file used to encrypt the shared key that is originally created on the WAS server and copied securely to the WebSEAL server. Verify the automatic LTPA Key generation is disabled.
      -Z keyfile-password Password required to open the key file.

  3. Delete the old junctions using the appropriate administration commands, such as server task instance_name -webseal-host_name delete junction_point.

These steps just described recommend creating the new virtual host junction before deleting the old junctions. This approach assumes there are no detected conflicto that would prevent the new junction from coexisting with the old junctions. A conflict might arise if the vhost_label value is the same between the new and old junctions. These conflicts should be avoided or worked around. If we cannot avoid the conflict, delete the old junction before creating the new virtual host junction. Create a backup copy of the WebSEAL configuration file first so we can refer to it if necessary.


Parent: Post-migration activities
Related:
Configure Tivoli Access Manager to perform authentication only
Configure Tivoli Access Manager for authentication, authorization, and the Credential Vault
Tivoli Access Manager for e-business


Virtual Portal post migration steps


Virtual Portal Manager portlet v6.1.x

If we are migrating from WebSphere Portal 6.1.x, and we use the Virtual Portal Manager portlet, update the shared setting for this portlet.

  1. Go to...

  2. Note the XML file in the script to create virtual portal content tree: field. Edit this value to point to the migrated script.

    For example, if the value is MyVirtScript.xml the new value would be...

      WebSphere:assetname=MigratedVirtualPortal.zip:MyVirtScript.xml

    As part of the migration process the virtual portal scripts are removed from the wps.ear and moved to a compressed file asset named MigratedVirtualPortal.zip.


Default Virtual Portal Content

To create new virtual portals with the same content as in the system you migrated from, you need to pre-configure the default content for virtual portal creation. This configuration is done by registering the filename.xml file we used in the system you migrated from. Be aware of the face that the name of the file might change based on the release and editions of portal we are using.

Examples of the used names:


Manage Seed List portlet

If you migrate from WebSphere Portal 6.1.x, the script can contain references to Manage Seed List portlet. This portlet is no longer available and any reference to this portlet will cause the script to fail.

Use the WAS admin console to update the virtual portal XML scripts to remove references to Manage Seed List portlet.

For example:

Make sure to remove those lines. Note that the object ids, portletrefs, sharerefs and other references in the example may vary in the installation.


Migrated Virtual Portal pages with old features

When you migrate a virtual portal, WebSphere Portal treats all pages in the portal as custom, customer-created content. As a result, if the virtual portal contains pages associated with features that are not available in the new installed version, WebSphere Portal migrates those pages regardless.

For example, if you migrate a virtual portal containing a Document Libraries page, WebSphere Portal preserver that page even though document libraries were removed from WebSphere Portal starting with Version 6.1. We can remove these pages manually, after migrating the virtual portal.


Update Web Content Manager pages theme

You must change the theme of the hidden Web Content Manager authoring portlet to Portal 8.0 theme, otherwise Web Content Manager related portlets do not work properly.

  1. Log in to Portal as an administrator and go to...

  2. In the Search by menu select...

      Unique name contains

    ...and search for...

      com.ibm.wps.hiddenpage.wcm.Authoring_Portlet

  3. Select...

      Web Content Manager page | Edit Page Properties | Theme field | Portal 8.0 | OK


Web Content Manager WCI pages

To use WCI portlets after migration, add WCI pages and portlets manually.

  1. Log in to Portal as an administrator.

  2. Navigate through Administration > Manage Pages > Content Root > Administration > WebSphere Portal > Portal Content.

  3. Create two new pages, one named Feed Configurations and the other Feed Jobs.

  4. Edit Page Layout of the Feed Configurations page, add the portlet named Feed Configurations and click OK.

  5. Edit Page Layout of the Feed Jobs page, add the portlet named Feed Schedules and click OK.


Parent: Post-migration activities
Related: Administer virtual portals


Mashup Integration Post Migration steps

Mashup Integration feature was removed in WebSphere Portal v8.0. This step is an optional if you actively used this feature in previous releases and you still want to continue using it in Websphere portal v8.0, you need to manually enable Mashup Integration after migration.

In previous versions of WebSphere Portal, the MashupMaker_Integration.ear was registered with the system in all cases. Even when it was only required in cases where the Mashup Integration feature was used actively in the system. To remove system overhead, the .ear file was removed from the portal configuration during migration.

If we used Mashup Integration in previous releases and you still want to continue using it in portal V 80 (and only in this case), register the .ear file with the following command:


Parent: Post-migration activities


Blogs and wikis post migration steps

After migrating from WebSphere Portal v7.0 to v8.0, you must run a configuration task to update the presentation templates used by blogs and wikis to apply the correct styling. You must run this task for content in the blogs and wikis to render properly.

  1. z/OS only: When using z/OS, open a UNIX System Services (USS) command prompt to change directories.

  2. Navigate to the WP_PROFILE/ConfigEngine.

  3. Run the following command:

      ./ConfigEngine.sh configure-blog -DPortalAdminPwd=foo -DWasPassword=foo

  4. RestartWebSphere Portal.

  5. Verify the presentation templates have been updated by accessing Administration > WebSphere Portal > Portal Content | Web Content Libraries..


Parent: Post-migration activities


Update custom theme Dojo references

The default Dojo context root in WebSphere Portal is /WpsContextRoot/portal_dojo. We can find the value of WpsContextRoot in WP_PROFILE/ConfigEngine/properties/wkplc.properties.

You might find that migrated Portal Web2 and Enhanced themes have references to /portal_dojo without the WpsContextRoot prefix.

Look for these references in both the WAR file and in the WebDAV storage for the theme and update if needed.


Parent: Post-migration activities


Analytics post migration steps

If we use site analytics on your migrated WebSphere Portal, create the analytics tag root label.

  1. Change to the following directory containing the WebSphere Portal tools:

      PORTAL_HOME/bin

  2. Create the analytics tag root label by running the following command: 

      ./xmlaccess.sh -url http://example_server.com:port/wps/config
               -user wpsadmin -password foo 
               -in PORTAL_HOME/base/wp.asa.server.impl/config/templates/create_asa_tag_root.xml
               -out results.xml

    As an alternative, we can also use the portal administration portlet Import XML to perform this import.

  3. After the request has been processed, verify the import process has returned the following message: <status element="all" result="ok">

Your site analytics tags are now ready for you to work.


Parent: Post-migration activities


Portlets no longer available

Some portlets that used to be available on previous releases of WebSphere Portal are no longer including in v8.0. These portlets are not migrated as part of the WebSphere Portal migration process.

Many of these portlets are now available for download from the IBM Lotus and WebSphere Portal Business Solutions Catalog. If these portlets are still required, installation and deployment instructions are provided with the portlet download.

See the What's new section for details on what changed and deprecated features in this release.


Parent: Post-migration activities
Related:
What's new
What's changed
Unsupported and deprecated features
Related:

IBM Lotus and WebSphere Portal Business Solutions Catalog


Set up Tag Center page

If the target environment does not have a Tag Center page create one along with all the associated portlets.

Deploy the portlets and create the Tag Center page by running the following commands:


Parent: Post-migration activities


Remove Person Tag hidden pages

Remove Person Tag hidden pages from migrated environments where Search for Portal Site was previously configured.

You may find errors captured in the systemOut.log file if the migrated system has Search for Portal Site configured and crawling runs. The following excerpt is provided as an example. 

00000052 PortletContai E com.ibm.wps.pe.pc.legacy.PortletContainerImpl 
         performBeginEvents EJPPG1122E: 
         
         An error occurred during portlet event processing.
             javax.portlet.PortletException: javax.servlet.UnavailableException: SRVE0200E: 
         
         Servlet [com.ibm.wkplc.people.portal.portlet.dynamicpersontag.DynamicPersonTagPortlet]: Could not 
         find  required class -  class java.lang.ClassNotFoundException: com.ibm.wkplc.people.portal.portlet.
         dynamicpersontag.DynamicPersonTagPortlet
                
         at com.ibm.wps.pe.pc.legacy.PortletContainerImpl.callPortletMethod(PortletContainerImpl.java:1308)

Remove the hidden pages to avoid these errors in the systemOut.log.

  1. Log in to Portal as an Administrator.

  2. Navigate through Administration > Manage Pages > Context Root > Hiden Pages.

  3. Look for Person Tag with unique name ibm.portal.Person.Tag.

  4. Delete this page.


Parent: Post-migration activities