wpf-mig-ent
TRANSCRIPT
IBM WebSphere Portal for Multiplatforms Version 5.0.2
Migrating Guide
Last updated on May 12, 2005
(c) Copyright 2000, 2005 International Business Machines Corp.
Migrating
Planning
Migration prerequisites
The migration process
Manual migration steps
Preparing to run the migration tasks
Running the migration tasks
With both WebSphere Portal versions running at the same time
One-task migration
Multitask migration
With only one WebSphere Portal version running at a time
Two-task migration
Multitask migration
Verifying the migration tasks
Migrating the remaining access control configuration
Migrating derived pages
Migration properties
Migration tasks
Optional migration tasks
TroubleshootingAdditional resources
Resources for learning
Resources and support
Directory structureGlossaryTrademarks
Migrating to WebSphere Portal Version 5.0 and 5.0.2
This section provides a detailed guide on migrating to WebSphere Portal Version 5.0 and 5.0.2.
References to version 5.0.x are used throughout the migration guide to refer to both version 5.0 and version 5.0.2. However, references to either version 5.0 or version 5.0.2 are still used to point out specific information that pertains only to that version.
The migration steps are organized as follows:
1. Planning2. Migration prerequisites 3. The migration process
❍ Manual migration steps❍ Preparing to run the migration tasks❍ Running the migration tasks
■ With both WebSphere Portal versions running at the same time ■ One-task migration■ Multitask migration
■ With only one WebSphere Portal version running at a time ■ Two-task migration■ Multitask migration
■ Verifying the migration tasks■ Migrating the remaining access control configuration■ Migrating derived pages
For the latest information about this topic, refer to the latest version of the WebSphere Portal InfoCenter at http://www.ibm.com/websphere/portal/library.
Related information● Migration properties● Migration tasks● Optional migration tasks● Troubleshooting
Planning
1: Introduction 1:1 Supported migration paths 1:2 Cluster environments2: WebSphere Portal/Product Offering Table3: Changes introduced in WebSphere Portal Version 5.0 3.1: XML configuration interface changes 3.2: Access control changes 3.3: Custom themes and skins 3.4: Portlets 3.5: Page object ID displayed if language is not supported4: Automated migration tasks 4.1:Tasks using the XML configuration interface 4.2:Tasks using direct database connections5: Manual migration steps6: Migrating bookmarks and internal URLs not currently supported
1: Introduction
The WebSphere Portal Version 5.0.x migration process is a combination of automated and manual steps. The automated steps (also referred to as migration tasks) are executed using ANT 1.4.1 scripts. The migration tasks provide optional granularity to allow for small manageable migration steps, rather than an all-or-none behavior. The manual steps that are performed depend on what features are in place on your WebSphere Portal Version 4.x system. Both processes are described in more detail in The migration process.
1:1: Supported migration paths
The following table details the supported migration paths. The left column indicates the current version of WebSphere Portal, and the right column indicates the version of WebSphere Portal to which you can migrate.
WebSphere Portal 4.x Version 5.0.x Version WebSphere Portal Enable Version 4.1.2, 4.1.3a, 4.1.4, 4.1.5, 4.2, or 4.2.1
WebSphere Portal Enable Version 5.0 or Version 5.0.2
WebSphere Portal Extend Version 4.1.2, 4.1.3a, 4.1.4, 4.1.5, 4.2, or 4.2.1
WebSphere Portal Extend Version 5.0 or Version 5.0.2
WebSphere Portal Experience Version 4.1.2, 4.1.3a, 4.1.4, 4.1.5, 4.2, or 4.2.1
WebSphere Portal Extend Version 5.0 or Version 5.0.2
● Migration to WebSphere Portal Version 5.0.x is supported from WebSphere Portal versions 4.1.2 and higher. ● Migrating from one operating system to another is not supported. For example, you cannot migrate from Windows
to Linux.● Migrating across database servers is not supported. This means that data cannot be migrated from DB2 to Oracle
or vice versa.
1:2: Cluster environments:If you are using WebSphere Portal Version 4.x in a cluster environment, do not migrate the clone nodes to WebSphere Portal Version 5.0.x individually. First, install a stand-alone WebSphere Portal Version 5.0.x that will serve as the new
main node for the WebSphere Portal Version 5.0.x cluster. Migrate data from the WebSphere Portal Version 4.x cluster main node to the WebSphere Portal Version 5.0.x main node. After you have established that migration has completed successfully, create your new clone nodes from the WebSphere Portal Version 5.0.x main node.
2: WebSphere Portal/Product Offering Table
The following table lists software offerings by version number that are shipped with, or supported by, each version of WebSphere Portal.
This information is useful for planning your WebSphere Portal Version 5.0.x installation and migration. For instance, you might find that you need to upgrade your database version before installing WebSphere Portal Version 5.0.x.
Note: Some software that is shown in the table is not shipped with WebSphere Portal and must be purchased separately. For the latest information on the software that WebSphere Portal ships and supports, refer to the InfoCenters for the respective versions.
ProductWebSphere Portal Version
Version 4.1.2
Version 4.1.3a
Version 4.1.4
Version 4.1.5
Version 4.2
Version 4.2.1
Version 5.0 Version 5.0.2
WebSphere Application Server Advanced Edition
4.0 FP2 4.0 FP24.0 FP34.0 FP4
4.0 FP4 4.0 FP44.0 FP5
4.0 FP4 4.0 FP5 5.0 FP1(Enterprise)
5.0 FP2(Enterprise)
WebSphere Application Server Advanced Single Server Editions
4.0 FP2 4.0 FP24.0 FP34.0 FP4
4.0 FP4 4.0 FP44.0 FP5
4.0 FP4 4.0 FP5 N/A N/A
Portal Toolkit N/A N/A 4.24.2.5
4.24.2.5
4.24.2.5
4.24.2.54.3
5.0 5.0.2
WebSphere Studio
4.0.3 4.0.3 4.0.3 4.0.3 4.0.3 5.0 (4.2, 4.2.5 toolkit)5.0.1 (4.3 toolkit)
5.0.1 5.0.1 FP1
IBM Cloudscape
N/A N/A N/A N/A N/A N/A 5.1.30 5.1.30
DB2 Enterprise Edition/Enterprise Server Edition/Workgroup Server Edition/for z/OS
7.2 FP5 7.2 FP57.2 FP7
7.2 FP7 7.2 FP77.2 FP8
7.2 FP7 7.2 FP77.2 FP87.1 (for z/OS)
8.1 FP1 (Workgroup Server Edition/Enterprise Server Edition)7.2 FP7 (Enterprise Edition)7.2 FP8 (Enterprise Edition)7.1 (for z/OS)
8.1 FP1 (Workgroup Server Edition/Enterprise Server Edition)7.2 FP7 (Enterprise Edition)7.2 FP8 (Workgroup Server/Enterprise Edition)7.2 FP9 (Workgroup Server/Enterprise Edition)7.1 (for z/OS)
Oracle 8.1.7 8.1.7 8.1.7 8.1.7 8.1.79.2.0.1
8.1.79.2.0.1
8.1.79.2.0.1
8.1.79.2.0.1
SQL Server 2000
N/A N/A N/A N/A N/A SP3 SP3 SP3
Informix Dynamic Server
N/A N/A N/A N/A N/A 9.39.4
9.39.4
9.39.4
IBM HTTP Server
1.3.19.1 1.3.19.1 1.3.19.3 1.3.19.3 1.3.19.3 1.3.19.4 1.3.26.1 (included with WebSphere Application Server only)
1.3.26.1 (included with WebSphere Application Server only)
IBM Directory Server/Secureway Directory Server
3.2.2 3.2.2 3.2.2 3.2.2 4.1 (IBM Directory Server)
4.1 (IBM Directory Server)
4.1 (IBM Directory Server)5.1 (IBM Directory Server)
4.1 (IBM Directory Server)5.1 (IBM Directory Server)
Sun ONE (formerly iPlanet) Directory Server
5.0 5.0 5.0 5.0 5.0 5.0 5.1 FP2 5.1 FP2
Novell eDirectory
N/A N/A N/A N/A 8.6 8.68.6 8.6
Microsoft Active Directory
2000 2000 2000 2000 2000 2000 2000 2000
Lotus Domino Enterprise Server (as application server)
5.0.8 5.0.8 5.0.8 5.0.8 5.0.9a 5.0.9a 5.0.9a 5.0.12
Lotus Domino Enterprise Server (as Web server)
5.0.8 5.0.8 5.0.8 5.0.8 5.0.9a 5.0.9a 5.0.9a 5.0.9a
Lotus Domino Enterprise Server (as LDAP server)
5.0.5 5.0.5 5.0.9a 5.0.9a 5.0.10 5.0.10 5.0.115.0.126.0
5.0.115.0.126.0
Lotus Collaborative Components
4.1.2 4.1.3 4.1.4 4.1.5 4.2 4.2.1 5.0 5.0.2
Lotus Collaboration Center
N/A N/A N/A N/A N/A N/A 5.0 5.0.2
Productivity Portlets
N/A N/A N/A N/A N/A N/A 5.0 5.0.2
Lotus Workflow 3.0A 3.0A 3.0A 3.0A 3.0A 3.0A N/A N/A
Lotus QuickPlace
2.0.8 2.0.8 2.0.8 2.0.8 3.0 3.0 3.01 3.0.1
Lotus Sametime
2.5 2.5 2.5 2.5 3.0 3.0 3.0 3.03.1
IBM Lotus Extended Search
3.7 3.7 3.7 3.7 3.7 3.7 4.0 4.0
WebSphere Site Analyzer/Tivoli Web Site Analyzer
4.1 4.1 4.1 4.1 4.1.2 4.1.24.5 (Tivoli Web Site Analyzer)
4.5 (Tivoli Web Site Analyzer)
Tivoli Access Manager 3.9 3.9 3.9 3.9 4.1 4.1 4.1 with fix
pack 2 installed
4.1 with fix pack 2 installed
IBM Content Manager 7.1 8.1 8.1 8.1 8.1 8.1 8.2 8.2
WebSphere Portal content publishing
N/A N/A N/A N/A 4.2 4.2 5.0 5.0.2
WebSphere Personalization 4.0.1 4.0.1 4.0.1 4.0.1 N/A N/A N/A N/A
3: Changes introduced in WebSphere Portal Version 5.0
3:1: XML configuration interface changesYou must complete two manual steps to accommodate the XML configuration interface changes in WebSphere Portal Version 5.0.x from WebSphere Portal Version 4.x.
● If you have custom deployment scripts that are written for a previous version of WebSphere Portal, you need to convert these scripts to work with WebSphere Portal Version 5.0.x.
● Exported WebSphere Portal Version 4.x configuration must include mapping to the original object IDs. You must add the include-mapping attribute to the request node of the export request and set its value to true. For example:
<request include-mapping="true"> <portal-action="export"> </request>
Refer to Migration tasks for more information on the migrate-xmlaccess-script command. For a description of the XML configuration interface changes for WebSphere Portal Version 5.0.2, see XML configuration interface - Changes for WebSphere Portal 5.0.2.
3:2: Access control changes
The access control architecture has changed significantly in WebSphere Portal Version 5.0.x. Migration tasks convert the permission-based access control in WebSphere Portal Version 4.x to the new role-based access control that is used in Version 5.0.x. Because of the fundamental differences in access control between WebSphere Portal WebSphere Portal Version 4.x and Version 5.0.x, it is strongly recommended that you thoroughly verify the access to all aspects of
WebSphere Portal Version 5.0.x after the migration process is complete. See the Authorization topic for more information about access control.
Permissions that a principal (a user or group) had in WebSphere Portal Version 4.x are mapped to the appropriate roles in WebSphere Portal Version 5.0.x. The following table illustrates this role mapping.
V4.x Permissions V5.0.x RolesView User
Edit Privileged User
Manage Manager
Delegate Security Administrator
View + Edit Privileged User
View + Manage Manager
View + Delegate Security Administrator + User
Edit + Manage Manager
Edit + Delegate Security Administrator + Privileged User (Migration option: Security Administrator + Editor)
Manage + Delegate Administrator
View + Edit + Manage Manager
View + Edit + Delegate Security Administrator + Privileged User (Migration option: Security Administrator + Editor)
View + Manage + Delegate Administrator
View + Edit + Manage + Delegate Administrator
Create
No longer necessary. In WebSphere Portal Version 5.0.x, principals with the Administrator, Manager, Editor, or Privileged User roles on a resource are automatically allowed to create new resources underneath that resource in the resource hierarchy.
The migration process creates inheritance blocks for all User, Privileged User, Editor, Manager, and Delegator roles on each resource. WebSphere Portal Version 5.0.x supports inheritance of access rights by way of the resource hierarchy. WebSphere Portal Version 4.x did not support this type of inheritance. Thus, role blocks are required to ensure that principals do not gain more access rights than they had in WebSphere Portal Version 4.x.
Administrator and Security Administrator roles cannot be blocked. As a result, principals that had Delegate permission on a resource in WebSphere Portal Version 4.x automatically receive the Security Administrator role on the corresponding WebSphere Portal Version 5.0.x resource and all of its child resources.
Note: It is important that you inspect the access control throughout all aspects of WebSphere Portal Version 5.0.x after completing the migration. Access control might require some changes if the migration process defaults are not suitable in your environment. The fundamental access control differences in WebSphere Portal Version 5.0.x could produce unexpected results.
3.3: Custom themes and skins
The navigation model that is used by themes and skins has also changed significantly in WebSphere Portal Version 5.0.x. Any custom themes and skins that are written for WebSphere Portal Version 4.x must be modified to accommodate these changes. Refer to Manual migration steps for more information.
3.4: Portlets
Most portlets that are written for WebSphere Portal Version 4.x will run unchanged in WebSphere Portal Version 5.0.x. However, there are a few exceptions related to packaging, and Struts portlets have to be manually migrated before deploying the portlets on WebSphere Portal Version 5.0.x. Refer to Manual migration steps for more information.
3.5: Page object ID displayed if language is not supported
If a page does not support any of the languages determined by the portal language selection process, then the object ID of the page is displayed in the navigation rather than its title. Such an object ID can be, for example, 7_0_5T. For details about the language selection process, see Language determined by the portal.
4: Automated migration tasks
Automated migration tasks are performed by running a series of commands. These commands are explained in more detail in the Running the migration tasks section. Automated migration tasks fall into two categories:
● Tasks using the XML configuration interface● Tasks using direct database connections
4.1: Tasks using the XML configuration interface
The XML configuration interface utility is supplied with WebSphere Portal. It allows access to portal data in XML format, independent of the underlying physical database that is used by WebSphere Portal.
The migration tasks make use of the XML configuration interface that is supplied with both the WebSphere Portal Version 4.x and WebSphere Portal Version 5.0.x systems. The version of the XML configuration interface that is supplied with your WebSphere Portal Version 4.x system is first used to extract portal data to XML files. These files are then supplied as input to the WebSphere Portal Version 5.0.x XML configuration interface to import data into the WebSphere Portal Version 5.0.x system.
Note: The XML configuration interface requires that WebSphere Portal is running and operational. This means that in order to use these tasks, both WebSphere Portal Version 4.x and WebSphere Portal Version 5.0.x must be running. Even if you have chosen the "only one system running at a time" scenario, both systems will be running at the same time at some point during the migration process.
It is possible to install WebSphere Portal Version 5.0.x on the same machine as WebSphere Portal Version 4.x. See the section on Software that can be installed on the portal machine under the Planning Considerations topic for coexistence restrictions on other products that are shipped with WebSphere Portal. When both versions are installed on the same machine, however, resource limitations might prohibit them from running at the same time. Therefore, you can also accomplish the migration tasks in two distinct steps: export and import. During export steps, WebSphere Portal Version 4.x should be running. During import steps, WebSphere Portal Version 5.0.x should be running.
The following WebSphere Portal artifacts are migrated using the XML configuration interface category of tasks:
● Client configuration:Configuration information for all clients that are supported by WebSphere Portal.
● Themes and skins configuration: Configuration information for custom themes and skins for WebSphere Portal. This configuration information includes locale-specific titles for your themes and skins and information on what skins are allowed for the themes.
Note:The Java server pages, cascading style sheets, and other artifacts that are used to implement your custom themes and skins must be migrated manually.
● Portlet applications and portlets: Migration tasks are provided to facilitate deployment of your custom portlet applications to WebSphere Portal Version 5.0.x. In addition to the deployment, these tasks also migrate the associated access control information. Refer to the Migrate custom portlet code section of Manual migration steps to determine if you need to update your portlets before deploying them to WebSphere Portal Version 5.0.x.
Note:In past releases WebSphere Portal supplied multiple portlets for each of the Notes/iNotes functions (e-mail, calendar, and so on). WebSphere Portal Version 5.0.x includes a single Notes and iNotes portlet. The migration procedures will handle this portlet merge to ensure that all portlet data is maintained during the migration.
● Portal pages, places, and favorites: The corresponding access control is migrated automatically with these artifacts.
● User customizations: Customizations created by portal users having EDIT but not MANAGE permissions on a page by editing a portlet or rearranging portlets on the page.
● Access control on user groups: Tasks migrate permissions on most user groups within the portal. The XML configuration interface task does not migrate permissions on All Authenticated Users and All Anonymous Users. These permissions must be migrated with a manual procedure that is described in the Migrating remaining access control configuration section.
4.2: Tasks using direct database connections
These tasks use a direct connection to the physical databases in WebSphere Portal Version 4.x and WebSphere Portal Version 5.0.x and do not require that WebSphere Portal be running during their invocation.
The following portal artifacts are migrated using this category of tasks:
● Users, groups, and their extended attributes: WebSphere Portal Version 4.x used WebSphere Member Services for managing portal users and groups. WebSphere Portal Version 5.0.x uses the new enhanced version of WebSphere Member Services, now referred to as Member Manager. If WebSphere Portal is configured to use LDAP, the users and groups information will instead be stored in LDAP and will not need to be migrated. Any other data that is stored in the WebSphere Member Services database would need to be migrated.Note:The WebSphere Member Services database must be cataloged locally in order to migrate WebSphere Member Services data to Member Manager.
● Personalization and content publishing: WebSphere Portal Version 4.1.x supported Personalization Version 4.0.x and WebSphere Content Publisher Version 4.1. WebSphere Portal Version 4.2.x enhanced these offerings and combined them under the WebSphere Portal content publishing Version 4.2.x. Depending on your WebSphere Portal environment, the following artifacts will be migrated:
❍ WebSphere Content Publisher Version 4.1 - Projects, ACLs, Publish Servers, Jobs❍ WebSphere Portal content publishing Version 4.2.x - Projects, ACLs, Publish Servers, Jobs,
Personalization Run time
Note:Based on your environment, the WebSphere Content Publisher Version 4.1 or WebSphere Portal content publishing Version 4.2.x database must be cataloged locally in order to be migrated. Migration tasks that are provided with WebSphere Portal Version 5.0.x will not migrate Personalization. If you are using Personalization in your current WebSphere Portal offering, use the WebSphere Portal content publishing Administration page user interface in WebSphere Portal Version 5.0.x to migrate this data.
5: Manual migration steps
Manual migration steps require more specific action than simply running commands. Refer to the Manual migration steps section for more detailed information on portal artifacts that require manual migration.
The following items must be migrated manually:
● Portlets❍ Require manual upgrade of struts portlets built with previous Struts Framework to Struts 1.1 RC 1
supported by WebSphere Portal Version 5.0.x.❍ Require repackaging of Click-to-Action portlets to update the pbportlet.jar.
● Access Control
❍ Access control for administrative places, pages, and portlets❍ Access control for WebSphere Portal and Resource Types ❍ Credential vault data
● Themes and skins❍ The Java server pages, cascading style sheets, and other artifacts used to implement custom themes and
skins
● Personalization and content publishing❍ Personalization Version 4.0.x: Resource Classes❍ WebSphere Content Publisher Version 4.1: Workflow processes, wizard-generated resource classes, CVS
content (unless by way of export/import) ❍ WebSphere Portal content publishing Version 4.2.x: Workflow processes, Concurrent Version Systems
content (unless by way of export/import), ClearCase content (unless by way of export/import), and Archives. Migration of wizard-generated resource classes is not required, but they should be regenerated to take advantage of new function. Templates do not need to be migrated.
● Other❍ Property files, markups, and global and service settings are node and version specific and should be
replaced by the configuration changes that are made to the WebSphere Portal Version 5.0.x system.
6: Migrating bookmarks and internal URLs not currently supported
The migration of bookmarks or the internal URLs for your WebSphere Portal Version 4.x is currently not supported. Support for migrating bookmarks and internal URLs is scheduled to be available in the future.
Next steps
You have completed this step. Continue to the next step by choosing the following topic:
● Migration prerequisites
Migration prerequisites
Thoroughly review the following list of prerequisites for migration before starting the migration process:
● You must install and configure all components of WebSphere Portal Version 5.0.x before attempting migration. This includes setting up the database that you plan to use, LDAP, and so on. Verify that WebSphere Portal Version 5.0.x is operational before you begin migration. See Installing for instructions. Note: Defer any major customizations to your WebSphere Portal Version 5.0.x system until after completion of migration. It is also recommended that migration be performed on a relatively pristine WebSphere Portal Version 5.0.x system to avoid potential conflicts.
● An operational WebSphere Portal Version 4.x environment is a prerequisite for a complete end-to-end migration. Installation of WebSphere Portal Version 5.0.x keeps your previous version of WebSphere Portal intact. This means that if you install WebSphere Portal Version 5.0.x on the same machine as WebSphere Portal Version 4.x, the version 4.x system will remain unchanged. Migration tasks will simply extract data from your WebSphere Portal Version 4.x environment and import it to the WebSphere Portal Version 5.0.x system.
● You must configure Lotus Collaborative Components before you begin migration. See the Enable Lotus Collaborative Components section for more information.
● In order to run Member Manager migration, you must have one of the following elements 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
● It is strongly recommended that you apply the Version 5.0 migration interim fix or the Version 5.0.2 fix pack before attempting migration to WebSphere Portal Version 5.0.x.
● If you have successfully completed and verified some migration tasks before applying the migration interim fix, you do not need to run them again. In other words, after applying the interim fix, continue with the tasks, rather than rerunning the tasks that were successful.
● WebSphere Portal Version 5.0.x does not support Portal Content Organizer portlets. The replacement for Portal Content Organizer portlets is the Document Manager portlet, and there is no migration path from the Portal Content Organizer portlet to the Document Manager portlet. If you have Portal Content Organizer portlets included on a page in WebSphere Portal Version 4.x that you plan to migrate, remove them from the page before running migration tasks.
● You must manually migrate the LDAP database of the WebSphere Portal Version 4.x system to the LDAP server of the WebSphere Portal Version 5.0.x system if the two versions are not using the same LDAP server.
● If two portals will be configured to the same WebSEAL machine during the migration process, and the JMT mapping option is being used, make sure that the context roots for the portals are different. For example, if you will be performing the migration with both the WebSphere Portal Version 4.x and the WebSphere Portal Version 5.0.x systems running at the same time, make the context root for the WebSphere Portal Version 4.x system at /wps/ and the context root for the WebSphere Portal Version 5.0.x system at /wpsv5/. The JMT mapping option cannot map two junctions to the same pattern. For more information about enabling the JMT function, see Configuring Tivoli Access Manager to perform authentication for WebSphere Portal and the WebSEAL Administrator's Guide.
● If you have WebSphere Portal Version 4.2.1 and are running Tivoli Access Manager, you must apply Tivoli Access Manager Fix Pack 2 or higher before migrating to WebSphere Portal Version 5.0.x. In order to apply the Tivoli Access Manager fix pack, you must also apply LDAP Fix Pack 2 to both the server and clients. After this is done, you must apply a patch (P411W-02D) to the LDAP server in order to start WebSphere Portal Version 4.2.1.
● You must catalog remote WebSphere Member Service and WebSphere Portal content publishing databases. The WebSphere Member Service database, which is used in WebSphere Portal Version 4.x to access users and groups, must be cataloged. The Personalization/WebSphere Content Publishing database should be cataloged locally if it is remote to the machine that is running WebSphere Portal Version 5.0.x.
Next steps
You have completed this step. Continue to the next step by choosing the following topic:
● The migration process
The migration process
This section provides an overview of the sequence of steps that are involved in the migration process.
1. Manual migration steps
First, complete the necessary manual migration steps. These depend on the specific features that you have implemented on WebSphere Portal Version 4.x and want to migrate to WebSphere Portal Version 5.0.x.
2. Preparing to run the migration tasks
Then complete the steps in this section in order to run the migration tasks.3. Running the migration tasks
In this section, choose a set of tasks depending on how WebSphere Portal Version 4.x and WebSphere Portal Version 5.0.x are set up. Either select to run the migration tasks with both versions running at the same timeor with only one version running at a time. After you choose one of these scenarios, then choose a series of migration steps to run based on how much individualized control you want to have over the specific elements that are migrated. You can verify almost every migration task after you run it by clicking the link that is provided in each step that points to a specific section of Verifying the migration tasks.
4. Migrating the remaining access control configuration
After you have successfully run the migration tasks, finish migrating access control.
Important note: Before you begin the migration process, you must install and configure WebSphere Portal Version 5.0.x. Refer to Installing and Installing coexisting WebSphere Portal products on the same machine for instructions.
Note the following information:
● You should install and configure all components of WebSphere Portal Version 5.0.x before continuing. This includes setting up the database that you plan to use, LDAP, and so on.
● You must configure Lotus Collaborative Components in order to migrate Notes and iNotes portlets. See the Enable Lotus Collaborative Components section for more information.
The Optional migration tasks, Migration properties, Migration tasks, and Troubleshooting sections are provided as references.
Next steps
You have completed this step. Continue to the next step by choosing the following topic:
● Manual migration steps
Manual migration steps
Note: These steps are optional depending on your level of customization. You only need to perform the following steps that are relevant to your WebSphere Portal. For example, if you do not have custom themes and skins, you do not need to follow the steps in the Migrating themes, skins, and style sheets section.
1: Moving an existing Portlet Project to WebSphere Studio Version 5.0 Products 2: Migrating WebSphere Studio Version 4.0 to Version 5.03: Changing the class path and taglib descriptor for WebSphere Portal Version 5.0.x4: Migrating themes and skins 4.1: Updates to engine tags 4.2: Suggested migration steps5: Migrating custom portlet code6: Migrating Click-to-Action portlets7: Migrating portlets built with the Struts Portlet Framework 7.1: Determining the version of the Struts Portlet Framework 7.2: Migrating from Struts Portlet Framework with Struts 1.1 Beta 2 7.3: Migrating from Struts Portlet Framework with Struts 1.1 RC 18: Migrating collaborative portlets9: Transcoding Technology migration10: Verifying updated portlets
1: Moving an existing Portlet Project to WebSphere Studio Version 5.0 Products
WebSphere Studio Products come in the following four offerings. These four offerings are supported by Portal Toolkit 5.0 and 5.0.2:
● WebSphere Studio Site Developer● WebSphere Studio Application Developer● WebSphere Studio Application Developer Integration Edition● WebSphere Studio Enterprise Developer
Follow these steps to migrate WebSphere Studio Products, Portal Toolkit 4.x, and their associated projects to WebSphere Studio Product 5.01 and Portal Toolkit 5.0 and 5.0.2:
1. Export each portlet application project to WAR files with source files.2. Uninstall the previous version of Portal Toolkit and WebSphere Studio Product (WebSphere Studio
Site Developer or WebSphere Studio Application Developer) 4.0.3.3. Install WebSphere Studio Product 5.01 and necessary fixes.4. Install Portal Toolkit 5.0 or 5.0.2.5. Create a new portlet application project, specifying the Create empty portlet and J2EE Level 1.2/
WebSphere Portal 4.2 option. 6. Import the WAR files that were exported in Step 1 to the new portlet application project.7. Turn off the Overwrite existing resources without warning option.
8. Answer No to Overwrite portlet.tld.9. Answer Yes to Overwrite portlet.xml and web.xml.
Note: You must use a new workspace after installing the new version of WebSphere Studio.
2: Migrating WebSphere Studio Version 4.0 to Version 5.0
In order to migrate projects, you must update any version 4.0 Web project that contains J2EE Web project resources to WebSphere Studio Version 5.0. The steps you take to update the Web projects depend on which version of WebSphere Application Server you are using. Follow the steps under the appropriate case:
Case 1: Moving a WebSphere Studio project to WebSphere Studio Version 5.0, while continuing to use WebSphere Application Server 4.x and WebSphere Portal Version 4.x:
1. Display the context menu for the project and select Migrate J2EE Migration Wizard.2. Select all of the projects that you would like to migrate, and deselect the box that says Migrate
project from version level J2EE 1.2 to J2EE 1.3.Note: This is an important step because J2EE 1.3 Web projects are supported on WebSphere Application Server Version 5.0 but not on version 4.0.
3. Then click Finish.
Case 2: Moving a WebSphere Studio Version 4.x project to WebSphere Studio Version 5.0, while using WebSphere Application Server 5.0 and WebSphere Portal Version 5.0.x:
1. Display the context menu for the project and select Migrate J2EE Migration Wizard.2. Select all of the projects that you would like to migrate. Do not deselect the box that says Migrate
project from version level J2EE 1.2 to J2EE 1.3.3. Then click Finish.
Note: Resource classes that are generated with wizards other than those contained in the version 5.0 plug-in will not allow the resources to be used for content management by IBM Content Manager. Resources from version 4.2 or later might be regenerated as part of the project migration in WebSphere Studio. You can regenerate the resources by right-clicking on the HRF file and selecting the option for resource regeneration. HRF files can be found in <was_root>/personalization/publishedResources. Resources that are generated prior to version 4.2 will have to be re-created by going through the wizard and remodeling the resource. Resources that are generated prior to version 5 can still be used at run time on version 5.0.
3: Changing the class path and taglib descriptor for WebSphere Portal Version 5.0.x
Portlet Projects that are migrated from WebSphere Portal Version 4.x need to be updated with the class path and taglib descriptor for WebSphere Portal Version 5.0.x.
1. Select your portlet project in Studio J2EE Navigator view.2. Select File Properties.3. Select Java build path.4. You find the following definition for WebSphere Portal Version 4.x:
<classpathentry kind="var" path="WPS_PLUGINDIR/portlet-api.jar"/>
<classpathentry kind="var" path="WPS_PLUGINDIR/wpsportlets.jar"/><classpathentry kind="var" path="WPS_PLUGINDIR/wps.jar"/>
Change these definitions so that they will work in WebSphere Portal Version 5.0.x:
<classpathentry kind="var" path="SERVERJDK_50_PLUGINDIR/jre/lib/rt.jar"/><classpathentry kind="var" path="WAS_50_PLUGINDIR/lib/cm.jar"/><classpathentry kind="var" path="WAS_50_PLUGINDIR/lib/cmInt.jar"/><classpathentry kind="var" path="WAS_50_PLUGINDIR/lib/dynacache.jar"/><classpathentry kind="var" path="WAS_50_PLUGINDIR/lib/ivjejb35.jar"/><classpathentry kind="var" path="WAS_50_PLUGINDIR/lib/j2ee.jar"/><classpathentry kind="var" path="WAS_50_PLUGINDIR/lib/naming.jar"/><classpathentry kind="var" path="WAS_50_PLUGINDIR/lib/ras.jar""/><classpathentry kind="var" path="WAS_50_PLUGINDIR/lib/runtime.jar""/><classpathentry kind="var" path="WAS_50_PLUGINDIR/lib/servletevent.jar"/><classpathentry kind="var" path="WAS_50_PLUGINDIR/lib/utils.jar"/><classpathentry kind="var" path="WAS_50_PLUGINDIR/lib/xerces.jar"/><classpathentry kind="var" path="WCM_PLUGINDIR/lib/databeans.jar"/><classpathentry kind="var" path="WCM_PLUGINDIR/lib/wpcpauthor.jar"/><classpathentry kind="var" path="WCM_PLUGINDIR/lib/wpcpquery_src.jar"/><classpathentry kind="var" path="WCM_PLUGINDIR/lib/wpcpresources.jar"/><classpathentry kind="var" path="WCM_PLUGINDIR/lib/wpcpruntime.jar"/><classpathentry kind="var" path="WCM_PLUGINDIR/lib/wpcpruntimecommon.jar"/><classpathentry kind="var" path="WPS_V5_PLUGINDIR/portlet-api.jar"/><classpathentry kind="var" path="WPS_V5_PLUGINDIR/wpsportlets.jar"/><classpathentry kind="var" path="WPS_V5_PLUGINDIR/wps.jar"/>
Note the following information: ❍ Make sure to check your class path entries in the new Studio Products tooling after
migration. Ensure that the class path entries are pointing to the new WebSphere Portal Version 5.0.x paths.
❍ When you create a Portlet Project for WebSphere Portal Version 5.0.x, you can choose WPS_V5_PLUGINDIR as a class variable.
5. Click File Import File System.6. Press Next.7. Select the following directory as a source directory: <WebSphere_Studio_root>/wstools/
eclipse/plugins/com.ibm.wps_v5_<WebSphere_Portal_version>
where: ❍ <WebSphere_Studio_root> is the root directory of WebSphere Studio.❍ <WebSphere_Portal_version> is the specific 4.x version of WebSphere Portal.
8. Select the following directory as a target directory: <portlet_project>/Web Content/WEB-INF/tld
where: <portlet_project> is the name of your project. 9. Override the existing portlet.tld file with the new one.
4: Migrating themes and skins
WebSphere Portal Version 4.1 supported a two-level hierarchy (places, or pageGroups, and pages). In V4.1, theme JSPs (Navigation.jsp, Banner.jsp) provided navigation for places and pages. JSP developers could customize the theme and skin JSPs by using the <wps:page/> and <wps:pageGroup/> tags.
WebSphere Portal Version 4.2 introduced multilevel navigation, in which users and administrators could create pages that are nested within other pages. Themes developed for V4.1 do not provide navigation to nested nodes that were introduced in V4.2. The <wps:navigation/> tag was added to allow JSP developers to make use of the new hierarchy. The original <wps:page/> and <wps:pageGroup/> tags remained in V4.2 for compatibility reasons. By default in V4.2, if nested nodes exist for a user, a navigation column provides complete access to all nodes not accessible from the theme. This navigation column is created by LayeredContainer-V.jsp in the /skins directory. A Java scriptlet that invoked the Composition Model API was used to implement the nested navigation tree in LayeredContainer-V.jsp.
More changes were introduced in the portal organization for V5.0.x. The representation of places or pagegroups has been removed entirely. Also, the Composition Model API has been replaced by a new enhanced Object Model API that is not available for public use. However, you can manipulate the appearance of the navigation tree by making changes to the images, colors, and other style settings that are used by the layered container.
Developers who used the Composition Model API in V4.2 should read the API migration document, available at http://www-1.ibm.com/support/docview.wss?uid=swg27004260
See Designing your portal to get a better understanding of how the portal page is built in WebSphere Portal V5.0.x.
4.1: Updates to engine tags
The following tags, deprecated in WebSphere Portal Version 4.x, have been removed in WebSphere Portal Version 5.0.x:
● <wps:pageGroupLoop/> Replaced by <wps:navigationLoop/>.
● <wps:pageGroup/> This tag was mostly used with attribute="title" to obtain the title of a page to display in the navigation. For WebSphere Portal Version 5.0.x, use this code in the navigation loop to obtain the title of a node:
<%= com.ibm.wps.model.LocaleHelper.getTitle((com.ibm.portal.Localized)wpsNavNode, com.ibm.wps.engine.RunData.from( pageContext.getRequest()).getLocale())%>
● <wps:pageLoopInit/>Replaced by the maxNumber attribute on <NavigationShiftTag/>.
● <wps:page/>This tag was mostly used with attribute="title" to obtain the title of a page to display in the navigation. For WebSphere Portal Version 5.0.x, use this code in the navigation loop to obtain the
title of a node:
<%= com.ibm.wps.model.LocaleHelper.getTitle((com.ibm.portal.Localized)wpsNavNode, com.ibm.wps.engine.RunData.from( pageContext.getRequest()).getLocale())%>
● <wps:frameURL/>In WebSphere Portal, support for frames is removed completely.
● <wps:pageLoop/>Replaced by <wps:navigationLoop/>.
● <wps:pageLoopShift/>Replaced by <wps:navigationShift/>.
● <wps:pageRender/>Replaced by <wps:compositionRender/>.
In addition, the <wps:URLSelect> tag, introduced in WebSphere Portal Version 4.2, has been replaced by the <URLGeneration/> tag. The following tags were also added:
● <wps:portletMoveRight />● <wps:portletMoveLeft />● <wps:portletMoveUp />● <wps:portletMoveDown />● <wps:portletDelete />
The following tags have been changed in WebSphere Portal Version 5.0.x:
● <wps:urlParent/>
With the removal of <wps:pageGroupLoop/>and <wps:pageLoop/>, you cannot use <wps:urlParent/>to obtain the URL for a page or node in the portal. Instead, links to nodes are created within the <wps:navigationLoop/>by using a wpsNavNodeobject. The following example shows how the link would be generated using an HTML anchor tag:
<a class="wpsSelectedPageLink" href='<%=wpsNavModelUtil.createSelectionChangeURL(wpsNavNode)%>' > ... </a>
● <wps:text/> and <wps:textParam/> tags 4.1 rendering classes for these tags were removed (TextTag_old.java and TextParamTag_old.java). Now use: TextTag.java and TextParamTag.java. The behavior of these tags has changed. The previous/old classes used the body contents of the tag only if the specified key was not found in the specified resource bundle. If your JSPs provide content in the body of the <wps:text/> tag, it will now always be written to the page. The new classes were introduced in Version 4.2, but not used by default.
● <wps:navigation/> computeSelectionPath and useModelFromRequestAttributeNamed attributes removed
● <wps:urlFind/> id attribute added
● <wps:if/> Changes to attributes:
❍ pageSelected (removed, replaced by nodeInSelectionPath)❍ pageGroupSelected (removed, replaced by nodeInSelectionPath)❍ pageAvailable (removed, replaced by navigationAvailable)❍ pageGroupAvailable (removed, replaced by navigationAvailable)❍ frameMode (removed, support for frames is removed completely)❍ showTools (new)❍ nodeInSelectionPath (new)❍ navigationAvailable (new)❍ portletSolo (new)❍ error (previously deprecated attribute has been removed)
● <wps:unless/> Exact same changes as <wps:if/> tag.
4.2: Suggested migration steps
Before performing any migration steps for themes and skins, read Designing your portal to get a good understanding of how the portal page is built in WebSphere Portal V5.0.x. It is especially important that you understand how the startLevel and stopLevel attributes on the <wps:navigation/> tags work. This is explained in Working with portal navigation.
If your existing portal site has custom themes and skins based on WebSphere Portal Version 4.x, follow these steps to migrate them to WebSphere Portal Version 5.0.x.
1. Install and configure WebSphere Portal Version 5.0.x, if you have not already done so. Refer to Installing for instructions. Verify that WebSphere Portal Version 5.0.x is installed and operating successfully.
2. Copy customized themes and skins from directory <wp4_root>/app/wps.ear/wps.war on WebSphere Portal Version 4.x to the <was5_root>/installedApps/<node_name>/wps.ear/wps.war directory on the WebSphere Portal Version 5.0.x system, where <node_name> is the name of the WebSphere Portal Version 5.0.x node.
3. Themes and skins that were copied in the previous step need to be upgraded before they can be used on WebSphere Portal Version 5.0.x. Update the JSPs that are used by themes and skins. Review the Updates to engine tags section here to determine what has changed and how to accommodate the changes in your JSPs. See also Tags used by the portal JSPs for complete descriptions of all new and changed tags.
4. Update style sheets (themes only) by adding the new classes that have been introduced. Classes that are introduced with each release are identified in the style sheets:
❍ Classes that were added in Version 4.2 have the comment, New in v4.2. ❍ Classes that were added in Version 5.0.x have the comment, New in v5.
Complete the following steps to update the style sheets with the new classes:
a. Copy these new classes from one of the WebSphere Portal Version 5.0.x theme style sheets to the style sheet of each of your themes.
b. Modify the classes to match the look of your themes.
5. Add the upgraded themes and skins to WebSphere Portal Version 5.0.x using the Manage themes and skins portlet in Portal Administration.
6. Add your customized skins to the themes.7. Use the Page Customizer to create a root page to use for testing themes and skins. Do not assign
the customized themes to any of the installed pages (Home, Portal Administration, and so on) at this point.
8. Assign a customized theme to the new page.9. Add some portlets to the page and assign one or more customized skins to the portlets.
10. Navigate to the new page to test the new themes and skins.11. Repeat Steps 8 through 10 as needed for each of your customized themes and skins that were
added in Step 5.
5: Migrating custom portlet code
The following list describes the changes to the Portlet API since WebSphere Portal Version 4.1. Use this as a reference when updating portlet source code for WebSphere Portal Version 5.0.x. Deprecated APIs will continue to work in WebSphere Portal Version 5.0.x; however, it is recommended that alternatives be used as soon as possible.
Note: The portlet.tld file is a common resource that should not be bundled with the portlet WAR file. If present, this file must be removed from any portlet WAR file prior to installation on WebSphere Portal Version 5.0.x. Portal Toolkit 5.0 and 5.0.2 provides a repackaging option to automate this process.
● In Version 5.0.x, the <portletAPI:text/> tag has been deprecated in favor of the <fmt:bundle/> and <fmt:message/> tags from the Java Standard Tag Library. See Deprecated portlet JSP tags for details.
● In Version 5.0, the WindowEvent and WindowListener interfaces were deprecated. ● In Version 4.2, the PortletURI.addAction(PortletAction action) method was
deprecated in favor of PortletURI.addAction(java.lang.String simpleAction). This change was made to support use of actions on WML phones and also to reduce session size. This change also affects the PortletAction and DefaultPortletAction objects, which have been deprecated.
● In Version 4.2, the ActionEvent.getAction() method was deprecated in favor of the ActionEvent.getActionString() method. This change was made to support the use of browser back and refresh buttons.
● In Version 4.2, the PortletSession.getUser() method was deprecated in favor of PortletRequest.getUser(). In Version 5.0.x, PortletSession.getUser() returns a null value.
● In Version 4.2.1, multiple portlets within a portlet application are not allowed to point to the same servlet definition in the web.xml file. Each portlet must have a 1-1 relationship with a servlet definition, although each servlet definition might actually point to the same servlet code.
● Originally, WebSphere Portal provided the portal user's ID and password to portlets through the user's Java Authentication and Authorization Service subject to support single signon. This functionality was deprecated in WebSphere Portal Version 4 in favor of using the credential vault service for single signon. Using the JAAS Subject to obtain the user's credentials was not always reliable, and support for this method has been removed in WebSphere Portal Version 5. For WebSphere Portal Version 5.0.x, portlets that are written to use the JAAS Subject to access the user's credentials must be updated to use the credential vault service instead.
● In Version 4.1.2, the PortletResponse.encodeURL() method that is used by JSPs to access content in the WAR file returned fully qualified URLs, for example:http://<hostname.yourco.com>/wps/portal/.../button.gif In Version 4.1.3a, this method was changed to return the relative URL of the content, for example:
/wps/portal/.../button.gif
This change was made to support SSL by allowing the configured protocol (for example, HTTPS) to be used in the URL.
● Portlet classes and interfaces from the following packages have been deprecated in Version 5.0.x. ❍ com.ibm.wps.portlets❍ org.apache.jetspeed.portlets❍ org.apache.jetspeed.portlets.util
The Javadoc for these helper classes is not provided along with the Portlet API Javadoc. Instead, the Javadoc can be found in the <wp_root>/dev/samples directory.
6: Migrating Click-to-Action portlets
The Click-to-Action functionality that is provided in WebSphere Portal Version 4.2 has been expanded to give developers more control over how their portlets share information, or properties. All portlets on a page that send or receive properties using the property broker are called cooperative portlets. Click-to-Action is a term that describes how portlets can provide a pop-up menu to allow users to designate how they want properties to be transferred on the page. Click-to-Action is a subset of the framework behind cooperative portlets, which is handled by the property broker run time.
The behavior of output parameters has changed from WebSphere Portal Version 4.x to WebSphere Portal Version 5.0.x. Output parameters will not be automatically propagated unless they have been explicitly wired to input parameters of other portlets. Apart from the output parameter behavior change, all previous functionality will work as before without source code changes. To use new functionality that is introduced in WebSphere Portal Version 5.0.x, source code changes might be required. See the section on Cooperative portlets for details about how to adjust your portlets for these changes.
Follow these steps to migrate Click-to-Action portlets:
1. Locate the pbportlet.jar file. The default location for this file is <wp_root>/pb/lib.2. Copy the file to the WEB-INF/lib directory in the WAR file of each Click-to-Action portlet
application that is developed for WebSphere Portal Version 4.x. This will overwrite the previous version of pbportlet.jar from WebSphere Portal Version 4. If you had moved the WebSphere Portal Version 4.0 version of pbportlet.jar to another location in the WAR file or renamed it, you will need to remove it in order to avoid classloading conflicts.
3. Redeploy or update the WAR file in the portal server.4. To verify successful migration of Click-to-Action portlet applications, complete the following steps:
❍ After completing the migration steps, place the migrated portlets on a page. Click-to-Action should work as expected, with clickable icons appearing next to properties that can be transferred to other portlets. A pop-up menu allowing an action to be chosen should appear when an icon is clicked, and the target portlet should react in the expected manner. The default look and feel of the icon and the menu are slightly different in WebSphere Portal Version 5.0.x than in WebSphere Portal Version 4.0.
❍ The behavior of output parameters has changed in WebSphere Portal Version 5.0.x. If your application was using output parameters to automatically transfer data to other portlets, this behavior will be different until a wire is created. See the section on Cooperative portlets for details.
7: Migrating portlets built with the Struts Portlet Framework
The Struts Portlet Framework is designed to allow users to package Struts applications that can be deployed on multiple versions of WebSphere Portal. For more information, see the Struts Portlet Framework section. The steps for migration depend on the Struts Portlet Framework version.
7:1: Determining the version of the Struts Portlet FrameworkThe version.txt file in the dev/struts directory allows you to determine the version of the Struts Portlet Framework and the version of Jakarta Struts that is integrated in the package. Here is a list of the Struts Portlet Framework versions:
1. WebSphere Portal Version 4.2a. Struts Portlet Framework : Version 4.2b. Struts release : Struts 1.1 Beta 2
2. WebSphere Portal 4.2.1a. Struts Portlet Framework : Version 4.2.1b. Struts release : Struts 1.1 RC 1
3. WebSphere Portal Version 5.0.x a. Struts Portlet Framework : Version 5.0.0b. Struts release : Struts 1.1 RC 1
4. Portlet Catalog a. Struts Portlet Framework : Version 4.1.5b. Struts release : Struts 1.1 RC 1
7.2: Migrating from Struts Portlet Framework with Struts 1.1 Beta 2The Struts Portlet Framework now includes Struts 1.1.0. There are several changes in Struts 1.1.0 that can affect Struts applications that were written using previous versions of the Struts Portlet Framework.
1. Unzip the PortalStrutsBlank.war file located in the <wp_root>/dev/struts/Struts portlet directory. This is an actual Struts application so the directory structure is similar to many Struts applications. Copy the following JAR files in the WEB-INF/lib directory from the PortalStrutsBlank.war to the WEB-INF/lib directory of the Struts application:
❍ commons-beanutils.jar ❍ commons-collections.jar ❍ commons-dbcp.jar ❍ commons-digester.jar ❍ commons-fileupload.jar ❍ commons-lang.jar ❍ commons-logging.jar ❍ commons-pool.jar ❍ commons-resources.jar ❍ commons-services.jar
❍ commons-validator.jar ❍ jakarta-oro.jar ❍ jdbc2_0-stdext.jar ❍ PortalStruts.jar (Struts Portlet Framework) ❍ PortalStrutsCommon.jar (Struts Portlet Framework) ❍ PortalStrutsTags.jar (Struts Portlet Framework - new) ❍ struts.jar ❍ StrutsUpdateForPortal.jar (Struts Portlet Framework)
2. Remove the following files from the WEB-INF/lib directory: ❍ commons-services.jar❍ jdbc2_0-stdext.jar❍ commons-dpcp.jar❍ commons-pool.jar❍ commons-resources.jar
3. Update the TLD files. The location of the TLD varies from application to application. Use the tag location element in the Web deployment descriptor to determine the location of the TLD files in your application. Update the TLDs with the versions from the WEB-INF/tld directory of the PortalStrutsBlank.war.
4. Remove the previous TLD files that were in the WEB-INF directory. Note that the location of the TLDs has changed; they are now in the WEB-INF/tld directory. The TLD files that ship with the Struts Portlet Framework and should be used in the Struts application are listed here.
❍ struts-bean.tld❍ struts-chtml.tld❍ struts-html.tld❍ struts-logic.tld❍ struts-nested.tld❍ struts-portal-html.tld❍ struts-portal-wml.tld❍ struts-template.tld❍ struts-tiles.tld❍ struts-wml.tld
5. Remove the ForwardAction class when migrating to the current release. The ForwardAction class can be found in the WEB-INF/classes/org/apache/struts/actions directory. Struts also ships an IncludeAction class. The Struts implementation of IncludeAction writes directly to the response object; this behavior is not supported for an action in WebSphere Portal, so it is also suggested that you use ForwardAction instead of IncludeAction.
6. Create the new WAR file and deploy the Struts application in WebSphere Portal. 7. Struts 1.1 has changed the name of subapplications to modules after the Beta 2 release. This
change led to the renaming of the ApplicationConfig class to ModuleConfig. Some tags and actions might use ModuleConfig to determine the current module prefix. The Struts application code should be checked to see if the ApplicationConfig object was used, and if so it should be migrated to the ModuleConfig object instead. Also note that the method of obtaining the ModuleConfig object from the request object has changed. Here is an example of the new implementation:
ModuleConfig config = (ModuleConfig) pageContext.getRequest().getAttribute(org.apache.struts.Globals.MODULE_KEY);
You can obtain additional information about the ModuleConfig class from the Jakarta Web site.
The name change of SubApplication to Module also caused the name change of an init-parameter supported by the Struts Portlet Framework. The Struts Portlet Framework supports customization through the specification of init-parameters in the Web deployment descriptor. Previous versions of the Struts Portlet Framework supported an init-parameter named SubApplicationSearchPath. For the Struts Portlet Framework to be consistent with Struts 1.1.0, the SubApplicationSeachPath init-parameter has been renamed ModuleSearchParameter. The SubApplicationSearchPath init-parameter continues to be supported, but is expected to be deprecated in a future release. If both the SubApplicationSearchPath and ModuleSearchPath parameters are specified as init-parameters in the Web deployment descriptor, then the ModuleSearchPath value will be used.
For example, if the Struts application had the following init-parameter in the Web deployment descriptor:
<init-param><param-name>SubApplicationSearchPath</param-name><param-value>markupName,mode</param-value></init-param>
it would be replaced with the following data:
<init-param><param-name>ModuleSearchPath</param-name><param-value>markupName,mode</param-value></init-param>
7.3: Migrating from Struts Portlet Framework with Struts 1.1 RC 1The Struts Portlet Framework that was released with WebSphere Portal 4.2.1 and downloads from the Portal Catalog for WebSphere Portal Version 4.1 includes Struts 1.1 RC 1.
1. The Portlet Deployment Descriptor should be checked for these applications to verify that the Struts Filter chain is specified. The following lines should be in the portlet.xml file:
<config-param><param-name>FilterChain</param-name><param-value>StrutsTranscoding</param-value></config-param>
The filter chain is used to implement solutions for some of the differences between the versions of WebSphere Portal.
2. The Struts application must be migrated to the newer version of the Struts Portlet Framework. Unzip the PortalStrutsBlank.war file that is located in the <wp_root>/dev/struts/Struts portlet directory. This is an actual Struts application so the directory structure is similar to many Struts applications. Copy the following JAR files in the WEB-INF/lib directory from the PortalStrutsBlank.war to the WEB-INF/lib directory of the Struts application:
❍ commons-beanutils.jar ❍ commons-collections.jar ❍ commons-dbcp.jar
❍ commons-digester.jar ❍ commons-fileupload.jar ❍ commons-lang.jar ❍ commons-logging.jar ❍ commons-pool.jar ❍ commons-resources.jar ❍ commons-services.jar ❍ commons-validator.jar ❍ jakarta-oro.jar ❍ jdbc2_0-stdext.jar ❍ PortalStruts.jar (Struts Portlet Framework) ❍ PortalStrutsCommon.jar (Struts Portlet Framework) ❍ PortalStrutsTags.jar (Struts Portlet Framework - new) ❍ struts.jar ❍ StrutsUpdateForPortal.jar (Struts Portlet Framework)
3. Remove the following files from the WEB-INF/lib directory: ❍ commons-services.jar❍ jdbc2_0-stdext.jar❍ commons-dpcp.jar❍ commons-pool.jar❍ commons-resources.jar
4. Update the TLD files. The location of the TLD varies from application to application. Use the tag location element in the Web deployment descriptor to determine the location of the TLD files in your application. Update the TLDs with the versions from the WEB-INF/tld directory of the PortalStrutsBlank.war.
5. Remove the previous TLD files that were in the WEB-INF directory. Note that the location of the TLDs has changed; they are now in the WEB-INF/tld directory. The TLD files that ship with the Struts Portlet Framework and should be used in the Struts application are listed here.
❍ struts-bean.tld❍ struts-chtml.tld❍ struts-html.tld❍ struts-logic.tld❍ struts-nested.tld❍ struts-portal-html.tld❍ struts-portal-wml.tld❍ struts-template.tld❍ struts-tiles.tld❍ struts-wml.tld
6. Remove the ForwardAction class when migrating to the current release. The ForwardAction class can be found in the WEB-INF/classes/org/apache/struts/actions directory. Struts also ships an IncludeAction class. The Struts implementation of IncludeAction writes directly to the response object; this behavior is not supported for an action in WebSphere Portal, so it is also suggested that you use ForwardAction instead of the IncludeAction.
7. Create the new WAR file and deploy the Struts application in WebSphere Portal.
8: Migrating collaborative portlets
If you plan to use an older version of the Sametime Contact List portlet (from WebSphere Portal Version 4.2.1 or older) in a WebSphere Portal Version 5.0.x environment, make sure that the hostAddress.xml file is made available to this portlet.
● Before upgrading, locate the file in the /peopleawareness directory and keep a copy.● After installing, copy the file to the same directory in the 5.0.x installation.● Edit the file and make sure that the Sametime server name that is specified matches the one that is
specified in the CSEnvironment.properties file in the WebSphere Portal Version 5.0.x installation.
9: Transcoding Technology migrationThe Transcoding Technology supports preference profiles (device and user), plug-ins, annotators, and style sheet resources that allow it to make Web-based information available to users of handheld and other pervasive devices. Refer to What is Transcoding Technology for more information.
If you have not used or made any customizations to these resources using the Transcoding Technology, you can skip this section.
The Transcoding Technology supplies scripts that can be used to create XML-based definition of transcoding resources. These scripts will be used to accomplish the migration. The Transcoding device profiles provide additional functional enhancements to help select the most appropriate WebSphere Portal client based on the request parameters. If you have created additional device profiles or updated existing ones, use the following steps to migrate these changes to WebSphere Portal Version 5.0.x.
1. Change your working directory to where Transcoding Technology was installed in your WebSphere Portal Version 4.x environment. Depending on your operating system, the path will be: Windows: C:\Program Files\IBMTrans Unix: /opt/IBMTrans AIX: /usr/IBMTrans
2. Invoke the following command to export device profile configuration information from Transcoding: Windows: ExportResources.bat -ResourceType device -FileName devices.xml Unix: ./ExportResources.sh -ResourceType device -FileName devices.xml
3. Copy the file that was exported in Step 2 to the directory where Transcoding is installed for WebSphere Portal Version 5.0.x. In WebSphere Portal Version 5.0.x, Transcoding Technology is always installed under <wp5_root>/IBMTrans, where <wp5_root> is the root installation directory of WebSphere Portal Version 5.0.x.
4. Change your working directory to <wp5_root>/IBMTrans.5. Invoke the following command to import device profile configuration information, to the Transcoding
in WebSphere Portal Version 5.0.x: Windows: C:\ImportResources.bat -ResourceType device -FileName devices.xml Unix: ./ImportResources.sh -ResourceType device -FileName devices.xml If you have also modified other transcoding resources in WebSphere Portal Version 4.0, repeat these steps for each of these resources, replacing device in steps 2 and 5 with the appropriate value for the other resources. Valid values for the -ResourceType arguments are device, plugin, stylesheet, annotator, and user. Refer to Using XML configuration for special considerations when migrating plug-in, style sheet, annotator resources, and any other additional information.
10: Verifying updated portlets
It is important to verify that the portlets you have migrated work correctly on WebSphere Portal. Use WebSphere Studio on your Version 5.0.x system to verify that the updated portlets are functioning properly. You could also verify that the portlets are functioning correctly on a WebSphere Portal Version 5.0.x development environment before deploying them to your production environment. Specific verification steps are listed in the Verifying the migration tasks section, which you will need to refer to as you are running the migration tasks.
Next steps
You have completed this step. Continue to the next step by choosing the following topic:
● Preparing to run the migration tasks
Preparing to run the migration tasks
1: Confirm successful installation of WebSphere Portal Version 5.0.x2: Apply interim fixes to WebSphere Portal Version 4.x3: Apply the migration interim fix4: Apply additonal fix if using an External Security Manager5: Specify values in the properties files6: Make portlet applications available to migration tasks for deployment.7. Prepare to migrate WebSphere Member Services 7.1: You might be able to skip step 7 if you do not store additional attributes in a Lookaside database 7.2: Preparatory steps 7.3: Setting parameters that are related to the Member Manager uuid8: Migrate custom deployment scripts9: Specify if external access control is migrated10: Ensure that all LDAP groups have at least one member
1: Confirm successful installation of WebSphere Portal Version 5.0.x
You should have already installed WebSphere Portal Version 5.0.x. Confirm that WebSphere Portal Version 5.0.x is installed, configured, and operating correctly. See Installing and Installing coexisting WebSphere Portal products on the same machine for instructions.
2: Apply interim fixes to WebSphere Portal Version 4.x
Apply interim fixes to your WebSphere Portal Multiplatform Version 4.x system.
Note: The migration interim fix overwrites any values in the mig_core.properties file. If you have modified this file prior to applying the migration interim fix, back up the original file before applying the migration interim fix and fill in the parameters in mig_core.properties again after applying the interim fix.
1. Stop your WebSphere Portal Version 4.x system.2. Open a command prompt/shell.3. Select the appropriate interim fix file from the wps/migration/efixes/MultiPlatform
directory on the WebSphere Portal Version 5.0.x Product CD. The file name of the interim fix indicates to which version it can be applied. For example, if you are running WebSphere Portal Multiplatform Version 4.2 or 4.2.1, select 42_421_Multiplatform_Cumulative_Fixes.jar.
4. Extract the interim fix to a temporary directory on the WebSphere Portal Version 4.x system by entering the following command on one line:
jar -xvf <filename>.jar
where <filename> is the name of the interim fix file.
5. If you are using WebSphere Portal Version 4.2.x, an XmlAccess.jar file will not be extracted in
the previous step; if you are using WebSphere Portal Version 4.1.x, an XmlAccess.jar file will be extracted. If an Xmlaccess.jar file was extracted, complete the following steps:
a. Make a backup of the existing XmlAccess.jar file in <wp_root>/bin.b. Copy the updated XmlAccess.jar file to <wp_root>/bin.
6. Change to the <was_root>/lib/app directory.
Note:In steps 7 through 9, the variable <Websphere_Portal_version>refers to the WebSphere Portal release that is specified in the *_MP_fix.jarfile that is produced when you extracted the interim fix file in Step 4. For example, extracting 42_421_Multiplatform_Cumulative_Fixes.jarproduces 42X_MP_fix.jar. So, <Websphere_Portal_version>would be 42X.
7. Copy the <Websphere_Portal_version>_MP_fix.jar file to the <was_root>/lib/app directory.
8. Extract the files by entering the following information on the command line:
jar -xvf <Websphere_Portal_version>_MP_fix.jar
9. Remove <Websphere_Portal_version>_MP_fix.jar from <was_root>/lib/app. After you have extracted the *_MP_fix.jar file, you no longer need it.
10. Edit the file <was_root>/lib/app/config/services/XmlAccessService.properties.a. Add the following line to the <was_root>/lib/app/config/services/
XmlAccessService.properties file. This should be entered on one line, maintaining all the capitalizations:
com.ibm.wps.command.xml.groupexport.GroupExportEngine=-//IBM//DTD Group Export//EN,/com/ibm/wps/command/xml/groupexport/GroupExport.dtd
b. Save the file.
11. Restart WebSphere Portal.
For more information:
● For information on applying the interim fix, see the IBM WebSphere Portal Version 5.0 interim fix readme file for APAR PQ77682: Fixes for migrating to WebSphere Portal Version 5.0 from prior releases.
● For information on applying the WebSphere Portal Version 5.0.2 fix pack, see the Version 5.0.2 fix pack readme file.
3: Apply the update to the fixes for 4.x
The Version 5.0 migration interim fix and the Version 5.0.2 fix pack both supply an update to the previously supplied fixes for WebSphere Portal Version 4.x. After installing the migration interim fix or the fix pack on WebSphere Portal Version 5.0, this update will be located in the <wp5_root>/migration/efixes directory. You must apply this update to your WebSphere Portal Version 4.x system by completing the following steps:
1. Stop your WebSphere Portal Version 4.x system.2. Open a command prompt/shell.3. Copy the appropriate update to the interim fix from the <wp5_root>/migration/efixes
directory to a temporary directory on your WebSphere Portal Version 4.x system. If you are using WebSphere Portal Version 4.1.x, copy WP41X_MP_Express_Patch.jar. If you are using WebSphere Portal Version 4.2.x, copy WP42X_MP_Express_Patch.jar.
4. Extract the update to the interim fix to a temporary directory on the WebSphere Portal Version 4.x system by entering the following command on one line:
jar -xvf <file_name>.jar
where: <file_name> is the name of the interim fix update file (WP41X_MP_Express_Patch.jar or WP42X_MP_Express_Patch.jar). This will extract the update file 41X_fix.jar or 42X_fix.jar.
5. Change to the <was_root>/lib/app directory.6. Copy the update file 41X_fix.jar or 42X_fix.jar to the <was_root>/lib/app directory.7. Extract the update files by entering the following information on the command line:
Note: This command will overwrite existing files.
jar -xvf <update_file>
where: <update_file> refers to 41X_fix.jar or 42X_fix.jar.
8. Remove the file 41X_fix.jar or 42X_fix.jar from the <was_root>/lib/app directory. 9. Restart WebSphere Portal Version 4.x.
4: Apply additional fix if using an External Security Manager
Perform this step only if you are using an External Security Manager with your WebSphere Portal Version 4.x system.
The fix file ESMmigration_412_413_413a_414_415_42_421_Express.jar is provided in the wps/migration/efixes directory on the WebSphere Portal Version 5.0.x Product CD. Complete the following instructions to apply the fix.
1. Stop your WebSphere Portal Version 4.x system.2. Open a command prompt/shell.3. Copy the ESMmigration_412_413_413a_414_415_42_421_Express.jar file to the
<was_root>/lib/app directory.4. Change to the <was_root>/lib/app directory.5. Extract the files by entering the following information on the command line:
jar -xvf ESMmigration_412_413_413a_414_415_42_421_Express.jar6. Modify <was_root>/lib/app/config/services.properties depending on the type of
External Security Manager you are using and the version of your WebSphere Portal Version 4.x system:
Tivoli Access Manager:❍ For WebSphere Portal Version 4.1.2:
com.ibm.wps.services.authorization.ExternalAccessControlService = com.ibm.wps.services.authorization.PDExternalAccessControlImpl412mig
❍ For WebSphere Portal Versions 4.1.3, 4.1.3a, 4.1.4, and 4.1.5:
com.ibm.wps.services.authorization.ExternalAccessControlService = com.ibm.wps.services.authorization.PDExternalAccessControlImpl41mig
❍ For WebSphere Portal Versions 4.2 and 4.2.1:
com.ibm.wps.services.authorization.ExternalAccessControlService = com.ibm.wps.services.authorization.PDExternalAccessControlImpl42mig
SiteMinder:❍ For WebSphere Portal Version 4.1.2:
com.ibm.wps.services.authorization.ExternalAccessControlService = com.ibm.wps.services.authorization.SiteminderExternalAccessControlImpl412mig
❍ For WebSphere Portal Versions 4.1.3, 4.1.3a, 4.1.4, and 4.1.5:
com.ibm.wps.services.authorization.ExternalAccessControlService = com.ibm.wps.services.authorization.SiteminderExternalAccessControlImpl412mig
❍ For WebSphere Portal Versions 4.2 and 4.2.1:
com.ibm.wps.services.authorization.ExternalAccessControlService = com.ibm.wps.services.authorization.SiteminderExternalAccessControlImpl42mig
7. Remove the file ESMmigration_412_413_413a_414_415_42_421_Express.jar from <was_root>/lib/app directory.
8. Restart WebSphere Portal Version 4.x.
5: Specify values in the properties filesYou must edit at least two files that are provided in the migration directory: mig_core.properties and mig_wmm.properties. If you are migrating WebSphere Portal content publishing, you must edit the mig_wpcp.properties file. 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, mig_wmm.properties allows you to modify properties that are related to Member Manager, and mig_wpcp.properties allows you to modify properties that are related to WebSphere Portal content publishing. 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
Version 4.x installation into the <wp5_root>/migration directory of the WebSphere Portal Version 5.0.x system, where <wp4_root> is the root directory of your WebSphere Portal Version 4.x system and where <wp5_root> is the root directory of your WebSphere Portal Version 5.0.x system. This file contains the version information for your WebSphere Portal Version 4.x system, which will be used to select an appropriate migration path.
Note:Migration tasks get the WebSphere Portal Version 5.0.x configuration information from <wp5_root>/config/wpconfig.properties. The migration package by default is installed in the <wp5_root>/migrationdirectory and thus, this file can be accessed. The parameters in the <wp5_root>/config/wpconfig.propertiesfile will be automatically loaded during migration task initialization.
3. If you have WebSphere Portal Version 4.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=extendExperience: WPFamilyName=experience
4. Leave the WPInstallLocation4x property in the mig_core.properties file blank if the location where WebSphere Portal Version 4.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 Version 5.0.x system. Note: 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 Version 4.x system...
to this location on the WebSphere Portal Version 5.0.x system
<wp4_root>/app/wps.ear/wps.war/themes
<was_root>/installedApps/<node_name>/wps.ear/wps.war/themes
<wp4_root>/app/wps.ear/wps.war/skins
<was_root>/installedApps/<node_name>/wps.ear/wps.war/skins
where: ❍ <wp4_root>is the installation root directory of WebSphere Portal Version 4.x. ❍ <was_root> is the installation root directory of WebSphere Application Server Version 5.0.❍ <node_name> is the node on which WebSphere Portal is installed.
6: 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 Version 4.x system. Depending on the features that are used by these portlets, they might have to first be upgraded to work with WebSphere Portal Version 5.0.x. Refer to the instructions that are provided in the Manual migration steps section to determine if you need to upgrade your portlets.
Some of the WAR files in the <wp4_root>/deployed directory might have been shipped with WebSphere Portal Version 4.x. In that case, there is no need to manually upgrade corresponding portlets.
You can safely use the corresponding WAR file from the wp5_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 Version 5.0.x system. Mig_core.properties provides an appsPath parameter that accepts a URL value that is passed to the WebSphere Portal Version 5.0.x system when deploying the portlets. Unless this URL is accessible from the WebSphere Portal Version 5.0.x system, migration tasks that deploy portlets will fail. The default value for appsPath is file://<localhost>/$server_root$/installableApps, which translates to <wp5_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 Version 5.0.x, so make sure that 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 Version 5.0.x. Also, copy any custom portlet WAR files to the <wp5_root>/installableApps directory.
If you did specify a different value for appsPath parameter, make sure that this path contains the WebSphere Portal Version 5.0.x version of all portlets that are deployed on your WebSphere Portal Version 4.x system.
7: Prepare to migrate WebSphere Member Services
This section describes the preparatory tasks that you must complete before invoking the migrate-wmm command. Actual migration of user attributes will occur when you invoke this command in the Running the migration tasks section.
In order to migrate WebSphere Member Services, you must 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
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.
7.1: You might be able to skip step 7, if you do not store additional attributes in a Lookaside database.
If your WebSphere Portal Version 4.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 Version 5.0.x, 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 Version 5.0.x to use the LDAP, and not the Lookaside database.
Use the following procedure to determine if your WebSphere Portal Version 4.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 Version 4.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 Version 4.x has information that will need to be migrated using the migrate-wmm task. This will also require that you configure your WebSphere Portal Version 5.0.x 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 <wp5_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.
7.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 Version 4.x installation to the <wp5_root>/migration/templates/wmm/xml/migration directory of WebSphere Portal Version 5.0.x.
Note:Skip the next step (step 2) if you do not use extended user attributes on your WebSphere Portal Version 4.x system.
2. If you need 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:
a. Modify the appropriate files listed here. These files are located in the WebSphere Portal Version 5.0.x directory <wp5_root>/migration/templates/wmm/xml/migration:
■ wmmDBAttributes.xml: used only for database-only WebSphere Member Services configurations. Specifies the WebSphere Member Manager attributes that will be inserted into the WMMDBATR table.
■ wmmLAAttributes.xml: used only for database + LDAP WebSphere Member Services configurations. Specifies the WebSphere 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 WebSphere 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.
b. The following steps migrate an additional WebSphere Member Services attribute (a1) to a WebSphere Member Manager attribute (a2):
Note:a1can 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 WebSphere 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 WebSphere 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 WebSphere Member Manager attribute name that you specify in the wmmDBAttributes.xml or wmmLAAttributes.xml file.
7.3: Setting parameters related to WebSphere the Member Manager uuid
When the WebSphere 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 (WebSphere 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 Version 4.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, you must make sure that 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 Version 4.x might not have a unique value associated with it because WebSphere Portal Version 4.x did not make use of the uuid attribute. In this case, specify a false value for LdapHasUuid.
If LdapHasUuid is set to false, you must 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 Version 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 WebSphere 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 <wp5_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.
Note: 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.
8: Migrate custom deployment scriptsIf you have written custom deployment scripts using the WebSphere Portal Version 4.x XML configuration interface schema, these scripts will not work directly on WebSphere Portal Version 5.0.x. Enter the following command on one line to make the scripts compatible with WebSphere Portal Version 5.0.x 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
Note: 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 Version 4.x.
9: Specify if external access control is migrated
Information in this section is relevant only if you used an external security manager with WebSphere Portal Version 4.x.
The omit-external-ac parameter in the >wp5_root</migraiton/mig_core.properties file determines whether the migration process automatically externalizes access control that was externalized in WebSphere Portal Version 4.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 Version 5.0.x.
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 Version 4.x. You must manually externalize access control in WebSphere Portal Version 5.0.x. You might want to set this value to true if:
● You used an external security manager with WebSphere Portal Version 4.x but will not use an external security manager with WebSphere Portal Version 5.0.x.
● You prefer to manually externalize access control in WebSphere Portal Version 5.0.x.
Follow these steps to set this value to true:
1. Use a text editor to open the <wp5_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.
10: Ensure that all LDAP groups have at least one member
Each group in the WebSphere Portal Version 4.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:
● Running the migration tasks
Running the migration tasks
1: Introduction2: Using the migration tasks3: Using the include and exclude parameters
1: Introduction
This section guides you through running the migration tasks. The tasks that you run vary depending on how WebSphere Portal Version 4.x and WebSphere Portal Version 5.0.x are set up. Because WebSphere Application Server Version 5.0 can coexist on the same physical machine as WebSphere Application Server Version 4.x, it is possible to install WebSphere Portal Version 5.0.x on the same machine as WebSphere Portal Version 4.x. However, when both versions are installed on the same machine, resource limitations might prohibit them from running at the same time. If you do not have the resources to run both versions on the same machine, you must skip starting WebSphere Portal Version 5.0.x and perform the migration tasks through two distinct steps, export and import. Export steps must be completed with WebSphere Portal Version 4.x running. Import steps must be accomplished by stopping WebSphere Portal Version 4.x, starting WebSphere Portal Version 5.0.x, and importing the data.
Note: Having both WebSphere Portal Version 4.x and WebSphere Portal Version 5.0.x running at the same time does not mean that both versions are on the same physical machine. You can have both versions installed on the same machine or on different machines, and have them running or not running at the same time. For example, you could have WebSphere Portal Version 4.x installed on one physical machine and WebSphere Portal Version 5.0.x installed on another, and still choose the "both systems running" scenario.
The following table displays all the migration tasks. The first row shows the two possible WebSphere Portal setup scenarios that were discussed in the previous paragraph; the second row lists the three tasks that run other tasks behind the scenes; the third row lists the tasks that are run by the tasks in the second row.
Both WebSphere Portal versions running Only one WebSphere Portal version running
migrate-all export-all import-all
export-all import-all
export-user-groups-acexport-credential-slots-segmentsexport-clientsexport-notes-portletsexport-placesexport-user-customizations
migrate-wmmimport-user-groups-acimport-credential-slots-segmentsimport-clientsimport-notes-portletsimport-placesimport-user-customizationsmigrate-wpcpoptmize-roles
You can also choose to run the migration tasks that are listed in the third row one at a time or by running the migrate-all or import-all and export-all tasks, which run all the other tasks without breaks.
For more information, see the Migration tasks reference.
2: Using the migration tasks
The WebSphere Portal migration package provides two primary script files that you can use to invoke the migration tasks:
● Windows: WPmigrate.bat ● Unix: WPmigrate.sh
You can run these scripts from the <wp5_root>/migration directory, where <wp5_root> is the directory in which WebSphere Portal Version 5.0.x is installed.
The syntax for invoking a migration task is as follows:
● Windows: ./WPmigrate.bat <task_name> -D<property>=<value> ● Unix: ./WPmigrate.sh <task_name> -D<property>=<value>
where:
● <task_name> indicates the migration task that you want to run● <property> indicates a specific property that will be used by the task● <value> indicates the value of a specific property that will be used by the task
For example, to invoke the migration task that exports a place named SuperPlace from an existing WebSphere Portal Version 4.x system and saves the exported data to a file called SuperPlaceOut.xml, you would enter the following command on one line:
● Windows: ./WPmigrate.bat export-places -DincludePlaces=SuperPlace -DfilenamePlaces=SuperPlaceOut.xml
● Unix: ./WPmigrate.sh export-places -DincludePlaces=SuperPlace -DfilenamePlaces=SuperPlaceOut.xml
For more information on the migration tasks, refer to the Migration tasks reference. For more information on the migration properties, refer to the Migration properties reference.
3: Using the include and exclude parameters
Many of the migration tasks provide parameters that begin with the words "include" and "exclude." For example, the migrate-places task provides the parameters includePlaces and excludePlaces. The optional include and exclude parameters offer a flexible way to limit the scope of migration for the tasks that support them. The include and exclude parameters take a comma-separated list of case-sensitive values. A wildcard character (*) can also be used within each value. If an exact match is found using the include parameter, the exclude parameter is ignored. See the following examples for clarification.
Example 1: This command will migrate all places that are defined in WebSphere Portal Version 4.x.
Windows: WPmigrate.bat migrate-places Unix: ./WPmigrate.sh migrate-places
Example 2: This command will migrate a place named My Place.
Windows: WPmigrate.bat migrate-places -DincludePlaces="My Place"Unix: ./WPmigrate.sh migrate-places -DincludePlaces="My Place"
Example 3: This command will migrate all places except for the place named My Place.
Windows: WPmigrate.bat migrate-places -DexcludePlaces="My Place"Unix: ./WPmigrate.sh migrate-places -DexcludePlaces="My Place"
Example 4: This command will migrate two places named My Place and My Test Place.
Windows: WPmigrate.bat migrate-places -DincludePlaces="My Place,My Test Place"Unix: Unix: ./WPmigrate.sh migrate-places -DincludePlaces="My Place,My Test Place"
Example 5: This command will migrate all places that have names beginning with the letters "My".
Windows: WPmigrate.bat migrate-places -DincludePlaces="My*"Unix: ./WPmigrate.sh migrate-places -DincludePlaces="My*"
Example 6: This command will migrate all places that have names beginning with the letters "My" except for the place named My Test Place.
Windows: WPmigrate.bat migrate-places -DincludePlaces="My*" -DexcludePlaces="My Test Place"Unix: ./WPmigrate.sh migrate-places -DincludePlaces="My*" -DexcludePlaces="My Test Place"
Example 7: This command will migrate all places that have names beginning with the words "test" and "My Test Place". Note that even though the exclude parameter indicates that all places beginning with the words "My" should be excluded, the place called My Test Place will be migrated since the include parameter does not include the wildcard character (*) when specifying "My Test Place".
Windows: WPmigrate.bat migrate-places -DincludePlaces="test*,My Test Place" -DexcludePlaces="My*"Unix: ./WPmigrate.sh migrate-places -DincludePlaces="test*,My Test Place" -DexcludePlaces="My*"
Next steps
You have completed this step. Continue to the next step by choosing one of the following topics:
● Performing migration with both WebSphere Portal versions running● Performing migration with only one version running at a time
Performing migration with both WebSphere Portal versions running
You can choose to run the migration tasks all at once without breaks or you can run them individually. If you choose the one-task option, you can run all the migration tasks one after the other with one command. If you choose the multitask option, you can run the tasks one at a time. The multitask option gives you more individualized control over the migration tasks and allows you to choose which specific elements are migrated.
Next steps
You have completed this step. Continue to the next step by choosing one of the following topics:
● Performing one-task migration● Performing multitask migration
Performing one-task migration
This section details the steps that are needed to perform one-task migration, using the migrate-all task. Refer to the Migration tasks section for more detailed information about the tasks.
After any migration task is completed, you can view the <wp5_root>/migration/MigrationReport.xml file for a report. This includes timestamp, names of individual tasks that were attempted, and if they were successfully completed.
Note: If you are migrating WebSphere Portal content publishing, you must complete all WebSphere Portal content publishing Workflow tasks before you begin the migration process.
1. Change your working directory to the migration directory that was created when you installed WebSphere Portal Version 5.0.x. The path to this directory is dependent on your operating system. For example:
❍ Windows: c:\WebSphere\PortalServer\migration❍ AIX: /usr/WebSphere/PortalServer/migration❍ Solaris: /opt/WebSphere/PortalServer/migration
2. Make sure that WebSphere Portal Version 4.x and WebSphere Portal Version 5.0.x are running and operational to your satisfaction.
3. Make sure that the mig_core.properties, mig_wmm.properties, and mig_wpcp.properties files are updated with all required parameters as indicated in these files. Supply optional parameters if desired. If you plan to migrate WebSphere Portal content publishing authoring and feedback, make sure that you update the mig_wpcp_author.properties and mig_wpcp_feedback.properties.
4. Note the following information before running the migration task: ❍ If you use an external security manager with WebSphere Portal Version 4.x or WebSphere
Portal Version 5.0.x, make sure that it is running.❍ If you do not explicitly assign a theme to your places or pages, WebSphere Portal Version 4.
x automatically uses the system default theme you have selected in the Themes and Skins Administration. The configuration for the system default theme is not migrated by the migrate-all task unless a place or a page has been defined to explicitly use that theme. In this case, the configuration for the system default theme must be migrated using the migrate-themes-skins-configs task before running the migrate-all task. The migrate-themes-skins-configs task, by default, excludes themes that are supplied with WebSphere Portal Version 4.x, so if you are using a WebSphere Portal supplied theme as the system default theme, you must specifically use the -DincludeThemes parameter when running this task. For example, if you are using the theme "WebSphere" as the system default theme, you would run the following command to migrate the "WebSphere" theme configuration to WebSphere Portal Version 5.0.x:
■ Windows: WPmigrate.bat migrate-themes-skins-configs -DincludeThemes=WebSphere
■ Unix: WPmigrate.sh migrate-themes-skins-configs -DincludeThemes=WebSphere
The migrate-all task does not deploy portlets and does not migrate portlet settings if the portlets are not included on pages being migrated using the task. This includes clipping portlets that you have created but not included on pages. If you have such portlets, you must deploy them separately using the migrate-apps task, which also migrates portlet settings and any access control information that is associated with the portlet while deploying the portlets. For example, to migrate all clipping portlets, use the following command:
■ Windows: WPmigrate.bat migrate-apps -DincludeApps="com.ibm.wps.portlets.clipper"
■ Unix: WPmigrate.sh migrate-apps -DincludeApps="com.ibm.wps.portlets.clipper"
❍ If you are using a remote Oracle database and the service name that is needed to access the database is different from the value that is specified by the WmmDbName property in the wpconfig.properties file, then you must enter the correct database on the command line by adding the -DWmmDbName parameter to the migrate-all command:
■ Windows: ./WPmigrate.sh migrate-all -DWmmDbName=<service_name>■ Unix: ./WPmigrate.sh migrate-all -DWmmDbName=<service_name>
where: <service_name> is the service name for the remote Oracle database.
5. Enter the following command on one line to perform all migration tasks supported by WebSphere Portal Version 5.0.x:
❍ Windows: WPmigrate.bat migrate-all❍ Unix: ./WPmigrate.sh migrate-all
Parameters:❍ -DskipWpcpMigration=<true_false>❍ -DskipWmmMigration=<true_false>
where:❍ <true_false> specifies whether the corresponding task for WebSphere Portal migration will
be skipped. If set to true, the migrate-wpcp task or the migrate-wmm task will be skipped.
skipWpcpMigration:Set this parameter to true if you do not use WebSphere Portal content publishing Version 4.2 or if you do not want to migrate WebSphere Portal content publishing run-time data.
For example:
❍ Windows: WPmigrate.bat migrate-all -DskipWpcpMigration=true❍ Unix: ./WPmigrate.sh migrate-all -DskipWpcpMigration=true
If this parameter is set to false or is not specified, the import-alltask calls the migrate-wpcptask, which is only suitable to migrate the WebSphere Portal content publishing Version 4.2 run time. Based on the content publishing options that are supported by your WebSphere Portal 4.x offering, you might need to run different, additional migration tasks to migrate the content publishing run-time data. For example, WebSphere Portal version 4.2.x included WebSphere Portal content publishing version 4.2. WebSphere Portal version 4.1.x offerings included WebSphere Portal content publishing version 4.1 or a stand-alone Personalization component. Refer to the following table to determine which tasks you need to run.
Content publishing option Task to runWPCP 4.2 Run time migrate-wpcp
WPCP 4.2 author time migrate-wpcp-author
WPCP 4.2 feedback migrate-wpcp-feedback
WCP 4.1 migrate-wpcp-author
Personalization Use WPCP GUI in WebSphere Portal Version 5.0.x to initiate migration.
If skipWpcpMigrationis set to false, note the following points:
❍ DB2 UDB Version 8 Fix Pack 1 contains an incorrect version of the Universal JDBC Driver (db2jcc.jar and sqlj.zip). For instructions on how to obtain the new drivers, go to http://www.ibm.com/software/data/db2/udb/support.html and search for "db2jcc." In the search results, select the item for the DB2 Version 8 Fix Pack and follow the instructions. Ensure that the db2jcc.jar file is updated.
❍ Before you perform the migration task, the db2java.zip file that resides on your WebSphere Portal Version 4.x system must be copied to the <wp5_root>/migration/lib directory, where <wp5_root> is the root directory of your WebSphere Portal Version 5.0.x system.
skipWmmMigration:In WebSphere Portal Version 4.x, the WebSphere Member Service database always acted as a Lookaside database. If you did not store additional attributes in a Lookaside database, skip Member Manager migration. For more informaton refer to Preparing to run the migration tasks, step 7.1. To do this, set skipWmmMigrationto true. For example:
❍ Windows: WPmigrate.bat migrate-all -DskipWmmMigration=true❍ Unix: ./WPmigrate.sh migrate-all -DskipWmmMigration=true
Next steps
You have completed this step. Continue to the next step by choosing the following topic:
● Migrating the remaining access control configuration
Performing multitask migration
This section details the tasks that are needed to perform migration. Before you begin running the migration tasks, carefully review the information in this bulleted list.
● Make sure that all parameters have the correct values in the mig_core.properties file. The optional parameters that are described in this section can be filled in in the properties file and can be specified on the command line. Any parameters you enter on the command line will overwrite the entries in the mig_core.properties file. If you have already specified parameters listed after the tasks in mig_core.properties, you need only enter the task itself without parameters. Refer to Migration properties for a detailed description of the properties file parameters, and to Migration tasks for more information about the migration tasks and their parameters.
● Optional migration tasks are provided for use during the development phase, when you might want to migrate individual artifacts and verify that they work as desired on WebSphere Portal Version 5.0.x. When migrating your production environments, it is recommended that you use one of the suitable scenarios described in the Running the migration tasks section. Do not use the optional tasks to migrate your production environments unless it is absolutely necessary.
● If you want to migrate themes, skins, portlet applications, and pages along with places, you can do so in the following step 8. If you want to migrate themes, skins, portlet applications, and pages individually, you can use the tasks in the Optional migration tasks section.
● Before you begin running the migration tasks, read through all the steps and develop a plan for running them.
● After any migration task is completed, you can view the <wp5_root>/migration/MigrationReport.xml file for a report. This includes timestamp, names of individual tasks that were attempted, and if they were successfully completed.
The following steps describe how to run the migration tasks: 1. Change your working directory to the migration directory that was created when you installed
WebSphere Portal Version 5.0.x. The path to this directory is dependent on your operating system. For example:
❍ Windows: c:\WebSphere\PortalServer\migration❍ AIX: /usr/WebSphere/PortalServer/migration❍ Solaris: /opt/WebSphere/PortalServer/migration
2. Make sure that WebSphere Portal Version 4.x and WebSphere Portal Version 5.0.x are running and operational to your satisfaction.
3. Make sure that the mig_core.properties, mig_wmm.properties, and mig_wpcp.properties files are updated with all required parameters as indicated in the files. If you are be
migrating WebSphere Portal content publishing authoring and feedback, you need to review the mig_wpcp_author.properties and mig_wpcp_feedback.properties files.
4. Migrate users, groups, and extended user attributes from WebSphere Portal Version 4.x (WebSphere Member Services) to WebSphere Portal Version 5.0.x (Member Manager).Skip step 4 if you did not use a Lookaside database to store additional attributes in WebSphere Portal Version 4.x. If you did not use a Lookaside database, you do not need to migrate Member Manager. For more informaton refer to Preparing to run the migration tasks, step 7.1.
a. Migrate users, groups, and extended user attributes by entering the following command on one line:
■ Windows: WPmigrate.bat migrate-wmm ■ Unix: ./WPmigrate.sh migrate-wmm
Note the following information: ■ Ensure that the Member Manager and WebSphere Member Services databases
have the same database user ID before proceeding. If the database user IDs do not match, the migrate-wmm command will fail.
■ If you are using a remote Oracle database and the service name that is needed to access the database is different from the value that is specified by the WmmDbName property in the wpconfig.properties file, then you must enter the correct database on the command line by adding the -DWmmDbName parameter to the migrate-wmm command:
■ Windows: WPmigrate.bat migrate-wmm -DWmmDbName=<service_name>
■ Unix: ./WPmigrate.sh migrate-wmm -DWmmDbName=<service_name>
where: <service_name> is the service name for the remote Oracle database. b. Refer to the Verifying the migration tasks section to verify that extended user attributes
were successfully migrated.
5. Migrate permissions that WebSphere Portal Version 4.x users have on user groups. a. If you use an external security manager with WebSphere Portal Version 4.x or WebSphere
Portal Version 5.0.x, make sure that it is running.
b. On the WebSphere Portal Version 5.x system, enter the following command on one line: ■ Windows: WPmigrate.bat migrate-user-groups-ac■ Unix: ./WPmigrate.sh migrate-user-groups-ac
c. Refer to the Verifying the migration tasks section to verify that access control on user groups was successfully migrated.
Note: Permissions on All Authenticated Users and All Anonymous Users are not migrated with this step. Permissions on All Anonymous and All Authenticated Users must be migrated using the procedure described in the Migrating the remaining access control configuration section.
6. If you had modified default portal clients supplied with WebSphere Portal Version 4.x or added
custom clients, you need to migrate them to WebSphere Portal Version 5.0.x. a. Enter the following command on one line to migrate portal clients to WebSphere Portal
Version 5.0.x:■ Windows: WPmigrate.bat migrate-clients ■ Unix: ./WPmigrate.sh migrate-clients
Optional parameters: ■ -DincludeClients=<include_names>■ -DexcludeClients=<exclude_names>
where:■ <include_names> is a comma-separated list of case-sensitive portal client names to
be included in migration. If you do not specify a value for the includeClients parameter, by default all the clients will be migrated.
■ <exclude_names> is a comma-separated list of case-sensitive portal client names to be excluded from migration. If you specify a value for excludeClients parameter, the clients that are specified will not be migrated.
b. Refer to the Verifying the migration tasks section to verify that portal clients were successfully migrated.
7. Deploy Notes and iNotes portlets that are shipped with WebSphere Portal Version 5.0.x and migrate settings from multiple Notes and iNotes Portlets from WebSphere Portal Version 4.x to WebSphere Portal Version 5.0.x. The user customization data that is associated with Notes and iNotes portlets will be migrated separately in step 10.
a. Enter the following command on one line to migrate Notes and iNotes portlets: ■ Windows: WPmigrate.bat migrate-notes-portlets■ Unix: ./WPmigrate.sh migrate-notes-portlets
b. Refer to the Verifying the migration tasks section
to verify that Notes and iNotes portlets were successfully migrated.
8. Migrate places defined in WebSphere Portal Version 4.x to WebSphere Portal Version 5.0.x. a. Enter the following command on one line to migrate places:
■ Windows: WPmigrate.bat migrate-places ■ Unix: ./WPmigrate.sh migrate-places
Optional parameters:■ -DincludePlaces=<include_names>■ -DexcludePlaces=<exclude_names>■ -DdeployPages=<true_false>■ -DdeployApps=<true_false>■ -DconfigThemesSkins=<true_false>■ -DappsPath=<your_path>
where:■ <include_names> is a comma-separated list of places to be included in migration. If
you do not specify a value for the includePlaces parameter, by default all the places will be migrated.
■ <exclude_names> is a comma-separated list of places to be excluded from migration. If you specify a value for excludePlaces parameter, the places that are specified will not be migrated.
■ <true_false> allows you the option of migrating the pages, portlet applications, themes, and skins that are associated with the places.
■ <your_path> points to a location where the XML configuration interface will look for WAR files during portlet deployment (for example: file:///usr/WebSphere/PortalServer/install). The default path is file://localhost/$server_root$/installableApps, which is equivalent to <wp5_root>/installableApps at run time.
Note the following information:■ If you do not explicitly assign a theme to your places or pages, WebSphere Portal
Version 4.x automatically uses the system default theme you have selected in the Themes and Skins Administration. The configuration for the system default theme is not migrated by the migrate-places task, unless a place or a page has been defined to explicitly use that theme. In this case, the configuration for the system default theme must be migrated using the migrate-themes-skins-configs task before running the migrate-places task. The migrate-themes-skins-configs task by default excludes themes that are supplied with WebSphere Portal Version 4.x, so if you are using a WebSphere Portal-supplied theme as the system default, you must specifically use the -DincludeThemes parameter when running this task. For example, if you are using the theme "WebSphere" as the system default theme, you would run the following command to migrate the "WebSphere" theme configuration to WebSphere Portal Version 5.0.x:
■ Windows: WPmigrate.bat migrate-themes-skins-configs -DincludeThemes=WebSphere
■ Unix: WPmigrate.sh migrate-themes-skins-configs -DincludeThemes=WebSphere
The migrate-places task does not deploy portlets and does not migrate portlet settings if the portlets are not included on pages that are being migrated using the migrate-places task. This includes clipping portlets that you have created but not included on pages. If you have such portlets, you must deploy them separately using the migrate-apps task, which also migrates portlet settings and any access control information that is associated with the portlet while deploying the portlets.
For example, to migrate all clipping portlets, use the following command:■ Windows: WPmigrate.bat migrate-apps -DincludeApps="com.ibm.wps.portlets.clipper"
■ Unix: WPmigrate.sh migrate-apps -DincludeApps="com.ibm.wps.portlets.clipper"
■ The configThemesSkins, deployApps, and deployPages parameters are set to true by default. This allows the migrate-places task to also migrate the corresponding pages that are used by the places, migrate the configuration of themes and skins that are used by the pages, and deploy portlet applications that are used on the pages. If you want to migrate these elements individually, make sure that the parameters are set to false and use the steps in the Optional migration tasks section. Note that the optional tasks are provided for your use during the development phase, when you want to migrate individual artifacts and verify that they work as desired on WebSphere Portal Version 5.0.x. When migrating your production environments, it is recommended that you use the migrate-places task and use the default value of true for the parameters configThemesSkins, deployApps, and deployPages.
b. Refer to the Verifying the migration tasks section to verify that places were successfully migrated.
9. Migrate all user customizations to WebSphere Portal Version 5.0.x. User customizations are artifacts that are attributed to a user that has EDIT but not MANAGE permissions on a page. They are created when such a user changes the layout of a page or edits portlet settings. The following command also exports user customizations for all Notes and iNotes portlets.
a. Enter the following command on one line to migrate user customizations: ■ Windows: WPmigrate.bat migrate-user-customizations ■ Unix: ./WPmigrate.sh migrate-user-customizations
Parameters: ■ -DincludePages=<include_page_names>■ -DexcludePages=<exclude_page_names>
where:■ <include_page_names> is a comma-separated list of page names to be included in
migration. If you do not specify a value for the includePages parameter, by default all the pages will be migrated.
■ <exclude_page_names> is a comma-separated list of page names to be excluded from migration.
■ <include_owner_names> is a comma-separated list of owner names that help further specify the pages to be included in migration.
■ <exclude_owner_names> is a comma-separated list of owner names that help further specify the pages to be excluded from migration.
b. Refer to the Verifying the migration tasks sectionto verify that user customizations were successfully migrated.
10. Migrate Credential Vault slots and segments. Existing credential vault data must be migrated with a separate manual procedure that is described in the Migrating the remaining access control
configuration section. a. Enter the following command on one line:
■ Windows: WPmigrate.bat migrate-credential-slots-segments■ Unix: ./WPmigrate.sh migrate-credential-slots-segments
2. Refer to the Verifying the migration tasks section to verify that Credential Vault slots were successfully migrated.
11. The following steps allow you to migrate contents in Personalization, WebSphere Content Publishing, or WebSphere Portal content publisher from WebSphere Portal Version 4.x to WebSphere Portal Version 5.0.x.
Based on the content publishing options that are supported by your WebSphere Portal 4.x offering, you might need to run different migration tasks. WebSphere Portal 4.2.x shipped with WebSphere Portal content publisher 4.2, WebSphere Portal 4.1.x offerings shipped with WebSphere Content Publishing 4.1 or a stand-alone Personalization component.
Content publishing option Task to runWPCP 4.2 Run time migrate-wpcp
WPCP 4.2 author time migrate-wpcp-author
WPCP 4.2 feedback migrate-wpcp-feedback
WCP 4.1 migrate-wpcp-author
Personalization Use WPCP GUI in WebSphere Portal Version 5.0.x to initiate migration.
Before you run these WebSphere Portal content publisher migration tasks, note the following points:
❍ DB2 UDB Version 8 Fix Pack 1 contains an incorrect version of the Universal JDBC Driver (db2jcc.jar and sqlj.zip). For instructions on how to obtain the new drivers, go to http://www.ibm.com/software/data/db2/udb/support.html and search for "db2jcc." In the search results you should select the item for the DB2 Version 8 Fix Pack and follow the instructions. Ensure that the db2jcc.jar file is updated.
❍ Before you perform the migration task, the db2java.zip file that resides on your WebSphere Portal Version 4.x system must be copied to the <wp5_root>/migration/lib directory, where <wp5_root> is the root directory of your WebSphere Portal Version 5.0.x system.
Enter the appropriate migration task to migrate WebSphere Portal content publishing, for example:
Windows: WPmigrate.bat migrate-wpcp UNIX: ./WPmigrate.sh migrate-wpcp
Refer to the Verifying the migration tasks section to verify that WebSphere Portal content
publishing was successfully migrated.
12. Optimize roles on the WebSphere Portal Version 5.0.x system. This step cleans up obsolete roles and role blocks that are created on WebSphere Portal Version 5.0.x resources during the migration process. If you use an external security manager, make sure that it is running before entering this command:
a. Enter the following command on one line to optimize roles: ■ Windows: WPmigrate.bat optimize-roles ■ Unix: ./WPmigrate.sh optimize-roles
b. Refer to the Verifying the migration tasks sectionto verify that roles were successfully optimized.
13. Proceed to Migrating the remaining access control configuration.
Next steps
You have completed this step. Continue to the next step by choosing the following topic:
● Migrating the remaining access control configuration
Performing migration with only one version running at a time
You can choose to run the migration tasks all at once without breaks or individually. If you choose the two-task option, you can run all the export tasks one after the other with a single command, and then you can run all the import tasks with a single command. If you choose the multitask option, you can run the import and export tasks one at a time. The multitask option gives you more individualized control over the migration tasks and allows you to choose which specific elements are migrated.
Next steps
You have completed this step. Continue to the next step by choosing one of the following topics:
● Performing two-task migration● Performing multitask migration
Performing two-task migration
This section details the tasks that are needed to perform two-task migration, using the export-all and import-all tasks. Refer to Migration tasks for more detailed information about the tasks.
After any migration task is completed, you can view the <wp5_root>migration/MigrationReport.xml file for a report. This will include timestamp, names of individual tasks that were attempted, and if they were successfully completed.
Note: If you are migrating WebSphere Portal content publishing, you must complete all WebSphere Portal content publishing Workflow tasks before you begin the migration process.
Important note: The path to all export files that are created with any of the export commands is <wp_root>/migration/work.
1. Change your working directory to the migration directory that was created when you installed WebSphere Portal Version 5.0.x. The path to this directory is dependent on your operating system. For example:
❍ Windows: c:\WebSphere\PortalServer\migration❍ AIX: /usr/WebSphere/PortalServer/migration❍ Solaris: /opt/WebSphere/PortalServer/migration
2. Make sure that WebSphere Portal Version 4.x is running and operational to your satisfaction.
3. Make sure that the mig_core.properties, mig_wpcp.properties, and mig_wmm.properties files are updated with all required parameters as indicated in these files. Supply optional parameters if desired. If you plan to migrate WebSphere Portal content publishing authoring and feedback, make sure that you update the mig_wpcp_author.properties and mig_wpcp_feedback.properties files.
4. Note the following information before running the export task: ❍ If you use an external security manager with WebSphere Portal Version 4.x and
WebSphere Portal Version 5.0.x, make sure that it is running.❍ If you do not explicitly assign a theme to your places or pages, WebSphere Portal Version 4.
x automatically uses the system default theme that you have selected in the Themes and Skins Administration. The configuration for the system default theme will not be exported by the export-all task unless a place or a page has been defined to explicitly use that theme. In this case, the configuration for the system default theme must be migrated using the export-themes-skins-configs task before running the export-all task. The export-themes-skins-configs task by default excludes themes that are supplied with WebSphere Portal Version 4.x, so if you are using a WebSphere Portal supplied theme as the system default theme, you must specifically use the -DincludeThemes parameter when running this task. For example, if you are using the theme "WebSphere" as the system default theme, you would run the following command to export the "WebSphere"
theme configuration: ■ Windows: WPmigrate.bat export-themes-skins-configs -DincludeThemes=WebSphere
■ Unix: WPmigrate.sh export-themes-skins-configs -DincludeThemes=WebSphere
The export-all task will not export portlets if they are not included on pages being exported by the export-places task. This includes clipping portlets that you have created but not included on pages. If you have such portlets, you must export them separately using the export-apps task, which also exports portlet settings and any access control information that is associated with the portlet while deploying the portlets. For example, to export all clipping portlets, use the following command:
■ Windows: WPmigrate.bat export-apps -DincludeApps="com.ibm.wps.portlets.clipper"
■ Unix: WPmigrate.sh export-apps -DincludeApps="com.ibm.wps.portlets.clipper"
5. Export places, pages, portlet applications, configuration for themes and skins, user customizations, portlet configuration data, and Notes and iNotes portlet settings by entering the following command on one line:
❍ Windows: WPmigrate.bat export-all ❍ Unix: ./WPmigrate.sh export-all
6. Optional: If WebSphere Portal Version 4.x and WebSphere Portal Version 4.x are installed on the same machine, you can now stop WebSphere Portal Version 4.x to minimize use of system resources.
7. Make sure that WebSphere Portal Version 5.0.x is running and operational to your satisfaction.
8. Note the following information before running the import-all task: ❍ If you exported themes in step 4, first import them using the following command:
■ Windows: WPmigrate.bat import-themes-skins-configs■ Unix: ./WPmigrate.sh import-themes-skins-configs
❍ If you exported any portlets in step 4, first import them using the following command:■ Windows: WPmigrate.bat import-apps■ Unix: ./WPmigrate.sh import-apps
❍ If you are using a remote Oracle database and the service name needed to access the database is different from the value specified by the WmmDbName property in the wpconfig.properties file, then you must enter the correct database on the command line by adding the -DWmmDbName parameter to the import-all command:
■ Windows: ./WPmigrate.sh import-all -DWmmDbName=<service_name>
■ Unix: ./WPmigrate.sh import-all -DWmmDbName=<service_name>
where: <service_name> is the service name for the remote Oracle database.
❍ If you use an external security manager with WebSphere Portal Version 5.0.x, make sure that it is running.
9. Enter the following command on one line to migrate WebSphere Member Services and WebSphere Portal content publishing run time data. This command will also import all data that is exported in step 4 (including places, pages, portlet applications, configuration for themes and skins, user customizations, portlet configuration data, and Notes and iNotes portlet settings).
❍ Windows: WPmigrate.bat import-all❍ Unix: ./WPmigrate.sh import-all
Parameters:❍ -DskipWpcpMigration=<true_false>❍ -DskipWmmMigration=<true_false>
where:❍ <true_false> specifies whether the corresponding task for WebSphere Portal migration will
be skipped. If set to true, the migrate-wpcp task or the migrate-wmm task will be skipped.
skipWpcpMigration: Set this parameter to true if you do not use WebSphere Portal content publishing Version 4.2 or if you do not want to migrate WebSphere Portal content publishing run-time data.
For example:
❍ Windows: WPmigrate.bat migrate-all -DskipWpcpMigration=true❍ Unix: ./WPmigrate.sh migrate-all -DskipWpcpMigration=true
If this parameter is set to false or is not specified, the import-alltask calls the migrate-wpcptask, which is only suitable to migrate the WebSphere Portal content publishing Version 4.2 run time. Based on the content publishing options that are supported by your WebSphere Portal 4.x offering, you might need to run different, additional migration tasks to migrate the content publishing run-time data. For example, WebSphere Portal Version 4.2.x included WebSphere Portal content publishing Version 4.2. WebSphere Portal Version 4.1.x offerings included WebSphere Portal content publishing Version 4.1 or a stand-alone Personalization component. Refer to the following table to determine which tasks you need to run.
Content publishing option Task to runWPCP 4.2 Run time migrate-wpcp
WPCP 4.2 author time migrate-wpcp-author
WPCP 4.2 feedback migrate-wpcp-feedback
WCP 4.1 migrate-wpcp-author
Personalization Use WPCP GUI in WebSphere Portal Version 5.0.x to initiate migration.
If skipWpcpMigrationis set to false, note the following points:
❍ DB2 UDB Version 8 Fix Pack 1 contains an incorrect version of the Universal JDBC Driver (db2jcc.jar and sqlj.zip). For instructions on how to obtain the new drivers, go to http://www.ibm.com/software/data/db2/udb/support.html and search for "db2jcc." In the search results you should select the item for the DB2 Version 8 Fix Pack and follow the instructions. Ensure that the db2jcc.jar file is updated.
❍ Before you perform the migration task, the db2java.zip file that resides on your WebSphere Portal Version 4.x system must be copied to the <wp5_root>/migration/lib directory, where <wp5_root> is the root directory of your WebSphere Portal Version 5.0.x system.
skipWmmMigration:In WebSphere Portal Version 4.x, the WebSphere Member Service database always acted as a Lookaside database. If you did not store additional attributes in a Lookaside database, you can skip Member Manager migration. For more informaton refer to Preparing to run the migration tasks, step 7.1. To do this, set skipWmmMigrationto true. For example:
❍ Windows: WPmigrate.bat migrate-all -DskipWmmMigration=true❍ Unix: ./WPmigrate.sh migrate-all -DskipWmmMigration=true
Next steps
You have completed this step. Continue to the next step by choosing the following topic:
● Migrating the remaining access control configuration
Performing multitask migration
This section details the tasks that are needed to perform migration. Before you begin running the migration tasks, carefully review the information in this bulleted list.
● Make sure that all parameters have the correct values in the mig_core.properties file. The optional parameters that are described in this section can be included in the properties file and can be specified on the command line. Any parameters that you enter on the command line will overwrite the entries in the mig_core.properties file. If you have already specified parameters listed after the tasks in the mig_core.properties file, you need only enter the task itself without parameters. Refer to Migration properties for a detailed description of the properties file parameters and to Migration tasks for more information about the migration tasks and their parameters.
● Optional migration tasks are provided during the development phase, when you might want to migrate individual artifacts and verify that they work as desired on WebSphere Portal Version 5.0.x. When migrating your production environments, it is recommended that you use one of the suitable scenarios described in the Running the migration tasks section. Do not use the optional tasks to migrate your production environments unless it is absolutely necessary.
● If you want to export and import themes, skins, portlet applications, and pages along with places, you can do so in the following steps 7 and 16. If you want to export and import themes, skins, portlet applications, and pages individually, you can use the tasks in the Optional migration tasks section.
● Before you begin running the migration tasks, read through all the steps and develop a plan for running them.
● After any migration task is completed, you can view the <wp5_root>/migration/MigrationReport.xml file for a report. This will include timestamp, names of individual tasks that were attempted, and if they were successfully completed.
Important note: The path to all export files is <wp5_root>/migration/work. For example, if you run the export-clients command and do not modify the default file name, the full path to your export file will be <wp5_root>/migration/work/clientsout.xml.
The following steps describe how to run the migration tasks: 1. Change your working directory to the migration directory that was created when you installed
WebSphere Portal Version 5.0.x. The path to this directory is dependent on your operating system. For example:
❍ Windows: c:\WebSphere\PortalServer\migration❍ AIX: /usr/WebSphere/PortalServer/migration❍ Solaris: /opt/WebSphere/PortalServer/migration
2. Make sure that WebSphere Portal Version 4.x is running and operational to your satisfaction.
3. Make sure that the mig_core.properties, mig_wmm.properties, and mig_wpcp.properties files are updated with all required parameters as indicated in the files. If you are migrating WebSphere Portal content publishing authoring and feedback, you need to review the mig_wpcp_author.properties and mig_wpcp_feedback.properties files.
4. Export permissions that WebSphere Portal Version 4.x users have on user groups.a. If you use an external security manager with WebSphere Portal Version 4.x, make sure that
it is running.
b. On the WebSphere Portal Version 4.x system, enter the following command on one line:■ Windows: WPmigrate.bat export-user-groups-ac ■ Unix: ./WPmigrate.sh export-user-groups-ac
Optional parameters: ■ -DfilenameUserGroupsAcOut=<filename>
where: ■ <filename> is the file to which access control information is exported. The default
file name is usergroupsacout.xml.
Note: Permissions on All Authenticated Users and All Anonymous Users are not migrated with this step. Permissions on All Anonymous and All Authenticated Users must be migrated using the procedure described in the Migrating the remaining access control configuration section.
5. If you had modified default portal clients that were supplied with WebSphere Portal Version 4.x or added custom clients, enter the following command on one line to export them from WebSphere Portal Version 4.x:
❍ Windows: WPmigrate.bat export-clients❍ Unix: ./WPmigrate.sh export-clients
Optional parameters: ❍ -DincludeClients=<include_names>❍ -DexcludeClients=<exclude_names>❍ -DfilenameClients=<filename>
where: ❍ <include_names> is a comma-separated list of case-sensitive portal client names to be
included in the export. If you do not specify a value for the includeClients parameter, by default all the clients will be exported.
❍ <exclude_names> is a comma-separated list of case-sensitive portal client names to be excluded from the export. If you specify a value for the excludeClients parameter, the
clients specified will not be exported. ❍ <filename> is the name of the file to which the portal client data will be exported. The
default is clientsout.xml.
6. Export settings from multiple Notes and iNotes Portlets from WebSphere Portal Version 4.x by entering the following command on one line:
❍ Windows: WPmigrate.bat export-notes-portlets ❍ Unix: ./WPmigrate.sh export-notes-portlets
Optional parameters: -DfilenameNotesPortlets=<filename>
where: <filename> is the name of the file to which the settings will be exported. The default is notesportletsout.xml.
7. Export places that are defined in WebSphere Portal Version 4.x by entering the following command on one line:
❍ Windows: WPmigrate.bat export-places❍ Unix: ./WPmigrate.sh export-places
Optional parameters: ❍ -DincludePlaces=<include_names> ❍ -DexcludePlaces=<exclude_names>❍ -DdeployPages=<true_false> ❍ -DdeployApps=<true_false>❍ -DconfigThemesSkins=<true_false> ❍ -DpathApps=<your_path>❍ -DfilenamePlaces=<filename>
where: ❍ <include_names> is a comma-separated list of places to be included in the export. If you do
not specify a value for the includePlaces parameter, by default all the places will be exported.
❍ <exclude_names> is a comma-separated list of places to be excluded from the export. If you specify a value for the excludePlaces parameter, the places specified will not be exported.
❍ <true_false> allows you to choose whether to export pages, portlet applications, and themes and skins along with the places. You can set this parameter to true to export these features along with places, or you can export them individually using the commands in the following optional tasks section.
❍ <your_path> points to a location where the XML configuration interface will look for WAR files during portlet deployment (for example, file:///usr/WebSphere/PortalServer/install). The default path is file://localhost/$server_root$/installableApps, which is equivalent to <wp5_root>/installableApps at run time.
❍ <filename> is the name of the file to which places will be exported. By default, the data will be exported to placesout.xml.
Note the following information: ❍ If you do not explicitly assign a theme to your places or pages, WebSphere Portal Version 4.
x automatically uses the system default theme you have selected in the Themes and Skins Administration. The configuration for the system default theme will not be exported by the export-places task, unless a place or a page has been defined to explicitly use that theme. In this case, the configuration for the system default theme must be exported using the export-themes-skins-configs task before running the export-places task. The export-themes-skins-configs task by default excludes themes that are supplied with WebSphere Portal Version 4.x, so if you are using a WebSphere Portal-supplied theme as the system default theme, you must specifically use the -DincludeThemes parameter when running this task. For example, if you are using the theme "WebSphere" as the system default theme, run the following command to export the "WebSphere" theme configuration:
■ Windows: WPmigrate.bat export-themes-skins-configs -DincludeThemes=WebSphere
■ Unix: WPmigrate.sh export-themes-skins-configs -DincludeThemes=WebSphere
The export-places task will not export portlets if they are not included on pages that are being exported using the export-places task. This includes clipping portlets that you have created but have not included on pages. If you have such portlets, you must export them separately using the export-apps task, which also exports portlet settings and any access control information that is associated with the portlet. For example, to export all clipping portlets, use the following command.
■ Unix: WPmigrate.sh export-apps -DincludeApps="com.ibm.wps.portlets.clipper"
■ Windows: WPmigrate.bat export-apps -DincludeApps="com.ibm.wps.portlets.clipper"
❍ The configThemesSkins, deployApps, and deployPages parameters are set to true by default. This will allow the export-places task to also export the corresponding pages that are used by the places, export the configuration of themes and skins that are used by the pages, and deploy portlet applications that are used on the pages. If you want to migrate these elements individually, make sure that the parameters are set to false and use the steps in the Optional migration tasks section. Note that the optional tasks are provided for your use during the development phase, when you want to migrate individual artifacts and verify that they work as desired on WebSphere Portal Version 5.0.x. When migrating your production environments, it is recommended that you use the export-places task and use the default value of true for the parameters configThemesSkins, deployApps, and deployPages.
8. Export all user customizations from WebSphere Portal Version 4.x. User cutomizations are artifacts that are attributed to a user that has EDIT but not MANAGE permissions on a page. They are created when such a user changes the layout of a page or edits portlet settings. The following command also exports user customizations for all Notes and iNotes portlets. Export user customizations by entering the following command on one line:
❍ Windows: WPmigrate.bat export-user-customizations❍ Unix: ./WPmigrate.sh export-user-customizations
Parameters: ❍ -DincludePages=<include_page_names> ❍ -DexcludePages=<exclude_page_names>❍ -DfilenameUserPages=<filename>
where: ❍ <include_page_names> is a comma-separated list of pages to be included in the export. If
you do not specify a value for the includePages parameter, by default all the pages will be exported.
❍ <exclude_page_names> is a comma-separated list of pages to be excluded from the export. If you do specify a value for the excludePages parameter, the pages specified will not be exported.
❍ <filename> is the name of the file to which the user customizations will be exported. By default, the data will be exported to userpagesout.xml.
9. Export Credential Vault segments and slots by entering the following command on one line. Existing credential vault data must be migrated with a separate manual procedure that is described in the Migrating the remaining access control configuration section.
❍ Windows: WPmigrate.bat export-credential-slots-segments ❍ Unix: ./WPmigrate.sh export-credential-slots-segments
Parameters:
❍ -filenameCredentialSlotsSegments=<filename>
where:❍ <filename> is the file name that is used for the exported Credential Vault data. If no
parameter is specified, this value is credentialslotssegmentsout.xml by default.
10. Optional: If WebSphere Portal Version 4.x and WebSphere Portal Version 4.x are installed on the same machine, you can now stop WebSphere Portal Version 4.x to minimize use of system resources.
11. Make sure that WebSphere Portal Version 5.0.x is running and is operational to your satisfaction.
12. Migrate users, groups, and extended user attributes from WebSphere Portal Version 4.x (WebSphere Member Services) to WebSphere Portal Version 5.0.x (Member Manager). Skip step 12 if you did not use a Lookaside database to store additional attributes in WebSphere Portal Version 4.x. If you did not use a Lookaside database, you do not need to migrate Member Manager. For more information, refer to Preparing to run the migration tasks, step 7.1.
a. Migrate users, groups, and extended user attributes by entering the following command on one line:
■ Windows: WPmigrate.bat migrate-wmm ■ Unix: ./WPmigrate.sh migrate-wmm
Note the following information: ■ Ensure that the Member Manager and WebSphere Member Services databases
have the same database user ID before proceeding. If the database user IDs do not match, the migrate-wmm command will fail.
■ If you are using a remote Oracle database and the service name needed to access the database is different from the value specified by the WmmDbName property in the wpconfig.properties file, then you must enter the correct database on the command line by adding the -DWmmDbName parameter to the migrate-wmm command:
■ Windows: WPmigrate.bat migrate-wmm -DWmmDbName=<service_name>■ Unix: ./WPmigrate.sh migrate-wmm -DWmmDbName=<service_name>
where: <service_name> is the service name for the remote Oracle database.
b. Refer to the Verifying the migration tasks section to verify that extended user attributes were successfully migrated.
13. Import permission on user groups that were exported in step 4.
a. Import access control on user groups by entering the following command on one line:■ Windows: WPmigrate.bat import-user-groups-ac ■ Unix: ./WPmigrate.sh import-user-groups-ac
Optional parameters: ■ -DfilenameUserGroupsAcOut=<filename>
where: ■ <filename> is the file to which the access control on user groups was exported in
step 4.
b. Refer to the Verifying the migration tasks section to verify that access control on user groups was successfully migrated.
14. Import clients that were exported in step 5.a. Import clients by entering the following command on one line:
■ Windows: WPmigrate.bat import-clients ■ Unix: ./WPmigrate.sh import-clients
Optional parameters:
■ -DfilenameClients=<filename>
where: ■ <filename> is the name of the file to which clients were exported in step 5.
b. Refer to the Verifying the migration tasks section to verify that portal clients were successfully migrated.
15. Import settings from multiple Notes and iNotes Portlets that were exported in step 6.a. Import settings from multiple Notes and iNotes Portlets by entering the following command
on one line:■ Windows: WPmigrate.bat import-notes-portlets ■ Unix: ./WPmigrate.sh import-notes-portlets
Optional parameters: ■ -DfilenameNotesPortlets=<filename>
where: ■ <filename> is the name of the file to which Notes portlets were exported in step 6.
b. Refer to the Verifying the migration tasks section to verify that Notes and iNotes portlets were successfully migrated.
16. Import places exported in step 7.
Note the following information:❍ If you exported themes in step 7, first import them using the following command:
■ Windows: WPmigrate.bat import-themes-skins-configs■ Unix: ./WPmigrate.sh import-themes-skins-configs
❍ If you exported any portlets in step 7, first import them using the following command: ■ Windows: WPmigrate.bat import-apps■ Unix: ./WPmigrate.sh import-apps
a. Import places by entering the following command on one line: ■ Windows: WPmigrate.bat import-places ■ Unix: ./WPmigrate.sh import-places
Optional parameters: ■ -DfilenamePlaces=<filename>
where: ■ <filename> is the name of the file to which places were exported in step 7.
b. Refer to the Verifying the migration tasks section to verify that places were successfully
migrated.
17. Import all user customizations that were exported in step 8.a. Enter the following command on one line to import user customizations:
■ Windows: WPmigrate.bat import-user-customizations ■ Unix: ./WPmigrate.sh import-user-customizations
Parameters: ■ -DfilenameUserPages=<filename>
where: ■ <filename> is the name of the file to which user customizations were exported in
step 8.
b. Refer to the Verifying the migration tasks section to verify that user customizations were successfully migrated.
18. Import Credential Vault slots and segments that were exported in step 9. a. Enter the following command on one line:
■ Windows: WPmigrate.bat import-credential-slots-segments■ Unix: ./WPmigrate.sh import-credential-slots-segments
Parameters: ■ -DfilenameCredentialSlotsSegments=<filename>
where: ■ <filename> is the name of the file to which slots and segments were exported in step
9.
b. Refer to the Verifying the migration tasks section to verify that Credential Vault slots were successfully migrated.
19. The following steps allow you to migrate contents in Personalization, WebSphere Content Publishing, or WebSphere Portal Content Publisher from WebSphere Portal Version 4.x to WebSphere Portal Version 5.0.x.
Based on the content publishing options that are supported by your WebSphere Portal 4.x offering, you might need to run different migration tasks. WebSphere Portal 4.2.x shipped with WebSphere Portal content publishing 4.2, and WebSphere Portal 4.1.x offerings shipped with WebSphere Content Publisher 4.1 or a stand-alone Personalization component.
Content publishing option Task to runWPCP 4.2 Run time migrate-wpcp
WPCP 4.2 author time migrate-wpcp-author
WPCP 4.2 feedback migrate-wpcp-feedback
WCP 4.1 migrate-wpcp-author
Personalization Use WPCP GUI in WebSphere Portal Version 5.0.x to initiate migration.
Before you run these WebSphere Portal content publishing migration tasks, note the following points:
❍ DB2 UDB Version 8 Fix Pack 1 contains an incorrect version of the Universal JDBC Driver (db2jcc.jar and sqlj.zip). For instructions on how to obtain the new drivers, go to http://www.ibm.com/software/data/db2/udb/support.html and search for "db2jcc." In the search results you should select the item for the DB2 Version 8 Fix Pack and follow the instructions. Ensure that the db2jcc.jar file is updated.
❍ Before you perform the migration task, the db2java.zip file that resides on your WebSphere Portal Version 4.x system must be copied to the <wp5_root>/migration/lib directory, where <wp5_root> is the root directory of your WebSphere Portal Version 5.0.x system.
Enter the appropriate migration task to migrate WebSphere Portal content publishing, for example:
Windows: WPmigrate.bat migrate-wpcp UNIX: ./WPmigrate.sh migrate-wpcp
Refer to the Verifying the migration tasks section to verify that WebSphere Portal content publishing was successfully migrated.
20. Optimize roles on the WebSphere Portal Version 5.0.x system. This step cleans up obsolete roles and role blocks that are created on WebSphere Portal Version 5.0.x resources during the migration process. If you use an external security manager, make sure that it is running before entering this command:
a. Enter the following command on one line to optimize roles: ■ Windows: WPmigrate.bat optimize-roles ■ Unix: ./WPmigrate.sh optimize-roles
b. Refer to the Verifying the migration tasks sectionto verify that roles were successfully optimized.
21. Proceed to Migrating the remaining access control configuration.
Next steps
You have completed this step. Continue to the next step by choosing the following topic:
● Migrating the remaining access control configuration
Verifying the migration tasks
This section details steps that can be used to verify the success of the migration tasks.
1: Steps to verify migration of extended user attributes2: Steps to verify migration of access control on user groups and role optimization3: Steps to verify Notes and iNotes portlets migration4: Steps to verify migration of portal clients5: Steps to verify migration of places and pages6: Steps to verify migration of user customizations7: Steps to verify migration of credential vault data8: Steps to verify migration of WebSphere Portal content publishing9: Steps to verify role optimization10: Steps to verify migration of themes and skins11: Steps to verify migration of portlet applications12: Steps to verify migration of portlet configuration data
1: Steps to verify migration of extended user attributes1. Open the trace.log file in the <wp5_root>/migration/work/templates/wmm directory.
Check to see if there are any exceptions or errors occurring.
2. Depending on the database and the Member Manager configuration, check the following items:
❍ DB2:Check the loader.log file in the directory <wp5_root>/migration/work/templates/wmm/db2/database or the directory <wp5_root>/migration/work/templates/wmm/db2/lookaside. Verify that all rows have been loaded properly.
❍ Oracle:Check the different log files in the directory <wp5_root>/migration/work/templates/wmm/oracledatabase or the directory <wp5_root>/migration/work/templates/wmm/oracle/lookaside.Verify that all rows have been loaded properly.
❍ SQLServer: Check the different log files in the directory <wp5_root>/migration/work/templates/wmm/sqlserver/database or the directory <wp5_root>/migration/work/templates/wmm/sqlserver/lookaside.Verify that all rows have been loaded properly.
❍ Informix:Check the different log files in the directory <wp5_root>/migration/work/templates/wmm/informix/database or the directory <wp5_root>/migration/work/templates/wmm/informix/lookaside. Verify that all rows have been loaded properly.
3. Check the WebSphere Member Services and Member Manager tables to see if the data has been migrated:
❍ For database-only configuration:
Check the following WebSphere Member Services tables and the corresponding Member Manager tables to verify that the data has been migrated.
WebSphere Member Services Table Name Member Manager Table Name
MEMBER WMMDBMBR
MBRGRPMBR WMMGRPMBR
MBRREL WMMMBRREL
USERREG WMMUSERREG
Check that the Member Manager table WMMDBATR contains the attributes that are to be migrated. The following attributes should be in the WMMDBATR table: uid, userPassword, cn, sn, mail, preferredLanguage, and givenName.The WMMDBASVAL, WMMDBAIVAL, WMMDBABVAL, WMMDBADVAL, and WMMDBABVAL tables contain data depending on the type of the attributes to be migrated. The following table lists each table with its type of attribute.
Table Attribute type WMMDBASVAL string
WMMDBAIVAL integer
WMMDBABVAL big integer
WMMDBADVAL double
WMMDBATVAL timestamp
Check the WebSphere Member Services MBRATTRVAL table to see if the attributes values for the attributes that are to be migrated are properly inserted into the proper Member Manager attribute value table.
❍ For LDAP + DB configuration:
Check the data in the following WebSphere Member Services tables and their corresponding Member Manager tables:
WebSphere Member Services Table Name Member Manager Table Name
MEMBER WMMLAMBR
MEMBER WMMLAEXTID
The WMMLAASVAL, WMMLAAIVAL, WMMLAABVAL, WMMLAADVAL, and
WMMLAABVAL tables contain attribute values data depending on the type of attributes to be migrated.The attributes uid, userPassword, cn, sn, mail, preferredLanguage, and givenName would be migrated to the WMMLAASVAL table (assuming that data existed in WebSphere Member Services in the MBRATTRVAL table for those attributes). Note that only the attributes and attribute values that are not mapped to an LDAP plug-in attribute will be migrated to the Lookaside database. For example, if the attribute cn is defined in the file attributeMap.xml (the file that was copied to the <wp_root>migration/templates/wmm/xml/migration directory), then it will not be migrated because the attribute is contained in the LDAP and not in the WebSphere Member Services tables.
2: Steps to verify migration of access control on user groups and role optimization1. Log in to the WebSphere Portal Version 5.0.x Administrative Interface.2. Click Access Resource Permissions. 3. Verify that the permissions users have on the User Groups resource type are equivalent to those in
WebSphere Portal Version 4.x.4. Make sure that only redundant roles have been removed.
You can also refer to Access control changes for further verification information.
3: Steps to verify Notes and iNotes portlets migrationVerify that Notes were successfully migrated using the WebSphere Portal Version 5.0.x Administrative interface. You can verify that your version 5.0.x portlet settings are the same as your version 4.x settings by looking in the Manage Portlets page. There should be a portlet in the portlet list for each portlet that existed in version 4.x. Note that in WebSphere Portal Version 4.x, these portlets were individual portlets, while in WebSphere Portal Version 5.0.x, they are copies of one portlet. Select each portlet, click Modify parameters, and verify that the portlet settings were migrated correctly. If you are migrating pages that had Notes portlets in them, the portlets should be on the page after migration and should work as they did on the version 4.x system.
4: Steps to verify migration of portal clients1. Log in to the WebSphere Portal Version 5.0.x Administrative Interface.2. Click Administration Portal Settings Supported Clients.3. Verify that the portal clients that you migrated show up in the list of supported clients.4. Select the clients that were migrated and click Edit Selected Clients to verify that all settings for
the client were migrated.5. Verify that your migrated clients are able to access WebSphere Portal.
5: Steps to verify migration of places and pages
The concept of a "place" does not exist in WebSphere Portal Version 5.0.x. WebSphere Portal Version 4.x places are treated like top-level pages in WebSphere Portal Version 5.0.x.
1. Log in to the WebSphere Portal Version 5.0.x Administrative Interface.2. Click Portal user interface Manage pages on the left navigation.3. All migrated places show up under the content root that is labeled My Portal. Settings for the
migrated pages can be accessed by following the link that is provided for each page under the
migrated place.4. For each migrated place, click on the page properties to verify the title and ensure that it uses the
same theme as WebSphere Portal Version 4.x. In the Advanced Options section, verify that supported markup settings and the titles and descriptions for other languages were migrated successfully.
5. For each page under the migrated place, click Edit page properties to verify that the title was migrated successfully. Also verify the options under the Advanced Options section.
6. For each page under the migrated place, click Edit Page Layout to verify the page layout and the portlets that are included on the page. Select the Appearance tab and ensure that the portlets on the page use the same skin as WebSphere Portal Version 4.x
You can also perform a full export of WebSphere Portal Version 5.0.x after migration is complete and verify the migrated places, pages and roles in the exported XML file. Refer to The XML configuration interface - Changes for WebSphere Portal 5.0.x for more information.
You should also verify the access control for migrated pages using the Administrative Interface.
1. Click Access Resource Permissions and select Pages from Resource Types. This displays the top-level page Content Root.
2. Click Content Root My Portal to display a list of pages that were migrated.3. Click Assign Access to verify the access control information.
You can also perform a full export of WebSphere Portal Version 5.0.x after migration is complete and verify the roles in the exported XML file. Refer to The XML configuration interface for more information.
Note: If a page does not support any of the languages determined by the portal language selection process, then the object ID of the page is displayed in the navigation rather than its title. Such an object ID can be, for example, 7_0_5T . For details about the language selection process, see Language determined by the portal
6: Steps to verify migration of user customizations
User customizations are artifacts that are attributed to a portal user that has EDIT but not MANAGE permissions on a page. These are created when such a user changes the layout of a page or edits portlet settings.
1. Log in to WebSphere Portal Version 5.0.x with credentials of users having the customizations.2. Verify that all user customizations from WebSphere Portal Version 4.x are present in WebSphere
Portal Version 5.0.x. You can also pick users at random and ensure that the users see the correct customizations in WebSphere Portal 5.0.x by comparing them visually to customizations in WebSphere Portal Version 4.x.
7: Steps to verify migration of credential vault segments and slots
These procedures help verify that the credential slots and segments were migrated successfully. Existing credential vault data must be migrated with a separate manual procedure that is described in the Migrating the remaining access control configuration section.
1. Log in to the WebSphere Portal Version 5.0.x Administrative Interface.
2. Click Access and then click Credential Vault on the left navigation.3. Using the Manage vault segments and Manage system vault slots options, verify that credential
segments and slots from WebSphere Portal Version 4.0 are now also present in WebSphere Portal Version 5.0.x.
8: Steps to verify migration of WebSphere Portal content publishing
To verify successful migration of run time, check PersAdmin for resources and campaigns and run your pages to check rules. To verify authoring, log in to the workspace and make sure that all projects and content are migrated. To verify feedback, check the database to verify that the data was migrated.
9: Steps to verify role optimization
Check to make sure that:
● No user has more privileges than he or she did before optimization.● No user has fewer privileges than he or she did before before optimization.● The number of role assignments is less or equal to the number of role assignments before
optimization.● The number of role blocks is less or equal to the number of role blocks before optimization.● Pages that were private resources before migration (meaning the pages were implicitly derived and
only one user could see them) are private resources in WebSphere Portal Version 5.0.x.
10: Steps to verify migration of themes and skins1. Log in to the WebSphere Portal Version 5.0.x Administrative Interface.2. Click Portal user interface Themes and Skins in the left navigation.3. Verify that the themes and skins that are listed are the ones that you migrated from WebSphere
Portal Version 4.x to WebSphere Portal Version 5.0.x.4. Verify that you are able to associate migrated themes and skins to existing pages and portlets, and
verify that they produce the desired view.
11: Steps to verify migration of portlet applications1. Log in to the WebSphere Portal Version 5.0.x Administrative Interface.2. Click Portlets Manage applications on the left navigation.3. Verify that the portlet applications that are listed are the ones that you migrated from WebSphere
Portal Version 4.x.4. For each Web Module, verify that all your portlet applications also display in the Portlet
Applications list.5. For each portlet application that is migrated and for which you have set up parameters on
WebSphere Portal Version 4.x, click Modify parameters next to the portlet applications list and verify that the parameters were migrated correctly.
You should also verify the access control for migrated portlet application and portlets using the Administrative Interface.
1. Click Access Resource Permissions and select Portlet Applications from Resource Types.
2. Click Assign Access to verify the access control information.
3. Click Access Resource Permissions and select Portlets from Resource Types. 4. Click Assign Access to verify the access control information.
You can also perform a full export of WebSphere Portal Version 5.0.x after migration is complete and verify the roles in the exported XML file. Refer to The XML configuration interface for more information.
12: Steps to verify migration of portlet configuration data1. Log in to the WebSphere Portal Version 5.0.x Administrative Interface.2. Click Portlets Manage portlets on the left navigation.3. Verify that all portlet configuration data migrated from WebSphere Portal Version 4.x are present in
WebSphere Portal Version 5.0.x by selecting the portlet from the list and clicking Modify Parameters.
Next steps
You have completed this step. Continue to the next step by choosing the following topic:
● Migrating the remaining access control configuration
Migrating the remaining access control configuration
This section explains procedures that are necessary to migrate specific access control configurations that are not handled automatically by the migration process. Perform these procedures after completing the steps described in the Running the migration tasks section.
1: Migrating permissions on All Authenticated and All Anonymous Users2: Migrating permissions on resource types2.1: Migrating permissions on the External_ACL resource2.2: Migrating permissions on the Portal resource
3: Migrating permissions on administrative places, pages, and portlets3.1: Migrating permissions on WebSphere Portal Version 4.1.x administrative resources3.2: Migrating permissions on WebSphere Portal 4.2.x administrative resources
4: Migrating credential vault data5: Deleting WebSphere Portal Version 4.x resource entries from Tivoli Access Manager
1: Migrating permissions on All Authenticated and All Anonymous Users
Permissions on User Groups in WebSphere Portal Version 4.x allowed principals to perform the following tasks:
● Edit group information● Change group membership● Change the access rights of the group members
The instructions in the Running the migration tasks section explain how to use commands to automatically migrate most permissions on user groups. These commands do not migrate permissions on All Authenticated Users and All Anonymous Users. You must use the following steps to migrate permissions on All Authenticated Users and All Anonymous Users.
Follow these steps to migrate permissions on user groups:
1. Use the WebSphere Portal Version 4.x ACL portlet to determine the permissions that principals had on All Authenticated Users and All Anonymous Users.
2. Consult the table in the Planning section to determine which roles correspond to the WebSphere Portal Version 4.x permissions.
3. On the WebSphere Portal Version 5.0.x system, use the User and Group Permissions portlet, the Resource Permissions portlet, or the XML configuration interface to assign the principals to roles on the appropriate user groups. For more information, refer to the portlet helps or XML configuration interface.
2: Migrating resource type permissions
In WebSphere Portal Version 4.x, principals could have Create and Delegate permissions on resource
types. The role-based access control for WebSphere Portal Version 5.0.x does not provide an exact equivalent for permissions on resource types. WebSphere Portal Version 5.0.x uses virtual resources instead of resource types. For more information about virtual resources, see Resources.
The following table maps WebSphere Portal Version 4.x resource types to WebSphere Portal Version 5.0.x virtual resources:
Resource Type Virtual Resource
Portlet ApplicationsPortlet ApplicationsThis virtual resource includes all portlets and portlet applications.
PortletsPortlet ApplicationsThis virtual resource includes all portlets and portlet applications.
PagesPagesThis virtual resource includes all pages, labels, and external URLs.
PlacesPagesThis virtual resource includes all pages, labels, and external URLs.
User Groups User Groups
Portal Portal
External_ACL External Access Control
Resource Collections N/A
Principals with Delegate permission on WebSphere Portal Version 4.x resource types should be assigned Security Administrator roles on the appropriate WebSphere Portal Version 5.0.x virtual resources. The Security Administrator role allows principals to modify the access control configuration for all child resources of the corresponding virtual resource.
Create permissions do not need to be migrated because they are not necessary in WebSphere Portal Version 5.0.x. In WebSphere Portal Version 5.0.x, principals with the Administrator, Manager, Editor, or Privileged User roles on a resource are automatically allowed to create new resources underneath that resource in the resource hierarchy.
Follow these steps to manually migrate permissions on resource types:
1. Determine which principals had permissions on each resource type in WebSphere Portal Version 4.x. Using the WebSphere Portal Version 4.x administrative interface to determine permissions on each resource type for all principals is difficult. In the administrative interface, permissions are displayed by principal. In order to determine which principals have which permissions, you must select each principal individually and determine if they had permissions on a resource type. A quicker alternative is to use the SQL queries that is decribed here to determine the list of principals. :
a. Run the following SQL commands on WebSphere Portal 4.x database to determine which principals had permissions on various resource types. These commands do not help you
determine which permissions the principals have; as described in step b, you must still use the ACL portlet to determine exactly which permissions the principals have.Portal: select name from user_desc where oid in (select subjectid from acl where objecttype=0 and objectid=-1) Pages: select name from user_desc where oid in (select subjectid from acl where objecttype=3 and objectid=-1) Portlet Applications: select name from user_desc where oid in (select subjectid from acl where objecttype=15 and objectid=-1) Portlets: select name from user_desc where oid in (select subjectid from acl where objecttype=2 and objectid=-1) User Groups: select name from user_desc where oid in (select subjectid from acl where objecttype=4 and objectid=-1) Users: select name from user_desc where oid in (select subjectid from acl where objecttype=1 and objectid=-1) External_ACL: select name from user_desc where oid in (select subjectid from acl where objecttype=18 and objectid=-1)
b. For each set of principals that is returned by the above queries, use the WebSphere Portal Version 4.x ACL portlet to determine which principals had the Delegate permission on each resource type.
2. Consult the preceding table to determine which WebSphere Portal Version 5.0.x virtual resources correspond to the WebSphere Portal Version 4.x resource types.
3. For each set of principals that had delegate permissions on the resource types, use the Resource Permissions portlet, the User and Groups Permissions portlet, or the XML configuration interface on the WebSphere Portal Version 5.0.x system to assign principals to Security Administrator roles on the appropriate virtual resources. For more information, refer to the portlet helps or the XML configuration interface.
2.1: Migrating permissions on the External_ACL resource
Users with Manage + Delegate permissions on the External_ACL resource in WebSphere Portal Version 4.x were allowed to put resources under the protection of an external security manager such as Tivoli Access Manager. This permission maps to the Security Administrator@External Access Control role in WebSphere Portal Version 5.0.x.
Follow these steps to manually migrate permissions on the External_ACL resource:
1. On the WebSphere Portal Version 4.x system, use the ACL portlet or the XML configuration interface to determine the permissions that principals had on the External_ACL resource.
2. Consult the preceding resource type mapping table and the role mapping table in the Planning section to determine how the WebSphere Portal Version 4.x resource types and permissions correspond to WebSphere Portal Version 5.0.x virtual resources and roles.
3. Use the external security manager interface to assign the principals to roles on the External Access Control virtual resource.
2.2: Migrating permissions on the Portal resource
Principals with Manage permission on the Portal resource in WebSphere Portal Version 4.x were allowed to change the access control configuration of the portal. This permission maps to the Security Administrator@Portal role.
User who had Manage and Delegate permissions on the Portal resource in WebSphere Portal Version 4.x can be added to the wpsadmins group in WebSphere Portal Version 5.0.x to get access to the portal.
Follow these steps to manually migrate permissions on the Portal resource:
1. On the WebSphere Portal Version 4.x system, use the ACL portlet or the XML configuration interface to determine the permissions that principals had on the Portal resource.
2. Consult the preceding resource type mapping table and the role mapping table in the Planning section to determine how the WebSphere Portal Version 4.x resource types and permissions correspond to WebSphere Portal Version 5.0.x virtual resources and roles.
3. On the WebSphere Portal Version 5.0.x system, use the Resource Permissions portlet, the User and Group Permissions portlet, or the XML configuration interface to assign the principals to roles on the Portal virtual resource. For more information, refer to the portlet helps or XML configuration interface.
3: Migrating permissions for administrative places, pages, and portlets
Because the administrative places, pages, and portlets have changed in different releases of WebSphere Portal, permissions on these resources must be manually migrated. The following sections show the mapping between the administrative resources in previous versions of WebSphere Portal and WebSphere Portal Version 5.0.x.
Follow these steps to migrate permissions on administrative places, pages, and portlets:
1. On the WebSphere Portal Version 4.x system, use the ACL portlet or the XML configuration interface to determine the permissions that principals had administrative resources.
2. Consult the following tables to determine how the administrative resources in WebSphere Portal Version 4.x correspond to WebSphere Portal Version 5.0.x.
3. On the WebSphere Portal Version 5.0.x system, use the Resource Permissions portlet, the User and Groups Permissions portlet, or the XML configuration interface to assign principals to roles on the appropriate administrative resources. For more information, refer to the portlet helps or XML configuration interface.
3.1: Migrating permissions on WebSphere Portal Version 4.1.x administrative resources
The following table explains how to map administrative resources from WebSphere Portal Version 4.1.x to WebSphere Portal Version 5.0.x in a way that takes advantage of inheritance through the resource hierarchy in WebSphere Portal Version 5.0.x.
4.1 Administrative Page Group/Page Version 5.0.x Administrative Page
Work with Pages Page Customizer
Edit Layout and Content inherit from Page Customizer
Manage Places and Pages inherit from Portal User Interface
Set Permissions inherit from Page Customizer
Choose Skins inherit from Page CustomizerPortal Administration Administration
Portlets Portlets
Install Portlets inherit from Portlets
Portlet Applications inherit from Portlets
Manage Portlets inherit from Portlets
Web Clipping inherit from Portlets
Manage Web Services N/A
Web Services N/A
Portal Settings Portal Settings
Global Settings inherit from Portal Settings
Themes and Skins inherit from Portal User Interface
Manage Clients inherit from Portal Settings
Manage Markups inherit from Portal Settings
Manage Search Index inherit from Portal Settings
Enable Tracing inherit from Portal Analysis
Users and Groups Access
Manage Users inherit from Access
Manage Groups inherit from Access
Security Access
Access Control List inherit from Access
Credential Vault inherit from Access
Portal Content N/A
Manage Content Organizer N/A
Content Organizer N/A
N/A Portal User Interface
N/A URL Mapping - inherit from Portal Settings
N/A Custom Unique Names - inherit from Portal Settings
N/A Portal Analysis
N/A Frequent Users - inherit from WebSphere Portal Analysis
The following table shows a one-to-one mapping of the administrative place and page hierarchy from WebSphere Portal Version 4.1.x to WebSphere Portal Version 5.0.x. This information is provided for reference only; do not use this table as a guide for migrating permissions on administrative resources. Use the preceding table to help you migrate permissions on administrative resources.
4.1.x Administrative Page Group/Page Version 5.0.x Administrative Page
Work with Pages Page Customizer
Edit Layout and Content Content
Manage Page Groups and Pages Manage Pages/Properties
Set Permissions Locks
Choose Skins AppearancePortal Administration Administration
Portlets Portlets
Install Portlets Install
Portlet Applications Manage Applications
Manage Portlets Manage Portlets
Web Clipping Web Clipping
Manage Web Services N/A
Web Services N/A
Portal Settings Portal Settings
Global Settings Global Settings
Themes and Skins Themes and Skins
Manage Clients Supported Markups
Manage Markups Supported Clients
Enable Tracing Enable Tracing
Users and Groups Access
Manage Users Users and Groups
Manage Groups Users and Groups
Security Access
Access Control List Resource Permissions and User Group Permissions
Credential Vault Credential Vault
Portal Content N/A
Manage Content Organizer N/A
Content Organizer N/A
N/A Portal User Interface
N/A URL Mapping
N/A Custom Unique Names
N/A Portal Analysis
N/A Frequent Users
Administrative Portlets
The following table maps administrative portlets from WebSphere Portal Version 4.1.x to WebSphere Portal Version 5.0.x.
4.1 Administrative Portlet Version 5.0.x Administrative Portlet Edit Layout and Content Content
Manage Page Groups and Pages Manage Pages/Properties
Set Permissions Locks
Choose Skins Appearance
Install Portlet Install Portlet
Manage Portlet Applications Manage Portlet Applications
Manage Portlets Manage Portlets
Web Clipper Web Clipper
Manage Web Services N/A
Web Services N/A
Global Settings Global Settings
Themes and Skins Themes and Skins
Manage Clients Manage Clients
Manage Markups Manage Markups
Enable Tracing Enable Tracing
Manage Users Users and Group
Manage User Groups Users and Group
Access Control List Resource Permissions/User Group Permissions
Credential Vault Credential Vault
Manage Content Organizer PDM
N/A Frequent Users
3.2: Migrating permissions on WebSphere Portal 4.2.x administrative resources
The following table explains how to map administrative resources from WebSphere Portal 4.2.x to WebSphere Portal Version 5.0.x in a way that takes advantage of inheritance through the resource hierarchy in WebSphere Portal Version 5.0.x.
4.2.x Administrative Page/Place Version 5.0.x Administrative Page
Work with Pages Page Customizer
Edit My Pages inherit from Page Customizer
Edit Layout inherit from Portal User Interface
Manage Pages and Places inherit from Page Customizer
Set Permissions inherit from Page Customizer
Choose Skins inherit from Page Customizer
Organize Favorites Organize FavoritesPortal Administration Administration
Portlets Portlets
Install Portlets inherit from Portlets
Portlet Applications inherit from Portlets
Manage Portlets inherit from Portlets
Web Clipping inherit from Portlets
Manage Web Services N/A
Web Services N/A
Portal Settings Portal Settings
Global Settings inherit from Portal Settings
Themes and Skins inherit from Portal User Interface
Manage Clients inherit from Portal Settings
Manage Markups inherit from Portal Settings
Manage Search Index inherit from Portal Settings
Enable Tracing inherit from Portal Analysis
Users and Groups Access
Manage Users inherit from Access
Manage Groups inherit from Access
Security Access
Access Control List inherit from Access
Credential Vault inherit from Access
Portal Content N/A
Manage Content Organizer N/A
Content Organizer N/A
N/A Portal User Interface
N/A URL Mapping - inherit from Portal Settings
N/A Custom Unique Names - inherit from Portal Settings
N/A Portal Analysis
N/A Frequent Users - inherit from Portal Analysis
The following table shows a one-to-one mapping of the administrative place and page hierarchy from WebSphere Portal 4.2.x to WebSphere Portal Version 5.0.x. This information is provided for reference only; do not use this table as a guide for migrating permissions on administrative resources. Use the preceding table to help migrate permissions on administrative resources.
4.2.x Administrative Page Group/Page Version 5.0.x Administrative Page
Work with Pages Page Customizer
Edit My Pages Content
Edit Layout Content
Manage Places and Pages Manage Pages/Properties
Set Permissions Locks
Choose Skins Appearance
Organize Favorites Organize FavoritesOrganize Favorites Administration
Portlets Portlets
Install portlets Install
Portlet Applications Manage Applications
Manage Portlets Manage Portlets
Web Clipping Web Clipping
Manage Web Services N/A
Web Services N/A
Portal Settings Portal Settings
Global Settings Global Settings
Themes and Skins Themes and Skins
Manage Clients Supported Markups
Manage Markups Supported Clients
Enable Tracing Enable Tracing
Users and Groups Access
Manage Users Users and Groups
Manage Groups Users and Groups
Security Access
Access Control List Resource Permissions and User Group Permissions
Credential Vault Credential Vault
Portal Content N/A
Manage Content Organizer N/A
Content Organizer N/A
N/A Portal User Interface
N/A URL Mapping
N/A Custom Unique Names
N/A Portal Analysis
N/A Frequent Users
Administrative Portlets
The following table maps administrative portlets from WebSphere Portal 4.2.x to WebSphere Portal Version 5.0.x.
4.2.x Administrative Portlet Version 5.0.x Administrative Portlet Quick Customizer Content
Edit Layout and Content Content
Manage Page Groups and Pages Manage Pages/Properties
Set Permissions Locks
Choose Skins Appearance
Organize Favorites Organize Favorites
Install Portlet Install Portlet
Manage Portlet Applications Manage Portlet Applications
Manage Portlets Manage Portlets
Web Clipper Web Clipper
Manage Web Services N/A
Web Services N/A
Global Settings Global Settings
Themes and Skins Themes and Skins
Manage Clients Manage Clients
Manage Markups Manage Markups
Enable Tracing Enable Tracing
Manage Users Users and Group
Manage User Groups Users and Group
Access Control List Resource Permissions/User Group Permissions
Credential Vault Credential Vault
Manage Content Organizer PDM
N/A Frequent Users
4: Migrating credential vault data
The migration process automatically migrates Credential Vault slots and segments with the migrate-credential-slots-segments task. This section assumes that the migrate-credential-slots-segments task has been completed successfully.
Existing credentials are handled differently depending on your environment:
● Standard WebSphere Portal Vault: complete the following procedure if you want to migrate existing credentials to the WebSphere Portal Version 5.0.x system.
● Third-party vault implementation (Tivoli Access Manager): No additional steps are required. Existing credentials should function in the WebSphere Portal Version 5.0.x system.
If you decide not to migrate existing credentials, users must provide their credential information the first time a Version 5.0.x portlet attempts to use the data.
Migrating the credentials involves moving two tables, VAULT_DATA and VAULT_RESOURCES from the WebSphere Portal Version 4.x database to the WebSphere Portal Version 5.0.x database. The table definition has not changed in WebSphere Portal Version 5.0.x, so the data does not need to be changed. There are two ways to move the tables:
● Back up and restore the tables● Use an import and export utility that is provided by the database server
The following example explains how to import and export the tables when DB2 is the database server. Use this example as general guide for your environment. Perform this procedure before any users have accessed the WebSphere Portal Version 5.0.x system and potentially added additional data to the system.
1. Export the tables from the WebSphere Portal Version 4.x database. a. On the WebSphere Portal Version 4.x database server, start the DB2 Command Line
Processor (CLP) (Windows) or the DB2 shell (Unix).b. Enter the following commands:
db2 connect to <wps4x-db> user <dbuser> using <dbuserpw>db2 export to C:/temp/vault.data.wp4.ixf of ixf messages C:/temp/vault.data.wp4.msgtxt select * from VAULT_DATAdb2 export to C:/temp/vault.res.wp4.ixf of ixf messages C:/temp/vault/res.wp4.msgtxt select * from VAULT_RESOURCESdb2 disconnect wps40
where <dbuser> is the database administrator user ID and <dbuserpw> is the password for this user ID
2. Import the data in the tables to the WebSphere Portal Version 5.0.x database. a. If the WebSphere Portal Version 5.0.x database server is not the same machine as the
WebSphere Portal Version 4.x database server, copy the exported vault.data.wp4.ixf and vault.res.ixf files to the WebSphere Portal Version 5.0.x database server machine.
b. On the WebSphere Portal Version 5.0.x database server, start the DB2 Command Line Processor (CLP) (Windows) or DB2 shell (Unix).
c. Enter the following commands:
db2 connect to <wps5-db> user <dbuser> using <dbuserpw>db2 import from C:/temp/vault.res.wp4.ixf of ixf modified by indexschema=<dbuser> messages C:/temp/vault/res.wp5.msgtxt insert into VAULT_RESOURCESdb2 import from C:/temp/vault.data.wp4.ixf of ixf modified by indexschema=<dbuser> messages C:/temp/vault/data.wp5.msgtxt insert into VAULT_DATA
where <dbuser> is the database administrator user ID and <dbuserpw> is the password for this user IDNote:Under certain conditions, the import into the VAULT_RESOURCES table might generate errors indicating that a row with the same resource name already exists. Disregard this error. The VAULT_RESOURCES table only defines Resource names for use in the credential vault. If the names already exist, there is no need to redefine them. Here is an example of this type of error:
SQL0803N One or more values in the INSERT statement, UPDATE statement, or foreign key update caused by a DELETE statement are not valid because the primary key, unique constraint or unique index identified by "1" constrains table "DB2ADMIN.VAULT_RESOURCES" from having duplicate rows for those columns. SQLSTATE=23505
d. If the WebSphere Portal Version 5.0.x system uses a database-only configuration for Member Manager, change the USER_DN values in the VAULT_DATA table using the following SQL scripts. See Member Manager for more information.
db2 update VAULT_DATA set USER_DN='uid=<wpsadmin>,o=default organization' where USER_DN='uid=<wpsadmin>,o=root organization'
db2 update VAULT_DATA set USER_DN=left(USER_DN,length(USER_DN)-length(',O=root organization')) where USER_DN='uid=<wpsadmin>,o=default organization'
where <wpsadmin> is the portal administrator usere. Enter the following command: db2 disconnect wps5.
3. Make sure that the system.dn value in the vaultservice.properties file for WebSphere Portal Version 5.0.x is set to the same value that was used in the previous WebSphere Portal system. This dn is used to store system (shared) credentials. If this value is different, the vault will not return the vault data.
5: Deleting WebSphere Portal Version 4.x resource entries from Tivoli Access Manager
If you used Tivoli Access Manager with WebSphere Portal Version 4.x, you might need to clean up obsolete resource entries that are left in the Tivoli Access Manager object space. You must complete this step if you are using the same Tivoli Access Manager system that you used with WebSphere Portal Version 4.x. This step is not necessary if you are using different Tivoli Access Manager systems for WebSphere Portal Version 4.x and WebSphere Portal Version 5.0.x. Do not perform this step until you are finished using the older version of WebSphere Portal.
1. On the WebSphere Portal Version 4.x system, open the externalaccesscontrolservice.properties file and determine the value for <pd_root>.
2. On the Tivoli Access Manager system, go to the pdadmin command line and enter the following command to delete the object space entries corresponding to WebSphere Portal Version 4.x resources: pdadmin> delete objectspace <pd_root>*
3. On the Tivoli Access Manager system, go to the pdadmin command line and enter the following command to delete the ACLs that were associated with WebSphere Portal Version 4.x resources: pdadmin> acl delete <acl_name>.
Related information
● The migration process● Migration properties● Migration tasks● Troubleshooting
Migrating derived pages
In WebSphere Portal Version 4.x, derived pages did not have locale-specific titles. The derived pages were displayed with the title of the base page followed by the administrative names in parentheses. For example: Base Page Title (administrative name)
The WebSphere Portal Version 4 administrative page names have no direct equivalent in WebSphere Portal Version 5.0.x. In WebSphere Portal Version 5.0.x, the unique name that is created for the page during migration has the old administrative name appended to it. The administrative name is part of the unique name.
In WebSphere Portal Version 5.0.x, the ability to change titles and descriptions of derived pages is enabled by default. Since derived pages did not have locale-specific titles in WebSphere Portal Version 4.x, derived pages will not have locale-specific titles after migrating to Version 5.0.x. In order to distinguish the derived pages from base pages, WebSphere Portal Version 5.0.x displays the migrated derived pages with titles similar to the following names:
● 6_0_7F● 6_0_7G● 6_0_7H
To migrate derived pages
After migration perform the following steps to modify the titles for your derived pages.
1. From the Manage Pages portlet, locate the page that you want to rename.2. Open the properties for that page. 3. Modify the name of the page to an appropriate unique name.
After these titles are modified, the derived pages will be displayed correctly.
Related information● The migration process● Migration properties● Migration tasks● Troubleshooting
Migration Properties
This topic describes the properties that are used by migration tasks during WebSphere Portal migration. Note that the specific properties that are required for migration can vary depending on how you are deploying WebSphere Portal and its related components. Refer to the installation instructions for each component for information on which properties you should set.
Three properties files (mig_core.properties, mig_wpcp.propeties, and mig_wmm.properties) are located in the <wp5_root>/migration directory. The following additional files are also required for migration.
1. <wp4x_root>/wps.properties. This file supplies version information about your WebSphere Portal Version 4.x environment to various migration tasks (see the wpInstallLocation4x property).
2. <wp5_root>/config/wpconfig.properties. This file supplies configuration information about your WebSphere Portal Version 5.0.x environment to various migration tasks. If you are running migration tasks from a directory other than <wp5_root>/migration, copy this file to the migration directory manually.
Note the following information:
● <wp4x_root> and <wp5_root> specify the installation root directory of WebSphere Portal Version 4.x and WebSphere Portal Version 5.0.x respectively.
● Two additional files are provided for more detailed WebSphere Portal content publishing migration: mig_wpcp_author.properties and mig_wpcp_feedback.properties. These files need to be set up only if you plan on migrating WebSphere Portal content publishing authoring and feedback.
Notes on setting values in properties files:
● Do not enclose values in quotation marks.● When specifying path information, always use forward slashes (/) to separate elements in the path,
instead of back slashes (\), even if you are installing in a Windows environment. ● Long file names can be used in Windows environments.
Notes on loading sequence of properties by migration tasks:
● After a property is set during task startup, its value cannot be overridden. The precedence order for setting properties is as follows, from highest precedence to lowest precedence:
❍ Properties set on the command line when the migration task is launched (using the -D<property>=<value> option, where <property> indicates a specific property that will be used by the task, and <value> indicates the value of a specific property that will be used by the task)
❍ If available, properties set in the file pointed to by the parentProperties parameter❍ Properties set in the mig_core.properties and mig_wmm.properties files❍ If available, properties set in the file pointed to by the childProperties parameter❍ Properties set in the mig_driver.xml file
Note: Migration requires that you edit a properties file with values that are unique to your environment. For
detailed information on working with properties files, see Configuration properties reference.
Core migration propertiesProperty Value
WpsHostName4xDescription: The fully qualified host name of WebSphere Portal Version 4.x. This property is required.
Value type: Host name
Example: yourhost.domain.com
Default Value: None
WpsPort4xDescription: The port number that is assigned to WebSphere Portal Version 4.x. This property is required.
Value type: Numeric text string
Example: 80
Default Value: None
WpsContextRoot4xDescription: The base URI for WebSphere Portal Version 4.x. This property is required.
Value type: Path name
Example: wps is the context root of <hostname>/wps/portal
Default Value: None
WpsDefaultHome4xDescription: The default home for WebSphere Portal Version 4.x. This property is required.
Value type: Path name
Example: portal is the default home of <hostname>/wps/portal
Default Value: None
omitExternalAccessControlDescription: Determines whether the migration process will automatically externalize access control that was externalized in WebSphere Portal Version 4.x. If this value is true, the migration process does not externalize access control for resources that were externalized in WebSphere Portal Version 4.x.
Value type: true,false
Default Value: false
PortalAdminId4xDescription: The WebSphere Portal Version 4.x portal administrator user ID. This property is required.
Value type: Alphanumeric text string
Example: wpsadmin
Default Value: None
PortalAdminPwd4xDescription: The WebSphere Portal Version 4.x portal administrator password for the administrator user ID. This property is required.
Value type: Alphanumeric text string
Default Value: None
ScriptPathDescription: The name of the path, including subdirectories, to search for the WebSphere Portal Version 4.x XML configuration interface file to be converted. Supply a value for this property only if you are planning to use the task migrate-xmlaccess-scripts.
Value type: Path name
Default Value: None
ScriptSrcDescription: The file name of the WebSphere Portal Version 4.x XML configuration interface file to be migrated. Supply a value for this property only if you are planning to use the task migrate-xmlaccess-scripts.
Value type: XML file name
Default Value: None
ScriptDestDescription: The file name of the migrated WebSphere Portal Version 5.0.x XML configuration interface file. Supply a value for this property only if you are planning to use the task migrate-xmlaccess-scripts.
Value type: XML file name
Default Value: None
useEditorDescription: Specifies which role should be used for users who possess EDIT and DELEGATE permissions. True signifies that the Editor role should be used; false signifies that the Privileged User role should be used. If the Editor role is selected for users having EDIT and DELEGATE permissions, these users will not be able to see the implicitly derived pages (user customizations) after migration.
Value type: true, false
Default Value: true
convertAccessControlDescription: This property determines whether access control form Pages, Places, Portlet Application, and Portlets WP4 will be migrated. False indicates that the access control will not be migrated.
Value type: true, false
Default Value: true
omitExternalAccessControlDescription: This parameter defines whether the access control information should be migrated if externalized access control is specified for resources. When the value is set to false, the access control information is migrated; when the value is set to true, the access control information is omitted.
Value type: true, false
Default Value: false
wpsInstallLocation4xDescription: The location of WebSphere Portal Version 4.x installation root directory, if accessible. If this value is left blank, a wps.properties file from the WebSphere Portal 4.x system to be migrated should be copied to the migration directory.
Value type: Path name
Example: /usr/WebSphere/PortalServer
Default Value: None
includeClientsDescription: Comma-separated names of clients to be included in the task processing.
Value type: Comma-separated list of file names
Default Value: None
excludeClientsDescription: Comma-separated names of clients to be excluded from the task processing.
Value type: Comma-separated list of file names
Default Value: None
filenameClientsDescription: File name to use during export from WebSphere Portal Version 4.x and import to WebSphere Portal Version 5.0.x.
Value type: XML file name
Default Value: clientsout.xml
includeThemesDescription: Comma-separated names of themes to be included in the task processing.
Value type: Comma-separated list of file names
Default Value: None
excludeThemesDescription: Comma-separated names of themes to be excluded from the task processing.
Value type: Comma-separated list of file names
Default Value: None
pathUpgradedThemesSkinsDescription: The file system path holding upgraded themes and skins to be copied to WebSphere Portal Version 5 system. If provided, the migrate-themes-skins-configs and import-themes-skins-configs tasks will copy necessary files from subdirectory themes and skins under the path pointed to by the pathUpgradedThemesSkins parameter.
Value type: System path name
Example: /usr/wp5_devThis example assumes that your upgraded themes and skins are in /usr/wp5_dev/themes and /usr/wp5_dev/skins
Default Value: None
filenameThemesDescription: The file name to use during export from WebSphere Portal Version 4.x and import to WebSphere Portal Version 5.0.x.
Value type: XML file name
Default Value: themesout.xml
includeAppsDescription: Comma-separated names of portlet applications to be included in the task processing.
Value type: Comma-separated list of file names
Default Value: None
excludeAppsDescription: Comma-separated names of portlet applications to be excluded from the task processing.
Value type: Comma-separated list of file names
Default Value: None
filenameAppsDescription: The file name to use during export from WebSphere Portal Version 4.x and import to WebSphere Portal Version 5.0.x.
Value type: XML file name
Default Value: appsout.xml
appsPathDescription: The path where portlet application WAR files reside. This path will be used to update existing location of WAR files in WebSphere Portal Version 4.x export so that the portlet applications are installed during the import step and should be accessible from the WebSphere Portal Version 5.0.x you are migrating.
Value type: Path name
Example: C:/WebSphere/PortalServer/install/
Default Value: //localhost/$server_root$/installableAppsThis translates to <wp_root>/installableApps
includePagesDescription: Comma-separated names of pages to be included in the task processing.
Value type: Comma-separated list of file names
Default Value: None
excludePagesDescription: Comma-separated names of pages to be excluded from the task processing.
Value type: Comma-separated list of file names
Default Value: None
filenamePagesDescription: The file name to use during export from WebSphere Portal Version 4.x and import to WebSphere Portal Version 5.0.x.
Value type: XML file name
Default Value: pagesout.xml
filenameUserPagesDescription: The file name to use during export from WebSphere Portal Version 4.x and import to WebSphere Portal 5.0.x.
Value type: XML file name
Default Value: userpagesout.xml
includePlacesDescription: Comma-separated names of places to be included in the task processing.
Value type: Comma-separated list of file names
Default Value: None
excludePlacesDescription: Comma-separated names of places to be excluded in the task processing.
Value type: Comma-separated list of file names
Default Value: None
deployPagesDescription: This property determines if all pages that re used by places would also be migrated or exported. Set to true to export all pages.
Value type: true, false
Default Value: true
deployAppsDescription: This property determines if all portlet applications that are used by pages would also be migrated or exported. Set to true to export all portlet applications.
Value type: true, false
Default Value: true
configThemesSkinsDescription: This property determines if configuration information for all themes and skins used on the exported pages would also be migrated/exported. Set to true to migrate/export all themes and skins configuration information.
Value type: true, false
Default Value: true
filenamePlacesDescription: The file name to use during export from WebSphere Portal Version 4.x and import to WebSphere Portal Version 5.0.x.
Value type: XML file name
Default Value: placesout.xml
filenamePortletsConfigsDescription: The file name to use during export from WebSphere Portal Version 4.x and import to WebSphere Portal Version 5.0.x.
Value type: XML file name
Default Value: portletsconfigsout.xml
filenameNotesPortletsDescription: The file name to use during export from WebSphere Portal Version 4.x and import to WebSphere Portal Version 5.0.x.
Value type: XML file name
Default Value: notesportletsout.xml
filenameCredentialSlotsSegmentsDescription: The file name to use when exporting credential vault slots from WebSphere Portal Version 4.x and importing them to WebSphere Portal Version 5.0.x.
Value type: XML file name
Default Value: credentialslotssegmentsout.xml
To run the run-time migration, the following required properties need to be filled out in mig_wpcp.properties:
WebSphere Portal content publishing run-time propertiesProperty Value
WpcpRuntimeSourceUrlDescription: The URL of the WebSphere Portal content publishing Version 4.x run-time database.
Value type: Database URL
Example: jdbc:db2://<4.2_SERVERNAME>:<PORT>/<DATABASENAME> for a DB2 database or jdbc:oracle:thin:@<4.2_SERVERNAME>:<PORT>:<DATABASENAME> for an Oracle database
where:
● <4.2_SERVERNAME> is the name of your WebSphere Portal Version 4.x server.
● <PORT> is the port that the net driver uses to connect to the database.
● <DATABASENAME> is the name of your database.
Note: DB2 must be set up for remote communication if you plan on
using the "net" driver.
Default Value: None
WpcpRuntimeSourceUserDescription: The user ID of the WebSphere Portal content publishing Version 4.x run-time database.
Value type: Alphanumeric text string; user name to log in to the database.
Default Value: None
WpcpRuntimeSourcePasswordDescription: The password for the WebSphere Portal content publishing Version 4.x run-time database user ID.
Value type: Alphanumeric text string
Default Value: None
WpcpRuntimeSourceJdbcDriverDescription: The JDBC driver that is used to connect to the database.
Value type: Class name
Example: oracle.jdbc.pool.OracleConnectionPoolDataSource is an example of an Oracle JDBC driver. COM.ibm.db2.jdbc.net.DB2Driver is an example of a DB2 JDBC driver.
Default Value: None
WpcpRuntimeTargetUrlDescription: The URL of the WebSphere Portal content publishing Version 5.0.x run-time database.
Value type: URL
Example: jdbc:db2://<5.0_SERVERNAME>:<PORT>/<DATABASENAME> for a DB2 database or jdbc:oracle:thin:@<5.0_SERVERNAME>:<PORT>: <DATABASENAME> for an Oracle database
where:
● <5.0_SERVERNAME> is the name of your WebSphere Portal Version 5.0.x server
● <PORT> is the database port number● <DATABASENAME> is the name of your database.
Note: DB2 must be set up for remote communication if you plan on using the "net" driver.
Default Value: None
WpcpRuntimeTargetUserDescription: The user ID of the WebSphere Portal content publishing 5.0.x run-time database.
Value type: Alphanumeric text string
Default Value: None
WpcpRuntimeTargetPasswordDescription: The password for the WebSphere Portal content publishing 5.0.x database user ID.
Value type: Alphanumeric text string
Default Value: None
WpcpRuntimeTargetJdbcDriverDescription: The JDBC driver that is used to connect to the database.
Value type: Class name
Example: oracle.jdbc.pool.OracleConnectionPoolDataSource is an example of an Oracle JDBC driver. com.ibm.db2.jcc.DB2Driver is an example of a Type 4 DB2 JDBC driver.
Default Value: None
WpcpMigrateRuntimeDescription: This property defines whether to migrate the run time.
Value type: true, false
Default Value: false
wpcpRuntimeDBTypeDescription: The database type that is used for the run-time database.
Value type: DB2, Oracle, DB2_390, SqlServer, Informix, or Sybase
Default Value: None
WpcpSilentModeDescription: This property defines whether messages are displayed.
Value type: true, false
Default Value: false
WpcpVerboseDescription: This property defines whether verbose messaging is used.
Value type: true, false
Default Value: false
wpcpWpsInstallLocation4xDescription: Installation location of WebSphere Portal Server version 4.x.
Value type: Directory name
Default Value: d:/test
To run the authoring migration, the following properties need to be defined in mig_wpcp_author.properties:
WebSphere Portal content publishing author propertiesProperty Value
WpcpAuthorSourceUrlDescription: The URL of the WebSphere Portal content publishing Version 4.2 database.
Value type: Database URL
Example: jdbc:db2://<SERVERNAME>: <PORT>/<DATABASENAME> for a DB2 database or jdbc:oracle:thin:@<SERVERNAME>:<PORT>:<DATABASENAME> for an Oracle database.
Default Value: None
WpcpAuthorSourceUserDescription: The user ID of the WebSphere Portal content publishing Version 4.2 authoring database.
Value type: Alphanumeric text string; user name to log in to the database
Default Value: None
WpcpAuthorSourcePasswordDescription: The password for the WebSphere Portal content publishing 4.2 Version authoring database user ID.
Value type: Alphanumeric text string; password to log in to the database
Default Value: None
wpcpAuthorSourceSchemaDescription: The schema that is used if the data is in a different schema than the user logging in. Set this value if the user who created the tables is different from the WebSphere Portal content publishing AuthorSourceUser.
Value type: Alphanumeric text string
Default Value: None
WpcpAuthorSourceJdbcDriverDescription: The JDBC driver that is used to connect to the database.
Value type: Class name
Example: oracle.jdbc.pool.OracleConnectionPoolDataSource is an example of an Oracle JDBC driver. COM.ibm.db2.jdbc.net.DB2Driver is an example of a DB2 JDBC driver
Default Value: None
WpcpAuthorTargetUrlDescription: The URL of the WebSphere Portal content publishing 5.0.x Authoring database.
Value type: URL
Example: jdbc:db2://<SERVERNAME>:<PORT><DATABASENAME> for a DB2 database or jdbc:oracle:thin:@<SERVERNAME>:<PORT>:<DATABASENAME> for an Oracle database
Default Value: None
WpcpAuthorTargetUserDescription: The user ID of the WebSphere Portal content publishing Version 5.0.x authoring database.
Value type: Alphanumeric text string
Default Value: None
WpcpAuthorTargetPasswordDescription: The password for the WebSphere Portal content publishing 5.0.x authoring database user ID.
Value type: Alphanumeric text string
Default Value: None
wpcpAuthorTargetSchemaDescription: The schema to use if the data is in a different schema than the user logging in.
Value type: Alphanumeric text string
Default Value: None
WpcpAuthorTargetJdbcDriverDescription: The JDBC driver that is used to connect to the database.
Value type: Class name
Example: oracle.jdbc.pool.OracleConnectionPoolDataSource is an example of an Oracle JDBC driver. com.ibm.db2.jcc.DB2Driver is an example of a Type 4 JDBC driver.
Default Value: None
WpcpMigrateAuthorDescription: This property defines whether to migrate the authoring environment.
Value type: true, false
Default Value: false
wpcpAuthorDbTypeDescription: The database type that is used for the authortime database.
Value type: DB2, Oracle, DB2_390
Default Value: None
WpcpAuthoringServerDescription: The WebSphere Portal content publishing 5.0.x Authoring Server URL.
Value type: URL
Example: http://<SERVERNAME>:<PORT>/wps/wcp
Default Value: http://localhost:9080/wps/wcp
WpcpAuthoringAdminUserIdDescription: The WebSphere Portal content publishing 5.0.x Authoring Server Administrative user ID.
Value type: text
Default Value: wpsadmin
WpcpAuthoringAdminPasswordDescription: The password for WebSphere Portal content publishing 5.0.x Authoring Server Administrative user ID.
Value type: text
Default Value: wpsadmin
WpcpSilentModeDescription: This property defines whether messages are displayed.
Value type: true, false
Default Value: false
WpcpVerboseDescription: This property defines whether verbose messaging is used.
Value type: true, false
Default Value: false
wpcpWpsInstallLocation4xDescription: Installation location of WebSphere Portal Server version 4.x.
Value type: Directory name
Default Value: d:/test
To run the feedback migration, all the following required properties must be defined in mig_wpcp_feedback.properties:
WebSphere Portal content publishing feedback propertiesProperty Value
WpcpFeedbackSourceUrlDescription: The URL of the WebSphere Portal content publishing Version 4.x feedback database.
Value type: URL
Example: jdbc:db2://<5.0_SERVERNAME>:<PORT>/ <DATABASENAME> for a DB2 database or jdbc:oracle:thin:@<SERVERNAME> :<PORT>:<DATABASENAME> for an Oracle database
Default Value: None
WpcpFeedbackSourceUserDescription: The user ID of the WebSphere Portal content publishing Version 4.x Feedback database.
Value type: Alphanumeric text string
Default Value: None
WpcpFeedbackSourcePasswordDescription: The password for the WebSphere Portal content publishing Version 4.x Feedback database user ID.
Value type: Alphanumeric text string
Default Value: None
WpcpFeedbackSourceJdbcDriverDescription: The JDBC driver to use to connect to the database.
Value type: Class name
Example: oracle.jdbc.pool.OracleConnectionPoolDataSource is an example of an Oracle JDBC driver. COM.ibm.db2.jdbc.net.DB2Driver is an example of a DB2 JDBC driver.
Default Value: None
WpcpFeedbackTargetUrlDescription: The URL of the WebSphere Portal content publishing Version 5.0.x Feedback database.
Value type: Database URL
Example: jdbc:db2://<SERVERNAME>:<PORT>/ <DATABASENAME> for a DB2 database or jdbc:oracle:thin:@ <SERVERNAME>:<PORT>:<DATABASENAME> for an Oracle database
Default Value: None
WpcpFeedbackTargetUserDescription: The user ID of the WebSphere Portal content publishing 5.0.x Feedback database.
Value type: Alphanumeric text string
Default Value: None
WpcpFeedbackTargetPasswordDescription: The password for the WebSphere Portal content publishing 5.0.x Feedback database user ID.
Value type: Alphanumeric text string
Default Value: None
WpcpFeedbackTargetJdbcDriverDescription: The JDBC driver to use to connect to the database.
Value type: Class name
Example: oracle.jdbc.pool.OracleConnectionPoolDataSource is an example of an Oracle JDBC driver. com.ibm.db2.jcc.DB2Driver is an example of a Type 4 JDBC driver.
Default Value: None
wpcpFeedbackDbTypeDescription: The database type used for the run-time database.
Value type: DB2, Oracle, DB2_390
Default Value: None
WpcpMigrateFeedbackDescription: This property defines whether to migrate feedback tables. This could take a very long time with the possibility of millions of rows.
Value type: true, false
Default Value: false
WpcpSilentModeDescription: This property defines whether messages are displayed.
Value type: true, false
Default Value: false
WpcpVerboseDescription: This property defines whether verbose messaging is used.
Value type: true, false
Default Value: false
wpcpWpsInstallLocation4xDescription: Installation location of WebSphere Portal Server version 4.x.
Value type: Directory name
Default Value: d:/test
Member Manager migration propertiesProperty Value
WmsDbNameDescription: The WebSphere Member Services database name.
Value type: Database name
Example: wms
Default Value: wmsdb
WmsDbUrlDescription: The WebSphere Member Services database JDBC URL.
Value type: Alphanumeric URL
Example: jdbc:db2:wms The following values can be specified:
● DB2: jdbc:db2:wms4● DB2/zOS: jdbc:db2:WMS4● Oracle: jdbc:oracle:thin:@linsuse2:1521:ora901● Informix: jdbc:informix-sqli://wps19:1526/wms4:informixserver=freeman
● SQL Server: jdbc:microsoft:sqlserver://wps19:1433;DatabaseName=wms4
Default Value: None
WmsDbUserDescription: The user ID of the WebSphere Member Services database user.
Value type: Alphanumeric text string
Example: db2inst1
Default Value: None
WmsDbPasswordDescription: The password for the WebSphere Member Services database user ID.
Value type: Alphanumeric text string
Example: db2inst1
Default Value: None
WmmConfigTypeDescription: The user registry type for Member Manager.
Value type: Numeric - 1, 2, 3 (DB=1, LDAP+LA=2, DB(Dev mode)=3)
Default Value: None
WmmUuidDescription: The repository unique identifier. This value can be found in the file wmm.xml as "UUID" in the <wp_root>/shared/app/wmm directory.
Value type: Alphanumeric text string
Default Value: None
DbAdminUserDescription: This property is required for Unix/Linux platforms only: Specifies the user with administrative privileges to the database server
Value type: Alphanumeric text string
Default Value: None
Db2HomeDescription: This property is required for DB2 Only: Root installation directory of DB2
Value type: Alphanumeric text string
Examples: c:/ibm/sqllib for Windows and /home/db2inst1/sqllib for UNIX
Default Value: None
WmmDbOwnerDescription: This property is required for SQL server only: The user that owns the Member Manager schema
Value type: Alphanumeric text string
Default Value: dbo
LdapHasUuidDescription: This property indicates whether or not the LDAP server has a unique user ID.
Value type: true, false
Default Value: None
LdapUuidNameDescription: The name of the attribute in the LDAP server storing the unique user ID. If you do not have an existing attribute in LDAP to store a unique user ID (LdapHasUuid must be set to false in this case), you must manually create it and link it to the LDAP auxiliary object. Also, after creating the auxiliary object class, assign the attribute unique user ID that was created above to the object class.
Value type: Alphanumeric text string
Example: Create an attribute called ibm-appUUID
Default Value: None
LdapAuxiliaryClassNameDescription: This property is required only if WmmConfigType=2 and LdapHasUuid=false. Creates an auxiliary object class in the LDAP server and specifies the name of the auxiliary object class.
Value type: Alphanumeric text string
Example: ibm-appUUIDAux
Default Value: None
wps4DbLibraryDescription: This property is required only if WmmConfigType=3: The directory and name of the zip file containing the db.driver class.
Value type: Alphanumeric database URL
Example: The following values can be specified:
● DB2: <SQLLIB>/java12/db2java.zip● DB2/zOS: <SQLLIB>/java12/db2java.zip● Oracle: <Oracle>/jdbc/lib/classes12.zip● Informix: <InformixJDBC>/lib/ifxjdbc.jar● SQL Server:<SQLServerJDBC>/lib/mssqlserver.jar;<SQLServerJDBC>/lib/msbase.jar; <SQLServerJDBC>/lib/msutil.jar
Default Value: None
wps4DbDriverDescription: This property is required only if WmmConfigType=3: The WebSphere Portal JDBC driver class name used to access the database over JDBC (also known as the JDBC provider).
Value type: Alphanumeric database name
Example: COM.ibm.db2.jdbc.net.DB2Driver The following values can be specified:
● DB2: COM.ibm.db2.jdbc.net.DB2Driver● DB2/zOS: COM.ibm.db2.jdbc.app.DB2Driver● Oracle: oracle.jdbc.driver.OracleDriver● Informix: com.informix.jdbc.IfxDriver● SQL Server:com.microsoft.jdbc.sqlserver.SQLServerDriver
Default Value: None
wps4DbUrlDescription: This property is required only if WmmConfigType=3: The WebSphere Portal Version 4.x database JDBC URL.
Value type: Alphanumeric database URL
Example: jdbc:db2:wps4 The following values can be specified:
● DB2: jdbc:db2:WPS4● DB2/zOS: jdbc:db2:WPS4● Oracle: jdbc:oracle:thin:@wps19:1521:wps4● Informix: jdbc:informix-sqli://wps19:1526/wps4:informixserver=freeman
● SQL Server:jdbc:microsoft:sqlserver://wps19:1433;DatabaseName=wps4
Default Value: None
wps4DbUserDescription: This property is required only if WmmConfigType=3: The WebSphere Portal 4.x database user.
Value type: Alphanumeric text string
Default Value: None
wps4DbPasswordDescription: Required only if WmmConfigType=3: The WebSphere Portal Version 4.x database password.
Value type: Alphanumeric text string
Default Value: None
wmmTraceEnabledDescription: This optional property determines whether tracing is enabled.
Value type: true, false
Default Value: false
wmmReportSqlErrorDescription: This property determines whether SQL error tracing is enabled.
Value type: true, false
Default Value: false
Related information
● Migration tasks● Troubleshooting
Migration Tasks
This topic explains the migration tasks that are used as part of the WebSphere Portal migration process. Note that the specific tasks that are required for migration can vary. Refer to the migration instructions in the Running the migration tasks section for information on which migration tasks you should use.
Note the following information:
● The migration tasks assume that WebSphere Portal Version 5.0.x is successfully installed and configured, and that all required parameters are provided in the mig_core.properties, mig_wmm.properties, mig_wpcp.properties, mig_wpcp_author.properties, and mig_wpcp_feedback.properties files.
● Any parameters that you specify when invoking the tasks from the command line will supersede the parameter values in the properties files.
● The -D flag needs to be placed on the task parameters if you enter them on the command line. For example, ./WPmigrate.sh export-apps with parameters added would be typed like this on the command line: ./WPmigrate.sh export-apps -DincludeApps=<appnames> -DexcludeApps=<appnames>
export-all
Description: Exports places, pages, portlet applications, configuration for themes and skins, user customizations, portlet configuration data, and Notes and iNotes Portlet settings to a specified file.
Usage: Invoked as part of the WPmigrate script file. For example: Unix/Linux: ./WPmigrate.sh export-all Windows: WPmigrate.bat export-all
export-apps
Description: Exports custom portlet applications and portlet configuration to a specified file.
Usage: Invoked as part of the WPmigrate script file. For example: Unix/Linux: ./WPmigrate.sh export-apps Windows: WPmigrate.bat export-apps
Inputs: This task takes the following inputs:
Input Description
includeAppsTakes a comma-separated list of portlet application global IDs to be included in the export. If the parameter is left blank, all portlet applications will be included in the export.
excludeAppsTakes a comma-separated list of portlet application global IDs to be excluded from the export. If the parameter is left blank, no portlet applications will be excluded from the export.
filenameApps Specifies the file to which the data is exported. The default file name is appsout.xml.
appsPath
Path to where WAR files for portlet applications reside. Points to a URL where the WAR files could be found for custom portlet applications (for example: file:///usr/WebSphere/PortalServer/install). The default file path is file://localhost/$server_root$/installableApps.
Note: Portlet applications with the following global IDs will not be exported by default unless the includeApps parameter is supplied to specifically include them. Notice that some entries in the following list include wildcard characters. So, for example, com.ibm.wps.* refers to any portlet application that has a global ID beginning with com.ibm.wps.
● com.ibm.hrl.portlets.Sindex● com.ibm.wps.*● com.ibm.portlets.exchange*● com.screamingmedia.openportlet.wps*● Document_Viewer_Portlet● Moreover News● An OCS Viewer Application● SQL Query Portlet● FT Portlet - Demonstration
export-clients
Description: Exports modified default portal clients or custom clients to a specified file.
Usage: Invoked as part of the WPmigrate script file. For example: Unix/Linux: ./WPmigrate.sh export-clients Windows: WPmigrate.bat export-clients
Inputs: This task takes the following inputs:
Input Description
includeClientsTakes a comma-separated list of case-sensitive portal client names to be included in the export. If left blank, all portal clients will be exported.
excludeClientsTakes a comma-separated list of case-sensitive portal client names to be excluded from the export. If left blank, no portal clients will be excluded from the export.
filenameClients Specifies the file to which the portal clients are exported. The default file name is clientsout.xml.
export-notes-portlets
Description: Exports settings from multiple Notes and iNotes portlets from WebSphere Portal Version 4.x to a specified file.
Usage: Invoked as part of the WPmigrate script file. For example: Unix/Linux: ./WPmigrate.sh export-notes-portlets Windows: WPmigrate.bat export-notes-portlets
Inputs: This task takes the following inputs:
Input Description
filenameNotesPortlets Specifies the file to which the Notes and iNotes portlets settings are exported. The default file name is notesportletsout.xml.
export-pages
Description: Exports pages that are defined in WebSphere Portal Version 4.x to a specified file name.
Usage: Invoked as part of the WPmigrate script file. For example: Unix/Linux: ./WPmigrate.sh export-pages Windows: WPmigrate.bat export-pages
Inputs: This task takes the following inputs:
Input Description
includePages Takes a comma-separated list of case-sensitive page names to be included in the export. If left blank, all pages will be exported.
excludePages Takes a comma-separated list of case-sensitive page names to be excluded from the export. If left blank, no pages will be excluded.
deployApps Takes true or false. If set to true, the portlet applications that are used on the pages will be exported along with the pages.
filenamePages Specifies the file to which pages will be exported. The default file name is pagesout.xml.
appsPath
Points to a URL where the WAR files could be found for custom portlet applications (for example: file:///usr/WebSphere/PortalServer/install). The default file path is file://localhost/$server_root$/installableApps.
configThemesSkins Takes true or false. If set to true, the configuration information for themes and skins used by the pages will also be exported.
Note: Pages with the following names will not be exported by default unless the includePages parameter is supplied to specifically include them.
● Users and Groups● Security● Portal Content● Portlets● Portal Settings● Manage Page Groups and Pages● Manage Places and Pages● Edit My Pages● Organize My Favorites● Edit Layout and Content
Set Permissions● Choose Skins● Install Portlets● Portlet Applications● Manage Portlets● Web Clipping● Manage Web Services● Web Services● Global Settings● Themes and Skins● Manage Clients● Manage Markups● Manage Search Index● Enable Tracing● Manage Users● Manage Groups● Access Control List● Credential Vault● Manage Content Organizer● Content Organizer
export-places
Description: Exports places that are defined in WebSphere Portal Version 4.x to a specified file.
Usage: Invoked as part of the WPmigrate script file. For example:
Unix/Linux: ./WPmigrate.sh export-places Windows: WPmigrate.bat export-places
Inputs: This task takes the following inputs:
Input Description
includePlaces Takes a comma-separated list of case-sensitive place names to be included in the export. If left blank, all places will be exported.
excludePlaces Takes a comma-separated list of case-sensitive place names to be excluded from the export. If left blank, no places will be excluded.
deployPagesTakes either true or false, and set to true by default. If set to true, pages associated with specified places will automatically be migrated.
deployAppsTakes either true or false, and set to true by default. If set to true, portlet applications associated with the specified places will automatically be migrated.
filenamePlaces Specifies the file to which places will be exported. The default file name is placesout.xml.
appsPath
Points to a URL where the WAR files could be found for custom portlet applications (for example: file:///usr/WebSphere/PortalServer/install). The default file path is file://localhost/$server_root$/installableApps.
configThemesSkins Takes true or false. If set to true, the configuration information for themes and skins used by the places will also be exported.
Note: Places with the following names will not be exported by default unless the includePlaces parameter is supplied to specifically include them.
● Work With Pages● Administration● Portal Administration
export-portlets-configs
Description: Exports all portlet configuration data from WebSphere Portal Version 4.x to a specified file.
Usage: Invoked as part of the WPmigrate script file. For example: Unix/Linux: ./WPmigrate.sh export-portlets-configs Windows: WPmigrate.bat export-portlets-configs
Inputs: This task takes the following inputs:
Input Description
includeAppsTakes a comma-separated list of global IDs for portlet applications to be included in the export. If left blank, all portlet applications will be included.
excludeAppsTakes a comma-separated list of global IDs for portlet applications to be excluded from the export. If left blank, no portlet applications will be excluded.
filenamePortletsConfigSpecifies the file name to which portlet configuration data will be exported. The default file name is portletsconfigsout.xml
export-themes-skins-configs
Description: Exports themes and skins to a specified file name. Theme configuration references skins. This task will automatically export configuration of skins that are referenced by the themes.
Usage: Invoked as part of the WPmigrate script file. For example: Unix: ./WPmigrate.sh export-themes-skins-configs Windows: WPmigrate.bat export-themes-skins-configs
Inputs: This task takes the following inputs:
Input Description
includeThemesTakes a comma-separated list of theme and skin names to be included in the export. If left blank, all themes and skins will be included.
excludeThemesTakes a comma-separated list of theme and skin names to be excluded from the export. If left blank, no themes and skins will be excluded.
filenameThemes Specifies a file name to which the themes and skins will be exported. The default file name is themesout.xml.
Note: Themes with the following names will not be migrated by default unless the includeThemes parameter is supplied to specifically include them.
● Admin● AdminLeftNavigation● Corporate● Engineering● Finance● Science● WebSphere● Home
export-user-customizations
Description: Exports all user customizations from WebSphere Portal Version 4.x to a specified file. User customizations are artifacts that are attributed to a user that has EDIT but not MANAGE permissions on a page. They are created when such a user changes the layout of a page or edits portlet settings.
Usage: Invoked as part of the WPmigrate script file. For example: Unix/Linux: ./WPmigrate.sh export-user-customizations Windows: WPmigrate.bat export-user-customizations
Inputs: This task takes the following inputs:
Input Description
includePages Takes a comma-separated list of case-sensitive page names to be included in the export. If left blank, all pages will be exported.
excludePages Takes a comma-separated list of case-sensitive page names to be excluded from the export. If left blank, no pages will be excluded.
filenameUserPages Specifies the file to which pages will be exported. The default file name is userpagesout.xml.
Assumptions/Prerequisites:
Error Conditions:
Task dependencies: None
Tasks invoked:
export-user-groups-ac
Description: Exports all user customizations from WebSphere Portal Version 4.x to a specified file.
Usage: Invoked as part of the WPmigrate script file. For example: Unix/Linux: ./WPmigrate.sh export-user-groups-ac Windows: WPmigrate.bat export-user-groups-ac
Inputs: This task takes the following inputs:
Input Description
filenameUserGroupsAcOut Specifies the file to which the user groups information will be exported. The default file name is usergroupsacout.xml.
import-all
Description: Imports places, pages, portlet applications, configuration for themes and skins, user customizations, portlet configuration data, and Notes and iNotes Portlet settings from a specified file.
Usage: Invoked as part of the WPmigrate script file. For example: Unix/Linux: ./WPmigrate.sh import-all Windows: WPmigrate.bat import-all
Inputs: This task takes the following inputs:
Input Description
skipWpcpMigration
Takes a true or false value. Specifies whether the migrate-wpcp task will be run as part of the import-all task. If set to true, the migrate-wpcp task will be skipped. Set this value to true if you do not use WebSphere Portal content publishing.
skipWmmMigrationTakes a true or false value. Specifies whether the migrate-wmm task will be run as part of the import-all task. If set to true, the migrate-wmm task will be skipped.
import-apps
Description: Imports portlet applications from a specified file.
Usage: Invoked as part of the WPmigrate script file. For example: Unix/Linux: ./WPmigrate.sh import-apps Windows: WPmigrate.bat import-apps
Inputs: This task takes the following inputs:
Input Description
filenameApps Specifies the file from which to import the portlet applications. The default file name is appsout.xml.
import-clients
Description: Imports clients from a specified file.
Usage: Invoked as part of the WPmigrate script file. For example: Unix/Linux: ./WPmigrate.sh import-clients Windows: WPmigrate.bat import-clients
Inputs: This task takes the following inputs:
Input Description
filenameClients Specifies the file from which to import the portal client data. The default file name is clientsout.xml.
import-notes-portlet
Description: Imports settings from multiple Notes and iNotes portlets from a specified file.
Usage: Invoked as part of the WPmigrate script file. For example: Unix/Linux: ./WPmigrate.sh import-notes-portlet Windows: WPmigrate.bat import-notes-portlet
Inputs: This task takes the following inputs:
Input Description
filenameNotesPortlets Specifies the file from which to import the notes portlet data. The default file name is notesportletsout.xml.
import-pages
Description: Imports pages from a specified file.
Usage: Invoked as part of the WPmigrate script file. For example: Unix/Linux: ./WPmigrate.sh import-pages Windows: WPmigrate.bat import-pages
Inputs: This task takes the following inputs:
Input Description
filenamePages Specifies the file from which to import the page data. The default file name is pagesout.xml.
import-places
Description: Imports places from a specified file.
Usage: Invoked as part of the WPmigrate script file. For example: Unix/Linux: ./WPmigrate.sh import-places Windows: WPmigrate.bat import-places
Inputs: This task takes the following inputs:
Input Description
filenamePlaces Specifies the file from which to import the place data. The default file name is placesout.xml
import-portlets-configs
Description: Imports all portlet configuration data from a specified file.
Usage: Invoked as part of the WPmigrate script file. For example: Unix/Linux: ./WPmigrate.sh import-portlets-configs Windows: WPmigrate.bat import-portlets-configs
Inputs: This task takes the following inputs:
Input Description
filenamePortletsConfigs Specifies the file from which to import the portlet configuration data. The default file name is portletsconfigsout.xml.
import-themes-skins-configs
Description: Imports themes and skins from a specified file name.
Usage: Invoked as part of the WPmigrate script file. For example: Unix: ./WPmigrate.sh export-themes-skins-configs Windows: WPmigrate.bat export-themes-skins-configs
Inputs: This task takes the following inputs:
Input Description
filenameThemes Specifies the file from which themes and skins will be imported. The default file name is themesout.xml.
import-user-customizations
Description: Imports all user customizations from a specified file.
Usage: Invoked as part of the WPmigrate script file. For example: Unix/Linux: ./WPmigrate.sh import-user-customizations
Windows: WPmigrate.bat import-user-customizations
Inputs: This task takes the following inputs:
Input Description
filenameUserPages Specifies the file from which user customization data will be imported. The default file name is userpagesout.xml.
import-user-groups-ac
Description: Imports all user customizations from a specified file
Usage: Invoked as part of the WPmigrate script file. For example: Unix/Linux: ./WPmigrate.sh import-user-groups-ac Windows: WPmigrate.bat import-user-groups-ac
Inputs: This task takes the following inputs:
Input Description
filenameUserGroups Specifies the file from which user customization data will be imported. The default file name is userpagesout.xml.
migrate-all
Description: Runs all the migration tasks one after the other with no breaks.
Usage: Invoked as part of the WPmigrate script file. For example: Unix/Linux: ./WPmigrate.sh migrate-all Windows: WPmigrate.bat migrate-all
Inputs: This task takes the following inputs:
Input Description
skipWmmMigrationTakes a true or false value. Specifies whether the migrate-wmm task will be run as part of the migrate-all task. If set to true, the migrate-wmm task will be skipped.
migrate-apps
Description: Deploys upgraded portlet applications to WebSphere Portal Version 5.0.x.
Usage: Invoked as part of the WPmigrate script file. For example: Unix/Linux: ./WPmigrate.sh migrate-apps Windows: WPmigrate.bat migrate-apps
Inputs: This task takes the following inputs:
Input Description
includeAppsTakes a comma-separated list of global IDs for portlet applications to include in migration. If left blank, all portlet applications will be included.
excludeAppsTakes a comma-separated list of global IDs for portlet applications to exclude from migration. If left blank, no portlet applications will be excluded.
appsPath
Points to a URL where the WAR files could be found for custom portlet applications (for example: file:///usr/WebSphere/PortalServer/install). The default file path is file://localhost/$server_root$/installableApps.
Note: Portlet applications with the following global IDs will not be exported by default unless the includeApps parameter is supplied to specifically include them. Notice that some entries in the following list include wildcard characters. So, for example, com.ibm.wps.* refers to any portlet application that has a global ID beginning with com.ibm.wps.
● com.ibm.hrl.portlets.Sindex● com.ibm.wps.*● com.ibm.portlets.exchange*● com.screamingmedia.openportlet.wps*● Document_Viewer_Portlet● Moreover News● An OCS Viewer Application● SQL Query Portlet● FT Portlet - Demonstration
migrate-clients
Description:
Migrates default portal clients to WebSphere Portal Version 5.0.x. When the includeClients parameter is specified, only the clients that are listed after that parameter are moved to WebSphere Portal Version 5.0.x. When the excludeClients parameter is specified, configuration information for the list of clients after the parameter will not be moved to WebSphere Portal Version 5.0.x. A wildcard character (*) can also be used within each name. For example, the following command will migrate configuration information for all clients from WebSphere Portal Version 4.x starting with the letters "Inter" and "Moz" except for clients ending with the word "test." WPmigrate.sh migrate-clients -DincludeClients=Inter*,Moz* -DexcludeClients=*test
Usage: Invoked as part of the WPmigrate script file. For example: Unix/Linux: ./WPmigrate.sh migrate-clients Windows: WPmigrate.bat migrate-clients
Inputs: This task takes the following inputs:
Input Description
includeClientsTakes a comma-separated list of case-sensitive portal client names to include in migration. If left blank, all portal clients will be included.
excludeClientsTakes a comma-separated list of case-sensitive portal client names to excluded from migration. If left blank, no portal clients will be excluded.
migrate-notes-portlets
Description: Migrates settings from multiple Notes and iNotes portlets from WebSphere Portal Version 4.x to a single Notes and a single iNotes portlet in WebSphere Portal Version 5.0.x.
Usage: Invoked as part of the WPmigrate script file. For example: Unix/Linux: ./WPmigrate.sh migrate-notes-portlets Windows: WPmigrate.bat migrate-notes-portlets
Inputs: None
migrate-pages
Description: Migrates pages to WebSphere Portal Version 5.0.x. This step only migrates pages that are defined as "explicit"(that is, pages that are not created implicitly by WebSphere Portal due to user customization). The user customizations are separately migrated using the migrate-user-customizations task.
Usage: Invoked as part of the WPmigrate script file. For example: Unix/Linux: ./WPmigrate.sh migrate-pages Windows: WPmigrate.bat migrate-pages
Inputs: This task takes the following inputs:
Input Description
includePages Takes a comma-separated list of case-sensitive page names to be included in migration. If left blank, all pages will be included.
excludePages Takes a comma-separated list of case-sensitive page names to be excluded from migration. If left blank, no pages will be excluded.
appsPath
Points to a URL where the WAR files could be found for custom portlet applications. If deployApps is set to true, appsPath defaults to file://localhost/<wp_root>/installableApps, which will try and look for portlet WAR files under <wp5_root>/installableApps. The default file path is file://localhost/$server_root$/installableApps.
configThemesSkins Takes true or false. If set to true, the configuration information for themes and skins used by the pages will also be migrated.
Note the following information:
● The migrate-pages task does not migrate theme references that you might have specified on the places containing the pages. You must migrate the places separately using the migrate-places task in order access the theme references. Using migrate-pages with all its available parameters is not recommended. However, it is useful in cases when you have already migrated your places using the migrate-places task and a new page is added to WebSphere Portal Version 4.x. In this situation, make sure that you delete the <wp4_root>/migration/work/navigationout.xml file (if present) before running the migrate-pages task to migrate the newly added page. This situation of a new page being added to WebSphere Portal Version 4.x could occur when you are testing migration on your development environments. When migrating your production environments, it is recommended that you freeze the changes to WebSphere Portal Version 4.x until the migration is complete. You might then use one of the suitable scenarios described in the Running the migration tasks section. You should not use the optional tasks to migrate your production environments unless it is required.
● Pages with the following names will not be migrated by default unless the includePages parameter is supplied to specifically include them.
❍ Users and Groups❍ Security❍ Portal Content❍ Portlets❍ Portal Settings❍ Manage Page Groups and Pages❍ Manage Places and Pages❍ Edit My Pages❍ Organize My Favorites❍ Edit Layout and Content❍ Set Permissions❍ Choose Skins❍ Install Portlets❍ Portlet Applications❍ Manage Portlets❍ Web Clipping❍ Manage Web Services❍ Web Services❍ Global Settings
❍ Themes and Skins❍ Manage Clients❍ Manage Markups❍ Manage Search Index❍ Enable Tracing❍ Manage Users❍ Manage Groups❍ Access Control List❍ Credential Vault❍ Manage Content Organizer❍ Content Organizer
migrate-places
Description: Migrates places to WebSphere Portal Version 5.0.x.
Usage: Invoked as part of the WPmigrate script file. For example: Unix/Linux: ./WPmigrate.sh migrate-places Windows: WPmigrate.bat migrate-places
Inputs: This task takes the following inputs:
Input Description
includePlaces Takes a comma-separated list of case-sensitive place names to be included in migration. If left blank, all places will be included.
excludePlacesTakes a comma-separated list of case-sensitive place names to be excluded from migration. If left blank, no place will be excluded from migration.
deployPages Takes true or false, and defaults to true. Allows the task to automatically migrate pages that are associated with the places.
deployApps Takes true or false, and defaults to true. Allows the task to automatically migrate portlets that are associated with the places.
appsPath
Points to a URL where the WAR files can be found for the portlet applications. AppsPath defaults to <wp5_root>/installableApps, which will allow the XML configuration interface to look for WAR files under that directory during portlet deployment. The default file path is file://localhost/$server_root$/installableApps.
configThemesSkinsTakes true or false, and defaults to true. Allows the task to automatically migrate themes and skins that are associated with the places.
Note: Places with the following names will not be migrated by default unless the includePlaces parameter is supplied to specifically include them.
● Work With Pages● Administration● Portal Administration
migrate-portlets-configs
Description: Migrates portlet configuration data to WebSphere Portal Version 5.0.x.
Usage: Invoked as part of the WPmigrate script file. For example: Unix/Linux: ./WPmigrate.sh migrate-portlets-configs Windows: WPmigrate.bat migrate-portlets-configs
Inputs: This task takes the following inputs:
Input Description
includeAppsTakes a comma-separated list of global IDs for portlet applications to include in migration. If left blank, all portlet applications will be included.
excludeAppsTakes a comma-separated list of global IDs for portlet applications to be excluded from migration. If left blank, no portlet application will be excluded.
migrate-themes-skins-configs
Description: Migrates themes and skins to WebSphere Portal Version 5.0.x.
Usage: Invoked as part of the WPmigrate script file. For example: Unix/Linux: ./WPmigrate.sh migrate-themes-skins-configs Windows: WPmigrate.bat migrate-themes-skins-configs
Inputs: This task takes the following inputs:
Input Description
includeThemes Takes a comma-separated list of themes and skins to be included in migration. If left blank, all themes and skins will be included.
excludeThemes Takes a comma-separated list of themes and skins to be excluded from migration. If left blank, no themes and skins will be excluded.
Note: Themes with the following names will not be migrated by default unless the includeThemes parameter is supplied to specifically include them.
● Admin
● AdminLeftNavigation● Corporate● Engineering● Finance● Science● WebSphere● Home
migrate-user-customizations
Description: This task migrates user customizations to WebSphere Portal Version 5.0.x. User customizations are artifacts that are attributed to a user that has EDIT but not MANAGE permissions on a page. They are created when such a user changes the layout of a page or edits portlet settings. Theme configuration references skins. This task will automatically migrate configuration of skins that are referenced by the themes. The parameters will help prevent unnecessary conflicts when migrating implicit (derived) pages holding the user customization data that might not have corresponding explicit pages. As an added precaution, this task checks for the existence of the corresponding explicit pages before importing the implicit page.
Usage: Invoked as part of the WPmigrate script file. For example: Unix/Linux: ./WPmigrate.sh migrate-user-customizations Windows: WPmigrate.bat migrate-user-customizations
Inputs: This task takes the following inputs:
Input Description
includePages Takes a comma-separated list of page names to be included in the migration. If left blank, all user customizations will be included.
excludePages Takes a comma-separated list of page names to be excluded from the migration. If left blank, no user customizations will be excluded.
Assumptions/Prerequisites:
Error Conditions:
Task dependencies: None
Tasks invoked:
migrate-user-groups-ac
Description: Migrates access control user groups.
Usage: Invoked as part of the WPmigrate script file. For example: Unix/Linux: ./WPmigrate.sh migrate-user-groups-ac
Windows: WPmigrate.bat migrate-user-groups-ac
Inputs: None
migrate-wmm
Description: Migrates extended user attributes to WebSphere Portal Version 5.0.x.
Usage: Invoked as part of the WPmigrate script file. For example: Unix/Linux: ./WPmigrate.sh migrate-wmm Windows: WPmigrate.bat migrate-wmm
Inputs: None
migrate-wpcp
Description: This task migrates the run-time tables from WebSphere Portal content publisher Version 4.2 to WebSphere Portal content publisher Version 5.0.x. This includes resource definitions, rules, and campaigns.
Usage: Invoked as part of the WPmigrate script file. For example: Unix/Linux: ./WPmigrate.sh migrate-wpcp Windows: WPmigrate.bat migrate-wpcp
Inputs: None
migrate-wpcp-author
Description: This task will migrate WebSphere content publishing 4.1 or 4.2 authoring projects into WebSphere Portal content publishing Version 5.0 authoring projects. This includes all content, files, rules, campaigns, preview profiles, and resources for each project. This task does not migrate access control or Portal users and groupsAll. WebSphere Portal content publishing Workflow tasks must be completed before beginning migration.
Usage: Invoked as part of the WPmigrate script file. For example: Unix/Linux: ./WPmigrate.sh migrate-wpcp-author Windows: WPmigrate.bat migrate-wpcp-author
Inputs: None
migrate-wpcp-feedback
Description: This task migrates all feedback data from WebSphere Portal content publishing 4.2 to
WebSphere Portal content publishing 5.0. This task could take a very long time to run, as the feedback tables could include many rows of data. It is suggested that if feedback migration is needed, it is run separately from any other migration step and when machine resources are not needed for any other purpose.
Usage: Invoked as part of the WPmigrate script file. For example: Unix/Linux: ./WPmigrate.sh migrate-wpcp-feedback Windows: WPmigrate.bat migrate-wpcp-feedback
Inputs: None
migrate-xmlaccess-script
Description: This task makes custom deployment scripts compatible with the WebSphere Portal Version 5.0.x XML configuration interface schema.
Usage: Invoked as part of the WPmigrate script file. For example:Windows: WPmigrate.bat migrate-xmlaccess-script Unix: ./WPmigrate.sh migrate-xmlaccess-script
Inputs: This task takes the following inputs:
Input DescriptionScriptPath The complete path to your script file.
ScriptSrc The script file name to be converted.
ScriptDest The name of the converted script file.
optimize-roles
Description: Optimizes access control roles.
Usage: Invoked as part of the WPmigrate script file. For example: Unix/Linux: ./WPmigrate.sh optimize-roles Windows: WPmigrate.bat optimize-roles
Inputs: None
Related information● Troubleshooting
Optional migration tasks
The following optional tasks allow you to migrate themes, skins, portlet applications, pages, and portlet configuration data individually during the development phase. When migrating your production environments, it is recommended that you use one of the suitable scenarios described in the Running the migration tasks section. Do not use the optional tasks to migrate your production environments unless it is absolutely necessary.
If you want to migrate artifacts individually in a development environment, choose one of the following sets of steps, depending on your migration scenario: With both WebSphere Portal Versions running at the same time or With only one WebSphere Portal version running at a time.
With both WebSphere Portal Versions running at the same time1. You can migrate themes and skins individually if you did not migrate them along with places.
a. Migrate themes and skins configuration by entering the following command on one line:
Windows:WPmigrate.bat migrate-themes-skins-configsUnix:./WPmigrate.sh migrate-themes-skins-configs
Optional parameters:■ -DincludeThemes=<include_names>■ -DexcludeThemes=<exclude_names>
where:■ <include_names> is a comma-separated list of the names of the themes and skins
to be included in migration. If you do not specify a value for the includeThemes parameter, by default all the themes and skins will be migrated.
■ <exclude_names> is a comma-separated list of the names of the themes and skins to be excluded from migration. If you specify a value for excludeThemes parameter, the themes and skins that are specified will not be migrated.
b. Refer to the Verifying the migration tasks sectionto verify that themes and skins were successfully migrated.
2. You can deploy portlet applications individually if you did not migrate them along with places.a. Enter the following command on one line to migrate portlet applications:
Windows: WPmigrate.bat migrate-apps Unix: ./WPmigrate.sh migrate-apps
Optional parameters: ■ -DincludeApps=<include_names>■ -DexcludeApps=<exclude_names>■ -DappsPath=<your_path>
where: ■ <include_names> is a comma-separated list of global-IDs for portlet applications to
be included in migration. If you do not specify a value for the includeApps parameter, by default all the portlet applications will be migrated.
■ <exclude_names> is a comma-separated list of global IDs for portlet applications to be excluded from migration. If you specify a value for excludeApps parameter, the portlet applications that are specified will not be migrated.
■ <your_path> points to a URL where the WAR files could be found for custom portlet applications (for example: file:///usr/WebSphere/PortalServer/install).
b. Refer to the Verifying the migration tasks section to verify that portlet applications were successfully migrated.
3. If you did not migrate pages along with places, you can migrate pages individually.
a. Migrate pages that are defined in WebSphere Portal Version 4.x to WebSphere Portal Version 5.0.x by entering the following command on one line:
Windows:WPmigrate.bat migrate-pagesUnix:./WPmigrate.sh migrate-pages
Optional parameters:■ -DincludePages=<include_names>■ -DexcludePages=<exclude_names> ■ -DappsPath=<your_path>■ -DconfigThemesSkins=<true_false>
where:■ <include_names> is a comma-separated list of case-sensitive page names to be
included in migration. If you do not specify a value for the includePages parameter, by default all the pages will be migrated.
■ <exclude_names> is a comma-separated list of page names to be excluded from migration. If you specify a value for excludePages parameter, the pages that are specified will not be migrated.
■ <include_owner_names> is a comma-separated list of owner names that help further specify the pages to be included in migration. If you do not specify a value for the includeOwners parameter, by default all the owner names will be migrated.
■ <exclude_owner_names> is a comma-separated list of owner names that help further specify the pages to be excluded from migration. If you specify a value for excludeOwners parameter, the owner names that are specified will not be migrated.
■ <your_path> points to a URL where the WAR files could be found for custom portlet applications if -DdeployApps is set to true.
■ <true_false> allows you to specify whether to migrate themes and skins that are associated with the pages.
b. Refer to the Verifying the migration tasks section to verify that pages were successfully
migrated.
4. If portlets were deployed using custom deployment scripts, you can still migrate all portlet configuration data (that is, portlet title and so on) from WebSphere Portal Version 4.x to WebSphere Portal Version 5.0.x. Use the following task to migrate portlet configuration data if you have not already done so manually.
a. Enter the following command on one line to migrate portlet configuration data:
Windows:WPmigrate.bat migrate-portlets-configsUnix:./WPmigrate.sh migrate-portlets-configs
Optional parameters:■ -DincludeApps=<include_names>■ -DexcludeApps=<exclude_names>
where:■ <include_names> is a comma-separated list of global IDs for portlet applications to
be included in migration. If you do not specify a value for the includeApps parameter, by default all the portlet applications will be migrated.
■ <exclude_names> is a comma-separated list of global IDs for portlet applications to be excluded from migration. If you specify a value for excludeApps parameter, the portlet applications that are specified will not be migrated.
b. Refer to the Verifying the migration tasks section to verify that portlet configuration data was successfully migrated.
With only one WebSphere Portal version running at a time1. If you chose not to export and import themes and skins along with places, you can export and
import them individually using the following steps.a. Export themes and skins configuration by entering the following command on one line:
Unix:./WPmigrate.sh export-themes-skins-configsWindows:WPmigrate.bat export-themes-skins-configs
Optional parameters:■ -DincludeThemes=<include_names>■ -DexcludeThemes=<exclude_names>■ -DfilenameThemes=<filename>
where:■ <include_names> is a comma-separated list of the names of themes and skins to be
included in the export. If you do not specify a value for the includeThemes parameter, by default all the themes and skins will be exported.
■ <exclude_names> is a comma-separated list of the names of themes and skins to be excluded from the export. If you specify a value for excludeThemes parameter, the themes and skins that are specified will not be exported.
■ <filename> is the file to which themes and skins will be exported. Themes and skins
are exported by default to themesout.xml
b. After you have completed all your desired optional export tasks, you can import themes and skins by entering the following command on one line:
Unix:./WPmigrate.sh import-themes-skins-configsWindows:WPmigrate.bat import-themes-skins-configs
Optional parameters:■ -DfilenameThemesSkins=<filename>
where:■ <filename> is the file from which themes and skins will be imported.
c. Refer to the Verifying the migration tasks sectionto verify that your themes and skins were successfully migrated.
2. If you chose not to export and import portlet applications along with places, you can export and import them individually using the following steps.
a. Export portlet applications by entering the following command on one line:
Unix:./WPmigrate.sh export-appsWindows:WPmigrate.bat export-apps
Optional parameters:■ -DincludeApps=<include_names>■ -DexcludeApps=<exclude_names>■ -DfilenameApps=<filename>■ -DpathApps=<your_path>
where:■ <include_names> is a comma-separated list of global IDs for portlet applications to
be included in the export. If you do not specify a value for the includeApps parameter, by default all the portlet applications will be migrated.
■ <exclude_names> is a comma-separated list of global IDs for portlet applications to be excluded from the export. If you specify a value for excludeApps parameter, the portlet applications that are specified will not be exported.
■ <filename> is the file to which portlet applications will be exported. Portlet applications are by default exported to appsout.xml.
■ <your_path> points to a URL where the WAR files could be found for the portlet applications.
b. After you have completed all your desired optional export tasks, you can import portlet applications by entering the following command on one line:
Unix:./WPmigrate.sh import-apps Windows:WPmigrate.bat import-apps
Optional parameters:■ -DfilenameApps=<filename>
where:■ <filename> is the name of the file to which the settings will be exported.
c. Refer to the Verifying the migration tasks section to verify that portlet applications were successfully migrated.
3. If you did not export and import pages along with places, you can export and import pages individually by completing the following steps below.
a. Export pages by entering the following command on one line:
Unix:./WPmigrate.sh export-pagesWindows:WPmigrate.bat export-pages
Optional parameters:■ -DincludePages=<include_page_names> ■ -DexcludePages=<exclude_page_names>■ -DfilenamePages=<filename>■ -DdeployApps=<true_false>■ -DconfigThemesSkins=<true_false> ■ -DpathApps=<your_path>
where:■ <include_page_names> is a comma-separated list of pages to be included in the
export. If you do not specify a value for the includePages parameter, by default all the pages will be exported.
■ <exclude_page_names> is a comma-separated list of pages to be excluded from the export. If you specify a value for excludePages parameter, the pages that are specified will not be exported.
■ <include_owner_names> is a comma-separated list of owner names that help further specify the pages to be included in the export. If you do not specify a value for the includeOwners parameter, by default all the owner names will be migrated.
■ <exclude_owner_names> is a comma-separated list of owner names that help further specify the pages to be excluded from the export. If you specify a value for the excludeOwners parameter, the owner names that are specified will not be exported.
■ <filename> is the name of the file to which the pages will be exported. The default file name is pagesout.xml.
■ <true_false> allows you to specify whether you want to export portlet applications and themes and skins along with the pages.
■ <your_path> is a URL where the WAR files could be found for custom portlet applications.
b. After you have completed all your desired optional export tasks, you can import pages by entering the following command on one line:
Unix:./WPmigrate.sh import-pagesWindows:WPmigrate.bat import-pages
Optional parameters:■ -DfilenamePages=<filename>
where:■ <filename> is the name of the file to which the page data was exported.
c. Refer to the Verifying the migration tasks section to verify that pages were successfully migrated.
4. If portlets were deployed using custom deployment scripts, you can still export and import all portlet configuration data (that is, portlet title and so on). Export and import portlet configuration data by completing the following steps.
a. Export portlet configuration data by entering the following command on one line:
Unix:./WPmigrate.sh export-portlets-configs Windows:WPmigrate.bat export-portlets-configs
Optional parameters:■ -DincludeApps=<include_names>■ -DexcludeApps=<exclude_names>■ -DfilenamePortletsConfig=<filename>
where:■ <include_names> is a comma-separated list of global IDs for portlet applications to
be included in the export. If you do not specify a value for the includeApps parameter, by default all the portlet applications will be exported.
■ <exclude_names> is a comma-separated list of global IDs for portlet applications to be excluded from the export. If you specify a value for excludeApps parameter, the portlet applications that are specified will not be exported.
■ <filename> is the file to which portlet configuration data will be exported. Portlet configuration data is exported by default to portletsconfigsout.xml.
b. After you have completed all your desired optional export tasks, you can import portlet configuration data by entering following command on one line:
Unix:./WPmigrate.sh import-portlets-configsWindows:WPmigrate.bat import-portlets-configs
Optional parameters:■ -DfilenamePortletsConfig=<filename>
where:■ <filename> is the name of the file to which the settings will be exported.
c. Refer to the Verifying the migration tasks section to verify that portlet configuration data was successfully migrated.
Related information
● Troubleshooting
Migration troubleshooting
● Issues with supported versions of Tivoli Access Manager● Exporting pages with duplicate page names causes an error● Problems encountered when running the migrate-wpcp task● HTTP 500 error encountered when running any of the migration tasks● Error 500 received while running migration tasks on Solaris and trying to contact WebSphere Portal
Version 4.1.x● Migrate-pages task fails with the error Duplicate objectid attribute● Migrate-pages task fails with the error Illegal page structure● Errors received in the trace.log file when running the migrate-wmm task● Error received when rerunning the migrate-places or migrate-pages task after applying the
interim fix
Issues with supported versions of Tivoli Access Manager
WebSphere Portal Version 5.0.x requires Tivoli Access Manager 4.1 + Fix pack 2. Some previous versions of WebSphere Portal supported older versions of Tivoli Access Manager and will not work with Tivoli Access Manager 4.1. This can create problems during the migration process. Choose one of the following methods for the most successful migration:
● Install fix pack 4 on Tivoli Access Manager 3.9. Perform the WebSphere Portal migration. After the migration is complete, you will be running WebSphere Portal Version 5.0.x with Tivoli Access Manager 3.9 + fix pack 4. This is not a supported configuration. Upgrade to Tivoli Access Manager 4.1 + fix pack 2 as soon as possible.
● Install Tivoli Access Manager 4.1 + fix pack 2 before beginning the WebSphere Portal migration. Leave the WebSphere Portal Version 4.x and Tivoli Access Manager 3.9 systems intact. Install WebSphere Portal Version 5.0.x and configure it to work with Tivoli Access Manager 4.1. Then begin the migration process. This method requires additional resources because WebSphere Portal Version 4.x, Tivoli Access Manager 3.9, WebSphere Portal Version 5.0.x, and Tivoli Access Manager 4.1 must all be installed and operational.
Exporting pages with duplicate page names causes an error
In the case of an explicit export of a component (executing export-places) an Identification is not unique error might occur. This might be the result of two users creating a page with same name. For example, two users can create a page called MyPage. In this case, the component needs to be renamed to be able to run the export. The exception can be overwritten by using the force flag (see the following sample). XML configuration interface will then export the first component that is found with that name.
Sample that would fail if there is more than one component named MyPage:
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE request PUBLIC "-//IBM//DTD Portal Configuration 1.1//EN" "PortalConfig_1.1.dtd">
<request include-mapping="true"> <portal action="locate"> <composition action="locate" name="Root.Composition"> <component action="locate" name="Home"> <!-- <component action="export" name="MyPage" force="true"/> --> <component action="export" name="MyPage"></component> </component> </composition> </portal></request>
Problems encountered when running the migrate-wpcp taskIf there are exceptions connecting to your database using the net driver on the WebSphere Portal Version 4.x system, or if the migrate-wpcp task hangs and does not return anything, complete the following steps:
1. Run db2profile in /home/db2admin/sqllib.2. Run the following command:
db2jstrt <port>
where: <port> is the port that will be used to connect to the database. This is the port that is specified in the WpcpRuntimeSourceUrl property in the mig_wpcp.properties file on your WebSphere Portal Version 5.0.x system.
HTTP 500 error encountered when running any of the migration tasks
If you receive an HTTP 500 error while running a migration task, open the <wp4_root>/log/appserver-out.log file. Check for the following error message:
# HotSpot Virtual Machine Error : 11
This means that WebSphere Portal Version 4.x was restarted due to a Java Virtual Machine crash. If you see this error in the log file, you must always access WebSphere Portal Version 4.x through a browser to verify that it is operational before running the migration tasks. You only need to check the appserver-out.log file once after WebSphere Portal Version 4.x restarts; if you see the error message in the log file once, the error will continue to occur.
Error 500 received while running migration tasks on Solaris and trying to contact WebSphere Portal Version 4.1.x
Open the file <wp4_root>/log/appserver-out.log. You will see that the JVM received a signal 11 and that WebSphere Portal has restarted.
If you are running WebSphere Portal Version 4.1.x on Solaris, verify the level of Java that is being used under the <was_root>/AppServer/java/bin
directory. The version that is tested with migration is 1.3.1_08. WebSphere Application Server 4.0.2 is not certified for this version of the Java Development Kit. If you find that you need to upgrade to fix this problem, consider using the following steps:
1. Back up the <was_root>/AppServer/java directory.2. Download the latest 1.3.1 JDK.3. Extract the JDK into a temporary subdirectory.4. In the extract directory, remove the jre/lib/security directory (you
need to keep the security directory that is shipped with WebSphere Application Server Version 4.0.2).
5. Stop WebSphere Application Server Version 4.0.2 and WebSphere Portal Version 4.1.x.
6. Overlay the <was_root>/AppServer/java directory structure with the extracted one.
7. Perform the migration tasks.8. Restore the original Java directory.9. Restart WebSphere Application Server Version 4.0.2 and WebSphere Portal
Version 4.1.x.
Migrate-pages task fails with the error Duplicate objectid attribute
If the migrate-pages task fails with the error Duplicate objectid attribute, remove the work directory from <wp5_root>/migration and try the task again.
Migrate-pages task fails with the error Illegal page structure
If the migrate-pages task fails with error Illegal page structure, make sure that you have applied the updated fix that is supplied with the migration interim fix to WebSphere Portal Version 4.x. If you have not, apply the updated fix to WebSphere Portal Version 4.x and rerun the migrate-pages task.
Errors received in the trace.log file when running the migrate-wmm task● If you are using DB2 version 7 Fix pack 8 client and server, ignore the following errors in the Member Manager trace.log file. Migration will continue successfully after these errors are reported: SQL0031C File "/home/db2inst1/sqllib/bnd/db2schem.bnd" could not be opened.SQL0040N An error occurred on one or more bind files in list "db2cli.lst".SQL0082C An error has occurred which has terminated processing.SQL0091N Binding was ended with "3" errors and "0" warnings.The errors are being reported because your DB2 client is missing a db2schem.bnd file. This file was added in DB2 version 7 Fix pack 8 to address some functionality in dealing with DB2 version 8. If you would like to modify your client so that the errors do not continue to occur, you should be able to copy the missing file from your server to the client. The next time DB2 performs an implicit bind on a
new database from your client's attach, the file will be accessible and the errors will not occur.
● If you ran the migrate-wmm task on a clean Member Manager database, or if some of the tables referenced by the task are not in the database, you will receive an error message. This message can be ignored. Here is an example of an error message that is received when the table WMMLAKEYS is not in the database:
DROP TABLE WMMLAKEYS---- --- ---exception executing: DROP TABLE WMMLAKEYSCOM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver][DB2/6000] SQL0204N "DB2INST1.WMMLAKEYS" is a name non-given a definition.SQLSTATE=42704
● If a user has specified that a certain uuid exists on the LDAP server, and a match cannot be found for that uuid under the corresponding distinguished name, you will receive an error message. The migrate-wmm command will not stop due to this error, but it will not create corresponding rows for the distinguished names in the WMMLAEXTID table. You might want to check to see if the uuid exists in the LDAP for the distinguished name, but the error can be ignored. Here is an example of the error message that this scenario will generate:
Error in WMMLAEXTID.del: Cannot add line with member_id: 157 ,alphanum_extid: null ,repositoryId: LDAP1Reason for error: Cannot find the uuid in the LDAP directory for the member: uid=user6,cn=users,dc=ibm,dc=com
● You can ignore the following error message depending on your Member Manager configuration:
Error in /usr/WebSphere5/PortalServer/migration/work/templates/wmm/db2/lookaside\WMMLAASVAL.del: Cannot find attribute userPassword in the WMS MBRATTR table...
If your LDAP is configured with a Lookaside database, some attributes might be stored in the LDAP server (in this case, the userPassword attribute). If this is the case, the attribute does not need to be migrated to the Member Manager Lookaside database and the error message can be ignored.
Error received when rerunning the migrate-places or migrate-pages task after applying the interim fix
If you run the migrate-places or migrate-pages tasks successfully before applying the interim fix and then rerun them after applying the interim fix, you might receive the error Although the resource was detected, it is wrong
in the context. If you receive this error, remove all the migrated places and pages from the WebSphere Portal Version 5.0.x system and rerun the task. If the task still fails, you will have to restore the WebSphere Portal Version 5.0.x database by deleting the existing database. Then you must reconfigure a new database from the default Cloudscape database that was initialized during installation. Use the following steps to restore databases to their initial state, and rerun all migration tasks:
1. Replace the values for the PortalAdminId and PortalAdminGroupId parameters with the default values in the wpsconfig.properties file.
2. Disable security using the following command:
Windows: WPSconfig.bat disable-securityUnix: ./WPSconfig.sh disable-security
3. Delete and re-create the wps50, wpcp50, and fdbk50 databases.4. Delete and re-create WPSDBUSR, WMMDBUSR, PZNADMIN, EJB, WCMDBADM, and
FEEDBACK users.5. Execute the following command:
Windows: WPSconfig.bat database-transfer-importUnix: ./WPSconfig.sh database-transfer-import
6. Replace the default values for the PortalAdminID and PortalAdminGroupID parmameters with the appropriate required values in the wpconfig.properties file.
7. Enable security using the following command:
Windows: WPSconfig.bat enable-security-ldapUnix: ./WPSconfig.sh enable-security-ldap
Related information● Planning
● The migration process● Manual migration steps
● Preparing to run the migration tasks● Running the migration tasks
● Migrating the remaining access control configuration● Migration properties
● Migration tasks● Optional migration tasks
Additional resources
Additional information that can help you install, configure, or administer the products provided with WebSphere Portal is available. You can locate information on the WebSphere Portal Web site and other IBM Web sites, and you can read the product documentation that is provided on the WebSphere Portal CDs.
Related information● Resources for learning● Resources and support● Directory Structure
Resources for learning
Use the following links to find relevant supplemental information. The information resides on IBM and non-IBM Internet sites, whose sponsors control the technical accuracy of the information.
These links are provided for convenience. Sometimes, the information is not specific to the WebSphere Portal product, but is useful all or in part for understanding the product. When possible, links are provided to technical papers and IBM Redbooks that supplement the broad coverage of the release documentation with in-depth examinations of particular product areas.
View links to additional information about:
● Planning, business scenarios, and IT architecture ● Installation scenarios● Programming model and decisions ● Programming instructions and examples ● Programming specifications ● Additional applications● Administration ● Support ● Related information
Planning, business scenarios, and IT architecture● IBM WebSphere Developer Domain
http://www.ibm.com/websphere/developer/zones/portal/The home of technical information for developers working with WebSphere products. You can download WebSphere software, take a fast path to developer domain zones, such as WebSphere Portal, WebSphere Application Server, or WebSphere Studio, learn about WebSphere products through a newcomers page, tutorials, technology previews, training, and IBM Redbooks, get answers to questions about WebSphere products, and join the WebSphere community, where you can keep up with the latest developments and technical papers.
● IBM WebSphere Developer Domain: WebSphere Portal Zonehttp://www.ibm.com/websphere/developer/zones/portal/ Technical information for developers and administrators of WebSphere Portal.
● WebSphere Portal home page$http://www.ibm.com/software/genservers/portal/The IBM WebSphere Portal home page contains useful information, including support links and downloads for interim fixes, tools, and trials.
● IBM WebSphere software platform home pagehttp://www.ibm.com/software/websphere/ The IBM WebSphere software platform home page introduces WebSphere products and describes how companies can easily transform to an e-business, with software that can grow as fast as the business it supports.
● Guide to WebSphere Portal
ftp://ftp.software.ibm.com/software/websphere/portal/pdf/Guide-to-Websphere-Portal.pdf This document provides an overview of the WebSphere Portal product technology, including its business and technical benefits. It is intended to help customers, independent software vendors, and application architects understand and plan their use of WebSphere Portal. Concepts such as portlets, portal applications, content, security, user management, administration, collaboration, and more are described, including highlights of related products that can be used with WebSphere Portal.
● developerWorks: IBM Patterns for e-businesshttp://www.ibm.com/developerworks/patterns/index.html The IBM developerWorks site is the source for IBM patterns for e-business, a set of tested, reusable intellectual assets that you can use to design and implement your e-business network and architecture.
● WebSphere Portal Collaborative Components, REDP0319http://publib-b.boulder.ibm.com/Redbooks.nsf/RedpieceAbstracts/redp0319.html This IBM Redbook discusses the collaborative capabilities that are included within the WebSphere Portal offering. It covers:- An introduction to the WebSphere Portal Family and the concept of collaborative portlets- Installation- and deployment-oriented topics for getting a collaborative WebSphere Portal environment up and running- Details around the Collaborative Portlets available out-of-the-box with WebSphere Portal- Details and best practices for the usage of the Collaborative Components API available with Portal - including several sample collaborative Portlets that leverage this API.
● Enterprise Business Portals II with Tivoli Access Manager, SG24-6556-00http://publib-b.boulder.ibm.com/Redbooks.nsf/9445fa5b416f6e32852569ae006bb65f/c2c8b29bfd41ec8c85256c22006e7655?OpenDocument This IBM Redbook describes how to build an integrated enterprise business portal with Tivoli Access Manager Version 4.1, WebSphere Portal Version 4.1.2, mySAP Workplace, and the SAP Enterprise Portal. It also describes how to implement a federated single signon solution within a Web Services scenario.
● A Secure Portal using WebSphere Portal V5 and Tivoli Access Manager, SG24-6077-00http://publib-b.boulder.ibm.com/Redbooks.nsf/9445fa5b416f6e32852569ae006bb65f/3d96ba9fea9a252985256d6e0064f0f7?OpenDocument The focus of this publication is the security aspect of the WebSphere Portal single access point with centralized authentication and authorization. Other aspects of security like auditing, firewall, and DMZ are not in the scope of this document.
● IBM WebSphere Portal V4.1.2 in a Linux Environment, REDP0310http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/redp0310.html This IBM Redbook helps you plan, install, and administer the WebSphere Portal Version 4.1.2 offering product in a Red Hat Linux environment so that existing enterprise applications can be accessed from portlets using the IBM WebSphere Portal product.
● Integrating Host Applications with e-business Portals, REDP0191http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/redp0191.html This IBM Redbook helps you integrate existing host enterprise applications so that they can be accessed from portlets using the WebSphere Portal product.
● Access Integration Pattern using IBM WebSphere Portal Server, SG24-6267-00http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/sg246267.html This IBM Redbook provides an example and guidelines for the Access Integration pattern. It shows
how the pattern works and documents the tasks required to build an example of it.- Part 1 of the redbook guides you through the process of choosing an application and run-time pattern to deliver the desired functionality of the Access Integration pattern. - Part 2 of the redbook provides a set of guidelines for building your portal application, including discussion of application design, application development and systems management. - Part 3 of the redbook demonstrates how to portalize an existing application and develop personalized portlets. The sample uses LDAP for external authentication and WebSphere Security for authorization.
● Deploying QuickPlace, SG24-6535-00http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/sg246535.html This IBM Redbook shows you how to install, configure, and deploy QuickPlace in your organization. It gives step-by-step installation instructions for the QuickPlace server and describes how to configure it to use the current directories of your organization.
● IBM WebSphere Application Server V5.0 System Management and Configuration: WebSphere Handbook Series, SG24-6195-00 http://publib-b.boulder.ibm.com/Redbooks.nsf/9445fa5b416f6e32852569ae006bb65f/738c2b6bd8dce36185256bd5004e1fd4?OpenDocument This IBM Redbook provides an overview of the architecture, topology options, and new features of WebSphere Studio Application Developer Version 5 and WebSphere Studio Application Developer Network Deployment Version 5. In addition, it describes how to install, configure, and perform ongoing management of the WebSphere environment.
● IBM WebSphere V5.0 Security WebSphere Handbook Series, SG24-6573-00 http://publib-b.boulder.ibm.com/Redbooks.nsf/9445fa5b416f6e32852569ae006bb65f/d630ec33fde5486785256b5f007ecac5?OpenDocument This IBM Redbook describes how to design, develop, and deploy secure e-business applications using WebSphere Studio Application Developer Version 5. It includes a detailed overview of WebSphere Application Server V5 Security, including J2EE security, modules and components of a J2EE enterprise application, and programmatic security techniques. It also describes end-to-end security solutions where WebSphere Studio Application Developer V5 is part of an enterprise solution, including including integration between WebSphere Studio Application Developer V5 and Tivoli Access Manager .
● Working with the Sametime Client Toolkits, SG24-6666-00 http://publib-b.boulder.ibm.com/Redbooks.nsf/9445fa5b416f6e32852569ae006bb65f/f2b73cdd644ac8a485256acc005ca7c7?OpenDocument This IBM Redbook is for developers and architects who want to use Sametime functionality in applications based on Java, C++, COM, or HTML and JavaScript. It explores capabilities offered by the different Sametime client toolkits, which you can use to add functionality to existing applications and to create powerful new applications that enable real-time collaboration. It discusses event-based programming, Sametime services, and the Sametime Place architecture.
Installation scenarios ● WebSphere Portal V4.1 Windows 2000 Installation, REDP3593
http://publib-b.boulder.ibm.com/Redbooks.nsf/RedpieceAbstracts/redp3593.html This IBM Redbook helps you plan, install, and administer the WebSphere Portal Version 4.1.2 offering product in a Microsoft Windows 2000 environment, so that existing enterprise applications can be accessed from portlets using the IBM WebSphere Portal product.
● WebSphere Portal V4.1 AIX 5L Installation, REDP3594http://publib-b.boulder.ibm.com/Redbooks.nsf/RedpieceAbstracts/redp3594.html This IBM Redbook helps you plan, install, and administer the WebSphere Portal Version 4.1.2 offering product in an IBM AIX 5L environment so that existing enterprise applications can be accessed from portlets using the IBM WebSphere Portal product.
● Installing WebSphere Portal Enable V4.1.2 in a Windows Proof of Concept Environmenthttp://www.ibm.com/support/docview.wss?rs=203&q=of%2Bconcept%2Bproof&uid=swg27002296 With WebSphere Portal V4.1, you can quickly install a proof-of-concept environment with security, scalability, and customization options already in place. This paper walks you through the installation of WebSphere Portal Version 4.1.2 and its prerequisite components.
Programming model and scenarios ● Designing e-business Solutions for Performance
http://www.ibm.com/developerworks/patterns/ebusiness-performance-customer-v2.pdf This white paper describes how the design or implementation of an e-business application can affect performance.
● Managing Web Site Performancehttp://www.ibm.com/developerworks/patterns/guidelines/HTTP_Session_Best_Practice.pdf This white paper contains tips and techniques for developers building applications that use session persistence. It also helps administrators to tune the WebSphere Application Server product appropriately for these applications.
Programming instructions and examples ● IBM developerWorks
http://www.ibm.com/developerworks/ IBM developerWorks contains many excellent resources for developers, including tutorials on Web development-related topics. There is an excellent tutorial on the JDBC API.
● IBM Redbookshttp://www.redbooks.ibm.com/ The IBM Redbooks site contains many WebSphere Application Server related documents.
● Servlets and JavaServer Pages - A Tutorial http://www.apl.jhu.edu/~hall/java/Servlet-Tutorial/ Tutorial from the author of Core Servlets and JavaServer Pages.
Programming specifications ● Java Authentication and Authorization Service (JAAS)
http://java.sun.com/products/jaas/index-10.html For more information about JAAS specifications, visit the Sun site that is previously mentioned.
● Portlet specificationhttp://jcp.org/jsr/detail/168.jsp For more information about portlet specifications, visit the Sun sponsored site that is previously mentioned.
● J2EE informationhttp://java.sun.com For more information about J2EE specifications, visit the Sun site that is previously mentioned.
● sun.net.inetaddr.ttl propertyhttp://java.sun.com/j2se/1.4/docs/guide/net/properties.html The following Java 2 SDK, Standard Edition 1.4 Web site describes the private sun.net.inetaddr.ttl property, which also works in Java 2 SDK, Standard Edition 1.3.
● java.net.URLConnection classhttp://java.sun.com/j2se/1.4.1/jcp/beta/ The Networking section of this Java 2 SDK, Standard Edition 1.4 Web site describes a change in the behavior of the java.net.URLConnection class.
Additional applications ● IBM Workplace Solutions Catalog
http://www7b.software.ibm.com/wsdd/zones/portal/catalog/index.html The portlets that are described in this IBM Workplace Solutions Catalog are provided by many parties, including IBM. The portlets are listed by IBM in this catalog for your information purposes only. Each of the portlets has an applicable user license agreement. The terms and conditions under which a specific portlet can be used and the responsibilities of the user and the portlet provider are described in the user license agreement for that portlet.
Administration ● Best Practices Zone on WSDD
http://www7b.boulder.ibm.com/wsdd/zones/bp/ The WebSphere Best Practices Zone is a collection of best practices for administering WebSphere Application Server. Over time, the zone is intended to grow to include best practices for using other WebSphere software products, and to cover more topics. Use the feedback mechanism to submit your best practice suggestions.
● The IBM Glossary of Computing Termshttp://www.ibm.com/ibm/terminology/goc/gocmain.htm This glossary defines technical terms that are used in many IBM products. It is not a comprehensive resource of all IBM computing terms. This resource is provided for information purposes only and is updated periodically. IBM takes no responsibility for the accuracy of the information it contains.
Support● WebSphere Portal Support page
http://www.ibm.com/software/genservers/portal/support/Take advantage of the Web-based Support and Service resources from IBM to quickly find answers to your technical questions. Here you will find support downloads, hints & tips, product information, and redbooks.
● IBM Software Support pagehttp://www.ibm.com/software/supportYou can access this extensive Web-based support through the IBM Software Support portal and search by product category or by product name. For example, if you are experiencing problems that are specific to WebSphere Application Server, select Products A-Z and locate WebSphere Application Server. The WebSphere Application Server Support page appears.
● IBM Software Support Guide
http://techsupport.services.ibm.com/guides/contacts.html This information provides the numbers to reach a duty manager, the numbers of service site hotlines, and the numbers of service site managers.
Related information● Additional resources
Resources and support
In addition to the Information Center, you can locate product documentation on the WebSphere Portal CDs or on a separate Information CD that is shipped with WebSphere Portal.
Important: It is recommended that you use the installation program to install the software that is included with WebSphere Portal. For more information, see Installing. If you elect to use the installation programs that are provided with a component, refer to this information to locate specific product documentation.
WebSphere Portal Enable includes the following products:
● WebSphere Portal● IBM WebSphere Application Server● IBM HTTP Server● IBM Directory Server● DB2 Enterprise Edition● IBM Rational Application Developer● WebSphere Translation Server
WebSphere Portal Extend adds the following products:
● IBM Lotus Domino Enterprise Server● Lotus Sametime● Lotus QuickPlace● IBM Tivoli Web Site Analyzer● IBM Lotus Extended Search
WebSphere Portal Enable includes the following products:
WebSphere Portal
Product documentation
WebSphere Portal product documentation is available to view and download from the Web. As updates are received the product documentation on the Web is updated, therefore it is important to always check the Web for the most current information. In addition to this Information Center, online files supplement the information in this Information Center. Examine these files before you install WebSphere Portal. They contain vital information about application and performance issues.
● Information Centerhttp://www.ibm.com/websphere/portal/libraryThe WebSphere Portal Information Center includes introduction, planning, installing, configuring, administering, and developing topics.
● Release Notes
http://www.ibm.com/websphere/portal/libraryRelease notes describe compatibility issues, feature differences from earlier versions of WebSphere Portal, and how these differences might affect current products. Release notes also contain information about any known problems and their workarounds.
● Supported hardware and softwarehttp://www.ibm.com/websphere/portal/librarySupported hardware and software shows the software products, operating systems, and hardware that WebSphere Portal supports. Supported versions, fixes, and special notes are included.
Additional information available on the Web
Product documentation, supplemental information, late breaking news, release notes, hints & tips, support, and downloads are available on the Web at the following Web sites:
● WebSphere Portal product documentation page http://www.ibm.com/websphere/portal/library This page contains product documentation, including Information Centers, Release Notes, and other supplemental information, for all offerings and releases of WebSphere Portal.
● WebSphere Portal support page http://www.ibm.com/software/genservers/portal/support/ This site contains Hints & Tips, workarounds for problems identified after release, downloads, and more.
● WebSphere Portal Zonehttp://www.ibm.com/websphere/developer/zones/portal/ This site contains articles, tutorials, JavaDoc, and more to help you make the most of your portal.
● WebSphere Portal Web sitehttp://www.ibm.com/software/genservers/portal/ This site provides information about WebSphere Portal and the WebSphere platform of products.
● IBM Software Support page http://www.ibm.com/software/support You can access this extensive Web-based support through the IBM Software Support portal and search by product category or by product name. For example, if you are experiencing problems that are specific to WebSphere Application Server, select Products A-Z and locate WebSphere Application Server. The WebSphere Application Server Support page appears.
● IBM Software Support Guide http://techsupport.services.ibm.com/guides/contacts.html This information provides the numbers to reach a duty manager, the numbers of service site hotlines, and the numbers of service site managers.
WebSphere Application Server
On the Web: additional information, downloads, support, and documentation are available on the Web site.
● Product site: http://www.ibm.com/software/webservers/appserv/was/● Documentation site: http://www.ibm.com/software/webservers/appserv/was/library/● Support site: http://www.ibm.com/software/webservers/appserv/was/support/
IBM HTTP Server
Additional information, downloads, support, and documentation are available on the Web site.
● Product site: http://www.ibm.com/software/webservers/httpservers/ ● Documentation: http://www.ibm.com/software/webservers/httpservers/library.html● Support site: http://www.ibm.com/software/webservers/httpservers/support.html
IBM Directory Server
On the Web: additional information, downloads, support, and documentation are available on the Web site.
● Product site: http://www.ibm.com/software/network/directory/● Documentation: http://www.ibm.com/software/network/directory/library/
DB2 Enterprise Edition
On the Web: additional information, downloads, support, and documentation are available on the Web site.
● Product site: http://www.ibm.com/software/data/db2/● Documentation: http://www.ibm.com/software/data/pubs/● Support site: http://www.ibm.com/software/data/support/
Application Developer
On the Web: additional information, downloads, support, and documentation are available on the Web site.
● Product site: http://www.ibm.com/software/awdtools/developer/application/● Support site: http://www.ibm.com/software/awdtools/developer/application/support/
Translation Server
On the Web: additional information, downloads, support, and documentation are available on the Web site.
● Product site: http://www.ibm.com/software/pervasive/products/voice/translation_server.shtml● Documentation: http://www.ibm.com/software/pervasive/products/voice/translation_server.shtml● Support site: http://www.ibm.com/software/pervasive/products/voice/translation_server.shtml
WebSphere Portal Extend adds the following products:
Domino
On the Web: additional information, downloads, support, and documentation are available on the Web
site.
● Web site: http://www.lotus.com/home.nsf/welcome/dominoapplicationserver
Sametime
On the Web: additional information, downloads, support, and documentation are available on the Web site.
● Web site: http://www.lotus.com/products/lotussametime.nsf/wdocs/homepage ● Support site: http://www.ibm.com/software/lotus/support/sametime/support.html
QuickPlace
On the Web: additional information, downloads, support, and documentation are available on the Web site.
● Web site: http://www.lotus.com/products/qplace.nsf/homepage/$first ● Support site: http://www.ibm.com/software/lotus/support/
Notes/Domino and Extended Products Portlets
On the Web, additional documentation for setting up Domino-based portlets is available in the Domino and Extended Products 6.5.1 Integration Guide. Includes planning information, as well as streamlined server and portlet installation and configuration procedures tailored to a pilot configuration.
● Web site: Domino and Extended Products 6.5.1 Integration Guide
Tivoli Web Site Analyzer
On the Web: additional information, downloads, support, and documentation are available on the Web site.
● Product site: http://www.ibm.com/software/sysmgmt/products/web-site-analyzer.html● Documentation site: http://www.ibm.com/software/tivoli/library/● Support site: http://www.ibm.com/software/sysmgmt/products/support/
Lotus Extended Search
On the Web: additional information, downloads, support, and documentation are available on the Web site.
● Web site: http://www.lotus.com/products/des.nsf/wdocs/home ● Support site: http://www.ibm.com/software/lotus/support/
Related information● Additional resources● Resources for learning
html_footer_ent
WebSphere Portal Directory structure
This topic shows the naming conventions used to denote the location of files on the portal server and the types of resources you can find in those directories.
WebSphere Portal directory structure
Throughout this documentation, the install location for the portal server component of WebSphere Portal is noted as wp_root. The following table shows the default location if it is not otherwise specified during installation:
Operating system Location
AIX /usr/WebSphere/PortalServer
Linux /opt/WebSphere/PortalServer
Solaris /opt/WebSphere/PortalServer
Windows C:\Program Files\WebSphere\PortalServer
The portal server has the following directory structure after installation:
wp_root Root directory for WebSphere Portal | + _uninst Files used to uninstall WebSphere Portal | +-- app Transcoding tag library definition in the /wps.ear/wps.war/WEB-INF/tld subfolder | +-- bin WebSphere Portal tools | +-- cloudscape Cloudscape database files | +-- config Portal configuration files | +-- deployed Copies of the .ear and .war files for installed portlet applications. | +-- dev Resources for portlet developers, including Struts | +-- doc WebSphere Portal Information Center and Javadoc | +-- IBMTrans Transcoding component |
+-- installableApps WAR files prior to deployment | +-- installedApps Active portlet applications extracted to the WAR file directory structure | +-- launchPad Images used by the WebSphere Portal Launchpad | +-- license WebSphere Portal license agreement | +-- log WebSphere Portal log files | +-- migration Scripts used to assist in migrating from previous releases of WebSphere Portal | +-- odc Productivity components | +-- package Response files and utilities for install | +-- pb Propery broker files for cooperative portlets | +-- portletscripts XML files for installing portlets individually | +-- shared | | | +-- app WebSphere Portal runtime JARs, TLDs, and other resources | | | +-- config Portal configuration files | | | | | +- services Portal services configuration files (*.properties) | | | +-- nls WebSphere Portal NLS files | | | +-- WEB-INF Resources for the WebSphere Portal | | | +- tld Portal JSP taglibs | +-- uninstall Resources for uninstalling WebSphere Portal and components | +-- version Version information for various components | +-- wmm Member Manager configuration, including attributes of portal users | +-- wpcp WebSphere Portal Content Publisher runtime and resources | +-- wts Resources for Transcoding Technology
WebSphere Application Server directory structure
Throughout this documentation, the install location for WebSphere Application Server is noted as was_root. The following table shows the default location if it is not otherwise specified during installation:
Operating system Location
AIX /usr/WebSphere/AppServer
Linux /opt/WebSphere/AppServer
Solaris /opt/WebSphere/AppServer
Windows C:\Program Files\WebSphere\AppServer
The WebSphere Portal enterprise application is installed to the following location within WebSphere Application Server's path:
/installedApps/hostname/wps.ear/wps.war
The WAR file directory structure for the WebSphere Portal enterprise application contains the following resources.
wps.war | +-- c2a Cooperative portlet resources | +-- dtd Document Type Definitions (DTDs) for Portal Server | +-- html HTML files for the portal | +-- images Graphics for the portal | +-- menu Files for MenuService | +-- META-INF Metadata for the portal Web application | +-- peopleawareness Files for PeopleService | +-- screens Screen JSPs for the portal | | | +-- markup_name Subdirectory for each markup type | |-- skins Skin JSPs for the portal | | | +-- markup_name Subdirectory for each markup type | |-- themes Theme JSPs for the portal | | | +-- markup_name Subdirectory for each markup type | +-- WEB-INF Resources for the Portal Server Web application
Directories for languages
The following shows the languages supported by WebSphere Portal and the directories used for storing locale-specific resources. These directories are used in portlet Web application directories and in the WebSphere Portal enterprise application (themes, skins, and other Web application resources).
Language (locale) Directory Language (locale) Directory
Arabic /ar Czech /cs
Danish /da Dutch /nl
English /en Finnish /fi
French /fr German /de
Greek /el Hebrew /iw
Hungarian /hu Italian /it
Japanese /ja Korean /ko
Norwegian /no Polish /pl
Portuguese /pt Brazilian Portuguese /pt_BR
Russian /ru Spanish /es
Simplified Chinese /zh Traditional Chinese /zh_TW
Swedish /sv Turkish /tr
Glossary
Refer to the IBM terminology Web site for glossary terms for this product and related products.
Notices and trademarks
Copyright
(c) Copyright International Business Machines Corporation 2000, 2005. All rights reserved. U.S. Government Users Restricted Rights - Use, duplication, or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Trademarks
AIX, DB2, IBM, RS/6000, SecureWay, Tivoli and WebSphere are trademarks of the IBM Corporation in the United States, other countries, or both.
Lotus, Notes, Domino, QuickPlace, Sametime, Lotus Discovery Server are trademarks or registered trademarks of Lotus Development Corporation and/or IBM Corporation in the United States, other countries, or both.
Documentum is a trademark of Documentum, Inc.
Interwoven and TeamSite are trademarks or registered trademarks of Interwoven, Inc.
Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.
JDBC is a trademark of Sun Microsystems, Inc. in the United States, other countries, or both.
Linux is a registered trademark of Linus Torvalds.
Microsoft, Active Directory, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.
Verdana is a trademark of Microsoft Corporation in the United States, other countries, or both.
Vignette is a registered trademark of Vignette Corporation.
This product includes software developed by the ExoLab Project (http://www.exolab.org/).
This product includes software developed by the Java Apache Project (http://java.apache.org/).
Other company, product, and service names may be trademarks or service marks of others.
About IBM | Privacy | Legal | Contact