MigrationGuide en
MigrationGuide en
MigrationGuide en
0
®
Introduction
WebSphere Application Server Version 7.0 can coexist with Version 5.1.x and
Version 6.x. Depending on the previous version of WebSphere Application Server,
port conflicts might exist that must be resolved. Read “Coexistence support” on
page 99 and Chapter 7, “Configuring ports,” on page 107 for more information.
The Migration wizard provides a graphical user interface to the migration tools.
The Migration wizard can call the migration tools, or you can run them directly.
Read “Using the Migration wizard to migrate product configurations” on page 27
for more information.
Important reference articles for this migration include the following articles:
v Creating profiles using the graphical user interface
v manageprofiles command.
v Migrating servers from multi-broker replication domains to data replication
domains
v Comparison of multi-broker versus data replication domains
v Migrating to Version 3 of the UDDI registry
v Migrating a complete gateway configuration
v Migrating from Version 5.1 embedded messaging
v Managing WebSphere Application Server Version 5 JMS use of WebSphere
Application Server Version 7.0 messaging resources
If you neither migrate nor coexist with an earlier version of WebSphere Application
Server, you are choosing to ignore the previous installation and you can run only
one version at a time because of conflicting default port assignments. It is possible
for both versions to run at the same time without conflict if you use non-default
ports in one version. To set up coexistence with WebSphere Application Server
Version 5.1.x or Version 6.x, ensure that unique ports are selected during profile
creation for the Version 7.0 installation. To set up coexistence with an existing
installation of Version 7.0, select the Install a new copy of the V70 Application
Server product radio button during installation.
You can resolve conflicting port assignments by specifying port assignments for
coexistence during profile creation, by wsadmin scripting, or by using the Servers
> Application Servers > server1 > Ports administrative console page to ensure that
WebSphere Application Server Version 7.0 can run with an earlier version. Read
the ″Wsadmin tool″ article in the information center for more information on
wsadmin scripting.
2 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
– Secure Authentication Service (SAS) Secure Sockets Layer (SSL) ServerAuth
listener address
– Common Secure Interoperability Protocol Version 2 (CSIV2) SSL ServerAuth
listener address
– CSIV2 SSL MutualAuth listener address
– Administrative console port
– HTTP transport port
– Distribution and Consistency Services (DCS) unicast address
– Administrative console secure port
– HTTP transport secure port
– Service Integration Bus (SIB) endpoint address
– SIB endpoint secure address
– SIB MQ endpoint address
– SIB MQ endpoint secure address
Chapter 1. Overview 3
Migrating and coexisting
Migrating involves collecting the configuration information from a previous release
of a WebSphere Application Server product and merging it into a configuration for
a new release. Coexisting involves running a new release of a WebSphere
Application Server product on the same machine at the same time as you run an
earlier release.
The migration tools basically save the existing WebSphere configurations and user
applications in a backup directory and then process the contents of this backup
directory to migrate the configurations and your applications from previous
WebSphere Application Server releases to the latest release.
If you have a previous version of WebSphere Application Server, you must decide
whether to migrate the configuration and applications of the previous version to
the new version.
If you run an earlier release at the same time as the WebSphere Application Server
Version 7.0 installation, the two versions are coexisting.
To support coexistence, you must either use the -portBlock and -replacePorts
options when you migrate a profile or you must resolve port conflicts manually so
that the two releases do not attempt to use the same ports. Any ports bound when
the first profile starts will prevent the second profile from starting because the port
is in use. No port changes are required if only one release of the profile is active at
any given time.
4 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
3. Migrate your WebSphere Application Server Version 5.1.x or Version 6.x
product configuration to Version 7.0.
You have the choice between migrating your configuration automatically using
the migration tools or manually.
v Use the migration tools to automatically migrate your configuration.
Read “Using the migration tools to migrate product configurations” on page
25 for more information.
The following two Network Deployment migration scenarios are possible:
– Automated migration with all-node upgrade
In this scenario, you use the migration tools to migrate the deployment
manager as well as all of its federated nodes.
There are the following advantages and considerations with this approach:
- Advantages
v You copy the old configuration automatically.
This includes all resource definitions, virtual host definitions, security
settings, cluster definitions, and so forth.
v You recreate the same exact Version 5.1.x or Version 6.x configuration
in Version 7.0, including the node definitions, server definitions, and
deployed applications by default.
v You can enable support for script compatibility.
Read “WASPostUpgrade command” on page 49 for more
information.
- Considerations
v You should have a good idea of how long it will take to migrate the
configuration before you begin.
v You should migrate within a maintenance window.
– Automated migration with mixed-node utilization
This scenario involves the following activities:
- You use the migration tools to migrate the deployment manager only.
- You add Version 7.0 nodes.
- You move your applications to Version 7.0 as they are tested on Version
7.
- You remove a Version 5.1.x or Version 6.x cell when it is no longer
needed.
There are the following advantages and considerations with this approach:
- Advantages
v You copy the old configuration automatically.
This includes all resource definitions, virtual host definitions, security
settings, cluster definitions, and so forth.
v You recreate the same exact Version 5.1.x or Version 6.x configuration
in Version 7.0, including the node definitions, server definitions, and
deployed applications by default.
v You can have a mixed-node configuration.
v You can enable support for script compatibility.
Read “WASPostUpgrade command” on page 49 for more
information.
v You can move applications iteratively.
- Considerations
Chapter 1. Overview 5
v You should have a good idea of how long it will take to migrate the
configuration before you begin.
v You should migrate within a maintenance window.
v Manually migrate your configuration.
Migrating your configuration manually involves the following activities:
– You start with a clean slate and build up a new environment for Version 7.
– Ideally, you would use an existing set of administration scripts to set up
the complete Version 7.0 environment.
– You move your applications to Version 7.0 as they are tested on Version 7.
– You remove a Version 5.1.x or Version 6.x cell when it is no longer needed.
Consider the following points related to manually migrating your
configuration:
– Advantages
- You can reuse the scripts for maintenance, replication, and disaster
recovery.
- You can easily refactor the topology if you desire.
– Considerations
- A complete set of administration scripts is a significant investment.
- You must address script incompatibilities and changes before you
migrate.
- You cannot have a mixed-node configuration.
4. Migrate Web server plug-ins as described in Chapter 3, “Migrating Web server
configurations,” on page 87.
5. Optional: Set up multiple versions of WebSphere Application Server to coexist.
No runtime conflicts can exist for multiple instances and versions of WebSphere
Application Server if they are going to run at the same time on the same
machine. Potential conflicts can occur with your port assignments. Read “Port
number settings in WebSphere Application Server versions” on page 107 for
more information.
v Set up your system to run Version 5.1.x or Version 6.x and Version 7.0
together as described in “Setting up Version 5.1.x or Version 6.x and Version
7.0 coexistence” on page 101.
v Set up your system to run two concurrent Version 7.0 profiles as described in
“Setting up Version 7.0 coexistence” on page 104.
v Create more than one Version 7.0 profile on the same machine as described
in the ″Creating profiles using the graphical user interface″ article in the
information center.
Premigration considerations
Before you begin the process of migrating to WebSphere Application Server
Version 7.0, there are some considerations of which you need to be aware.
v After you install WebSphere Application Server Version 7.0, you might want to
build a complete Network Deployment cell configuration and verify that it
works correctly before you attempt to migrate an existing cell or node.
This process ensures that your system has all of the necessary prerequisites and
supports the new level of WebSphere Application Server.
v Before you perform the migration, evaluate the items deprecated in WebSphere
Application Server Version 7.0.
6 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
For more information, read the ″Deprecated and removed features″ article in the
information center.
v High-availability manager (HAM) and core-group functionality are included in
WebSphere Application Server Version 6.0 and later.
Read the ″Core group migration considerations″ article in the information center
for core-group configuration and topology considerations that might impact
your migration from Version 5.1.x or Version 6.x to Version 7.0.
Note: The migration tools add all servers to the default core group during
migration from Version 5.1.x. In most cases, however, the recommended
number of servers in a core group should not exceed 50. You receive a
warning message when the migration tools add a server that exceeds the
recommended upper limit.
v Before you migrate to Java™ Standard Edition (SE) Development Kit (JDK) 6
from JDK 5 or JDK 1.4 , review your applications for necessary changes based
on the Sun Microsystems Java specification.
Read “API and specification migration” on page 12 for more information.
v When migrating a cell with multiple nodes, the applications must remain at the
lowest JDK level until all nodes are migrated.
v Java Native Interface (JNI) applications that work with WebSphere
Application Server Version 6.0.2 on Solaris x64 must be recompiled in a 64-bit
environment for them to work with WebSphere Application Server Version 7.0.
This includes all JNI applications that run in a WebSphere Application Server
process—code called from Enterprise JavaBeans™ for example.
On Solaris x64, WebSphere Application Server Version 6.0.2 runs as a 32-bit
application even though the underlying operating system supports a 64-bit
environment. This is because the underlying Java Virtual Machine (JVM) is
32-bit. WebSphere Application Server Version 7.0 runs as a 64-bit application
because the underlying JVM is 64-bit. JNI applications compiled in a 32-bit
environment for Version 6.0.2 cannot run in the 64-bit environment of Version
7.0.
v The Web server plug-in configuration file, plugin-cfg.xml, that is generated after
successful migration from Version 5.1.x to Version 7.0 is topology centric—that
is, it includes all the applications within a cell. You cannot manage this cell-wide
plug-in configuration file from the administrative console until you have
manually configured it.
Read Chapter 3, “Migrating Web server configurations,” on page 87 for more
information.
v The migration articles in this information center assume that WebSphere
Application Server Version 7.0 is being installed in an environment where it
must coexist with prior levels of WebSphere Application Server.
Consider the following items when planning to enable coexistence:
– Update prerequisites to the levels required by WebSphere Application Server
Version 7.0.
Prior levels of WebSphere Application Server continue to run at the higher
prerequisite levels.
– Review the ports that have been defined to ensure that the WebSphere
Application Server Version 7.0 installation does not conflict.
Read “Port number settings in WebSphere Application Server versions” on
page 107 for default port information.
Read Chapter 5, “Coexisting,” on page 99 for more information.
Chapter 1. Overview 7
v Consider the following information if you are planning to have any
mixed-release cells:
– You can upgrade a portion of the nodes in a cell to WebSphere Application
Server Version 7.0 while leaving others at the previous release level. This
means that, for a period of time, you might be administering servers that are
at the previous release level and servers that are running the newer release in
the same cell.
In this mixed-release environment, some restrictions on what you can do with
servers at the previous release level might exist. For details, read the
″Creating application servers″ article in the information center.
– A WebSphere Application Server Version 7.0 Network Deployment cell can
contain mixed releases of Version 5.1.x or Version 6.x nodes; however, no
mixed-node management support exists for Version 6.0.0.x and Version 6.0.1.x.
The Version 7.0 migration tools still migrate these nodes during
deployment-manager migration; however, these tools issue a warning
message that the nodes cannot be managed by the Version 7.0 deployment
manager. You can then perform one of the following actions.
- Upgrade all Version 6.0.0.x and Version 6.0.1.x nodes to at least Version
6.0.2. This allows them to be administered by a Version 7.0 deployment
manager.
- Migrate these nodes to Version 7.0.
v During migration, Version 7.0 cluster information is distributed throughout the
cell. Version 6.0.x nodes that are not at Version 6.0.2.11 or later fail to read this
information and the cluster function might fail. Therefore, upgrade all Version
6.0.x nodes that will be contained in or interoperating with a Version 7.0 cell to
Version 6.0.2.11 or later before migrating your deployment managers to Version
7.0.
v WebSphere Application Server Version 7.0 migration converts HTTP transports
to channel-framework Web container transport chains.
For more information on WebSphere Application Server Version 7.0 transport
support, read the following articles in the information center:
– Configuring transport chains
– HTTP transport channel settings
– Transport chains
v The default profile location was changed in WebSphere Application Server
Version 6.0.x. The previous file path app_server_root/profiles/<profile>/<node>/
installedApps/<ear>/<war> was changed to app_server_root/profiles/<profile>.
To avoid configuration errors, use servlet APIs to control the file location instead
of using the default location.
v The following restrictions apply to a deployment manager migration:
– The Version 7.0 cell name must match the cell name in the Version 5.1.x or
Version 6.x configuration.
If you create a profile with a new cell name, the migration will fail.
– Either one or the other of the following options must be true:
- The Version 7.0 deployment manager node name must be the same as the
Version 5.1.x or Version 6.x deployment manager node name.
- The Version 7.0 deployment manager node name must be different from
every node name in the Version 5.1.x or Version 6.x configuration.
Otherwise, the migration fails with the following message:
8 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
MIGR0488E: The deployment manager node name in the new configuration
({0}) cannot be the same as a nodeagent node in the old configuration.
v When migrating a federated node, the WebSphere Application Server Version 7.0
cell name and node name must match their respective Version 5.1.x or Version
6.x names.
v If you create a profile that does not meet the migration requirements such as
naming requirements, you can remove the previous profile and create a new one
rather than uninstalling and reinstalling the WebSphere Application Server
Version 7.0 product.
v If you migrate a node to WebSphere Application Server Version 7.0 and then
discover that you need to revert back to Version 5.1.x or Version 6.x, read
“Rolling back your environment” on page 80.
v If you have a Web services gateway running on a WebSphere Application Server
Version 5.1.x or Version 6.x application server that is part of a Network
Deployment cell and you want to migrate the cell from a Version 5.1.x or
Version 6.x to a Version 7.0 deployment manager, you must first preserve the
gateway configuration as described in the ″Coexisting with previous gateway
versions″ article in the information center.
v If you have a Web services gateway running on a WebSphere Application Server
Version 5.1.x or Version 6.x application server that is part of a Network
Deployment cell and you want to migrate the cell from a Version 5.1.x or
Version 6.x to a Version 7.0 deployment manager, you must first preserve the
gateway configuration as described in the information center.
v The migration tools create a migration backup directory containing a backup
copy of the configuration from the previous version. The following guidelines
might help you to determine the amount of file-system space that this directory
might require:
– If you are migrating from Version 5.1.x, the space available for this directory
must be at least the size of the configuration directory and applications from
the previous version plus the size of the configuration directory and
applications for any WebSphere Application Server instances (wsinstances)
that you have defined.
– If you are migrating from Version 6.x, the space available for this directory
must be at least the size of the configuration directory and applications from
the previous profile.
v If you use the migration tools to create more than one Version 7.0 target profile
on the same host or installation instance and you use the default port settings,
there is a chance that the target profiles will share the same ports for some of
the new Version 7.0 port definitions. This will cause startup problems if both of
the migrated profiles are used.
If you are migrating two or more profiles that reside on the same host or
installation instance, perform the following actions for each additional target
profile:
1. Before using the migration tools, use the Profile Management tool or
manageprofiles command to create the target profile and make sure that you
select unique ports rather than using the default ports.
2. When you use the migration tools, select the target profile rather than letting
the tools create it.
v The amount of storage that your system requires during migration to Version 7.0
depends on your environment as well as on the migration tool that you are
using.
– WASPreUpgrade storage requirements
Chapter 1. Overview 9
- Location: Backup directory specified as a parameter of the WASPreUpgrade
command
- Amount: For an estimate of your storage requirements when using this
command, add the following amounts.
v Size of the following items for all of the profiles in your previous
configuration:
– profile_root/installableApps directory
– profile_root/installedApps directory
– profile_root/config directory
– profile_root/properties directory
– Shared libraries referenced in the libraries.xml configuration files
– Resource adapter archive (RAR) files referenced in the resources.xml
configuration files
v If trace is enabled, which is the default, up to 200 MB (depending on the
size and complexity of your configuration)
For more information about this command, read “WASPreUpgrade
command” on page 47.
– WASPostUpgrade storage requirements
- For an estimate of your storage requirements when using this command,
add the following amounts.
v Location: New configuration relative to the new profile_root directory
Size of the following items for the previous profile that you are
migrating:
– profile_root/installableApps directory
– profile_root/installedApps directory
– profile_root/config directory
– profile_root/properties directory
– Shared libraries referenced in the libraries.xml configuration files
– RAR files referenced in the resources.xml configuration files
v Location: Backup directory specified as a parameter of the
WASPreUpgrade and WASPostUpgrade commands
If trace is enabled, which is the default, up to 1 GB (depending on the
size and complexity of your configuration)
For more information about this command, read “WASPostUpgrade
command” on page 49.
v If you use isolated data repositories—specifically, nonshared data repositories
such as transaction logs for SIB and IBM Cloudscape or Apache Derby
databases—and you migrate from a previous release, your existing databases
and transaction logs are saved when the WASPreUpgrade tool is run. Any
database changes that you make after the WASPreUpgrade tool is run will not
be reflected in the migrated environment.
– If you have mission-critical information that is stored in these local data
repositories, you should safely shut down all servers that interact with those
repositories before attempting migration. Those servers should remain offline
until the migration has been successfully completed or rolled back.
– If you make multiple attempts at migration, either because of unexpected
rollback or to apply fixes, rerun the WASPreUpgrade tool so that any changes
to your isolated data repositories are reflected in the migrated environment.
10 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
After the migration is complete or you have rolled back to the previous version,
you can restart the servers that interact with these isolated data repositories.
v If you try to run the WASPreUpgrade command to migrate from
Version 6.1 with the node and application server that own the SIB file store still
running, you might get an error similar to the following:
C:\was70A\bin>WASPreUpgrade c:\bkupWAS6.1.0.17June30B C:\was61B
MIGR0385I: Starting to save profile AppSrv01.
MIGR0215W: The migration function cannot copy the file and open the destination file
c:\bkupWAS6.1.0.17June30B\migrated\C_\FSJune19\Log.
MIGR0272E: The migration function cannot complete the command.
If you then shut down the application server and node, the WASPreUpgrade
command completes.
v Before you migrate an Apache Derby database, ensure that any application
servers hosting applications that are using the Apache Derby database are
closed. Otherwise, the Apache Derby migration fails.
v You should be aware of the following rules related to migrating security
domains:
– If you migrate a deployment manager that has a security domain with a
cell-level scope, the migration tools take the following actions:
- Migration creates a domain in the new configuration called
PassThroughToGlobalSecurity if it does not already exist.
- Migration adds a cluster mapping to the new configuration for all clusters
that existed in the old configuration.
v Clusters that only existed in the Version 7.0 deployment-manager
configuration before migration do not have their mappings to
PassThroughToGlobalSecurity changed.
– If mappings for the Version 7.0 clusters exist before migration, they
still exist after migration.
– If no mappings for the Version 7.0 clusters exist before migration, they
still do not exist after migration.
v If a cluster exists in both the previous configuration and the Version 7.0
configuration before migration, the cluster in the new configuration is
added to the PassThroughToGlobalSecurity domain and behaves like the
cluster in the previous release.
- Migration adds a bus mapping for any busses that exist in a migrated
Version 6.1.x configuration.
Bus mappings are updated following the same rules as those for cluster
mapping that are described above.
- Administrative servers (deployment manager) are not added to the
PassThroughToGlobalSecurity domain.
– If you migrate a federated node that has a security domain with a cell-level
scope, the migration tools take the following actions:
- Migration creates a domain in the new configuration called
PassThroughToGlobalSecurity if it does not already exist.
- Migration adds a server-level mapping to the PassThroughToGlobalSecurity
domain for all non-clustered servers in the old node’s configuration.
v Servers on the node that is being migrated that are part of a cluster do
not receive entries in the PassThroughToGlobalSecurity domain because
this was addressed through a cluster mapping during
deployment-manager migration.
If you have removed that mapping, migration maintains that behavior.
Chapter 1. Overview 11
v Administrative servers (node agents) are not added to the
PassThroughToGlobalSecurity domain.
Read the ″Security domains in a mixed-version environment″ section of the
″Multiple security domains″ article in the information center.
v After you use the migration tools to migrate to WebSphere Application Server
Version 7.0, you might need to perform some actions that are not done
automatically by the migration tools.
– Examine any Lightweight Third-Party Authentication (LTPA) security settings
that you might have used in WebSphere Application Server Version 5.1.x or
Version 6.x, and verify that Version 7.0 security is set appropriately.
Read the ″Lightweight Third Party Authentication″ article in the information
center for more information.
– Check the WASPostUpgrade.log file in the logs directory for details about any
JavaServer Pages (JSP) objects that the migration tools did not migrate.
If Version 7.0 does not support a level for which JSP objects are configured,
the migration tools recognize the objects in the output and log them.
– Review your Java Virtual Machine (JVM) settings to verify that you are using
a heap size of at least 50 for improved startup performance.
Read the ″Java virtual machine settings″ article in the information center for
more information.
If you have used a smaller heap size before, you can use the default heap size
of 50.
– Verify the results of the automatic Apache Derby database migration, and
manually migrate any Apache Derby databases that are not automatically
migrated by the tools.
Read “Migrating IBM Cloudscape or Apache Derby databases” on page 74 for
more information.
– WebSphere Application Server Version 7.0 does not include the WebSphere
Connect JDBC driver for SQL Server. The
WebSphereConnectJDBCDriverConversion tool is provided to convert data
sources from the WebSphere Connect JDBC driver to the DataDirect Connect
JDBC driver or the Microsoft® SQL Server 2005 JDBC driver.
Read “Migrating from the WebSphere Connect JDBC driver” on page 76 for
more information.
In many cases, IBM provides additional features and customization options that
extend the specification level even further. If your existing applications use IBM
extensions from earlier product versions, it might be necessary for you to perform
mandatory or optional migration to use the same kinds of extensions in Version
7.0.
12 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
v WebSphere Application Server
began supporting Java SE
Development Kit (JDK) 6 in
Version 7.0.
Read JSR 270: Java SE 6
Release Contents and Java SE
6 for more information about
JDK 6.
v In general, existing Version
5.1.x and 6.x application
binaries that were developed
using JDK 1.4 and 5 are
highly compatible and
typically do not require
modifications to run.
However, recompilation of the
JDK 1.4 or 5 applications at
the JDK 6 level might
necessitate modifications of
the source code to conform to
incompatible changes that are
present in JDK 6. As part of
your migration planning, you
should review the JDK
compatibility restrictions that
are documented by Sun
Microsystems at Java SE 6
Release Notes®: Compatibility.
v A mixed cell containing
Version 5.1.x or Version 6.x
and Version 7.0 nodes requires
that all application binaries
deployed on Version 5.1.x or
Version 6.x remain at the
lowest JDK level associated
with the Version 5.1.x or
Version 6.x nodes. Although
you can successfully migrate
Version 5.1.x or Version 6.x
applications to Version 7.0,
this is only meant to be a
temporary state as you
transition to Version 7.0. After
you begin migration to
Version 7.0, plan to complete
the migration of the entire
cell, update your tooling to
Version 7.0, and update your
applications to conform to
JDK 6 requirements. Complete
this action before any further
application changes. After you
have completely migrated
your cell to Version 7.0,
upgrade your application
Chapter 1. Overview 13
binaries to the JDK 6 level the
next time that you make
application modifications that
require recompiling. This
action might require source
code changes to your
application to conform to the
JDK 6 API changes as
documented by Sun
Microsystems.
v The Java Virtual Machine
Debug Interface (JVMDI) and
the Java Virtual Machine
Profiler Interface (JVMPI)
were deprecated in JDK 5 and
removed in JDK 6.
Read Java SE 6 Release
Deprecated API for more
information.
Read the ″Specifications and API documentation″ article in the information center
for a summary of the specifications and API documentation supported in current
and prior product releases.
Validating PMEs
14 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
Running a mixed-node environment
Chapter 1. Overview 15
16 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
Chapter 2. Migrating product configurations
Use the WebSphere Application Server Version 7.0 migration tools to migrate your
product configurations. These migration tools support migration from Version 5.1.x
and Version 6.x.
You can migrate your product configurations using the WebSphere Application
Server Version 7.0 Migration wizard or the command-line migration tools.
Before using the migration tools, consult the IBM WebSphere Application Server
supported hardware, software, and APIs Web site to understand what fixes you
must apply to earlier versions. Applying fixes to an earlier version might also
apply fixes to files that have a role in the migration. Apply any fixes to ensure the
most effective migration of configurations and applications.
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 7.0 environment.
Bootstrap port
The migration tools carry the old release value into the Version 7.0
environment.
If a value for 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 7.0.
Command-line parameters
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 7.0 configuration do not
exist, have different meanings, or have different scopes.
For information on how to change the process-definition settings, read the
″Process definition settings″ article in the information center. For
information on how to change the JVM settings, read the ″Java virtual
machine settings″ article in the information center.
18 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
Generic server
In WebSphere Application Server Version 5.1.x, a generic server was an
APPLICATION_SERVER fitted to manage external resources. In Version 6.x
and later, it has its own type called GENERIC_SERVER. Migration will
perform this conversion, but migration cannot accurately migrate the
external resources that the generic server references. After migration has
completed migrating the generic server settings, you might need to
perform additional tasks. If the old resource that the generic server was
managing is located under the old WebSphere Application Server
installation, perform the following tasks:
1. Copy any related files to the new installation.
2. Run any setup required to put the external application back into a valid
and working state.
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.
Java heap size for migrating EAR files
When migrating all WebSphere Application Server Version 5.1.x or Version
6.x EAR files to Version 7.0 using the wsadmin tool, the WASPostUpgrade
tool uses the default maximum Java heap size value of 64 MB to install the
EAR files.
If a Version 5.1.x or Version 6.x EAR file fails to install during migration
because the Java heap size is not large enough, you see a message similar
to the following message:
java.lang.OutOfMemoryError JVMXE006:OutOfMemoryError
Increase the maximum Java heap size and follow the example below to
install the application.
Example of installing the application on WebSphere Application Server
Version 7.0
Assume that:
Installation root
C:\WebSphere\AppServer
Number signs (###)
Maximum heap size value
EAR_file_name
Name of the EAR file
app_name
Name of the application
server_name
Name of the server on which the EAR file installs
node_name
Name of the node on which the server is configured
20 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
Important: Use the same cell name when migrating Network Deployment
from Version 5.1.x or Version 6.x to Version 7.0. If you use a
different cell name, federated nodes cannot successfully
migrate to the Network Deployment Version 7.0 cell.
Migrating a base WebSphere Application Server node that is within a cell
to Version 7.0 also migrates the node agent to Version 7.0. A cell can have
some Version 7.0 nodes and other nodes that are at Version 5.1.x or Version
6.x levels. Read “Coexistence support” on page 99 for information on
restrictions on using mixed-release cells.
Policy files
WebSphere Application Server Version 7.0 migrates all the policy files that
are installed with Version 5.1.x or Version 6.x by merging settings into the
Version 7.0 policy files with the following characteristics:
v Any comments located in the Version 7.0 policy files will be preserved.
Any comments contained in the Version 5.1.x or Version 6.x policy files
will not be included in the Version 7.0 file.
v Migration will not attempt to merge permissions or grants; it is strictly
an add-type migration. If the permission or grant is not located in the
Version 7.0 file, the migration will bring it over.
v Security is a critical component; thus, the migration makes any additions
at the end of the original .policy files right after the comment MIGR0372I:
Migrated grant permissions follow. This is done to help administrators
verify any policy-file changes that the migration has made.
Properties directories
Migration copies files from prior version directories into the WebSphere
Application Server Version 7.0 configuration.
Property files
WebSphere Application Server Version 7.0 migrates all the property files
that are installed with Version 5.1.x or Version 6.x by merging settings into
the Version 7.0 property files with these exceptions for Version 5.1.x files:
v j2c.properties (migrated into resources.xml files)
v samples.properties
Resource adapter archives (RARs) referenced by J2C resources
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.
22 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
installedConnectors/
x2.rar″ for example) in
Version 6.x, however, the
Version 7.0 migration
tools cannot change the
archivePath attribute to
reflect this because that
would break all of the
other cluster members
that have not been
migrated.
Samples
During the migration of the deployment manager, only WebSphere
Application Server Version 5.1.x samples for federated nodes are migrated.
Equivalent Version 7.0 samples are available for all other Version 5.1.x
samples and all Version 6.x samples.
Security
Java 2 security is enabled by default when you enable security in
WebSphere Application Server Version 7.0. 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 7.0. 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 7.0
properties directory to enterprise applications as they are being migrated.
When migrating to WebSphere Application Server Version 7.0, your choice
of whether or not to migrate to support script compatibility results in one
of two different outcomes.
v If you choose to migrate to support script compatibility, your security
configuration is brought over to Version 7.0 without any changes.
This is the default.
v If you choose not to migrate to support script compatibility, the security
configuration is converted to the default configuration for WebSphere
Application Server Version 7.0. The default security configuration for
Version 6.1 and later acts almost the same as in the previous versions,
but there are some changes.
For example, existing keyfiles and trustfiles are moved out of the
SSLConfig repertoire and new keystore and truststore objects are created.
For more information on migrating your security configurations to Version
7.0, read the ″Migrating, coexisting, and interoperating – Security
considerations″ article in the information center.
Stdin, stdout, stderr, passivation, and working directories
The location for these directories is typically within the installation
directory of a previous version. The default location for stdin, stdout, and
stderr is the logs directory of the WebSphere Application Server Version 7.0
installation root.
The migration tools attempt to migrate existing passivation and working
directories. Otherwise, appropriate Version 7.0 defaults are used.
24 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
Web servers are not affected. The properties are set to indicate to the JVM
that the configuration should use a Java annotation scan policy other than
the Version 7.0 default scan policy.
v If you migrate a Version 6.1 profile that has the Feature Pack for EJB 3.0
installed, the migration tools add the following system property to the
JVM definitions for all Java servers defined on that node:
com.ibm.websphere.ejb.UseEJB61FEPScanPolicy = true
v If you migrate a Version 6.1 profile that has the Feature Pack for Web
Services installed, the migration tools add the following system property
to the JVM definitions for all Java servers defined on that node:
com.ibm.websphere.webservices.UseWSFEP61ScanPolicy = true
v If you migrate a Version 6.1 profile that has both the Feature Pack for
EJB 3.0 and the Feature Pack for Web Services installed, the migration
tools add both of the system properties to the JVM definitions for all
Java servers defined on that node:
com.ibm.websphere.ejb.UseEJB61FEPScanPolicy = true
com.ibm.websphere.webservices.UseWSFEP61ScanPolicy = true
A Network Deployment configuration requires that the deployment
manager profile be augmented with all of the feature packs used in the
cell. This means that the deployment-manager profile can potentially
have both feature packs installed even if none of its federated nodes
have both installed.
If these properties are set, the following two changes take place in the
default Version 7.0 behavior:
v Application installation generates classes based on the annotation scan
policy associated with the settings for those two properties.
This means that you can potentially use the following four annotation
scan policies:
– Version 7 default behavior
– Feature Pack for EJB 3.0 behavior
– Feature Pack for Web Services behavior
– Net behavior from having both the Feature Pack for EJB 3.0 and the
Feature Pack for Web Services installed
v The servers use the generated annotation classes based on the properties
set, resulting in four potential behaviors.
You can change the scan policy behavior by adding or removing the
custom JVM system properties from your server.xml files.
Important: To evoke the correct installApp behavior, the server.xml file for
the deployment manager must retain any property specified for
any node in the cell.
After changing the properties, you must reinstall or update your
applications and then resynchronize the cell to implement the change.
Important: Use the migration tools for the version of WebSphere Application
Server that you are installing. The tools change over time. If you use
migration tools from an earlier release of WebSphere Application
Server, you are likely to encounter a problem with the migration.
The WASPreUpgrade tool is also on the utilities disk so that you can store the
configuration of an existing release before installing the Version 7.0 product. The
tools on the product disk provide the necessary function for migrating from a
previous release of WebSphere Application Server to the one on the product disk.
26 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
clientUpgrade tool
You can use the clientUpgrade tool to upgrade the client application to a
new release level.
Read “clientUpgrade command” on page 42 for more information.
convertScriptCompatibility tool
Administrators use the convertScriptCompatibility tool to convert their
configuration from a mode that supports backward compatibility of
Version 5.1.x or Version 6.x administration scripts to a mode that is fully
Version 7.0.
Read “convertScriptCompatibility command” on page 43 for more
information.
convertSelfSignedCertificatesToChained task
Chained certificates are the default certificate type in Websphere
Application Server Version 7.0. Administrators can use the
convertSelfSignedCertificatesToChained task with the wsadmin tool to
convert self-signed certificates to chained certificates.
Read the ″SSLMigrationCommands command group for the AdminTask
object″ article for more information.
Before using the Migration wizard, you must have access to the existing, previous
version of WebSphere Application Server.
Select the appropriate option to obtain instructions on how to migrate from your
old version of WebSphere Application Server using the Migration wizard.
v “Migrating to a Version 7.0 standalone application server using the Migration
wizard” on page 28
Before using the Migration wizard, you should have installed Version 7.0 already.
You can first use the Profile Management tool or the manageprofiles command to
create a valid new target Version 7.0 application server profile if one does not
already exist, or you can create a target profile later using the Migration wizard.
Restriction: You cannot use the Profile Management tool to create profiles on the
following platforms:
v 64-bit platforms
v Linux for zSeries platform for 64-bit or 31-bit
The WebSphere Application Server Network Deployment product does not create a
profile during installation because there are four profile types. The Installation
wizard prompts you to create a profile, but that action is optional during
installation.
Tip: Before migrating a WebSphere Application Server Version 5.1.x or Version 6.x
application server, use the backupConfig command or your own preferred
backup utility to back up your existing configuration if you want to be able to
restore it to its previous state after migration. Read the ″backupConfig
command″ article in the information center for more information. Make sure
that you note the exact name and location of this backed-up configuration.
28 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
The Migration wizard was introduced in WebSphere Application Server Version
6.0. The wizard is the graphical interface to the primary Version 7.0 command-line
migration tools, which are the “WASPreUpgrade command” on page 47 and the
“WASPostUpgrade command” on page 49.
After gathering all of the information that is required during the migration, use the
wizard to migrate a WebSphere Application Server Version 5.1.x or Version 6.x
application server to a Version 7.0 standalone application server.
Restrictions: If you choose this option, the location is shared by the existing
WebSphere Application Server Version 5.1.x or Version 6.x
installation and the Version 7.0 installation. If you keep the
migrated applications in the same locations as those of the
previous version, the following restrictions apply:
– The WebSphere Application Server Version 7.0 mixed-node
support limitations must be followed. This means that the
following support cannot be used when evoking the
wsadmin command:
- Precompile JSP
- Use Binary Configuration
- Deploy EJB
– You risk losing the migrated applications unintentionally if
you later delete applications from these locations when
administering (uninstalling for example) your Version 5.1.x
or Version 6.x installation.
v Choose to install the applications in the default directory of the target
version.
v Specify the directory in which to install the migrated applications.
11. Select one of the options for setting port values, optionally specify a starting
port value for resolving port conflicts, and then click Next.
You can choose to do ether one of the following with the port values:
v Use the port values assigned to the previous (source) installation.
v Use the port values assigned to the target profile.
By default, a port conflict is resolved by incrementing the port number by one
until an unused port number is found. Instead, you can specify a starting port
number to be used when a conflict is detected. If the starting port number is
in use, it will be incremented by one until an unused port number is found.
30 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
12. Select the check box if you want to migrate to support script compatibility,
and then click Next.
If you select this option, migration creates the following Version 5.1.x or
Version 6.x configuration definitions:
v Transports
v ProcessDef
v Version 5.1.x or Version 6.x SSL
v Version 5.1.x or Version 6.x ORB service threadpool
instead of the following Version 7.0 configuration definitions:
v Channels
v ProcessDefs
v Version 7.0 SSL
v Version 7.0 ORB service threadpool
Select this option in order to minimize impacts to existing administration
scripts. If you have existing wsadmin scripts or programs that use third-party
configuration APIs to create or modify the Version 5.1.x or Version 6.x
configuration definitions, for example, you might want to select this option
during migration.
Note: This is meant to provide a temporary transition until all of the nodes in
the environment are at the Version 7.0 level. When they are all at the
Version 7.0 level, you should perform the following actions:
a. Modify your administration scripts to use all of the Version 7.0
settings.
b. Use the convertScriptCompatability command to convert your
configurations to match all of the Version 7.0 settings.
Read “convertScriptCompatibility command” on page 43 for more
information.
13. Specify the administrative console workspace user root directory where the
″My Tasks″ user information is stored in the previous installation, and then
click Next.
This panel displays only if you are migrating from Version 6.1.x.
14. Enter the administrative security credentials for the source WebSphere
Application Server installation, and then click Next.
This panel displays only if security is enabled and if the server user identity is
not stored in the repository.
15. Check the information in the summary panel and make sure that it is correct,
and then click Next to start the migration.
16. If the wizard indicates that the profile-creation process was successful, click
Next.
This panel displays only if you selected the option to create a new target
profile.
If the process is not successful, the wizard displays a failure panel. If the
process is partially successful, the wizard displays a warning panel. Correct
any problems and retry the migration.
17. If the wizard indicates that the pre-upgrade process was successful, click Next.
If the process is not successful, the wizard displays a failure panel. If the
process is partially successful, the wizard displays a warning panel. Correct
any problems and retry the migration.
You can now start the migrated standalone application server in the WebSphere
Application Server Version 7.0 environment.
Tip: When migrating a WebSphere Application Server Version 5.1.x or Version 6.x
federated node, you must perform the following actions if you want to be
able to roll it back to its previous state after migration:
1. Back up your existing configuration.
v Run the backupConfig command or your own preferred utility to back
up the Version 7.0 deployment manager configuration.
Important: Make sure that you note the exact name and location of this
backed-up configuration.
Read the ″backupConfig command″ article in the information center for
more information.
v Run the backupConfig command or your own preferred utility to back
up the Version 5.1.x or Version 6.x federated node configuration.
Important: Make sure that you note the exact name and location of this
backed-up configuration.
Read the ″backupConfig command″ article in the information center for
more information.
2. Migrate the federated node.
3. If necessary, you can now roll back the federated node that you just
migrated.
Read “Rolling back a federated node” on page 83 for more information.
32 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
For help in troubleshooting problems when migrating, see Chapter 8,
“Troubleshooting migration,” on page 113.
1. Perform a typical or custom WebSphere Application Server Version 7.0
installation.
2. Migrate the WebSphere Application Server Version 5.1.x or Version 6.x
deployment manager to Version 7.0 as described in “Migrating to a Version
7.0 deployment manager using the Migration wizard” on page 37.
3. Collect the information that the Migration wizard will prompt you for during
the migration.
Read “WASPreUpgrade command” on page 47 and “WASPostUpgrade
command” on page 49 for descriptions of the parameters related to the
information that you need to collect.
4. Optional: Use the WebSphere Application Server Version 7.0 Profile
Management tool or the manageprofiles command to create a application
server or custom profile, but do not federate the node.
Restriction: You cannot use the Profile Management tool to create profiles on
the following platforms:
v 64-bit platforms
v Linux for zSeries platform for 64-bit or 31-bit
You can first use the Profile Management tool or the manageprofiles command
to create a valid new target Version 7.0 application server profile if one does
not already exist, or you can create a target profile later using the Migration
wizard. Read the ″Creating profiles using the graphical user interface″ article
in the information center for more information.
For migration to be successful, you must use the same node names and cell
names for each node that you migrate from Version 5.1.x or Version 6.x to
Version 7.
Tip: If you make any cell-level changes to the new Version 7.0 node before
migration, such as changes to virtual-host information, these changes will
be lost during migration. Therefore, you should wait until after the node
has been migrated before making any such changes. Otherwise, you will
have to manually remake all of the changes to the new cell after
migration using the administrative console running on the deployment
manager. This tip is reflected in message MIGR0444W.
5. Ensure that the Version 7.0 deployment manager is up and running.
Note: You can migrate a Version 5.1.x or Version 6.x node whether the node is
running or stopped. The migration tools can retrieve all the
configuration data either way. You must stop the Version 5.1.x or
Version 6.x node before you can start the Version 7.0 node that you are
installing, however, so it makes sense to stop it now.
6. Start the Migration wizard.
Perform one of the following actions to access the Migration wizard:
v Go to Start > Programs > IBM WebSphere > Application Server V7.0
Network Deployment, and click Migration wizard.
v Run the following command:
– app_server_root/bin/
migration.sh
– app_server_root\bin\migration.bat
Restrictions: If you choose this option, the location is shared by the existing
WebSphere Application Server Version 5.1.x or Version 6.x
installation and the Version 7.0 installation. If you keep the
migrated applications in the same locations as those of the
previous version, the following restrictions apply:
– The WebSphere Application Server Version 7.0 mixed-node
support limitations must be followed. This means that the
following support cannot be used when evoking the
wsadmin command:
- Precompile JSP
34 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
- Use Binary Configuration
- Deploy EJB
– You risk losing the migrated applications unintentionally if
you later delete applications from these locations when
administering (uninstalling for example) your Version 5.1.x
or Version 6.x installation.
v Choose to install the applications in the default directory of the target
version.
v Specify the directory in which to install the migrated applications.
15. Select one of the options for setting port values, optionally specify a starting
port value for resolving port conflicts, and then click Next.
You can choose to do any one of the following with the port values:
v Use the port values assigned to the previous (source) installation.
v Use the port values assigned to the target profile.
By default, a port conflict is resolved by incrementing the port number by one
until an unused port number is found. Instead, you can specify a starting port
number to be used when a conflict is detected. If the starting port number is
in use, it will be incremented by one until an unused port number is found.
16. Select the check box if you want to migrate to support script compatibility,
and then click Next.
If you select this option, migration creates the following Version 5.1.x or
Version 6.x configuration definitions:
v Transports
v ProcessDef
v Version 5.1.x or Version 6.x SSL
v Version 5.1.x or Version 6.x ORB service threadpool
instead of the following Version 7.0 configuration definitions:
v Channels
v ProcessDefs
v Version 7.0 SSL
v Version 7.0 ORB service threadpool
Select this option in order to minimize impacts to existing administration
scripts. If you have existing wsadmin scripts or programs that use third-party
configuration APIs to create or modify the Version 5.1.x or Version 6.x
configuration definitions, for example, you might want to select this option
during migration.
Note: This is meant to provide a temporary transition until all of the nodes in
the environment are at the Version 7.0 level. When they are all at the
Version 7.0 level, you should perform the following actions:
a. Modify your administration scripts to use all of the Version 7.0
settings.
b. Use the convertScriptCompatability command to convert your
configurations to match all of the Version 7.0 settings.
Read “convertScriptCompatibility command” on page 43 for more
information.
17. Specify the administrative console workspace user root directory where the
″My Tasks″ user information is stored in the previous installation, and then
click Next.
You might need to do some things that are not done automatically by the
migration tools.
v Examine any Lightweight Third Party Authentication (LTPA) security settings
that you might have used in WebSphere Application Server Version 5.1.x or
Version 6.x, and make sure that Version 7.0 security is set appropriately.
Read the ″Lightweight Third Party Authentication″ article in the information
center for more information.
v Check the WASPostUpgrade.log file in the logs directory for details about any
JSP objects that the migration tools did not migrate.
If Version 7.0 does not support a level for which JSP objects are configured, the
migration tools recognize the objects in the output and log them.
v Review your Java Virtual Machine (JVM) settings to verify that you are using a
heap size of at least 50 for improved startup performance.
Read the ″Java virtual machine settings″ article in the information center for
more information.
If you have used a smaller heap size in the past, you can use the default heap
size of 50.
36 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
v Configure WebSphere Application Server to use a database.
For example, you can configure WebSphere Application Server to use DB2®.
v Verify the results of the automatic Apache Derby database migration, and
manually migrate any Apache Derby databases that are not automatically
migrated by the tools.
Read “Migrating IBM Cloudscape or Apache Derby databases” on page 74 for
more information.
Before using the Migration wizard, you must have access to the existing
WebSphere Application Server Version 5.1.x or Version 6.x deployment manager.
You can first use the Profile Management tool or the manageprofiles command to
create a valid new target Version 7.0 management profile for a deployment
manager if one does not already exist, or you can create a target profile later using
the Migration wizard.
Restriction: You cannot use the Profile Management tool to create profiles on the
following platforms:
v 64-bit platforms
v Linux for zSeries platform for 64-bit or 31-bit
After gathering all of the information that is required during the migration, use the
wizard to migrate a WebSphere Application Server Version 5.1.x or Version 6.x
deployment manager to the Version 7.0 deployment manager.
Tip: Before migrating a WebSphere Application Server Version 5.1.x or Version 6.x
deployment manager, use the backupConfig command or your own preferred
backup utility to back up your existing configuration if you want to be able to
restore it to its previous state after migration. Read the ″backupConfig
command″ article in the information center for more information. Make sure
that you note the exact name and location of this backed-up configuration.
1. Start the Migration wizard.
Perform one of the following actions to access the Migration wizard:
v Go to Start > Programs > IBM WebSphere > Application Server V7.0
Network Deployment, and click Migration wizard.
v Run the following command:
– app_server_root/bin/
migration.sh
– app_server_root\bin\migration.bat
2. Read the Welcome panel to learn about the migration process, and then click
Next.
3. Select or specify a previous version of WebSphere Application Server from
which to migrate, and then click Next.
Select the check box and enter the location of the previous installation if it
does not display in the selection list.
4. Select the source profile or instance that you want to migrate, and then click
Next.
5. Select the target profile to which you want to migrate from the list of valid
profiles for the installation or select Create new profile, and then click Next.
Select the check box to create a backup copy of the target profile’s
configuration before migrating the source profile. If you select the check box,
the backup copy of the target profile will be written to profile_root/temp/
MigrationBackup.time_stamp.zip. You can use the restoreConfig command to
restore the configuration after migration if necessary.
6. If you selected Create new profile on the last panel, enter the parameters for
creating the new profile and then click Next.
Restrictions for a deployment manager migration:
v The Version 7.0 cell name must match the cell name in the Version 5.1.x or
Version 6.x configuration.
If you create a profile with a new cell name, the migration will fail.
v Either one or the other of the following options must be true:
– The Version 7.0 deployment manager node name must be the same as
the Version 5.1.x or Version 6.x deployment manager node name.
– The Version 7.0 deployment manager node name must be different from
every node name in the Version 5.1.x or Version 6.x configuration.
Otherwise, the migration fails with the following message:
MIGR0488E: The deployment manager node name in the new configuration
({0}) cannot be the same as a nodeagent node in the old configuration.
If you also use the same node name that you used for the Version 5.1.x or
Version 6.x cell, the node agents will still work after migration without being
restarted.
38 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
7. Specify a migration backup directory in which to place a backup copy of the
configuration from the previous version, and then click Next.
The directory is created if it does not already exist. If the directory exists, it
should be empty because the backup operation might overwrite existing
backup files.
8. Select one of the options for migrating the applications installed on the source
profile, and then click Next.
You can choose to do any one of the following with the applications:
v Include your enterprise applications as part of the migration.
v Prepare your enterprise applications for installation in the WebSphere
Application Server Version 7.0 installableApps directory without actually
installing them during migration processing.
Scripts that can be used to install these applications are generated and
saved in the migration backup directory. You can then run these files at any
point and in any combination after the migration. You can also reorganize
and combine these files for better applications installation efficiency if you
want.
v Do nothing with your enterprise applications during migration processing.
9. If you selected the option to install your applications, specify where the
migrated applications should be located and then click Next.
You can choose any one of the following options:
v Keep the applications in the same directories in which they are currently
located.
Restrictions: If you choose this option, the location is shared by the existing
WebSphere Application Server Version 5.1.x or Version 6.x
installation and the Version 7.0 installation. If you keep the
migrated applications in the same locations as those of the
previous version, the following restrictions apply:
– The WebSphere Application Server Version 7.0 mixed-node
support limitations must be followed. This means that the
following support cannot be used when evoking the
wsadmin command:
- Precompile JSP
- Use Binary Configuration
- Deploy EJB
– You risk losing the migrated applications unintentionally if
you later delete applications from these locations when
administering (uninstalling for example) your Version 5.1.x
or Version 6.x installation.
v Choose to install the applications in the default directory of the target
version.
v Specify the directory in which to install the migrated applications.
10. Select the check box if you want to prevent migration processing from
disabling the existing WebSphere Application Server Version 5.1.x or Version
6.x deployment manager, and then click Next.
If this is selected, you can use the existing Version 5.1.x or Version 6.x
deployment manager while the migration is being completed.
Note: This is meant to provide a temporary transition until all of the nodes in
the environment are at the Version 7.0 level. When they are all at the
Version 7.0 level, you should perform the following actions:
a. Modify your administration scripts to use all of the Version 7.0
settings.
b. Use the convertScriptCompatability command to convert your
configurations to match all of the Version 7.0 settings.
Read “convertScriptCompatibility command” on page 43 for more
information.
13. Specify the administrative console workspace user root directory where the
″My Tasks″ user information is stored in the previous installation, and then
click Next.
40 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
This panel displays only if you are migrating from Version 6.1.x.
14. Enter the administrative security credentials for the source WebSphere
Application Server installation, and then click Next.
This panel displays only if security is enabled and if the server user identity is
not stored in the repository.
15. Check the information in the summary panel and make sure that it is correct,
and then click Next to start the migration.
16. If the wizard indicates that the profile-creation process was successful, click
Next.
This panel displays only if you selected the option to create a new target
profile.
If the process is not successful, the wizard displays a failure panel. If the
process is partially successful, the wizard displays a warning panel. Correct
any problems and retry the migration.
17. If the wizard indicates that the pre-upgrade process was successful, click Next.
If the process is not successful, the wizard displays a failure panel. If the
process is partially successful, the wizard displays a warning panel. Correct
any problems and retry the migration.
18. If the wizard indicates that the post-upgrade process was successful, click
Next.
If the process is not successful, the wizard displays a failure panel. If the
process is partially successful, the wizard displays a warning panel. Correct
any problems and retry the migration.
19. If the wizard indicates that the migration was successful, click Next.
If the process is not successful, the wizard displays a failure panel. If the
migration is partially successful, the wizard displays a warning panel. Correct
any problems and retry the migration.
20. Click Next to migrate another profile, or click Cancel to exit the Migration
wizard.
You can now start the migrated servers in the WebSphere Application Server
Version 7.0 environment.
You might need to do some things that are not done automatically by the
migration tools.
v Examine any Lightweight Third Party Authentication (LTPA) security settings
that you might have used in WebSphere Application Server Version 5.1.x or
Version 6.x, and make sure that Version 7.0 security is set appropriately.
Read the ″Lightweight Third Party Authentication″ article in the information
center for more information.
v Check the WASPostUpgrade.log file in the logs directory for details about any
JSP objects that the migration tools did not migrate.
If Version 7.0 does not support a level for which JSP objects are configured, the
migration tools recognize the objects in the output and log them.
v Review your Java Virtual Machine (JVM) settings to verify that you are using a
heap size of at least 50 for improved startup performance.
Read the ″Java virtual machine settings″ article in the information center for
more information.
If you have used a smaller heap size in the past, you can use the default heap
size of 50.
v Configure WebSphere Application Server to use a database.
Use it for migration involving operating systems that are not supported by
WebSphere Application Server Version 7.0.
1. Run the WASPreUpgrade command on the utilities disk against the existing
WebSphere Application Server version on the existing operating-system level.
v Specify the migration backup directory.
v Specify the name of the installation root directory for the current WebSphere
Application Server Version 5.1.x or Version 6.x installation.
v Optional: Specify the name of a specific instance or profile to be migrated
from a previous version of WebSphere Application Server.
v Optional: Specify the location of user preferences for the administrative
console for one or more profiles.
Read “WASPreUpgrade command” on page 47 for more information.
2. Upgrade the operating system.
3. Install WebSphere Application Server Version 7.0.
Do not use the migration option when you install it.
4. Run the WASPostUpgrade command manually.
Read “WASPostUpgrade command” on page 49 for more information.
clientUpgrade command
Use the clientUpgrade command to migrate previous versions of client resources
to Version 7 level resources.
Use the clientUpgrade command to migrate Version 5.1.x and Version 6.x client
resources to Version 7 level resources. In the process of migrating these resources,
the client-resources.xmi file located in the client jars is migrated to the latest level.
A backup of the client-resources.xmi file is also located in the client jar. If this
command is not executed against the client EAR files before they are installed on
Version 7, the client EARs do not operate or install correctly.
42 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
clientUpgrade.bat EAR_file [-clientJar client_jar ][-logFileLocation logFileLocation]
[-traceString trace_spec [-traceFile file_name ]]
Parameters
convertScriptCompatibility command
The convertScriptCompatibility command is used by administrators to convert
their configurations from a mode that supports backward compatibility of
WebSphere Application Server Version 5.1.x or Version 6.0.x administration scripts
to a mode that is fully in the Version 7.0 configuration model.
The scope of the configuration changes depend on the type of profile that is being
processed.
v For standalone configurations, the default is to convert all servers owned by the
node in that configuration.
Use the -serverName parameter for more granular control.
v For Network Deployment configurations, the default behavior is to convert all
nodes and all servers owned by those nodes.
Use the -nodeName and -serverName parameters for more granular control.
Nodes are checked to verify that they are at a WebSphere Application Server
Version 7.0 level before they are processed in order to support mixed-node
configurations. Client environments are not processed.
Location
Syntax
convertScriptCompatibility.sh -help
convertScriptCompatibility.bat -help
Parameters
44 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
Read the ″restoreConfig command″ article in the information center for more
information.
-profileName
This is an optional parameter that is used to specify the profile configuration
in the Version 7.0 environment. If this is not specified, the default profile is
used. If the default profile has not been set or cannot be found, the system
returns an error.
-nodeName
This is an optional parameter that is used to specify a particular node name be
processed rather than every node in the configuration. If this is not specified,
all nodes in the configuration are converted.
-serverName
This is an optional parameter that is used to specify a particular server name
to be processed rather than every server in the configuration. It can be used on
all profile types and can be used in conjunction with the -nodeName
parameter when processing Network Deployment configurations. If this
parameter is not specified, all servers in the configuration are converted. If it is
used in conjunction with the -nodeName parameter, all processing is limited to
the specified node name.
-traceString
This is an optional parameter. The value trace_spec specifies the trace
information that you want to collect. To gather all trace information, specify
″*=all=enabled″ (with quotation marks). The default is to not gather trace
information. If you specify this parameter, you must also specify the -traceFile
parameter.
-traceFile
This is an optional parameter. The value file_name specifies the name of the
output file for trace information. If you specify the -traceString parameter but
do not specify the -traceFile parameter, the command does not generate a trace
file.
Usage
Standalone application server profile
Example scenario
1. Run the WASPostUpgrade command and specify
-scriptCompatibility=true or do not specify a value for the
-scriptCompatibility parameter (which has a default value of true).
2. Follow these steps to convert all servers under this standalone profile:
a. Open a command window.
b. Change to the Version 7.0 profile’s profile_root/bin directory.
c. Run the following command:
./convertScriptCompatibility.sh
convertScriptCompatibility.bat
Deployment manager with federated nodes
Example scenario 1
1. Run the WASPostUpgrade command against the deployment manager
as well as all of its federated nodes and specify
./convertScriptCompatibility.sh
convertScriptCompatibility.bat
3. Synchronize the deployment manager’s configuration with each
federated node to produce a consistent configuration.
Example scenario 2
1. Run the WASPostUpgrade command against the deployment manager
and specify -scriptCompatibility=false.
2. Run the WASPostUpgrade command against the deployment manager’s
federated nodes and specify -scriptCompatibility=true or do not
specify a value for the -scriptCompatibility parameter (which has a
default value of true).
3. Follow these steps to convert all non-converted nodes and servers in
the cell.
For more information about where to run this command, read the ″Using
command line tools″ article in the information center.
46 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
WASPreUpgrade command
The WASPreUpgrade command for WebSphere Application Server Version 7.0
saves the configuration of a previously installed version of WebSphere Application
Server into a migration-specific backup directory.
Location
The command file is located in and must be run from the Version 7.0
app_server_root/bin directory.
Syntax
WASPreUpgrade.bat backupDirectory
currentWebSphereDirectory
[-traceString trace_spec [-traceFile file_name ]]
[-machineChange true | false]
[-oldProfile profile_name]
[-workspaceRoot profile1=user_workspace_folder_name_1;
profile2=user_workspace_folder_name_2]
Parameters
Logging
The WASPreUpgrade tool displays status to the screen while it runs. The tool also
saves a more extensive set of logging information in the
WASPreUpgrade.time_stamp.log file written to the backupDirectory directory, where
backupDirectory is the value specified for the backupDirectory parameter. You can
view the WASPreUpgrade.time_stamp.log file with a text editor.
Migrated resources
WASPreUpgrade saves all of your resources, but it does not migrate entities in
your classes directory.
48 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
The WASPreUpgrade command also saves all instances created in the Version 5.1.x
environment.
WASPostUpgrade command
The WASPostUpgrade command for WebSphere Application Server Version 7.0
retrieves the saved configuration that was created by the WASPreUpgrade
command from the backupDirectory that you specified. The WASPostUpgrade script
for WebSphere Application Server Version 7.0 reads the configuration from this
directory to migrate to WebSphere Application Server Version 7.0 and adds all
migrated applications into the app_server_root/installedApps directory for the
Version 7.0 installation.
Location
The command file is located in and must be run from the Version 7.0
app_server_root/bin directory.
Syntax
WASPostUpgrade.bat backupDirectory
[-username userID]
[-password password]
[-oldProfile profile_name]
[-profileName profile_name]
[-scriptCompatibility true | false]
[-portBlock port_starting_number]
[-backupConfig true | false]
[-replacePorts true | false]
[-includeApps true | false | script]
[-keepDmgrEnabled true | false]
[[-appInstallDirectory user_specified_directory]
| [-keepAppDirectory true | false]]
[-traceString trace_spec [-traceFile file_name]]
Parameters
Tip: When you need to specify a password in the Migration wizard or when
you use the WASPostUpgrade command with the -password parameter
on the command line, you can type the password in plain text or use the
xor-ciphered value. To use the xor-ciphered value, type the entire cipher
including the {xor} prefix as the value for the parameter. This
xor-ciphered value can be specified in any one of several WebSphere
Application Server configuration files for your previous configuration,
including the soap.client.props, ssl.client.props, and security.xml files.
-oldProfile
This is an optional parameter for migrating instances or profiles from previous
WebSphere Application Server versions. The instance or profile must already
exist in the migration backup directory before running this command.
In WebSphere Application Server Version 5.1.x, unique instance names were
defined by the concatenation of -instanceName and -hostName; this
concatenation forms the profile_name that you need to use with the -oldprofile
parameter. In WebSphere Application Server Version 5.1.x, this concatenation is
stored in the app_server_root/properties directory in a file called
wsinstance.config.
-profileName
This is an optional parameter for migrating to specific profiles in WebSphere
Application Server Version 7.0. The value profile_name specifies the name of the
Version 7.0 profile to which the script migrates your configuration. You must
have already created this profile before calling the WASPostUpgrade
command.
If the -profileName parameter is not specified, the default profile is used. If no
default profile is found, the system reports an error.
50 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
-scriptCompatibility
This is an optional parameter used to specify whether or not migration should
create the following Version 5.1.x or Version 6.x configuration definitions:
v Transport
v ProcessDef
v Version 5.1.x or Version 6.x SSL
instead of the following Version 7.0 configuration definitions:
v Channels
v ProcessDefs
v Version 7.0 SSL
The default value is true.
Specify true for this parameter in order to minimize impacts to existing
administration scripts. If you have existing wsadmin scripts or programs that
use third-party configuration APIs to create or modify the Version 5.1.x or
Version 6.x configuration definitions, for example, you might want to specify
true for this option during migration.
Note: This is meant to provide a temporary transition until all of the nodes in
the environment are at the Version 7.0 level. When they are all at the
Version 7.0 level, you should perform the following actions:
1. Modify your administration scripts to use all of the Version 7.0
settings.
2. Use the convertScriptCompatability command to convert your
configurations to match all of the Version 7.0 settings.
Read “convertScriptCompatibility command” on page 43 for more
information.
-portBlock
This is an optional parameter. The port_starting_number value specifies the
starting value of a block of consecutive port numbers to assign when creating
new ports.
If a value is specified for this parameter, any new ports that are assigned are
set based on this value. Every time a new port value is required, the port is
created based on this value and the seed value is incremented for the next
usage. No duplicate ports are assigned. If the -replacePorts parameter value is
not specified, all port values in the profile are based on this value.
-backupConfig
This is an optional parameter used to specify whether the existing WebSphere
Application Server Version 7.0 configuration is saved before any changes are
made by the WASPostUpgrade tool. The default is true—that is, to use the
backupConfig command to save a copy of the current configuration into the
profile_name/temp directory.
Use the restoreConfig command to restore that configuration as required. Read
the ″restoreConfig command″ article in the information center for more
information.
-replacePorts
This optional parameter is used to specify how to map port values.
v True
Use all port values from the old configuration in the new configuration.
This value is the default.
52 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
Restrictions: If this parameter is specified as true, the location is shared by the
existing WebSphere Application Server Version 5.1.x or Version
6.x installation and the Version 7.0 installation. If you keep the
migrated applications in the same locations as those of the
previous version, the following restrictions apply:
v The WebSphere Application Server Version 7.0 mixed-node
support limitations must be followed. This means that the
following support cannot be used when evoking the wsadmin
command:
– Precompile JSP
– Use Binary Configuration
– Deploy EJB
v You risk losing the migrated applications unintentionally if you
later delete applications from these locations when
administering (uninstalling for example) your Version 5.1.x or
Version 6.x installation.
-appInstallDirectory
This is an optional parameter that is used to pass the directory name to use
when installing all applications during migration. The default of
profile_name\installedApps is used if this parameter is not specified.
If you specify this parameter, you cannot specify the -keepAppDirectory
parameter.
Quotes must be used around the directory name if one or more spaces are in
the name.
If you use this parameter, the migration tools investigate the node-level
variables for the node being migrated both in the backup directory (variables
for the old release) and in the destination profile (variables from the new
release). If the path is part of any of the following variables in either of these
releases, the tools contract the path information to use the related variable:
v APP_INSTALL_ROOT
v USER_INSTALL_ROOT
v WAS_INSTALL_ROOT
When the contraction takes place, you receive the following warning message
that tells you that the tools changed your specified value and what that
contracted value is:
MIGR0341W: Application install directory has been updated to {0}.
For example:
MIGR0341W: Application install directory has been updated to
${USER_INSTALL_ROOT}\customAppDirectory.
or
MIGR0341W: Application install directory has been updated to
${APP_INSTALL_ROOT}\cellName\customAppDirectory\.
-traceString
This is an optional parameter. The value trace_spec specifies the trace
information that you want to collect.
To gather all trace information, specify ″*=all=enabled″ (with quotation
marks).
Logging
The WASPostUpgrade tool displays status to the screen while running. This tool
also saves a more extensive set of logging information in the
WASPostUpgrade.time_stamp.log file located in the backupDirectory/logs directory.
You can view the WASPostUpgrade.time_stamp.log file with a text editor.
Security considerations
The target system must have security disabled before migration. If you migrate
from a source configuration that has security enabled, the WASPostUpgrade
command automatically enables security for the Version 7.0 target configuration
during the migration.
Select the appropriate migration scenario for information on how to migrate from a
WebSphere Application Server Version 5.1.x or Version 6.x standalone application
server to a Version 7.0 standalone application server.
v “Migrating to a Version 7.0 standalone application server” on page 55
This article contains instructions for migrating a WebSphere Application Server
Version 5.1.x or Version 6.x standalone application server profile to a Version 7.0
standalone application server.
v “Migrating to a Version 7.0 standalone application server on a remote machine”
on page 57
This article contains instructions for migrating a WebSphere Application Server
Version 5.1.x or Version 6.x standalone application server profile to a Version 7.0
standalone application server on a remote machine.
v “Migrating a standalone application server from an operating system that is no
longer supported” on page 59
This article contains instructions for migrating from a WebSphere Application
Server Version 5.1.x or Version 6.x configuration that is running on an operating
system that Version 7.0 does not support.
54 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
Tip: For help, read Chapter 8, “Troubleshooting migration,” on page 113.
Tip: Before migrating a WebSphere Application Server Version 5.1.x or Version 6.x
standalone application server, use the backupConfig command or your own
preferred backup utility to back up your existing configuration if you want to
be able to restore it to its previous state after migration. Read the
″backupConfig command″ article in the information center for more
information. Make sure that you note the exact name and location of this
backed-up configuration.
Decide whether you want to migrate from WebSphere Application Server Version
5.1.x or Version 6.x to Version 7.0 using the Migration wizard or using the
command-line migration tools.
v Migrate from WebSphere Application Server Version 5.1.x or Version 6.x to
Version 7.0 using the Migration wizard.
1. Stop all of the WebSphere Application Server Version 5.1.x or Version 6.x
application servers that are running on the node.
Use the stopServer command from the app_server_root/bin directory. Read the
″stopServer command″ article in the information center for more information.
For example, issue the following commands to stop server1 and
server2 on the Linux® operating system:
./stopServer.sh server1
./stopServer.sh server2
If security is enabled, specify the -user and -password parameters on the
stopServer command.
You can migrate a WebSphere Application Server Version 5.1.x or Version 6.x
node without stopping it; however, you must stop the node before you can
start the Version 7.0 node that you are installing. It is not necessary to have
the node running to migrate its configuration. The migration tools can
retrieve all the configuration data while the node is stopped.
2. Install WebSphere Application Server Version 7.0.
Read the ″Installing the product and additional software″ article in the
information center for more information.
3. Optional: Use the Profile Management tool or the manageprofiles command
to create a WebSphere Application Server Version 7.0 profile.
Restriction: You cannot use the Profile Management tool to create profiles on
the following platforms:
56 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
the node running to migrate its configuration. The migration tools can
retrieve all the configuration data while the node is stopped.
2. Install WebSphere Application Server Version 7.0.
Read the ″Installing the product and additional software″ article in the
information center for more information.
3. Use the Profile Management tool or the manageprofiles command to create a
WebSphere Application Server Version 7.0 profile.
Read the ″Creating profiles using the graphical user interface″ article or the
″manageprofiles command″ article in the information center for more
information.
4. Run the WASPreUpgrade command, specifying the migration backup
directory name and the existing WebSphere Application Server directory
name.
Read “WASPreUpgrade command” on page 47 for more information.
The WASPreUpgrade tool saves selected files from the /bin directory to a
backup directory you specify on a wizard panel. Migration saves files from
the following directories to the backup directory:
– classes
– config
– installableApps
– installedApps (or an alternate directory specified by the user)
– properties
5. Run the WASPostUpgrade command, specifying the migration backup
directory.
Read “WASPostUpgrade command” on page 49 for more information.
The WASPostUpgrade tool copies the environment in the backup directory to
the WebSphere Application Server Version 7.0 standalone application server
installation.
Typically, you can use the WASPreUpgrade and the WASPostUpgrade migration
tools to upgrade from Version 5.1.x or Version 6.x to Version 7.0 on the same
machine. However, some scenarios require that you migrate the Version 5.1.x or
Version 6.x configuration on one machine to Version 7.0 on a different machine.
One of these scenarios is when you install new machines for your Version 7.0
environment but need to migrate your existing Version 5.1.x or Version 6.x
configuration from other machines.
If you find that your operating system is not supported for migration to Version
7.0, read “Migrating a standalone application server from an operating system that
is no longer supported” on page 59.
The WASPreUpgrade command saves the existing Version 5.1.x or Version 6.x
configuration into a migration-specific backup directory. The WASPostUpgrade
command uses this directory to add the old configuration settings to the new
Version 7.0 environment.
Tip: Before migrating a WebSphere Application Server Version 5.1.x or Version 6.x
standalone application server on a remote machine, use the backupConfig
command or your own preferred backup utility to back up your existing
configuration if you want to be able to restore it to its previous state after
migration. Read the ″backupConfig command″ article in the information
center for more information. Make sure that you note the exact name and
location of this backed-up configuration.
./WASPreUpgrade.sh /filepath/migration_specific_backup
/opt/WebSphere/AppServer
WASPreUpgrade C:\filepath\migration_specific_backup
C:\Program Files\WebSphere\AppServer
The WASPreUpgrade command provides status to the screen and to log files in
the migration_specific_backup directory. ASCII log file names start with the text
WASPreUpgrade and include a date and timestamp.
3. Copy the migration_specific_backup directory from the WebSphere Application
Server Version 5.1.x or Version 6.x machine to the Version 7.0 machine.
Use the ftp command, shared storage, or some other mechanism to copy the
directory to the new machine.
4. Install WebSphere Application Server Version 7.0 on the new machine.
Read the ″Installing the product and additional software″ article in the
information center for more information.
Install the same features as the earlier release.
58 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
5. Use the Profile Management tool or the manageprofiles command to create a
WebSphere Application Server Version 7.0 profile.
Restriction: You cannot use the Profile Management tool to create profiles on
the following platforms:
v 64-bit platforms
v Linux for zSeries platform for 64-bit or 31-bit
Read the ″Creating profiles using the graphical user interface″ article or the
″manageprofiles command″ article in the information center for more
information.
6. Add the WebSphere Application Server Version 5.1.x or Version 6.x
configuration to the Version 7.0 configuration.
Read “WASPostUpgrade command” on page 49 for more information.
Use the WASPostUpgrade command in the app_server_root/bin directory of the
Version 7.0 installation to add the Version 5.1.x or Version 6.x configuration to
the Version 7.0 configuration.
./WASPostUpgrade.sh /filepath/migration_specific_backup
WASPostUpgrade C:\filepath\migration_specific_backup
You have migrated WebSphere Application Server from Version 5.1.x or Version 6.x
to a remote Version 7.0 machine.
Tip: Before migrating from WebSphere Application Server Version 5.1.x or Version
6.x, use the backupConfig command or your own preferred backup utility to
back up your existing configuration if you want to be able to restore it to its
previous state after migration. Read the ″backupConfig command″ article in
Important: Your JDK must be version 1.6 or later if you want to use the
migration tools.
The JDK directory should be in the same directory as the migration
directory that you created on your local system in the last step, or you
should have a working symlink that allows Java to be invoked from that
path.
<directory>
- migration directory
- JDK/jre.pak/repository/package.java.jre/java/jre/bin/java
c. Copy the WASPreUpgrade.bat (or WASPreUpgrade.sh) and the
setupCmdLine.bat (or setupCmdLine.sh) files from the migration/bin
directory of the WebSphere Application Server Version 7.0 utilities disk to
the migration directory that you created on your local system.
d. Edit the setupCmdLine.bat or setupCmdLine.sh file in your new migration
directory.
v Change WAS_HOME to point to the fully qualified path to the migration
directory that you created
v Change JAVA_HOME to point to the fully qualified path to your IBM
Developer Kit or Java directory.
e. Ensure that the executable bit is on for the setupCmdLine.sh and
WASPreUpgrade.sh files in the migration directory that you created.
f. Run the command from the migration directory that you created.
Identify the backup directory and the location of the configuration files.
migration_directory\WASPreUpgrade migration_specific_backup_directory
file_path\WebSphere\AppServer node_name
3. Shut down the WebSphere Application Server Version 5.1.x or Version 6.x
release by stopping all server nodes in the configuration.
4. Tar or zip the migration_specific_backup directory, and FTP it to another system.
5. Install the new operating system, keeping the same host name.
If possible, keep the system name and passwords the same as on the old
system. Place any database files related to applications that you are migrating
60 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
in the same path as on the previous system. In general, try to keep paths the
same. If you do change paths and names, refer to “Migrating to a Version 7.0
standalone application server on a remote machine” on page 57. Make any
changes before running the WASPostUpgrade command as described in a later
step.
6. FTP the migration_specific_backup directory from the other system, and extract it.
7. Install WebSphere Application Server Version Version 7.0.
Read the ″Installing the product and additional software″ article in the
information center for more information.
8. Use the Profile Management tool or the manageprofiles command to create a
WebSphere Application Server Version Version 7.0 profile.
Read the ″Creating profiles using the graphical user interface″ article or the
″manageprofiles command″ article in the information center for more
information.
9. Run the WASPostUpgrade command from the Version 7.0 app_server_root/bin
directory.
Specify the migration_specific_backup directory that you extracted in an earlier
step.
Read “WASPostUpgrade command” on page 49 for the proper command
syntax.
Tip: Before migrating a WebSphere Application Server Version 5.1.x or Version 6.x
deployment manager, use the backupConfig command or your own preferred
backup utility to back up your existing configuration if you want to be able to
restore it to its previous state after migration. Read the ″backupConfig
command″ article in the information center for more information. Make sure
that you note the exact name and location of this backed-up configuration.
./stopManager.sh
stopManager.bat
Read the ″stopManager command″ article in the information center for more
information.
If you have security enabled, specify the -user and -password parameters of the
command.
You can migrate a Version 5.1.x or Version 6.x deployment manager whether it
is running or stopped. The migration tools can retrieve all the configuration
data either way. You must stop the Version 5.1.x or Version 6.x deployment
manager before you can start the Version 7.0 deployment manager that you are
installing, however, so it makes sense to stop it now.
2. Use the migration tools to migrate the Version 5.1.x or Version 6.x configuration
to Version 7.0.
The Migration wizard, which is the graphical interface to the Version 7.0
command-line migration tools (WASPreUpgrade and WASPostUpgrade), is the
recommended migration tool. For instructions and information on the
Migration wizard, read “Using the Migration wizard to migrate product
configurations” on page 27.
a. Install the Version 7.0 product on the same machine as the Version 5.1.x or
Version 6.x deployment manager.
Read the ″Installing the product and additional software″ article in the
information center for more information.
b. Determine the cell name of the Version 5.1.x or Version 6.x Network
Deployment cell.
62 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
Note: For a deployment manager migration, the Version 7.0 cell name must
match the name in the Version 5.1.x or Version 6.x configuration.
c. Optional: Create a new Version 7.0 deployment manager profile with the
same cell name as the Version 5.1.x or Version 6.x cell.
Restrictions for a deployment manager migration:
v The Version 7.0 cell name must match the cell name in the Version 5.1.x
or Version 6.x configuration.
If you create a profile with a new cell name, the migration will fail.
v Either one or the other of the following options must be true:
– The Version 7.0 deployment manager node name must be the same as
the Version 5.1.x or Version 6.x deployment manager node name.
– The Version 7.0 deployment manager node name must be different
from every node name in the Version 5.1.x or Version 6.x configuration.
Otherwise, the migration fails with the following message:
MIGR0488E: The deployment manager node name in the new configuration
({0}) cannot be the same as a nodeagent node in the old configuration.
Read the ″manageprofiles command″ article in the information center for
more information.
If you also use the same node name that you used for the Version 5.1.x or
Version 6.x cell, the node agents will still work after migration without
being restarted.
d. Stop the Version 7.0 deployment manager.
e. Use the Migration wizard to migrate the deployment manager to Version
7.0.
Read “Migrating to a Version 7.0 deployment manager using the Migration
wizard” on page 37 for more information.
f. Start the Version 7.0 deployment manager.
g. Optional: Uninstall the Version 5.1.x or Version 6.x deployment manager.
Read the ″Uninstalling the product″ article in the information center for
more information.
Perform this step only after you are certain that you have successfully
migrated the configuration of the deployment manager that you intend to
delete.
h. Read “Migrating a Version 5.1.x or Version 6.x federated node” for
information on iteratively migrating each federated node to Version 7.0.
After the deployment manager is upgraded to Version 7.0, each node in the cell
can be upgraded incrementally, one at a time. Read “Migrating a Version 5.1.x or
Version 6.x federated node” for more information.
Tip: When migrating a WebSphere Application Server Version 5.1.x or Version 6.x
federated node, you must perform the following actions if you want to be
able to roll it back to its previous state after migration:
1. Back up your existing configuration.
v Run the backupConfig command or your own preferred utility to back
up the Version 7.0 deployment manager configuration.
Important: Make sure that you note the exact name and location of this
backed-up configuration.
Read the ″backupConfig command″ article in the information center for
more information.
v Run the backupConfig command or your own preferred utility to back
up the Version 5.1.x or Version 6.x federated node configuration.
Important: Make sure that you note the exact name and location of this
backed-up configuration.
Read the ″backupConfig command″ article in the information center for
more information.
2. Migrate the federated node.
3. If necessary, you can now roll back the federated node that you just
migrated.
Read “Rolling back a federated node” on page 83 for more information.
Decide whether you want to migrate from WebSphere Application Server Version
5.1.x or Version 6.x to Version 7.0 using the Migration wizard or using the
command-line migration tools.
Over time, migrate each WebSphere Application Server Version 5.1.x or Version 6.x
federated node in the Version 7.0 cell to Version 7.0. After migrating all Version
5.1.x or Version 6.x federated nodes, use the convertScriptCompatibility script to
64 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
change the deployment manager from a node that supports backward
compatibility of Version 5.1.x or Version 6.x administration scripts to a node that
supports only Version 7.0. Read “convertScriptCompatibility command” on page 43
for more information.
Note: You can migrate a Version 5.1.x or Version 6.x node whether the node is
running or stopped. The migration tools can retrieve all the configuration
data either way. You must stop the Version 5.1.x or Version 6.x node
before you can start the Version 7.0 node that you are installing,
however, so it makes sense to stop it now.
5. Migrate as many WebSphere Application Server Version 5.1.x or Version 6.x
federated nodes as you intend to migrate by using the following procedure.
a. Determine the node name of the Version 5.1.x or Version 6.x federated node.
b. Optional: Use the WebSphere Application Server Version 7.0 Profile
Management tool or the manageprofiles command to create a application
server or custom profile, but do not federate the node.
Restriction: You cannot use the Profile Management tool to create profiles
on the following platforms:
v 64-bit platforms
v Linux for zSeries platform for 64-bit or 31-bit
Read the ″Creating profiles using the graphical user interface″ article or the
″manageprofiles command″ article in the information center for more
information.
Use the same name for the node that was used for the Version 5.1.x or
Version 6.x federated node name.
Tip: If you make any cell-level changes to the new Version 7.0 node before
migration, such as changes to virtual-host information, these changes
Note: When migrating federated nodes from Version 5.1.0 to Version 7.0,
there is a custom property of which you should be aware:
com.ibm.websphere.ObjectIDVersionCompatibility. It might be
possible to gain performance benefits after the entire cell is migrated
to Version 7.0. Read the ″Object Request Broker custom properties″
article in the information center for complete details.
d. Stop and restart each of the application servers on the migrated node.
Note: For migration to be successful, you must use the same node names and
cell names for each node that you migrate from Version 5.1.x or Version
6.x to Version 7.0.
6. If you chose the compatibility option (which is the default) and if all of your
nodes are completely migrated to WebSphere Application Server Version 7.0,
run the convertScriptCompatibility script to remove backward compatibility
from the WebSphere Application Server Version 7.0 deployment manager.
Issue the convertScriptCompatibility command from the bin directory.
v app_server_root/bin/
convertScriptCompatibility.sh
v app_server_root\bin\convertScriptCompatibility.bat
Read “convertScriptCompatibility command” on page 43 for more information.
Occasionally (after rebooting an application server machine for example), you must
restart the nodeagent server on the application server node by running the
startNode command from the profile_root/bin directory. To keep your application
server nodes running without having to access the bin directory of each one, use
the operating system to monitor and restart the node agent process on each
application server node. (You can also set up the dmgr server as a managed
66 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
process on the deployment manager node.) For more information, read the
″Automatically restarting server processes″ article in the information center.
Adding a node automatically issues the startNode command for the node.
Note: When a deployment manager is migrated, the applications in the cell are
reinstalled. Even though the name is unchanged, the application is different
from the version that was deployed on the previous release. When the
federated nodes synchronize with the migrated deployment manager,
therefore, they detect the new application and download it. After the
application has been downloaded (synchronized), the node agent uses the
new application rather than the old application. If the application is running
on any active servers, the application will appear to restart as the old
application is stopped and uninstalled and the new application is installed
and started.
Note: Select the smallest timeout value that will meet your needs. Be
prepared to wait for at least three times the timeout that you
select—once to download files to the backup directory, once to
upload the migrated files to the deployment manager, and once to
synchronize the deployment manager with the migrated node
agent.
4. Go to the following location in the backup directory that was created by
the WASPreUpgrade command:
backupDirectory/profiles/profile_name/properties
You can use this strategy to satisfy your specific maintenance-window requirement
by building the full WebSphere Application Server Version 7.0 Network
Deployment configuration in the background while the existing topology is still
running and being managed.
At this point, the WebSphere Application Server Version 7.0 deployment manager
should be running and the normal application synchronization should occur.
If you find that your operating system is not supported for migration to Version
7.0, read “Migrating a deployment manager from an operating system that is no
longer supported” on page 72.
The WASPreUpgrade command saves the existing Version 5.1.x or Version 6.x
configuration into a migration-specific backup directory. The WASPostUpgrade
command uses this directory to add the old configuration settings to the new
Version 7.0 environment.
Tip: Before migrating a WebSphere Application Server Version 5.1.x or Version 6.x
deployment manager on a remote machine, use the backupConfig command
or your own preferred backup utility to back up your existing configuration if
you want to be able to restore it to its previous state after migration. Read the
″backupConfig command″ article in the information center for more
information. Make sure that you note the exact name and location of this
backed-up configuration.
WASPreUpgrade C:\filepath\migration_specific_backup
C:\Program Files\WebSphere\AppServer -machineChange true
The WASPreUpgrade command provides status to the screen and to log files in
the migration_specific_backup directory. ASCII log file names start with the text
WASPreUpgrade and include a date and timestamp.
70 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
3. Copy the migration_specific_backup directory from the WebSphere Application
Server Version 5.1.x or Version 6.x machine to the Version 7.0 machine.
Use the ftp command, shared storage, or some other mechanism to copy the
directory to the new machine.
4. Install WebSphere Application Server Version 7.0 on the new machine.
Read the ″Installing the product and additional software″ article in the
information center for more information.
Install the same features as the earlier release.
5. Use the Profile Management Tool or the manageprofiles command to create a
WebSphere Application Server Version 7.0 profile.
Restriction: You cannot use the Profile Management tool to create profiles on
the following platforms:
v 64-bit platforms
v Linux for zSeries platform for 64-bit or 31-bit
Read the ″Creating profiles using the graphical user interface″ article or the
″manageprofiles command″ article in the information center for more
information.
The Version 7.0 deployment manager profile must have the same cell name as
the Version 5.1.x or Version 6.x profile that is being migrated.
6. Add the WebSphere Application Server Version 5.1.x or Version 6.x
configuration to the Version 7.0 configuration.
Read “WASPostUpgrade command” on page 49 for more information.
Specify -keepDmgrEnabled true when you run the WASPostUpgrade command
in a remote deployment-manager migration. If you fail to do so, the
WASPostUpgrade command will fail when it is unable to locate the Version
5.1.x or Version 6.x installation on the same machine as the Version 7.0
installation.
Use the WASPostUpgrade command in the app_server_root/bin directory of the
Version 7.0 installation to add the Version 5.1.x or Version 6.x configuration to
the Version 7.0 configuration.
./WASPostUpgrade.sh /filepath/migration_specific_backup
-keepDmgrEnabled true
WASPostUpgrade C:\filepath\migration_specific_backup
-keepDmgrEnabled true
You have migrated WebSphere Application Server from Version 5.1.x or Version 6.x
to a remote Version 7.0 machine.
Tip: Before migrating from WebSphere Application Server Version 5.1.x or Version
6.x, use the backupConfig command or your own preferred backup utility to
back up your existing configuration if you want to be able to restore it to its
previous state after migration. Read the ″backupConfig command″ article in
the information center for more information. Make sure that you note the
exact name and location of this backed-up configuration.
Important: Your JDK must be version 1.6 or later if you want to use the
migration tools.
The JDK directory should be in the same directory as the migration
directory that you created on your local system in the last step, or you
should have a working symlink that allows Java to be invoked from that
path.
72 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
<directory>
- migration directory
- JDK/jre.pak/repository/package.java.jre/java/jre/bin/java
c. Copy the WASPreUpgrade.bat (or WASPreUpgrade.sh) and the
setupCmdLine.bat (or setupCmdLine.sh) files from the migration/bin
directory of the WebSphere Application Server Version 7.0 utilities disk to
the migration directory that you created on your local system.
d. Edit the setupCmdLine.bat or setupCmdLine.sh file in your new migration
directory.
v Change WAS_HOME to point to the fully qualified path to the migration
directory that you created
v Change JAVA_HOME to point to the fully qualified path to your IBM
Developer Kit or Java directory.
e. Ensure that the executable bit is on for the setupCmdLine.sh and
WASPreUpgrade.sh files in the migration directory that you created.
f. Run the command from the migration directory that you created.
Identify the backup directory and the location of the configuration files.
migration_directory\WASPreUpgrade migration_specific_backup_directory
file_path\WebSphere\AppServer node_name
3. Shut down the WebSphere Application Server Version 5.1.x or Version 6.x
release by stopping all server nodes in the configuration.
4. Tar or zip the migration_specific_backup directory, and FTP it to another system.
5. Install WebSphere Application Server Version 7.0 on the new operating system.
Read the ″Installing the product and additional software″ article in the
information center for more information.
Install the same features as the earlier release.
6. Use the Profile Management Tool or the manageprofiles command to create a
WebSphere Application Server Version 7.0 profile.
The Version 7.0 deployment manager profile must have the same cell name as
the Version 5.1.x or Version 6.x profile that is being migrated.
Read the ″Creating profiles using the graphical user interface″ article or the
″manageprofiles command″ article in the information center for more
information.
7. Add the WebSphere Application Server Version 5.1.x or Version 6.x
configuration to the Version 7.0 configuration.
Read “WASPostUpgrade command” on page 49 for more information.
Specify -keepDmgrEnabled true when you run the WASPostUpgrade command.
If you fail to do so, the WASPostUpgrade command will fail when it is unable
to locate the Version 5.1.x or Version 6.x installation on the same machine as the
Version 7.0 installation.
Use the WASPostUpgrade command in the app_server_root/bin directory of the
Version 7.0 installation to add the Version 5.1.x or Version 6.x configuration to
the Version 7.0 configuration.
./WASPostUpgrade.sh /filepath/migration_specific_backup
-keepDmgrEnabled true
WASPostUpgrade C:\filepath\migration_specific_backup
-keepDmgrEnabled true
Tips:
v Before you run the migration tools, ensure that any application servers
hosting applications that are using a Cloudscape or a Derby database are
closed.
Otherwise, the database migration will fail.
v Before you run the migration tools, ensure that the debug migration trace is
active.
By default, this trace function is enabled. To reactivate the debug
migration trace if it is disabled, set one of the following trace options:
– all traces*=all
– com.ibm.ws.migration.WASUpgrade=all
WebSphere Application Server Version 7.0 requires Apache Derby Version 10.3 or
later. Apache Derby Version 10.3 is a pure Java database server that combines the
74 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
Derby runtime with the opportunity to use the full services of IBM Software
Support. For comprehensive information about Apache Derby Version 10.3, read
the Apache Derby Web site.
Service integration bus-enabled Web services use a Service Data Objects (SDO)
repository for storing and serving WSDL definitions. If you migrate a configuration
that uses a Cloudscape database as the SDO repository, the SDO application will
still be configured to use Cloudscape in the new configuration. Migration converts
the Cloudscape database to Derby, but you must still update any SDO
application’s backend ID to use the new database. After you migrate all of the
nodes on a server with an SDO repository application that uses Cloudscape,
perform the following actions to reset the database type used by the SDO
application on the new configuration to Derby:
1. Read about the basic usage for the installSdoRepository.jacl script inside the
script file.
2. Run the installSdoRepository.jacl script by changing to the app_server_root/bin/
directory and running the following command:
wsadmin.extension -f app_server_root/bin/installSdoRepository.jacl
-editBackendId DERBY_V10
Read the ″Installing and configuring the SDO repository″ article in the information
center for more information on upgrading the SDO repository application to
Version 7.0 .
76 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
The WebSphereConnectJDBCDriverConversion command processes resources.xml
files, and there are many options that can be specified to indicate which
resources.xml files to process.
Syntax
./WebSphereConnectJDBCDriverConversion.sh
[-profileName profile_name]
[-driverType MS | DD]
[-classPath class_path]
[-nativePath native_path]
[-pathSeparator separator]
[[-cellName ALL | cell_name [-clusterName ALL | cluster_name] |
[-applicationName ALL | application_name] |
[-nodeName ALL | node_name] [-serverName ALL | server_name]]]
[-backupConfig true | false]
[-username userID]
[-password password]
[[-traceString trace_spec [-traceFile file_name]]
WebSphereConnectJDBCDriverConversion.bat
[-profileName profile_name]
[-driverType MS | DD]
[-classPath class_path]
[-nativePath native_path]
[-pathSeparator separator]
[[-cellName ALL | cell_name [-clusterName ALL | cluster_name] |
[-applicationName ALL | application_name] |
[-nodeName ALL | node_name] [-serverName ALL | server_name]]]
[-backupConfig true | false]
[-username userID]
[-password password]
[[-traceString trace_spec [-traceFile file_name]]
Parameters
-profileName profile_name
This optional parameter is used to specify a specific profile configuration
in the Version 7.0 environment.
If this parameter is not specified, the default profile is used. If the default
is not set or cannot be found, an error is returned.
If the command is run from within the profile_name/bin directory, it is
implicit that the profile_name profile should be migrated and this parameter
is not needed.
-driverType MS | DD
This required parameter is used to indicate the type of conversion that you
want to perform.
Specifying MS converts to the Microsoft SQL Server 2005 JDBC Driver, and
specifying DD converts to the DataDirect Connect JDBC driver.
-classPath class_path
This required parameter is used to specify the class path for the new JDBC
driver.
78 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
-traceFile file_name
This optional parameter is used with -traceString to gather trace
information for use by IBM service personnel.
Set the ownership of the profile or deployment manager directory to be the same
as the user under which WebSphere Application Server is to run.
This must be done for the deployment manager or application servers to run
correctly.
where the profile name is dmgr run as a user in wasadmin with the primary group
wasndgrp.
You can now run either a deployment manager or application server as root.
Generally, migration does not modify anything in the configuration of the prior
release; however, there are cases where minimal changes are made that are
reversible.
v To roll back a Version 7.0 deployment manager and its federated nodes to
Version 5.1.x or Version 6.x, follow the instructions in “Rolling back a Network
Deployment cell.”
v To roll back a Version 7.0 federated node to Version 5.1.x or Version 6.x, follow
the instructions in “Rolling back a federated node” on page 83.
v To roll back a Version 7.0 standalone application server to Version 5.1.x or
Version 6.x, follow the instructions in “Rolling back a standalone application
server” on page 85.
The configuration should now be returned to the state that it was in before
migration.
You can now restart the migration process if you want to do so.
80 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
Best practice: When migrating a Version 5.1.x or Version 6.x Network Deployment
cell, the best practice is to perform the following actions if you want
to be able to roll it back to its previous state after migration:
1. Back up your existing configuration.
v Run the backupConfig command or your own preferred utility
to back up the Version 5.1.x or Version 6.x deployment
manager configuration.
Important: Make sure that you note the exact name and
location of this backed-up configuration.
Read the ″backupConfig command″ article in the information
center for more information.
v Run the backupConfig command or your own preferred utility
to back up the Version 5.1.x or Version 6.x federated node
configurations.
Important: Make sure that you note the exact name and
location of each of these backed-up configurations.
Read the ″backupConfig command″ article in the information
center for more information.
2. Migrate the Network Deployment cell.
1. Stop all of the servers and node agents that are currently running in the
Version 7.0 environment.
2. If you chose to disable the previous deployment manager when you migrated
to the Version 7.0 deployment manager, perform one of the following actions.
Important: Make sure that you restore the same backed-up configuration
that you created just before you migrated the deployment
manager.
Read the ″restoreConfig command″ article in the information center for
more information.
b. If you did not back up your previous deployment manager configuration,
use the wsadmin command to run the migrationDisablementReversal.jacl
script from the Version 5.1.x or Version 6.x profile_root/bin directory of the
deployment manager that you need to roll back from Version 7.0.
In a Linux environment, for example, use the following parameters:
./wsadmin.sh -f migrationDisablementReversal.jacl -conntype NONE
Important: Make sure that you restore the same backed-up configuration
that you created just before you migrated the federated node.
Read the ″restoreConfig command″ article in the information center for
more information.
b. If you did not back up your previous federated node configuration, use the
wsadmin command to run the migrationDisablementReversal.jacl script
from the Version 5.1.x or Version 6.x profile_root/bin directory of the
federated node.
In a Linux environment, for example, use the following
parameters:
./wsadmin.sh -f migrationDisablementReversal.jacl -conntype NONE
where node_name is the name of the federated node that you want
to roll back.
2) If you see a serverindex.xml_disabled file in this directory, perform
the following actions:
a) Delete or rename the serverindex.xml file.
b) Rename the serverindex.xml_disabled file to serverindex.xml.
4. Synchronize the federated nodes if they were ever running when the Version
7.0 deployment manager was running.
Read the ″Synchronizing nodes with the wsadmin tool″ article in the
information center for more information.
5. If you chose to keep the installed applications in the same location as the prior
release during migration to Version 7.0 and any of the Version 7.0 applications
are not compatible with the prior release, install applications that are
compatible.
6. Delete the Version 7.0 profiles.
Read the ″Deleting a profile″ article in the information center for more
information.
7. Start the rolled-back deployment manager and its federated nodes in the
Version 5.1.x or Version 6.x environment.
The configuration should now be returned to the state that it was in before
migration.
82 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
You can now restart the migration process if you want to do so.
Best practice: When migrating a Version 5.1.x or Version 6.x federated node, the
best practice is to perform the following actions if you want to be
able to roll it back to its previous state after migration:
1. Back up your existing configuration.
a. Run the backupConfig command or your own preferred
utility to back up the Version 7.0 deployment manager
configuration.
Important: Make sure that you note the exact name and
location of this backed-up configuration.
Read the ″backupConfig command″ article in the information
center for more information.
b. Run the backupConfig command or your own preferred
utility to back up the Version 5.1.x or Version 6.x federated
node configuration.
Important: Make sure that you note the exact name and
location of this backed-up configuration.
Read the ″backupConfig command″ article in the information
center for more information.
2. Migrate the federated node.
3. If necessary, you can now roll back the federated node that you
just migrated.
Important: If you do not have a backup copy of your Version 7.0 deployment
manager configuration as it was before you migrated the Version 5.1.x
or Version 6.x federated node that you want to roll back, you cannot
use the procedure described in this article and you must roll back your
whole cell as described in “Rolling back a Network Deployment cell”
on page 80.
You must perform all of the backup and rollback actions for each migrated
federated node before you proceed to migrate another federated node.
1. Run the backupConfig command or your own preferred utility to back up the
Version 7.0 deployment manager configuration at the current state.
Important: Make sure that you note the exact name and location of this
backed-up configuration.
Read the ″backupConfig command″ article in the information center for more
information.
2. Stop all servers and the node agent on the Version 7.0 federated node that you
want to roll back.
3. Restore your previous configuration.
Important:
v Make sure that you restore the same backed-up
configuration that you created just before you migrated the
federated node.
v If you have made changes to your environment (application
or configuration changes for example), these changes are
rolled back at the same time and cause the other nodes to
force synchronization with the deployment manager.
Read the ″restoreConfig command″ article in the information center for
more information.
b. Perform one of the following actions to restore the Version 5.1.x or Version
6.x configuration for the federated node.
v Run the restoreConfig command or your own preferred utility to restore
the Version 5.1.x or Version 6.x configuration.
84 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
7. If you chose to keep the installed applications in the same location as the
prior release during migration to Version 7.0 and any of the Version 7.0
applications are not compatible with the prior release, install applications that
are compatible.
8. Start the rolled-back Version 5.1.x or Version 6.x federated node and servers.
9. Validate that the configuration is satisfactory.
This is the last chance to undo the rollback action by restoring the
deployment-manager configuration that you backed up in the first step.
10. Delete the Version 7.0 profile for the federated node that you rolled back to
Version 5.1.x or Version 6.x.
Read the ″Deleting a profile″ article in the information center for more
information.
The configuration should now be returned to the state that it was in before
migration.
You can now restart the migration process if you want to do so.
Best practice: When migrating a Version 5.1.x or Version 6.x standalone application
server, the best practice is to perform the following actions if you
want to be able to roll it back to its previous state after migration:
1. Run the backupConfig command or your own preferred utility
to back up the Version 5.1.x or Version 6.x standalone application
server configuration.
Important: Make sure that you note the exact name and location
of this backed-up configuration.
Read the ″backupConfig command″ article in the information
center for more information.
2. Migrate the standalone application server.
3. If necessary, you can now roll back the standalone application
server that you just migrated.
1. Stop all of the servers that are currently running in the Version 7.0
environment.
2. Perform one of the following actions to restore the Version 5.1.x or Version 6.x
configuration for the standalone application server.
v Run the restoreConfig command or your own preferred utility to restore the
Version 5.1.x or Version 6.x configuration.
Important: Make sure that you restore the same backed-up configuration
that you created just before you migrated this standalone
application server.
Read the ″restoreConfig command″ article in the information center for more
information.
v Use the wsadmin command to run the migrationDisablementReversal.jacl
script from the Version 5.1.x or Version 6.x profile_root/bin directory of the
standalone application server.
The configuration should now be returned to the state that it was in before
migration.
You can now restart the migration process if you want to do so.
86 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
Chapter 3. Migrating Web server configurations
You can migrate a Web server from supporting an earlier version of WebSphere
Application Server to support the current version.
1. Install the IBM HTTP Server Version 7.0 and its plug-in or a plug-in for another
supported Web server.
Install the HTTP Server and its plug-in on a different machine with the
following procedure:
a. Insert the product disk into the machine.
b. Close the launchpad if it starts automatically.
c. Change directories to the IHS directory on the product disk.
d. Install the IBM HTTP Server.
Run the appropriate installation script for your platform.
v InstallIHS.sh
v InstallIHS.bat
This script installs the plug-in that you need and makes the necessary
configuration changes for the supported Web server.
IBM HTTP Server Version 7.0 can coexist with earlier versions, or you can
upgrade earlier versions to Version 7.0. Install Version 7.0 into the same
directory structure as the earlier version to upgrade that version.
Note: The IHS ISMP installer will not allow installing into the previous
directory. The target directory MUST be empty.
If you install the HTTP Server into a different directory, Version 7.0 coexists
with the previous version. By default, the administration server and the Web
Server use the same ports as the previous version, which causes a conflict.
However, you can change the port assignments on the port assignment panel of
the WebSphere Application Server Installation wizard or the Profile
Management tool. Read the ″Installing the product and additional software″
article in the information center for more information.
v Change the port number assignments for the new installation if you install
into a separate directory. You can change port numbers on the coexistence
panel. You can back track through the Installation wizard and change the
port settings if you have not already done so. Or, you can change the port
settings after installation in the httpd.conf file in the HTTP Server directory.
v Update the IBM HTTP Server httpd.conf configuration entries to remove
entries for earlier WebSphere Application Server versions if you install into
the same directory as an earlier version.
Versions 5.1.x, 6.x, and 7.0 of WebSphere Application Server use the same
HTTP transport plug-in binary module. If the Web server configuration file
contains WebSphere Application Server Version 5.1.x or Version 6.x plug-in
information, you must manually remove it. Otherwise when the HTTP Server
attempts to start the second Version 7.0 plug-in binary module, there is an
error. The error indicates that the module is already loaded.
The configuration file might contain duplicate entries for accessing
WebSphere Application Server samples. Remove any aliases for previous
versions and retain the Version 7.0 entries:
88 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
plugin-cfg.xml file generated in the administrative console has a granularity that
allows each application to be mapped to its specific Web or application server.
v To set up the administrative console so that you can use it to manage the Web
server plug-in configuration, you must first create a default Web server
configuration and then use the administrative console to add the plug-in
properties from your migrated plugin-cfg.xml file to this Web server
configuration.
– To create a default Web server configuration and then add the plug-in
properties from your migrated plugin-cfg.xml file in a Network Deployment
configuration, use the Version 6.x administrative console to perform the
following tasks:
1. Create a default Web server configuration.
Read the ″Setting up a local Web server″ article or the ″Setting up a
remote Web server″ article in the information center for more information.
2. Add the plug-in properties from your migrated plugin-cfg.xml file to this
Web server configuration.
Read the ″Communicating with Web servers″ and ″Web server plug-in
configuration properties″ articles in the information center for more
information.
– To create a default Web server configuration and then add the plug-in
properties from your migrated plugin-cfg.xml file in a standalone application
server configuration, perform the following tasks:
1. Use the Version 7.0 Plug-ins installation wizard to create a default Web
server configuration.
Read the ″Installing Web server plug-ins″ article in the information center
for more information.
2. Use the Version 7.0 administrative console to edit the configuration and
define the plug-in properties.
Read the ″Communicating with Web servers″ and ″Web server plug-in
configuration properties″ articles in the information center for more
information.
90 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
Chapter 4. Migrating administrative scripts
You can migrate administrative scripts using scripting and the wsadmin tool.
There are a few changes to be aware of that are required for your existing scripts
when moving to WebSphere Application Server Version 7.0. In general, the
administration model has changed very little. However, there are some changes
required when moving from Version 5.1.x to Version 7.0.
v Be aware of the implications of migrating JMS applications from the embedded
messaging in WebSphere Application Server Version 5.1.x to the default
messaging provider in WebSphere Application Server Version 7.0.
v A new version of Jacl (1.3.2) was shipped beginning with WebSphere Application
Server Version 6.x. With this Jacl version, regexp command supports only Tcl 8.0
regexp command syntax. If your existing Version 5.1.x Jacl script uses the regexp
command syntax that is supported in Jacl 1.2.6 but not anymore in Jacl 1.3.2,
you might not get a match anymore or you might get a compile error for your
regexp command similar to the following:
com.ibm.bsf.BSFException: error while eval’ing Jacl expression:
couldn’t compile regular expression pattern: ?+* follows nothing
while executing
"regexp {(?x)
..."
("if" test expression)
invoked from within
"if {[regexp {(?x)
..."
(file testregexp.jacl line 2)
(file line 2)
invoked from within
"source testregexp.jacl"
There is no workaround for this regression problem. Jacl has indicated that this
is by design and there is no simple patch to fix this design decision.
v For WSADMIN $AdminConfig: The PME CacheInstanceService type is no longer
used. If your scripts contain code to set the enable attribute on the
CacheInstanceService type, remove the code. It is not needed in Version 7.0.
v There are a few changes to be aware of that are required for your existing
Version 5.1.x scripts when moving to WebSphere Application Server Version 7.0.
These types of changes can be evolved directly without the assistance of script
compatibility support. The data can be accessed from multiple locations,
including the old and new locations. As long as the new location is not updated,
92 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
if {[$AdminConfig showAttribute $prop name] == "allowConfigOverwrites"} {
set foundAllowConfigOverwrites $prop
break
}
}
}
if {$foundAllowConfigOverwrites == ""} {
$AdminConfig create Property $configRepository {{name allowConfigOverwrites} {value true}}
} else {
$AdminConfig modify $foundAllowConfigOverwrites {{value true}}
}
$AdminConfig save
Using Jython:
s1AdminService = AdminConfig.getid(’/Server:dmgr/AdminService:/’)
configRepository = AdminConfig.showAttribute(s1AdminService, ’configRepository’)
props = AdminConfig.showAttribute(configRepository, ’properties’)
foundAllowConfigOverwrites = ’’
if props != ’[]’:
properties = props[1:len(props)-1].split(’ ’)
for prop in properties:
name = AdminConfig.showAttribute(prop, ’name’)
if name == ’allowConfigOverwrites’:
foundAllowConfigOverwrites = prop
break
if len(foundAllowConfigOverwrites) != 0:
AdminConfig.modify(foundAllowConfigOverwrites, [[’value’, ’true’]])
else:
AdminConfig.create(’Property’, configRepository, [[’name’, ’allowConfigOverwrites’],
[’value’, ’true’]])
AdminConfig.save()
2. Restart the deployment manager. From the bin directory of the deployment
manager profile, run the following:
stopManager
startManager
./stopManager.sh
./startManager.sh
3. Allow configuration overwrite, for example:
Using Jacl:
$AdminConfig setSaveMode overwriteOnConflict
Using Jython:
AdminConfig.setSaveMode(’overwriteOnConflict’)
The location of the transaction logs directory attribute has changed from the
ApplicationServer::TransactionService to the ServerEntry::recoveryLogs. As
long as the new location is not used, the value from the old location will continue
to be used. Scripts that modify the old location can still be used; that value will
take effect until a value in the new location is set. The change to scripts to use the
new location is as follows:
Old location:
v Using Jacl:
set transService [$AdminConfig list TransactionService $server1]
$AdminConfig showAttribute $transService transactionLogDirectory
# Select one entry from the list, e.g the entry for server1:
serverEntryId = AdminConfig.getid("/ServerEntry:server1")
serverEntry = AdminConfig.list("ServerEntry", serverEntryId)
The following changes can be made with with script compatibility support.
v HTTP transports: the architecture uses the new channel framework. HTTP
definitions are mapped on top of this support. When compatibility mode is
chosen, the old HTTPTransport objects are migrated and mapped onto the
channel architecture. Existing scripts can modify these objects and will run
unchanged.
v Process definition: The name of this object is changed from processDef to
processDefs. You can mitigate this change by using the compatibility mode
mapping provided by the migration tools. The change to scripts to use the new
location is as follows:
– Old example:
- Using Jacl:
set processDef [$AdminConfig list JavaProcessDef $server1]
set processDef [$AdminConfig showAttribute $server1 processDefinition]
Using Jython:
processDef = AdminConfig.list(’JavaProcessDef’, server1)
print processDef
– New example. Identify the process definition belonging to this server and
assign it to the processDefs variable:
- Using Jacl:
set processDefs [$AdminConfig list JavaProcessDef $server1]
set processDefs [$AdminConfig showAttribute $server1 processDefinitions]
Using Jython:
processDefs = AdminConfig.list(’JavaProcessDef’, server1)
print processDefs
94 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
set httpPort 7575
set server [$AdminConfig getid /Cell:myCell/Node:myNode/Server:server1/]
set transports [$AdminConfig list HTTPTransport $server]
set transport [lindex $transports 0]
set endPoint [$AdminConfig showAttribute $transport address]
$AdminConfig modify $endPoint [list [list port $httpPort]]
$AdminConfig save
Using Jython:
httpPort = 7575
server = AdminConfig.getid("/Cell:myCell/Node:myNode/Server:server1/")
transports = AdminConfig.list("HTTPTransport", server).split(java.lang.System.getProperty("line.separator"))
transport = transports[0]
endPoint = AdminConfig.showAttribute(transport, "address")
AdminConfig.modify(endPoint, [["port", httpPort]])
AdminConfig.save()
v wsadmin Version 6.x
Using Jacl:
set serverNm server1
set newPort 7575
set node [$AdminConfig getid /Cell:myCell/Node:myNode/]
set TCS [$AdminConfig getid /Cell:myCell/Node:myNode/Server:server1/TransportChannelService:/]
set chains [$AdminTask listChains $TCS {-acceptorFilter WebContainerInboundChannel}]
$AdminConfig save
Using Jython:
serverNm = "server1"
newPort = "7575"
node = AdminConfig.getid("/Cell:myCell/Node:myNode/")
TCS = AdminConfig.getid("/Cell:myCell/Node:myNode/Server:server1/TransportChannelService:/")
chains = AdminTask.listChains(TCS, "[-acceptorFilter WebContainerInboundChannel]").split(java.lang.System.getProperty("line.separator"))
AdminConfig.save()
When migrating to Version 7.0, you can use the “WASPreUpgrade command” on
page 47 to save the configuration of your previously installed version into a
migration-specific backup directory. When migration is complete, you can use the
“WASPostUpgrade command” on page 49 to retrieve the saved configuration and
WASPostUpgrade script to migrate your previous configuration. The
-scriptCompatibility parameter for the WASPostUpgrade command is used to
specify whether to maintain the Version 5.1.x or 6.x configuration definitions or to
upgrade the format to Version 7.0 configuration definitions. If you used the default
value, or -scriptCompatibility true when migrating, you do not need to perform
this task. If you set the scriptCompatibility parameter to false during migration,
you may notice that your existing administration scripts for SSL configurations do
not work correctly. If this occurs, use this task to convert your Version 5.1.x or 6.x
SSL configuration definitions to Version 7.0 This process creates a new SSL
configuration based on the existing configuration.
1. Create a key store that references the key store attributes in the old
configuration.
a. In the existing configuration, find the keyFileName, keyFilePassword, and
keyFileFormat attributes.
96 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
keyFileName="${install_root}/etc/MyServerKeyFile.jks"
keyFilePassword="password" keyFileFormat="JKS"
b. Use the keyFileName, keyFilePassword, and keyFileFormat attributes to
create a new KeyStore object. For this example, set the name as
″DefaultSSLSettings_KeyStore″.
Using Jacl:
$AdminTask createKeyStore {-keyStoreName DefaultSSLSettings_KeyStore -keyStoreLocation
${install_root}/etc/MyServerKeyFile.jks -keyStoreType JKS -keyStorePassword
password -keyStorePasswordVerify password }
2. Create a trust store that references the trust store attributes from the existing
configuration.
a. Find the trustFileName, trustFilePassword, and trustFileFormat attributes
in the existing configuration.
trustFileName="$install_root/etc/MyServerTrustFile.jks" trustFilePassword="password" trustFileFormat="JKS"
3. Create a new SSL configuration using the new key store and trust store. Include
any other attributes from the existing configuration which are still valid.
Use a new alias for your updated SSL configuration. You can not create an SSL
configuration with the same name as your existing configuration.
Using Jacl:
$AdminTask createSSLConfig {-alias DefaultSSLSettings -trustStoreName DefaultSSLSettings_TrustStore
-keyStoreName DefaultSSLSettings_KeyStore -keyManagerName IbmX509 -trustManagerName IbmX509
-clientAuthentication true -securityLevel HIGH -jsseProvider IBMJSSE2 -sslProtocol SSL }
Coexistence support
Coexistence is a state in which multiple installations and multiple nodes from
different versions of WebSphere Application Server run independently in the same
environment at the same time.
WebSphere Application Server Version 7.0 products can coexist with the following
supported versions:
v WebSphere Application Server Version 5.1.x
v WebSphere Application Server Network Deployment Version 5.1.x
v WebSphere Application Server Version 6.x
v WebSphere Application Server Network Deployment Version 6.x
All combinations of Version 5.1.x products, Version 6.x products, and Version 7.0
products can coexist so long as there are no port conflicts.
WebSphere Application Server Version 5.1.x and Version 6.x clients can coexist with
Version 7.0 clients.
WebSphere Application Server Version 5.1.x and Version 6.x products can coexist
with Version 7.0 products.
Table 3. WebSphere Application Server Version 5.1.x, Version 6.x, and Version 7.0 multiversion coexistence support
WebSphere Application Server Version
Installed 5.1.x WebSphere Application Server Version 6.x WebSphere Application Server Version 7.0
product Application Network Application Network Application Network
Express Express Express
Server Deployment Server Deployment Server Deployment
WebSphere
Application
Supported Supported Supported Supported Supported Supported Supported Supported Supported
Server
Version 5.1.x
WebSphere
Application
Server
Supported Supported Supported Supported Supported Supported Supported Supported Supported
Network
Deployment
Version 5.1.x
WebSphere
Application
Server
Supported Supported Supported Supported Supported Supported Supported Supported Supported
Integration
Server
Version 5.1.x
WebSphere
Application
Supported Supported Supported Supported Supported Supported Supported Supported Supported
Server clients
Version 5.1.x
WebSphere
Application
Supported Supported Supported Supported Supported Supported Supported Supported Supported
Server
Version 6.x
WebSphere
Application
Server
Supported Supported Supported Supported Supported Supported Supported Supported Supported
Network
Deployment
Version 6.x
WebSphere
Application
Supported Supported Supported Supported Supported Supported Supported Supported Supported
Server clients
Version 6.x
WebSphere
Application
Supported Supported Supported Supported Supported Supported Supported Supported Supported
Server
Version 7
WebSphere
Application
Server
Supported Supported Supported Supported Supported Supported Supported Supported Supported
Network
Deployment
Version 7.0
100 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
Table 3. WebSphere Application Server Version 5.1.x, Version 6.x, and Version 7.0 multiversion coexistence
support (continued)
WebSphere Application Server Version
Installed 5.1.x WebSphere Application Server Version 6.x WebSphere Application Server Version 7.0
product Application Network Application Network Application Network
Express Express Express
Server Deployment Server Deployment Server Deployment
WebSphere
Application
Supported Supported Supported Supported Supported Supported Supported Supported Supported
Server clients
Version 7.0
102 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
Use the netstat -a command to check existing port assignments. Analyze the
port assignments to determine 12 sequential free ports.
This procedure assumes that no port assignments exist between 3320 and
3380.
c. Change directories to the bin directory of the new profile.
Assume that you create an application server profile named V70MngNode
in the default installation root directory on a Linux system.
cd /opt/IBM/WebSphere/AppServer/profiles/V70MngdNode/bin
d. Use the addNode command with the -startingport parameter to federate the
node into the deployment manager cell and to assign ports from a
beginning value.
Assume that the deployment manager has the following characteristics:
v Host name is the domain name system address: nittany.ibm.raleigh.com
v JMX connector type: remote method invocation (RMI)
v RMI port assignment: 8879
v Security status: Enabled
v Applications to install: DefaultApplication and the samples
In a Linux environment, for example, issue the following command:
./addNode.sh nittany.ibm.raleigh.com \
-conntype RMI 8879 \
-includeapps \
-user lions44 \
-password PSU
-startingport 3333
The \ character is a continuation character for using more than one line to
submit commands.
The -startingport parameter supplies the base port number for all node agent
ports and increments all of the port values from the starting point. The
nonconflicting port assignments let the new node agent run when the Version
5.1.x or Version 6.x node agent process is already running.
This procedure results in the ability to start your Version 5.1.x or Version 6.x
node at the same time as your Version 7.0 node. The node agents can run on
the same server.
You can also assign ports individually using the -portprops parameter. The
parameter identifies a flat file of key words and port number assignments that
you must create. The following example of a portprops file shows all key
words and their default port assignments:
WC_defaulthost 9081
WC_adminhost 9062
WC_defaulthost_secure 9444
WC_adminhost_secure 9045
BOOTSTRAP_ADDRESS 2810
SOAP_CONNECTOR_ADDRESS 8881
SAS_SSL_SERVERAUTH_LISTENER_ADDRESS 9901
CSIV2_SSL_SERVERAUTH_LISTENER_ADDRESS 9201
CSIV2_SSL_MUTUALAUTH_LISTENER_ADDRESS 9102
ORB_LISTENER_ADDRESS 9900
CELL_DISCOVERY_ADDRESS 7272
DCS_UNICAST_ADDRESS 9354
After migrating a Version 5.1.x or Version 6.x deployment manager to a Version
7.0 deployment manager, you can migrate the Version 5.1.x or Version 6.x
federated nodes incrementally. Read “Migrating a Version 5.1.x or Version 6.x
federated node” on page 63 for more information.
This is not a typical scenario. One of the main goals of multiple-profile support is
to minimize the need for scenarios like this. One reason that you might want to
install two or more instances of WebSphere Application Server Version 7.0 on the
same machine might be a need to have different fix levels of the product on a
machine for some reason.
1. Use the Installation wizard to install another set of the core product files as
described in the ″Installing the product and additional software″ article in the
information center.
Select the new installation option from the Installation wizard panel to install a
new instance instead of adding features to the last installation and to install
into a separate profile directory.
2. Use the Profile Management tool or the manageprofiles command to create
multiple application-server processes.
During profile creation using the Profile Management tool, you can specify
your port settings. Read the ″Creating profiles using the graphical user
interface″ article in the information center for more information.
During profile creation, the manageprofiles command can use port values that
you specify instead of the default port values. You can use a port file, specify a
starting port, or accept the default port values. Read the ″manageprofiles
command″ article in the information center for more information.
3. If you have a node that you cannot start because of port conflicts, change port
assignments to nonconflicting ports in configuration files.
Use one of the following methods:
v Use the updatePorts tool to change port settings.
Read the ″Updating ports in an existing profile″ article in the information
center for more information.
v Edit the profile_root/config/cells/cell_name/nodes/node_name/
serverindex.xml file to change the port settings, or use scripting to change
the values.
104 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
Chapter 6. Interoperating
WebSphere Application Server Version 7.0 is interoperable with other versions of
the product under certain conditions.
You can upgrade a portion of the nodes in a cell to WebSphere Application Server
Version 7.0 while leaving others at the older release level. This means that, for a
period of time, you might be administering servers that are at the current release
and servers that are running the newer release in the same cell.
All fixes are available on the Support site for WebSphere Application Server
products.
Interim fix PQ84384:
The transaction service is changed so that when a transaction is marked
for rollbackOnly in a subordinate server, the superior server will be
informed.
This will allow applications running in the superior server to detect this
status change.
2. Follow the required guidelines for WebSphere Application Server Version 5.1.x.
Guideline 1:
Be aware of the level of WebSphere Application Server in which each
function you use is supported. Applications that you intend to be
interoperable must only use function that is supported by all levels of
WebSphere Application Server in the cluster. For example, applications
that use the commonj.timer.TimerManager resource, which was new in
Version 6.0, should not be deployed to a cluster including both Version
5.1.x and Version 7.0 servers.
Guideline 2:
If you run related cross-domain interoperating applications (one server
is in rtp.raleigh.ibm.com and the other is in cn.ibm.com for example),
you need to use fully qualified host names (host9.rtp.raleigh.ibm.com
instead of just host9 for example) when installing WebSphere
Application Server Version 7.
Guideline 3:
If you want to interoperate Version 7.0 with Version 5.1.x, you must be
at or above the Version 5.1.1.1 level. Older levels of Version 5.1 do not
support interoperability with Version 7.0.
3. Upgrade the Software Development Kit (SDK) used to one supported by
Version 7.0.
Read Recommended fixes for WebSphere Application Server for more
information.
106 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
Chapter 7. Configuring ports
When you configure WebSphere Application Server resources or assign port
numbers to other applications, you must avoid conflicts with other assigned ports.
In addition, you must explicitly enable access to particular port numbers when you
configure a firewall.
1. Review the port number settings, especially when you are planning to coexist.
2. Optional: Change the port number settings.
During installation, you can use the Installation wizard as described in the
″Installing the product and additional software″ article in the information
center.
You can set port numbers when configuring the product after installation.
v During profile creation using the manageprofiles command, you can accept
the default port values or you can specify your port settings. If you want to
specify ports, you can do so in any of the following ways:
– Specify the use of a port file that contains the port values.
– Specify the use of a starting port value.
– Specify the use of the default port values.
Read the ″manageprofiles command″ article in the information center for
more information.
v During profile creation using the Profile Management tool, you can accept
the port settings recommended by the tool or you can specify your port
settings.
Read the ″Creating profiles using the graphical user interface″ article in the
information center for more information.
You can perform one of the following actions to change port settings after
installation:
v Use the updatePorts tool to change port settings.
Read the ″Updating ports in an existing profile″ article in the information
center for more information.
v Edit the profile_root/config/cells/cell_name/nodes/node_name/
serverindex.xml file to change the port settings, or use scripting to change
the values.
If ports are already defined in a configuration being migrated, the migration tools
fix the port conflicts in the Version 7.0 configuration and log the changes for your
verification .
108 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
Table 5. Port definitions for WebSphere Application Server Version 7.0 (continued)
Port Name Default Value Files
Standalone Federated Deployment Administrative Job Manager Secure Proxy Server Administrative
Application Server Application Server Manager Agent Subsystem
Bootstrap Port 2809 2809 9809 9807 9808 ---- ---- serverindex.xml
(BOOTSTRAP
_ADDRESS)
Cell Discovery ---- ---- 7277 ---- ---- ---- ----
Address (CELL
_DISCOVERY
_ADDRESS)
CSIV2 Client 9402 9405 9402 9402 9402 ---- ----
Authentication
Listener Port (CSIV2
_SSL
_MUTUALAUTH
_LISTENER
_ADDRESS)
CSIV2 Server 9403 9406 9403 9403 9403 ---- ----
Authentication
Listener Port (CSIV2
_SSL
_SERVERAUTH
_LISTENER
_ADDRESS)
High Availability 9353 9353 9352 ---- ---- ---- ----
Manager
Communication Port
(DCS _UNICAST
_ADDRESS)
Internal JMS Server 5557 ---- ---- ---- ---- ---- ----
Port (JMSSERVER
_SECURITY _PORT)
IPC Connector Port 9633 9633 9632 9630 9631 9633 9634
(IPC _CONNECTOR
_ADDRESS)
MQ Transport Port 5558 5558 ---- ---- ---- ---- ----
(SIB _MQ
_ENDPOINT
_ADDRESS)
MQ Transport 5578 5578 ---- ---- ---- ---- ----
Secure Port (SIB
_MQ _ENDPOINT
_SECURE
_ADDRESS)
ORB Listener Port 9100 0 9100 9098 9099 ---- ----
(ORB _LISTENER
_ADDRESS)
RMI Connector Port ---- ---- ---- ---- ---- ---- 9810
(RMI
_CONNECTOR
_ADDRESS)
JSR 160 RMI ---- ---- ---- ---- ---- ---- 9811
Connector Port
(JSR160RMI
_CONNECTOR
_ADDRESS)
SAS _SSL 9401 9404 9401 9401 9401 ---- ----
_SERVERAUTH
_LISTENER
_ADDRESS
Service Integration 7276 7276 ---- ---- ---- ---- ----
Port (SIB
_ENDPOINT
_ADDRESS)
Service Integration 7286 7286 ---- ---- ---- ---- ----
Secure Port (SIB
_ENDPOINT
_SECURE
_ADDRESS)
SIP Container Port 5060 5060 ---- ---- ---- 5060 ----
(SIP
_DEFAULTHOST)
SIP Container Secure 5061 5061 ---- ---- ---- 5061 ----
Port (SIP
_DEFAULTHOST
_SECURE)
SOAP Connector 8880 8880 8879 8877 8876 ---- 8881
Port (SOAP
_CONNECTOR
_ADDRESS)
IBM HTTP Server 80 ---- ---- ---- ---- ---- ---- virtualhosts.xml,
Port plugin-cfg.xml, and
web _server
_root/conf/
httpd.conf
IBM HTTPS Server 8008 ---- ---- ---- ---- ---- ---- web _server
Administration Port _root/conf/
admin.conf
When you federate an application server node into a deployment-manager cell, the
deployment manager instantiates the node agent server process on the application
server node. The node agent server uses these port assignments by default.
When you federate an application server node into a deployment manager cell, the
deployment manager instantiates the node agent server process on the application
server node. The node agent server uses these port assignments by default.
110 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
Table 8. Port definitions for the Version 6.1 node agent server process
Port Name Default Value File
Bootstrap Port (BOOTSTRAP _ADDRESS) 2809 serverindex.xml
CSIV2 Server Authentication Port (CSIV2 _SSL _SERVERAUTH 9201
_LISTENER _ADDRESS)
CSIV2 Client Authentication Listener Port (CSIV2 _SSL 9202
_MUTUALAUTH _LISTENER _ADDRESS)
High Availability Manager Communication Port (DCS _UNICAST 9354
_ADDRESS)
Node Discovery Address (NODE _ DISCOVERY _ADDRESS) 7272
Node IPV6 Discovery Address (NODE _IPV6 _MULTICAST 5001
_DISCOVERY _ADDRESS)
Node Multicast Discovery Address (NODE _MULTICAST 5000
_DISCOVERY _ADDRESS)
ORB Listener Port (ORB _LISTENER _ADDRESS) 9100
SAS _SSL _SERVERAUTH _LISTENER _ADDRESS 9901
SOAP Connector Port (SOAP _CONNECTOR _ADDRESS) 8879
When you federate an application server node into a deployment manager cell, the
deployment manager instantiates the node agent server process on the application
server node. The node agent server uses these port assignments by default.
Table 10. Port definitions for the Version 6.0.x node agent server process
Port Name Default Value File
BOOTSTRAP _ADDRESS 2809 serverindex.xml
ORB _LISTENER _ADDRESS 9900
SAS _SSL _SERVERAUTH _LISTENER _ADDRESS 9901
CSIV2 _SSL _MUTUALAUTH _LISTENER _ADDRESS 9202
CSIV2 _SSL _SERVERAUTH _LISTENER _ADDRESS 9201
NODE _DISCOVERY _ADDRESS 7272
NODE _MULTICAST _DISCOVERY _ADDRESS 5000
NODE _IPV6 _MULTICAST _DISCOVERY _ADDRESS 5001
DCS _UNICAST _ADDRESS 9354
DRS _CLIENT _ADDRESS 7888
SOAP _CONNECTOR _ADDRESS 8878
When you federate an application server node into a deployment manager cell, the
deployment manager instantiates the node agent server process on the application
server node. The node agent server uses these port assignments by default.
Table 12. Port definitions for the Version 5.1.x node agent server process
Port Name Default Value File
BOOTSTRAP _ADDRESS 2809 serverindex.xml
ORB _LISTENER _ADDRESS 9900
SAS _SSL _SERVERAUTH _LISTENER _ADDRESS 9901
CSIV2 _SSL _MUTUALAUTH _LISTENER _ADDRESS 9101
CSIV2 _SSL _SERVERAUTH _LISTENER _ADDRESS 9201
NODE _DISCOVERY _ADDRESS 7272
NODE _MULTICAST _DISCOVERY _ADDRESS 5000
DRS _CLIENT _ADDRESS 7888
SOAP _CONNECTOR _ADDRESS 8878
112 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
Chapter 8. Troubleshooting migration
You might encounter problems while migrating from an older version of
WebSphere Application Server.
v While you are using the Version 7.0 Migration wizard to create a profile before
migrating a configuration, you might see the following profile-creation error
messages.
profileName: profileName cannot be empty
profilePath: Insufficient disk space
These error messages might be displayed if you enter a profile name that
contains an invalid character such as a space. Rerun the Migration wizard, and
verify that there are no invalid characters in the profile name such as a space,
quotes, or any other special characters.
v If you encounter a problem when you are migrating from a previous version of
WebSphere Application Server to Version 7.0, check your log files and other
available information.
1. Look for the log files, and browse them for clues.
– migration_backup_dir/logs/WASPreUpgrade.time_stamp.log
– migration_backup_dir/logs/WASPostUpgrade.time_stamp.log
– app_server_root/logs/clientupgrade.time_stamp.log
2. Look for MIGR0259I: The migration has successfully completed or
MIGR0271W: The migration completed with warnings in one of the log files.
– migration_backup_dir/logs/WASPreUpgrade.time_stamp.log
– migration_backup_dir/logs/WASPostUpgrade.time_stamp.log
– app_server_root/logs/clientupgrade.time_stamp.log
If MIGR0286E: The migration failed to complete is displayed, attempt to
correct any problems based on the error messages that appear in the log file.
After correcting any errors, rerun the command from the bin directory of the
product installation root.
3. Open the service log of the server that is hosting the resource that you are
trying to access, and browse error and warning messages.
4. With WebSphere Application Server running, run the dumpNameSpace
command and pipe, redirect, or ″more″ the output so that it can be easily
viewed.
This command results in a display of all objects in WebSphere Application
Server’s namespace, including the directory path and object name.
5. If the object that a client needs to access does not appear, use the
administrative console to verify the following conditions.
– The server hosting the target resource is started.
– The Web module or enterprise Java bean container hosting the target
resource is running.
– The JNDI name of the target resource is properly specified.
For current information available from IBM Support on known problems and
their resolution, read the IBM Support page. IBM Support also has documents
that can save you time gathering information needed to resolve this problem.
Before opening a PMR, read the IBM Support page.
v During the migration process, problems might occur while you are using the
WASPreUpgrade tool or the WASPostUpgrade tool.
© Copyright IBM Corp. 2005, 2008 113
– Problems can occur when you are using the WASPreUpgrade tool.
- A ″Not found″ or ″No such file or directory″ message is returned.
This problem can occur if you are trying to run the WASPreUpgrade tool
from a directory other than the WebSphere Application Server Version 7.0
app_server_root\bin. Verify that the WASPreUpgrade script resides in the
Version 7.0 app_server_root\bin directory, and launch the file from that
location.
- The DB2 JDBC driver and DB2 JDBC driver (XA) cannot be found in the
drop-down list of supported JDBC providers in the administrative console.
The administrative console no longer displays deprecated JDBC provider
names. The new JDBC provider names used in the administrative console
are more descriptive and less confusing. The new providers will differ only
by name from the deprecated ones.
The deprecated names will continue to exist in the jdbc-resource-provider-
templates.xml file for migration reasons (for existing JACL scripts for
example); however, you are encouraged to use the new JDBC provider
names in your JACL scripts.
- You receive the following message:
MIGR0108E: The specified WebSphere directory does not contain
a WebSphere version that can be upgraded.
The following possible reasons for this error exist:
v If WebSphere Application Server Version 5.1.x or Version 6.x is installed,
you might not have run the WASPreUpgrade tool from the bin directory
of the Version 7.0 installation root.
1. Look for something like the following message to display when the
WASPreUpgrade tool runs: IBM WebSphere Application Server,
Release 5.1.
This message indicates that you are running the WebSphere
Application Server Version 5.1 migration utility, not the Version 7.0
migration utility.
2. Alter your environment path or change the current directory so that
you can launch the WebSphere Application Server Version 7.0
WASPreUpgrade tool.
v An invalid directory might have been specified when launching the
WASPreUpgrade tool.
Read “WASPreUpgrade command” on page 47 for more information.
– Problems can occur when you are using the WASPostUpgrade tool.
- A ″Not found″ or ″No such file or directory″ message is returned.
This problem can occur if you are trying to run the WASPostUpgrade tool
from a directory other than the WebSphere Application Server Version 7.0
app_server_root\bin. Verify that the WASPostUpgrade script resides in the
Version 7.0 app_server_root\bin directory, and launch the file from that
location.
- You receive the following message:
MIGR0102E: Invalid Command Line. MIGR0105E: You must specify
the primary node name.
The most likely cause of this error is that WebSphere Application Server
Version 5.1.x or Version 6.x is installed and the WASPostUpgrade tool was
not run from the bin directory of the Version 7.0 installation root.
To correct this problem, run the WASPostUpgrade command from the bin
directory of the WebSphere Application Server Version 7.0 installation root.
114 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
- When you migrate the federated nodes in a cell, you receive the following
error messages:
MIGR0304I: The previous WebSphere environment is being restored.
com.ibm.websphere.management.exception.RepositoryException:
com.ibm.websphere.management.exception.ConnectorException: ADMC0009E:
The system failed to make the SOAP RPC call: invoke
MIGR0286E: The migration failed to complete.
A connection timeout occurs when the federated node tries to retrieve
configuration updates from the deployment manager during the
WASPostUpgrade migration step for the federated node. Copying the entire
configuration might take more than the connection timeout if the
configuration that you are migrating to Version 7.0 contains any of the
following elements:
v Many small applications
v A few large applications
v One very large application
The best practice is to modify the timeout value before running the
WASPostUpgrade command to migrate a federated node.
1. Go to the following location in the Version 7.0 directory for the profile
to which you are migrating your federated node:
profile_root/properties
2. Open the soap.client.props file in that directory and find the value for
the com.ibm.SOAP.requestTimeout property. This is the timeout value in
seconds. The default value is 180 seconds.
3. Change the value of com.ibm.SOAP.requestTimeout to make it large
enough to migrate your configuration. For example, the following entry
would give you a timeout value of a half of an hour:
com.ibm.SOAP.requestTimeout=1800
Note: Select the smallest timeout value that will meet your needs. Be
prepared to wait for at least three times the timeout that you
select—once to download files to the backup directory, once to
upload the migrated files to the deployment manager, and once
to synchronize the deployment manager with the migrated node
agent.
4. Go to the following location in the backup directory that was created by
the WASPreUpgrade command:
backupDirectory/profiles/profile_name/properties
5. Open the soap.client.props file in that directory and find the value for
the com.ibm.SOAP.requestTimeout property.
6. Change the value of com.ibm.SOAP.requestTimeout to the same value
that you used in the Version 7.0 file.
Alternatively, you might want to consider a solution in which you specify
-includeApps script in the WASPostUpgrade command when you migrate
the deployment manager to Version 7.0 if one or both of the following are
true for your situation:
v You want to quickly migrate all nodes in the cell. After the entire cell is
migrated, however, you are willing to manually run the application
installation script for every application in the deployment manager
backup directory and then synchronize the configuration with all
migrated nodes.
v You are able to run without any applications installed.
116 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
3. Run the syncNode command on the node to synchronize it with the
deployment manager.
4. Rerun the migration.
- You receive the ″Unable to copy document to temp file″ error message.
Here is an example:
MIGR0304I: The previous WebSphere environment is being restored.
com.ibm.websphere.management.exception.DocumentIOException:
Unable to copy document to temp file:
cells/sunblade1Network/applications/LARGEApp.ear/LARGEApp.ear
Your file system might be full. If your file system is full, clear some space
and rerun the WASPostUpgrade command.
- You receive the following message:
MIGR0108E: The specified WebSphere directory does not contain
a WebSphere version that can be upgraded.
The following possible reasons for this error exist:
v If WebSphere Application Server Version 5.1.x or Version 6.x is installed,
you might not have run the WASPostUpgrade tool from the bin directory
of the Version 7.0 installation root.
1. Look for something like the following message to display when the
WASPostUpgrade tool runs: IBM WebSphere Application Server,
Release 5.1.
This message indicates that you are running the WebSphere
Application Server Release 5.1 migration utility, not the Version 7.0
migration utility.
2. Alter your environment path or change the current directory so that
you can launch the WebSphere Application Server Version 7.0
WASPostUpgrade tool.
v An invalid directory might have been specified when launching the
WASPreUpgrade tool or the WASPostUpgrade.
v The WASPreUpgrade tool was not run.
- You receive the following error message:
MIGR0253E: The backup directory migration_backup_directory does not exist.
The following possible reasons for this error exist:
v The WASPreUpgrade tool was not run before the WASPostUpgrade tool.
1. Check to see if the backup directory specified in the error message
exists.
2. If not, run the WASPreUpgrade tool.
Read “WASPreUpgrade command” on page 47 for more information.
3. Retry the WASPostUpgrade tool.
v An invalid backup directory might be specified.
For example, the directory might have been a subdirectory of the Version
5.1.x or Version 6.x tree that was deleted after the WASPreUpgrade tool
was run and the older version of the product was uninstalled but before
the WASPostUpgrade tool was run.
1. Determine whether or not the full directory structure specified in the
error message exists.
2. If possible, rerun the WASPreUpgrade tool, specifying the correct full
migration backup directory.
118 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
v When you use the Migration wizard to migrate a profile from
WebSphere Application Server Version 6.0.2 to Version 7.0 on a Solaris x64
processor-based system, the migration might fail during the WASPostUpgrade
step.
You might see messages similar to the following in migration_backup_dir/logs/
WASPostUpgrade.time_stamp.log:
MIGR0327E: A failure occurred with stopNode.
MIGR0272E: The migration function cannot complete the command.
WebSphere Application Server Version 6.0.2 uses a Java Virtual Machine (JVM)
in 32-bit mode. The Migration wizard for WebSphere Application Server Version
7.0 calls the WASPostUpgrade.sh script, which attempts to run the JVM for
Version 6.0.2 in the 64-bit mode when the server stops the Version 6.0.2 node.
Complete the following actions to remove the incomplete profile and enable
WebSphere Application Server to correctly migrate the Version 6.0.2 profile:
1. From a command line, change to the app_server_root/bin directory.
For example, type the following command:
cd /opt/IBM/WebSphere/AppServer/bin
2. Locate the WASPostUpgrade.sh script in the app_server_root/bin directory,
and make a backup copy.
3. Open the WASPostUpgrade.sh script in an editor, and perform the following
actions:
a. Locate the following line of code:
. "$binDir" /setupCmdLine.sh
b. Insert the following line of code after the code that was identified in the
previous step:
JVM_EXTRA_CMD_ARGS=""
c. Save the changes.
4. Use the following command to delete the incomplete Version 7.0 profile that
was created during the migration process:
app_server_root/bin/manageprofiles.sh -delete -profileName profile_name
5. Delete the profile_root directory of the Version 7.0 profile that was removed in
the previous step.
6. Rerun the Migration wizard.
v If you select the option for the migration process to install the enterprise
applications that exist in the Version 5.1.x or Version 6.x configuration into the
new Version 7.0 configuration, you might encounter some error messages during
the application-installation phase of migration.
The applications that exist in the Version 5.1.x or Version 6.x configuration might
have incorrect deployment information—typically, invalid XML documents that
were not validated sufficiently in previous WebSphere Application Server
runtimes. The runtime now has an improved application-installation validation
process and will fail to install these malformed EAR files. This results in a
failure during the application-installation phase of WASPostUpgrade and
produces an ″E:″ error message. This is considered a ″fatal″ migration error.
If migration fails in this way during application installation, you can do one of
the following:
– Fix the problems in the Version 5.1.x or Version 6.x applications, and then
remigrate.
– Proceed with the migration and ignore these errors.
In this case, the migration process does not install the failing applications but
does complete all of the other migration steps.
Chapter 8. Troubleshooting migration 119
Later, you can fix the problems in the applications and then manually install
them in the new Version 7.0 configuration using the administrative console or
an install script.
v Version 5.1.x node agents might display as not synchronized or not available
when you change the deployment manager node name in a mixed cell during
migration to the Version 7.0 deployment manager.
Version 5.1.x node agents maintain a link to the Version 5.1.x deployment
manager until they are restarted; therefore, they might fail to synchronize with
the new deployment manager. The discovery problem, which prevents automatic
synchronization, occurs because the node agent is not yet aware of the
deployment manager name change that occurred during the migration. If you
experience this problem, perform these steps on the node.
1. Stop the node.
2. Run the syncNode command.
3. Restart the node.
v After migrating to a Version 7.0 cell that contains or interoperates with Version
6.x nodes that are not at Version 6.0.2.11 or later, the cluster function might fail.
When starting these Version 6.x application servers, you might see the following
problems:
– You might see a first failure data capture (FFDC) log that shows a
ClassNotFoundException error message. This exception is thrown from the
RuleEtiquette.runRules method and looks something like the following
example:
Exception = java.lang.ClassNotFoundException
Source = com.ibm.ws.cluster.selection.SelectionAdvisor.<init>
probeid = 133
Stack Dump = java.lang.ClassNotFoundException: rule.local.server
at java.net.URLClassLoader.findClass(URLClassLoader.java(Compiled Code))
at com.ibm.ws.bootstrap.ExtClassLoader.findClass(ExtClassLoader.java:106)
at java.lang.ClassLoader.loadClass(ClassLoader.java(Compiled Code))
at java.lang.ClassLoader.loadClass(ClassLoader.java(Compiled Code))
at java.lang.Class.forName1(Native Method)
at java.lang.Class.forName(Class.java(Compiled Code))
at com.ibm.ws.cluster.selection.rule.RuleEtiquette.runRules(RuleEtiquette.java:154)
at com.ibm.ws.cluster.selection.SelectionAdvisor.handleNotification(SelectionAdvisor.java:153)
at com.ibm.websphere.cluster.topography.DescriptionFactory$Notifier.run(DescriptionFactory.java:257)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1462)
– You might see a java.io.IOException that looks something like the following
example:
Exception = java.io.IOException
Source = com.ibm.ws.cluster.topography.DescriptionManagerA. update probeid = 362
Stack Dump = java.io.IOException
at com.ibm.ws.cluster.topography.ClusterDescriptionImpl.importFromStream(ClusterDescriptionImpl.java:916)
at com.ibm.ws.cluster.topography.DescriptionManagerA.update(DescriptionManagerA.java:360)
Caused by: java.io.EOFException
at java.io.DataInputStream.readFully(DataInputStream.java(Compiled Code))
at java.io.DataInputStream.readUTF(DataInputStream.java(Compiled Code))
at com.ibm.ws.cluster.topography.KeyRepositoryImpl.importFromStream(KeyRepositoryImpl.java:193)
120 IBM WebSphere Application Server Network Deployment Version 7.0: Migrating, coexisting, and interoperating
com.ibm.ws.runtime.WsServerImpl.start(WsServerImpl.java:139)
[5/11/06 15:41:23:196 CDT] 0000000a SystemErr R at
com.ibm.ws.runtime.WsServerImpl.main(WsServerImpl.java:460)
[5/11/06 15:41:23:196 CDT] 0000000a SystemErr R at
com.ibm.ws.runtime.WsServer.main(WsServer.java:59)
[5/11/06 15:41:23:196 CDT] 0000000a SystemErr R at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[5/11/06 15:41:23:196 CDT] 0000000a SystemErr R at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
[5/11/06 15:41:23:197 CDT] 0000000a SystemErr R at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Change the port number at which the federated node’s application server is
listening. If the deployment manager is listening at port 9101 for
ORB_LISTENER_ADDRESS, for example, the application server of the federated
node should not be listening at port 9101 for its ORB_LISTENER_ADDRESS. To
resolve the problem in this example, perform the following steps:
1. From the administrative console, click Application servers > server_name >
Ports > ORB_LISTENER_ADDRESS .
2. Change the ORB_LISTENER_ADDRESS port number to one that is not used.
v If synchronization fails when you migrate a federated node to Version 7.0, the
application server might not start.
You might receive messages similar to the following when you migrate a
federated node to Version 7.0:
ADMU0016I: Synchronizing configuration between node and cell.
ADMU0111E: Program exiting with error:
com.ibm.websphere.management.exception.AdminException: ADMU0005E:
Error synchronizing repositories
ADMU0211I: Error details may be seen in the file:
/opt/WebSphere/70AppServer/profiles/AppSrv02/logs/syncNode.log
MIGR0350W: Synchronization with the deployment manager using the SOAP protocol
failed.
MIGR0307I: The restoration of the previous WebSphere Application Server
environment is complete.
MIGR0271W: Migration completed successfully, with one or more warnings.
If you did not find your problem listed, contact IBM support.
IBM may have patents or pending patent applications covering subject matter in
this document. The furnishing of this document does not give you any license to
these patents. You can send license inquiries, in writing, to the following address: