Migrate the remaining access control configuration

Migrate the remaining access control configuration

+

Search Tips | Advanced Search

Migrate permissions on All Authenticated Portal Users and All Portal User Groups group
Migrate permissions on WebSphere Portal 5.1.x administrative resources
Migrate the Member Manager database the DB2 command line
Migrate credential vault data
Delete the previous WebSphere Portal resource entries from Tivoli Access Manager

Perform the following procedures after completing the steps described in the Using command line scripts section:

Migrating permissions on All Authenticated Portal Users and All Portal User Groups group
Permissions on User Groups allows principals to perform the following tasks:

Edit group information

Change group membership

Change the access rights of the group members

Follow this step to migrate permissions on user groups:

On the current WebSphere Portal 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 The XML configuration interface. To assign the principals to roles on the appropriate user groups using the Resource Permissions portlet:

Log in to portal using an administrator account.

Open the Resource permissions portlet.

Select the Resource type user group.

Select the All Authenticated Portal Users option and analyze the existing role assignments on that user group.

Use the Resource permissions portlet to create the same role assignments on the new portal.

Repeat these steps for All Portal User Groups.

Migrating permissions on WebSphere Portal 5.1.x administrative resources

5.1.x Administrative Page 5.1.x Administration Portlet title
Portal User Interface

Manage Pages
Themes and Skins
Manage Pages
Themes and Skins
Portlet Management

Web Modules
Applications
Portlets
Web Services
Web Clipping

Manage Web Modules
Manage Applications
Manage Portlets
Web Service Configuration
Web Clipping Editor
Access

Users and Groups
Resource Permissions
User and Group Permissions
Credential Vault
Manage Users and Groups
Resource Permissions
User and Group Permissions
Credential Vault
Portal Settings

Global Settings
URL Mapping
Custom Unique Names
Supported Markups
Supported Clients
Search Administration
Import XML
Global Settings
URL Mapping portlet
Manage Custom Unique Names
Manage Markups
Manage Clients
Manage Search Collection
Import XML
Portal Analysis

Frequent Users

Enable Tracing

Frequent Users
Enable Tracing
Portal Content

Manage Document Libraries

Manage Document Libraries
Virtual Portals

Manage Virtual Portals

Virtual Portal Manager
Page Customizer

Content Layout
Appearance
Locks
Wires

Edit Layout
Appearance portlet
Page Locks
Portlet Wiring Tool
Page properties Page properties
Organize Favorites Organize Favorites
Login Login portlet
Edit My Profile Edit My Profile

Migrating the Member Manager database using the command line

To migrate a DB2 Member Manager database:

Connect to the previous WebSphere Portal database using the following command:
db2 connect to DB user db_user using db_password

Use the following command to export the Member Manager tables from the previous database:
db2 export to filename.ixf of ixf SELECT * FROM db_user.table

filename is the name of the ixf file.
db_user is the name of the database user. table is the name of one of the following Member Manager tables:

WMMDBABVAL WMMDBACMPV WMMDBACOMP
WMMDBACVAL
WMMDBADTYP
WMMDBADVAL
WMMDBAIVAL
WMMDBAMTYP
WMMDBARVAL
WMMDBASVAL
WMMDBATR
WMMDBATVAL
WMMDBKEYS
WMMDBMBR
WMMGRPMBR
WMMKEYS
WMMLAACMPV
WMMLAACOMP
WMMLAACVAL
WMMLAADTYP
WMMLAADVAL
WMMLAAIVAL
WMMLAAMTYP
WMMLAARVAL
WMMLAASVAL
WMMLAATR
WMMLAATVAL
WMMLAEXTID
WMMLAKEYS
WMMLAMBR
WMMMBR
WMMMBRREL
WMMUSERREG

See EXPORT Command for additional information about exporting data from a database.

Optional: Use the following command to clean all tables from the current WebSphere Portal database if there is no Member Manager data on the database:
db2 DELETE FROM db_user.table table

db_user is the name of the database user.
table is the name of one of the above listed Member Manager tables.

Use the following command to export the Member Manager tables from the previous database:
db2 import from filename.ixf of ixf INSERT INTO db_user.table
filename is the name of the ixf file.
Each filename should match the ones that you exported for the same table.
db_user is the name of the database user. table is the name of one of the following Member Manager tables:

WMMDBABVAL
WMMDBACMPV
WMMDBACOMP
WMMDBACVAL
WMMDBADTYP
WMMDBADVAL
WMMDBAIVAL
WMMDBAMTYP
WMMDBARVAL
WMMDBASVAL
WMMDBATR
WMMDBATVAL
WMMDBKEYS
WMMDBMBR
WMMGRPMBR
WMMKEYS
WMMLAACMPV
WMMLAACOMP
WMMLAACVAL
WMMLAADTYP
WMMLAADVAL
WMMLAAIVAL
WMMLAAMTYP
WMMLAARVAL
WMMLAASVAL
WMMLAATR
WMMLAATVAL
WMMLAEXTID
WMMLAKEYS
WMMLAMBR
WMMMBR
WMMMBRREL
WMMUSERREG

See IMPORT Command for additional information about exporting data from a database.

To migrate a Cloudscape Member Manager database:

Copy the Cloudscape database from the previous WebSphere Portal server to a location on the same machine as the current server.
If the previous server is on the same machine as the current server, you do not need to do this step; however, stop the previous server if it is active.

Edit the wpconfig_sourceDb.properties file to point to the previous server's Cloudscape database that you copied to the current server, for example:

source.wmm.DbUrl=jdbc:db2j:C:\\migrationcloudscape\\cloudscape\\wpsdb
source.wmm.DbUrl=jdbc:db2j:/opt/migrationcloudscape/cloudscape/wpsdb
source.wmm.DbUrl=jdbc:db2j:/opt/migrationcloudscape/cloudscape/wpsdb

Run the database-transfer-wmm task to migrate/transfer the Member Manager database from the previous server to the current server, for example:

C:\Program Files\IBM \WebSphere\PortalServer\config\WPSconfig.bat database-transfer-wmm

/opt/IBM /WebSphere/PortalServer/config/WPSconfig.sh database-transfer-wmm

/opt/IBM /WebSphere/PortalServer/config/WPSconfig.sh database-transfer-wmm

Migrating credential vault data
Existing credential secrets must be handled differently depending on the environment:

WebSphere Portal Default Vault: complete the following procedure if you want to migrate existing credential secrets to the current WebSphere Portal system.

Third-party vault implementation (Tivoli Access Manager ): No additional steps are required. Existing credential secrets can be used in the current WebSphere Portal system.

If you decide not to migrate existing credential secrets, users must provide their credential information the first time a Version 6.0 portlet attempts to use the data.
Migrating the credential secrets involves moving two tables, VAULT_DATA and VAULT_RESOURCES from the previous WebSphere Portal database to the current WebSphere Portal database. The table definition has not changed in WebSphere Portal Version 6.0, so the data does not need to be changed. Because the database is now split in different database domains, the data also has to be split. Use an import and export utility provided by the database server to migrate the data.
The following example explains how to import and export the tables when DB2 is the database server. Use this example as a general guide for the environment. Perform this procedure before any users have accessed the current WebSphere Portal system and potentially added additional data to the system.

Export the tables from the previous WebSphere Portal database.

On the previous WebSphere Portal database server, start the DB2 Command Line Processor (CLP) (Windows) or the DB2 shell (Unix).

Enter the following commands (type each section of text on one line):
connect to wpsdb user dbuser using dbuserpw export to C:/temp/vault.res.customization.wp5.ixf of ixf messages C:/temp/vault.res.customization.wp5.msgtxt SELECT DISTINCT VAULT_RESOURCES.RESOURCE_NAME FROM VAULT_RESOURCES, CRED_SLOT, CRED_SEGMENT WHERE VAULT_RESOURCES.RESOURCE_NAME = CRED_SLOT.RESOURCE_NAME AND CRED_SLOT.SEGMENT_OID = CRED_SEGMENT.OID AND CRED_SEGMENT.USER_MAPPED > 0 export to C:/temp/vault.res.release.wp5.ixf of ixf messages C:/temp/vault.res.release.wp5.msgtxt SELECT DISTINCT VAULT_RESOURCES.RESOURCE_NAME FROM VAULT_RESOURCES, CRED_SLOT, CRED_SEGMENT WHERE VAULT_RESOURCES.RESOURCE_NAME = CRED_SLOT.RESOURCE_NAME AND CRED_SLOT.SEGMENT_OID = CRED_SEGMENT.OID AND CRED_SEGMENT.USER_MAPPED = 0 export to C:/temp/vault.data.customization.wp5.ixf of ixf messages C:/temp/vault.data.customization.wp5.msgtxt SELECT VAULT_DATA.RESOURCE_NAME, VAULT_DATA.USER_DN, VAULT_DATA.USERID, VAULT_DATA.PWD, VAULT_DATA.BINARY_DATA FROM CRED_SEGMENT, CRED_SLOT, VAULT_DATA WHERE VAULT_DATA.RESOURCE_NAME = CRED_SLOT.RESOURCE_NAME AND CRED_SLOT.SEGMENT_OID = CRED_SEGMENT.OID AND CRED_SEGMENT.USER_MAPPED > 0 export to C:/temp/vault.data.release.wp5.ixf of ixf messages C:/temp/vault.data.release.wp5.msgtxt SELECT VAULT_DATA.RESOURCE_NAME, VAULT_DATA.USER_DN, VAULT_DATA.USERID, VAULT_DATA.PWD, VAULT_DATA.BINARY_DATA FROM CRED_SEGMENT, CRED_SLOT, VAULT_DATA WHERE VAULT_DATA.RESOURCE_NAME = CRED_SLOT.RESOURCE_NAME AND CRED_SLOT.SEGMENT_OID = CRED_SEGMENT.OID AND CRED_SEGMENT.USER_MAPPED = 0 disconnect wpsdb

...where wpsdb is the database name of the previous WebSphere Portal database, dbuser is the database administrator user ID, and dbuserpw is the password for this user ID.

Import the data in the tables to the current WebSphere Portal database.

If the current WebSphere Portal database server is not on the same machine as the previous WebSphere Portal database server, copy the exported ixf files to the current WebSphere Portal database server machine.

On the current WebSphere Portal database server, start the DB2 Command Line Processor (CLP) (Windows) or DB2 shell (Unix).

Enter the following commands (type each section of text on one line):
connect to wpsdb user dbuser using dbuserpw import from C:/temp/vault.res.customization.wp5.ixf of ixf modified by indexschema=customization messages C:/temp/vault.res.customization.wp6.msgtxt INSERT INTO CUSTOMIZATION.VAULT_RESOURCES import from C:/temp/vault.res.release.wp5.ixf of ixf modified by indexschema=release messages C:/temp/vault.res.release.wp6.msgtxt INSERT INTO RELEASE.VAULT_RESOURCES import from C:/temp/vault.data.customization.wp5.ixf of ixf modified by indexschema=customization messages C:/temp/vault.data.customization.wp6.msgtxt INSERT INTO CUSTOMIZATION.VAULT_DATA import from C:/temp/vault.data.release.wp5.ixf of ixf modified by indexschema=release messages C:/temp/vault.data.release.wp6.msgtxt INSERT INTO RELEASE.VAULT_DATA

...where wpsdb is the database name of the current WebSphere Portal database, dbuser is the database administrator user ID, and dbuserpw is the password for this user ID.
Under certain conditions, the import into the VAULT_RESOURCES and VAULT_DATA tables 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. The same is true for the VAULT_DATA table. Credentials that are already stored in the table must not be redefined. 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 "SCHEMA_NAME.VAULT_RESOURCES or VAULT_DATA" from having duplicate rows for those columns. SQLSTATE=23505

Enter the following commands:
select USER_DN, RESOURCE_NAME from RELEASE.VAULT_DATA vd1 where EXISTS (SELECT * FROM RELEASE.VAULT_DATA vd2 WHERE LOWER(vd1.USER_DN) = LOWER(vd2.USER_DN) and vd1.RESOURCE_NAME = vd2.RESOURCE_NAME and vd1.USER_DN < vd2.USER_DN)

select USER_DN, RESOURCE_NAME from CUSTOMIZATION.VAULT_DATA vd1 where EXISTS (SELECT * FROM CUSTOMIZATION.VAULT_DATA vd2 WHERE LOWER(vd1.USER_DN) = LOWER(vd2.USER_DN) and vd1.RESOURCE_NAME = vd2.RESOURCE_NAME and vd1.USER_DN < vd2.USER_DN)
Any value returned by these commands shows a potential user DN conflict where a conversion to lower case would not complete successfully. Those entries will have to be reviewed for its matching user DN and the duplicate rows will have to be removed manually. Rerun the above commands until no values are returned.If the above commands do not return any values, enter the following commands to update the user DN fields to the lower case string:
UPDATE RELEASE.VAULT_DATA SET USER_DN = LOWER(USER_DN) UPDATE CUSTOMIZATION.VAULT_DATA SET USER_DN = LOWER(USER_DN)

Enter the following command:
disconnect wpsdb

...where wpsdb is the database name of the current WebSphere Portal database.

Verify that the system.dn value in VaultService for the current version of WebSphere Portal 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 credential secrets for shared slots.

Delete the previous WebSphere Portal resource entries from Tivoli Access Manager
If you used Tivoli Access Manager with the previous WebSphere Portal version, 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 the previous WebSphere Portal version. This step is not necessary if you are using different Tivoli Access Manager systems for the previous WebSphere Portal version and the current WebSphere Portal version.
Do not perform this step until you are finished using the older version of WebSphere Portal.

On the previous WebSphere Portal system, open the externalaccesscontrolservice.properties file and determine the value for pd_root.

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 the previous WebSphere Portal version resources: pdadmin> delete objectspaces pd_root*.

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 the previous WebSphere Portal version resources: pdadmin> acl delete acl_name.

Related information

Migrating WebSphere Portal Configurations

Troubleshooting migration

Parent topic:
Migrating

5.1.x Administrative Page	5.1.x Administration Portlet title
Portal User Interface Manage Pages Themes and Skins	Manage Pages Themes and Skins
Portlet Management Web Modules Applications Portlets Web Services Web Clipping	Manage Web Modules Manage Applications Manage Portlets Web Service Configuration Web Clipping Editor
Access Users and Groups Resource Permissions User and Group Permissions Credential Vault	Manage Users and Groups Resource Permissions User and Group Permissions Credential Vault
Portal Settings Global Settings URL Mapping Custom Unique Names Supported Markups Supported Clients Search Administration Import XML	Global Settings URL Mapping portlet Manage Custom Unique Names Manage Markups Manage Clients Manage Search Collection Import XML
Portal Analysis Frequent Users Enable Tracing	Frequent Users Enable Tracing
Portal Content Manage Document Libraries	Manage Document Libraries
Virtual Portals Manage Virtual Portals	Virtual Portal Manager
Page Customizer Content Layout Appearance Locks Wires	Edit Layout Appearance portlet Page Locks Portlet Wiring Tool
Page properties	Page properties
Organize Favorites	Organize Favorites
Login	Login portlet
Edit My Profile	Edit My Profile