This document details the deployment instructions for IBM® WebSphere® Portal and Web Content ManagerTM Hypervisor Edition in the form of an Open Virtual Archive (hereafter referred to as "OVA", or "image") for deploying through the IBM Workload Deployer Appliance (IWD) and IBM PureSystems.
IBM PureSystems is a new product family of expertly integrated systems from IBM that combine software and hardware to give you a pre-configured, efficient virtualization platform. The offering from PureSystems that function with the WebSphere Portal Hypervisor Edition is the IBM PureApplication System (PureApp), and includes IBM middleware images and patterns to cusotmze and deploy, relying on the IWD function to handle image and instance management. Because the IWD function is an integral part of PureApp, working with the WebSphere Portal and WCM patterns within PureApp is identical to working with them on IWD.
This OVA lets you experience the fully functional WebSphere Portal Server and Web Content Manager instance deployed through IWD and PureApp. The image also includes definitions and configurations for multiple parts of a typical WebSphere Portal and Web Content Manager deployment, allowing you to build very-simple-to-more complex topologies quickly and easily. In addition, the package also includes optional functionality available in the IBM Connections Files and Profiles Integration Pack for WebSphere Portal.
This document guides you through the steps of deploying this OVA, as well as how to build new OVA images based on an instance created from the original image. You may wish to build new OVAs to contain your own custom WebSphere Portal and Web Content Manager solutions that can be used to build deployment patterns of your own design.
We focus on the process of setting up an instance of WebSphere Portal Hypervisor, covering the following topics in detail:
- Initializing a new instance based on the OVA, using deployment patterns created by the user
- Accessing and managing WebSphere Portal
- Building a new OVA based on an instance you customize
This documentation is intended for users who have a general knowledge of Linux® and how it works. To get the most from this article, you should have a good understanding of Linux commands and how to manipulate input and output. You should also have a good working knowledge of the PureApp and IWD appliance, its administrative console, and how to deploy patterns using it.
We provide a basic overview of how to manage WebSphere Portal and include links to product documentation for more detailed information and guidance on how to use the product to build a Web site.
OVA contents and configuration
The WebSphere Portal OVA is a pre-installed and pre-configured instance of the product. Instances created based on this OVA are ready to use and pre-configured with certain features to make it easier to get started. The product configuration includes:
Security enablement - WebSphere Application Server security is enabled with the virtuser user ID, serving as both the WebSphere Portal administrator and WebSphere Application Server administrator id. During the deployment of the OVA, you will be required to set the password for the virtuser user id.
HTTP Server enablement - The IBM HTTP Server is configured to provide port 80 access to WebSphere Portal. The IBM HTTP Server is configured in its own part definition, so that it can be set up as a remote virtual machine for certain topologies instead of running on the same machine as WebSphere Portal. Section 3.3 covers how to use the HTTP Server.
External DB2 database - An instance of IBM® DB2 Enterprise Edition is installed and configured as WebSphere Portal's external database, providing an enterprise-class and highly performing database environment. It's configured in its own part definition, so that it can be set up as a remote virtual machine if desired.
Deployment Manager - A Deployment Manager part is defined to be run in its own virtual machine for managing a cell containing a WebSphere Portal / Web Content Manager cluster.
Web Content Manager enablement - The OVA has Web Content Manager configured for rendering and authoring. Several sample content libraries are also provided, including support for blogs and wikis.
IBM Connections Integration Pack - Connections Files and Profiles functionality is included automatically in your Portal deployment if you choose any of the supported cluster patterns. For more information see the IBM Connections Integration Pack section
Adding the OVA to IWD and PureSystems
There are two methods for adding the Portal OVA into IWD: the Web interface and the command line.
To import the image, patterns, and script packages using importPatterns.py
- Uncompress and extract the downloaded WebSphere Portal Hypervisor Edition to a temporary directory. You should have file named patterns.json and 3 subdirectories: ./images, ./add_ons, and ./script_packages in the /tmp/portalPattern directory. For example:
tar -zxvf image.tgz -C /tmp/portalPattern
tar -xvf image.tar -C /tmp/portalPattern
- Determine the hostname, username and password for your IWD or PureApp appliance. Download and install the Command Line Interface
- Execute the deployer or pure command for your platform with the parameters as shown
cli_home/bin/deployer -u username -p password -h iwd_hostname -f ../samples/importPatterns.py -s /tmp/portalPattern
cli_home/bin/pure -u username -p password -h iwd_hostname -f ../samples/importPatterns.py -s /tmp/portalPattern
/tmp/portalPattern is the temporary directory where the Portal package was extracted
cli_home is the location of the IWD or PureApp Command Line Interface
username is the IWD or PureApp administrator username
password is the IWD or PureApp password
iwd_hostname is the IWD or PureApp appliance hostname
To import just the image using the PureApp or IWD Web interface
- Extract the WebSphere_Portal.ova file from the downloaded package under the images subdirectory and make it accessible via and HTTP or SCP server. Click the link "Catalog", then "Virtual Images" menu located on the PureApp Workload page. This takes you to a page containing all the virtual images in the catalog.
- Click the New Virtual Image icon ( ) and enter the requested information to add the Portal OVA into the catalog.
- For remote access, specify either an SCP or HTTP URL in the Location field and, optionally, a user ID and password, if the URL is protected (see figure 1).
Figure 1. Creating a new OVA
To manually import the script packages IWD or PureApp Web interface
- Extract the script package tar files from the downloaded package under the script_packages sub-directory. Click the link Add Script Packages located under the PureApp System Console, Catalog, Script Packages page. This takes you to a page containing all the script packages in the catalog.
- Click the New Script Package icon and enter the requested information to add the script package into the catalog.
- Select the zip or tgz file on the local filesystem using the Browse field, and select Upload (see figure 2).
Figure 2. Creating a new script package
Initializing a new instance of the OVA
The following sections outline prerequisite information and steps for creating a new instance or pattern of an image. Details of how to use the IWD and PureApp administrative console, set up an account, and a cloud of hypervisors are not provided here. For more information on the IWD and PureApp, refer to the IWD InfoCenters and PureSystem Infocenters
If you imported the package with the importPatterns.py described , there are several pre-defined patterns representing various deployment options. You can view them on the Patterns, Virtual Systems page. If you did not import the patterns, or to create new patterns:
1. Click the new pattern icon ( ) on the patterns tab of the Web interface to create a new pattern for the Portal image (see figure 3).
Figure 3. Creating a new pattern
2. Enter the required information and optional description. IWD then creates a new blank pattern with the information specified (see figure 4).
Figure 4. New blank pattern
3. Click the edit pattern icon ( ). A list of all the parts, Add-ons, and script packages provided by the virtual image that are available for the pattern to use are in the parts for ESX (see figure 5). The canvas is where you drag parts over to model virtual machines that will be created.
Figure 5. The pattern editor
4. To create a standalone WebSphere Portal instance in a single virtual machine that runs DB2 and the IBM HTTP Server locally, simply drag the Standalone server part over into the canvas. A single box containing the part appears (figure 6), representing a single virtual image, which is the simplest to deploy for standalone systems.
Figure 6. A simple pattern
5. To build a more complex pattern, such as a standalone portal instance with a remote DB2 instance, or a portal cluster, use the Portal Part instead of the Standalone server part and add additional machines to the deployment, simply by dragging over multiple parts (see figure 7).
IWD automatically detects and creates links between various machines and configures them accordingly at deployment. The Portal Part is used over the Standalone Server Part to provide for more configuration options when supporting more complex configurations.
To use the Connections features available in the IBM Connections Files and Profiles Integration Pack for WebSphere Portal, you must have a cluster-type topology defined, For more details on using the new Social Portal deployment, refer to the IBM Connections Files and Profiles Integration Pack for WebSphere Portal section .
Figure 7. Portal cluster of two nodes
6. If you choose not to use the IBM Connections Integration pack for WebSphere Portal, simply drag the Disable Connections Integration Pack script package onto the Portal Part in your pattern (see figure 8).
Figure 8. Portal cluster with IBM Connections Integration Pack disabled
7. You can make additional changes, such as memory, CPU, and passwords for each VM, and set specific ordering requirements on the deployment operations. Click Done editing to save a your pattern. You can then make your pattern read-only, or deploy it.
Parts of the OVA
The WebSphere Portal and Web Content Manager OVA contains six parts that can be used for defining patterns for deployment:
Standalone server - Configures a self-contained virtual machine for setting up simple single-server deployments and for extending and capturing a new virtual image (see Section 5).
Deployment Manager - A virtual machine configured to run the Deployment Manager, for managing a cell containing a WebSphere Portal cluster. If the IBM Connections Integration Pack for WebSphere Portal is enabled, this node will also host a Connections Application Server
IHS Part - Sets up a remote IBM HTTP Server to load-balance Web access to the portal cluster.
Portal Part - The most versatile part, this creates a self-contained Portal instance with a local DB2 instance and HTTP Server, or is linked to a Deployment Manager as a part of a cluster pattern. It can also link to the remote IHS and DB2 parts. Selecting a Portal Part instead of a Standalone server provides for more configuration options at deployment. The Portal Part also contains more links with other parts than the Standalone, making it the desired part to use with clustering. Note: A Portal cluster pattern should have only 1 Portal part, representing the Primary node
Secondary Portal Part - In a Portal cluster, operations on secondary cluster members are different than those on the Primary node. This part should be used in patterns as secondary Portal cluster members, and can be incremented to increase the total number of Portal cluster members
Remote DB2 - Creates a remote DB2 instance for either a single-server instance (using a single Portal Part) or a cluster of portal instances.
Included Script packages
The WebSphere Portal and Web Content Manager package also includes optional script packages that can be used with your patterns for enhanced function.
Disable Connections Integration Pack - Optionally disables Connections Files and Profiles functionality in your portal deployment. This script package will remove portlets, pages, profiles, clusters and application servers. It will take away the ability to navigate seamlessly between Portal content and Connections Files and Profiles pages
Additional script packages
Other commonly needed script packages are available as part of this wiki page in the Attachments section . These packages can be placed on various parts of your patterns for various, related configuration steps beyond what the base deployment provides. These are meant to be samples only and are a starting point to your own pattern customizations. For more details on script packages and patterns, see the IWD and PureApp Infocenters.
Current Script packages
Update IHS Plugin - placed on the IHS Part in a portal cluster pattern. This script package communicates with the deployment manager node to trigger a regeneration of the webserver plugin, capturing all newly deployed applications, or additional cluster members, copies the configuration back to the webserver node, and restarts the webserver. Because there may be multiple updates to a virtual system deployment, we recommend this script package be set to run "When I initiate it"
Expand Connections - placed on the Secondary Portal part in a Social Portal cluster pattern. This script package communicates with the deployment manager, and adds a new cluster member under the ConnectionsCluster. In order to inform the HTTP Server of the new member, it is recommended to also use this script package in conjunction with the Update IHS Plugin script package.
Script packages that are currently under development to be available soon
Add LDAP Configuration - placed on the Portal Part and Secondary Portal part. This script package augments the out of the box file-based registry with a proper LDAP server that exists on your network. Some updates to LDAP properties, such as hostname, suffixes, schemas, etc will be required in the included wkplcParent.properties
Modify HTTP Server working threads - placed on the IHS Only part. This script package modifies the number of worker threads in use by the IBM HTTP Server component in your deployment.
Modify JVM working threads - placed on the Deployment Manager part. This script package modifies the number of worker threads in use by theWebSphere Application Server JVM running WebSphere Portal in your deployment.
Modify JVM Heap size - placed on the Deployment Manager or Standalone Server part. This script package modifies the size of the WebSphere Application Server JVM running WebSphere Portal in your deployment.
Modify Datasource connection pool size - placed on the Deployment Manager or Standalone Server part. This script package modifies the size of the WebSphere Application Server datasource pool your deployment.
To deploy a pattern:
- Select a pattern to deploy, and then click the "Deploy in the cloud..." icon (). A prompt displays in which you can configure the deployment by setting the virtual system name, scheduling the deployment, and configuring each virtual machine. For the Portal OVA, the configuration consists of setting passwords and the cell and node names, determining whether to federate the node if it's the primary node, and enabling VNC.
- On the initial deployment window (see figure 9), specify a name for this deployment. Select a Cloud Group on which to deploy the pattern, and then click the "Configure virtual parts" link to provide the missing configuration details for the portal pattern, on a per-part basis.
Figure 9. Deploying a virtual system
3. As you click each part in the virtual system description window, a resulting window displays to set the required parameters for each part (see an example in figure 10). This include setting machine sizes, required passwords, node and cell identities.
Figure 10. Configuring the virtual machine
4. Click OK after filling out each part's required values in the window, and then click the OK button to start the deployment. IWD will optionally notify you via email when the deployment has completed.
Working with an OVA instance
Congratulations on completing the deployment of a WebSphere Portal and Web Content Manager OVA.
We now brief you on how to get started with the system. For more information on how to administer, customize, and develop applications for the WebSphere Portal platform, refer to the WebSphere Portal and Web Content Manager product documentation page.
File system locations
Table 1 summarizes the locations for the file systems.
Note: By default, the Connections shared data directory exists on the DMGR node only. Other Connections cluster members must mount their local directory of this name to the DMGR node. See the IBM Connections Infocenter for more information on the shared data directory.
Starting and stopping WebSphere Portal
You can start and stop WebSphere Portal by using the WebSphere Application Server startServer.sh and stopServer.sh shell scripts, respectively. By default WebSphere Portal is started at the end of deployment. For a cluster of WebSphere Portal instances, it is easier to start and stop instances and manage other resources from the Deployment Manager's administration console.
To manage individual server instances, even in a cluster, open a secure shell session with your new instance and change to the /opt/IBM/WebSphere/Profiles/wp_profile/bin directory. To start WebSphere Portal, run the following command as virtuser from within this directory:
Where server_Name is WebSphere_Portal for a standalone server, or the cluster member name running on this machine.
Likewise, stop WebSphere Portal using the following command within the same directory:
./stopServer.sh <server_name> -user virtuser -password <password>
Note that with the stopServer.sh script, you must specify the administrative user (virtuser) and password that were provided in the password configuration windows during initial setup of this instance.
When deployments use the IBM Connections Files and Profiles Integration Pack for WebSphere Portal function, additional steps are required to stop and start the various server. Refer to the IBM Connections Files and Profiles Integration Pack for WebSphere Portal section for more details.
Accessing the Deployment Manager console
To access the Deployment Manager administration console, in which individual cluster members can be managed centrally, open a browser and point it to the server where the Deployment Manager part was deployed, logging in as virtuser:
Starting and stopping the HTTP Server
The OVA comes pre-configured with the IBM HTTP Server to allow port 80 and 443 access to WebSphere Portal. By default, the HTTP Server is started only on cluster patterns with a remote IHS part. To stop the HTTP Server, change to the /opt/IBM/HTTPServer/bin directory and run the following command:
Likewise, to start the HTTP Server, run the command:
The HTTP Server reads its application server plug-in configuration from /opt/IBM/HTTPServer/Plugins/config/webserver1/plugin_cfg.xml, which is automatically refreshed during pattern deployment.
On standalone server deployments, the HTTP Server is on the same server as WebSphere Portal. In cluster pattern deployments, the HTTP Server is on the machine running the IHS Part.
Accessing the site from a browser
Different versions of the WebSphere Portal product use different ports in WebSphere Application Server for administration and direct access to the portal JVM. With the most current version of the OVA, after WebSphere Portal has started, you can access it using the following URLs:
WebSphere Portal home page (if HTTP Server is stopped):
http://<public host name>:10039/wps/portal
WebSphere Portal home page (if HTTP Server is active):
http://<public host name>/wps/portal
WebSphere Application Server admin console (standalone pattern):
http://<public host name>:10042/ibm/console
WebSphere Application Server admin console (cluster pattern):
http://<public host name>:9060/ibm/console
IBM Connections Integration Pack for WebSphere Portal
In newer versions of the WebSphere Portal, customers are pre-entitled to the files and profiles features of the IBM Connections offering. The Portal OVA now includes these functions preinstalled on the image, including a seamless security and navigation integration that allows your portal users to use these features without re-authenticating or even leaving portal navigation. On the default portal home page, there are two new pages defined for each of these features: Files and Profiles
Although the image includes both products tightly integrated, the WebSphere Portal and IBM Connections deployment must still be treated as 2 separate products, relying on each products respective Information Centers. Several types of configuration changes will have to be coordinated between the 2 product to result in consistent behavior.
The benefit of the IBM Connections Files and Profiles Integration Pack for WebSphere Portal is it offers faster, more automated integration between WebSphere Portal and IBM Connections (Files and Profiles).
After you deploy the pattern, you have the following items installed and configured:
- IBM WebSphere Portal
- IBM Connections Files and Profiles
- Web Application Integrator portlet
- IBM Connections 4.0 portlets for WebSphere Portal (Profiles portlet enabled)
The Web Application Integrator portlet is used to display the Connections Profiles page on a Websphere Portal page. The Profiles portlet provides a directory of your colleagues. You can use this directory to build a network of local expertise.
The topology for IBM Connections Files and Profiles Integration Pack for WebSphere Portal, includes a clustered WebSphere Portal environment, IBM Connections 4.0 Files and Profiles, Search, News, Files, and Profiles, databases, and a federated file-based user registry.
WebSphere Portal and IBM Connections Integration Points
The two integration points between IBM Connections and WebSphere Portal are the Web Application Integrator and the Profiles portlet.
Web Application Integrator (Files and Profiles)
Web Application Integrator (WAI) brings a normal web application into the WebSphere Portal navigation. WAI allows users to keep their Portal navigation visible while they are viewing content from another source. In the IBM Connections Files and Profiles Integration Pack for WebSphere Portal, WAI exposes the Files and Profiles functions from IBM Connections directly into your WebSphere Portal navigation. After completing the steps in this documentation, you can use the page created for IBM Connections Files and Profiles to integrate the Files and Profiles user interface with WebSphere Portal. You can browse the Files and Profiles pages as if they were a portal page. Users have full access to all the features and functions provided by the Files and Profiles application.
Note: If you are using custom themes, see the wai_CustomizeTheme.html file, located in the WebSphere/Profiles/wp_profile/paa/WAIPortlet/components/WAIPortlet/documentation/ directory.
You can add the IBM Connections Profile portlet for IBM Connections 4 to any portal page. The portlet provides the typical portlet uses, including aggregating profile content in context on the page with other portlets or web applications. You can view the Profiles page with WAI or directly on a portal page as a portlet. Choose the Profiles portlet when you need applications to interact with each other on the same portal page. The Profile portlet does not duplicate the Profiles page functionality. Instead, it provides a subset of the full Profiles user interface functionality. It specifically targets in context interactions with profiles on a page. To access the full user interface, use WAI to integrate the Portal navigation over the IBM Connections Profiles page.
Once deployed, the WebSphere Portal and Connections cluster will be started and configured with WebSphere Federated Repositories, but relies on the out of the box file-based registry for its users. Users in this registry will not be enabled for the Connection Profile function, including the WebSphere and Portal administrative user, virtuser. Because the WebSphere Portal and Connections application servers are in the same WebSphere cell, they share security configuration as well.
We recommend you follow the portal instructions Configuring a federated LDAP user registry on Linux in a clustered environment
Tivoli Directory Integrator
Once the LDAP registry is added, you must use the Profiles Database Population Wizard to synchronize the LDAP users with the Connections databases. IBM Tivoli Directory Integrator is required to be installed before this wizard can operate. Follow the Connections instructions: Populating the Profiles database
Note: These operations can be scripted and converted into a script package to apply to your IWD/PureApp pattern
Several other optional integration points can be used to further enhance your Portal and Connections deployment.
Integrate IBM Connections Files so IBM Web Content Manager authors can link to content stored in Files.
Note: Usage of this function requires Portal 8 CF03 to be installed
Add additional Portal and Connections nodes to the cluster if necessary.
Regenerate the web server plug-in.
1. Regenerate the web server plug-in using the deployment manager WebSphere Integrated Solutions Console.
2. If you are using a remote web server, copy the updated plug-in configuration file (plugin-cfg.xml) to the web server's plug-in configuration directory.
3. Stop and restart the web server.
Launching a deployment of WebSphere Portal using IWD and PureApp will create your portal using a default locale setting of English, however, there are several ways that Portal can present the web page in other locales. Browser settings can trigger page views in various locales without any change to the default setting. For more information on locale detection and on changing the default locale used in Portal, see the Language Support section in the IBM WebSphere Portal Information Center.
If the IBM Connections Files and Profiles features are in use, you should coordinate any Connections default locale configuration changes, and understand the locale detection mechanims may not be the same across products. In addition, the Files and Profiles portal page links are not currently translated, and browser nor profile level locale settings will affect their display.
A WebSphere Portal Server and Web Content Manager, and IBM Connections instance based on this OVA can be serviced just like any other native installation of this software. Corrective service packages in the form of iFixes (or "interim fixes" that address a particular product issue) or CFs (regular, cumulative roll-ups of iFixes into a single installable unit) are available for download from the IBM Support Web sites:
From these sites you can search on problem symptoms and obtain information from Technotes, Redbooks publications, and fixes that can address problems. Although the image includes both products tightly integrated, the WebSphere Portal and IBM Connections deployment must still be treated as 2 separate products, relying on each products respective Information Centers.
To install iFixes and fixpacks, you can use the Installation Manager already included.
Alternatively, you may wish to re-apply your customizations to a new instance created from an OVA that has been updated to a more recent service level by IBM. To do this, you must have extracted all custom artifacts from the instance so that they can be applied again, such as:
- Exported content libraries using the ConfigEngine's export-wcm-data configuration task
- Exported portal configuration using the xmlaccess utility
- Collecting all portlet WAR files and other J2E resources
These artifacts can be imported into the new instance using the appropriate administration utilities. Refer to the WebSphere Portal / WCM InfoCenter for topics on administering WebSphere Portal and the use of the xmlaccess utility and importing libraries:
Extending and capturing an OVA
After customizing an instance of a WebSphere Portal Server and Web Content Manager OVA with custom applications, site designs, and content libraries, you may want to build a new OVA based on this instance from which new instances can be created. Follow the instructions to prepare and capture a new OVA.
Extending a virtual image
To do this:
- Go to the virtual images catalog and select the OVA you wish to extend. It is recommended you use the Standalone server image.
- Click the extend icon (), enter the requested information, and click OK. A new virtual image is created, along with a single virtual machine of that image.
- Once the virtual machine is deployed, you can make any changes you wish to the virtual machine. These changes are what you will capture as a part of your new virtual image.
Capturing a virtual image
To do this:
- Capture the virtual image by clicking the capture icon ( ). When the capture is finished the virtual image will contain all the changes you made. Those changes will be reflected in any patterns you deploy that use that virtual image. WCA will automatically reset the virtual machine before capturing.
- You can recapture your virtual machine as many times as you like. When you are finished with your changes, you can mark the virtual image as read-only by clicking the Make read-only icon ().
wpcollector.sh execution fails on Portal 8 Hypervisor Edition with OutOfMemoryException
wpcollector.sh execution fails on Portal 8 Hypervisor Edition with a java.lang.OutOfMemoryError exception because there is a wp_profile symlink in the wp_profile directory which is causing recursion while gathering files. Removal of the symlink resolves the issue
Officially tested and supported browsers for each product can be found in the respective product Infocenters. When using the IBM Connections Integration Pack, we recommend a browser supported by both. Currently the recommended list is:
- Firefox version 10 or higher
- Internet Explorer versions 8 and higher
- Safari version 5 and higher
- Google Chrome 19 and higher
"Message: Can't move focus to the control because it is invisible, not enabled, or of a type that does not accept the focus" . The error only occurs with the tag cloud on a person's profile, where typically a list view is used, i.e., it is not as critical or common for a single user has tons of tags where the tags have to be viewed as 'cloud'
The WebSphere Portal navigation is not displaying on the IBM Connections page
The WebSphere Portal navigation does not display on some browsers if you log in to WebSphere Portal using an unsecure port. To resolve this issue, log in to WebSphere Portal using the secure port.
The Profiles portlet within WebSphere Portal is separate from the Profiles in IBM Connections
A user has to update and maintain both Profiles. Updates to the WebSphere Portal Profile do not get reflected in the IBM Connections Profile.
Tagging on IBM Connections Files and Profiles Integration Pack
If you tagged content on the files and profiles pages, you will not be able to see them in the Portal tag cloud. In order to import Connections tags into Portal, you are required to use a full version of Connections 4
Receive error when trying to access the Profile from the Person Card
You receive a message that the UID is null or undefined. The Profile portlet only supports the Business Card format from IBM Connection. It also supports systems that have the email setting available for the user profiles.
Selecting Cancel button or Applications Access tab takes you to the IBM Connections login page
You log in as a user and select the Email Preferences. If you click Cancel or the Applications Access tab, you are taken to the IBM Connections login page. This page displays because the WAI script has not run. You must log in to IBM Connections to access the Connections information. Similarly, if you try to access Portal information, before the WAI script runs, you must log in to Portal.
Permission problems when applying software maintenance
Installation Manager is installed and must be run as root, however the java processes are configured to run as the virtuser OS user . If the maintenance being applied will restart the java processes, problems may occur with the service, related to file permissions and ownership. To workaround this, temporarily modify the WebSphere processes Run As settings. From the WebSphere Administrative Console, select the Java and Process Management -> Process Definition -> Process Execution -> Run As User, and remove the virtuser entry. Depending on the pattern type, you may have to adjust the individual application server setting, or, for cluster patterns, on the Dmgr process. A restart is required.
After installation, revert the WebSphere administrative changes, and ensure the directory structure, including any new or updated files are owned by virtuser. For example: chown -R virtuser:users /opt/IBM/WebSphere
IWD or PureApp limitations
Some problems were uncovered during testing on current IWD and PureApp firmware. These will be fixed in future fixpacks of that firmware, and workarounds are listed if possible.
Error importing Portal patterns using importPattern.py
The IWD and PureApp command line interface includes an importPattern.py to import all the artifacts of the Portal patterns. This script allows the specification of a local directory, or a tgz file in the -s parameter. There is a known problem when using the importPattern.py and specifying a tgz or tar file. The workaround is to extract the package as described in the Adding the OVA to IWD and PureSystems section.
IWD Pattern Editor Problems on Windows XP clients with Internet Explorer 8.0
Various problems, such as obsolete content, disappearing parts, etc occur when interacting with the IWD pattern editor.
Pattern Editor "order" is not honored
When creating a multi-node cluster portal pattern in the PureApp Pattern Editor, the default order shows the HTTP Server starting last, as desired, but the virtual machine history shows the HTTP Server VM starting before the Secondary portal part. A workaround is to explicitly reposition the HTTP Server part as last in the ordering list
Unicode values for Cell and Node names cause instance failure
When deploing an IWD pattern, specifying Unicode characters for the Cell and/or Node names cause problems during instance startup and the system in not correctly initialized.
Warning message when placing parts on a pattern
If you add the Portal Part to a blank pattern before the DMGR part, a warning message indicating "There are no custom nodes federated to the deployment manager",even after the DMGR node is added. Workaround is to remove all the parts and begin the pattern with the DMGR part