+

Search Tips   |   Advanced Search

Portal, V6.1

 

Migrate the security configuration

To migrate the security configuration to the deployment manager, you run the migrate-wmm-to-vmm task.

Complete this part of the migration process after you have migrated the product configuration, federated the primary node, created the cluster and configured LDAP (if LDAP is configured to match the LDAP server of the node).

  1. Ensure that the deployment manager host.name and port are specified in the wkplc.properties file. In the next step, you run the wp-prep-vmm-db-secured-environment on the primary node. Sample instructions are provided for Windows. For detailed instructions for your platform...

    1. If the portal uses a property extension database, see the topic on creating a property extension database based on your operating system (for example Configuring a property extension database on Linux).

    2. If the portal uses a database user registry, see the topic on adding a database user registry based on your operating system

      For example...

      Adding a database user registry on Linux).

    Limitation: The WAS UserManagement component (VMM) requires used database libraries in the WAS server classpath (appserver/lib). This limitation will be addressed with PK66195. In the meantime if you want to use the VMM database functions such as Property Extension or database user registry, copy the following library files into the appserver/lib directory prior to starting the server:

    • DB2 Type 2 driver: db2java.zip

    • DB2 Type 4 driver: db2jcc.jar;db2jcc_license_cu.jar

    • DB2 for z/OS Type 2 driver: db2java.zip

    • DB2 for z/OS Type 4 driver: db2jcc.jar;db2jcc_license_cisuz.jar;db2jcc_javax.jar

    • Oracle: ojdbc14.jar

  2. Perform the following steps in a clustered environment:

    1. Run the ConfigEngine.bat wp-prep-vmm-db-secured-environment -DWasPassword=wpsadmin -DDbDomain=la|federated.db -Ddb_type.DmgrDbLibrary=local path of the database jars on the Deployment Manager -DDmgrNodeName=dmgr_node from the WP_PROFILE\ConfigEngine directory to create the local Deployment Manager WebSphere variable used to access the database jars.

      Where DbDomain is either la or federated.db depending on whether you are using a property extension database (la) or a database user registry (federated.db). The db_type in db_type.DmgrDbLibrary should be set to the type of database you are using, for example db2. The local path of the database jars on the Deployment Manager should be one of the following options:

      • DB2 Type 2 driver: db2java.zip

      • DB2 Type 4 driver: db2jcc.jar;db2jcc_license_cu.jar

      • DB2 for z/OS Type 2 driver: db2java.zip

      • DB2 for z/OS Type 4 driver: db2jcc.jar;db2jcc_license_cisuz.jar;db2jcc_javax.jar

      • Oracle: ojdbc14.jar

    2. Run the following task for EACH WebSphere Portal node that participates in the cluster to set up access to the database drivers; if multiple nodes share the same database library path you can submit a comma separated list of node names:

      This task does not need to be executed from the node identified in the VmmNodeName parameter.

      1. Set the property value for federated.db.DbType if using a database user registry or if the cell is migrated from a previous version and set the property value for la.DbType if using a property extension database in the wkplc.properties file.

      2. Run the ConfigEngine.bat wp-node-prep-vmm-db-secured-environment -DWasPassword=wpsadmin -DDbDomain=la|federated.db -DVmmNodeName=node -Ddb_type.NodeDbLibrary/path/to/DB/jars from the WP_PROFILE\ConfigEngine directory on each node to create the variable used to access the VMM database jars.

        Where DbDomain is either la or federated.db depending on whether you are using a property extension database (la) or a database user registry (federated.db). VmmNodeName is a list of one or more WebSphere Portal nodes names in the cell which share the same database driver paths. The db_type in db_type.NodeDbLibrary should be set to the type of database you are using, for example db2. The local full path of the database jars should be one of the following options:

        • DB2 Type 2 driver: db2java.zip

        • DB2 Type 4 driver: db2jcc.jar;db2jcc_license_cu.jar

        • DB2 for z/OS Type 2 driver: db2java.zip

        • DB2 for z/OS Type 4 driver: db2jcc.jar;db2jcc_license_cisuz.jar;db2jcc_javax.jar

        • Oracle: ojdbc14.jar

    3. Run ConfigEngine.bat wp-connect-database-vmm -DWasPassword=wpsadmin -DDbDomain=la|federated.db task to connect to the VMM database, where DbDomain is either la or federated.db depending on whether you are using a property extension database (la) or a database user registry (federated.db).

    4. Stop and restart the deployment manager, the node agent(s), server1, and the WebSphere_Portal servers.

  3. Copy the backup directory that the portal-post-upgrade used, and move the copy to the deployment manager, under the same path as on the portal node.

    You must copy the same, exact backup directory that the portal-post-upgrade used. You cannot run portal-post-upgrade to create a new backup and then use the new backup copy.

  4. Disable security on the deployment manager.

  5. Restart the deployment manager.

  6. Change to the portal_server_root/migration directory on the primary node. If using i5/OS you can run the script from the UserData directory: portal_server_root/migration.

  7. Run the migrate-wmm-to-vmm task as follows:

    Operating System Command
    Windows WPmigrate.bat migrate-wmm-to-vmm -DbackupDirectory=dirname -DPrevPortalAdminId=adminid -DPrevPortalAdminPwd=adminpassword -DWasUserid=wasid -DWasPassword=waspassword
    UNIX ./WPmigrate.sh migrate-wmm-to-vmm -DbackupDirectory=dirname -DPrevPortalAdminId=adminid -DPrevPortalAdminPwd=adminpassword -DWasUserid=wasid -DWasPassword=waspassword
    i5/OS WPmigrate.sh migrate-wmm-to-vmm -DbackupDirectory=dirname -DPrevPortalAdminId=adminid -DPrevPortalAdminPwd=adminpassword -DWasUserid=wasid -DWasPassword=waspassword

    where:

    backupDirectory

    The copy of the backup directory that the portal-post-upgrade used when it imported data from the earlier portal server.

    PrevPortalAdminId

    Administrator ID for the earlier portal server.

    PrevPortalAdminPwd

    Administrator password for the earlier portal server.

    WasUserid

    Administrator ID for WAS that is used by the new portal server.

    The administrator ID that the new portal installation uses must match the administrator ID that the earlier portal version uses.

    WasPassword

    Password for the WAS administrator ID.

    The administrator password for the new portal installation must match the administrator password used in the earlier portal version.

    If the task fails, correct the problem and then rerun the task.

  8. Change to the WP_PROFILE/ConfigEngine directory and then run the following task to replace the old WebSphere Portal administrative user with the new user:

    Operating System Command
    Windows ConfigEngine.bat wp-change-portal-admin-user -DnewAdminId=newadminid –DnewAdminPw=newpassword -DnewAdminGroupId=newadmingroup -Dskip.ldap.validation=true
    UNIX ./ConfigEngine.sh wp-change-portal-admin-user -DnewAdminId=newadminid –DnewAdminPw=newpassword -DnewAdminGroupId=newadmingroup -Dskip.ldap.validation=true
    i5/OS ConfigEngine.sh wp-change-portal-admin-user -DnewAdminId=newadminid –DnewAdminPw=newpassword -DnewAdminGroupId=newadmingroup -Dskip.ldap.validation=true

  9. Restart the deployment manager, node agents, and servers.

    To avoid problems restarting (caused by the node being out of synch with the new security settings), stop and restart the node agents and servers from the node (at the command line), rather than from the deployment manager console.

 

Parent topic

Migrating WebSphere Portal