Multiple profile support

Multiple profile support

Overview
WebSphere Portal creates an application server configuration profile to represent its application server configuration, such as...

datasource definitions
web application and portlet deployments
JVM configuration

A configuration profile represents the full configuration of a single portal instance. Multiple profiles give you the ability to have multiple, independently configured portal instances running from the same installation. Before WebSphere Portal v7, there was only one configuration profile per installation, which was typically named wp_profile.
Start in WebSphere Portal v7. it is possible to create additional profiles in addition to the default profile, which is useful in the following popular scenarios:

Reuse a single installation for multiple independent portal instances, such as for various test or development efforts.

Recover from a configuration problem by deleting the current profile and re-creating it without having to re-install the product.

Create custom profiles to expand a cluster's capacity without having to manage the extra, nonessential resources of a regular standalone instance.

Update a Deployment Manager profile to handle portal servers and thus avoid all the manual preparation steps.
The following different profile types can be generated:

Profile Description
portal.default Holds a standalone portal server in the captured configuration. May be used as a standalone server or after the federation as a base for a portal cluster.
managed.portal Custom profile enhanced with the portal run time environment. Does not contain any servers. Main purpose is as a run time environment for additional cluster members. After federation the standard portal tasks can be used to create a portal server cluster member from an existing cluster template.
management.portal.augment Created by augmenting a standard dmgr profile. The resulting profile holds a dmgr prepared for use with portal. It can be used to federate the other portal profiles right away without the need for the additional manual steps. Because the dmgr is often located on different hardware, there is the possibility to move this augmentation template to another installation and execute it there.

Search Collection and Multiple Profiles

When you run the enable-profiles or replace-profiles tasks, all existing Search collections are captured in the profile template. The Search functionality does not support sharing Search collections between multiple profiles. Before running the enable-profiles or replace-profiles tasks, you should either delete all search collections, including the default Search collections to avoid search errors when you create the additional profiles. You can use the back up and restore procedures to preserve the search collections on the original profile or you can use the following export and import steps:

Export the existing search collections.

Remove the existing search collections.

If you installed WebSphere Portal as a non-root user, to modify permissions for the Portal Server directory...
chmod -R g+rwx /portal_server_root

Run the enable-profiles or replace-profiles configuration task to capture the Portal configuration in the profile template.

Import the saved search collections on the original profile.

Create new profiles using the profile templates; default search collections will be automatically created in the new profile.

Run the chmod -R g+rx /portal_server_root task to restore permissions to the Portal Server directory.
To share search collections between multiple Portal server instances, such as in a clustered or Portal Farm environment, then configure a remote search server to support the sharing of the search collections.

Special considerations for cluster configurations
As a best practice, you should manage all maintenance at the cluster level. That means that during maintenance application to a cluster, the entire cluster should be taken out of service, so that cluster-wide changes can take effect without affecting user traffic or potentially causing synchronization conflicts between cell managed resources, like enterprise applications and portlets, and the product binary files in the local file system. In a continuous availability environment, multiple clusters might be necessary, to allow traffic to continue to one cluster while another is being serviced.
Maintain a WebSphere Portal installation with multiple profiles involves applying maintenance to the product binary files as well as applying maintenance to each profile instance. It is important that all profile instances and the WebSphere Portal product binary files are updated at the same time to avoid conflicts. If one of the profiles on a particular installation belongs to a cluster, then whenever that cluster is updated, the shared WebSphere Portal product binary files and all other profiles on the system must be updated as well to maintain synchronization.
Therefore, in the event that multiple portal profiles using a single set of product binary files are used as part of a cluster configuration, it is strongly recommended that all profiles sharing the same product binary files belong to the same cluster to stay consistent with the best practice of applying maintenance at the cluster boundary.

Parent
Plan to install WebSphere Portal

Related tasks
Support multiple profiles
Create multiple profiles on AIX
Create multiple profiles on IBM i
Create multiple profiles on Linux
Create multiple profiles on Solaris
Create multiple profiles on Windows
Portal farm considerations

+
Search Tips | Advanced Search

Profile	Description
portal.default	Holds a standalone portal server in the captured configuration. May be used as a standalone server or after the federation as a base for a portal cluster.
managed.portal	Custom profile enhanced with the portal run time environment. Does not contain any servers. Main purpose is as a run time environment for additional cluster members. After federation the standard portal tasks can be used to create a portal server cluster member from an existing cluster template.
management.portal.augment	Created by augmenting a standard dmgr profile. The resulting profile holds a dmgr prepared for use with portal. It can be used to federate the other portal profiles right away without the need for the additional manual steps. Because the dmgr is often located on different hardware, there is the possibility to move this augmentation template to another installation and execute it there.