Configure WAS after migration

 

Before you begin

Installation automatically configures IBM WebSphere Application Server, V6 and all other bundled products. There is no need for additional configuration if you did not migrate from an earlier version.

 

Overview

If you migrate an installation of WebSphere Application Server, V4.0.x, there are some items to review before considering your environment fully configured.

 

Procedure

  1. Examine any LTPA security settings you might have used, and apply the settings in the WebSphere Application Server security settings.

    Global security that uses LTPA authentication in V4.0.x is migrated to the base WAS product and to the Network Deployment product. However, although global security was enabled in V4.0.x, it is disabled during migration to V6.

    If you add this node later to an IBM WebSphere Application Server Network Deployment, V6 configuration, one can enable and use the LTPA configuration. Use the administrative console to generate keys for the migrated LTPA authentication mechanism. After generating the keys, you can enable global security.

    Global security that uses localos authentication mechanisms in V4.0.x is migrated to the Network Deployment product. However, although global security was enabled in V4.0.x, it is disabled during migration to V6. The Network Deployment product does not support the SWAM authentication mechanism. Migration sets the authentication mechanism in V6 to LTPA. Use the administrative console to generate keys for the migrated LTPA authentication mechanism. After generating the keys, one can enable global security.

  2. Check the WASPostUpgrade.log file in the logs directory, for details about JSP 0.91 objects that the migration tools do not migrate.

    V6 does not support JSP 0.91 objects. The migration tools do not migrate JSP objects configured to run as JSP 0.91 objects. The migration tools do, however, recognize the objects in the output and log them. Version 6 runs JSP 1.0 and 1.1 objects as JSP 1.2 objects, which is its only supported level.

  3. Be aware that V4.0.x Server Groups are converted to V6 clusters.

    V4.0.x server groups have been dramatically redefined in V6 as clusters and cluster members. Application servers are the only objects supported as models and cluster members in V6.

  4. Identify and use the migration tools to migrate non-migrated nodes in V4.0.x repositories that have multiple nodes.

    A Version 4.0.x repository can contain more than one node name and its associated children. The WASPostUpgrade tool processes only those objects and children that match the migrating node. This determination is made by checking the names of nodes in configuration files with fully qualified and non-qualified network names of the migrating machine.

  5. Update J2EE resources in client JAR files to the new resource format with the ClientUpgrade tool.

    J2EE applications might exist on the client, if the client has client JAR files with J2EE resources.

  6. To migrate a V4.0.x or V5.x XML application to the V6 level, recompile it.

  7. Configure WAS to use a database. For example, one can configure WebSphere Application Server to use DB2.

  8. Review your Java virtual machine settings to verify that you are using a heap size of at least 50 for improved startup performance.

    If you have used a smaller heap size in the past, use the default heap size, which is now 50.

 

Result

Now you are finished with pre-test configuration. You might have to fine tune your WAS environment as you test it. Test all redeployed applications before moving them into production.

 

What to do next

Return to Installing WebSphere Application Server to continue.

 

See also


Important information about XML4J
Configuring WAS for DB2

 

See Also


Configuration mapping during migration

 

Related Tasks


Migrating welcome page