InfoCenter Home >
3: Migration overview >
3.8: Running coexisting installations of WebSphere Application Server on a single machine

3.8: Running coexisting installations of WebSphere Application Server on a single machine

This article describes various coexistence scenarios that WebSphere Application Server supports and the steps required to achieve coexistence.

What is meant by "coexistence of WebSphere"?

Coexistence of WebSphere encompasses any of the following:

  • Running different releases of WebSphere Application Server on a single machine at the same time
  • Running multiple instances of a single version of WebSphere Application Server on a single machine at the same time
  • Running multiple instances of WebSphere Application Server from multiple installations at the same time

As part of coexistence, you can configure a single Web server for multiple instances or releases of WebSphere Application Server or configure a separate instance of a Web server for each instance or release of WebSphere Application Server.

Planning for coexistence

Before you install WebSphere Application Server, consider the following issues:

  1. Do you need to upgrade WebSphere supporting software to have coexisting installations of WebSphere Application Server? For coexistence of WebSphere Application Server Version 3.5 and WebSphere Application Server Version 4.0, you must upgrade software so it supports WebSphere Application Server Version 4.0; that is, you must use software that is common among the releases. For example, levels of Web servers common among WebSphere Application Server Versions 3.5 and 4.0 include: IBM HTTP Server 1.3.19, Apache HTTP Server 1.3.20, iPlanet Web Server 4.1 SP7, Lotus Domino 5.0.6, and Microsoft IIS 4.0 on Windows NT and 5.0 on Windows 2000. Examine the WebSphere supporting software Web page at http://www.ibm.com/software/webservers/appserv/doc/latest/prereq.html to see if you can use common levels of supporting software for your desired installations.

  2. Do you need to resolve conflicts in the desired configurations? Supported configurations include:
    • WebSphere Application Server Versions 3.5 and later releases and 4.0 and later releases
    • Multiple domain configuration of WebSphere Application Server Advanced Edition from a single installation
    • Multiple domain configuration of WebSphere Application Server Advanced Edition from multiple installations
    • WebSphere Application Advanced Single Server Edition and WebSphere Application Server Advanced Edition

    Determine whether you need a single instance of a Web server with mutiple instances of WebSphere Application Server or a separate instance of a Web server with each instance of WebSphere Application Server. See " Configuring Web servers" for details on selecting a single Web server instance or multiple Web server instances.

  3. Does the machine have enough system resources to handle coexistence? Based on system requirements for each instance, determine if your system has enough resources to support coexistence.

  4. Will you need to install WebSphere Application Server FixPaks (PTFs)?

    If you do need to install PTFs, you must address issues such as the following for Windows: when installing Version 3.5 PTFs earlier than 3.5.5, the PTF installer uses WAS_HOME to determine the location of where to install the PTF. If installing 3.5.4 or earlier PTFs when Version 4.0 or later releases is already installed, the PTF installer will install into the Version 4.0 WebSphere directory. Before installing a PTF earlier than Version 3.5.5, update the WAS_HOME entry to point to WebSphere Application Server Version 3.5 and, after the installation completes, switch it back to the Version 4.0 location.

Installing various supported configurations

This section describes how to install the supported configurations. References to Version 3.5 includes 3.5 and all later releases and FixPaks. References to Version 4.0 includes 4.0 and all later releases and FixPaks.

Enabling coexistence of WebSphere Application Server Version 3.5 and WebSphere Application Server Advanced Edition Version 4.0, where both use a common Web server

Assuming Version 3.5 is already installed on your system, complete the following steps to enable installations of WebSphere Application Server to co-exist. For these steps, the assumed Version 3.5 installation root is \WebSphere35\AppServer.

  1. Use XMLConfig in WebSphere Application Server Version 3.5 to back up the configuration so that you can repair inadvertent mistakes in configurations.
  2. Stop WebSphere Application Server Version 3.5.
  3. Upgrade your Web server to the version commonly supported by different versions of WebSphere Application Server. For example, if your system is using IBM HTTP Server Version 1.3.12 but needs Version 1.3.19 to support coexisting installations of WebSphere Application Server, upgrade IBM HTTP Server to 1.3.19.
  4. Back up the HTTP configuration file of your Web server (for example, httpd.conf for IBM HTTP Server and obj.conf for Sun ONE [iPlanet] Web Server V4.1 or both obj.conf and magnus.conf for Sun ONE V6.0) so that you can repair inadvertent mistakes in configurations.
  5. Install WebSphere Application Server Advanced Edition Version 4.0. For coexistence of Versions 3.5 and 4.0, specify a different database for your repository when prompted by the Version 4.0 installation program. Also, specify a different location (for example, \WebSphere40\AppServer) for the installation directory from that of Version 3.5. When installing Version 4.0, do not select any Web server plug-in.
  6. After successfully installing WebSphere Application Server Advanced Edition Version 4.0, create the database that is specified in the install screens (for example, WAS40). On Windows with DB2 as the repository, the specified database will be created when system reboots.
  7. Fix the Web server HTTP configuration to support both releases of WebSphere Application Server.
  8. Fix conflicting ports in the WebSphere Application Server instances. Choose port numbers not being used by other applications. For the Version 4.0 Advanced Edition, add com.ibm.ejs.sm.adminServer.lsdPort=9001 and com.ibm.ejs.sm.adminServer.bootstrapPort=901 to the 4.0 admin.config file in the \WebSphere40\AppServer\bin directory. Select an unused port. Write down the name of the bootstrap port.
  9. Configure a virtual host, if needed. For information on virtual hosts, see the WebSphere Application Server Version 4.0 InfoCenter.
  10. Start both releases of WebSphere Application Server.
  11. Run tools as needed to support coexistence.

    For example, installing WebSphere Application Server Version 4.0 updates the system variable PATH, potentially affecting tools with the same name across installations. To run tools with conflicting names, alter the PATH environment variable in a command window and place the directory for the former WebSphere installation before the directory for the latter WebSphere installation (for example, PATH=E:\WebSphere\AppServer\35\bin;%PATH%). Then, invoke the tools from the bin directory.

    Further, specify the bootstrap port. In coexistence environments, you must configure different WebSphere instances with different bootstrap ports. While invoking the tools, specify the bootstrap port of the server you are trying to access. For example, if the bootstrap port is 901, to start the administrative client on Windows, enter adminclient.bat localhost 901. For information, see "Using WebSphere Application Server tools."

  12. Stop the WebSphere Application Server administrative server.

    Note that, on Windows, if both versions are running and the administrative server (either Version 3.5 or 4.0) is stopped using the Services panel, the last-started application server stops and leaves the other instance running, but the Services panel shows both instances as stopped. Thus, use the WebSphere administrative console to stop an administrative server (stop the node).

Enabling coexistence of WebSphere Application Server Version 3.5 and and later releases and WebSphere Application Server Advanced Edition Version 4.0 and later releases using separate instances of a Web server

Assuming Version 3.5 is already installed on your system, complete steps such as those described in this section to enable installations of WebSphere Application Server to co-exist. For these steps, the assumed Version 3.5 installation root is \WebSphere35\AppServer.

  1. Use XMLConfig in WebSphere Application Server Version 3.5 to back up the configuration so that you can repair inadvertent mistakes in configurations.
  2. Stop WebSphere Application Server Version 3.5.
  3. Upgrade your Web server to the version commonly supported by different versions of WebSphere Application Server. For example, if your system is using IBM HTTP Server Version 1.3.12 but needs Version 1.3.19 to support coexisting installations of WebSphere Application Server, upgrade IBM HTTP Server to 1.3.19.
  4. Create a second instance of the Web server. For IBM HTTP Server, see "Fixing an IBM HTTP Server configuration for WebSphere Application Server Version 3.5." Write down the port number that is being used for the second instance of the Web server.
  5. Back up the HTTP configuration file of your Web server (for example, httpd.conf for IBM HTTP Server and obj.conf for Sun ONE [iPlanet] Web Server V4.1 or both obj.conf and magnus.conf for Sun ONE V6.0) so that you can repair inadvertent mistakes in configurations.
  6. Install WebSphere Application Server Advanced Edition Version 4.0. For coexistence of Versions 3.5 and 4.0, specify a different database for your repository when prompted by the Version 4.0 installation program. Also, specify a different location (for example, \WebSphere40\AppServer) for the installation directory from that of Version 3.5. When installing Version 4.0, select the Web server plug-in that you need to supoort a second instance of the Web server. If you are using IBM HTTP Server, the installation program does not give the option of creating a second instance configuration file; thus, after installation, fix the Web server configuration manually.
  7. After successfully installing WebSphere Application Server Advanced Edition Version 4.0, create the database that is specified in the install screens (for example, WAS40). On Windows with DB2 as the repository, the specified database will be created when system reboots.
  8. Fix conflicting ports in the WebSphere Application Server instances. Choose port numbers not being used by other applications. For the Version 4.0 Advanced Edition, add com.ibm.ejs.sm.adminServer.lsdPort=9001 and com.ibm.ejs.sm.adminServer.bootstrapPort=901 to the 4.0 admin.config file in the \WebSphere40\AppServer\bin directory. Select an unused port. Write down the name of the bootstrap port.
  9. Configure a virtual host to support the second Web server instance, if needed. For information on virtual hosts, see the WebSphere Application Server Version 4.0 InfoCenter.
  10. Start both releases of WebSphere Application Server.
  11. Run tools as needed to support coexistence.

    For example, installing WebSphere Application Server Version 4.0 updates the system variable PATH, potentially affecting tools with the same name across installations. To run tools with conflicting names, alter the PATH environment variable in a command window and place the directory for the former WebSphere installation before the directory for the latter WebSphere installation (for example, PATH=E:\WebSphere\AppServer\35\bin;%PATH%). Then, invoke the tools from the bin directory.

    Further, specify the bootstrap port. In coexistence environments, you must configure different WebSphere instances with different bootstrap ports. While invoking the tools, specify the bootstrap port of the server you are trying to access. For example, if the bootstrap port is 901, to start the administrative client on Windows, enter adminclient.bat localhost 901. For information, see "Using WebSphere Application Server tools."

  12. Stop the WebSphere Application Server administrative server.

    Note that, on Windows, if both versions are running and the administrative server (either Version 3.5 or 4.0) is stopped using the Services panel, the last-started application server stops and leaves the other instance running, but the Services panel shows both instances as stopped. Thus, use the WebSphere administrative console to stop an administrative server (stop the node).

Enabling coexistence of multiple domains of WebSphere Application Server Advanced Edition Version 4.0 from a single installation using a single instance of a Web server

This section describes how to configure multiple domains from one installation of WebSphere Application Server Advanced Edition.

  1. Install WebSphere Application Server Advanced Edition Version 4.0. For these steps, the installation root directory is \WebSphere\AppServer.
  2. Copy the admin.config file in the directory \WebSphere\AppServer, naming it admin-sec.config. If you have already started the WebSphere Application Server before making a copy, open an editor on the admin-sec.config file and change the following properties to true.
    • install.initial.config=true
    • com.ibm.ejs.sm.adminServer.createTables=true
  3. Open an editor on the admin-sec.config file and make the following changes:
    1. Change the conflicting ports. Add the following to the bottom of the file:
      com.ibm.ejs.sm.adminServer.lsdPort=9001
      com.ibm.ejs.sm.adminServer.bootstrapPort=901
    2. Change the log file names. Edit the respective properties to the following. Note that the properties should each be on one line, though some appear here on more than one line to improve readability.
      com.ibm.ejs.sm.adminServer.traceFile=I:/WebSphere/AppServer-AE/logs/tracefile-sec
      com.ibm.ejs.sm.util.process.Nanny.traceFile=I:/WebSphere/AppServer-AE/logs/nanny-sec.trace
      com.ibm.ejs.sm.adminServer.logFile=I:/WebSphere/AppServer-AE/tranlog/planetjava_tranlog1-sec,
      I:/WebSphere/AppServer-AE/tranlog/planetjava_tranlog2-sec
    3. Change the database name to was40sec:
      com.ibm.ejs.sm.adminServer.dbdatabaseName=was40sec
  4. Copy the adminserver.(sh/bat) file in \WebSphere\AppServer\bin and name the copy adminserver-sec.(sh/bat).
  5. Optional: If you need different security settings for different domains, copy the \WebSphere\AppServer\properties\sas.server.properties file and change the copy to meet your needs. See the Version 4.0 InfoCenter for more details.
    1. Change the property com.ibm.CORBA.ConfigURL in the admin.config file to point to the new file. For example:
      com.ibm.CORBA.ConfigURL=file:/f:/WebSphere/40/AE/properties/sas2.server.props
    2. Copy the setupCmdLine.(sh/bat) file and name it setupCmdLine-sec.(sh/bat). Then, open an editor on setupCmdLine-sec.(sh/bat) and change SERVERSAS to point to the new properties file. Also, if desired, change CLIENTSAS and WCSCLIENTSAS to point to the new files.
  6. Open an editor on the adminserver-sec.(sh/bat) file and change %WAS_HOME%\bin\admin.config to %WAS_HOME%\bin\admin-sec.config. If you changed the location of the sas.*.properties files in earlier steps, look for the setupCmdLine.(sh/bat) invocation in the adminserver-sec.(sh/bat) file and change adminserver-sec(sh/bat) to invoke the setupCmdLine-sec.(sh/bat) file.
  7. Start the first WebSphere Application Server domain:
    1. Go to a command prompt and move to the \WebSphere\AppServer\bin directory.
    2. Run adminserver.(sh/bat).
    3. Start the administrative console using the command adminclient.(sh/bat).
  8. Start the second WebSphere Application Server domain:
    1. Go to a command prompt and move to the \WebSphere\AppServer\bin directory.
    2. Run adminserver-sec.(sh/bat).
    3. Start the administrative console using the command
      adminclient.(sh/bat) localhost 901

      If you modified client CLIENTSAS properties in an earlier step, create a separate copy of the adminclient.(sh/bat) file to invoke the modified setupcmdline.(sh/bat) file and run the modified adminclient script for the second instance.

  9. Deploy your application.
    1. Copy the EAR file.
      You need two copies of the EAR file.
    2. Give each EAR file a unique name.
      Each EAR file needs a unique name because all instances share the installableApps directory.
    3. Deploy the uniquely named EAR files.
      During deployment, each instance accesses a subdirectory in the installedApps directory named for each unique EAR file. The result is each instance deployed into a subdirectory in the installedApps directory.

      It is recommended that you use the Application Assembly Tool to build the EAR file for deployment. The EAR file can then be installed using the administrative console.

      You can follow tasks to deploy applications in the Application deployment tutorial.

  10. If you are using the default server in the second domain, modify conflicting ports in the default server of the second domain. (If you are not using the default server in the second domain, this step is not required.)
    1. In the second administrative console started in the previous step, select Virtual Hosts, right-click on default_host in the right pane, and select Properties. Under Aliases in the Virtual Host Properties dialog, change the list host aliases so it includes the aliases *:81 and *:9081 and click OK.
    2. In the second administrative console, select your server, Application Servers, Default Server and, on the right in the Default Server's Services tab, select Web Container Service and click Edit Properties. In the Web Container Service dialog, under HTTP transports, change the port for host * to 9081 and click OK.
  11. To set up a single, shared Web server instance, manually merge the plugin-cfg.xml files for the two server instances into a single plugin-cfg.xml file for use by the server:
    1. Remove or rename the \WebSphere\AppServer\config\plugin-cfg.xml file.
    2. Run the command
      GenPluginCfg.(bat/sh) -nodeName node_name-nameServicePort 900

      The command generates \WebSphere\AppServer\config\plugin-cfg.xml. Copy the file and name it plugin-cfg1.xml.

    3. Run the command
      GenPluginCfg.(bat/sh) -nodeName node_name-nameServicePort 901

      The command generates \WebSphere\AppServer\config\plugin-cfg.xml. Copy the file and name it plugin-cfg2.xml.

    4. Manually merge the contents of the two files into the /WebSphere/AppServer/config/plugin-cfg.xml file.
  12. If you are using WebSphere Application Server versions that do not support the same version of a specific Web server, you must do the following steps to configure the plug-ins for multiple WebSphere Application Server instances:
    1. Configure multiple Web servers instances with only one instance listening on port 80.
      The Web server listening on port 80 can have as few as 0 (zero) or one WebSphere plug-in.
    2. For URLs that are handled by another Web server instance, you need to redirect the request of the Web server listening on port 80 to a different port so that the appropriate Web server/WebSphere product combination serves the request.
  13. Change files and locations:
    1. Select the default server in the administrative console of the second domain.
    2. Specify different log files for the default server:
      1. Select File in the right-hand panel.
      2. Change the Standard Output and Standard Input file names so they are different from that of the first domain.
    3. Specify a different temporary directory for JSP files:
      1. Select JVM Settings in the right-hand panel.
      2. Specify the system property com.ibm.websphere.servlet.temp.dir=\WebSphere\AppServer\mytemp. See the Version 4.0 InfoCenter for more information on specifying system properties.
Enabling coexistence of multiple domains of WebSphere Application Server Advanced Edition Version 4.0 from a single installation using multiple instances of a Web server

This section describes how to configure multiple domains from one installation of WebSphere Application Server Advanced Edition.

  1. Install WebSphere Application Server Advanced Edition Version 4.0. For these steps, the installation root directory is \WebSphere\AppServer.
  2. Copy the admin.config file in the directory \WebSphere\AppServer, naming it admin-sec.config. If you have already started the WebSphere Application Server before making a copy, open an editor on the admin-sec.config file and change the following properties to true.
    • install.initial.config=true
    • com.ibm.ejs.sm.adminServer.createTables=true
  3. Open an editor on the admin-sec.config file and make the following changes:
    1. Change the conflicting ports. Add the following to the bottom of the file:
      com.ibm.ejs.sm.adminServer.lsdPort=9001
      com.ibm.ejs.sm.adminServer.bootstrapPort=901
    2. Change the log file names. Edit the respective properties to the following. Note that the properties should each be on one line, though some appear here on more than one line to improve readability.
      com.ibm.ejs.sm.adminServer.traceFile=I:/WebSphere/AppServer-AE/logs/tracefile-sec
      com.ibm.ejs.sm.util.process.Nanny.traceFile=I:/WebSphere/AppServer-AE/logs/nanny-sec.trace
      com.ibm.ejs.sm.adminServer.logFile=I:/WebSphere/AppServer-AE/tranlog/planetjava_tranlog1-sec,
      I:/WebSphere/AppServer-AE/tranlog/planetjava_tranlog2-sec
    3. Change the database name to was40sec:
      com.ibm.ejs.sm.adminServer.dbdatabaseName=was40sec
  4. Copy the adminserver.(sh/bat) file in \WebSphere\AppServer\bin and name the copy adminserver-sec.(sh/bat).
  5. Optional: If you need different security settings for different domains, copy the \WebSphere\AppServer\properties\sas.server.properties file and change the copy to meet your needs. See the Version 4.0 InfoCenter for more details.
    1. Change the property com.ibm.CORBA.ConfigURL in the admin.config file to point to the new file. For example:
      com.ibm.CORBA.ConfigURL=file:/f:/WebSphere/40/AE/properties/sas2.server.props
    2. Copy the setupCmdLine.(sh/bat) file and name it setupCmdLine-sec.(sh/bat). Then, open an editor on setupCmdLine-sec.(sh/bat) and change SERVERSAS to point to the new properties file. Also, if desired, change CLIENTSAS and WCSCLIENTSAS to point to the new files.
  6. Open an editor on the adminserver-sec.(sh/bat) file and change %WAS_HOME%\bin\admin.config to %WAS_HOME%\bin\admin-sec.config. If you changed the location of the sas.*.properties files in earlier steps, look for the setupCmdLine.(sh/bat) invocation in the adminserver-sec.(sh/bat) file and change adminserver-sec(sh/bat) to invoke the setupCmdLine-sec.(sh/bat) file.
  7. Start the first WebSphere Application Server domain:
    1. Go to a command prompt and move to the \WebSphere\AppServer\bin directory.
    2. Run adminserver.(sh/bat).
    3. Start the administrative console using the command adminclient.(sh/bat).
  8. Start the second WebSphere Application Server domain:
    1. Go to a command prompt and move to the \WebSphere\AppServer\bin directory.
    2. Run adminserver-sec.(sh/bat).
    3. Start the administrative console using the command
      adminclient.(sh/bat) localhost 901

      If you modified client CLIENTSAS properties in an earlier step, create a separate copy of the adminclient.(sh/bat) file to invoke the modified setupcmdline.(sh/bat) file and run the modified adminclient script for the second instance.

  9. If you are using the default server in the second domain, modify conflicting ports in the default server of the second domain. (If you are not using the default server in the second domain, this step is not required.)
    1. In the second administrative console started in the previous step, select Virtual Hosts, right-click on default_host in the right pane, and select Properties. Under Aliases in the Virtual Host Properties dialog, change the list host aliases so it includes the aliases *:81 and *:9081 and click OK.
    2. In the second administrative console, select your server, Application Servers, Default Server and, on the right in the Default Server's Services tab, select Web Container Service and click Edit Properties. In the Web Container Service dialog, under HTTP transports, change the port for host * to 9081 and click OK.
  10. To set up multiple instances of the Web server instance, generate the plugin-cfg.xml files for the two server instances:
    1. Run the command
      GenPluginCfg.(bat/sh) -nodeName node_name-nameServicePort 901

      The command generates \WebSphere\AppServer\config\plugin-cfg.xml. Copy the file and name it plugin-cfg2.xml.

    2. Remove or rename the \WebSphere\AppServer\config\plugin-cfg.xml file.
    3. Run the command
      GenPluginCfg.(bat/sh) -nodeName node_name-nameServicePort 900

      where node_name is the host name that appears in the WebSphere Application Server administrative console under the WebSphere administrative domain. The command generates \WebSphere\AppServer\config\plugin-cfg.xml.

  11. Create a second instance of the Web server. Specify information for the WebSphere plug-in and the location of the plug-in configuration file (/temp/server2_directory) in the second instance of the Web server configuration file. See "Creating and configuring multiple instances of IBM HTTP Server for multiple installations of WebSphere Application Server Version 4.0."
  12. Specify a virtual host, if needed. For information on virtual hosts, see the WebSphere Application Server Version 4.0 InfoCenter.
  13. Change files and locations:
    1. Select the default server in the administrative console of the second domain.
    2. Specify different log files for the default server:
      1. Select File in the right-hand panel.
      2. Change the Standard Output and Standard Input file names so they are different from that of the first domain.
    3. Specify a different temporary directory for JSP files:
      1. Select JVM Settings in the right-hand panel.
      2. Specify the system property com.ibm.websphere.servlet.temp.dir=\WebSphere\AppServer\mytemp. See the Version 4.0 InfoCenter for more information on specifying system properties.
Enabling coexistence of multiple domains of WebSphere Application Server Advanced Edition Version 4.0 from multiple installations

This section describes how to run multiple instances of WebSphere Application Server Advanced Edition. Having multiple instances allows, for example, different developers to have their own environment (instance) of the Advanced Edition running their application on a single machine.

To begin, install Version 4.0 FixPak 2 (4.0.2) of the Advanced Edition once on a single machine. Then, complete the steps below.

  1. If you want to use a different Web server for the second instance, create a second instance of the Web server.
  2. Install the second instance of WebSphere Advanced Edition in a different location from that of previous installation (for example, /WebSphere/AppServer2/). If you use a different Web server instance for the second installation, choose that Web server configuration when installing. With IBM HTTP Server as the Web server, the installation program will not give you the option to select the second instance configuration file; thus, after successfully installing WebSphere Application Server, fix the IBM HTTP Server configuration manually. If you use a single instance of the Web server for both instances, do not select a plug-in in the installation program. Further, choose a different database repository than that of the previous installation.
  3. Open an editor on the /WebSphere/AppServer2/bin/admin-sec.config file and change the conflicting ports. Add the following to the bottom of the file:
    com.ibm.ejs.sm.adminServer.lsdPort=9001
    com.ibm.ejs.sm.adminServer.bootstrapPort=901
  4. Start the first WebSphere Application Server domain:
    1. Go to a command prompt and move to the \WebSphere\AppServer\bin directory.
    2. Run adminserver.(sh/bat).
    3. Start the administrative console using the command adminclient.(sh/bat).
  5. Start the second WebSphere Application Server domain:
    1. Go to a command prompt and move to the \WebSphere\AppServer\bin directory.
    2. Run adminserver-sec.(sh/bat).
    3. Start the administrative console using the command
      adminclient.(sh/bat) localhost 901

      If you modified client CLIENTSAS properties in an earlier step, create a separate copy of the adminclient.(sh/bat) file to invoke the modified setupcmdline.(sh/bat) file and run the modified adminclient script for the second instance.

  6. If you are using the default server in the second domain, modify conflicting ports in the default server of the second domain. (If you are not using the default server in the second domain, this step is not required.)
    1. In the second administrative console started in a previous step, select Virtual Hosts, right-click on default_host in the right pane, and select Properties. Under Aliases in the Virtual Host Properties dialog, change the list host aliases so it includes the aliases *:81 and *:9081 and click OK.
    2. In the second administrative console, select your server, Application Servers, Default Server and, on the right in the Default Server's Services tab, select Web Container Service and click Edit Properties. In the Web Container Service dialog, under HTTP transports, change the port for host * to 9081 and click OK.
  7. To set up a single, shared Web server instance, manually merge the plug-in configuration files for the two server instances into a single plugin-cfg.xml file for use by the server:
    1. Remove or rename the \WebSphere\AppServer\config\plugin-cfg.xml file.
    2. Run the command
      GenPluginCfg.(bat/sh) -nodeName node_name-nameServicePort 900

      where node_name is the host name that appears in the WebSphere Application Server administrative console under WebSphere administrative domain. The command generates \WebSphere\AppServer\config\plugin-cfg.xml.

    3. Run the command
      GenPluginCfg.(bat/sh) -nodeName node_name-nameServicePort 901

      The command generates \WebSphere\AppServer2\config\plugin-cfg.xml.

    4. Manually merge the contents of the two generated files and replace both the files with the merged one.
Enabling coexistence of WebSphere Application Server Advanced Edition Version 4.0 and WebSphere Application Server Advanced Single Server Edition Version 4.0

This section describes how to run WebSphere Application Server Advanced Edition Version 4.0 and WebSphere Application Server Advanced Single Server Edition Version 4.0 on the same machine. Having multiple instances allows, for example, different developers to have their own environment (instance) of the Advanced Edition running their application on a single machine.

To begin, install Version 4.0 FixPak 2 (4.0.2) of the Advanced Single Server Edition once on a single machine. Then, complete the steps below.

  1. If you want to use a different Web server for the second instance, create a second instance of the Web server.
  2. Install the WebSphere Advanced Edition in a different location from that of the WebSphere Advanced Single Server Edition previously installed (for example, /WebSphere/AppServer2/). If you want a different Web server instance for the second installation, choose that Web server configuration when installing. If you want to use a single instance of the Web server for both instances, do not select a plug-in in the installation program.
  3. Open an editor on the /WebSphere/AppServer2/bin/admin-sec.config file and change the conflicting ports. Add the following to the bottom of the file:
    com.ibm.ejs.sm.adminServer.lsdPort=9001
    com.ibm.ejs.sm.adminServer.bootstrapPort=901
  4. Start the WebSphere Application Server Advanced Single Server product:
    1. Go to a command prompt and move to the \WebSphere\AppServer\bin directory.
    2. Run sartupServer(sh/bat).
  5. Start the WebSphere Application Server Advanced Edition product:
    1. Go to a command prompt and move to the \WebSphere\AppServer2\bin directory.
    2. Run adminserver-sec.(sh/bat).
    3. Start the administrative console using the command
      adminclient.(sh/bat) localhost 901
  6. If you are using the default server in the Advanced Edition, modify conflicting ports in the default server of the Advanced Edition. (If you are not using the default server in the Advanced Edition, this step is not required.)
    1. In the Advanced Edition administrative console started in a previous step, select Virtual Hosts, right-click on default_host in the right pane, and select Properties. Under Aliases in the Virtual Host Properties dialog, change the list host aliases so it includes the aliases *:81 and *:9081 and click OK.
    2. In the second administrative console, select your server, Application Servers, Default Server and, on the right in the Default Server's Services tab, select Web Container Service and click Edit Properties. In the Web Container Service dialog, under HTTP transports, change the port for host * to 9081 and click OK.
  7. To set up a single, shared Web server instance, manually merge the plug-in configuration files for the two server instances into a single plugin-cfg.xml file for use by the server:
    1. Run the command for the Advanced Single Server Edition (shown here on two lines to improve readability):
      /WebSphere/AppServer/GenPluginCfg.(bat/sh) -configFile server1_configuration_file
      -outputFile /temp/server1_directory

      The command generates /WebSphere/AppServer/config/plugin-cfg.xml.

    2. Run the command for the Advanced Edition:
      GenPluginCfg.(bat/sh) -nodeName node_name-nameServicePort 901

      The command generates /WebSphere/AppServer2/config/plugin-cfg.xml.

    3. Manually merge the contents of the two generated files and replace both the files with the merged one.
Enabling coexistence of WebSphere Application Server Advanced Edition Version 3.5 and WebSphere Application Server Advanced Edition Version 4.0 with security on

When security is enabled, it is also needed to configure each instance with a different LSDSSL port which is not used. WebSphere Application Server Version 3.5 uses 9001 as LSDSSL port.

To specify LSDSSL port in WebSphere Application Server Advanced Edition Version 4.0, add the following property in the admin.config file:

com.ibm.ejs.sm.adminserver.lsdPort=9020
com.ibm.CORBA.LSDSSLPort=9011

Configuring Web servers

This section covers the following:

Upgrading from IBM HTTP Server Version 1.3.12 to Version 1.3.19

To upgrade from IBM HTTP Server Version 1.3.12 to 1.3.19, do the following for the appropriate platform. The following steps assume that WebSphere Application Server Version 3.5 is installed with IBM HTTP Server Version 1.3.12. After upgrading to IBM HTTP Server Version 1.3.19, fix the configuration for WebSphere Application Server Version 3.5.

AIX
  1. Stop the IBM HTTP Server and IBM HTTP Administration servers.
  2. Copy the httpd.conf file in the IBM HTTP Server conf directory and name the copy httpd-35.conf.
  3. Install IBM HTTP Server 1.3.19 over the existing 1.3.12 product using the smit option Update Installed Software to Latest Level (Update ALL) or the installp command:
    installp_cmd -a -d 'IHS_source_directory -f' '_update_all' '-c' '-N' '-g' '-x'

To execute the new ikeyman installed with IBM HTTP Server, you might need to point ikeyman to the IBM Software Developer Kit installed with WebSphere. Set the JAVA_HOME environment variable to point to the software development kit and then run ikeyman.

HP-UX and Solaris
  1. Stop the IBM HTTP Server and IBM HTTP Administration servers.
  2. Copy the httpd.conf file in the IBM HTTP Server conf directory and name the copy httpd-35.conf.
  3. Uninstall IBM HTTP Server Version 1.3.12 and then install IBM HTTP Server Version 1.3.19.

To execute the new ikeyman installed with IBM HTTP Server, you might need to point ikeyman to the system's Java Development Kit or to the Kit installed with WebSphere. Set the JAVA_HOME environment variable to point to Kit supported by WebSphere and then run ikeyman.

Windows NT or 2000
  1. In a Services dialog, stop the IBM HTTP Server and IBM HTTP Administration services.
  2. Copy the httpd.conf file in the IBM HTTP Server conf directory and name the copy httpd-35.conf.
  3. Uninstall IBM HTTP Server 1.3.12.
  4. Install IBM HTTP Server 1.3.19.
Fixing an IBM HTTP Server configuration for WebSphere Application Server Version 3.5
UNIX

Open an editor on the httpd.conf file for IBM HTTP Server Version 1.3.19 and add the following lines at the bottom of the file based on your installation root. Following are the entries for Solaris. Check in the backed-up configuration file httpd-35.conf for the appropriate extensions for other UNIX platforms. For AIX, WebSphere Application Server usually installs into the /usr directory.

LoadModule ibm_app_server_module  /opt/WebSphere/AppServer/bin/mod_ibm_app_server.so
AddModule mod_app_server.c
NcfAppServerConfig BootFile  /opt/WebSphere/AppServer/properties/bootstrap.properties
Alias /IBMWebAS/  /opt/WebSphere/AppServer/web/

If the directory structure is not deleted when IBM HTTP Server 1.3.12 was uninstalled and IBM HTTP Server 1.3.19 is installed in the same location, settings in httpd.conf are preserved. In that case above steps are optional. Check the httpd.conf file to make sure entries are there in the file.

Windows NT

Open an editor on the httpd.conf file for IBM HTTP Server 1.3.19 and add the following lines at the bottom of the file. (These entries are in the backed-up httpd-35.conf file.)

LoadModule ibm_app_server_module drive_letter:/WebSphere/AppServer/bin/mod_ibm_app_server.dll
NcfAppServerConfig BootFile drive_letter:\WebSphere\AppServer\properties\bootstrap.properties
Alias /IBMWebAS/ "drive_letter:/WebSphere/AppServer/web/"
Fixing an IBM HTTP Server configuration for WebSphere Application Server Version 4.0

Websphere Application Server Version 4.0 requires the following entries in the HTTP configuration file for the Web server:

UNIX
LoadModule ibm_app_server_http_module/opt/WebSphere40/AppServer/bin/mod_ibm_app_server_http.so
AddModule mod_app_server_http.c
Alias /Wssamples "/opt/WebSphere40/AppServer/WSsamples/"
WebSpherePluginConfig /opt/WebSphere40/AppServer/configplugin-cfg.xml

Note that the above entry for LoadModule points to the mod_ibm_app_server_http.so file, which is Solaris-specific. For other UNIX platforms specify the library accordingly by checking the file extension in the /WebSphere/AppServer/bin directory. For AIX, usually WebSphere Application Server installs under the /usr directory. So, change the file based on your installation root.

Windows NT or 2000
LoadModule ibm_app_server_http_module drive_letter:/WebSphere40/AppServer/bin/mod_ibm_app_server_http.dll
Alias /Wssamples "drive_letter:/WebSphere40/AppServer/WSsamples/"
WebSpherePluginConfig drive_letter:\WebSphere40\AppServer\config\plugin-cfg.xml
Creating multiple instances of IBM HTTP Server for WebSphere Application Server Versions 3.5 and 4.0

The following steps assume that you have upgraded to IBM HTTP Server Version 1.3.19 and configured IBM HTTP Server for Version 3.5 using the previous section.

  1. Copy the httpd.conf file and name the copy httpd2.conf. Open an editor on httpd2.conf and remove lines corresponding to Version 3.5. That is, remove the lines that added in the previous section, "Fixing an IBM HTTP Server configuration for WebSphere Application Server Version 4.0."
  2. Select the port for the second instance. Select the port that is not in use by any other application. Open an editor on the httpd2.conf file and change the port 80 to 81.
  3. UNIX only: Copy the file IBM_HTTP_SERVER_ROOT_DIR/bin/apachectl and name the file IBM_HTTP_SERVER_ROOT_DIR/bin/apachectl2. Open and editor on apachectl2 and modify the variables PIDFILE and HTTPD to point to httpd2.pid and httpd2.conf as shown below (the directory /opt/IBMHTTPD is assumed to be IBM_HTTP_SERVER_ROOT_DIR:
    PIDFILE=/opt/IBMHTTPD/logs/httpd2.pid
    
    HTTPD="/opt/IBMHTTPD/bin/httpd -f /opt/IBMHTTPD/conf/httpd2.conf"
      Warning: The above steps in this section have you configure the httpd.conf file. The http.conf file contains information such as log files, root directory, and security information in addition to configuration information. If changes beyond those outlined in these steps are needed, consult the IBM HTTP Server documentation before making the changes. Also, you might want to create a corresponding IBM HTTP Server administrative server for each IBM HTTP Server instance created. An IBM HTTP Server administrative server is basically another instance of IBM HTTP Server using a different port (8008 instead of 80) and a different configuration file (admin.conf instead of httpd.conf).

  4. Start the IBM HTTP Server instances.

    UNIX

    To start the first IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR/bin. Then, run the command

    apachectl start
    To start the second IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR/bin. Then, run the command
    apachectl2 start

    Windows NT

    To start the first IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR. Then, run the command

    apache-f .\conf\httpd.conf
    To start the second IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR. Then, run the command
    apache-f .\conf\httpd2.conf

Creating and configuring multiple instances of IBM HTTP Server for a single installation of WebSphere Application Server Version 4.0

The following steps assume that you have installed WebSphere Application Server Version 4.0 and configured it for IBM HTTP Server 1.3.19.

  1. Copy the httpd.conf file and name the copy httpd2.conf. Open an editor on httpd2.conf and modify it to point to the second instance's WebSphere plug-in configuration file. For example:
    WebSpherePluginConfig I:/WebSphere/AppServer/config/plugin-cfg2.xml
  2. Select the port for the second instance. Select the port that is not being used by any other application. Open an editor on the httpd2.conf file and change the port 80 to 81.
  3. UNIX only: Copy the file IBM_HTTP_SERVER_ROOT_DIR/bin/apachectl and name the file IBM_HTTP_SERVER_ROOT_DIR/bin/apachectl2. Open and editor on apachectl2 and modify the variables PIDFILE and HTTPD to point to httpd2.pid and httpd2.conf as shown below (the directory /opt/IBMHTTPD is assumed to be IBM_HTTP_SERVER_ROOT_DIR:
    PIDFILE=/opt/IBMHTTPD/logs/httpd2.pid
    
    HTTPD="/opt/IBMHTTPD/bin/httpd -f /opt/IBMHTTPD/conf/httpd2.conf"
      Warning: The above steps in this section have you configure the httpd.conf file. The http.conf file contains information such as log files, root directory, and security information in addition to configuration information. If changes beyond those outlined in these steps are needed, consult the IBM HTTP Server documentation before making the changes. Also, you might want to create a corresponding IBM HTTP Server administrative server for each IBM HTTP Server instance created. An IBM HTTP Server administrative server is basically another instance of IBM HTTP Server using a different port (8008 instead of 80) and a different configuration file (admin.conf instead of httpd.conf).

  4. Start the IBM HTTP Server instances.

    UNIX

    To start the first IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR/bin. Then, run the command

    apachectl start
    To start the second IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR/bin. Then, run the command
    apachectl2 start

    Windows NT

    To start the first IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR. Then, run the command

    apache-f .\conf\httpd.conf
    To start the second IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR. Then, run the command
    apache-f .\conf\httpd2.conf

Creating and configuring multiple instances of IBM HTTP Server for multiple installations of WebSphere Application Server Version 4.0

The following steps assume that you have installed WebSphere Application Server Version 4.0 and configured it for IBM HTTP Server 1.3.19.

  1. Copy the httpd.conf file and name the copy httpd2.conf. Open an editor on httpd2.conf and modify it to point to the second instance's WebSphere plug-in configuration file. For example:
    WebSpherePluginConfig I:/WebSphere/AppServer2/config/plugin-cfg.xml
  2. Select the port for the second instance. Select the port that is not being used by any other application. Open an editor on the httpd2.conf file and change the port 80 to 81.
  3. UNIX only: Copy the file IBM_HTTP_SERVER_ROOT_DIR/bin/apachectl and name the file IBM_HTTP_SERVER_ROOT_DIR/bin/apachectl2. Open and editor on apachectl2 and modify the variables PIDFILE and HTTPD to point to httpd2.pid and httpd2.conf as shown below (the directory /opt/IBMHTTPD is assumed to be IBM_HTTP_SERVER_ROOT_DIR:
    PIDFILE=/opt/IBMHTTPD/logs/httpd2.pid
    
    HTTPD="/opt/IBMHTTPD/bin/httpd -f /opt/IBMHTTPD/conf/httpd2.conf"
      Warning: The above steps in this section have you configure the httpd.conf file. The http.conf file contains information such as log files, root directory, and security information in addition to configuration information. If changes beyond those outlined in these steps are needed, consult the IBM HTTP Server documentation before making the changes. Also, you might want to create a corresponding IBM HTTP Server administrative server for each IBM HTTP Server instance created. An IBM HTTP Server administrative server is basically another instance of IBM HTTP Server using a different port (8008 instead of 80) and a different configuration file (admin.conf instead of httpd.conf).

  4. Start the IBM HTTP Server instances.

    UNIX

    To start the first IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR/bin. Then, run the command

    apachectl start
    To start the second IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR/bin. Then, run the command
    apachectl2 start

    Windows NT

    To start the first IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR. Then, run the command

    apache-f .\conf\httpd.conf
    To start the second IBM HTTP Server instance, open a new command window and move to the directory IBM_HTTP_SERVER_ROOT_DIR. Then, run the command
    apache-f .\conf\httpd2.conf

Configuring a single instance of a Web server with WebSphere Application Server Versions 3.5 and 4.0

The following section provides the steps required for using a single Web server with WebSphere Application Server Versions 3.5 and 4.0. When you use a single instance of a Web server with multiple instances of WebSphere, there cannot be a common Web context root present in both instances of WebSphere. If common context roots are present, then the last-configured plug-in will service the requests.

Configuring a single instance of IBM HTTP Server with WebSphere Application Server Versions 3.5 and 4.0

The following steps assume that you have installed WebSphere Application Server Version 3.5 and configured it for IBM HTTP Server 1.3.19 and that you installed Version 4.0 without selecting the plug-in choice during installation.

To confgure a single instance, add the following lines at the bottom of the httpd.conf file of IBM HTTP Server based on your WebSphere Application Server Version 4.0 installation root.

UNIX

LoadModule ibm_app_server_http_module/opt/WebSphere/AppServer40/bin/mod_ibm_app_server_http.so
AddModule mod_app_server_http.c
Alias /WSsamples "/opt/WebSphere/AppServer40/WSsamples/"
WebSpherePluginConfig /opt/WebSphere/AppServer40/configplugin-cfg.xml

Note that the above entry for LoadModule points to mod_ibm_app_server_http.so, which is Solaris-specific. For other UNIX platforms, specify the library according to the file extension in the /WebSphere/AppServer/bin directory. For AIX, WebSphere Application Server usually installs into the /usr directory.

Windows NT

LoadModule ibm_app_server_http_module e:/WebSphere/AppServer40/bin/mod_ibm_app_server_http.dll
Alias /WSsamples "e:/WebSphere/AppServer40/WSsamples/"
WebSpherePluginConfig e:\WebSphere\AppServer40\config\plugin-cfg.xml
Configuring a single instance of iPlanet Web Server with WebSphere Application Server Versions 3.5 and 4.0

The following steps assume that you have installed WebSphere Application Server Version 3.5 and configured it for iPlanet Web Server and that you installed WebSphere Application Server Version 4.0 without selecting the plug-in choice during installation.

To configure a single instance, add the following lines at the bottom of the obj.conf file of Sun ONE (iPlanet) Web Server V4.1, or at the bottom of the magnus.conf file of Sun ONE (iPlanet) Web Server V6.0, based on your WebSphere Application Server Version 4.0 installation root.

UNIX

Init fn="load-modules" funcs="as_init,as_handler,as_term" shlib="/opt/WebSphere40/AppServer/bin/libns41_http.so"
Init fn="as_init" bootstrap.properties=" /opt/WebSphere40/AppServer/config/plugin-cfg.xml"
Service fn="as_handler"

Note that the above entry for LoadModule points to libns41_http.so, which is Solaris-specific. For other UNIX platforms, specify the library according to the file extension in the /WebSphere/AppServer/bin directory. For AIX, WebSphere Application Server usually installs into the /usr directory.

Windows NT

Init fn="load-modules" funcs="as_init,as_handler,as_term" shlib="E:\WebSphere40\AppServer\bin\libns41_http.dll"
Init fn="as_init" bootstrap.properties=" E:\WebSphere40\AppServer\config\plugin-cfg.xml"
Service fn="as_handler"
Configuring a single instance of Microsoft IIS with WebSphere Application Server Versions 3.5 and 4.0

The following steps assume that you have installed WebSphere Application Server Version 3.5 and configured it for IIS and that you installed WebSphere Application Server Version 4.0 without selecting the plug-in choice during installation.

  1. Start the Internet Service Manager application.
  2. Create a new Virtual Directory for the Web site instance you want to work with WebSphere Application Server. To do this with a default installation, expand the tree on the left until you see Default Web Site. Right-click on Default Web Site' and select New -> Virtual Directory. In the wizard for adding a Virtual Directory, do the following:
    1. In the space provided for Alias to be used to Access Virtual Directory, type sePlugins.
    2. In the space provided for Enter the physical path of the directory containing the content you want to publish, browse the WebSphere Application Server bin directory. For What access permissions do you want to set for this directory, check the Allow Execute Access check box.
    3. Click Finish and a virtual directory will be added to your default Web site entitled sePlugins.
  3. Add the ISAPI filter into the IIS configuration. Right-click on the host name in the tree on the left and select Properties. In the Properties dialog, do the following:
    1. On the Internet Information Services tab, select WWW Service in the Master Properties drop-down box and click Edit.
    2. In the WWW Service Master Properties window that opens, click on the ISAPI Filters tab and then the Add button. This opens the Filter Properties window.
    3. For Filter Name, type iisWASPlugin.
    4. For Executable, click Browse and go into the WebSphere bin directory and select the iisWASPlugin_http.dll file. Then, click OK until all open windows are closed.
  4. Add the variable Plugin Config to the registry under the path HKEY_LOCAL_MACHINE -> SOFTWARE -> IBM -> WebSphere Application Server -> 4.0. Set the value for this variable to the location of the plugin-cfg.xml file.
Configuring a single instance of Domino with WebSphere Application Server Versions 3.5 and 4.0

The following steps assume that you have installed WebSphere Application Server Version 3.5 and configured it for Domino. Follow the steps to enable the HTTP Transport plug-in to work correctly with Domino Version 5.05 or 5.06. The following modifications are not made by the WebSphere installation program and must be performed manually.

  1. Start the Domino server.
  2. Access the file /webadmin.nsf using your Web browser (for example, http://hokie2ks.raleigh.ibm.com/webadmin.nsf). The browser should prompt you for a password. Give the short name for the administrator and the administrator password.
  3. Click on the Configuration link on the left side of the page.
  4. Click on the Servers link on the top-left center of the page.
  5. Double-click on the server you want to work with WebSphere Application Server.
  6. Click Edit Server on the top-left of the center window.
  7. Click Internet Protocols in the middle of the page.
  8. Under DSAPI in the middle-right of the page, add the path to the Domino plug-in. The plug-in is installed into the WebSphere Application Server bin directory.
  9. Click Save and Close on the upper-left of the center window.
  10. Define the location of the configuration file.

    UNIX

    Set the WAS_HOME environment variable to point to WebSphere Application Server Version 4.0 root directory.

    Windows

    Add the variable Plugin Config to the registry under the path HKEY_LOCAL_MACHINE -> SOFTWARE -> IBM -> WebSphere Application Server -> 4.0. Set the value for this variable to the location of the plugin-cfg.xml file.

  11. Restart the Domino server. When the server is starting, you should see something similar to the following:
    02/12/2001 03:05:09 PM  JVM: Java Virtual Machine initialized.
    WebSphere DSAPI filter loaded
    02/12/2001 03:05:10 PM  HTTP Web Server started

Configuring virtual hosts in WebSphere Application Server Version 4.0

This section describes how to configure virtual hosts for Version 4.0. For general information on virtual hosts, see the Version 4.0 InfoCenter.

Configuring a virtual host for the Advanced Edition
  1. Write down the port used by the Web server configured for this WebSphere Application Server instance. For example, the port is 81.
  2. Start the administrative server and administrative client. In the administrative console, select Virtual Hosts, select the default_host in the right-hand pane, right click on the default_host, and select Properties.
  3. Add *.81 to the Host Aliases list and apply the changes.
Configuring a virtual host for the Advanced Single Server Edition
  1. Write down the port to be added to the list of virtual hosts. For example, the port is 81.
  2. Open the \WebSphere\AppServer40\config\server-cfg.xml file and add the above port (for example, 81) under virtual hosts:
    <aliases xmi:id="HostAlias_5" hostname="*" port="81"/>

    Following is the sample section of the file after adding the above entry:

    <virtualHosts xmi:id="VirtualHost_1" name="default_host">
    <aliases xmi:id="HostAlias_1" hostname="*" port="9080"/>
    <aliases xmi:id="HostAlias_2" hostname="*" port="9443"/>
    <aliases xmi:id="HostAlias_3" hostname="*" port="80"/>
    <aliases xmi:id="HostAlias_4" hostname="*" port="443"/>
    <aliases xmi:id="HostAlias_5" hostname="*" port="81"/>
    ...

Uninstalling WebSphere Application Server

This section covers the following:

Uninstalling WebSphere Application Server Version 3.5 where there is a coexistant installation of WebSphere Application Server Version 4.0 FixPak 2 (4.0.2)
Uninstalling Version 3.5 on AIX

To uninstall Version 3.5 on AIX, do the following:

  1. Move to a command prompt for the /usr/lpp directory.
  2. Delete the package directories corresponding to the Version 3.5 installation. Remove the directories starting with IBMWebAS but not having the identifier WAS.

    WARNING: Do not remove the packages starting with IBMWEBAS.base.WAS.

  3. Run smit and remove Version 3.5.
Uninstalling Version 3.5 on Windows NT or 2000

You might encounter unexpected behavior when uninstalling an installation of WebSphere Application Server where there are co-existent installations. This section provides some additional steps that you might need to take when uninstalling Version 3.5 on Windows. It is recommended that you manually execute uninstse.exe for uninstalling Version 3.5 and uninstWAS40.exe for uninstalling WebSphere 4.0. These files are located in root directory of the installation. Note that, after installing 4.0, the Windows Add/Remove Programs Panel no longer indicates that 3.5 is installed, the only way to uninstall is using uninstse.exe command. After uninstalling 3.5, the Windows Add/Remove Programs Panel believes that Version 4.0 is no longer installed. The only way to uninstall 4.0 is to execute uninstWAS40.exe.

To uninstall Version 3.5 on Windows, go to the Websphere Application Server Version 3.5 directory \WebSphere35\AppServer and run uninstse.exe. The program will uninstall Version 3.5.

As a consequence of the uninstallation, if single instance of IBM HTTP Server is the Web server used, the WebSphere plug-in information for Version 4.0 is removed while the Version 3.5 plug-in is left in the configuration file. After uninstalling 3.5, validate that the Version 4.0 Web server configuration file is correct. Refer to " Configuring a single instance with WebSphere Application Server Versions 3.5 and 4.0" to find out the entries required in a Web server configuration file to support Version 4.0.

Uninstalling Version 3.5 or Version 4.0 on HP-UX (Defect 115384.RN)

If you have installed WebSphere Application Server Version 3.5 before installing Version 4.0 on your machine, you could receive the following error message when uninstalling Version 3.5:

java.lang.NoClassDefFoundError: installer/util/PTFAndExtensionsUninstaller

Or, if you have installed WebSphere Application Server Version 4.0 after installing Version 3.5, you could receive the following error message when uninstalling Version 4.0:

java.lang.NoZClassDefFoundError: JConfig

To work around this problem, perform one of the following steps:

  • Back up the /usr/bin/juninst file to the /usr/bin/juninst_35 file before installing WebSphere Application Server Version 3.5 and back up the /usr/bin/juninst file to the /usr/bin/juninst_40 file before installing WebSphere Application Server Version 4.0.

    You can uninstall WebSphere Application Server Version 3.5 or Version 4.0 by copying back the respective backed up files and running the respective uninstaller.

  • If you have installed WebSphere Application Server Version 3.5 or Version 4.0 on your machine, then use these techniques:
    1. Back up the /usr/bin/juninst file to the /usr/bin/juninst_40 file.
    2. Create the /usr/bin/juninst file with the following lines in it:
      /usr/WebSphere/AppServer/java/bin/java -classpath /usr/bin/uinstall.jar Uninstaller $1 $2 $3 .

      Note: This is assuming that the WebSphere Application Server Version 3.5 installation is in the /usr/WebSphere/AppServer directory.

    3. Save the file and give rx permission and run the uninstaller.
    4. Rename the /usr/bin/juninst_40 file to the /usr/bin/juninst file for WebSphere Application Server Version 4.0 uninstallation.
Uninstalling WebSphere Application Server Version 4.0 Advanced Edition or Advanced Single Server Edition if there are multiple installations

The following section discusses uninstalling when you have more than one version of WebSphere Application Server Version 4.0 installed on your system.

UNIX

When you have multiple installations of WebSphere Application Server, packages contain information of only the last installation. Use uninstall.sh in the Websphere Application Server installation root to uninstall a particular installation.

Windows NT or 2000

When you have multiple installations of WebSphere Application Server, the registry contains information of only the last installation. In case of multiple installations of the Advanced Edition, the Services panel contains reference to only the last installation. To uninstall each Websphere Application Server installation, run a command such as the following in a command window:

c:\winnt\isuninst.exe -y -f WEBSPHERE_INSTALLATION_ROOT\DeISL1.isu

For example, to uninstall an installation in C:\WebSphere40\AppServer, run the command:

c:\winnt\isuninst.exe -y -f C:\WebSphere40\AppServer40\DeISL1.isu

Note that, when an instance of WebSphere Application Server is uninstalled, the Windows registry information for WebSphere Application Server is deleted (and the entry is removed from the Services panel if an Advanced Edition is uninstalled).

Go to previous article: Interoperability with Version 3.5.x Go to next article: Developing applications

 

 
Go to previous article: Interoperability with Version 3.5.x Go to next article: Developing applications