Prepare the new environment for migration

Prior to migration from WebSphere Portal v6.0.1.x, complete the steps outlined here to prepare the new environment.

Check that you have access to an administrative user ID and password for both WebSphere Portal and IBM WebSphere Application Server. If you are using a WMM-based configuration on the source server, either as a database repository or a federated LDAP directory, no additional security enablement is required on the target server. The migration process will migrate the WMM configuration to VMM automatically. When migrating a WMM configuration, the administrator ID and password for WAS on the target server must match the values used on the source server. This does not mean that the same security be configured on both servers but only that the same adminstrator IDs and passwords must be set before attempting the migration.

  1. Install WebSphere Portal v7.0, then verify that you can stop and start the portal and log in to the default welcome page.

    When installing the new portal, use the Full installation option. Using the Base installation option can cause the migration process to fail. If you are running IBM WebSphere Portal using IBM DB2 Universal Databaseā„¢ for i V5R4, apply the fix for APAR SE34114 to the OS of the database server to ensure successful migration. To download the fix, you can use either the Send PTF Order (SNDPTFORD) command or the central site distribution process. For details, see the i information center.

  2. Configure the target portal to use the same security as the earlier source portal:

    1. If the source portal uses a standalone LDAP registry, enable a standalone LDAP registry on the target portal and ensure that the target portal's registry uses the same users and groups (with the same extid) as the source portal's registry.

    2. If the source portal is configured to use an external security manager and has resources that are under the control of the external security manager, configure the target portal to use that external security manager. Alternatively, you can bring the externalized resources back under WebSphere Portal control in the source portal environment prior to migration, and then configure the target portal to use the external security manager after migration is complete.

        If the portal uses eTrust SiteMinder to perform authorization, verify that the SiteMinderLoginModule custom property is defined because any XML Configuration Interface execution can be affected. For instructions on modifying the SiteMinderLoginModule custom property, see the topic on Configuring eTrust SiteMinder to perform authorization for WebSphere Portal.

    3. Ensure that the target portal uses the same WAS and WebSphere Portal administrator user names and passwords for login as the source portal.

        If you are using a stand-alone LDAP user registry, this happens automatically when you configure security on the target portal.

        If you are using a WMM-based user registry, you might need to take additional steps on the 7.0 server to ensure that the portal is configured to use the same login IDs as the 6.0 portal. The 7.0 installation program does not allow certain special characters and by default sets the WAS and WebSphere Portal administrator user name and password to the same values. If the 6.0 portal administrator user ID and password contain characters that cannot be used in the 7.0 installation program or if the logon IDs for the portal administrator and WAS administrator are different, update the 7.0 portal to use matching values after you install and before you attempt to migrate. Refer to Update user ID and passwords for details.

  3. Copy and activate required database library files as noted below.

      Limitation: The WAS UserManagement component (VMM) requires access to the following database libraries to use the VMM database functions such as Property Extension and database user registry, however, if the Portal is using the DB2 Type 2 driver, due to functional limitations, VMM must use the DB2 Type 4 driver; see Configure a JDBC provider and datasource for federated repositories for additional information:

      For all supported OSs except i:

        DB2Type 2 driver: db2java.zip
        DB2 Type 4 driver: db2jcc.jar;db2jcc_license_cu.jar
        DB2 for z/OSType 2 driver: db2java.zip
        DB2 for z/OS Type 4 driver: db2jcc.jar;db2jcc_license_cisuz.jar;db2jcc_javax.jar
        Oracle: ojdbc14.jar
        SQL Server JDBC driver provided by Microsoft: sqljdbc.jar
        SQL Server JDBC driver provided by DataDirect: sqlserver.jar;base.jar;util.jar

      (Oracle only): During the migration process, do not use Oracle JDBC driver version 11.2.0.2.0, because the database migration fails. If you use driver version 11.2.0.2.0, the wrong meta data information for columns created with datatype INTEGER is returned. As an alternative to driver 11.2.0.2.0, you can use driver version 11.2.0.1.0 during the migration process. Once you have migrated environment, you can change the driver version from 11.2.0.1.0 to 11.2.0.2.0

      For i:

        IBM DB2 for i Type 2 driver: /QIBM/ProdData/Java400/ext/db2_classes.jar
        IBM DB2 for i Type 4 driver: /QIBM/ProdData/HTTP/Public/jt400/lib/jt400.jar

      Depending on the driver that you are using, copy the required files into the WAS_HOME/lib directory. Then stop and restart the server1 and WebSphere_Portal servers to load the library files.

  4. Make sure that the new portal's certificate for HTTP SSL communication matches the old server's certificate. To do this, you can retrieve the appropriate CA certificate from the previous server. For information about how to do this, refer to the topic about Retrieving signers using the retrieveSigners utility at the client in the WAS information center.

  5. If you plan to migrate any virtual portals that exist in the source portal, use the create-virtual-portal ConfigEngine task to recreate each virtual portal with the corresponding name and URL context in the target portal.

      For information on the create-virtual-portal task, see Virtual portals reference.

  6. If you plan to migrate remote portlets (portlets that are provided as WSRP services), ensure that the WSRP Producer is available before you run the portal-post-upgrade task to import content to the new portal.

  7. Migration can take awhile and interruptions to HTTP connection during the export process or import process can cause migration to fail. To avoid this problem, change HTTP server timeout to an unlimited length while performing migration.

      Refer to HTTP server documentation for information on how to change the timeout value.

  8. To ensure that timeouts do not occur during SOAP connections during the migration process, it is recommended that you increase the SOAP timeout value as follows:

    1. Log in to the WAS administrative console.

    2. Click Servers -> Applications servers -> WebSphere_Portal -> Server Infrastructure -> Administration -> Administration Services -> JMX Connectors -> SOAPConnector -> Custom properties.

    3. Select the requestTimeout property and increase the value from 600 to 6000.

    4. Save the configuration changes, and then restart the server.

  9. Back up the databases and the entire directory structure for the new portal server installation prior to running the portal-post-upgrade task.


Parent

Prepare for migration from v6.0.1.x
Use WSRP services


Related tasks


Update user ID and passwords
Manage user data
Configure eTrust SiteMinder to perform authorization
Virtual portals reference

IBM i5 information center

  Sep 1, 2010 12:36:30 PM


+

Search Tips   |   Advanced Search