You should have a good understanding of the WebSphere Portal installation process and advanced configuration tasks, especially those typically involved in initial setup, such as security enablement and database configuration. It is also helpful to know the scripted administration capabilities of IBM WebSphere Application Server that use the wsadmin scripting command.
The time it takes to run through the basic installation of WebSphere Portal, to the point where a functioning portal is available, is typically one to two hours. Getting this portal to the point where it meets internal security configuration requirements and connects to the corporate LDAP and database servers and deploy the portal’s basic set of pages and portlets, however, involves many manual configuration and deployment tasks that can add days to this task.
You can cut the costs of these operations, which would normally have to be performed on every new installation of WebSphere Portal. This article describes how an initial system installation can be archived and used as a template for additional installations, without requiring additional repetitions of the post-installation configuration tasks.
Portal administrators can create several different customized installation archives, one for each target environment type, such as development, test, preproduction staging, and production. These installation archives can be used to create both stand-alone server profiles and additional clustered server profiles.
Portal solution providers can use this method to deliver an installation bundle preconfigured with their solution.
This article does not cover the tasks necessary for installing and configuring that initial instance, but instead focuses on building an archive from this installation and creating additional server instances based on it. This scenario involves these steps:
Create the installation archive by following these steps:
- Install and configure WebSphere Portal as appropriate.
- Archive the PortalServer directory and WebSphere Application Server configuration.
- Create the custom installation package (CIP).
Install a WebSphere Portal instance based on the installation archive by following these steps:
- Install a new WebSphere Application Server instance.
- Import the WebSphere Application Server configuration archive.
- Expand the PortalServer directory.
- Optionally establish the new installation’s database instances.
Before you begin building and testing your first WebSphere Portal installation archive, familiarize yourself with the following information.
- Installation archive. The snapshot of a customized WebSphere Portal installation containing the PortalServer directory, a WebSphere Application Server installation factory custom install package (CIP), a WebSphere Application Server configuration archive, and optionally an export of WebSphere Portal database data.
- Configuration archive. A file system archive of a WebSphere Application Server profile’s configuration directory, built using the wsadmin command.
- Custom install package. A single installation package built using the installation factory tool that is an aggregation of a base WebSphere Application Server installation package (for example, Version 6.1) plus any number of fix packs, service packs, and interim fixes.
It is assumed that you already have an installed and fully configured instance of WebSphere Portal that you want to use as a basis for this cloning procedure.
There are configuration scripts packaged with this article that also must be downloaded and applied to the WebSphere Portal installation image that form the basis for the installation archive that you are building. These configuration scripts define tasks necessary for localizing a new WebSphere Portal instance to the local system, including node name, cell name, and host name.
Using WebSphere Application Server installation factory
WebSphere Application Server provides a utility called Install Factory that is used to combine a base installation image with any number of service packs and interim fixes into a single installation image called a custom install package, or CIP. The CIP installs much faster than an individual application of each installation layer. In fact, WebSphere Portal uses installation factory to install WebSphere Application Server at its prerequisite service level, which for WebSphere Portal V6.1 is WebSphere Application Server Version 6.1.0.15.
Use installation factory to build your own CIP, based on your prerequisite WebSphere Application Server service level, and then use this package as a basis for each new WebSphere Application Server beneath WebSphere Portal.
Installation factory greatly simplifies the WebSphere Portal cloning procedure. The instructions in this article assume that you will build and use your own CIP containing all prerequisite WebSphere Application Server maintenance that WebSphere Portal requires. Note that WebSphere Application Server does not support mass-replication of a server installation using an archive mechanism; instead, it emphasizes and supports the use of installation factory to simplify this cloning process. For more information on using installation factory, refer to the Resources section at the end of the article.
WebSphere Portal makes extensive use of databases to store portal site configuration data and community- and user-specific definitions, such as authored content, document repositories, and customized pages and portlets. The database tables are broken up into domains, based on the intended use and scope of the data. Every new WebSphere Portal installation must have a set of database domains. These database domains can be shared in environments where portal profiles are clustered, or can be unique in stand-alone installations, or can even be embedded in WebSphere Portal itself, when for example the Derby database embeds default database domains in a new installation.
Before building WebSphere Portal installation archives and using them to reproduce standard installation configurations, carefully plan how to include these database domains as part of the installation archives.
There are two options for handling database data:
- Use the included Derby database that is used by default after an initial installation to hold portal configuration information. In this case, the database is part of the archive and is replicated for each installation.
- Configure WebSphere Portal to use an external database and capture the portal configuration using database-specific tools, such as backup and restore.
The scenarios that follow illustrate how the database handling mechanisms can be used.
Installation archives for clustering
Every portal cluster server member shares the same database domains, meaning that there is some central database server or servers hosting all the required database domains. These domains are set up by the initial, or primary, portal cluster member. Subsequent cluster members, however, point to these central database domains, eliminating the need to include any database exports as part of the installation archive or the need to transfer a database to build new database domains.
The installation archive should contain the data source definitions already preconfigured to point to these central database domains. When you create additional clustered server instances based on an installation archive, the new profile should already be configured to point to the correct database domains, simplifying or eliminating any post-installation reconfiguration.
Because WebSphere Application Server configuration archives cannot be created from a federated profile, you need to create the archive from a stand-alone portal profile before it is placed under the deployment manager’s control (federated) and used to build the cluster.
Installation archives for development
When you install a new WebSphere Portal, the portal database domains are set up in an embedded Derby database. Thus, there is no need for an external database. This document’s installation archive procedure captures the Derby database configuration and reproduces it with each new cloned WebSphere Portal installation.
Even though the Derby database is not well suited for production use, it is ideal for development use, as it simplifies the system requirements and topology. You might want to install and configure a WebSphere Portal for developers and include the default Derby-based database domains in the installation archive. No additional database-related configuration is necessary.
Installation archives for new stand-alone server installations
You might want to build a WebSphere Portal installation archive to serve as a standard configuration for a new stand-alone portal requiring the use of an external database. Perhaps the embedded Derby database won’t work for your intended purpose, or you have a corporate standard and mandate to use a certain database product, even for development. To use an external database, you need to build a new set of WebSphere Portal database domains for this new stand-alone portal.
Capture the WebSphere Portal database configuration as a set of file system assets that can be added to the rest of the installation archive, to ensure that the database data is synchronized with the portal installation. The easiest way to do this task is to capture the Derby database instance embedded in WebSphere Portal, which is populated as part of the default installation. Then use WebSphere Portal’s database transfer facility (refer to the Resources section for more information) to dynamically build a new set of database domains from this Derby instance.
As an alternative, use database-specific facilities for exporting and importing table information, such as the IBM DB2® db2look and db2move utilities. The exported data is then made part of the overall installation archive as a file system asset. A new database instance can then be created based on this captured data, followed by using the connect-database ConfigEngine task to connect to the new instance. Refer to the Resources section for more information.
The procedures in this article work only with installations of WebSphere Portal Version 6.1 or later.
Homogeneous server environments
For simplicity, it is assumed that a WebSphere Portal installation archive is used to build additional WebSphere Portal installations on the same operating system on which the installation archive was built. Additionally, it is assumed that the installation directory is the same on each server into which the installation archive is expanded. This uniformity eliminates the need for any reconfiguration of the new WebSphere Portal installation. The process of creating a new WebSphere Application Server profile and importing the configuration archive takes care of configuring the TCP/IP host name and WebSphere Application Server cell and node names for the new portal.
Common user repository
Because the installation archive contains role definitions and access controls for both WebSphere Application Server and WebSphere Portal assets, it is assumed that the archive's capture of a user repository configuration (for example, a corporate LDAP server) is common with each new WebSphere Portal installation built from this archive.
Stand-alone server support
This cloning process can be used only to create new stand-alone WebSphere Portal server installations. It cannot be used to upgrade an existing node managed by the deployment manager because federated profiles do not support the importing of configuration archives. After using this process to create the new WebSphere Portal server installation, however, the server can then be federated (put under the deployment manager’s control) and used as a basis for additional cluster instances.
Cannot be used with WebSphere Process Server
The cloning process cannot be used in conjunction with WebSphere Process Server because it doesn’t yet support the use of configuration archives to replicate profiles. In the meantime, additional WebSphere Portal and WebSphere Process Server installations must be created using traditional installation processes.
No WebSphere Portal specific operating system updates
Because the WebSphere Portal installation is being replicated through expansion of a file system archive there is no installation process to update the operating system’s configuration, which means that, depending on the operating system, certain features are missing.
For Microsoft® Windows®, this limitation means that there are no Start menu folders or desktop icons for accessing and controlling WebSphere Portal. Also, there are no Windows registry updates, so WebSphere Portal does not display in the Software Maintenance application, and thus has to be uninstalled manually by either deleting the PortalServer directory or running the uninstall command manually from the WebSphere Portal home directory’s uninstall subdirectory.
No support for multiple nodes in the same profile
WebSphere Application Server V6.1 supports the ability to define a Web server as an additional server type in the profile. Web servers are typically defined in a different node than the application servers, so the resulting profile has two node definitions in it. The WebSphere Application Server wsadmin command does not yet support exporting a profile that contains more than one node in it. The instructions that follow for creating a configuration archive instruct you to temporarily delete the Web server node to build the configuration archive. The Web server configuration can be added back later.
Uninstallation
Because WebSphere Portal is installed together with WebSphere Application Server, there is no separate uninstallation for WebSphere Portal. WebSphere Application Server must be uninstalled first; then you can remove whatever files and directories are remaining.
Build the installation archive
Use the following steps to build an installation archive from a fully installed and configured WebSphere Portal profile. In this example, <wp_home> is used to denote the WebSphere Portal installation directory, <was_home> is used to denote the WebSphere Application Server installation directory, and <profile_home> is used as the profile’s base directory. A temporary directory, denoted as <tmp>, is used to store results of the following steps.
All directory paths are shown in UNIX® style, using forward slashes. All dollar signs ($) used as part of wsadmin scripting commands are escaped to prevent them from being interpreted as environment variables. Dollar signs ($) do not need to be escaped on Windows operating systems.
- Download and unpack the additional configuration scripts included with this article under the <profile_home>/ConfigEngine directory. There should be these files:
config/includes/localize_clone61.xml config/includes/create_clone.xml config/was/wp_UpdateWasVariable.jacl config/was/wp_GetWasConfig.jacl
Because configuration tasks are run as part of the installation archive creation process, ensure that the WasPassword property is set properly in <profile_home>/ConfigEngine/properties/wkplc.properties.
Alternatively, every ConfigEngine command can also include the WasPassword=<password> option for specifying the WebSphere Application Server administrative password when invoking configuration commands.
- WebSphere Portal has several scheduled tasks that run periodically within a running server instance. These task definitions are maintained in a database table, and some of them have references to the local host name. Because the host name changes when new instances are created based on this cloning procedure, these task definitions need to be rebuilt with the updated host name. That process happens automatically at startup if task definitions do not initially exist, so they should be deleted now before the installation template is created.
To delete the scheduled tasks, run the following ConfigEngine task:
<profile_home>/ConfigEngine/ConfigEngine.sh action-clean-scheduled-tasks
This task assumes that the database type is Derby. If database data is located in an external database (for example, DB2), then the task definition must be changed to specify that database type. Edit the <profile_home>/ConfigEngine/config/includes/necessary_tasks.xml file and change the following two property values under the action-clean-scheduled-tasks target definition:
<property name="driver.prop" value="${<db_type>.DbDriver}"/> <property name="library.prop" value="${<db_type>.DbLibrary}"/>
Where <db_type> is set to the value of the release.DbType property in the <profile_home>/ConfigEngine/properties/wkplc_comp.properties file.
- Create a series of file system archives of the WebSphere Portal’s installation directory and additions to the WebSphere Application Server configuration profile. These activities capture all property file configurations and file system assets that make up the WebSphere Portal runtime environment.
A configuration task has been provided to help build the required configuration archives:
<profile_home>/ConfigEngine/ConfigEngine.sh clone-create-zip –DoutDir=<tmp>
This configuration command creates the following file system archives in the <tmp> directory:
- wp_home.zip. An archive of the PortalServer directory and some specific additions to the AppServer directory.
- wp_profile_adds.zip. An archive of several WebSphere Portal specific directories added to the WebSphere Application Server profile that are not captured as part of the configuration archive created later.
- variables.xml. A copy of the WebSphere variable definitions, which contains variables required for importing a portal-based configuration archive.
- Create an Ant script called <tmp>/wp_home_unzip.ant for unpacking the WebSphere Portal installation directory archive and another one called <tmp>/removePortal.ant for removing the WebSphere Portal installation directory during uninstallation. These Ant scripts are installed with the installation factory custom installation. Note that the wp_home_unzip.ant script refers to the environment variable WP_INSTALL_SRC, which refers to the <tmp> directory, or the source for the ZIP file. You can either replace this environment variable with a static value or set the environment variable prior to installation. Use the wp_home_unzip.ant and removePortal.ant scripts that are included with the file archive associated with this article as starting points.
- Create an Ant script called <tmp>/wp_profile_unzip.ant for unpacking the WebSphere Portal additions to the configuration profile and localizing the portal configuration. This Ant script is included with the installation factory custom installation package and is invoked after profile creation and configuration archive import complete. Note that the script refers to three environment variables:
- WP_INSTALL_SRC, which refers to the <tmp> directory, or the source for the ZIP file
- WP_INSTALL_DIR, which refers to the installation directory for WebSphere Portal
- WP_PROFILE_DIR, which refers to the location of the wp_profile directory
You can either replace these environment variables with static values or set the environment variables prior to installation. Use the wp_profile_unzip.ant file that is included with the file archive associated with this article as a starting point.
The ConfigEngine task called in the Ant script above requires the three configuration files included with this article to be part of the installation archive and the PortalServer.policy file, which should be placed in the <tmp> directory.
- If the WebSphere Application Server configuration profile contains a Web server definition in its own node (separate from the node containing the WebSphere_Portal application server instance), then this node must be temporarily deleted to create the configuration archive in a following step. The Web server configuration can be added back later when the new instance is created.
The Web server node and server definition can be removed using the following wsadmin command:
<was_home>/bin/wsadmin –c “\$AdminTask removeUnmanagedNode {-nodeName <web_server_node>}” –user <was_admin_id> -password <was_admin_pwd> -conntype NONE
Where <web_server_node> is the node name containing the Web server definition, <was_admin_id> is the WebSphere Application Server administration user ID, and <was_admin_pwd> is the associated password.
- For Windows only: By default, WebSphere Portal sets the short version of the installation directory name as the value for the WPS_HOME WebSphere Application Server environment variable, which can cause problems during the configuration archive import layer. Before creating the configuration archive in the next step, you need to change this variable value to the full path. For example, if the value is currently set to C:\PROGRA~1\WEBSPH~1\PORTAL~1, it needs to be changed to C:\Program Files\WebSphere\PortalServer.
You can reset the WPS_HOME variable value using the WebSphere Application Server administration console under Environment - WebSphere Variables. Be sure to save your changes.
- Note that WebSphere Portal must be stopped before running this command.
Create a WebSphere Application Server configuration archive to capture the WebSphere Portal’s application server configuration. A configuration task is also included to make this easier, which places a configuration archive file named wp_profile.car into the directory specified by the –DoutDir parameter:
<profile_home>/ConfigEngine/ConfigEngine.sh clone-create-car -DoutDir=<tmp>
- Optionally, you might want to export the database tables used by the WebSphere Portal installation that forms the basis for this installation archive’s portal. Export the database tables into a <tmp>/db subdirectory. These exported tables can then be imported in new database instances to serve new WebSphere Portal server installations built from this archive.
Alternatively, WebSphere Portal’s database transfer utility can be used to dynamically transfer data from one database into a new instance. If the new WebSphere Portal installation is to be used to build additional cluster members, then no database import or transfers operations are necessary because cluster members share a common database.
Refer to the "Database considerations" section for more information on these options.
Now, let's build the installation factory custom installation package.
- Download and unpack the Installation Factory tool for WebSphere Application Server V7.0.
Note that the installation factory tool V7.0 is used because it is capable of building custom installation packages for both WebSphere Application Server V6.1 and V7.0.
- In this example, you build a CIP at the WebSphere Application Server Network Deployment V6.1.0.15 maintenance level. Under <tmp>, create subdirectories to hold the base WebSphere Application
Server Network Deployment V6.1 installation image, the WebSphere Application Server V6.1.0.15 service pack image, and the latest Java™ SDK service pack image. The directory structure should look like this:
<tmp> ├─ SDK ├─ WASND_61 └─ WAS_610.15
Populate the staging directories as follows:
- Download and unpack the WebSphere Application Server Network Deployment V6.1 base installation image into the <tmp>/WASND_61 directory. If you do not have the installation media for WebSphere Application Server Network Deployment V6.1, then as a WebSphere Portal V6.1 customer you are entitled to download it from the Passport Advantage® online Web site. On this Web site, under Software Downloads, search for "WebSphere Portal 6.1" and then open the eAssembly corresponding to your WebSphere Portal package. A link should display for downloading WebSphere Application Server Network Deployment V6.1.
- Download and unpack the latest Java SDK 1.5 cumulative fix package to the <tmp>/SDK directory.
- Download and unpack the WebSphere Application Server V6.1.0.15 service pack to the <tmp>/WAS_610.15 directory.
- Launch the installation factory graphical user interface application (ifgui) to begin the process of building a new CIP based on the packages that you have downloaded into the <tmp> directory. The launch pad shown in figure 1 opens.
Figure 1. The installation factory launch pad
- Click Create New Customized Installation Package to get started. The Product Selection wizard launches, which guides you through the initial process of building a CIP. Provide the following values on the pages:
- Product selection: IBM WebSphere Application Server 6.1.0.0
- Product package selection: IBM WebSphere Application Server
- Edition selection: Network Deployment
- After finishing the Product Selection wizard, the Build Definition wizard launches to facilitate the build of the CIP based on the product selections that you just provided. The first page is the Mode Selection page shown in figure 2.
Figure 2. Mode Selection page
- Select Connected mode and click Next to continue. Next is the Package Identification page as shown in figure 3.
Figure 3. Package Identification page
- On the Package Identification page, provide a unique ID that identifies this CIP apart from other CIPs that you might create. This example uses com.ibm.wp.610.archive. Also specify a version for this CIP. In the future, increment this value as appropriate to denote new archive versions. Click Next to continue to the Build Information page shown in figure 4.
Figure 4. Build Information page
- On the Build Information page, specify the location of the <tmp> directory for the package build directory path and build definition location. In this example, <tmp> is C:\temp\if_staging. After providing your directory location, click Next to continue to the Product Installation Image page shown in figure 5.
Figure 5. Product Installation Image page
- Specify the directory where you have stored the WebSphere Application Server Network Deployment V6.1 base installation image. This example specifies <tmp>/WASND_61, or c:\tmp\if_staging\WASND_61. Click Next to continue to the Feature Selection page shown in figure 6.
Figure 6. Feature Selection page
- Select the WebSphere Application Server features that you want to include in the CIP. To conserve space, this example does not include samples. Click Next to continue to the Maintenance Packages page, shown in figure 7, to specify the package files for the service levels that you want to include in the CIP.
Figure 7. Maintenance Packages page
- Note that the wizard requires that you specify the PAK files for each service package, so you must navigate through the subdirectories in the staging area to locate each package file. The prior screencapture illustrates the location of these PAK files as set up in this example’s staging area. Click Next to continue to the Install and Uninstall Scripts page, shown in figure 8, where you list custom installation Ant scripts to add to the CIP.
Figure 8. Install and Uninstall Scripts page, the Install tab
Figure 9. Install and Uninstall Scripts page, the Uninstall tab
- On the Install page, add the wp_home_unzip.ant custom Ant script for unzipping the PortalServer directory. On the Uninstall page, shown in figure 9, add the removePortal.ant script for removing the PortalServer directory. Click Next to go to the Profile Customization page, shown in figure 10, where the configuration archive and another custom Ant script is provided.
Figure 10. Profile Customization page
- Select the Stand-alone Application Server profile type, then provide the configuration archive that you created before, wp_profile.car. Then provide the custom Ant script wp_profile_unzip.ant. Ensure that the Ant script is positioned after the configuration archive, so that it is run after the configuration archive is imported. You are now done providing input to the custom installation package. Click Next several times to proceed to the last page, Customized Installation Package Preview, shown in figure 11.
Figure 11. Customized Installation Package Preview page
- Click Save build definition file and generate customized installation package, then click Finish to build the CIP. The build of the CIP takes some time, and the final location is in the <tmp>\ifpackage directory.
Note where the build definition file is located (<tmp>/builddefs/com.ibm.wp.610.archive_1.0.0.0.xml). At any time you can return to the installation factory tool to revise this CIP by first loading this build definition file.
- Create response files for the CIP image so that it can be installed silently as part of any automation set up to create additional WebSphere Portal installations. Information on how to customize and use the response file is included in the installation factory documentation references in the Resources section.
This example uses the responsefile.nd.txt sample response file for the silent installatioon and places a copy of it in the <tmp> directory, as responsefile.txt. Sample response files can be found under the Automating the process section later in this article.
Create a WebSphere Portal instance from an archive
Use the following steps to create a new WebSphere Portal instance based on an existing installation archive. These steps use the tag <tmp> to specify the root directory of the installation archive, and the tags <was_home> and <wp_home> to specify the WebSphere Application Server and WebSphere Portal home directories, respectively. It is assumed that the contents of the <tmp> directory have been copied from the original master server to this new server where the clone will be created and that <tmp> now refers to the location of the installation archive on this new server.
- You can skip this step if you hard-coded directory locations in your configuration Ant scripts in the CIP.
Set the WP_INSTALL_SRC environment variable to the <tmp> directory and the WP_INSTALL_DIR to the target PortalServer directory, so that the unzip Ant script knows where to locate the wp_home.zip file and portal configuration scripts. For example, on Windows, based on the installation factory example values from the previous section, use this code:
set WP_INSTALL_SRC=C:\tmp\if_staging set WP_INSTALL_DIR=C:\IBM\PortalServer set WP_PROFILE_DIR=C:\IBM\WebSphere\wp_profile
For UNIX, use the export command as in the following example:
export WP_INSTALL_SRC=/mnt/if_staging export WP_INSTALL_DIR=/opt/IBM/WebSphere/PortalServer export WP_PROFILE_DIR=/opt/IBM/WebSphere/wp_profile
If WP_INSTALL_SRC refers to a different directory than the original <tmp> location, then be sure the ifpackage directory and wp_home.zip file are copied to this new location.
- Change to the <tmp>/ifpackage/WAS directory, and invoke the installation program in silent mode to install the new WebSphere Portal instance. Provide the response file created in the last step of building the installation archive to the install command as an option by entering this code on the command line:
<tmp>/ifpackage/WAS/install -options <tmp>/responsefile.txt –silent
- If new database instances are required for this new WebSphere Portal installation, create them at this time, and reconfigure the WebSphere Portal data sources to point to these new databases.
If the installation archive includes an embedded Cloudscape database prepopulated with the default portal configuration, then use the transfer-database configuration task to transfer this data to a new set of database instances. Refer to the Resources section for more information on the transfer-database configuration task.
If the installation archive includes exported table and data definitions, then use them to create the new database instances and use the WebSphere Portal connect-database configuration task to reconfigure all of WebSphere Portal’s data source definitions to point to these new instances. Refer to the Resources section for more information on the connect-database configuration task.
- Perform any required application-specific localization of this installation to ensure that the applications included in this installation archive work appropriately on this server.
Most, if not all, of the prior steps can be automated. Because installation factory is actually controlling the entire installation of both WebSphere Application Server and WebSphere Portal, only a silent installation of the CIP is required to create a stand-alone portal instance. Additional automation might be required to perform such steps as database instance creation and transfer, but those steps are not covered in this article.
The following example is a silent installation response file with parameters that control the installation of the WebSphere Application Server CIP and creation of the configuration profile. The file is located in the installation archive root directory (<tmp>).
Sample installation response file
This response file is used for silently installing the CIP and creating the custom configuration profile. To save space, this sample includes only the property values and none of the inline comments or unused options. The properties themselves come from the sample response file ( responsefile.nd.txt) provided with the CIP. This sample, shown here as listing 1, would be stored as <tmp>/responsefile.txt, to correspond to the command-line example in step 2 of the previous section. A copy of this response file is included with the file archive that accompanies this article.
Listing 1. Sample installation response file
-OPT silentInstallLicenseAcceptance="true" -OPT if_cip_modifyexistinginstall=customizationAndMaintenance -OPT installType="installNew" -OPT feature="noFeature" -OPT installLocation="C:\WebSphere61\AppServer" -OPT profileType="standAlone" -OPT PROF_enableAdminSecurity="true" -OPT PROF_adminUserName=wpsadmin -OPT PROF_adminPassword=wpsadmin -OPT PROF_profileName=wp_profile -OPT PROF_profilePath=C:\WebSphere61\wp_profile -OPT PROF_isDefault="true" -OPT PROF_hostName=tristan.dyn.webahead.ibm.com -OPT PROF_nodeName=tristanNode -OPT PROF_cellName=tristanCell -OPT PROF_defaultPorts="true" -OPT PROF_validatePorts="true" -OPT PROF_winserviceCheck="false" |
Because clone instance creation can now be driven by a single installation process, troubleshooting becomes more important because you have less control over the process. Here is the process for determining if a problem has occurred and identifying its cause:
- CIP installation logs its progress and final status in a log.txt file located in the system-defined temporary directory (for example, %HOMEPATH%\waslogs\log.txt for Microsoft Windows and $TMP/waslogs/log.txt for UNIX). Note that this file is cumulative. The status for the latest installation attempt is at the end.
- If installation succeeded, then an INSTCONFSUCCESS message displays at the end of the file.
- If a failure occurred, this file reports an INSTCONFFAILED status message at the end along with an indicator of what failed and typically a pointer to another log file with more details.
Note that at the end of installation, whether or not the installation failed, the log.txt file is relocated to <was_root>/logs/install. It will exist only in the above locations during the actual installation process.
- If no log.txt file seems to have been created, then the installation did not get far enough to create one. Check your responsefile.txt file to ensure that you don’t have duplicate –OPT entries or any incorrectly specified entries.
- If there was a failure during profile creation and CAR import, it should be reported under <was_root>/logs/manageprofiles/wp_profile, where <was_root> is the WebSphere Application Server installation directory, not the profile directory.
- Because most of the profile operations are conducted through the wsadmin scripting interface, you can also look for more error details within the <profile_root>/logs/wsadmin.traceout log file.
- Finally, the custom Ant scripts used to unzip and localize the PortalServer directory logs its operation to <profile_root>/logs/install/wp_home_unzip.ant.log and <profile_root></profile_root>/logs/manageprofiles/wp_profile/wp_profile_unzip.ant.log, assuming that you named the custom Ant scripts as such. Refer to those logs to see if any errors occurred during any of these operations.
If the installation does fail, it might not be enough to delete the target installation directories. You might also have to update the .nifregistry file or the InstallShield vpd.properties file to remove the registration entries for WebSphere Application Server. Otherwise, another installation attempt will fail with an error indicating that a version of the product already exists at that location. On Windows, both .nifregistry and vpd.properties are located in the C:\Windows directory, and on UNIX, they are typically under /root/ or /. Edit the files using a text editor, remove the rows for the WebSphere Application Server version targeting the installation directory that you specify, and then save the file.
This article explained how to take a preinstalled and preconfigured WebSphere Portal installation and copy it to easily build additional installations of the identical configuration. The copying process includes steps to build a WebSphere Application Server installation factory image, a WebSphere Application Server configuration archive, and a set of WebSphere Portal file system archives. Additionally, options were discussed for including portal database data as part of this archive and for using the archive as a template for building additional portal installations.
There remain several steps involved in cloning portal installations, but using this procedure can remove hours, if not days, from the installation and configuration process and ensure a consistent deployment of WebSphere Portal across your entire infrastructure.
The authors wish to especially thank the following individuals who helped with verifying the content of this article:
- Mary Lindt, T. Rowe Price
- Jammie L Sammons, CDS Global
- Andrew Cook, Carefx
| Name | Size | Download method |
|---|---|---|
| portal_cloning_files.zip | 13KB | HTTP |
Information about download methods
- Participate in the discussion forum.
- Refer to the WebSphere Application Server Information Center to learn how to use installation factory to build a WebSphere Application Server custom installation package.
- Refer to the WebSphere Portal Information Center to learn how to use the connect-database configuration task.
- Refer to the WebSphere Portal Information Center to learn how to to use the transfer-database configuration task. The task is discussed under database-specific instructions, starting here (for Linux® and DB2 in this example).
- Refer to the WebSphere Portal product documentation.
- Check out the developerWorks WebSphere Portal zone.
- Learn more about the Apache Ant scripting environment.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
