Create and service WebSphere Application Server master images with IBM Installation Manager

IBM® Installation Manager is the technology for installing and maintaining IBM WebSphere® Application Server V8 and later. Typically, Installation Manager is installed on every production system with the products whose lifecycle it is used to govern. This article reviews the basic components of Installation Manager, and documents a procedure for installing master images of WebSphere Application Server that can be deployed to a production environment and then later serviced in place. This can facilitate mass deployments, in both virtualized and non-virtualized environments. This content is part of the IBM WebSphere Developer Technical Journal.


Ilene Seelemann (, WebSphere Application Server Architect, IBM

Ilene Seelemann is a Senior Software Developer at the IBM Toronto Lab. Ilene is the architect responsible for WebSphere Application Server installation. She also has a long background in XML technology and is the lead for the WebSphere Application server XML components and WebSphere Application Server V7 XML Feature Pack.

30 January 2013

Also available in Chinese Spanish


The procedure described in this article uses IBM Installation Manager, without the need to install it on every system. It shows how to package up critical Installation Manager data with the product image, so that the image can be serviced after it is deployed. We will begin by reviewing some Installation Manager basics.

Installation Manager fundamentals

In a typical installation topology, IBM Installation Manager is installed once on every machine. Installation Manager is configured to point to one or more product repositories that contain the product payload and metadata used to create an install image. Repositories are often hosted remotely (for example, via HTTP or FTP server) from the machine on which the installation is running. Repositories are loosely coupled and can be shared amongst Installation Manager instances (Figure 1).

Figure 1. Installation topology
Figure 1. Installation topology

It is possible to have multiple Installation Managers on a single machine by installing a group mode or user mode Installation Manager:

  • Group mode enables a UNIX® administrative group to share a single Installation Manager to manage product installations. You can have multiple group mode Installation Managers installed on the same system.
  • User mode supports one Installation Manager per user.

See the Installation Manager Information Center for more information on administrative modes.

Sometimes administrators prefer not to have Installation Manager installed on every machine at all. This can be due to business policies that complicate managing Installation Manager as another product install, or it might be related to disk footprint, especially in a virtualized environment. :

Furthermore, for large deployments of WebSphere Application Server, administrators might prefer to create a master image in an engineering environment, which can be cloned to target systems. Once deployed to the target systems, administrators create WebSphere Application Server profiles. Later, when it is time to apply maintenance, such as fix packs or ifixes, administrators must be able to service the cloned images.

The remainder of this article will review the basic Installation Manager components and describe a procedure for deploying cloned images of WebSphere Application Server that supports the servicing of those images.

Installation Manager directories

Before diving into the procedure, it is important to understand the directories that Installation Manager creates in order to govern the lifecycle of the products that it is used to install. There are two directories:

  • The Agent Data Location, sometimes referred to as the appDataLocation, contains metadata that includes the history and state of all installs being managed by Installation Manager. This directory is critical to the healthy functioning of Installation Manager. Once the directory is created, it cannot be moved and should not be touched. If the Agent Data Location becomes corrupt, then all product installations that are tracked by that Agent Data Location will become unserviceable and will need to be reinstalled if service is needed.

    This directory is created when Installation Manager is itself installed. You can override the default location by specifying the –dataLocation (or –dL) command line option when installing Installation Manager.

    For this procedure we will not actually be installing Installation Manager, so we will discuss how this directory is created for our scenario later in this article.

  • The Shared Resources Directory is used for two purposes:
    • In some cases, it contains resources that can be shared by installed products at run time. WebSphere Application Server products do not have run time dependencies on the contents of this folder.
    • It is also used at install time to stage the payload before it is installed into its target folder. During this step, 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 rollback or update in the future.

    The location of the Shared Resources Directory is set when the first product is installed. Each product repository specifies a default location, so if this location is not overridden, then the first installed product determines the location. To explicitly set this location, use the -sharedResourcesDirectory command line option when the first product is installed.

    Like the Agent Data Location, the Shared Resources Directory cannot be changed after it is initially set. Because product payloads are cached here, space requirements can grow very large over the lifetime of the product, as maintenance is applied. The WebSphere Application Server product image is large, so if this content is permitted to accumulate, then this directory will grow to be many gigabytes in size over the course of multiple fix pack applications. You should never manually delete the content in this folder.

Fortunately, there is a preference that you can use to prevent the caching of this data. During any installation or maintenance operation, you can use this preference:


With this preference set to false, all data that is no longer needed will be removed after the operation completes. You still need to ensure you have enough space to stage the payload during the installation and maintenance operations, but data will not accumulate over time. If you have previously not used this preference, all old payloads will be removed the first time you use it. The only way to remove the data without performing an install or maintenance operation is with the Installation Manager GUI, using the Delete Saved Files button in the Preferences panel (Figure 2). You can also set the preference in this panel.

Figure 2. Delete Saved Files option in Preferences
Figure 2. Delete Saved Files option in Preferences

Be aware that if you use this preference, then you will always need to connect to a product repository in order to perform rollback or update operations. You will not be able to rely on cached payloads. Most administrators find this an acceptable trade off.

Using the installer

Now that we have reviewed the two directories that Installation Manager creates and uses to govern product installs, let us look at how you can use Installation Manager without actually installing it. In the Installation Manager Information Center documentation, this is referred to as using the installer or install kit.

The installer should not be used on a system where you already have Installation Manager installed. If you attempt this, some operations will detect the installed Installation Manager and block it.

To begin, you must download the Installation Manager installer. You can download the platform-specific installer that matches the platform on which you will be installing:

Figure 3
Figure 3

Extract the files to a directory. The command line invocation imcl can be found in the tools subdirectory of the installer. Use this command to drive install operations or to invoke a response file that contains your install instructions. (Be aware that the installer cannot be used to record a response file.) Sample response files are available for WebSphere Application Server V8 and WebSphere Application Server V8.5.

Know that response files and command line arguments provide equivalent capability and the choice to use one versus the other is personal preference. For brevity, examples in this article are shown using command line arguments.

Creating a master image

Now that you have the installer downloaded and extracted, you can install your WebSphere Application Server master image. You must have a WebSphere Application Server product repository for the service level you need to install. Examples in this article will use the IBM-hosted web repository, but you can also set up a locally hosted enterprise repository for your business. For more information on creating an enterprise repository, see these resources:

Consider the command shown in Listing 1.

Listing 1
-installationDirectory <install_home>/AppServer
-dataLocation <install_home>/iim_appData
-sharedResourcesDirectory <install_home>iim_shared

Arguments and options:

  • -

    This instructs Installation Manager to install the WebSphere Application Server Network Deployment V85. The fix pack level installed will be the latest found in the specified repositories. All applicable ifixes will also be installed.

  • repositories

    You must provide a comma-delimited list of repositories that contain the product payload and metadata for the products you need to install. This repository is the IBM-hosted web repository for WebSphere Application Server Network Deployment V85.

    - Product identifiers (also known as offering IDs and package IDs) as well as repository product URLs are available for WebSphere Application Server V8 and for WebSphere Application Server V8.5.

  • -installationDirectory <install_home>AppServer

    This argument specifies where to install the product.

  • -dataLocation <install_home>/iim_appData

    As discussed earlier, -dataLocation specifies the Agent Data Location which Installation Manager uses to track the state and history of this product installation. When servicing products in this install location you must always specify the same -dataLocation argument.

  • sharedResourcesDirectory <install_home>/iim_shared

    This argument specifies the location of the Shared Resources Directory. You should always specify the same Shared Resources Directory and Agent Data Location pair.

  • -preferences

    This preference cleans up the Shared Resources Directory cache after install and update operations. This is discussed in detail above in the Shared Resources Directory section. (There will still be a few files in this folder.)

  • -acceptLicense

    Review the product license, and then specify this argument.

  • -showProgress

    Gives visual feedback as the install progresses.

After the install operation completes, you will have a directory structure of the form:


As you can see, this creates the Agent Data Location and Shared Resources Directory as peer folders of the product installation. Keeping these folders co-located with the product installation will enable you to apply maintenance to this install image in the future. You can now package up all directories in this master image and copy it to your production systems. The operating system and architecture, and directory structures in your production systems must exactly match those in the environment used to create the master image.

Applying maintenance to your install image

At some time in the future, you might need to apply a fix pack or ifix directly to your deployed product image. To do this, you simply need to use an Installation Manager installer and specify the same –dataLocation and –sharedResourcesDirectory that is associated with your product installation. The installer must always be at the same or higher level than was previously used. If you performed the initial install with Installation Manager 1.5.3 and then did an update with 1.6.0, you can never go back to an installer older than 1.6.0. Doing so can result in corruption of the Installation Manager metadata. One way to guard against this is to package up the installer with the product image, like this:


Suppose that you have WebSphere Application Server Network Deployment installed at fix pack level and you want to apply Fix Pack On the production machine, you would run the same original command, from the /iim_installer_160 folder. This would have the effect of updating your image to the current Fix Pack level that is published to the IBM hosted web repository (currently You could also explicitly specify the fix pack level, by qualifying the package name:

Fix packs and iFixes can be applied using the same method.


This article described a process for installing a master image of WebSphere Application Server that can be deployed and serviced. This process involves two key points:

  • Use the Installation Manager installer to install the master image and apply maintenance to the image in production.
  • Co-locate Installation Manager key directories with the master image and package these up with the image so that maintenance can be applied after it is deployed.

By following these guidelines, you can create serviceable master images of WebSphere Application Server.



Get products and technologies


developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

Zone=WebSphere, Rational
ArticleTitle=Create and service WebSphere Application Server master images with IBM Installation Manager