[V5.1 and later]Adding or changing features on a federated node

This task describes a manual procedure workaround for changing features on a federated node that you are migrating .

 

Overview

When migrating a federated node, the configuration on the base node is owned by the deployment manager and cannot be changed. It is always true that unfederate a node before adding features. When you unfederate the node, you lose any of the configuration for the node that you performed with the administrative console of the deployment manager while the node was federated. After installing additional features, add the node back to the cell to cause the deployment manager to add the configuration of the base node. When migrating a node, always select the same features for the new node that are in the existing node. Adding or changing features can cause configuration problems in a federated node.

 

Overview

If you intend to install additional features, use the following procedure to avoid component regression problems. It is important that you understand that there is no way to add features to a base node without unfederating it from its cell and losing its configuration. The configuration for the base node is restored back to its original configuration, before it was federated and before you changed it with the administrative console of the deployment manager. This means that you will lose the configuration for any additional servers that you created on the base node from the deployment manager. (The additional servers will not exist any more.) You will lose any other configuration you performed from the deployment manager administrative console. Although you can use the backupConfig command to save the configuration, you cannot restore it with the restoreConfig command because the configuration you restore does not include any features that you add to the base node.

You can use the backupConfig command to save the Network Deployment configuration so that you can restore it if necessary. You can also refer to the configuration as you use the administrative console of the deployment manager to reconfigure the base node.

If the node you are migrating is part of a deployment manager cell, migrate the V5.0.x deployment manager to V5.1 first, before continuing this procedure. The deployment manager node must always be at the highest release level within the cell.

[V5.1 and later]Use the following procedure to unfederate the V5.0.x node, so that you can add or change features during the migration of the cell to V5.1.

  1. Cancel the installation of the base WebSphere Application Server, if you have already begun the installation.

    1. Click Cancel.Confirm that you intend to cancel the installation.

    2. Open a command window and change directories to the V5.0.x install_root/bin directory.

  2. Unfederate the node.Use the removeNode.sh or the removeNode.bat script. For example, use the following command to remove the node on a Linux platform: 

    ./removeNode.sh
    Wait for the successful conclusion of the command.

  3. (Optional)   Uninstall the V5.0.x node.Click the platform-specific uninstalling procedure in the topic to remove product artifacts from the machine. Verify that you are manually removing artifacts from the V5.0.x node and not another installation instance that might be on the machine. Leave files related to the embedded messaging feature if other installation instances also use embedded messaging.

  4. Install the product. Select the custom installation type. Select any features you intend to use.

  5. Verify the installation of the Application Server.Use the First Steps tool when it appears at the end of installing the product, or run the installation verification test yourself, if the First Steps tool does not appear for some reason.

  6. Verify that the deployment manager is running.If it is not, start the deployment manager with the startManager.sh or the startManager.bat script, issued from the install_root/bin directory of the deployment manager node.

  7. Add the V5.x node to the deployment manager cell.Open a command window and change directories to the V5.x install_root/bin directory of the base WebSphere Application Server product. Use the addNode.sh or the addNode.bat script to federate the V5.1 node. For example, use the following command to add the node on a Linux platform: 

    ./addNode.sh deploymgrNode 8879 -includeapps

    Use the name of the deployment manager node in place of the deploymgrNode variable in this example. Use the -includeapps parameter to copy all Sample applications to the deployment manager. The default port is SOAP port 8879, which must match the deployment manager port.

    Wait for the successful conclusion of the command.

    The addNode command starts the nodeagent process for the V5.1 node.

  8. Start the messaging service provider if the embedded messaging server feature is installed.Use the startServerer.sh or the startServer.bat script from the install_root/bin directory of the V5.1 Application Server. For example, use the following command on a Linux platform: 

    ./startServer.sh jmsserver

  9. Use the administrative console of the deployment manager to configure the base node.

 

Results

You can install additional features on a federated node by unfederating the V5.0.x node, uninstalling fix packs and interim fixes, and reinstalling the node with additional features. Adding features to a federated node always involves removing the node from the cell, which loses the cell-controlled configuration. If the deployment manager is at a later release level, such as V5.1, uninstall the V5.0.x node if add features and install a V5.1 node. Configure the V5.1 node manually with the administrative console to achieve the intended configuration.

 

What to do next

Return to Migrating configuration data to continue.

Related tasks
Migrating configuration data