Installation Manager overview
IBM Installation Manager is a common installer for many IBM software products used 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 WAS products. It determines and shows available packages, including products, fix packs, and interim fixes; checks prerequisites and inter dependencies; and installs the selected packages. We also use Installation Manager to uninstall the packages that it installed.
Depending on the operating system, we 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 installed at a single location.
To manage multiple copies of a software product, such as a test copy and a production copy, we 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. WAS 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 WAS 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, we 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. We must still ensure we have enough space to stage the payload during the installation and maintenance operations, but data no longer accumulates over time. If we have previously not used this preference, all old payloads are removed the first time we use this preference. We can also specify this preference by selecting the Delete Saved Files option on the Preferences panel in the Installation Manager GUI. We 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.
(Windows) (iSeries) Group mode is not available for the Windows or IBM i platform.
How many Installation Managers are needed?
We need to run Installation Manager only on those systems on which we 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.
Install Installation Manager
When the installation kit is available on the system, we 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 creating an Installation Manager, we 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, we run the Installation Manager installation command from the appropriate user ID to install Installation Manager.
Access 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 we install a new product, we can choose from any of the available product levels in any accessible repository.
We 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 we install a new product, we can choose from any of the available product levels in any accessible repository.
Install the product
After creating an Installation Manager and have access to all necessary product repositories, we can use the Installation Manager GUI, command-line commands, console mode, or response files to perform the actual product installations. When we install a product, we 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 we can select at installation time or a list of optional supported language packs from which we 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.
Work with installed products
Use Installation Manager commands to list installed products and product levels. We can also obtain this information for installed copies of WAS v9.0 products by running the versionInfo.bat or versionInfo.sh command from the product file system.
After products are installed, we can unmount them from the locations at which they are known to Installation Manager and remount them at other production locations, or we can copy them to other computer systems. If we copy the Installation Manager binary files and runtime data along with the product file system, we can apply maintenance to the installed products on any computer system that has access to the product and service repositories.
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.
Use IBM Packaging Utility
IBM Packaging Utility is a companion tool for Installation Manager used to create custom Installation Manager repositories. We 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 further customization and reduces the size of the repository by maintaining content for only those platforms used by our organization. For more information, read Command-line arguments for pucl.
If we specify unsupported operating-system and architecture combinations for WAS offerings when we use the -platform option of the Packaging Utility copy command, however, unusable local repositories might be created.
Valid combinations for creating a local WAS offering repository sliced by operating system and architecture.
Platform Options Resulting Repository Windows os=win32,arch=x86_64
os=win32Windows 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=aixAIX 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=os400IBM i 64 bit z/OS os=zos,arch=s390x
os=zosz/OS 64 bit Restriction: When using the Packaging Utility command-line interface (PUCL.exe) that is available in the Packaging Utility installation folder, we can only specify the -platform parameter once.
Subtopics