Previous | Home | Next


Centralized Installation Manager

IBM Update Installer

To avoid issues when using the centralized installation manager, be sure you use Update Installer V7.0.0.15 or later and Installation Factory V7.0.0.15 or later. If you previously installed Update Installer on any of the target hosts in a directory location other than...

...directory, you might want to consider uninstalling Update Installer with its uninstall process because it is not used by the centralized installation manager. We do not need to uninstall the previous copy of Update Installer for centralized installation manager to work properly.

When you install fix packs or other maintenance on the target systems, the centralized installation manager installs Update Installer if the option is selected. If the version of Update Installer located in...

...directory does not meet the minimum version required by the interim fix or fix pack, the centralized installation manager can automatically install a newer version on the target. The automatic install happens only if the newer version is downloaded to the centralized installation manager repository.

We can use the centralized installation manager to install Update Installer on nodes that are federated to the deployment manager cell.


The centralized installation manager repository structure

The centralized installation manager for WAS V6.1 or V7 works with the additional repository. This repository consists of directories containing the installation images for product files, the maintenance files, and the Update Installer files. These directories are located...

...and use the following directory names and files types:


Package types

Package type Description
Product installation Includes descriptor and binary files. Loaded when the product is loaded into the repository. During the product installation, the following descriptors are included:

  • Maintenance for WAS ND V6.1 descriptor files provided by the product installation
  • Maintenance for WAS ND V7
  • Update Installer for WAS V7
  • WAS ND V7

Maintenance tool

Contains the Update Installer for applying maintenance to a WAS V6.1 or V7 environment. Before using the centralized installation manager to apply maintenance on remote systems, download the latest level of Update Installer. You must first install fix packs locally on the deployment manager system using Update Installer.

Refresh and fix packs

 Download binary files based on a specific platform. When a refresh or fix pack for IBM WAS is released, it usually comes with a fix pack for Java SDK. The centralized installation manager requires both fix packs in the repository and installs both fix packs to the selected targets.

Interim fixes

Used to apply a small update to the WAS runtime, usually provided by WebSphere support.


Access the central installation manager

We can manage WAS V6.1 or V7 from the centralized installation manager in WAS V8.5 using the following interfaces:

In the deployment manager console, the centralized installation manager jobs are also available from the Jobs menu, but they are reserved only for WAS V8 and V8.5. Additional tools for WAS V6.1 and V7 only are available by clicking...

The tools for WAS V6.1 and V7 (System administration | Centralized Installation Manager) are described in the following list: 

Available Installations Installs installation packages to the targets.
Installation Packages Displays all available descriptors and packages in the centralized
installation manager repository.

Installations in Progress
Displays the status of installations that are in progress.

Installation History
Displays the history log for installations done with the centralized
installation manager.

Installation Targets
Lists and defines installation targets for the centralized
installation manager.

To work with the centralized installation manager through the command line, we can use AdminTask by invoking it from the wsadmin script from the deployment manager host. Example 29-2 presents a Jython example of AdminTask object usage. In this example, a connection test is made with target host yourhost.com from the deployment manager to check if the connection is active.

The AdminTask object uses different methods and parameters when working with the centralized installation manager for WAS V8 or V8.5 than for V6.1 or V7.


Managing WAS V8 and V8.5

  1. Define your targets.
  2. Install Installation Managers on targets.
  3. Install the product.
  4. Create profiles.
  5. Register with job manager.
  6. Work with environment.

Not every step is required when working with the centralized installation manager. It depends on your WAS environment and if you are working with existing installations or creating a new environment.


Add new targets

To register a new target:

  1. Start the job manager or deployment manager and the targets. In the web console, click...

      Jobs | Targets | New Host

  2. Supply the form presented below with the host name of your target and its operation type. Specify the user that will be used for product installation and management, or select to use a public/private key pair to authenticate to the target. If you select a non-root user, be sure that this account allows you to install the product.

  3. We can also select the Save security information option to save the credentials together with the host. This action eliminates supplying the credentials each time you submit a job to that host.

  4. In the Installation Manager data location path(s) field, we can also supply paths on the target host to the Installation Manager installation directory. If there is no Installation Manager on that host, leave this field blank. If the Installation Manager was not installed in the standard location (during installation, a custom path was given), use the custom path in this field. This action helps the centralized installation manager to obtain which Installation Manager it must use on the target. Path information helps because the inventory job the centralized installation manager uses to detect the installed WebSphere software, might not be able to locate the Installation Manager product.

  5. Click OK to save the target.

  6. Click Jobs | Targets.

  7. Select the check boxes next to your targets, and click the Display Resources button.

  8. In the pop-up menu, select All to see all available resources

    Note that not all targets contain the version information. Targets that have versions are managed nodes registered in the job manager, such as deployment manager or administrative agent servers, and the version is their product version level. Targets that are just added as new targets do not contain this information.

    Discovered resources are displayed. If your target does not contain any WAS or Installation Manager products, the list is empty.

    We can also filter the resources to see by selecting a different Display Resources option, for example, limited only to Applications.

    The target resources include information, such as the package or package group that was used to install a given product with the Installation Manager. There are package groups for both IBM WAS ND V8.5 and IBM WAS ND V8.0 which were used as the base for WAS resources. We can also see there are profiles resources derived from the IBM WAS ND packages.


Installing Installation Manager on remote targets

With defined targets, we can install the Installation Manager on those targets.

To prepare your Installation Manager installation kit for use on your targets:

WAS V8.5 comes with Installation Manager V1.5.2. We can use this version to work with the centralized installation manager, but consider using the newest Installation Manager version available. To download a current version of IBM Installation Manager, go to the following website:

  1. Download the compressed Installation Manager copy valid for the target operating system to your local machine.

  2. Click Jobs | Installation Manager installation kits.

  3. Optionally, to change the default local directory where the job manager or deployment manager keeps binaries, enter the path under Installation Manager installation kits location. By default, it is the PROFILE_HOME/IMKits directory, where PROFILE_HOME is your job manager or deployment manager profile directory.

  4. Click Add, and point to the Installation Manager compressed file on your local machine.

    The Installation Manager installation kit is transferred to the job manager or deployment manager and registered in its repository.

    If we do not want to transfer the Installation Manager installation kit using your local computer and HTTP transfer, we can copy this file directly to the Installation Manager installation kit location directory on the deployment manager or job manager.

    To delete the Installation Manager installation kit, select it from the list and click the Delete button. The compressed file with the Installation Manager will be deleted from the server.

    We can install additional versions of Installation Manager for other platforms of your choice that are supported by the Installation Manager. Each of them is kept in the Installation Manager installation kit directory.

    The centralized installation manager repository location is configured in the CIMJMMetadata.xml file. This file is located in the job manager or deployment manager PROFILE_HOME/properties/cimjm directory.

    To proceed with the installation of Installation Manager on remote targets:

    1. Click Jobs | Submit from the Jobs navigation section.

    2. From the drop-down menu, choose the Install IBM Installation Manager job, and click Next.

    3. Choose the job targets:

      1. Select a group of targets from the list, or select Target names.

      2. If you selected Target names, specify a target name, and click Add, or click Find, and specify the chosen targets in the Find targets window.

      3. If user authentication is required, specify a user name, password, or any other authentication values as needed

      4. Click Next.

    4. Because you specified the Installation Manager installation kit in the previous step, we can leave the The path and file name of Installation Manager kit field empty is also useful because when you install the Installation Manager on a group of targets (consisting of different platforms), the Installation Manager automatically uses an appropriate Installation Manager installation kit for each target.The automatic function does require the Installation Manager has a valid copy for the given platform, so providing a static directory only works for single targets.

      We can also leave the Installation Manager agent data location and Installation Manager installation directory empty to use the default Installation Manager install directory.

      To proceed to the next step, accept the terms in the license agreements by selecting I accept the terms in the license agreements. To review the license, extract the Installation Manager installation kit and from the extraction point location run the install.exe command for Windows systems or install command for AIX, Linux or Solaris operating systems. We can also run installc -c to review the license in text mode.

    5. To schedule this job to run at a specified time, we can use this step to define specific dates and times. We can also specify the job to run on a given basis, such as daily or weekly. To just install the product, leave the form with its defaults with Availability interval selected to Run once, and click Next.

    6. Review the summary and then click Finish to submit the job. After you submit the job, a unique identifier is allocated to it to track the job status. The administrator can always return to the Jobs | Status view to track the job progress

      If the job is successful or it fails, additional messages and files might be shown. If files are present, we can click them to see the full path to the file on the target. This path can be used to locate the file and obtain it using a Collect file job. In case of an error, investigate the error message or file, correct the condition that caused the error, and submit the job again.


    Updating the Installation Manager on remote targets

    To update the Installation Manager, select the Update IBM Installation Manager job.


    Uninstalling the Installation Manager on remote targets

    Select Uninstall IBM Installation Manager to proceed with this procedure. Note that to uninstall the Installation Manager, all products installed using it must be uninstalled first.


Installing a Secure Shell (SSH) public key

Installing a secure shell public key is not a required step, but can be done using the job manager or the deployment manager console.

To install a secure shell public key:

  1. Click Jobs | Submit from the navigation tree of the dmgr console.

  2. Select the Install SSH Public Key job and click Next.

  3. Select the job targets, and supply the administrative user name and password. Click Next.

  4. On the Specify the job parameters window, specify the location of the public key file to install on the selected target, and click Next.

  5. Schedule the job, and click Next.

  6. Review the summary, and click Finish to submit the job.

    If the job is successful, we can use the public/private key pair method to authenticate from the job manager or network manager host to the target host.


Installing WAS binaries on remote hosts

With the targets defined and the Installation Manager installed on the targets to install the WAS binaries on remote hosts:

  1. Consider running an inventory job to refresh the job manager or deployment manager targets repository:

    1. In the dmgr console, click Job | Submit.

    2. In the Job type menu list, select the Inventory job, and click Next.

    3. Specify the target names and target authentication, and click Next.

    4. Schedule and submit the job.

  2. Use the Manage offerings job to install the product:

    1. In the dmgr console, click Job | Submit.

    2. In the Job type menu list, select the Manage offerings job, and click Next.

    3. Specify the target names and target authentication, and click Next.

    4. Required parameter: Response file path name

      The full path name to the Installation Manager response file. The path must point to a file located on job manager or deployment manager machine.

      We can obtain the Installation Manager response file using the IBMIM.exe command for Windows or IBMIM command for UNIX, executed from installation_manager_home/eclipse directory:

        IBMIM -record <path_to_your_file>.xml -skipInstall <path_to_empty_directory>

      shows a sample response file that can be used for WAS V8.5 product installation. Note that edit the highlighted properties to tell Installation Manager which repository to use and where to install the product on the target. There are many more ways to edit this file to instruct Installation Manager.

      Response file used to install WAS V8.5 product 

      <?xml version="1.0" encoding="UTF-8"?>
<!--The "acceptLicense" attribute has been deprecated. Use "-acceptLicense"
command line option to accept license agreements.-->
<agent-input acceptLicense='true'>
<server>
<repository location='<MY REPOSITORY LOCATION>'/>
<repository
location='https://www.ibm.com/software/repositorymanager/service/com.ibm.web
sphere.ND.v85/8.5.0.0'/>
</server>
<profile id='IBM WAS V8.5'
installLocation='<LOCATION TO INSTALL PRODUCT ON TARGET MACHINE>'>
<data key='eclipseLocation' value='<LOCATION TO INSTALL PRODUCT ON TARGET
MACHINE>'/>
<data key='user.import.profile' value='false'/>


<data key='cic.selector.os' value='win32'/>
<data key='cic.selector.ws' value='win32'/>
<data key='cic.selector.arch' value='x86'/>
<data key='cic.selector.nl' value='en'/>
</profile>
<install modify='false'>
<offering id='8.5.0.0-WS-WAS-IFPM62795' version='8.5.0.20120503_1150'
profile='IBM WAS V8.5' features='-'/>
<offering id='8.5.0.0-WS-WAS-IFPM63690' version='8.5.0.20120611_1318'
profile='IBM WAS V8.5' features='-'/>
<offering id='8.5.0.0-WS-WAS-IFPM63827' version='8.5.0.20120503_1507'
profile='IBM WAS V8.5' features='-'/>
<offering id='8.5.0.0-WS-WASProd-IFPM64186' version='8.5.0.20120611_1543'
profile='IBM WAS V8.5' features='-'/>
<offering id='8.5.0.0-WS-WASProd-MultiOS-IFPM63479'
version='8.5.0.20120613_2056' profile='IBM WAS V8.5' features='-'/>
<offering id='com.ibm.websphere.ND.v85' version='8.5.0.20120501_1108' profile='IBM WAS V8.5'
features='core.feature,ejbdeploy,thinclient,embeddablecontainer,com.ibm.sdk.
6_64bit,samples,liberty' installFixes='none'/>
</install>
<preference name='com.ibm.cic.common.core.preferences.eclipseCache'
value='<LOCATION TO IBM IMShared FOLDER ON TARGET MACHINE>'/>
<preference name='com.ibm.cic.common.core.preferences.connectTimeout'
value='30'/>
<preference name='com.ibm.cic.common.core.preferences.readTimeout'
value='45'/>
<preference
name='com.ibm.cic.common.core.preferences.downloadAutoRetryCount'
value='0'/>
<preference name='offering.service.repositories.areUsed' value='true'/>
<preference name='com.ibm.cic.common.core.preferences.ssl.nonsecureMode'
value='false'/>
<preference
name='com.ibm.cic.common.core.preferences.http.disablePreemptiveAuthenticati
on' value='false'/>
<preference name='http.ntlm.auth.kind' value='NTLM'/>
<preference name='http.ntlm.auth.enableIntegrated.win32' value='true'/>
<preference
name='com.ibm.cic.common.core.preferences.preserveDownloadedArtifacts'
value='true'/>
<preference name='com.ibm.cic.common.core.preferences.keepFetchedFiles'
value='false'/>
<preference name='PassportAdvantageIsEnabled' value='false'/>
<preference name='com.ibm.cic.common.core.preferences.searchForUpdates'
value='true'/>
<preference name='com.ibm.cic.agent.ui.displayInternalVersion'
value='true'/>
<preference name='com.ibm.cic.common.sharedUI.showErrorLog' value='true'/>
<preference name='com.ibm.cic.common.sharedUI.showWarningLog' value='true'/>
<preference name='com.ibm.cic.common.sharedUI.showNoteLog' value='true'/>
</agent-input>

    5. Specify optional parameters: IBM Installation Manager Path Path to install Installation Manager on the remote machine. If this parameter is blank, then Installation Manager is considered to be installed in the default location. IBM Installation Manager agent data location Specify an IBM Installation Manager data location not the default location for the manageOfferings job. IBM Installation Manager key ring file If the package repository requires a key ring file for authentication, specify the full path name of the key ring file on the job manager machine. Key ring file password If the key ring file is password protected, specify the key ring password.

      To avoid trouble, if you installed the Installation Manager using defaults, use defaults during this task. Do not use a non-default data location unless you are familiar with IBM Installation Manager.

    6. Select I accept the terms in the license agreements, and click Next.

    7. Schedule the job, or click Next to proceed with the next step.

    8. Review the summary of the job, and click Finish to submit it.

  3. At this point, your job is submitted and has a unique identifier. We can track its status by clicking...


Create a WAS profile on a remote target

In this example, two profiles are created: a deployment manager profile and a default profile, which is federated into the deployment manager cell.

To create profiles with centralized installation manager, you need response files. Consider preparing our own response files on your local, experimental environment. Two response files that we use in this section.

Response file for a default server profile federated to the deployment manager

To use the centralized installation manager to create the deployment manager profile and a default profile:

  1. Click Jobs | Submit.

  2. From the drop-down menu, select Manage profiles.

  3. Select your targets and authentication method, and click Next.

  4. Specify the installation home directory of WAS product. Specify the path where it was defined during the base product installation.

    Path to the response file that will be used to create the profile. In this case, copy the response file to the job manager or deployment manager machine, and type the path to that file

  5. Schedule the job, or submit it to run once, and click Next.

  6. Review the job details, and submit it by clicking Finish, or change its parameters by clicking Previous.

    If the job completes successfully, proceed with creating the next profile. If any errors occur during installation, inspect them, correct them, and run the manage profiles job again.

    To create a second profile, complete steps but in step 4, enter the path to the response file shown earlier.

    When the second job completes successfully, the profiles are ready, but not started. To use them, the administrator has to start the deployment manager and the node agent of the server profile. We can either log into the targets and invoke the ./startManager and ./startNode commands or use the job manager or deployment manager dmgr console.

    To use the job manager or deployment manager administrative console to start the deployment manager and node agent:

    1. Click Jobs | Submit.

    2. Select Run command job on remote host from the drop-down menu.

    3. Add your target on which you installed the profiles.

    4. Specify the user name that you used to install the product, supply the password or use the public/private key authentication method, and click Next.

    5. Specify the script name to run in the Command or script field, and run startManager.sh to start the deployment manager or startNode.sh to start the node agent.

      In the field under Working directory, specify the path to your command. To start the deployment manager server, use:

        PROFILE/MyDmgr/bin

      We can use our own directory where you installed the deployment manager profiles. If to start the server profile, use:

        PROFILE/MyServer/bin

      Alternately, we can use our own directory where you installed the federated server profile.

    6. Schedule your job, and click Next.

    7. Review the job details, and submit the job by clicking OK.


Registering and unregistering the profile with the Job Manager

To fully control target WAS profiles, we have to register the newly created deployment manager.

Apart from deployment manager servers, we can also register administrative agent type servers to manage even more complex WAS environments.

To register deployment manager:

  1. In the target deployment manager dmgr console, click System administration | Deployment manager.

  2. Click the Job managers link under the Additional Properties section.

  3. Click Register with Job Manager.

  4. Supply the managed node name for the job manager profile.

    Specify the job manager host name, secure http port, and the alias name to be used in the job manager. Specify the user name and password of the job manager user.

    To view the job managers from the deployment manager console:

    1. Click...

    2. Click Job managers under the Additional Properties section.

      To unregister your deployment manager from the Job Manager:

      1. Click...

      2. Click the Job managers under the Additional Properties section.

      3. Click Unregister from a Job Manager.

      4. Supply the form with all of the information about your job manager profile. WAS uses this information to unregister your deployment manager. Note that although only the Managed node name is the required field, we have to specify all information about your job manager to unregister it.

        If some information is missing or is not correct, an error message similar to the one


    Working with remote targets

    In this section, the job manager is used to deploy applications to the target. We assume that you followed the previous steps and the environment is prepared to deploy applications.

    We can download the sample applications from the WAS V8.5 samples website: http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.samples.doc /ae/welcome_samples.html

    A JavaServer Faces 2.0 JSFSample example is used in this chapter.

    To install a new application on a remote target:

    1. Copy the application ear file (JSFSample.ear) into the job manager directory...

        PROFILE_HOME/config/temp/JobManager

    2. Log on to the job manager console.

    3. Click Jobs | Submit.

    4. From the Job type box, select the Distribute file job, and click Next.

    5. Select your target and the authentication method to use against the operating system, and click Next.

    6. Specify the source as JSFSample.ear. It is a relative path to the job manager directory from step 1.

      Specify the destination where the file will be uploaded. In this case, use the path...

        /opt/WAS/AppServer/profiles/Dmgr8_01/downloadedContent

      Your user must have access to the directory where you upload the application.

    7. Schedule the job, and click Next.

    8. Review the job details, and click Finish to submit it.

      When the job finishes successfully, the file is transferred to the directory of your choice on the target.

      To install it remotely on the WebSphere Application Server target:

      1. Click Jobs | Submit.

      2. From the Job type box, select the Install application job, and click Next.

      3. Select your target and the authentication method to use against the deployment manager.

      4. Specify the job parameters. Enter the application file name. For example, if you copied the application to the dmgr_PROFILE_HOME/downloadedContent directory on a remote deployment manager, we can simply enter the application name (JSFSample.ear) in the Application location.

        To specify which server the application is deployed to, click the Find button next to the Server name. Select the desired server instance, and click OK.

        After we specify the server instance, the Node name field is automatically set with the correct server node name. Your window at this point looks similar to Figure 29-21.

        If your topology uses application clusters, specify the cluster name on which the application will be deployed in the Cluster name field. In this case, we run it only on a single server, so we can omit this field, and click Next.

      5. Schedule the job, and click Next.

      6. Review the job information, and click Finish to submit it.

      When the job finishes successfully, the application is deployed on the remote target, but it is stopped.

      If the target server is stopped, start it.

      To start the server using job manager:

      1. Click Jobs | Submit.

      2. From the Job type box, select the Start server job, and click Next.

      3. Select the target and authentication method to use against the deployment manager, and click Next.

      4. Specify the Server name to start, and use the Find button to select it from the list. After you select the target server, the Node name field is automatically set with the correct value. Click Next.

      5. Schedule the job, and click Next.

      6. Review the job information, and click Finish to submit it.

      If the target server instance is available, we can start the JSFSample application using the Start application job:

      1. Click Jobs | Submit.

      2. From the Job type box, select the Start application job, and click Next.

      3. Select the target and authentication method to use against the deployment manager, and click Next.

      4. Specify the application name to start. Note that to use this job the application must already be deployed on the server. Use the Find button to select it, and click Next.

      5. Schedule the job, and click Next.

      6. Review the job information, and click Finish to submit it.

        When the job finishes successfully, we can invoke the application on the remote target. If you used the JSFSample application, use the following URL to access the application:

          http://<your target host>:<your port>/SampleTemplating/home.faces


    Installing maintenance to remote targets

    To install maintenance packages on remote targets, use the Manage offerings job with the appropriate response file. This procedure is the same for WAS V8 and V8.5. Before installation, verify all Java processes on the target runtime are stopped.

    1. From the list, select the manageOfferings job to install maintenance:

      1. In the dmgr console, click Job | Submit.

      2. In the Job type menu list, select the Manage offerings job, and click Next.

      3. Specify the target names and target authentication, and click Next.

      4. Specify this required parameter:

        Response file path name The full path name to the Installation Manager response file in which we specify the maintenance to install, repository, and target WAS runtime. The path must point to a file located on the job manager or the deployment manager machine. We can prepare your response file using Installation Manager parameters.

      5. Specify these optional parameters:

        IBM Installation Manager Path Path to install Installation Manager on the remote machine. If this parameter is blank, Installation Manager is considered to be installed in the default location.
        IBM Installation Manager agent data location IBM Installation Manager data location not the default location for the manageOfferings job.
        IBM Installation Manager key ring file If the package repository requires a key ring file for authentication, specify the full path name of the key ring file on the job manager machine.
        Key ring file password If the key ring file is password protected, specify the key ring password, and confirm it.

      6. Select I accept the terms in the license agreements, and click Next.

      7. Schedule the job, or click Next to proceed with the next step.

      8. Review the summary of the job, and click Finish to submit it.

      At this point, the job is submitted and has a unique identifier. We can track its status under the Jobs | Status.

      After a successful installation, you will see a message in the stdOut.txt log similar to the following example:

      Updated to com.ibm.websphere.ND.v80_8.0.1.20110620_2048 in the directory...

        /opt/WAS/AppServer

      The change is also reflected in the console of the target. Log on to the updated server to see the new maintenance level. The current version is displayed on the welcome window.

      See:


Use the centralized installation manager with a command line

Every centralized installation manager operation that can be run from the job manager or deployment manager can also be run from the command-line interface. This interface allows you to create an even more automated WAS environment.

The following list of jobs can be used to work with the environment:


Managing WAS V6.1 and V7 with the centralized installation manager

To use the centralized installation manager in WAS V8.5 with previous v6.1 or v7 products, the following additional steps must be completed:

  1. Install the IBM Installation Factory.

  2. Configure the centralized installation manager repository for WAS V6.1 and V7 products.

  3. Install additional product packages into the repository.

  4. Create additional targets.

  5. Work with the environment.

    The centralized installation manager for WAS V6.1 and V7 has limited functionality compared to V8 or V8.5.


Installing the IBM Installation Factory

Use Installation Factory V7.0.0.15 or newer versions. We can download the current version from the IBM Installation Factory for WAS at the following website: http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg24020213 After it is downloaded, extract the binaries to any directory for which we have the appropriate permissions. We can also install Installation Factory on the system using the code from the product media. Copy the Installation Factory on to your operating system. Use the setupif command provided on the Installation Factory disc, or as part of the package download:

  • UNIX: Run the setupif.sh command or setupif.sh target_location.

  • Windows: Run the setupif.bat command or setupif.bat target_location.

    This command copies the Installation Factory to user_home/InstallationFactory by default.

    We can specify the target location using the target location parameter.


    Create the centralized installation manager repository

    Before we can populate the centralized installation repository, ensure that we have write access to the directories you plan to use:

    1. Download the product images, and expand the file (.tar or .zip) to a temporary directory, or ensure access to the product CD.

    2. Use the ifcli.bat command for Windows or ifcli.sh for UNIX to populate the repository.The default folder for the centralized installation manager repository is...

        WAS_HOME/cimrepos

      Set up the centralized installation manager repository in the...

        /opt/IBM/CIMRepo

      Command for creating the central installation manager repository for WAS V6.1 and V7... 

      cd INSTALL_ROOT/bin/
./ifcli.sh -wasPath /opt/WAS/AppServer85 
           -repositoryPath /opt/IBM/CIMRepo 
           -installationPackagePath /tmp/installs/WAS70ND

      The centralized installation manager is configured for the WAS product installed under /opt/WAS/AppServer location. It is also populated with the WAS V7 binaries that are downloaded to the /tmp/installs/WAS70ND directory.

      We can also use GUI-based tools to create repositories.

      Listing a successful repository creation 

      **********************************************************************************
The ifcli command started at Jun 26, 2012 5:44:57 PM with options: 
    '-wasPath /opt/WAS/AppServer85 -repositoryPath /opt/IBM/CIMRepo -installationPackagePath /tmp/installs/WAS70ND'
**********************************************************************************
The specified installation was successfully configured to associate with the repository. 
Centralized Installation Manager must be restarted in order to use the repository.
Adding installation package to the repository...
The installation package was successfully added to the repository.
**********************************************************************************
The ifcli command ended at Jun 26, 2012 5:47:31 PM with return code: INSTCONFSUCCESS.
**********************************************************************************

      We can review the structure of the repository in the /opt/IBM/CIMRepo directory.


    Add packages when deployment manager is connected to the Internet

    To download the latest version of the Update Installer to your centralized installation manager repository. Update Installer is required to apply maintenance on the target systems.

    1. Click...

        System Administration | Centralized Installation Manager | Installation Packages | Update Installer for WAS

    2. Select one or more operating systems that you will use and then click Download.

    3. Review the summary, and select Download to start downloading the packages.

    4. On the Installation packages window, after the download starts, we can monitor the status by clicking Refresh. If you receive errors, refer to the following file for more detailed information:

        DMGR_PROFILE/logs/dmgr/systemOut.log


    Downloading descriptors

    The centralized installation manager also supports the installation of ND V6.1 and V7 Fix Packs on remote nodes that are within the network deployment cell. This configuration is known as a mixed-version cell, where the deployment manager node is at v7 or higher and the other nodes within the cell are either at the same level as the deployment manager node or at the v6.1 level. The centralized installation manager does not support maintenance levels prior to v6.1.

    Download additional installation packages and maintenance files to your centralized installation manager repository by clicking...

      System Administration | Centralized Installation Manager | Installation Packages | add package

    Select one or more descriptor files), and click Download to proceed.

    We can monitor the progress of the download by selecting Download Status.


    Downloading fix pack binaries

    After the descriptor for the required ND V6.1 Fix Pack has been downloaded using the method described here, download the *.pak files for that fix pack to the centralized installation manager repository.

    The centralized installation manager uses the Update Installer for WAS V7 to install and uninstall WAS ND V6.1 and V7 Fix Packs.

    To download the binary files for a refresh pack, fix pack, or maintenance tool package type, which includes the Update Installer:

    1. Click...

        System Administration | Centralized Installation Manager | Installation Packages | package name

    2. Select one or more platforms and then select Download to proceed.

    3. When all the required files are downloaded, the Download Status column displays Complete.

      If one or more files are missing, the Download Status column displays an Incomplete status. In this case, try to download again. If your status is Incomplete, check for error messages in...

        DMGR_PROFILE/logs/dmgr/SystemOut.log

      ...where DMGR_PROFILE is the profile location of the deployment manager. Downloading interim fixes

    To download interim fixes:

    1. To download a specific APAR, click System Administration | Centralized Installation Manager | Installation Packages. Click the name of the package file, and a new window opens.

    2. Select Add files to go to the Download Files window.

    3. Enter the APAR number and then select Search

    4. Select the APAR from the list provided and then select Download, verify the information, and click Download to proceed.


    Add packages when deployment manager is not connected to the

    Internet

    If your deployment manager system does not have Internet access, manually download and transfer files to the centralized installation manager repository.

    Before we can copy the downloaded files into the repository, set up the directory structure.

    To obtain the address of the FTP site to manually download the required file, click

      Administration console | System Administration | Centralized Installation manager | Installation Packages | Add Packages

    The FTP URL format is:

      ftp://public.dhe.ibm.com/software/websphere/appserv/support/cim/cim70_yyyymmdd

    If the deployment manager does not have Internet access, an error message is displayed the FTP URL is not known. Write down the FTP URLs because they are used on the system that has Internet access.

    We can find the address of the FTP site for the following items:

  • Descriptor files: Click...

      System Administrator | Centralized Installation manager | Installation Packages | Add packages

    To determine the location of the FTP server, expand the Download Options, which gives you the FTP URL location used by the centralized installation manager for downloading the Descriptor files.

  • Update Installer files: Click...

      System Administrator | Centralized Installation manager | Installation Packages, and click Update Installer for WAS

    Expand the Download Options. This gives you the FTP URL location used by the centralized installation manager for downloading the Update Installer for the various operating systems.

  • Fix packs: Copy descriptor files to the descriptor directory of your centralized installation manager, click...

      System Administrator | Centralized Installation manager | Installation Packages | fix pack | Download Options

    This action gives you the FTP URL location used by the centralized installation manager for downloading cumulative fix packs and individual fixes.

    Choose the FTP URL for the type of fix you are downloading.

  • Interim Fixes: Click...

      System Administrator | Centralized Installation manager | Installation Packages | [Maintenance for WAS ND 6.1 | Maintenance for WAS ND 7.0] | Add Files

    The FTP URL is available under Download Options section.

    With the FTP URLs, we can go to any system with Internet access and download the required files. After the files are downloaded, copy them to the correct directory structure in the centralized installation manager repository. Another option for obtaining the latest Update Installer, fix packs, and interim fixes is to set up an FTP gateway on a system that has Internet access. Refer to the information center at the following website for the steps to set up an FTP Gateway: http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.installatio n.nd.doc/ae/tins_cim_files_download_no_internet.html


    Add and remove additional installation targets

    To install products or maintenance on remote hosts, specify the targets:

    1. Click...

        System Administration | Centralized Installation Manager | Installation Targets | Add Installation Target

    2. Enter the host name, user name, password and Platform type of the system to add. Consider using a host name rather than an IP address because this name is used in the configuration of the node.

    3. Click OK. The new target system is added to the list of target systems...

    4. To remove a target, click...

        System Administration | Centralized Installation Manager | Installation Targets | target | Remove Installation Target


    Installing a Secure Shell public key

    To install a Secure Shell (SSH) public key on specific installation targets:

    1. Click...

      Select one or more targets from the table, and click Install SSH Public Key.

    2. On the next window, enter the operating system, user name and password and then click Next.

    3. You are prompted for the specific SSH public key location

      Enter the file location, and click Next to continue.

    4. Verify the summary and then click Finish.

      You also see a key icon in the target list. This icon means that your deployment manager host can authenticate with that target using the public/private key pair method.


    Installing packages to the target systems

    The centralized installation manager relies heavily on remote node information maintained locally on the deployment manager node. This remote node information (namely the node-metadata.properties file) for each node is refreshed every time the node agent on the remote node starts and provides the centralized installation manager with up-to-date information regarding the WebSphere products and versions that are installed on the target nodes.

    One example of how the node-metadata.properties file is used by the centralized installation manager is in the filtering of nodes that might be selected for the installation of an interim fix.

    The node-metadata.properties file is also used by the centralized installation manager to determine only the applicable nodes during a maintenance installation. This process allows the cell administrator to see which nodes are potential candidates for this update and then initiate the installation of the interim fix on one or all the candidate nodes. Because of the availability of the node-metadata.properties file on the deployment manager node, we can use the centralized installation manager to perform this filtering without accessing the target nodes. The node agent process that runs on each node ensures the node-metadata.properties files of the nodes on the deployment manager are kept up to date.

    For this reason, if you apply maintenance to the node or install new WebSphere products (such as the Feature Pack for Web Services) outside of the centralized installation manager on the remote node, restart the node agent process after the installation to get the deployment manager copy of the node-metadata.properties file of the node up to date.


    Installing a software package

    To install a software package:

    1. Click...

        System Administration | Centralized Installation Manager | Available Installations

    2. Select the package type Product Install, and select the installation package WAS ND - 7.0. When selecting a product install, you are required to select Optional features. Choose from the following features:

      • Install the sample applications for learning and demonstration environments.

      • Install the non-English language files for using the dmgr console from machines with non-English locales. If we do not select this option, only the English language pack is installed.

      • Install the non-English language files that support the application server runtime environment, such as wsadmin and logging. If we do not select this option, only the English language pack is installed.

    3. Click Show Installation Targets to list defined targets, and select the targets on which to install the product.

    4. Click Install | Accept License Agreement | Next.

    5. Select Authentication method to access the target. Choose a user name and password or the use of Secure Shell (SSH) Public/Private key authentication.

    6. In the next window, provide the installation directory and a working (temporary) directory and then click Next.

      The next two windows give you the option to disable prerequisite checking and to accept limitations to allow installing as a non-root user.

    7. By default, the centralized installation manager uses 64-bit installation binaries on 64-bit operating systems. The next window allows you to override this setting. Click Next.

    8. Review the Summary window, and select Finish to start the installation.

    9. To watch the progress of the installation, click System Administrator | Centralized Installation Manager | Installation Progress.

    10. When the installation is complete, click System Administrator | Centralized Installation Manager | Installation History for details about the installation.


    Installing maintenance to a target system

    The centralized installation manager cannot be used to install maintenance to the deployment manager.

    All node agents in the cell must be stopped on the target systems. If the node agents or any other server processes are running, it is up to the administrator to verify they all are stopped.

    There is no need to explicitly install the Update Installer on the targets first before initiating the installation of the fix packs or interim fixes because the centralized installation manager automatically installs the latest version of the Update Installer on the target if needed.

    After the centralized installation manager successfully completes the installation process on a remote node, it then deletes the installation image files located in the temporary location specified during the installation process. If the installation is unsuccessful, the files remain in the temporary location for you to use to determine what caused the installation error. However, we can safely delete these files.

    Fix packs that include updates to the SDK might overwrite unrestricted policy files. Back up unrestricted policy files before you apply a fix pack and reapply these files after the fix pack is applied.

    Using the centralized installation manager to install refresh or fix packs

    To use the centralized installation manager to install refresh or fix packs:

    1. Click...

        System Administrator | Centralized Installation Manager | Available Installations

      For the package type, select Refresh pack, fix pack, or maintenance tool.

    2. From the drop-down list of available installation packages, choose the installation package containing the refresh pack or fix pack to install on your remote systems.

      These are the packages that you previously downloaded to your centralized installation manager repository.

    3. Click Show installation targets to get a list of target systems available for install. Select your target systems. To continue, click Install.

    4. The next window shows the license agreement. Review the agreement, select Agree and then click Next.

    5. On the next window, specify the authentication method to use, the user name, and password or Secure Shell (SSH). Choose your method.

    6. The next window that opens depends on the type of authentication you choose. You see a window prompting you to enter a user name and password or a window prompting you for the location of the SSH private key file and keystore password.

    7. Verify the installation and the working location of the installation targets. The installation location is the remote location of each installation target in which the package is to be installed. The working location specifies the directory on the remote target where the files are sent before the package is installed in the specified location. Make sure that we have enough disk space in both the installation location and the working location. Click Next to continue.

    8. A summary window opens. Review the information entered, then to start the installation, select Finish.

      Any interim fixes that you previously installed on the remote targets are uninstalled by the Update Installer prior to installing the refresh pack or fix pack. If the refresh pack or fix pack does not include the official fixes that were included in the removed interim fixes, reinstall the interim fixes after you install the refresh pack or fix pack.

    9. We can click System Administrator | Centralized Installation Manager | Installation Progress to check the progress of the installation. When complete, click System Administrator | Centralized Installation Manager | Installation History for details about the installation.


    Using the centralized installation manager to install interim fixes

    To install an interim fix on remote target...

    1. Click...

        System Administrator | Centralized Installation Manager | Available Installations | package type | Interim fix | Select an Installation package drop-down menu | [Maintenance for WAS ND 7.0 | 6.1]

      If the interim fixes were previously downloaded to the centralized installation manager repository, they are displayed under Select one or more maintenance packs. Select the maintenance pack to install on your target systems.

    2. Click Show Installation Targets. A list of your target systems are displayed. From this list, select your targets, and click Install. Note that we can select only targets that are applicable for that interim fix.

    3. Click View License Agreement to read the agreement and accept the terms. Click Next to continue.

    4. The next window is where you choose the authentication method to use, user name, and password or Secure Shell (SSH). Choose your method, and click Next to proceed.

    5. The next window that opens depends on the type of authentication you choose. A window that prompts you to enter a user name and password opens or a window that prompts you for the location of the SSH private key file and keystore password opens.

    6. Verify the installation and the working location of the installation targets. The installation location is the remote location of each installation target in which the package is to be installed. The working location specifies the directory on the remote target where the files are sent before the package is installed in the specified location. Make sure we have enough disk space in both the installation location and the working location. Click Next to continue.

    7. Verify the Summary window, and select Finish to start the installation request.

      To check the status of your request, select Installations in Progress on the dmgr console. After the installation is completed, click Installation history in the dmgr console to review the log files for each of the installation requests that you submit. From the Installation History window, the administrator can click View Details to open a window with additional details about the results. Links to logs on the remote targets are included. Those logs can be moved, replaced, or deleted by other users or administrator if they are not viewed immediately after an installation operation.

      If you attempt to install an interim fix without having a copy of the IBM Update Installer for WebSphere Software in your centralized installation manager repository, you receive the following error message:

      The installation binary files required for the install_package_name or its dependent package Update Installer for WAS for workstation_platform do not exist.


    Uninstalling packages

    1. Click...

        System Administrator | Centralized Installation Manager | Available Installations

      On this window, select the package type to uninstall. Select the installation package to be uninstalled. Click Show Uninstallation Targets | Target system and then click Uninstall.

    2. You are prompted for an authentication method. Enter either a user name and password or the location of the SSH key file. Next, verify the Installation target directory. Review the summary page, then click Finish to proceed with the uninstallation.

    Refer to the installation history for the results of the uninstallation.


    The centralized installation manager AdminTask commands

    We can use the centralized installation manager AdminTask commands with Jacl or Jython scripting language. These commands and parameters can be used to install, uninstall, and manage various software packages and maintenance files in the centralized installation manager environment. Here is a list of AdminTask commands available for WAS V6.1 and V7 products: 

    installWASExtension Installs a server extension package.
installSoftware Installs a specified software package.
installWithResponseFile Installs a specified software package using parameters from a response file.
installMaintenance Installs maintenance.
listPackagesForInstall Lists packages from the centralized installation repository.
listFeaturesForInstall Lists the features of software packages from the centralized installation repository.
showPackageInfo Displays information about a specific software package.
showLicenseAgreement Displays the license agreement for a specified installation package.  
getManagedNodesOnHostByInstallLoc Lists the names of managed nodes defined in the deployment manager cell.  
listManagedNodesOnHost Lists the names of the managed nodes located on targets in the deployment manager cell.
testConnectionToHost Verifies if a connection from the deployment manager to a remote host can be established using a user name and password.
testConnectionToHostUsingSSHKey Verifies if a connection from the deployment manager to a remote host can be established using an SSH private key.
installSSHPublicKeyOnHost Installs an SSH public key on the remote target.
listKeyInstallationRecords Lists the centralized installation manager SSH public key records of target host names.
updateKeyInstallationRecords Updates the centralized installation manager SSH public key records.
listPendingRequests Lists submitted installation or uninstallation requests that are not started yet.
listInProgressRequests Lists submitted installation or uninstallation requests that are in progress.
listRequestsForTarget Lists submitted installation or uninstallation requests for given target.
showLatestInstallStatus Displays the status of the most recently submitted installation request.
showLatestUninstallStatus Displays the status of the most recently submitted uninstallation request.
uninstallSoftware Uninstalls the software package from the target.
uninstallMaintenance Uninstalls the maintenance package from the target.


    Managing the Liberty profile with the centralized installation manager

    The new Liberty profile is a fast to start, dynamic application server runtime environment. OSGi services are used to manage component lifecycles, the injection of dependencies, and configurations. The server process comprises a single JVM, the Liberty kernel, and any number of optional features. The feature code, and most of the kernel code, runs as OSGi bundles within an OSGi framework. Features provide the programming models and services required by applications.

    The Liberty profile environment can be downloaded and installed using the Installation Manager or from the WASdev community downloads page:

    We can install the Liberty profile environment using the following methods:

    • Eclipse-based Liberty profile WAS Developer Tools
    • Executing a JAR file
    • The Installation Manager
    • The job manager console


    Installing the Liberty Profile using the job manager console

    To install the Liberty profile using the job manager, we have to use the Manage Offerings job type. To do this, you need a response file. We can customize it for the environment by modifying the bolded values. 

    <?xml version="1.0" encoding="UTF-8"?>
<!--The "acceptLicense" attribute has been deprecated. Use "-acceptLicense"
command line option to accept license agreements.-->
<agent-input acceptLicense='true'>
<server>
<repository location='/opt/IBM/IMRepo/WAS_ND'/>
<repository location='/opt/IBM/IMRepo/web2mobile.repo.1100.all'/>
<repository location='/opt/IBM/IMRepo/WAS85_ND'/>
<repository location='/opt/IBM/kits/Java7'/>
</server>
<profile id='IBM WAS V8.5_2'
installLocation='/opt/WAS/WLP85_1'>
<data key='eclipseLocation' value='/opt/WAS/WLP85_1'/>
<data key='user.import.profile' value='false'/>
<data key='cic.selector.os' value='aix'/>
<data key='cic.selector.ws' value='motif'/>
<data key='cic.selector.arch' value='ppc'/>
<data key='cic.selector.nl' value='en'/>
</profile>
<install modify='false'>
<offering id='com.ibm.websphere.ND.v85' version='8.5.0.20120501_1108' profile='IBM
WAS V8.5_2' features='com.ibm.sdk.6_64bit,liberty'
installFixes='none'/>
</install>
<preference name='com.ibm.cic.common.core.preferences.eclipseCache'
value='/opt/IBM/IMShared'/>
<preference name='com.ibm.cic.common.core.preferences.connectTimeout' value='30'/>
<preference name='com.ibm.cic.common.core.preferences.readTimeout' value='45'/>
<preference name='com.ibm.cic.common.core.preferences.downloadAutoRetryCount'
value='0'/>
<preference name='offering.service.repositories.areUsed' value='true'/>


<preference name='com.ibm.cic.common.core.preferences.ssl.nonsecureMode'
value='false'/>
<preference
name='com.ibm.cic.common.core.preferences.http.disablePreemptiveAuthentication'
value='false'/>
<preference name='http.ntlm.auth.kind' value='NTLM'/>
<preference name='http.ntlm.auth.enableIntegrated.win32' value='true'/>
<preference name='com.ibm.cic.common.core.preferences.preserveDownloadedArtifacts'
value='true'/>
<preference name='com.ibm.cic.common.core.preferences.keepFetchedFiles'
value='false'/>
<preference name='PassportAdvantageIsEnabled' value='false'/>
<preference name='com.ibm.cic.common.core.preferences.searchForUpdates'
value='false'/>
<preference name='com.ibm.cic.agent.ui.displayInternalVersion' value='false'/>
<preference name='com.ibm.cic.common.sharedUI.showErrorLog' value='true'/>
<preference name='com.ibm.cic.common.sharedUI.showWarningLog' value='true'/>
<preference name='com.ibm.cic.common.sharedUI.showNoteLog' value='true'/>
</agent-input>

    To install the Liberty profile on a remote host:

    1. Consider running an inventory job to refresh the job manager or deployment manager targets repository:

      1. In the dmgr console, click Job | Submit.

        In the Job type menu list, select the Inventory job, and click Next.

        Specify the target names and target authentication, and click Next.

        Schedule and submit the job.

      2. Use the Manage offerings job to install the product:

        1. In the dmgr console, click Job | Submit.
        2. In the Job type menu list, select the Manage offerings job, and click Next.
        3. Specify the target names and target authentication, and click Next.
        4. Required parameter.

          1. Response file path name: The full path name to the Installation Manager response file. The path must point to a file located on job manager or deployment manager machine.

          2. Select I accept the terms in the license agreements, and click Next. We can use the response file provided earlier. after you customize the highlighted areas according to the need of the environment.

        5. Schedule the job, or click Next, to proceed with the next step.

        6. Review the summary of the job, and click Finish to submit it.

      3. At this point, your job is submitted and has a unique identifier. We can track its status by clicking...

          Jobs | Status | job id

        We can view the messages in the stdOut.txt file At this point your Liberty profile is installed, and we can create a server.


    Deploying a packaged Liberty Profile on a production server using the

    job manager console

    To deploy a packaged Liberty profile server, decompress its archive file on the target environment. Alternatively we can use the WebSphere ND job manager console to deploy the package on the remote target.

    The content of the Liberty profile server archive contains the root wlp directory with the server configuration, applications, and all libraries so the server is ready to start. Remember that you might also need to specify the location of the Java runtime for the server

    The root directory to install the resources on the target host must be defined. At minimum, set the WLP_WORKING_DIR variable to a valid directory on the target host. To install the resources to a shared directory on the target host, set the WLP_SHARED_DIR variable to a valid directory. See Setting variables for Liberty profile servers at the following website: http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.nd.doc/ae/t agt_jobmgr_var_cs_res.html

    To deploy a packaged Liberty profile server on a remote host:

    1. Consider running an inventory job to refresh the job manager or deployment manager target repository:

      1. In the dmgr console, click Job | Submit.

      2. In the Job type menu, select the Inventory job, and click Next.

      3. Specify the target names and target authentication, and click Next.

      4. Schedule and submit the job.

      5. Use the Install Liberty profile resources job to deploy the Liberty profile archive:

        1. In the dmgr console, click Job | Submit.
        2. In the Job type menu, select the Install Liberty profile resources job, and click Next.
        3. Specify the target names and target authentication, and click Next.

      6. Required parameter, which is the path to the Liberty profile resource archive file

      7. Schedule the job, or click Next to proceed with the next step.

      8. Review the summary of the job and then click Finish to submit it.

      9. At this point, your job is submitted and has a unique identifier. We can track its status by clicking...

          Jobs | Status | job id

      10. After the job successfully finishes, we can inspect the target working Liberty profile folder to view its contents.


    Start and stop a Liberty profile server using the job manager console

    We can start or stop a Liberty profile server using the job manager console. To do this, we have to use the Start Liberty profile server or the Stop Liberty profile server job.

    To start a Liberty profile server on a remote host:

    1. Consider running an inventory job to refresh the job manager or deployment manager targets repository:

      1. In the dmgr console, click Job | Submit.

      2. In the Job type menu list, select the Inventory job, and click Next.

      3. Specify the target names and target authentication, and click Next.

      4. Schedule and submit the job.

    2. Use the Start Liberty profile server job to install the product:

      1. In the dmgr console, click Job | Submit.

      2. In the Job type menu list, select the Start Liberty profile server job, and click Next.

      3. Specify the target names and target authentication, and click Next.

    3. Required parameter, which is the Liberty profile server to be started. We can complete this step by clicking Find and selecting the server to start from the available resources.

    4. At this point, your job is submitted and has a unique identifier. We can track its status by clicking...

        Jobs | Status | job id

    5. After the job is successfully finished, we can work with the applications installed in the Liberty profile server.

    To stop a Liberty profile server on a remote host:

    1. Consider running an inventory job to refresh the job manager or deployment manager targets repository:

      1. In the dmgr console, click Job | Submit.

      2. In the Job type menu list, select the Inventory job, and click Next.

      3. Specify the target names and target authentication, and click Next.

      4. Schedule and submit the job.

    2. Use the Stop Liberty profile server job to install the product:

    3. Click...

    4. Select...

        Enable automatic repository checkpoints

      Clear the check box that disables automatic checkpoints.

    5. For Automatic checkpoint depth, specify the maximum number of checkpoints to keep.

      After the number of checkpoints reaches this checkpoint depth, the product deletes the oldest delta checkpoint when a new delta checkpoint is made.

    6. Click Apply or OK.


    Archiving or deleting checkpoints

    To reduce clutter and free up disk space, we might need to archive or delete old checkpoints periodically. The number of checkpoints stored to disk add up when automatic delta checkpoints are enabled and checkpoint depth is high. Two locations in the product installation hold information for configuration repository checkpoints:

    • PROFILE_HOME/config/cells/cellname/repository/checkpoints subdirectories hold checkpoint metadata
    • PROFILE_HOME/checkpoints subdirectories hold checkpoint contents

    These locations contain subdirectories, one for each checkpoint. Full checkpoints have the user-specified checkpoint name when delta checkpoints are named Delta-sequence_number.

    The file name also contains the time of creation.

    There is no automatically archive function provided by WAS V8.5, but we can use any archive tools to archive these two location files.

    To delete checkpoints use the delete option on the dmgr console Repository checkpoints page. To access the delete option complete the following steps:

    1. Select System administration | Extended repository service | Repository checkpoints | checkpoint_name.

    2. Click the Delete button.


    Restoring checkpoints

    1. Click...

    2. Select one checkpoint_name to restore and then click Restore.

    3. Logout and Login again.

    Delta checkpoints must be restored in descending sequence number order only. Selecting multiple checkpoints for restoration is not supported because it can only restore one checkpoint at each time.


    Configure change audit

    We can also use a delta checkpoint to audit what changes were made to the configuration. A delta checkpoint can be exported as a compressed file. This file contains the before and after versions of configuration files that have been changed.

    To export a delta checkpoint:

    1. Click...

    2. Select the delta_checkpoint_name, and click Export.

    3. On the Export repository checkpoints page, select the name of the compressed file.

    4. Save the file to a specified location.

    5. Extract files from the exported compressed file, and examine the changes in the configuration.


    Restoring transactions

    WAS stores information about transactions that it manages in the form of persistent logs. The default directory for the transaction logs is:

      PROFILE_HOME/tranlog

    These logs can be used to recover transactions that did not complete due to, for example, a hardware or software server failure. The WAS recovers transactions during startup. We can also force it to recover transactions by specifying the -recovery parameter in the startServer command.

    The WAS also supports more complex recovery cases when in a clustered environment, referred to as transactional high availability. The high availability of the transaction service enables any server in a cluster to recover the transactional work for any other server in the same cluster.


    Restarting an application server in recovery mode

    When starting a server with the -recovery parameter after a failure, the transaction service uses recovery logs to complete the recovery process. You must issue the command from the PROFILE_HOME/bin directory of the profile with which the server is associated.

    Using the additional -recovery parameter specifies the server starts in the special recovery mode. The special recovery mode engages the following actions:

  • Transactional resources complete the actions in their recovery logs. This action frees up any resource locks the application server held prior to the failure.

  • During the recovery period, only a subset of the application server functions are accessible. The subset includes only those necessary for the transactional recovery to proceed.

  • The application server does not accept transactions during recovery.

  • The application server shuts down when the recovery is complete.


    Administering the transaction service

    We can view or change settings for the transaction service and manage active and prepared transactions. We can configure transaction properties to enable peer recovery of failed application servers in a cluster. We can manage transaction logging to optimize the availability of application servers. The following list describes the configurations available and what they manage:

    • Configuring transaction properties for an application server Change the location or default file size of the transaction log files, transaction timeout properties, or heuristic-related properties.

    • Configuring transaction properties for peer recovery Peer recovery for the transaction service enables servers in a cluster to complete outstanding work for a failed cluster member. We can configure and manage the manual and automated peer recovery.

    • Managing active and prepared transactions

      In some circumstances, you might have to resolve a transaction manually:

      • Manual transactions: Transactions awaiting administrative completion.
      • Retry transactions: Transactions with some resources being retried.
      • Heuristic transactions: Transactions that have completed heuristically.
      • Imported prepared transactions: Transactions that are imported and prepared but not yet committed.

    • Managing transaction logging for optimum server availability

      The default disk space allocation for the transaction logs is 1M. If all the log space is in use, no more transactions can commit until more log space is made available. We can change the space allocation of transaction log files. It is useful in high workloads scenario.

      We can also store the transaction log in a highly-available file system to complete or recover transaction more quickly.

    • Displaying transaction recovery audit messages

      We can configure the server to use the HPEL log and trace infrastructure instead of using SystemOut.log and trace.log. Set the DISABLE_RECOVERY_AUDIT_LOGGING custom property to turn off the transaction recovery message written to the SystemOut.log.

    • Delaying the cancelling of transaction timeout alarms

      By default, transaction timeout alarms are cancelled prior to the before completion phase of the transaction begins. The DELAY_CANCELLING_ALARMS custom property allows the before completion phase of the transaction to be encompassed within the transaction timeout period.

    • Removing entries from the transaction partner log

      As part of the transaction recovery process, the partner log is checked to establish which resources are needed. We can set the REMOVE_PARTNER_LOG_ENTRY custom property to remove certain entries from the partner log, such as a resource.


    Transactional high availability

    In a clustered environment, a running instance of a server can recover the failed transactions of another server from the same cluster. There is no need to restart the failed server to recover its transactions. Having another server in the cluster to be able to recover transactions is useful when a hardware failure is the cause of the original server unavailability. Transactional high availability allows for the needed time to recover, especially when the hardware fault is extensive.

    There are two possible ways to recover and release the locks of another server in a cluster:

    • Automated peer recovery

      If an application server fails, WAS automatically selects another server to perform peer recovery processing on its behalf. Apart from enabling high availability and configuring the recovery log location for each cluster member, no additional WAS configuration steps are required to use this mode. This is the default recovery option for WAS installations.

    • Manual peer recovery

      If an application server fails, an administrator can use the dmgr console to select a particular server in the cluster to perform recovery processing on behalf of the failed server. To use this recovery mode, additional configuration steps are required.


    Recovery node with addNode -asExistingNode command

    The WAS addNode command is now extended with the additional -asExistingNode parameter to simplify the recovery of nodes in a distributed environment.

    This parameter allows the following abilities:

  • Recover an existing managed node of a deployment manager.

  • Move a node to a product installation on a different computer at the same or different path.

  • Create a cell from a template cell.


    Considerations when using the -asExistingNode command

    1. To make sure the application runs properly in your target environment, update the virtual hosts (host aliases) to include the target host name of the application server node.

    2. If the node uses a SSL certificate, the default SSL certificate of the node does not contain the name of the target machine. Change the default certificate to contain the host name of the new node to make sure SSL works properly.

    3. You might also need to update the configuration of other infrastructure components, such as web servers, that are statically configured to use application servers residing on specific hosts.

    4. Some of the addNode command parameters are incompatible with the -asExistingNode option. Do not use -asExistingNode with the following parameters:

      • includeapps
      • includebuses
      • startingport
      • portprops
      • nodeagentshortname
      • nodegroupname
      • registerservice
      • serviceusername
      • servicepassword
      • coregroupname
      • excludesecuritydomains


    Recovering a failed managed node of deployment manager

    In WAS, to recover a damaged node in a distributed environment (without the backup) complete the following steps:

    1. Reinstall WAS in the same directory as previously used.

    2. Create a profile with the same managed node name and path.

    3. Recover the damaged node using addNode -asExistingNode.

    4. Synchronize the nodes in the cell.

      illustrates this procedure after a node1 failure. When the managed node is unavailable, but the node information remains on the deployment manager, use the -asExistingNode option to recreate the unavailable node. 1 /Node01 addNode -asExistingNode Running recovery procedure for node Node agent/Node01 server1 /Dmgr /Node01 Damaged node Node agent/Node01 server1 Recovered node2 3 Dmgr

      To accomplish rapid node recovery:

      1. Ensure the existing damaged node is not running. Stop the node agent and any application servers that reside on the node. If the node cannot be stopped using standard commands, stop its processes.

      2. Remove the original profile, and create a profile to replace the damaged node and give it the same profile path, profile name, and node name as the unavailable node. Alternatively, we can create the profile on a different computer from the original node, if your original computer is unavailable and we have configured a new one with the same host name.

        In this scenario, node was85Node01 within server profile name Node01 stops working. To recover the node, use the following steps:

      3. Remove the node...

          ./manageprofiles -delete -profileName Node01

      4. Replace the damaged node with a new node. Create a profile named Node01 with node name was85Node01. Be sure to use the same directory path and federate the node later.

        To engage this process:

          ./manageprofiles.sh -create -profileName Node01 -nodeName was85Node01 -profilePath /opt/WAS/AppServer/profiles/Node01 -federateLater true ...

      5. Run the addNode command with the -asExistingNode option from the bin directory of the damaged node profile.

          ./addNode.sh dmgr_host dmgr_port -asExistingNode -username user_name -password foo

        Using -asExistingNode to recover a failed Node 

        [root@myhost bin]# pwd
/opt/WAS/AppServer/profiles/Node01/bin
[root@myhost bin]# ./addNode.sh myhost 8879 -asExistingNode -username admin -password admin ADMU0116I: Tool information is being logged in file /home/opt/WAS/AppServer/profiles/Node01/logs/addNode.log
ADMU0128I: Starting tool with the Node01 profile 
ADMU2010I: Stopping all server processes for node was85Node01
ADMU0024I: Deleting the old backup directory.
ADMU0015I: Backing up the original cell repository.
ADMU0016I: Synchronizing configuration between node and cell.
ADMU0018I: Launching Node Agent process for node: was85Node01
ADMU0020I: Reading configuration for Node Agent process: nodeagent
ADMU0022I: Node Agent launched. Waiting for initialization status.
ADMU0030I: Node Agent initialization completed successfully. Process id is: 7094
ADMU0300I: The node was85Node01 was successfully added to the was85DmgrCell01 cell.
ADMU0003I: Node was85Node01 has been successfully federated.

      6. Synchronize all of the active nodes in the cell. Your node is fully operational again


    Moving a node to a different system

    We can also use the -asExistingNode option to move the node to a different machine. The procedure overview

    1. Ensure the node to move, with the source profile, is not running. Stop the node agent and any application servers that reside on the node.

    2. On the deployment manager, change the host name of the node to target machine host name using the AdminTask.changeHostName command.

    3. Install WAS on the new machine at the same directory location.

    4. Create a profile with the original node name and profile name.

    5. Run the addNode -asExistingNode command.

    6. Synchronize nodes in the network manager cell.

      Using addNode -asExistingNode to move the node to a different machine involves three different profiles:

    7. Deployment manager profile: This profile manages the source profile and is used to manage the destination profile.

    8. Source profile: This profile is migrated to a different destination.

    9. Target profile: This is the new profile created on the source profile base.

      We can use the addNode -asExistingNode command to do the following actions:

    10. Move a node to a different computer but with same operating system and at the same path.

    11. Move a node to a different operating system or with a different path.

      In the following scenario, we assume the source and destination targets use the same profile name and node name, but create a different installation directory and profile path:

      1. Stop the node agent or any application server processes on the source profile, and back up the profile. In this example, we use Node=was85Node01 and profile=Node01.

      2. Change the host name of the source profile node within the master configuration present at the deployment manager. We assume the source machine is myhost and the destination is saw211-win1.

        Change the node host name

          [root@myhost bin]# pwd
          /opt/WAS/AppServer/profiles/Dmgr/bin
          [root@myhost bin]# ./wsadmin.sh -lang jython -username admin -password admin
          WASX7209I: Connected to process "dmgr" on node was85Dmgr01 using SOAP connector; The type of process is: DeploymentManager
          WASX7031I: For help, enter: "print Help.help()"
          wsadmin>AdminTask.changeHostName('[-hostName saw211-win1 -nodeName was85Node01]') ''
          wsadmin>AdminConfig.save() ''

        • If the target profile has the new product installation and profile paths, include this step (if not, proceed to step 4). This step outlines changing the product installation and profile paths of each node in the variable maps on the deployment manager configuration before moving the node to the target computer. The following process outlines the necessary actions for this step:

          1. In a deployment manager dmgr console, click Environment | WebSphere variables.

          2. On the WebSphere Variables page, select the node scope as Node=was85Node01 and then click the WAS_INSTALL_ROOT variable.

          3. On the Settings page for the WAS_INSTALL_ROOT variable, change the Value setting to specify the new product installation path, and save the change.

          4. On the WebSphere Variables page, with the node scope selected, click the USER_INSTALL_ROOT variable.

          5. On the Settings page for the USER_INSTALL_ROOT variable, change the Value setting to specify the new profile installation path, and save the change.

          6. Repeat these steps as needed to change the product installation and profile paths of each node so the paths are correct for the target computer.

        • Log in to the destination target machine, and do the following steps:

          1. Install WAS in a directory that has the same name as the product installation directory on the source profile target.

          2. Create a custom profile that has the same profile name and node name as the one to move, and select to federate the node later (if you move the node with the same profile path, keep the profile directory the same): manageprofiles.bat -create -profileName Node01 -profilePath /IBM/WAS/AppServer/profiles\Node01 -nodeName was85Node01 -hostName saw211-win1 -federateLater true ...

          3. Change your working directory to the newly created profile bin directory:

              cd /IBM/WAS/AppServer/profiles\Node01\bin

          4. Run the addNode command with the -asExistingNode option to replace the application server node with the node to move.

              ./addNode.sh dmgr_host dmgr_port -asExistingNode -username user_name -password foo

          Successfully move node to a different target

            /IBM/WAS/AppServer/profiles.Node01.bin$ addNode.bat myhost 8879 -asExistingNode -username admin -password admin
            ADMU0116I: Tool information is being logged in file

            /IBM/WAS/AppServer/profiles\Node01\logs\addNode.log
            ADMU0128I: Starting tool with the Node01 profile
            ...
            ADMU2010I: Stopping all server processes for node was85Node01
            ADMU0024I: Deleting the old backup directory.
            ADMU0015I: Backing up the original cell repository.
            ADMU0016I: Synchronizing configuration between node and cell.
            ADMU0018I: Launching Node Agent process for node: was85Node01
            ADMU0020I: Reading configuration for Node Agent process: nodeagent
            ADMU0022I: Node Agent launched. Waiting for initialization status.
            ADMU0030I: Node Agent initialization completed successfully. Process id is: 2524
            ADMU0505I: Servers found in configuration:
            ADMU0506I: Server name: Cluter1_Member1
            ADMU0506I: Server name: nodeagent
            ADMU0300I: The node was85Node01 was successfully added to the was85DmgrCell01 cell.
            ...
            ADMU0003I: Node was85Node01 has been successfully federated.

        • Synchronize the nodes using the deployment manager console by clicking...

            System Administration | Nodes unsynchronized nodes | Synchronize

        • Your node is fully operational again in the new target. We can remove the source profile directory and its backup.

        • Applications that use Scheduler only work with the same host name. After you move a node, reschedule any scheduled tasks.

        • We cannot move nodes between product installations on z/OS and non-z/OS operating systems.

        • Previously installed JCA adapters are not stored as part of the WebSphere configuration. After you move a node, reinstall them.


    Recreating a cell from a template

    This procedure requires a good knowledge of WAS configurations. You need to update several files, generated by the server, to migrate them to the new environment.

    Assuming we have your deployment manager cell environment set up:

    1. Back up the deployment manager profile using the backupConfig command.

    2. Copy the backup file to a target where your deployment manager will reside.

    3. On each new target environment to be provisioned, install WAS and create a deployment manager profile or a managed node profile, depending on the environment topology.

    4. Restore the new target deployment manager profile configuration using the restoreConfig command and customize each node configuration.

    5. Update the deployment manager host name using the changeHostName command of AdminTask through wsadmin in local mode. If the profile path or the product installation path changed, update the variables.xml file of the deployment manager node with the new value. Update additional properties files as needed, for example...

      • wsadmin.properties
      • soap.client.props

    6. Customize each node configuration on the deployment manager profile from the old source environment properties to new target environment properties. For example, change the following settings:

    7. Host name: changeHostname command of AdminTask object.
    8. Ports: Ports page of node agent on dmgr console.
    9. Product installation directory: WAS_INSTALL_ROOT variable.
    10. Profile directories: USER_INSTALL_ROOT variable.

    11. Security configuration.

    12. Log in to each new target node, and run the following command from each node PROFILE_HOME/bin directory: 

      ./addNode.sh dmgr_host \
             dmgr_port \
             -asExistingNode \
             -username user_name \
             -password foo

    13. To enable servers for each node to run properly:

      1. Start the node.
      2. Update the virtual hosts (host aliases).
      3. Start servers of the node.

      4. If the cell uses a SSL certificate, replace the SSL certificates.

    14. Synchronize all of the nodes from the deployment manager.

    Restrictions when creating a cell using the -asExistingNode command:

    • Applications that use Scheduler only work with the same host name. After you move a node, reschedule any scheduled tasks.
    • You must asses whether different resources, such as data sources, are required for each environment.
    • Previously installed JCA adapters are not stored as part of the WebSphere configuration. After you move a node, reinstall them.