This article provides a list of general best practices to apply to any WebSphere Application Server V7 and V8 environment. These recommendations could be used to set up any WebSphere environment.

General Best Practices for WebSphere Application Environments

1. All WebSphere Application processes should be running as non-admin/root user.It's not a good practice to run a process as an admin/root user. For obvious reasons, you don't want more folks to know about the admin/root password and generally the WebSphere admins are not the system admins. Create a services user account on the box and use it for the WebSphere Application's start and stop purposes.

2. Enabled Global Security.By default, the WebSphere Application Server enables administrative security. Thus, for the most part, the infrastructure provides for reasonable authentication, authorization, and encryption of administrative traffic by default. When administrative security is enabled, the WebSphere Application Server's internal links between the deployment manager and the application servers and traffic from the administrative clients (Web and command line) to the deployment manager are encrypted and authenticated. Among other things, this means that administrators will be required to authenticate when running the administrative tools.

3. Enabled Application Security.In addition to leveraging the application server's security for administration, it's strongly recommend that you leverage it for application security. Doing so gives your applications access to a strong and robust standards-based security infrastructure. Applications that didn't leverage application server security were typically found to have serious security holes. Designing and implementing a secure distributed infrastructure is not easy.

To enable application security, go to the global security panel and select Enable application security.

4. Configure WebSphere Security with proper LDAP repository.WebSphere security supports different configurations, including LDAP servers, local users and local operating system levels users. However, it's recommended that you use a proper LDAP server for this purpose.

5. Leverage Administrative roles.WebSphere Application Server allows for a variety of administrative roles depending on the version: Administrator, Operator, Monitor, Configurator, AdminSecurityManager, iscadmins, Deployer, or Auditor. These roles make it possible to give individuals (and automated systems) access that's appropriate to their level of need. It's strongly recommended that you take advantage of roles whenever possible.

By using the less powerful roles of monitor and operator, you can restrict the actions an administrator can take. For example, you can give the less senior administrators just the ability to start and stop servers and the night operators just the ability the watch the system (monitor). These actions greatly limit the risk of damage by trusting people with only the permissions they need.

6. Use HTTP Server as an interface for the Applications.Use HTTP servers in front of an application layer, i.e., WebSphere Application. Don't allow communications directly with WebSphere's http web container port from either a load balance or from browsers.

7. HTTP and WebSphere on the Same box.At least in higher environments, install and configure the http server on a different box than the WebSphere box. In the lower environments the same box can be used for both layers.

8. Logs on External Drive.At least in higher environments, write the WebSphere and application log files to an external drive, so it won't fill up the server's file space.

9. Logs Archive.Depending on the application, rotate and clean up the logs in a timely manner.

10. Read-only Logs Access for Developer.If it's okay with the security team, grant developers read-only access for WebSphere and the applications logs on the external drive.

11. Alternate Log Access for Developers.

To enable developers to view the production application and WebSphere logs, host those shared folders from the web server instead of giving them access to those boxes. Once the logs are hosted from the web server, developers need only a web browser to view those files from their computers.

12. Log Level.Configure log level to error in high environments. Logs in the higher environments don't need to produce unnecessary information. In the lower environments it can be set to info or debug level.

13. Leverage WebSphere Application Servers' high availability and failover capabilities.Out-of-the-box WebSphere support high availability and failover functionality. There is no need to use any external component or product for this. One of the key benefits is that user http session can be shared within the cluster members and, in the case of failover, the other active cluster members can resume the activity using same session.

14. Minimum Cluster Members in Cluster.In the WebSphere clustered environment, define and create at least three cluster members. In the case of failover with two cluster members, not only the entire load will shift to one node but it also becomes a single point of failure. With three nodes, at least the load will still be distributed to two nodes and there is no single point of failure.

15. Database and WebSphere on Same box.At least in higher environments, separate the application layer from the data layer and install them on different boxes. In the lower environments the same box can be used for both layers.

16. Use Type-4 JDBC Drivers.Type-4 JDBC drivers don't require any component to be installed on the application layer. For the type-2 and type-3, the database's client needs to install on the WebSphere box.

17. Protect application server to database link.As with any other network link, confidential information can be written to or read from the database. Most databases support some form of network encryption and you should leverage it.

18. Script based WebSphere Administration.In general, it's good practice to use scripts to avoid human errors during the deployment and

configuration, especially in higher environments. However, it requires an investment in time and resources to develop these scripts, especially if it is first time and / or script-based administration is not part of the current culture. Once the scripts are created, they can be used in all environments and maybe automate some of the tasks.

19. Monitoring.Use proper application and infrastructure runtime monitoring tools that can monitor environments and application thresholds and potentially alert you to problems before they cause service interruptions.

20. EAR vs WAR Files.According to J2EE specs, EAR file should be deployed in WebSphere. However, WebSphere does support deploying WARs and upgrade class functionality. Developers should produce EAR files from their development tool or generate EAR should it be created from the deployment scripts before deploying the application in WebSphere.

21. Don't run samples in production.WebSphere Application Server ships with several excellent examples to demonstrate various parts of the WebSphere Application Server. These samples are not intended for use in a production environment. Don't run them there, as they create significant security risks. In particular, the showCfg and snoop servlets can provide an outsider with tremendous amounts of information about your system. This is precisely the type of information you don't want to give a potential intruder. This is easily addressed by not installing the samples during the profile creation.

22. Environments.Generally, it's good to have more environments. Typically four would be a sufficient enough: development, QA, staging and production. Development and QA environments don't need a lot of hardware resources. It's recommended that the staging environment be a replica of production in terms of application data and hardware resources. The staging environment can also be used for stress testing and / or for production support.

23. Performance Tuning.Tune WebSphere application servers properly for each application. Performance tuning includes optimization of a number of web container threads, JVM heap sizes, JDBC connections, OS tuning, etc. After configuring these parameters to optimize values, boost the application performance. Stress / staging environment should be used for load testing.

24. Separate your production network from your intranet.Most organizations today understand the value of a DMZ that separates the outsiders on the Internet from the intranet. However, far too many organizations fail to realize that many intruders are on the inside. You need to protect against internal as well as external threats. Just as you protect yourself against the large untrusted Internet, you should also protect your production systems from the large and untrustworthy intranet.

25. Separate your production networks from your internal network using firewalls.These firewalls, while likely more permissive than the Internet-facing firewalls, can still block numerous forms of attack.

Keep up-to-date with patches and fixes. As with any complex product, IBM occasionally finds and fixes security bugs in WebSphere Application Server, Virtual Enterprise, Datapower and other products. It's crucial that you keep up-to-date on these fixes. It's advisable that you subscribe to

support bulletins for the products you use and, in the case of WebSphere Application Server and WebSphere Virtual Enterprise, monitor the security bulletin site for your version. Those bulletins often contain notices of recently discovered security bugs and the fixes. You can be certain that potential intruders learn of those security holes quickly. The sooner you act the better.

----------------------------------------------------------------------------------------------------------------------------------

Migration Failures in a WebSphere Network Deployment on an AIX Platform

Migration failures may occur when migrating application run-time configurations for a large complex network deployment to a higher version of WebSphere Application Server (WAS) Network Deployment (ND) on an AIX platform. The WebSphere migration utilities such as WASPreUpgrade and WASPostUpgrade provide the necessary mechanisms to move the existing configuration information such as older defaults and settings including ports, JVM parameters, etc., from a previous version to a higher version of the WebSphere Application Server. These migration failures may happen for several reasons such as any shortcomings in the procedure or a peculiar deployment topology chosen by the customer or due to any underlying network and synchronization failures from configurations in WebSphere or AIX.

Migration Environment

Source - WebSphere Application Server ND V6.0 Target - WebSphere Application Server ND V7.0 Operating System - 64-bit AIX6.1

Migration Failures due to Shortcomings in the ProcedureEnough file system space has not been allocated to cater to the binaries and profiles

Permission has not been set to read, write or create on the file system

WebSphere Application Server product has not been correctly installed or the profiles have not been properly created for the target environment.

Migration Failures from Peculiar TopologyPeculiar topology may include a managed node with a federated application server (outside the cluster) and co-located deployment manager, and clustered application servers in the cell. The process of migration in the WebSphere product specifies migrating a deployment manager profile and then migrating application servers nodes. However, migration failure may occur when the deployment manager node is migrated prior to the clustered application server nodes.

Migration Failures from WebSphere/AIX ConfigurationsThe migration synchronization process is observed to fail when the system user runs out of file handles with default AIX 'nofiles' limit setting (i.e., ulimit -n) of 2000. This 'nofiles' value proves to be too low, resulting in errors opening files or establishing connections in the migration process.

It is also known that the migration process synchronizes data in the migrated node with the deployment manager during which the contents of the new profile's configurations are uploaded to the deployment manager, one file at a time. Some 'network connection reset' or 'network read error’ condition may occur due to migration tool saturating the deployment manager's connections

with incoming data if the max connections on the TCP channel configured are too low (say default 100).

----------------------------------------------------------------------------------------------------------------------------

Migration of an existing WAS 6.1 ND clustered test environment to WAS 7.0.

There are several benefits to migrating a test environment before migrating your production environment.These include:• Allows you to gain experience of the migration process• Gives you a migrated environment to test that your applications and configuration continue to work correctly• Helps you to determine whether any problems are introduced by the migration process

Migrating WAS 6.1 to 7.0This section describes the steps necessary to migrate a test environment from WAS 6.1 to 7.0.The high level steps to migrate from WAS 6.1 to WAS 7.0 are:1. Install WAS 7.0.2. Update WAS 7.0 to the latest maintenance level.3. Migrate the WAS configuration from 6.1 to 7.0.

Installing WAS 7.0This task describes the steps necessary to install WebSphere Application Server Network Deployment 7.0.Use the following procedure to install the WebSphere Application Server Network Deployment product.This procedure installs the product ready for use in a new environment or allows migration from a previousversion. Run all commands as root user.1. Obtain the install media appropriate for your platform. For example: Download part numberC1G2QML for 64-bit AIX.2. Enter the following command to create a temporary directory to hold the install media:mkdir /tmp/was73. Copy the software image to the temporary directory.4. Enter the following commands to extract the install media into the temporary directory:gzip -d C1G2QML.tar.gztar -xvf C1G2QML.tar5. Use a text editor to create a response file called responsefile.txt in /tmp/was7/WAS with thefollowing content:-OPT silentInstallLicenseAcceptance="true";-OPT installType="installNew";-OPT profileType="none";-OPT feature="noFeature";-OPT installLocation="/usr/IBM/WebSphere70/AppServer"6. Enter the following commands to start the installer in silent mode using the response file created in the previous step:cd /tmp/was7/WAS./install -options "/tmp/was7/WAS/responsefile.txt" -silentNote: If serious problems are encountered that prevent the product from installing, the errors are

logged in the /waslogs directory. Review the files in this directory, correct any problems (for exampleinsufficient space on target file systems), and retry the installation.a) Verify that the installation succeeded using the installver.sh command. This command verifies thatthe product files were installed as expected and reports on any variations./usr/IBM/WebSphere70/AppServer/bin/installver.sh7. If the installation files are no longer needed, they can be deleted by running the following command:rm -r /tmp/wasThe product files are installed into the /usr/IBM/WebSphere70/AppServer directory on the target machine.

Updating WAS 7.0 to the latest maintenance levelThis topic describes the high level steps necessary to update WebSphere Application Server NetworkDeployment 7.0 to the latest maintenance level.The high level steps required to update the WAS ND 7.0 to the latest maintenance level are:1. Install the latest version of the IBM Update Installer for WebSphere Software.2. Apply the latest WAS fix pack.3. Apply the latest WAS SDK fix pack.

Details for each of these steps are provided in the sections that follow.Installing the IBM Update Installer for WebSphere SoftwareThis task describes the steps necessary to install the IBM Update Installer for WebSphere Software. This software is used to install maintenance and updates to WebSphere Application Server.Use the following procedure to install the IBM Update Installer for WebSphere Software. Run allcommands as root user.1. Obtain the install file appropriate for your platform from http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg24020212.a) For example:download 7.0.0.1-WS-UPDI-AixPPC64.tar.gz for 64 bit AIX.2. Enter the following command to create a temporary directory to hold the install media:mkdir /tmp/updi3. Copy the software image to the temporary directory.4. Enter the following commands to extract the install media to the temporary directory:gzip -d 7.0.0.1-WS-UPDI-AixPPC64.tar.gztar -xvf 7.0.0.1-WS-UPDI-AixPPC64.tar5. Use a text editor to create a response file called responsefile.txt in /tmp/updi/UpdateInstaller with the following content:-OPT silentInstallLicenseAcceptance=”true”-OPT installLocation=”/usr/IBM/WebSphere70/UpdateInstaller”6. Enter the following commands to start the installer in silent mode using the response file created in the previous step:cd /tmp/updi/UpdateInstaller./install -options “/tmp/updi/UpdateInstaller/responsefile.txt” -silentNote: If serious problems are encountered that prevent the product from installing, the errors arelogged in the /updilogs directory. Review the files in this directory, correct any problems (forexample insufficient space on target file systems), and retry the installation.a) Verify that the installation succeeded using the installver.sh command. This command verifies thatthe product files were installed as expected and reports on any variations./usr/IBM/WebSphere70/UpdateInstaller/bin/installver.sh7. If the installation files are no longer needed, they can be deleted by running the following command:

rm -r /tmp/updiThe software is installed into the /usr/IBM/WebSphere70/UpdateInstaller directory on the target machine.

Applying a fix pack to WAS 7.0This task describes the steps necessary to use the IBM Update Installer for WebSphere Software toupdate WebSphere Application Server Network Deployment 7.0 with the latest recommended fix pack.The list of recommended fixes for all versions of WebSphere can be found at the following location:http://www-01.ibm.com/support/docview.wss?uid=swg27004980The instructions below apply to that fix pack.Use the following procedure to apply a fix pack to WAS 7.0. Run all commands as root user.1. Obtain the appropriate fix pack file for your platform.a) For example, download 7.0.0-WS-WAS-AixPPC64-FP0000001.pak for 64 bit AIX.2. Copy the fix pack file to the maintenance directory under the Update Installer directory which is /usr/IBM/WebSphere70/UpdateInstaller/maintenance3. Use a text editor to create a response file called install7.0.0.1.txt in the directory /usr/IBM/WebSphere70/UpdateInstaller/responsefiles with the following content:-W product.location="/usr/IBM/WebSphere70/AppServer"-W maintenance.package="/usr/IBM/WebSphere70/UpdateInstaller/maintenance/7.0.0-WS-WAS-AixPPC64-FP0000001.pak"-W update.type="install"4. Enter the following commands to start the installer in silent mode using the response file created in the previous step:cd /usr/IBM/WebSphere70/UpdateInstaller./update.sh -options “/usr/IBM/WebSphere70/UpdateInstaller/responsefiles/install7.0.0.1.txt” -silent5. Enter the following command to run the VersionInfo tool:/usr/IBM/WebSphere70/AppServer/bin/versionInfo.sha) Ensure that the update was applied by checking that the Version field correctly reflects the fix pack you applied, in this case 7.0.0.1. The output should be similar to the following:WVER0010I: Copyright (c) IBM Corporation 2002, 2005, 2008; All rightsreserved.WVER0012I: VersionInfo reporter version 1.15.1.26, dated 8/9/08--------------------------------------------------------------------------------IBM WebSphere Application Server Product Installation Status Report--------------------------------------------------------------------------------Report at date and time 06 January 2009 14:45:41 GMTInstallation--------------------------------------------------------------------------------Product Directory /usr/IBM/WebSphere70/AppServerVersion Directory /usr/IBM/WebSphere70/AppServer/properties/versionDTD Directory /usr/IBM/WebSphere70/AppServer/properties/version/dtdLog Directory /usr/IBM/WebSphere70/AppServer/logsBackup Directory /usr/IBM/WebSphere70/AppServer/properties/version/nif/backupTMP Directory /tmpProduct List--------------------------------------------------------------------------------ND installedInstalled Product

--------------------------------------------------------------------------------Name IBM WebSphere Application Server - NDVersion 7.0.0.1ID NDBuild Level cf010845.08Build Date 11/12/08Architecture PPC64--------------------------------------------------------------------------------End Installation Status Report--------------------------------------------------------------------------------WAS ND 7.0 is upgraded to the latest maintenance level on the target machine.

Applying a fix pack to the WAS 7.0 SDKThis task describes how to use the IBM Update Installer for WebSphere Software to update WebSphereApplication Server 7.0 Software Development Kit (SDK) with the latest recommended fixes.The list of recommended fixes for all versions of WebSphere can be found at the following location:http://www-01.ibm.com/support/docview.wss?uid=swg27004980The instructions below are applicable for that fix pack.Use the following procedure to apply a fix pack to WAS 7.0 SDK. Run all commands as root user.1. Obtain the appropriate fix pack file for your platform.a) For example download 7.0.0-WS-WASSDK-AixPPC64-FP0000001.pak for 64 bit AIX2. Copy the fix pack file to the maintenance directory under the Update Installer directory which is /usr/IBM/WebSphere70/maintenance3. Using a text editor create a response file called installSDK7.0.0.1.txt in the directory /usr/IBM/WebSphere70/UpdateInstaller/responsefiles with the following content:-W product.location="/usr/IBM/WebSphere70/AppServer"-W maintenance.package="/usr/IBM/WebSphere70/UpdateInstaller/maintenance/7.0.0-WS-WASSDK-AixPPC64-FP0000001.pak"-W update.type="install"4. Run the update program using the response file created in the previous step:cd /usr/IBM/WebSphere70/UpdateInstaller./update.sh -options “/usr/IBM/WebSphere70/UpdateInstaller/responsefiles/installSDK7.0.0.1.txt" -silent5. Verify that the update was applied using the version information command:/usr/IBM/WebSphere70/AppServer/java/bin/java -fullversiona) The output should be similar to the following. Ensure that the Version field correctly reflects theJava SDK fix pack you applied. For example, the following message will be displayed for the7.0.0.1 Java SDKjava full version "JRE 1.6.0 IBM AIX build pap6460sr3-20081106_07 (SR3)"WAS 7.0 SDK is upgraded to the latest maintenance level.

Migrating the WAS configurationThis task describes the steps necessary to migrate a WAS Network Deployment 6.1 clustered testenvironment to WAS 7.0.Before starting the migration ensure that you have performed the following tasks:• Read the planning section and make any changes required for your applications to run in WAS 7.0.• Install WAS 7.0 and apply the latest maintenance level on each machine hosting a managed node in the WAS 6.1 test environment to be migrated.• Verify that the WAS 6.1 environment to be migrated is stable and prevent any administration activity or configuration changes being made until the migration is complete. The WAS 6.1 system

can be left up and running until key stages within the migration when you will be required to stop various processes.• Unconfigure any IBM Tivoli Composite Application Manager (ITCAM) for WebSphere Data Collectors that you have configured for your WAS application servers. For details see Appendix "ITCAM Considerations." You will need to reconfigure these following the migration. Backup the existing WAS 6.1 profiles using the backupConfig command. This is good practice, so that in the event of any problems, this configuration can be easily restored using the restoreConfig command.Note: The migration process does not change the existing WAS 6.1 configuration (other than todisable the deployment manager and node agents to prevent them from being started accidentally).The WASPreUpgrade step backs up the 6.1 configuration, but the format of this backup does notsupport an easy restoration of the configuration.• Collect the following information:• WAS 6.1 configuration cell name• WAS 6.1 deployment manager's profile name and node name• For each WAS 6.1 managed node: profile name and node name.• The userids under which the WAS processes run.This procedure will migrate the deployment manager profile, followed by each managed node profile in turn.Important: The deployment manager must always be at the highest release and fix level within a cell for it to manage all nodes in the cell. The Version 7.0 deployment manager can manage Version 5.1.x, Version 6.x, and Version 7.0 nodes. This allows a cell to be upgraded to a new release one node at a time, with minimal impact to the applications that are running within the cell.

The following diagram describes the WAS configuration in the test environment to be migrated.Figure 3: WAS configuration in test environment

These instructions make the following assumptions:WAS 6.1 has been installed into the directory: /usr/IBM/WebSphere61/AppServer.WAS 7.0 has been installed into the directory: /usr/IBM/WebSphere70/AppServer.

Use the following procedure to migrate a WAS 6.1 clustered test environment to WAS 7.0. Run all

commands as root user, unless otherwise specified.1. Migrate the deployment manager.a) Create a WAS 7.0 deployment manager profile.This profile will become the target profile during the WASPostUpgrade migration step.Important: The cellName must match the value used for the WAS 6.1 deployment manager'sprofile and the nodeName must either match the value used for the 6.1 deployment manager or beunique within the cell.Example: To create a WAS 7.0 deployment manager profile called TestDmgr01 with administrationsecurity enabled enter the following commands:cd /usr/IBM/WebSphere70/AppServer/bin./manageprofiles.sh -create -templatePath /usr/IBM/WebSphere70/AppServer/profileTemplates/management -profileName TestDmgr01 -profilePath /usr/IBM/WebSphere70/AppServer/profiles/TestDmgr01/ -enableAdminSecurity true -adminUserName wasadmin -adminPassword password-cellName TestCell01 -nodeName TestDmgr01b) Run the WASPreUpgrade command for the deployment manager profile.This saves the configuration of the previously installed version of the WAS profile into a migrationspecific backup directory.Example: To run the WAS 7.0 WASPreUpgrade command for the deployment manager profileenter the following commands:cd /usr/IBM/WebSphere70/AppServer/bin./WASPreUpgrade.sh /usr/IBM/WebSphere61/DmgrBackup /usr/IBM/WebSphere61/AppServer -oldProfile TestDmgr01Note: For full syntax of the WASPreUpgrade command see the WAS 7.0 InfoCenter.c) Increase SOAP connection timeouts if migrating a large ND configuration.To avoid connection timeouts when migrating a large number of small applications or one largeapplication increase the value of the SOAP request timeout property to be sufficient for themigration to complete (the value is in milliseconds).Example: To increase the SOAP request timeout value from the WAS default of 180ms to 1800ms,edit the soap.client.props file to set com.ibm.SOAP.requestTimeout=1800 in each of thefollowing directories (make a note of the existing values first):WAS 7.0 deployment manager profile's property directory: /usr/IBM/WebSphere70/AppServer/profiles/TestDmgr01/propertiesWAS 6.1 deployment manager profile's backupDirectory/profiles/profile_name/propertiesdirectory: /usr/IBM/WebSphere61/DmgrBackup/profiles/TestDmgr01/propertiesd) Run the WASPostUpgrade command for the deployment manager profile.This retrieves the saved configuration that was created by the WASPreUpgrade command fromthe backupDirectory that you specified. The WASPostUpgrade script reads the configuration fromthis directory to migrate to the WAS 7.0 profile.Example: To run the WAS 7.0 WASPostUpgrade command for the deployment manager profileenter the following commands:cd /usr/IBM/WebSphere70/AppServer/bin./WASPostUpgrade.sh /usr/IBM/WebSphere61/DmgrBackup -profileNameTestDmgr01 -oldProfile TestDmgr01 -username wasadmin -password password-includeApps script -keepDmgrEnabled trueNotes:1. The use of -includeApps script and -keepDmgrEnabled false are recommended to give morecontrol over the migration, allowing you to deploy the applications to WAS 7.0 as a separatestep. (The default options are -includeApps true and -keepDmgrEnabled false).2. The default option -scriptCompatibility true is used to minimize the impact to existingadministrative scripts. This provides a temporary transition until all of the nodes in the

IBM - Mixed Platform Stack | Migrating a WAS 6.1 test environment to WAS 7.0 | 21© 2009, IBM Advanced Technical Support Techdocs, http://www.ibm.com/support/Techdocsenvironment are at WAS 7.0, at which time you should perform the actions required toconvert the configuration to use WAS 7.0 settings.3. For full syntax of the WASPostUpgrade command see the WAS 7.0 InfoCenter.e) Install the enterprise applications.Ensure all the enterprise applications deployed to the WAS 6.1 configuration are deployed to theWAS 7.0 configuration.If the default option -includeApps true is specified on the WASPostUpgrade command then allapplications are automatically migrated as part of that step and you need take no further action.If the option -includeApps script is specified on the WASPostUpgrade command, thenat this time the applications can be deployed to the WAS 7.0 deployment manager. TheWASPostUpgrade command copies the enterprise application ear files from WAS 6.1 into theWAS 7.0 deployment manager profile's installableApps directory and creates wsadmin jythonscripts to install the applications in the deployment manager profile's backup directory. A scriptcalled install_all_apps.jy is created, along with jython scripts to install each individualapplication.Example: To run the generated wsadmin jython script to install all migrated applications enter thefollowing commands:cd /usr/IBM/WebSphere70/AppServer/profiles/TestDmgr01/bin./wsadmin.sh -f /usr/IBM/WebSphere61/DmgrBackup/install_all_apps.jy -conntype NONE -lang jythonImportant: If you have a large number of applications, you may wish to reorganize and combinethe install application scripts created by the WASPostUpgrade command for better applicationsinstallation efficiency, rather than running the single install_all_apps.jy script. However,you MUST install all applications that were deployed in your WAS 6.1 environment to your WAS7.0 deployment manager BEFORE attempting to start the WAS 7.0 deployment managerf) Stop the WAS 6.1 deployment manager and disable it.Important: The WAS 6.1 deployment manager MUST be stopped before starting the WAS 7.0deployment manager.If default option -KeepDmgrEnabled false is specified on the WASPostUpgrade command thenthe WAS 6.1 deployment manager is automatically stopped and disabled and you need take nofurther action.If option -KeepDmgrEnabled true is specified on the WASPostUpgrade command, then at thistime you must manually stop the WAS 6.1 deployment manager. It is recommended that youalso disable the WAS 6.1 deployment managerer to prevent an accidental start.Example: To disabling the WAS 6.1 deployment manager by renaming its serverindex.xml fileenter the following commands:cd /usr/IBM/WebSphere61/AppServer/profiles/TestDmgr01/config/cells/TestCell01/nodes/TestDmgr01/mv serverindex.xml servindex.xml_disabledg) If migrating a WAS configuration running as a non-root user: change the ownership of thedeployment manager profile's directory structure.The userid under which the WAS deployment manager process runs should be the owner of thedeployment manager profile's directory structure, to ensure it has sufficient access permissions toall the files it requires to run successfully.Example: To change the ownership of the deployment manager profile's directory structure wherethe deployment manager process runs as user=wasuser defined in group=wasgroup, enter thefollowing commands:cd /usr/IBM/WebSphere70/AppServer/profileschown -R wasuser:wasgroup TestDmgr01

h) Start the WAS 7.0 deployment manager.Important: If migrating a WAS configuration running as a non-root user: ensure you are loggedon as the non-root user before issuing the startManager command, otherwise the deploymentmanager will fail to start due to insufficient file permissions.Example: To start the WAS 7.0 deployment manager issue the following command:cd /usr/IBM/WebSphere70/AppServer/profiles/TestDmgr01/bin./startManager.shi) Check that the WAS 7.0 deployment manager is working correctly.Ensure the deployment manager starts cleanly (check SystemOut.log and SystemErr.log).Ensure you can log in to administration console and that Welcome page displays version as7.0.x.x.Ensure administration console shows node agents are started, nodes are synchronized,application servers are started and their versions are displayed as 6.1.x.j) Reset the SOAP connection timeouts.If you increased the SOAP connection timeouts during the migration of the deployment manageryou can reset them now.Example: Edit the soap.client.props file to set com.ibm.SOAP.requestTimeout back to itsoriginal value in each of the following directories:WAS 7.0 deployment manager profile's property directory: /usr/IBM/WebSphere70/AppServer/profiles/TestDmgr01/propertiesWAS 6.1 deployment manager profile's backupDirectory/profiles/profile_name/propertiesdirectory: /usr/IBM/WebSphere61/DmgrBackup/profiles/TestDmgr01/propertiesA WAS 7.0 deployment manager is running with WAS 6.1 node agents and application servers.2. Migrate ONE of the managed nodes:a) Create a WAS 7.0 managed node profileThis profile will become the target profile during the WASPostUpgrade migration step.Important:The cellName and nodeName must match the values for the corresponding WAS 6.1managed node profile.Do NOT federate the custom profiles into the cell, this will be done during theWASPostUpgrade step.Example: To create a WAS 7.0 managed node profile called TestNode01 enter the followingcommands:cd /usr/IBM/WebSphere70/AppServer/bin./manageprofiles.sh -create -templatePath /usr/IBM/WebSphere70/AppServer/profileTemplates/management -profileName TestDmgr01 -profilePath /usr/IBM/WebSphere70/AppServer/profiles/TestDmgr01/ -enableAdminSecurity true -adminUserName wasadmin -adminPassword password-cellName TestCell01 -nodeName TestDmgr01

b) Run the WASPreUpgrade command for deployment manager profile.This saves the configuration of the previously installed version of the WAS profile into a migration specific backup directory.Example: To run the WAS 7.0 WASPreUpgrade commands for the deployment manager profileenter the following commands:cd /usr/IBM/WebSphere70/AppServer/bin./manageprofiles.sh -create -templatePath /usr/IBM/WebSphere70/AppServer/profileTemplates/managed -profileName TestNode01 -profilePath /usr/IBM/WebSphere70/AppServer/profiles/TestNode01 -nodeNameTestNode01 -cellName TestNode01 -federateLater trueNote: For full syntax of the WASPreUpgrade command see the WAS 7.0 InfoCenter.

c) Run the WASPreUpgrade command for the managed node profile.Example: to run the WAS 7.0 WASPreUpgrade commands for a managed node profile enter thefollowing commands:cd /usr/IBM/WebSphere70/AppServer/bin./WASPreUpgrade.sh /usr/IBM/WebSphere61/Node01Backup /usr/IBM/WebSphere61/AppServer -oldProfile TestNode01Note: For full syntax of the WASPreUpgrade command see the WAS 7.0 InfoCenter.d) Run the WASPostUpgrade command for the managed node profile.This retrieves the saved configuration that was created by the WASPreUpgrade command fromthe backupDirectory that you specified. The WASPostUpgrade script reads the configuration fromthis directory to migrate to the WAS 7.0 profile.Example: To run the WAS 7.0 WASPostUpgrade commands for a managed node profile enter thefollowing commands:cd /usr/IBM/WebSphere70/AppServer/bin./WASPostUpgrade.sh /usr/IBM/WebSphere61/Node01Backup -profileNameTestNode01 -oldProfile TestNode01 -username wasadmin -password passwordNote:The WASPostUpgrade script stops and disables the WAS 6.1 node agent but leavesany associated application servers running. The WASPostUpgrade script initiates a fullsynchronization from the migrated WAS 7.0 node agent to the deployment manager.For full syntax of the WASPostUpgrade command see the WAS 7.0 InfoCenter.e) Stop all the WAS 6.1 application servers associated with the migrated managed node profile.Important: All WAS 6.1 application servers associated with a specific managed node MUST bestopped before the WAS 7.0 version of that node agent is started.Example: To stop the WAS 6.1 application server TestServer01 on node TestNode01 from thecommand line issue the following commands:cd /usr/IBM/WebSphere70/AppServer/profiles/TestNode01/bin./stopServer.sh TestServer01f) If migrating a WAS configuration running as a non-root user: change the ownership of themanaged node profile's directory structure.The userid under which the node agent and application server processes run should be theowner of the managed node profile's directory structure, to ensure they have sufficient accesspermissions to all the files they require to run successfully.Example: To change the ownership of the managed node profile's directory structure where thenode agent and application server processes runs as user=wasuser defined in group=wasgroup,enter the following commands:cd /usr/IBM/WebSphere70/AppServer/profileschown -R wasuser:wasgroup TestNode01g) Start the WAS 7.0 managed node's node agent.Start the WAS 7.0 node agent for the migrated managed node in preparation for starting themigrated WAS 7.0 application servers.Example: To start the WAS 7.0 node agent for node TestNode01 from the command line issue thefollowing commands:cd /usr/IBM/WebSphere70/AppServer/profiles/TestNode01/bin./startNode.shh) If the WAS configuration integrates with WebSphere MQ (WMQ): configure the WebSphere MQJMS Provider definitions to reference the WMQ libraries.If applications deployed to the WAS 7.0 configuration access WebSphere MQ using Bindingsmode, it is necessary to configure the IBM WebSphere MQ JMS Provider's Native library pathparameter to reference the location of the WebSphere MQ libraries. For details see the Appendix"WMQ Considerations."

i) Start the WAS 7.0 application servers associated with the migrated managed node profile.Use the WAS 7.0 administration Console to start the WAS 7.0 application server(s).Example: To start a WAS 7.0 application server called TestServer01 using the WAS 7.0administration console complete the following steps:• Log in to the WAS 7.0 administration console.• Expand Servers• Expand Server Types• Expand WebSphere application servers• Select TestServer01.• Click Start• Wait for the server startup to complete.j) Check that the WAS 7.0 node agent and application server(s) started successfully.WAS 7.0 deployment manager is running with one WAS 7.0 node agent and its application server(s)and remaining node agent(s) and application server(s) running at WAS 6.1.3. Migrate the remaining managed nodes.Repeat the steps performed for migrating the first managed node for each of the remaining nodes asappropriate for your environment and requirements.4. Reconfigure ITCAM for WebSphere Data Collectors.If your WAS 6.1 environment had ITCAM for WebSphere Data Collectors configured, you canreconfigure them now to work with the migrated WAS 7.0 environment. For details see Appendix"ITCAM Considerations."5. Convert the WAS 7.0 configuration to use version 7.0 settings.Once all nodes in the configuration have been migrated to WAS 7.0 you should ensure that thefollowing configuration settings are changed to use WAS 7.0 definitions:• Transport• ProcessDef• SSL configurationIf you selected the option -scriptCompatibility=false on the WASPostUpgrade command, then thiswill have been performed automatically during the migration and you need take no further action.If you accepted the default option -scriptCompatibility=true on the WASPostUpgrade command,then these configuration settings were kept at their WAS 6.1 definitions to minimize the impact onany administrative scripts and you should use the following procedure to update your WAS 7.0configuration:a) Review your administration scripts and update them (where applicable) to use the WAS 7.0settings: Channels instead of Transport, ProcessDefs instead of ProcessDef and use of version7.0 SSL.b) Run the convertScriptCompatibility command to convert WAS 7.0 configuration to use the WAS7.0 settings:Example: To run the convertScriptCompatibility command for all nodes and application serversissue the following commands:cd /usr/IBM/WebSphere70/AppServer/profiles/TestDmgr01/bin./convertScriptCompatibility.shNote:This command MUST be run from the deployment manager profile's bin directory.The default options backs up the configuration first and convert all application servers on allnodes. Options are available to convert specific nodes or application servers for more granularcontrol.For full syntax of the convertScriptCompatibility command see the WAS 7.0InfoCenter.c) Perform a full resynchronization of the deployment manager's configuration with each federatednode to produce a consistent configuration.

A running WAS 7.0 clustered environment is created containing the applications and configurationmigrated from WAS 6.1.After performing the migration you may wish to migrate your WAS 7.0 configuration to use the fivecharacter message ids.In WAS 6.1 and 7.0 the format of message ids changed from four characters to five characters. The four character message ids have been deprecated but are maintained for users with a dependency on them.If you had not previously migrated to the five character message ids in WAS 6.1 the message ids willstill be four characters in your migrated WAS 7.0 configuration and the following message will appear inthe SystemOut.log of the deployment manager, node agents and application servers: TRAS0111I: The message Ids that are in use are deprecated. Provided that you have no dependency on the four char message ids (for example, by log parsers or monitoring tools) then you can migrate to the five character message ids as followsTo change the message ids in the JVM logs:• Set the JVM property com.ibm.websphere.logging.messageId.version = 6 for each WAS 7.0 javaprocess (deployment manager, node agent and application servers).• Use a text editor to create a text file called setJVMLogsMessageIds.jy in the /tmp directory with the following content:ls = java.lang.System.getProperty("line.separator")cfgJvmList = AdminConfig.list("JavaVirtualMachine").split(ls)for i in range(len(cfgJvmList)):cfgJvm = cfgJvmList[i]print "Set message id value for JVM "+cfgJvm.split("|")[0]AdminConfig.create('Property', cfgJvm,[['name','com.ibm.websphere.logging.messageId.version'],['value', '6'],['required', 'false']])AdminConfig.save()• Enter the following commands to run the wsadmin jython script:cd /usr/IBM/WebSphere70/AppServer/profiles/TestDmgr01/bin./wsadmin.sh -lang jython -f /tmp/setJVMLogsMessageIds.jyTo change the message ids in the startManager, stopManager, startNode, stopNode, startServer andstopServer log files:• On UNIX:1. Append the following code to the end of the existingD_ARGSparameter in the startManager.sh,stopManager.sh,startNode.sh, stopNode.sh, startServer.sh and stopServer.sh files in theinstall_root/bin directory.$DEBUG -Dcom.ibm.websphere.logging.messageId.version=6

2. Restart the java processes for the changes to take effect.

Result: All subsequent messages issued to the WAS 7.0 logs will contain five character message ids.