Prepare to run the migration tasks

 

+

Search Tips   |   Advanced Search

 

This section describes the manual steps that need to be performed before migrating IBM WebSphere Portal. The following steps are required to run the migration tasks:

  1. Confirm successful installation of WebSphere Portal

  2. Update anonymous user roles

  3. Accessing WebSphere Portal to perform migration

  4. Change the timeout for the HTTP server

  5. Run the migrate property collector task

  6. Make portlet applications available to migration tasks for deployment.

  7. Create the virtual portal from the previous version in the current version

  8. Required performance tuning for exporting large groups and resources

Perform the following steps before running the migration tasks:

  1. Confirm successful installation of the current version of WebSphere Portal

    See Installing and configuring and Installing coexisting WebSphere Portal products on the same machine for instructions.

  2. Update anonymous user roles

    Check the previous environment for any anonymous users with the following roles:

    Change all of these roles to User.

  3. Accessing WebSphere Portal to perform migration

    To perform the migration, provide the user ID and password of a user that has administrative authority for WebSphere Portal :

    • For the export task, enter an administrative user ID for the previous version

    • For the import task, enter an administrative user ID for the current version

  4. Change the timeout for the HTTP server

    Because migration can be a lengthy process, you suggest that you change the timeout length of the HTTP server to unlimited timeout while performing the migration task. Refer to the HTTP server documentation for information on how to change the timeout value.

  5. Run the migrate property collector task to collect required files from the previous version to allow the migration scripts to access the previous version:

    1. Copy the propcollector.xml and propcollector.jar files from the...

      portal_server_root/migration

      ...directory of the current version to the...

      wp_old_root/config/includes

      ...directory of the previous version and run the following command from the...

      wp_old_root/config

      ...directory of the previous version:

      If using i5/OS, the directory path is portal_server_root for the current version of WebSphere Portal and wp_user_old_root for the previous version of WebSphere Portal.

      • Windows and UNIX:

        WPSconfig.{sh|bat} prop-collector -DDbPassword=wpsdb_password

      • i5/OS From the UserData directory:

        WPSconfig.sh -instance instance_name prop-collector -DDbPassword=wpsdb_password

        ...where instance_name is the name of the WebSphere Application Server profile where WebSphere Portal is installed.

        The following information applies to running the above command:

        • -DDbPassword=wpsdb_password is not required if the value is already defined in the wpconfig.properties file.

        • Ensure that the values for DbUrl, DbName, and DbServer are defined in the wpconfig.properties file.

    2. Copy...

      wp_old_root/config/includes/propcollectorOutput.zip

      ...from the previous version to the...

      portal_server_root/migration directory

      ...on the current version.

    3. Execute from the...

      portal_server_root/migration

      ...directory of the current version to extract the propcollectorOutput.zip file: 

          WPmigrate.{sh|bat} collector-extract

  6. Make portlet applications available to migration tasks for deployment

    The directory...

    portal_server_root/installedApps

    ...contains a list of all portlet applications that are deployed on the previous WebSphere Portal system. Depending on the features that are used by these portlets, they might have to first be upgraded to work with the current version of WebSphere Portal. Refer to the instructions that are provided in the Migrating the customized resources section to determine to upgrade the portlets.

    Some of the WAR files in the directory...

    portal_server_root/installedApps

    ...might have been shipped with the current version of WebSphere Portal. In that case, there is no need to manually upgrade corresponding portlets. We can safely use the corresponding WAR file from the directory...

    portal_server_root/installableApps

    ...as an upgraded version of the portlet.

    Before running migration tasks, all the upgraded portlets must be made available in the directory...

    portal_server_root/installableApps

    ...of the current WebSphere Portal system. This directory has the sample portlets that ship with the current version of WebSphere Portal ; do not overwrite these with the sample versions that shipped with earlier versions of WebSphere Portal.

  7. Create the virtual portal from the previous version in the current version

    In order to migrate the data from the previous virtual portal into the current version, recreate the virtual portal in the current version. Use the Virtual Portal Manager to create the virtual portal in the current version.

  8. Required performance tuning for exporting and importing large groups and resources

    1. Check the LDAP server to determine the number of groups and perform the appropriate steps if the number is greater than 200:

      • Perform the following steps on the previous version of WebSphere Portal if migrating from v5.0.2.x:

        1. Change to the wp_old_root/shared/app/wmm directory of the 5.0.2.x system.

        2. Open the wmm.xml file and change the numerical value in maximumSearchResults to "$GROUPS" where "$GROUPS" is a number greater than the actual number of groups on the LDAP server; for example if the LDAP server has 300 groups, then enter 301.

        3. Save the changes.

      • Perform the following steps on the previous version of WebSphere Portal if migration from v5.1.x:

        1. Change to the wp_old_root/wmm directory of the 5.1.x directory.

          If using i5/OS, the directory is wp_user_old_root; see the Directory structure for the 5.1.x version.

        2. Open the wmm.xml file and change the numerical value in maximumSearchResults to "$GROUPS" where "$GROUPS" is a number greater than the actual number of groups on the LDAP server; for example if the LDAP server has 300 groups, then enter 301.

        3. Save the changes.

        4. If this is a clustered environment, change to the was_old_root/config/wmm directory of the 5.1.x system.

          If using i5/OS, the directory is was_user_old_root; see the Directory structure for the 5.1.x version.

        5. Open the wmm.xml file and change the numerical value in maximumSearchResults to "$GROUPS" where "$GROUPS" is a number greater than the actual number of groups on the LDAP server; for example if the LDAP server has 300 groups, then enter 301.

        6. Save the changes.

        7. If this is a clustered environment, change to the dmgr_old_root/config/wmm directory on the deployment manager machine of the 5.1.x system.

        8. Open the wmm.xml file and change the numerical value in maximumSearchResults to "$GROUPS" where "$GROUPS" is a number greater than the actual number of groups on the LDAP server; for example if the LDAP server has 300 groups, then enter 301.

        9. Save the changes.

      • Perform the following steps on the current version of WebSphere Portal after completing any security-related tasks, such as, but not limited to, running the enable-security-ldap task:

        1. Change to the directory...

          portal_server_root/wmm

          ...of the current version.

          If using i5/OS, the directory path is portal_server_root.

        2. Open the wmm.xml file and change the numerical value in maximumSearchResults to "$GROUPS" where "$GROUPS" is a number greater than the actual number of groups on the LDAP server; for example if the LDAP server has 300 groups, then enter 301.

        3. Save the changes.

    2. Change the following LDAP server parameters to "unlimited":

      • Size limit
      • Look-through limit
      • Time limit
      • Idle timeout

    3. Use the following steps to stop and restart the servers:

      1. Open a command prompt and change to the following directory:

      2. Enter the following command:

        • UNIX:

          ./stopServer.sh server1 -user admin_userid -password admin_password

        • Windows:

          stopServer.bat server1 -user admin_userid -password admin_password

        • i5/OS:

          stopServer -profileName profile_root -user admin_userid -password admin_password

          ...where profile_root is the name of the WebSphere Application Server profile where WebSphere Portal is installed; for example, wp_profile.

        ...where server1 is the name of the WebSphere Application Server administrative server, and profile_root is the name given to the WebSphere Application Server profile in use.

      3. Enter the following command:

        • UNIX:

          ./stopServer.sh WebSphere_Portal -user admin_userid -password admin_password

        • Windows:

          stopServer.bat WebSphere_Portal -user admin_userid -password admin_password

        • i5/OS:

          stopServer WebSphere_Portal -profileName profile_root -user admin_userid -password admin_password

          ...where profile_root is the name of the WebSphere Application Server profile where WebSphere Portal is installed; for example, wp_profile.

      4. Enter the following command:

        • UNIX:

          ./startServer.sh server1

        • Windows:

          startServer.bat server1

        • i5/OS:

          startServer -profileName profile_root

          ...where profile_root is the name of the WebSphere Application Server profile where WebSphere Portal is installed; for example, wp_profile.

        ...where server1 is the name of the WebSphere Application Server administrative server.

      5. Enter the following command:

        • UNIX:

          ./startServer.sh WebSphere_Portal

        • Windows:

          startServer.bat WebSphere_Portal

        • i5/OS:

          startServer WebSphere_Portal -profileName profile_root

          ...where profile_root is the name of the WebSphere Application Server profile where WebSphere Portal is installed; for example, wp_profile.

  9. Optional: Set the Computer Associates eTrust SiteMinder property to ensure successful migration

    If you are using eTrust SiteMinder to perform authorization, verify that the SiteMinderLoginModule custom property is defined because any XML Configuration Interface execution can be affected. See the SiteMinderLoginModule step in Configuring eTrust SiteMinder to perform authorization for WebSphere Portal

 

Next steps

 

Related Information

 

Parent topic:

Migrating