Preparing the system for multiple profile support on Solaris

IBM® WebSphere® Portal provides several profile templates that you can use to create a new WebSphere Portal profile or to augment an existing profile with WebSphere Portal. To use these profile templates, you must first run the enable-profiles task to configure the profile templates, register these templates with IBM WebSphere Application Server, and save the current WebSphere Portal baseline configuration. The baseline configuration is provided in the form of a configuration archive (CAR) that is created by exporting the contents of an existing profile. You can create the CAR any time, such as immediately after the initial installation or after the original portal is fully configured with security, database, basic application deployment, and server tuning.

Before you begin

Before creating new profiles, you must delete any existing search collections.

About this task

WebSphere Application Server uses the wsadmin scripting interface to support the CAR creation. WebSphere Portal provides a configuration task that creates the CAR and also captures additional portal-specific files that must be kept with the CAR. The task also places the CAR and any associated files in the correct directory.

Many portal customizations, such as new pages, blogs, and wikis, are stored in the WebSphere Portal release database, which uses the Derby database after the initial installation. Any customizations made to the Derby database prior to running the enable-profiles task are included in the additional profiles created later. However, if you complete a database transfer to set up the release database on an external server before running the enable-profiles task, then any customizations made between the transfer and when the enable-profiles task is run are NOT picked up by additional profiles. Therefore, you should complete all customizations that you want included on the additional profiles before transferring your release database domain to an external database server.

Restriction: Your environment MUST be a stand-alone profile. If you have a node federated to a Deployment Manager, you must remove the node from the cell. If you have a web server node, you must remove the node before running enable-profiles.
Restriction: Search Collections cannot be shared between multiple profiles. Before running enable-profiles, remove existing search collections from the default profile. You can re-create the search collections after you run enable-profiles.

Complete the following steps to prepare the system for multiple profile support:

Procedure

  1. If you installed WebSphere Portal as a non-root user, run the chmod -R u+rwx PortalServer_root/ task to modify permissions for the Portal Server directory.
  2. Run the ./ConfigEngine.sh enable-profiles -DWasPassword=password task, from the wp_profile_root/ConfigEngine directory of the configuration profile whose configuration will form the basis for the portal profile template, to create the CAR. The Portal.car file is saved to the PortalServer_root/profileTemplates/default.portal/configArchives directory.
    Type 4 database drivers only: If you configured WebSphere Portal for a remote database and placed your database drivers inside of the wp_profile_root/PortalServer directory, they are included in the configuration archive file that is created when running the enable-profiles script.
  3. Run the chmod -R u+rx PortalServer_root/ task to restore the non-root permissions to the Portal Server directory.

What to do next

After completing the initial profile template generation with your required configuration, you should only make further customization changes to the wp_profile directory that are intended to be included in all additional Portal profiles. This approach allows the portal profile template configuration to be immediately updated after applying maintenance, because it will already contain the required configuration to be saved with the Portal profile templates.