<<

. 21
( 87 .)



>>

95 percent of the examples by using the appropriate directory format and
replacing WPMigrate with WPMigrate.sh. In this chapter, <wp4_root>
refers to the WebSphere Portal 4.x root directory, <wp5_root> refers to the
WebSphere Portal 5.x root directory, <was4_root> refers to the WebSphere
Administration Server 4.x root directory, and <was5_root> refers to the
WebSphere Administration 5.x root directory.



Preparing for a Migration
In order to prepare for a migration, you must identify the supported mi-
gration path, any constraints, and your environment. There are numerous
constraints on the migration paths supported by WebSphere 5.x. Table 6-1
lists the various versions of WebSphere Portal Server that can be migrated
to WebSphere Portal 5.x. Basically, you can only migrate from WebSphere
Portal Version 4.1.2 and higher. The left column lists the version that can be
migrated to the WebSphere Portal version in the right column.


105
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-06 WY009-BenNatan-v1.cls May 9, 2004 9:35




106 Chapter 6

Table 6-1 Supported Migration Paths
WEBSPHERE PORTAL 4.X VERSION 5.X VERSION
WebSphere Portal Enable Version 4.1.2, WebSphere Portal Enable Version 5.x
4.1.3a, 4.1.4, 4.1.5, 4.2, or 4.2.1

WebSphere Portal Extend Version 4.1.2, WebSphere Portal Extend Version 5.x
4.1.3a, 4.1.4, 4.1.5, 4.2, or 4.2.1

WebSphere Portal Experience Version WebSphere Portal Extend Version 5.x
4.1.2, 4.1.3a, 4.1.4, 4.1.5, 4.2, or 4.2.1

WebSphere Portal Express Version 4.1, WebSphere Portal Express Version 5.x
4.1.5, or 4.2.1

WebSphere Portal Express Plus Version WebSphere Portal Express Plus Version
4.1, 4.1.5, or 4.2.1 5.x




The following are some other constraints:

1. Migration between WebSphere Portal environments across operating
system (for example, Linux to Windows) is not supported.
2. Migration across database servers (for example, DB2 to SQL server)
is not supported.
3. Migration of bookmarks or internal URLs is not supported.
4. Migration of WebSphere V5.x in a cluster is done by migrating data
from the WebSphere Portal V4.x cluster main node to a standalone
WebSphere Portal V5.x, making the V5.x server a main node, and
then creating new clone nodes from it.
5. Content organizer in WebSphere Portal V4.x has been replaced with
Document Manager and WPCP has been replaced with WCM.
Presently there is no migration path for either new component.
6. The WebSphere Member service must be cataloged locally.


Recommended Migration Environment
To migrate WebSphere Portal V4.x to WebSphere Portal V5.x, both systems
should be on separate machines. While it is possible to run both systems on
one machine, the amount of resources required and the complexity of the
con¬guration make it an exercise for a masochist.
The migration should be isolated to WebSphere Portal. Any changes in
LDAP or database version should be made beforehand and veri¬ed with
WebSphere Portal V5.x. If you are changing LDAP servers, you should
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-06 WY009-BenNatan-v1.cls May 9, 2004 9:35




Migrating to WebSphere Portal Version 5.0 107


export the LDAP database information as an LDIF ¬le and re-import it into
your new LDAP databases.
Before you perform your migration, you need to do the following:
1. Apply the 42_421_Multiplatform_Cumulative_Fixes.jar
(found on CD 2) to WebSphere Portal server V4.2.1.
2. Add the following line to the XmlAccessService.properties
¬le in <was5_root>\lib\app\config\services\
:com.ibm.wps.command.xml.groupexport.GroupExportEngine=-//IBM//DTD
GroupExport//EN,
/com/ibm/wps/command/xml/groupexport/GroupExport.dtd.

3. If WPS 4.x uses an external security manager, copy the
<wp5_root>\migration\efixes\ESMMigration.jar ¬le to
<was4_root>\lib\app directory.
4. Apply ¬xes PQ77682_WP50_Migration_iFix and
PQ77683_WP50_iFix to the WP V5.x server.
5. Go to your WebSphere Portal 5.x machine and in the directory
<was5_root>\migration\efixes and copy
WP42X_MP_EXPRESS_Patch.jar ¬le to <was4_root>\lib\app
directory on your WPS 4.2.1 machine. If you have a WPS 4.1
machine, copy WP41X_MP_EXPRESS_Patch.jar ¬le. Extract the
update by typing jar-xvf WP42X MP Express Patch.jar, which will
result in the ¬le 42X_fix.jar. Then extract 42X_fix.jar by
typing jar-xvf 42X ¬le.jar.
Remember that before applying ¬xes, you should stop the servers (Server1
and WebSphere Portal) and restart them after the ¬xes have been applied.
Also verify that both portals are working by accessing them and clicking
on various pages and portlets.


Performing the Migration
You will now ¬nd out how to do a migration using an example migration
environment like the one shown in Figure 6-1. The goal is to migrate Web-
Sphere Portal 4.2.1 using LDAP authentication and store data remotely on
DB2 to a WebSphere Portal 5.0 portal with con¬guration similar to version
4.2.1 except that the database and LDAP versions have been upgraded. The
custom place (Place), the custom pages (Page1 to Page3), and the portlets
(Portlets1, Portlets2, and Portlets3) will be migrated. Assume that, before
the migration, all the servers (sandbox1.rigorconsultants.com to
sandbox6.rigorconsultants.com) have been con¬gured and the
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-06 WY009-BenNatan-v1.cls May 9, 2004 9:35




108 Chapter 6




Figure 6-1 Migration example infrastructure.


WebSphere, Web, database, and LDAP software have been tested. Also
assume that the appropriate tables and user permissions have been created
and set in the remote databases and the user schema and data has exported
from sandbox2.rigorconsultants.com and imported into the LDAP
server on sandbox4.rigorconsultants.com using the LDIF utility. All
servers and software are running during the migration process. Lastly, as-
sume that both WebSphere Portal versions are con¬gured and get requests
through IBM HTTP Server using port 80.


Setting up the Migration Property Values
Much of the migration process is automated using de¬ned automated
tasks. To run these tasks, you have to set the values in the migration prop-
erty ¬les. You will ¬nd the migration property ¬les on the WebSphere
Portal 5 server (sandbox5.rigorconsultants.com) in the directory
<wp5_root>\migration. But before you modify the ¬les, copy the Web-
Sphere Portal Server wpsconfig.properties ¬les on sandbox1
.rigorconsultants.com to <wp5_root>\migration on sandbox5
.rigorconsultants.com. If you are migrating WebSphere Portal ver-
sion 4.1.2, then you must add the WPFamilyNameKey to the wps.proper-
ties ¬le. WPFamilyName key identi¬es the WebSphere Portal packaging.
For instance, if you installed WebSphere Portal Enable then you would set
WPFamilyName=enable.
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-06 WY009-BenNatan-v1.cls May 9, 2004 9:35




Migrating to WebSphere Portal Version 5.0 109

Table 6-2 Core Migration Properties
PROPERTY VALUE DESCRIPTION
WpsHostName4x Fully quali¬ed host name of the
sandbox1.
WebSphere Portal V4.2.1
rigorconsultants.com
machine; sandbox1
.rigorconsultants
.com

WpsPort4x 80 Port number to which
WebSphere Portal V4.2.1
receives requests

WpsContextRoot4x wps Base URI for WebSphere Portal
V4.2.1

WpsDefaultHome4x portal Default home for WebSphere
Portal V4.2.1

PortalAdminId4x wpsadmin WebSphere Portal V4.2.1
administrator ID

PortalAdminPwd4x wpsadmin WebSphere Portal V4.2.1
administrator password

wpsinstallLocation4x Root directory of WebSphere
C:/WebSphere/
Portal V4.x
PortalServer

includePlaces Place1 Comma-separated names of the
custom places you want to
migrate

includePages Page1, Page2, Page3 Comma-separated names of the
custom pages you want to
migrate

includeApps Portlet1, Portlet2, Comma-separated names of the
Portlet3 portlet applications you want to
migrate




The ¬rst migration property ¬le to modify is mig_core.properties,
which speci¬es the core migration properties. Table 6-2 lists the properties
we set for our example.


Migrating Access Controls
Now that your migration environment is all set up, the ¬rst step is to convert
the access control. This is signi¬cant migration since access controls have
changed from permission base in WebSphere Portal Version 4 to role-based
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-06 WY009-BenNatan-v1.cls May 9, 2004 9:35




110 Chapter 6

Table 6-3 Mapping of Permissions to Roles
V4.X PERMISSIONS V5.0 ROLES
View 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 or
Security Administrator + Editor

Manage + Delegate Administrator

View + Edit + Manage Manager

View + Edit + Delegate Security Administrator + Privileged User or
Security Administrator + Editor

View + Manage + Delegate Administrator

View + Edit + Manage + Delegate Administrator

Create Not Applicable in WP 5.0




access control (more on this in Chapter 10). Table 6-3 shows the migration
process mapping of permissions to roles.
Inheritance blocks will be created by the migration process for all roles

<<

. 21
( 87 .)



>>