Installation Manager overview

IBM® Installation Manager is a common installer for many IBM software products that you use to install WebSphere® Application Server and other associated software.

Installation Manager is a single installation program that can use remote or local software flat-file repositories to install, modify, or update new WebSphere Application Server products. It determines and shows available packages, including products, fix packs, and interim fixes; checks prerequisites and inter dependencies; and installs the selected packages. You also use Installation Manager to easily uninstall the packages that it installed.

Depending on your operating system, you can work with Installation Manager through a graphical user interface, command-line interface, console mode, or response files.

IBM Installation Manager Version 1.8.5 or later is required to install the product.

For more information on using Installation Manager, read the IBM Installation Manager documentation.

Packages and package groups

Each software product that can be installed with Installation Manager is referred to as a package. An installed package has a product level and an installation location. A package group consists of all of the products that are installed at a single location.

To manage multiple copies of a software product, such as a test copy and a production copy, you install the product several times and into separate package groups, each with a distinct installation location. The different copies of the product can be maintained or upgraded separately.

Installation Manager directories

Installation Manager uses the following directory terminology:

Agent data location

The agent data location directory contains the metadata that tracks the history and state of all product installations that the Installation Manager is managing. This directory is created when Installation Manager is installed.

The agent data location directory, which is sometimes referred to as the app data location, is critical to the correct functioning of Installation Manager. After the directory is created, it cannot be moved. If the agent data location directory becomes corrupted, all product installations that are tracked by the metadata in the agent data location directory become unserviceable and must be reinstalled if service is needed. See the Installation Manager documentation for the default location of the agent data location directory.

Shared resources directory

The shared resources directory is used for two purposes:

It might be used to contain resources that can be shared by installed products at run time. WebSphere Application Server products do not have runtime dependencies on the contents of this folder.
It might be used at installation time to stage the payload before it is installed into its target folder. In this scenario, filesum checks are performed on the transferred data to ensure that it is intact. By default, this content remains cached in the shared resources directory after installation so that it can be used for future updates or rollback.

The location of the shared resources directory is set when the first product is installed. Each product repository specifies a default location. Therefore, if this location is not overridden, then the first installed product determines the location.

The -sharedResourcesDirectory command line option can be used the first time the Installation Manager installs a product to specify the location of this directory. The location of the shared resources directory cannot be changed after it is initially set.

Because product payloads are cached in this directory, space requirements can grow very large over the lifetime of the product, as service updates are applied. The WebSphere Application Server traditional product image is large, so if this content is permitted to accumulate, then this directory can grow to be many gigabytes in size over the course of multiple fix pack applications. Never manually delete the content in this folder. Instead, during any installation or maintenance operation, you can specify the following preference to remove some of the content in this folder:

-preferences com.ibm.cic.common.core.preferences.preserveDownloadedArtifacts=false

When this preference is set to false, all data that is no longer needed is removed after the operation completes. You must still ensure you have enough space to stage the payload during the installation and maintenance operations, but data no longer accumulates over time. If you have previously not used this preference, all old payloads are removed the first time you use this preference. You can also specify this preference by selecting the Delete Saved Files option on the Preferences panel in the Installation Manager GUI. You can also use this panel to indicate that download artifacts are not to be preserved.

Installation Manager modes

IBM Installation Manager can be installed in one of the following three modes:

In admin mode, the Installation Manager is installed from an administrator or a root ID and can be invoked by any administrator or root user.
In nonAdmin mode (also called user mode), the Installation Manager can be invoked only by the user that installed it.
In group mode, the Installation Manager can be invoked by any user ID that is connected to the default group of the user that installed it. However, only one person can use the single instance of IBM Installation Manager at a time.
Group mode is not available for the Windows or IBM i platform.

How many Installation Managers are needed?

You need to run Installation Manager only on those systems on which you install or update product code. You normally need only one Installation Manager on a system because one Installation Manager can track any number of product installations.

Getting the Installation Manager installation kit

IBM Installation Manager comes in the form of an installation kit, which contains a set of Installation Manager binary files and a repository for the Installation Manager product. The installation kit is primarily used for setup and maintenance of the Installation Manager.

Installing Installation Manager

When the installation kit is available on your system, you can install Installation Manager. Installation Manager consists of a set of binary files that are copied from the installation kit and a set of runtime data that describes the products that were installed by this particular Installation Manager.

Before you create an Installation Manager, you must decide in which mode the Installation Manager will run and where the binary files and runtime data—called agent or app data—will reside. Then, you run the Installation Manager installation command from the appropriate user ID to install Installation Manager.

Accessing product repositories

All software materials that IBM Installation Manager installs are stored in repositories. Each repository contains program objects and metadata for one or more packages—that is, software products at a particular level. Repositories can also contain product maintenance, such as fix packs and interim fixes. Whenever you install a new product, you can choose from any of the available product levels in any accessible repository.

You can also have Installation Manager download product fix packs and interim fixes from an IBM service website. Note that interim fixes are available only through the service website or from the IBM Support Center.

Whenever you install a new product, you can choose from any of the available product levels in any accessible repository.

Installing the product

After you create an Installation Manager and have access to all necessary product repositories, you can use the Installation Manager GUI, command-line commands, console mode, or response files to perform the actual product installations. When you install a product, you provide the package name, optionally the product level to be installed, the product location, and any other optional properties. For example, some products have optional features that you can select at installation time or a list of optional supported language packs from which you can select.

Each copy of a product must be installed at a separate file system location. Certain products might be intended to be installed together into a common location.

Choosing installation locations is a critical part of product planning. These installation locations are normally distinct from the locations at which the products are mounted when actually in use.

Working with installed products

You can use Installation Manager commands to list installed products and product levels. You can also obtain this information for installed copies of WebSphere Application Server Version 9.0 products by running the versionInfo.bat or versionInfo.sh command from the product file system.

After products are installed, you can unmount them from the locations at which they are known to Installation Manager and remount them at other production locations, or you can copy them to other computer systems. If you copy the Installation Manager binary files and runtime data along with the product file system, you can apply maintenance to the installed products on any computer system that has access to the product and service repositories.

You can use Installation Manager to install a new product level, roll back to a previous level, or modify the product by adding or removing optional features or language packs.

Using IBM Packaging Utility

IBM Packaging Utility is a companion tool for Installation Manager with which you can create and manage custom Installation Manager repositories for your organization. You can copy multiple packages, maintenance levels, and fixes into a single repository. Packaging Utility copies from source repositories to your target custom repositories. Source repositories can include any accessible Installation Manager repository, including IBM web-hosted product repositories and unzipped Passport Advantage® downloads. For more information on Packaging Utility, see the Installation Manager documentation about Packaging Utility.

Packaging Utility Version 1.5.2 introduced the capability to create platform-scoped repositories. The -platform option of the Packaging Utility copy command allows you to further customize and reduce the size of your repository by maintaining content for only those platforms that your organization uses. For more information, read Command-line arguments for pucl. If you specify unsupported operating-system and architecture combinations for WebSphere Application Server offerings when you use the -platform option of the Packaging Utility copy command, however, unusable local repositories might be created. The following table lists valid combinations for creating a local WebSphere Application Server offering repository that is sliced by operating system and architecture.

Table 1. Valid combinations for creating a local WebSphere Application Server offering repository using the Packaging Utility copy command
Platform	Options	Resulting Repository
Windows	os=win32,arch=x86_64 os=win32	Windows 64 bit
Linux® Intel	os=linux,arch=x86_64	Linux Intel 64 bit
Linux Power®	os=linux,arch=ppc64	Linux Power 64 bit
zLinux	os=linux,arch=s390x	zLinux 64 bit
AIX®	os=aix,arch=ppc64 os=aix	AIX 64 bit
Solaris Sparc	os=solaris,arch=sparc64	Solaris Sparc 64 bit
Solaris Intel	os=solaris,arch=x86_64	Solaris Intel 64 bit
HP-UX Itanium	os=hpux,arch=ia64	HP-UX Itanium 64 bit
IBM i	os=os400,arch=ppc64 os=os400	IBM i 64 bit
z/OS®	os=zos,arch=s390x os=zos	z/OS 64 bit

Restriction: When using the Packaging Utility command-line interface (PUCL.exe) that is available in the Packaging Utility installation folder, you can only specify the -platform parameter once.