Various configurations are mapped during product-configuration migration.
Migration always involves migrating a single profile to another single profile on the same machine or a separate machine. Go to the information center for the WebSphere Application Server Network Deployment product to learn how the migration tools map models, clones, server groups, clusters, and Lightweight Third Party Authentication (LTPA) security settings.
Many migration scenarios are possible. The migration tools map objects and attributes existing in the version from which you are migrating to the corresponding objects and attributes in the Version 6.1 environment.
The migration tools map a non-default value directly into the Version 6.1 environment.
If the -portBlock parameter is specified during the call to WASPostUpgrade, however, a new port value is given to each application server that is migrated to Version 6.1.
The migration tools convert appropriate command-line parameters to Java virtual machine (JVM) settings in the server process definition. Most settings are mapped directly. Some settings are not migrated because their roles in the WebSphere Application Server Version 6.1 configuration do not exist, have different meanings, or have different scopes.
It is best that you reinstall the resource into the new WebSphere Application Server directory. Whatever you choose to do, the final step is to reset the reference to the new location of the application.
If the old resource that the generic server was managing is not installed under the old WebSphere Application Server installation, nothing further is required.
Migration copies files from prior version directories into the WebSphere Application Server Version 6.1 configuration.
Migration does not overlay property files.
RARs that are referenced by J2C resources are migrated if those RARs are in the old WebSphere Application Server installation. In this case, the RARs are copied over to the corresponding location in the new WebSphere Application Server installation. Relational Resource Adapter RARs will not be migrated.
No migration of samples from previous versions is available. There are equivalent WebSphere Application Server Version 6.1 samples that you can install.
Java 2 security is enabled by default when you enable security in WebSphere Application Server Version 6.1. Java 2 security requires you to grant security permissions explicitly.
There are several techniques that you can use to define different levels of Java 2 security in Version 6.1. One is to create a was.policy file as part of the application to enable all security permissions. The migration tools call the wsadmin command to add an existing was.policy file in the Version 6.1 properties directory to enterprise applications as they are being migrated.
This is the default.
For example, existing keyfiles and trustfiles are moved out of the SSLConfig repertoire and new keystore and truststore objects are created.
The location for these directories is typically the logs directory under the WebSphere Application Server profile directory. For WebSphere Application Server Version 6.1, the default location for the stdin, stdout, and stderr files is the logs directory located under the WebSphere Application Server profile directory—for example, the logs directory for the default profile is /QIBM/UserData/WebSphere/AppServer/V61/Base/profiles/default/logs.
The migration tools attempt to migrate existing passivation and working directories. Otherwise, appropriate Version 6.1 defaults are used.
In a coexistence scenario, using common directories between versions can create problems.
The migration tools migrate all ports. The tools log a port-conflict warning if a port is already defined in the configuration. You must resolve any port conflicts before you can run servers at the same time.
This results in your transport ports being brought over as they are. This is the default.
This results in the transport ports being converted to the implementation of channels and chains. From an external application usage standpoint, they will still act the same; but they have been moved to the TransportChannelService.
For more information on the WASPostUpgrade command, see WASPostUpgrade command.
You must manually add virtual host alias entries for each port.
The specification level of the Java 2 Platform, Enterprise Edition (J2EE) implemented in WebSphere Application Server Version 6.0.x required behavior changes in the Web container for setting the content type. If a default servlet writer does not set the content type, not only does the Web container no longer default to it but the Web container returns the call as "null." This situation might cause some browsers to display resulting Web container tags incorrectly. To prevent this problem from occurring, migration sets the autoResponseEncoding IBM extension to "true" for Web modules as it migrates enterprise applications.