Preparing to run the migration tasks

1: Confirm successful installation of WebSphere Portal V5.1

2: Apply interim fixes to previous installations of WebSphere Portal

3: Apply additional fix if using an External Security Manager

4: Specify values in the properties files

5: Make portlet applications available to migration tasks for deployment.

6. Prepare to migrate WebSphere Member Services

   6.1: You might be able to skip step 7 if you do not store additional attributes in a Lookaside database

   6.2: Preparatory steps

   6.3: Set parameters that are related to the Member Manager uuid

7: Migrate custom deployment scripts

8: Specify if external access control is migrated

9: Ensure that all LDAP groups have at least one member

 

1: Confirm successful installation of WebSphere Portal V5.1

You should have already installed WebSphere Portal V5.1. Confirm that WebSphere Portal V5.1 is installed, configured, and operating correctly. See Install and Install coexisting WebSphere Portal products on the same machine for instructions.

 

2: Apply interim fixes to previous installations of WebSphere Portal

WebSphere Portal 4.1.6 and 4.2.1 Source Server:

  1. Stop the previous version of WebSphere Portal.

  2. Open a command prompt/shell on the 5.1 server and change to the <wp_root> /migration/efixes directory.

  3. Type the following command: jar -xvf WP4xx_MP_Express_Patch.jar (where xx is the version of the source server you are using.)

  4. For information on the fixes contained in the patch, refer to the ReadMe.txt file that is the output from the jar command.

  5. Copy the <wp_root> /migration/efixes/4XX_fix.jar file to the $WAS_HOME /lib/app directory of the 4.1.6 or 4.2.1 server.

  6. Open a command prompt/shell on the 4.1.6 or 4.2.1 server and change to the $WAS_HOME /lib/app directory.

  7. Type the following command: jar -xvf 4XX_fix.jar

  8. Edit the $WAS_HOME /lib/app/config/services/XmlAccessService.properties file.

  9. Add the following line to the $WAS_HOME /lib/app/config/services/XmlAccessService.properties file, on one line and maintaining all of the capitalizations: com.ibm.wps.command.xml.groupexport.GroupExportEngine=-//IBM//DTD Group Export//EN,/com/ibm/wps/command/xml/groupexport/GroupExport.dtd

  10. Save the file.

  11. Start the previous version of WebSphere Portal.

To confirm that the fixes were applied correctly, look for a /com directory that was created in $WAS_HOME /lib/app.

4.2.2 Source Servers:

  1. Stop the previous version of WebSphere Portal.

  2. Copy the WP422_MP_Express_Patch.jar file from <wp_root> /migration/efixes to a temporary directory on the 4.2.2 server.

  3. Type the following command: jar -xvf WP422_MP_Express_Patch.jar.

  4. For information on the fixes contained in the patch, refer to the ReadMe.txt file that is the output from the jar command.

  5. Open a command prompt/shell on the 4.2.2 server and change to the <wp_root> /bin directory.

  6. For each jar file output in the temporary directory created by step 3, type the following command: wps efix install PQ*****.jar

    Be sure to run this command on each apar in numerical order; for example, PQ76366 before PQ91600.

  7. Edit the file $WAS_HOME /lib/app/config/services/XmlAccessService.properties.

  8. Add the following line to the $WAS_HOME /lib/app/config/services/XmlAccessService.properties file, on one line and maintaining all of the capitalizations: com.ibm.wps.command.xml.groupexport.GroupExportEngine=-//IBM//DTD Group Export//EN,/com/ibm/wps/command/xml/groupexport/GroupExport.dtd

  9. Save the file and then restart the Portal Server.

Notes:

  • You need write permission on $WAS_HOME and <wp_root> directories.

  • You can view the list of currently installed interim fixes by typing: wps efix list

  • You can remove the interim fix by typing (for each fix enclosed): wps efix uninstall PQ92583

  • On UNIX platforms, wps is as executed as sh./wps.sh

5.x Source Servers:

  1. Stop the previous version of WebSphere Portal.

  2. Download and apply the latest Portal UpdateInstaller to the 5.xx source server.

  3. On the 5.1 server (migration node), copy the WP5xx_MP_Express_Patch.jar file from <wp_root> /migration/efixes to a temporary directory on the 5.xx server (where xx is the version of your source server).

  4. On the 5.xx server, type the following command: jar -xvf WP5xx_MP_Express_Patch.jar (where xx is the version of your source server.)

  5. For information on the fixes contained in the patch, refer to the ReadMe.txt files that are the output from the jar command.

  6. Open a command prompt/shell on the 5.xx server and change to the directory containing the latest Portal UpdateInstaller. For each jar file output in the temporary directory created by step 4, use updatePortal.sh or updatePortalWizard.sh to install each of the jar files. Be sure to run this command on each jar in numerical order; for example, PQ76366 before PQ91600.

  7. Restart the previous version of WebSphere Portal.

To confirm that the fixes were applied correctly to the 5.xx server, there should be a corresponding efix entry in <wp_root>/version for each of the installed jar files.

The following examples of commands assume that you have previously downloaded the Update installer in the <wp_root> /update directory and the fix pack in the <wp_root> /update/fixpacks directory. If you have used different directories for either of these locations, adjust the remaining instructions in this section accordingly.

Standalone WebSphere Portal:

This step is only necessary when migrating from WebSphere Portal V5.00. It is not required for other WebSphere Portal 5.0x levels, such as WebSphere Portal V5.0.2.

From the directory where you downloaded the update installer, enter a command similar to the following: C:\Program Files\WebSphere\PortalServer\update> updatePortal -fix

-installDir "C:\Program Files\WebSphere\PortalServer"

-fixDir "C:\Program Files\WebSphere\PortalServer\update\fixes" (from step 3)

-install

-fixJars PQ77683_WP50_iFix.jar

Although this command is shown on multiple lines for clarity, it should be entered on the same line. For detailed instructions on using the Update installer, refer to the WebSphere Portal Update installer README file provided with the Update installer.

WebSphere Portal in a cluster environment:

This step is only necessary when migrating from WebSphere Portal V5.00. It is not required for other WebSphere Portal 5.0x levels, such as WebSphere Portal V5.0.2.

If WebSphere Portal is also federated into Deployment Manager, that means that aspects of WebSphere Portal's configuration and runtime support are being managed centrally by Deployment Manager. To apply the interim fix, create a file named wpwasdm.properties with the following contents: WasDM=true

The WasDM property indicates that the update installer should perform its update through Deployment Manager, rather than as if WebSphere Application Server and WebSphere Portal are on the same node.

apply the interim fix to each node in the cluster.

From the directory where you downloaded the update installer, enter a command similar to the following: C:\Program Files\WebSphere\PortalServer\update> updatePortal -fix

-installDir "C:\Program Files\WebSphere\PortalServer"

-fixDir "C:\Program Files\WebSphere\PortalServer\update\fixes" (from step 3)

-install

-fixJars PQ77683_WP50_iFix.jar

-configProperties ./wpwasdm.properties

Although this command is shown on multiple lines for clarity, it should be entered on the same line.

Progress note: During the installation of fixes, you may see the message "BUILD SUCCESSFUL" appear, and the update installer may appear to hang. Do not interrupt the update installer. The update installer is still running. The "BUILD SUCCESSFUL" message is appearing due to the completion of a WebSphere Portal configuration task, which is a small part of the overall interim fix being applied. When it has completed, the update installer will show "End of [ updatePortal.bat ]" on the console for machines running Windows or "End of [ updatePortal.sh ]" for machines running UNIX or Linux.

 

3: Apply additional fix if using an External Security Manager

If you are using an External Security Manager with your WebSphere Portal V4.x system.

The fix file ESMmigration_416_421_422_MP_Express.jar is provided in the <wps> /migration/efixes directory. Complete the following instructions to apply the fix.

  1. Stop your WebSphere Portal V4.x system.

  2. Open a command prompt/shell.

  3. Copy the ESMmigration_416_421_422_MP_Express.jar file to the $WAS_HOME/lib/app directory.

  4. Change to the $WAS_HOME/lib/app directory.

  5. Extract the files by entering the following information on the command line:

    jar -xvf ESMmigration_416_421_422_MP_Express.jar

  6. Modify $WAS_HOME /lib/app/config/services.properties depending on the type of External Security Manager you are using and the version of your WebSphere Portal V4.x system:

    Tivoli Access Manager:

    • For WebSphere Portal V4.1.6:

      com.ibm.wps.services.authorization.ExternalAccessControlService = com.ibm.wps.services.authorization.PDExternalAccessControlImpl41mig

    • For WebSphere Portal Versions 4.2.1 and 4.2.2:

      com.ibm.wps.services.authorization.ExternalAccessControlService = com.ibm.wps.services.authorization.PDExternalAccessControlImpl42mig

    SiteMinder:

    • For WebSphere Portal V4.1.6:

      com.ibm.wps.services.authorization.ExternalAccessControlService = com.ibm.wps.services.authorization.SiteminderExternalAccessControlImpl41mig

    • For WebSphere Portal Versions 4.2.1 and 4.2.2:

      com.ibm.wps.services.authorization.ExternalAccessControlService = com.ibm.wps.services.authorization.SiteminderExternalAccessControlImpl42mig

  7. Remove the file ESMmigration_416_421_422_MP_Express.jar from the $WAS_HOME /lib/app directory.

  8. Restart WebSphere Portal V4.x.

 

4: Specify values in the properties files

edit at least two files that are provided in the migration directory: mig_core.properties and mig_wmm.properties. These files contain values that must be correctly set for migration and allow you invoke various migration tasks without supplying individual parameters on the command line. Mig_core.properties allows you to modify the core migration properties and mig_wmm.properties allows you to modify properties that are related to Member Manager. The files are automatically read during migration tasks and have placeholders for required and optional parameters for all associated migration tasks. If the required parameters are not specified in these files or on the command line, the migration task will halt. See Migration properties and Migration tasks for more information.

Complete the following tasks:

  1. Edit the required properties in the mig_core.properties and mig_wmm.properties files. If you are migrating WebSphere Portal content publishing, edit the mig_wpcp.properties file.

  2. Copy the wps.properties file from the <wp4_root> directory of your WebSphere Portal V4.x installation into the <wp51_root>/migration directory of the WebSphere Portal V5.1 system, where <wp4_root> is the root directory of your WebSphere Portal V4.x system and where <wp51_root> is the root directory of your WebSphere Portal V5.1 system. This file contains the version information for your WebSphere Portal V4.x system, which will be used to select an appropriate migration path.

    Migration tasks get the WebSphere Portal V5.1 configuration information from <wp51_root>/config/wpconfig.properties. The migration package by default is installed in the <wp51_root>/migration directory and thus, this file can be accessed. The parameters in the <wp51_root>/config/wpconfig.properties file will be automatically loaded during migration task initialization.

  3. If you have WebSphere Portal V4.1.2, the WPFamilyName key must be added to the wps.properties file. Add the following line to wps.properties file, depending on your offering of WebSphere Portal:

    Enable: WPFamilyName=enable

    Extend: WPFamilyName=extend

    Experience: WPFamilyName=experience

  4. Leave the WPInstallLocation4x property in the mig_core.properties file blank if the location where WebSphere Portal V4.x is installed is not accessible from the machine that is running the migration tasks. If you leave the WPInstallLocation4x property blank, copy any updated custom themes and skins to the WebSphere Portal V5.1 system.

    Themes and skins do not reside directly in the themes and skins directories. They are actually in html, wml, or chtml directories inside the themes or skins directory.

    Copy these files from the WebSphere Portal V4.x system... to this location on the WebSphere Portal V5.1 system
    <wp4_root>/app/wps.ear/wps.war/themes $WAS_HOME/installedApps/<node_name>/wps.ear/wps.war/themes
    <wp4_root>/app/wps.ear/wps.war/skins $WAS_HOME/installedApps/<node_name>/wps.ear/wps.war/skins

    where:

    • <wp4_root>is the installation root directory of WebSphere Portal V4.x.

    • $WAS_HOME is the installation root directory of WebSphere Application Server V5.0.

    • <node_name> is the node on which WebSphere Portal is installed.

 

5: Make portlet applications available to migration tasks for deployment

The <wp4_root>/deployed directory contains a list of all portlet applications that are deployed on your WebSphere Portal V4.x system. Depending on the features that are used by these portlets, they might have to first be upgraded to work with WebSphere Portal V5.1. Refer to the instructions that are provided in the Manual migration steps section to determine if upgrade your portlets.

Some of the WAR files in the <wp4_root>/deployed directory might have been shipped with WebSphere Portal V4.x. In that case, there is no need to manually upgrade corresponding portlets. You can safely use the corresponding WAR file from the wp51_root/installableApps directory as an upgraded version of the portlet.

Before running migration tasks, all the upgraded portlets must be made available to your WebSphere Portal V5.1 system. Mig_core.properties provides an appsPath parameter that accepts a URL value that is passed to the WebSphere Portal V5.1 system when deploying the portlets. Unless this URL is accessible from the WebSphere Portal V5.1 system, migration tasks that deploy portlets will fail. The default value for appsPath is file://<localhost>/$server_root$/installableApps, which translates to <wp51_root>/installableApps at run time. If you have not modified this value, copy all the upgraded portlets to this directory. This directory has the sample portlets that ship with WebSphere Portal V5.1, so verify you do not overwrite these with sample versions that shipped with earlier versions of WebSphere Portal. It is recommended that you instead use the sample versions that are shipped with WebSphere Portal V5.1. Also, copy any custom portlet WAR files to the <wp51_root>/installableApps directory.

Note the following information:

  • In V4.x, the name of the resource must be specified in includePages or excludePages.

  • In V5.x, a unique name must be assigned to the object in the source server and then specified in includePages or excludePages. To set a unique name, log in to the source server as an administrator, select Administration > Portal Settings > Custom Unique Names, and then select the type of resource you want to migrate. After you select a type, a list of resources currently residing on that server is displayed, including the Resource Names, Unique Identifiers, and the Custom Names. Use the value displayed in the Custom Name field of the resource you want to specify in includePages or excludePages. If no Custom Name exists, assign one to the resource in order to migrate it individually.

If you did specify a different value for appsPath parameter, verify this path contains the WebSphere Portal V5.1 version of all portlets that are deployed on your WebSphere Portal V4.x system.

 

6: Prepare to migrate WebSphere Member Services

This section describes the preparatory tasks that complete before invoking the migrate-wmm command. Actual migration of user attributes will occur when you invoke this command as described in the Run the migration tasks section.

In order to migrate WebSphere Member Services, have one of the following options installed:

  • A database client on the machine where the migration tasks are running

  • A database server on the machine where the migration tasks are running

In addition, catalog the WebSphere Member Services database on the the V5.1 Portal Server's database server or client.

WebSphere Member Services will not work if there is neither a database client nor a database server installed on the machine where the migration code runs.

6.1: You might be able to skip step 7, if you do not store additional attributes in a Lookaside database.

If your WebSphere Portal V4.x was configured to use LDAP, the WebSphere Member Service database always acted as a Lookaside database. In most cases the Lookaside database only stores duplicate information that is already stored in LDAP, with the exception of the case when you are storing additional attributes that are not present in LDAP. The enhanced version of WebSphere Member Service, known as Member Manager in WebSphere Portal V5.1, allows you to use LDAP only and not use the Lookaside database if all the information about your users and groups is already in LDAP. This eliminates storing duplicate data in the Lookaside database. In the case when all your attributes are stored in LDAP, you can configure WebSphere Portal V5.1 to use the LDAP, and not the Lookaside database.

Use the following procedure to determine if your WebSphere Portal V4.x Lookaside database contains information that is not stored in LDAP.

  1. Locate the attributeMap.xml file from the <wp4_root>/wms/xml directory, where <wp4_root> is the root installation directory of WebSphere Portal V4.x. This file lists all the user attributes that are stored in your LDAP.

  2. Look in this file to determine if you are using attributes that are not stored in your LDAP.

    If you are using attributes that are not listed in this file, your Lookaside database on WebSphere Portal V4.x has information that will need to be migrated using the migrate-wmm task. This will also require that you configure your WebSphere Portal V5.1 to use LDAP and Lookaside database.

If you are not using a Lookaside database, it is not necessary to perform migration using the migrate-wmm task or to perform the preparatory steps. You can skip to step 8.

If you plan to use the migrate-all or import-all tasks to migrate other artifacts, you can skip the internal call to the migrate-wmm task by using the skipWmmMigration parameter, which can be supplied on a command line or can be put in the <wp51_root>/migration/mig_wmm.properties file. This parameter accepts the values true or false. The following examples illustrate the use of this parameter on the command line:

  • Windows: WPMigrate.bat migrate-all -DskipWmmMigration=true

  • UNIX: ./WPMigrate.sh migrate-all -DskipWmmMigration=true

Additional examples are provided within the migration steps.

 

6.2: Preparatory steps

Complete the following preparatory steps:

  1. Copy the files attributeMap.xml and attributeMap.dtd from the <wp4_root>/wms/xml directory of the WebSphere Portal V4.x installation to the <wp51_root>/migration/templates/wmm/xml/migration directory of WebSphere Portal V5.1.

    Skip the next step (step 2) if you do not use extended user attributes on your WebSphere Portal V4.x system.

  2. To migrate additional user attributes other than the seven that are migrated by default (uid, userPassword, cn, sn, mail, preferredLanguage, and givenName), complete the following steps:

    1. Modify the appropriate files listed here. These files are located in the WebSphere Portal V5.1 directory <wp51_root>/migration/templates/wmm/xml/migration:

      • wmmDBAttributes.xml: used only for database-only WebSphere Member Services configurations. Specifies the Member Manager attributes that will be inserted into the WMMDBATR table.

      • wmmLAAttributes.xml: used only for database + LDAP WebSphere Member Services configurations. Specifies the Member Manager attributes that will be inserted into the WMMLAATR table.

      • wmmMigrationAttributesInfo.xml: instructs the migration utility where the attribute value data is coming from for each of the attributes that is specified in the wmmDBAttributes.xml or the wmmLAAttributes.xml file. Attributes can originate from two sources:

        • The WebSphere Member Services MBRATTR table and their corresponding attribute values come from the WebSphere Member Services MBRATTRVAL table.

        • Column names for certain WebSphere Member Services tables can become attributes in Member Manager and their corresponding attribute values will be the data under the WebSphere Member Services column name. For example, if the column Registration in the USERS table has been used explicitly to store meaningful data, then the column name Registration becomes an attribute and its data becomes its attribute values.

    2. The following steps migrate an additional WebSphere Member Services attribute (a1) to a Member Manager attribute (a2):

      a1 can be the same as a2.

      1. Add the following section in the wmmXXAttributes.xml file: 
        <attributeMap   wmmAttributeName=a2
                        pluginAttributeName=a2
                        applicableMemberTypes=Person;Group
                        dataType=String
                        valueLength=256
                        multiValued=true />

        where:

        • wmmAttributeName is the attribute name in Member Manager

        • pluginAttributeName is the plug-in attribute name in LDAP

        • applicabeMemberTypes is the member types to which the attribute is applicable. The values can be Person, Group, Organization, or OrganizationalUnit.

        • dataType is the data type of the attribute. The possible values are String, Integer, Double, Long, and Timestamp.

        • valueLength is the maximum length of the attribute value (This parameter is optional and only applies to the String data type).

        • multiValued is a flag that specifies if the attribute is multivalued (true/false).

      2. For attribute a1, specify in the wmmMigrationAttributesInfo.xml file where the attribute values for a1 are coming from. For example, if the attribute a1 comes from the MBRATTR table, add the following section: 
        <AttributeInfo  tableName=MBRATTR
                        wmsAttributeName=a1
                        attributeType=String
                        wmmAttributeName=a2 />

        where:

        • tableName is the table where the attribute is coming from

        • wmsAttributeName is the attribute name in the WebSphere Member Services MBRATTR table

        • attributeType is the data type of the attribute. The possible values are String, Integer, Double, Long, and Timestamp.

        • wmmAttributeName is the Member Manager attribute name that you specify in the wmmDBAttributes.xml or wmmLAAttributes.xml file.

      3. If the WebSphere Member Services attribute a1 comes from the column name C1 of a table T1, add the following information: 
        <AttributeInfo  tableName=T1
                        wmsColumnName=C1
                        attributeType=String
                        wmmAttributeName=a2 />

        where:

        • tableName is the table where the attribute is coming from

        • wmsColumnName is the column name of the WebSphere Member Services table T1 from which the attribute value data is coming.

        • attributeType is the data type of the attribute. The possible values are String, Integer, Double, Long, and Timestamp.

        • wmmAttributeName is the Member Manager attribute name that you specify in the wmmDBAttributes.xml or wmmLAAttributes.xml file.

 

6.3: Setting parameters related to WebSphere the Member Manager uuid

When the Member Manager is configured to use a Lookaside repository, some member attributes are accessed from the main profile repository (LDAP server), while others that are specific to WebSphere Portal are stored in the Lookaside repository (Member Manager database). The association between the data in the main profile repository and the data in the Lookaside repository must be maintained.

Every member in the profile repository should have an attribute whose value includes the following characteristics:

  • Uniquely identifies the member from all other members in the same profile repository

  • Does not change after it is set

  • Will not be reused even if the member is deleted

The attribute that is previously described can be used to associate data for a member in the main profile repository and data for the same member in the Lookaside repository. This attribute is referred to as uuid.

The format of uuid might follow the string form for a DCE-style uuid (for example, 1D919000-C758-1C34-92BD-001212121212). For IBM Directory Server 5.1, an attribute already exists to uniquely identify an LDAP entry called ibm-appUUID. For Active Directory server, there is the attribute objectGUID that uniquely identifies an LDAP entry.

The LdapHasUuid property in the the mig_wmm.properties file is the name of the attribute in the LDAP that is storing the uuid. The value for the LdapHasUuid property in the mig_wmm.properties file must be correctly set before you run the migrate-wmm task. The LdapHasUuid property indicates whether or not the LDAP server already has a uuid attribute defined and that all users from WebSphere Portal V4.x whose main profiles are stored in LDAP have a unique, static, and never reused value associated with their profile in the LDAP. Before you run the migrate-wmm task, verify the value that you specify for LdapHasUuid is correct in terms of how the uuid attribute is set on your LDAP.

If LdapHasUuid is set to true, the migrate-wmm task will read this value and populate the WebSphere Member Manager Lookaside database with this information in order to establish a mapping between the main profile that is stored in LDAP and the WebSphere Portal specific profile that is stored in the Lookaside database.

It is possible that your LDAP server already defines an attribute that can store a unique, static, and never reused value. However, the profile of members accessed from LDAP by WebSphere Portal V4.x might not have a unique value associated with it because WebSphere Portal V4.x did not make use of the uuid attribute. In this case, specify a false value for LdapHasUuid.

If LdapHasUuid is set to false, specify values for the LdapUuidName and LdapAuxiliaryClassName properties. The migrate-wmm task will then generate a uuid value for each user defined in the WebSphere Member Services Member table in WebSphere Portal V 4.x, store the generated value in the uuid attribute, and then attach the auxiliary object to the corresponding LDAP entry (if none exists). However, this would mean that the Member Manager migration will write to the LDAP directory. It also means that the user identified by the LDAPAdminUId and LDAPAdminPwd parameters defined in your <wp51_root>/config/wpconfig.properties file must have write access to your LDAP server. Otherwise, the migrate-wmm task will fail.

Depending on your setup, open the mig_wmm.properties file and complete the following steps according to one of the following scenarios: Case 1: If a uuid has been identified, then set the parameter LdapHasUuid to true and set the parameter LdapUuidName to the uuid attribute name. For example, for IBM Directory Server 5.1, if you identified the ibm-appUUID attribute as the uuid, then you would set the parameter LdapUuidName to ibm-appUUID. Similarly, for Active Directory, if the objectGUID attribute is identified as the attribute that uniquely identifies an LDAP entry, then set the parameter LdapUuidName to objectGUID.

Case 2: If a uuid has not been defined on the LDAP:

  1. Set the parameter LdapHasUuid to false.

  2. Create an attribute in the LDAP directory that will uniquely identify an LDAP entry. For example, create an attribute called ibm-appUUID to store the unique ID of an entry. Then, set the parameter LdapUuidName to the attribute name that you just created. For example, set the LdapUuidName parameter to ibm-appUUID.

  3. Create an auxiliary object class in the LDAP directory and add the attribute that you just created in step 2 as an optional attribute to the auxiliary object class. For example, create an auxiliary object class called ibm-appUUIDAux and add the ibm-appUUID attribute as an optional attribute to the object class. After creating the auxiliary object class, set the parameter LdapAuxiliaryClassName to the auxiliary object class name. For example, set the parameter LdapAuxiliaryClassName to ibm-appUUIDAux.
For Case 2, after the uuid attribute and the auxiliary object class are created, the migrate-wmm migration task will generate a uuid value for each entry in the WebSphere Member Services table, store the generated value in the uuid attribute, and then attach the auxiliary object to the corresponding LDAP entry (if one exists). Following the steps in Case 2 causes the migrate-wmm task to write to the LDAP directory.

Case 3: If you do not want the migrate-wmm task to write to the LDAP server:

  1. Create an attribute that can hold uuid in your LDAP if it does not already exist.

  2. Generate your own uuid for each LDAP entry that is associated with the WebSphere Portal user.

  3. Set the LdapHasUuid flag to true.

 

7: Migrate custom deployment scripts

If you have written custom deployment scripts using the WebSphere Portal V4.x XML configuration interface schema, these scripts will not work directly on WebSphere Portal V5.1. Enter the following command on one line to make the scripts compatible with WebSphere Portal V5.1 XML Configuration Interface schema:

UNIX:

./WPmigrate.sh migrate-xmlaccess-script -DScriptPath=<your_path>

-DScriptSrc=<srcname> -DScriptDest=<destname>

Windows:

WPmigrate.bat migrate-xmlaccess-script -DScriptPath=<your_path>

-DScriptSrc=<srcname> -DScriptDest=<destname>

where:

  • <your_path> is the complete path to your script file.

  • <srcname> is the script file name to be converted.

  • <destname> is the name of the converted script file.

For example, the following command will convert /usr/scripts/my_script.xml and save the converted script to /usr/scripts/my_converted_script.xml:

WPmigrate.sh migrate-xmlaccess-script -DScriptPath=/usr/scripts -DScriptSrc=my_script.xml -DScriptDest=my_converted_script.xml

These scripts can be used later to deploy your custom pages, places, portlet applications, and so on from scratch instead of migrating them from WebSphere Portal V4.x.

 

8: Specify if external access control is migrated

Information in this section is relevant only if you used an external security manager with WebSphere Portal V4.x.

The omit-external-ac parameter in the >wp51_root</migraiton/mig_core.properties file determines whether the migration process automatically externalizes access control that was externalized in WebSphere Portal V4.x. By default, this property is commented out and its value defaults to false, which means that resources with externalized access control in WebSphere Portal are automatically externalized in WebSphere Portal V5.1.

If this value is uncommented and set to true, the migration process does not externalize access control for resources that were externalized in WebSphere Portal V4.x. manually externalize access control in WebSphere Portal V5.1. You might want to set this value to true if:

  • You used an external security manager with WebSphere Portal V4.x but will not use an external security manager with WebSphere Portal V5.1.

  • You prefer to manually externalize access control in WebSphere Portal V5.1.

Follow these steps to set this value to true:

  1. Use a text editor to open the <wp51_root>/migration/mig_core.propeties file.

  2. Uncomment the following property: omitExternalAccessControl=false.

  3. Change the omitExternalAccessControl value to true.

  4. Save and close the file.

 

9: Ensure that all LDAP groups have at least one member

Each group in the WebSphere Portal V4.x LDAP directory must have at least one member (for example, uid=dummy). Otherwise, some of the migration tasks will fail.

 

Next steps

You have completed this step. Continue to the next step by choosing the following topic:

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.

 

Tivoli is a trademark of the IBM Corporation in the United States, other countries, or both.