Uninstall WAS ND

Uninstall WAS ND

Uninstall WAS ND to remove the core product files.
The uninstall calls the uninstaller program that is created during installation. The uninstaller program is customized for each product installation, with specific disk locations and routines for removing installed features.
The uninstaller program removes registry entries, uninstalls WAS ND, and removes all related features. The uninstaller program does not remove log files in the installation root directory.
New feature: The uninstaller for WAS is now able to detect other products which extend the appserver and have claimed a dependency on the appserver. If we have installed other products which extend the appserver, then you will be unable to uninstall the appserver before uninstalling the other products. Products which extend the appserver are feature packs and other products which rely on the appserver runtime environment
Uninstall any products which extend the appserver, such as feature packs or other products which rely on the appserver runtime environment, before you attempt to uninstall the appserver. You will be unable to uninstall the appserver product without uninstalling the other products.

(Windows) Avoid trouble: If an administrator user uninstalls an appserver that is owned by another user, then all registry entries for all appserver instances owned by the administrator will also be removed. You should uninstall any non-administrator appserver with the owning non-administrator user if possible.
This procedure uninstalls the WAS ND product.
For more information on uninstalling other components on WAS disc such as IBM HTTP Server or the Web server plug-ins, see the documentation for those products.
The time required to uninstall is dependent on the processing speed of the machine. As a rough guideline, uninstalling the core product files and one application server profile takes approximately 10 minutes when using the uninstall command.

[AIX] [HP-UX] [Linux] [Solaris]
Log on using the same user ID that was used when WAS was installed.
Issue the ls -al command at the root of the WAS installation to find the user ID that was used to install WAS ND.
(Windows) Log on as a user who belongs to the Administrators group or as the user who installed WAS ND.
Run the uninstaller program for the Web server plug-ins for WAS.
If a Web server is configured to run with the appserver, uninstall the plug-ins to remove the configuration from the Web server. See the plug-ins uninstallation documentation for more information.
Stop the node agent process with the stopNode command. Stop the node agent processes associated with the target product instance. For example, issue the following command from the $WP_PROFILE/bin directory of a federated node on a Linux machine to stop the node agent process:
./stopNode.sh

If servers are running and security is enabled, use the following command:
./stopNode.sh -user user_ID -password password

Stop the dmgr dmgr process with the stopManager command. Stop all dmgr processes that are running on the machine. For example, issue this command on a Linux machine from the $WP_PROFILE/bin directory of the dmgr profile. The example assumes we have administrative security enabled.
./stopManager.sh -user user_ID -password password

Stop each running appserver with the stopServer command. Stop all server processes in all profiles associated with the target product instance. You do not have to stop processes related to other instances of WAS on the machine. For example, issue the following command from the $WP_PROFILE/bin directory to stop the server1 process in the appserver profile:
./stopServer.sh server1

If a server is running and security is enabled, use the following command:
./stopServer.sh server1 -user user_ID -password password

If we have multiple servers, we can use the serverStatus command to find running appservers associated with the target product instance. Issue the following command from the $WP_PROFILE/bin directory to determine which servers, if any, are running:
./serverStatus.sh -all

Back up configuration files and log files to refer to them later if necessary.
Use the AdminTask command scripting interface to create a configuration archive file of an existing WAS profile, for example.
Back up the config folder and the logs folder of each profile to refer to it later if necessary. We cannot reuse profiles so there is no need to back up an entire profile.
Issue the uninstall command. Run the uninstall command:

[AIX] [HP-UX] [Linux] [Solaris]
APP_ROOT/uninstall/uninstall
(Windows) APP_ROOT\uninstall\uninstall.exe

The uninstaller wizard begins and displays the Welcome panel.
We can also issue the uninstall command with a silent parameter to use the wizard without the GUI. Issue the following command to start the uninstaller wizard in silent mode, without the graphical user interface, and to remove all profiles:

[AIX] [HP-UX] [Linux] [Solaris]
APP_ROOT/uninstall/uninstall -silent (default behavior)
[AIX] [HP-UX] [Linux] [Solaris]
APP_ROOT/uninstall/uninstall -silent -OPT removeProfilesOnUninstall="true"
(Windows) APP_ROOT\uninstall\uninstall -silent (default behavior)
(Windows) APP_ROOT\uninstall\uninstall -silent -OPT removeProfilesOnUninstall="true"

Issue the following command to start the uninstaller wizard in silent mode and to leave all profiles intact:

[AIX] [HP-UX] [Linux] [Solaris]
APP_ROOT/uninstall/uninstall -silent -OPT removeProfilesOnUninstall="false"
(Windows) APP_ROOT\uninstall\uninstall -silent -OPT removeProfilesOnUninstall="false"

If using the wizard, click Next to begin uninstalling WAS ND.
The uninstaller wizard displays a confirmation panel that lists a summary of the components that we are uninstalling.

Click Next to continue uninstalling the product.
When using the wizard, a panel allows you to choose whether or not the uninstaller deletes all profiles before it deletes the core product files. By default, all profiles will be deleted, but this option can be deselected on the panel. To change the default behavior, start the wizard with this command:
uninstall -OPT removeProfilesOnUninstall="false"

After uninstalling profiles, the uninstaller program deletes the core product files in component order.
Click Finish to close the wizard after the wizard removes WAS ND.

Remove any configuration entries in the managed node that describe a deleted dmgr.
A common topology is to install the core product files on multiple machines. One machine has the dmgr and other machines have managed nodes created from custom profiles or federated appserver profiles. If we delete a ND installation where you created an appserver profile or a custom profile and federated the node into a dmgr cell in another installation, remove the configuration from the deployment manager.
The official statement of support for a node configuration problem in the managed node is that you use the backupConfig command after the initial installation. Use the command again whenever you make significant changes to the configuration that save. With a valid backup of the configuration, we can always use the restoreConfig command to get back to a previously existing state in the configuration. You can also use the following command to remove the node when the deployment manager is not running. Issue the command from the APP_ROOT/profiles/managed_node_profile/bin directory on the machine with the managed node:

[AIX] [HP-UX] [Linux] [Solaris]
removeNode.sh -force
(Windows) removeNode.bat -force

If manually clean up the configuration on the managed node, we can attempt the following unsupported procedure:

Rename the cell_name directory for the node to the original name if the current name is not the original name.
Go to the $WP_PROFILE/config/cells/ directory. Rename the cell_name directory to the original name.
Delete the dmgr_node_name directory if it exists.
Go to the $WP_PROFILE/config/cells/original_cell_name/nodes directory to look for the dmgr_node_name directory that delete.
Edit the setupCmdLine.sh file on an operating system such as AIX or Linux, or the setupCmdLine.sh file on a Windows system and change the cell name to the original cell name.
The file is in the $WP_PROFILE/bin directory. Change the value of the WAS_CELL variable to the original cell name.

Remove any configuration entries in the deployment manager that describe a deleted managed node.
Open the admin console of the dmgr and click System administration > Nodes > node_name > Remove node. If the admin console cannot successfully remove the node, run the following command with the dmgr running:

[AIX] [HP-UX] [Linux] [Solaris]
APP_ROOT/bin/cleanupNode.sh node_name
(Windows) APP_ROOT/bin/cleanupNode.bat node_name

The official statement of support for a node configuration problem in the dmgr is that you use the backupConfig command after the initial installation. Use the command again whenever you make significant changes to the configuration that save. With a valid backup of the configuration, we can always use the restoreConfig command to get back to a previously existing state in the configuration.
If manually clean up the configuration, we can attempt the following unsupported procedure:

Within the nodes directory of the deployment manager, remove the configuration directory for the node that you deleted.
Go to the $WP_PROFILE/config/cells/cell_name/nodes directory to find the deleted_node_name file.
Within the buses directory of the deployment manager, remove the configuration directory for the node that you deleted.
Go to the $WP_PROFILE/config/cells/cell_name/buses directory to find the deleted_node_name file.
Edit the coregroup.xml file in each subdirectory of the coregroups directory of the dmgr. Look for elements of type coreGroupServers. Remove any coreGroupServers elements that have a reference to the node that you deleted.
Go to the $WP_PROFILE/config/cells/cell_name/coregroups/deleted_node_name directory to find the file.
Edit the nodegroup.xml file in each subdirectory of the nodegroups directory of the dmgr. Look for elements of type members. Remove any members elements that have a reference to the node that you deleted.
Go to the $WP_PROFILE/config/cells/cell_name /coregroups/deleted_node_name directory to find the file.

Review the log file.
Review the APP_ROOT/logs/uninstall/log.txt file. The log file records file system or other unusual errors. Look for the INSTCONFSUCCESS indicator of success in the log:
(date_time), Uninstall, com.ibm.ws.install.ni.ismp.actions. SetExitCodeAction, msg1, CWUPI0000I: EXITCODE=0 (date_time), Uninstall, com.ibm.ws.install.ni.ismp.actions. ISMPLogSuccessMessageAction, msg1, INSTCONFSUCCESS

(Windows) If uninstalling on Windows operating systems, then we might see the following error in the uninstallation log:
Failed to delete: file:/C:<input type = "hidden">/Installed/FI_INS_11/properties/version/nif/config/uninstall/lib/instcas.jar java.io.IOException: Failed to delete: file:/C:/Installed/FI_INS_11/properties/version/nif/config/uninstall/lib/instcas.jar
The instcas.jar file is locked by the operating system and cannot be deleted by the uninstaller. We can manually delete this file after the uninstallation with other files that have not yet been deleted.
If any product files remain, uninstall manually before reinstalling.
Manually uninstall WAS to remove all artifacts of WAS so that we can reinstall into the same installation root directory. If we do not plan to reinstall, you do not need to manually uninstall.
See Uninstall manually for more information.

Results

This procedure results in uninstalling the WAS ND product.

Next steps

After uninstalling WAS and cleaning the system with the manual uninstall procedure, we can reinstall.
See Task overview: Installing for an overview of installing WAS and creating a functional e-business environment.

Subtopics

installRegistryUtils
uninstall
vpd.properties file
Uninstall manually