+

Search Tips   |   Advanced Search

Cumulative fix instructions: Cluster 9.5


Maintain 24x7 operation during the upgrade process

To preserve current user sessions during the upgrade process, verify distributed sessions are enabled. This allows recovery of user session information when a cluster node is stopped for maintenance. Alternatively, use monitoring to determine when all (or most) user sessions on a cluster node have completed, then stop the cluster node prior to the for upgrade


Limitations on 24x7 maintenance

  1. The 24x7 Single cluster upgrade is only supported on a Rendering environment, with no deployments or authoring being performed during the upgrade process.

    Typical authoring or deployment tasks that must NOT be performed during the upgrade window:

    • Deploy portlets
    • Execute XMLAccess
    • Author, modify, delete content
    • Run ConfigEngine
    • Deploy PAAs
    • Import or Export libraries
    • Use the WAS AdminConsole or wsadmin tooling to deploy or modify configuration or code
    • Use the Portal Admin portlets to make changes like delete a page
    • Use any WCM system task like the workflowchecker or member fixer
    • Change WebDAV resources like the theme
    • Modify personalization rules
    • Create or Delete Virtual Portals
    • Perform JCR Search crawling. HCL recommends disabling textsearch on rendering systems during upgrade.
    • New features introduced with the Cumulative fix should not be enabled or leveraged until all cluster members have been upgraded to the CF

  2. If we have not implemented horizontal scaling and have implemented only vertical scaling in the environment such that all cluster members reside on the same node, the cumulative fix installation process will result in a temporary outage for end users due to a required restart. In this case, we will be unable to upgrade while maintaining 24x7 availability.

  3. For a single local Web server in the environment, maintaining 24x7 availability during the cluster upgrade may not be possible since we might be required to stop the Web server while applying corrective service to the local WebSphere Application Server installation.

  4. When installing the cumulative fix in a clustered environment, the portlets are only deployed when installing the cumulative fix on the primary node. The cumulative fix installation on additional (also known as secondary) nodes simply synchronizes the node with the deployment manager to receive updated portlets. During the portlet deployment on the primary node, the database will be updated with the portlet configuration. This updated database, which is shared between all nodes, would be available to additional nodes before the additional nodes receive the updated portlet binary files.

    It is possible that the new portlet configuration will not be compatible with the previous portlet binary files, and in a 24x7 production environment problems may arise with anyone attempting to use a portlet that is not compatible with the new portlet configuration. Therefore HCL recommends that we test our portlets before upgrading the production system in a 24x7 environment to determine if any portlets will become temporarily unavailable on additional nodes during the time between the completion of the cumulative fix installation on the primary node and the installation of the cumulative fix on the additional node.

  5. To maintain 24x7 operations in a clustered environment, it is required that you stop HCL WebSphere Portal on one node at a time and upgrade it. It is also required that during the upgrade of the primary node, you manually stop node agents on all other cluster nodes that continue to service user requests. Failure to do so may result in portlets being shown as unavailable on nodes having the node agent running.

When rolling back of the cumulative fix in a clustered environment, the portlets are only redeployed when roll back of the cumulative fix is on the primary node. The cumulative fix roll back on additional nodes simply synchronizes the node with the deployment manager to receive updated portlets. During the portlet redeployment on the primary node, the database will be updated with the portlet configuration, which would be available to additional nodes before the additional nodes receive the updated binary files, since all nodes share the same database. HCL recommends that you test our portlets before rolling back on the production system in a 24x7 environment because the possibility of such incompatibility might arise if the previous portlet configuration is not compatible with the new portlet binary files.

Unless we are migrating from a previous release or plan to add this node to an existing cluster, create the Portal profile before applying the cumulative fix. If you did not do this during the initial installation, we can use the Configuration Wizard to do so now. Portal v8.5 CF12 or later introduces support for JDK8. However, if we plan to use JDK 8 with our profile, first create the profile using JDK 7 and then upgrade to JDK 8 after applying the cumulative fix.

In Portal v8.5 CF12 or later, the blacklist settings have become more restrictive. For inquiries, go to HCL Software Support page. Space RequirementsEnsure that enough disk space is available in the following directories:


Review CF best practices

Go to the HCL Software Support page for Portal Upgrade Best Practices.


Disable syndication

HCL recommends that servers utilizing syndication have associated syndicators and subscribers disabled prior to installing the cumulative fixpack. Otherwise syndication updates that run during install may clash with install modifications and can cause the CF update to fail.

Syndicators and subscribers can be disabled by editing them in the syndication administration portlet. Go to the Syndicators and Subscribers topic pages in the HCL WebSphere Portal v8.5 product documentation for more information. Syndication should then be re-enabled after the update is complete. Alternatively, the following ConfigEngine tasks have also been integrated into CF09 or later to globally disable and enable syndication (These tasks can be used in place of the manual updates linked above:


Turn off search crawlers

HCL recommends that any search crawlers are disabled before applying the CF. If a CF is applied at the same time the crawler is running, this may corrupt the search collection. The search crawler should be restarted after the CF update is complete.


Back up the Installation Manager data

Backup the contents of the IBM Installation Manager data directory on the server we are upgrading in the event you lose connection during the upgrade, as this could corrupt the data directory. The default locations of these directories are:

See Back up and restore Installation Manager


Known Issues

Review the Known issues for combined cumulative fix topic page to be aware of any known issues for the HCL WebSphere Portal v9.5 CF releases.


Review supported hardware/software requirements

For Portal v8.5 CF08 or later, the minimum recommended WebSphere Application Server level is at least WAS 8.5.5.6 with the corresponding JDK level applied.

Review theSupported hardware and software requirements article for this cumulative fix. If necessary, upgrade all hardware and software before applying this cumulative fix, including interim fixes required for WebSphere Application Server.

Note: Ensure that the optional WebSphere Application Server feature "EJBDeploy tool for pre-EJB 3.0 modules" is installed.


Check fixes installed on the system

All temporary or interim fixes on the system must be removed before installing this cumulative fix.

Also check whether the fixes installed on the system are included in the list of fixes provided in this cumulative fix. If we have temporary or interim fixes on the system that are not included in this cumulative fix then contact HCL Software Support for an updated version of those fixes or for more information.


Special instructions pertaining to HCL WebSphere Portal Patterns

Please note: These instructions are highlighted in this section but should be taken in the context of the rest of this readme. For each step, assure that we have read thru this readme and are taking all other documentation into account. If the Portal server default profile (wp_profile) directory is owned by a different OS user than the default binary directory (PortalServer), extra manual steps are needed before running Installation Manager to update to the cumulative fix.

  1. Run the chown command to change ownership of the (wp_profile) directory to the same owner as PortalServer:

      chown -R OSUser:admingroup /opt/IBM/WebSphere/wp_profile.

  2. Run the Installation Manager update for the Portal v8.5 CF as the user that owns PortalServer.

  3. Run the chown command to change ownership of the (wp_profile) tree back to the original owner:

      chown -R Original-OSUser:admingroup /opt/IBM/WebSphere/(wp_profile)

  4. Run applyCF.sh as portaladmin the same owner as (wp_profile)


Ensure wkplc properties files are correct

The HCL WebSphere Portal upgrade will run several ConfigEngine scripts. These scripts depend on the wkplc.properties being up to date and accurate, particularly with the password properties. If we are using multiple profiles, verify that the information in each profile is correct.

  1. Edit the <wp_profile root>/ConfigEngine/properties/wkplc.properties file and ensure the following values are set correctly:

      WasRemoteHostName=<the hostname of WAS instance>
      WasSoapPort=<the soap port of WAS instance>
      WasUserid=<WAS admin user>
      WasPassword=<WAS admin pwd>
      PortalAdminId=<the Portal Admin ID>
      PortalAdminPwd=<the Portal Admin password>
      WpsHostName=<Your Portal hostname>
      WpsHostPort=<The port we use to access Portal>
      WpsContextRoot=<the Portal context root>

  2. Edit the <wp_profile root>/ConfigEngine/properties/wkplc_dbdomain.properties file and ensure the following values are set correctly:

      release.DbPassword=<the database user password>
      community.DbPassword=<the database user password>
      customization.DbPassword=<the database user password>
      jcr.DbPassword=<the database user password>
      likeminds.DbPassword=<the database user password>
      feedback.DbPassword=<the database user password>

  3. Edit...

      <wp_profile root>/ConfigEngine/properties/wkplc_comp.properties

    ...and ensure the following values are set correctly:

      XmlAccessHost=<the Portal hostname>
      XmlAccessPort=<the port we use to access Portal>

If the server is configured with database runtime users, for example...

...ensure to set their password values correctly as well, for example, in...


Unix, Linux, Windows, and IBM i:

The update process removes plain text passwords from the wkplc*.properties files. To keep these passwords in the properties files, include the following line in the wkplc.properties file: PWordDelete=false


Multiple profile considerations

Verify that all of our profiles are at the same level before starting the upgrade or rollback. All profiles that share the same Portal installation directory (multiple profile option) must be manually upgraded after the IBM Installation Manager update completes. See the "Additional configuration steps" for details.


Non-root considerations

In Unix/Linux environments, install the cumulative fix as the same user which we used to install HCL WebSphere Portal originally. This could be either root or a non-root user. To use a non-root user, ensure the following conditions are met:

To open a command-line utility to run Installation Manager commands:

  1. Open a command line window.

  2. To check your current umask setting:

      umask

  3. If necessary, to set the umask:

      umask 0022


Anti-virus and file indexing software considerations (Windows only)

As part of the CF upgrade process, new files will be created in the WebSphere installation directory, as well as the user's temp directory. Anti-viruses and file indexing software (like Google Desktop) have been known to lock newly created files as they are being scanned, which can interfere with the upgrade process. If you find such software is interfering with the Portal CF upgrade process contact the software vendor for further assistance. If possible, HCL recommends to exclude the WebSphere installation directory and the user's temp directory from being scanned by this software during the upgrade. Or we can stop /disable these tools for the duration of the upgrade, and re-enable them after the upgrade completes. However HCL does not recommend such modifications and instead recommends to contact the software vendor for further assistance.


Special note for customers using WAS 8.5.5.14

Support for WebSphere Application Server v8.5.5.14 will be added in Portal Cumulative Fix 16. If we need to apply Portal Cumulative Fix 15 or earlier to a WAS v8.5.5.14 installation, we will need to perform an additional manual step during the upgrade. After running Installation Manager to install the new Portal code but before running the applyCF.sh or applyCF.bat command to update the Portal profile, perform these steps:

  1. cd /opt/IBM/WebSphere/ConfigEngine

  2. Make a backup copy of the ConfigEngine script. This file is named ConfigEngine.bat for Windows and ConfigEngine.sh for all other platforms.

  3. Make sure our user has write permissions for the script file and open it in a text editor.

  4. Look for the text EJBDEPLOY_JAVA_HOME in the script. If we do not find it, no further action is necessary and we can continue with the installation. If we do find it, delete every line that contains the text EJBDEPLOY_JAVA_HOME anywhere in the line. (There should be 3 such lines in the .sh script and 2 lines in the .bat script.)

  5. Save the file.

You may now continue with the installation of the Portal CF.


Download the cumulative fix

If we are installing the cumulative fix using a live repository, then you do not need to download the cumulative fix to the server. To download the cumulative fix, then we can follow these steps.

  1. Log on to HCL Software Licensing Portal or HCL Software Licensing Portal and download the latest zip file that corresponds to the installation on the system.

  2. Create a directory and extract the zip file(s) into this directory. Inside the zip file is a readme file, sample response files (Server and Express only), and the actual cumulative fix file itself.

  3. Create a subdirectory and extract the appropriate WP8500CFnn_ zip file to this directory. The extraction results in a repository.config file used by IBM Installation Manager during the update.


Disable automatic synchronization and stopping the node agents

Ensure that automatic synchronization is disabled and that all node agents are stopped for all Portal clusters in the cell. When the automatic synchronization is enabled, the node agent on each node automatically contacts the deployment manager at startup and at every synchronization interval to attempt to synchronize the node's configuration repository with the master repository managed by the deployment manager.

  1. In the administrative console for the deployment manager, select System administration then Node agents in the navigation tree.

  2. Click nodeagent for the required node.

  3. Click File Synchronization Service.
  4. Uncheck the Automatic Synchronization check box and uncheck the Enable service at server startup check box on the File Synchronization Service page to disable the automatic synchronization feature and synchronization service at server startup and then click OK.

  5. Repeat these steps for all other nodes to be upgraded.

  6. Click Save to save the configuration changes to the master repository.

  7. Select System administration then Nodes in the navigation tree.

  8. Select all nodes that are not synchronized, and click on Synchronize.

  9. Select System administration then Node agents in the navigation tree.

  10. For the primary node and all additional nodes in all Portal clusters in the cell, select the node agents and click Stop. If we do not stop the node agents the cumulative fix configuration might fail.


Upgrading the primary node

There are several different methods to install the cumulative fix, and they are:

Start with the step "Stopping IP traffic" then choose one method that is available for the system. Follow the detailed steps for that option, and then proceed with the "Additional configuration steps."

Note: Do not attempt to combine the steps for primary and secondary nodes. The update must be performed first on the primary node and then on the additional nodes, according to the following instructions. When instructed to stop or start the HCL WebSphere Portal server, stop or start all Portal server instances including vertical cluster members on the node. Stopping IP traffic (Required only if following the 24x7 single cluster upgrade.)

To stop traffic to the nods:

  1. In the Deployment Manager administrative console, to obtain a view of the collection of cluster members. click...

      Servers > Clusters > WebSphere application server clusters > cluster_name > Cluster members

  2. Locate the cluster member we are upgrading and change the value in the Configured weight column to zero. NOTE: Record the previous value to restore the setting when the upgrade is complete.

  3. Click Update to apply the change.

Note that the web server plug-in will check periodically for configuration updates based on the value of Refresh Configuration Interval property for the Web server plug-in (default value is 60 seconds). We can check this value on the Deployment Manager administrative console by selecting...'

If automatic propagation of the plug-in configuration file is enabled on the web server(s) disable it from the Deployment Manager administrative console by going to:

...and unchecking...

Once disabled, we will need to manually generate and/or propagate the plugin-cfg.xml file to the Web server.

  1. Stop any active application servers and node agents using the stopServer and stopNode commands. To see which application servers are active...

      cd <wp_profile>/bin directory ./serverStatus

    and...

      cd <cw_profile>/bin
      /serverStatus

    If the Deployment Manager is installed on the same server as one of the cluster nodes, also stop the Deployment Manager using the stopManager command from the <dmgr>/bin directory.

      ./serverStatus.sh -all

  2. Launch the IBM Installation Manager that was used to install HCL WebSphere Portal v8.5.

  3. Use Installation Manager, click File > Preferences.

  4. Go to the Repositories panel and click "Add Repository".

  5. Navigate to the repository.config file mentioned earlier and select it.

  6. Select Update and follow the prompts to update HCL WebSphere Portal.

  7. After installation completes, proceed with the "Additional configuration steps."
Use a command line (available on Windows, Linux, and Unix operating systems)

  1. If we are running an external web server, stop the web server.

  2. Stop any active application servers and node agents using the stopServer and stopNode commands. To see which application servers are active, use the serverStatus command from the <wp_profile>/bin directory and again from the <cw_profile>/bin directory. If the Deployment Manager is installed on the same server as one of the cluster nodes, also stop the Deployment Manager using the stopManager command from the (dmgr)/bin directory.

      ./serverStatus.sh -all

  3. Open a command window and switch to the eclipse/tools subdirectory of Installation Manager. By default, this is:

      /opt/IBM/InstallationManager/eclipse/tools

  4. If we are installing the cumulative fix on HCL WebSphere Portal Express, skip to Step 5. Otherwise, run the following command to launch the installation program of Installation Manager. 

      ./imcl install com.ibm.websphere.PORTAL.SERVER.v85 \
     -repositories <fullpath/to/repository.config> \
     -installationDirectory <portal_server_root>  \
     -acceptLicense

  5. For HCL WebSphere Portal Express only (IBM i must use silent or console mode method): Launch the installation program of Installation Manager. p>In Linux:

      ./imcl install com.ibm.websphere.PORTAL.EXPRESS.v85 \ -repositories (fullpath/to/repository.config) \ -installationDirectory (portal_server_root) \ -acceptLicense

  6. After installation completes, proceed with the "Additional configuration steps."

Use silent mode installation (available on Windows, Linux, Unix, and IBM i operating systems)

  1. Stop any active application servers and node agents using the stopServer and stopNode commands.

    To see which application servers are active:

      <wp_profile)/bin/ serverStatus -all
      <cw_profile>/bin/serverStatus -all

    If the Deployment Manager is installed on the same server as one of the cluster nodes, also stop the Deployment Manager:

      <dmgr>/bin/stopManager

  2. cd /opt/IBM/InstallationManager/eclipse/tools

  3. Update the sample response file packaged with the cumulative fix level according to the comments in the file. We can also record a response file to use to install the fix in silent mode.

    Do note that the feature set listed in the response file must match the feature set we have installed. We cannot add or remove features during the cumulative fix update. The feature set listed in the sample response file is features='ce.install,portal.binary,portal.profile'. If we do not have any profiles on this node (because we are in the process of migration from a previous version of HCL WebSphere Portal, or installing an additional node for a cluster, or creating multiple profiles, or you originally installed HCL WebSphere Portal v8.5 as a binary install), then you should remove the 'portal.profile' feature from the features='ce.install,portal.binary' list.

  4. Install in silent mode:

      imcl -acceptLicense -input <Full_path_to_response_file> -log (Full_Path_to_a_log_file) -showProgress

  5. After installation completes, proceed with the "Additional configuration steps."

Use Console Mode installation (available on Windows, Linux, Unix and IBM i operating systems)

  1. Stop any active application servers and node agents using the stopServer and stopNode commands. To see which application servers are active, use the serverStatus command from the (wp_profile)/bin directory and again from the (cw_profile)/bin directory. If the Deployment Manager is installed on the same server as one of the cluster nodes, also stop the Deployment Manager using the stopManager command from the (dmgr)/bin directory.

      ./serverStatus.sh -all

  2. Open a command window and

      cd /opt/IBM/InstallationManager/eclipse/tools

  3. Start the IBM Installation Manager in console mode.

      ./imcl -c

  4. Add the repositories.

  5. Select Update and follow the prompts to update HCL WebSphere Portal.

  6. After installation completes, proceed with the "Additional configuration steps".
To add the repositories:


Additional configuration steps

For any profiles the following configuration steps are mandatory.

If we do not have any profiles at this point (because we are in the process of migration from a previous version of HCL WebSphere Portal), no additional configuration steps are necessary and we can continue with the "Restoring IP traffic" steps described below.

Note: The following configuration steps should be run as the user who normally administers the Portal Server, which may or may not be the same user who runs the installation program.

Use the following commands to update all profiles. These steps must be repeated for each profile, if multiple profiles exist. All cluster members and all profiles that share the same Portal installation directory (multiple profile option) must be updated to the same level to complete the CF installation.

Optional Note To skip regeneration of the profile template, add the following flag to the CF update command:

If an updated template is needed at a later time, this command can be run to do so at any time:

  1. Ensure the nodeagent and HCL WebSphere Portal servers are stopped on the profile you intend to upgrade. The Deployment Manager must be started.

  2. On the Farm Master Server execute the following command from within the path of the profile to configure: Do not that if we are installing the CF on an empty portal, see the Special Considerations below before running applyCF.

      <profile_root>/PortalServer/bin/applyCF.sh -DPortalAdminPwd=<password> -DWasPassword=<password>

    If the applyCF command fails for any reason, check the error logs and correct error conditions before re-running.

  3. On the Farm Support Server execute the following command from within the path of the profile to configure.

Note: If the Farm Support Server only has read-only access to the Portal Binaries use the -DSharedBinaries=true flag with the applyCF command.

If the applyCF command fails for any reason, check the error logs and correct error conditions before re-running. Special Consideration for empty portals If we are installing the CF on an empty portal then extra steps are required to avoid upgrade errors.

  1. If we have created any custom content on top of the empty portal, first use XMLAccess to export the Portal content. From the wp_profile_root/PortalServer/bin directory run:

      xmlaccess.bat/sh -user Portal_admin_user -password Portal_admin_password -url http://<myhost>:<port>/wps/config -in <Portal home>/doc/xml-samples/Export.xml -out result.xml

    Upgrade the portal profile to the new CF level. Because many of the expected artifacts will not exist in an empty portal, define the "isEmptyPortal" property when performing this step:

      <profile_root>/PortalServer/bin/applyCF.sh -DisEmptyPortal=true -DPortalAdminPwd=<password> -DWasPassword=<password>

    If the applyCF command fails for any reason, check the error logs and correct error conditions before continuing. Following a successful run of the applyCF script, re-run the empty-portal task to remove Portal artifacts that were reintroduced with the CF, as these may cause runtime errors.

      <profile_root>/ConfigEngine/ ./ConfigEngine.sh empty-portal -DWasPassword=<password> -DPortalAdminPwd=<password>

  2. If you exported custom content in step #1 above, we can now use XMLAccess to reimport that content.

      cd wp_profile_root/PortalServer/bin directory
      xmlaccess.bat/sh -user <Portal_admin_user> -password <Portal_admin_password> -url http://<myhost>:<port>/wps/config -in result.xml -out importResults.xml

Restoring IP traffic (Required only if following the 24x7 single cluster upgrade)

To restore traffic to the upgraded node:

  1. In the Deployment Manager administrative console, click Servers > Clusters > WebSphere application server clusters > cluster_name > Cluster members to obtain a view of the collection of cluster members.

  2. Locate the cluster member you upgraded and change the value in the Configured weight column back to the original value.

  3. Click Update to apply the change.
If you previously disabled automatic propagation of the Web server(s), re-enable it now using the Deployment Manager administration console by going to Servers > Server Types > Web Servers > web_server_name > Plug-in Properties and checking Automatically propagate plug-in configuration file. If we are not using automatic generation and propagation for the Web server plug-in, manually generate and/or propagate the plugin-cfg.xml file to the Web servers.


Upgrading additional nodes

There are several different methods to install the cumulative fix, and they are:

Start with the step "Stopping IP traffic for additional nodes" then choose one method that is available for the system. Follow the detailed steps for that option, and then proceed with the Additional configuration steps.

Note: Do not attempt to upgrade additional nodes until after completing the upgrade of the primary node. The update for the primary must be performed and completed before the upgrade of any additional nodes. Additional node upgrades can be performed sequentially or in parallel. Update the additional nodes according to the following instructions. When instructed to stop or start the HCL WebSphere Portal server, stop or start all Portal server instances including vertical cluster members on the node. Stopping IP traffic for additional nodes (Required only if following the 24x7 single cluster upgrade)

To stop traffic to the node:

  1. In the Deployment Manager administrative console, click Servers > Clusters > WebSphere application server clusters > cluster_name > Cluster members to obtain a view of the collection of cluster members.

  2. Locate the cluster member we are upgrading and change the value in the Configured weight column to zero. NOTE: Record the previous value to restore the setting when the upgrade is complete.

  3. Click Update to apply the change.

Note that the web server plug-in will check periodically for configuration updates based on the value of Refresh Configuration Interval property for the Web server plug-in (default value is 60 seconds). We can check this value on the Deployment Manager administrative console by selecting...'

Once automatic plug-in generation and propagation is disabled, we will need to manually generate and/or propagate the plugin-cfg.xml file to the Web servers. Use a Graphical User Interface on additional nodes (available on Windows, Linux, and Unix operating systems)

  1. Stop any active application servers and node agents using the stopServer and stopNode commands. To see which application servers are active, use the serverStatus command from the (wp_profile)/bin directory and again from the cw_profile>/bin directory. If the Deployment Manager is installed on the same server as one of the cluster nodes, also stop the Deployment Manager using the stopManager command from the (dmgr)/bin directory.

      >Unix/Linux: ./serverStatus.sh -all
  2. Launch the IBM Installation Manager that was used to install HCL WebSphere Portal v8.5
  3. Use Installation Manager, click File > Preferences.

  4. Go to the Repositories panel and click "Add Repository".
  5. Navigate to the repository.config file mentioned earlier and select it.

  6. Select Update and follow the prompts to update HCL WebSphere Portal.

  7. After installation completes, proceed with the "Additional configuration steps on additional nodes."
Use a live repository via the Graphical User Interface on additional nodes (available on Windows, Linux, and Unix operating systems)

  1. Stop any active application servers and node agents using the stopServer and stopNode commands. To see which application servers are active, use the serverStatus command from the (wp_profile)/bin directory and again from the cw_profile>/bin directory. If the Deployment Manager is installed on the same server as one of the cluster nodes, also stop the Deployment Manager using the stopManager command from the (dmgr)/bin directory.

      ./serverStatus.sh -all

  2. Launch the IBM Installation Manager that was used to install HCL WebSphere Portal v8.5
  3. Use Installation Manager, click File > Preferences.

  4. Go to the Repositories panel and click Search service repositories during installation and updates. Click apply.

  5. Select Update and follow the prompts to update HCL WebSphere Portal.

  6. After installation completes, proceed with the "Additional configuration steps on additional nodes."
Use a command line on additional nodes (available on Windows, Linux, and Unix operating systems)

  1. Stop any active application servers and node agents using the stopServer and stopNode commands. To see which application servers are active, use the serverStatus command from the (wp_profile)/bin directory and again from the cw_profile>/bin directory. If the Deployment Manager is installed on the same server as one of the cluster nodes, also stop the Deployment Manager using the stopManager command from the (dmgr)/bin directory.

      ./serverStatus.sh -all

  2. Open a command window and switch to the eclipse/tools subdirectory of Installation Manager. By default, this is:

      /opt/IBM/InstallationManager/eclipse/tools

  3. If we are installing the cumulative fix on HCL WebSphere Portal Express, skip to step 5. Otherwise, run the following command to launch the installation program of Installation Manager. Do note that the commands are shown here on multiple lines for clarity, but the entire command must be entered on one line. Include quotation marks around file paths that include spaces.

      ./imcl install com.ibm.websphere.PORTAL.SERVER.v85 \ -repositories <fullpath/to/repository.config> \ -installationDirectory <portal_server_root> \ -acceptLicense

  4. HCL WebSphere Portal Express only (IBM i must use silent or console mode method): Launch the installation program of Installation Manager). Do note that the commands are shown here on multiple lines for clarity, but the entire command must be entered on one line. Include quotation marks around file paths that include spaces.

      ./imcl install com.ibm.websphere.PORTAL.EXPRESS.v85 \ -repositories <fullpath/to/repository.config> \ -installationDirectory <portal_server_root> \ -acceptLicense

  5. After installation completes, proceed with the "Additional configuration steps on additional nodes."

Use silent mode installation on additional nodes (available on Windows, Linux, Unix, and IBM i operating systems)

  1. Stop any active application servers and node agents using the stopServer and stopNode commands. To see which application servers are active, use the serverStatus command from the (wp_profile)/bin directory and again from the (cw_profile)/bin directory. If the Deployment Manager is installed on the same server as one of the cluster nodes, also stop the Deployment Manager using the stopManager command from the (dmgr)/bin directory.

      ./serverStatus.sh -all

  2. Open a command window and switch to the eclipse/tools subdirectory of Installation Manager. By default, this is:

      /opt/IBM/InstallationManager/eclipse/tools

  3. Update the sample response file packaged with the cumulative fix level according to the comments in the file. We can also record a response file to use to install the fix in silent mode.

    The feature set listed in the response file must match the feature set we have installed. We cannot add or remove features during the cumulative fix update. The feature set listed in the sample response file is:

      features='ce.install,portal.binary,portal.profile'

    If we do not have any profiles on this node (because we are in the process of migration from a previous version of HCL WebSphere Portal, or installing an additional node for a cluster, or creating multiple profiles, or you originally installed HCL WebSphere Portal v8.5 as a binary install), then you should remove the 'portal.profile' feature from the features='ce.install,portal.binary' list.

  4. Install in silent mode:

      imcl -acceptLicense -input <Full_path_to_response_file> -log <Full_Path_to_a_log_file> -showProgress

  5. After installation completes, proceed with the "Additional configuration steps on additional nodes."

Use Console Mode installation on additional nodes (available on Windows, Linux, Unix and IBM i operating systems)

  1. Stop any active application servers and node agents using the stopServer and stopNode commands. To see which application servers are active, use the serverStatus command from the (wp_profile)/bin directory and again from the (cw_profile)/bin directory. If the Deployment Manager is installed on the same server as one of the cluster nodes, also stop the Deployment Manager using the stopManager command from the (dmgr)/bin directory.

      ./serverStatus.sh -all

  2. cd /opt/IBM/InstallationManager/eclipse/tools

  3. Run the command to start the IBM Installation Manager in console mode. For Unix or Linux:

      /imcl -c

  4. Add the repositories.

  5. Select Update and follow the prompts to update HCL WebSphere Portal.

  6. After installation completes, proceed with the "Additional configuration steps".
To add the repositories:

  1. Enter P to go to the Preferences menu.

  2. Enter 1 to go to the Repositories menu.

  3. Enter D to add repositories.

  4. Type the path for the HCL WebSphere Portal v8.5 CF repository file.

  5. Enter A to apply your repositories and return to the Preferences menu.

  6. Enter R to return to the Main menu.


Additional configuration steps on additional nodes

For any profiles the following configuration steps are mandatory.

If we do not have any profiles at this point (because we are in the process of migration from a previous version of HCL WebSphere Portal), no additional configuration steps are necessary and we can continue with the "Restoring IP traffic" steps described below.

Note: The following configuration steps should be run as the user who normally administers the Portal Server, which may or may not be the same user who runs the installation program.

Linux, Unix, Windows or IBM i Use the following commands to update all profiles. These steps must be repeated for each profile, if multiple profiles exist. All cluster members and all profiles that share the same Portal installation directory (multiple profile option) must be updated to the same level to complete the CF installation.

Notes:

Optional Note To skip regeneration of the profile template, add the following flag to the CF update command:

If an updated template is needed at a later time, this command can be run to do so at any time:

  1. Ensure the nodeagent and HCL WebSphere Portal servers are stopped on the profile you intend to upgrade. The Deployment Manager must be started.
  2. Execute the following command from within the path of the profile to configure. Do note that if we are installing the CF on an empty portal, see the *Special Considerations* below before running applyCF.

      <profile_root>/PortalServer/bin/applyCF.sh -DPortalAdminPwd=<password> -DWasPassword=<password>

    Important: If the applyCF command fails for any reason, check the error logs and correct error conditions before re-running.

  3. Verify that the system is operational by entering the server's URL in a browser and logging in to browse the content.

Special Consideration for empty portals If we are installing the CF on an empty portal then extra steps are required to avoid upgrade errors.

  1. If we have created any custom content on top of the empty portal, first use xmlaccess to export the Portal content. From the wp_profile_root/PortalServer/bin directory run: 

      xmlaccess.bat/sh -user Portal_admin_user -password Portal_admin_password -url http://<myhost>:<port>/wps/config -in <Portal home>/doc/xml-samples/Export.xml -out result.xml
  2. Upgrade the portal profile to the new CF level. Because many of the expected artifacts will not exist in an empty portal, define the "isEmptyPortal" property when performing this step:

      <profile_root>/PortalServer/bin/applyCF.sh -DisEmptyPortal=true -DPortalAdminPwd=<password> -DWasPassword=<password>

    Important: If the applyCF command fails for any reason, check the error logs and correct error conditions before continuing.

  3. Following a successful run of the applyCF script, re-run the empty-portal task to remove Portal artifacts that were reintroduced with the CF, as these may cause runtime errors.

      <profile_root>/ConfigEngine/ ./ConfigEngine.sh empty-portal -DWasPassword=<password> -DPortalAdminPwd=<password>

  4. If you exported custom content in step #1 above, we can now use XMLAccess to reimport that content. From the wp_profile_root/PortalServer/bin directory run: 

            xmlaccess.bat/sh -user <Portal_admin_user>> -password <Portal_admin_password> -url http://<myhost>:<port>/wps/config -in result.xml -out importResults.xml
Restoring IP traffic (Required only if following the 24x7 single cluster upgrade.)

If we are using the Web server plug-in for load balancing, perform the following steps to restore traffic to the upgraded node:

  1. In the Deployment Manager administrative console, click Servers > Clusters > WebSphere application server clusters > cluster_name > Cluster members to obtain a view of the collection of cluster members.

  2. Locate the cluster member you upgraded and change the value in the Configured weight column back to the original value.

  3. Click Update to apply the change.
If we are not using automatic generation and propagation for the Web server plug-in, manually generate and/or propagate the plugin-cfg.xml file to the Web servers.


Finalizing the upgrade

    1. Re-enable automatic synchronization on all nodes in the cluster if you disabled it earlier.

    1. In the administrative console for the deployment manager, to enable the automatic synchronization feature select...

        System administration > nodeagent > File Synchronization Service > Automatic Synchronization (check box)

      Enable service at server startup check box to enable the synchronization service at server startup on the File Synchronization Service page and then click OK.

    2. Repeat these steps for all remaining nodes.

    3. Click Save to save the configuration changes to the master repository.

    4. Select System administration > Nodes in the navigation tree.

    5. Select all nodes that are not synchronized, and click on Synchronize.
    6. Select System administration > Node agents in the navigation tree.
    7. Select all node agents where automatic synchronization has been re-enabled and click Restart.

  1. If there is a custom theme that contains a static content WAR and the com.hcl.portal.resource.blacklist and com.hcl.portal.resource.whitelist context parameters have not yet been added to the web.xml file, go and log in to HCL Software Support to find detailed information associated with Security Bulletin: Fix Available for Security Vulnerability in HCL WebSphere Portal (CVE-2014-8912). The changes associated with this security bulletin (APAR PI47714) can cause custom themes to produce a lot of warning messages in the logs resulting in a significant performance penalty. The custom theme must be redeployed before the changes will take effect.

  2. If necessary, redeploy any customizations, including JSPs, to the WCM portlets (if using Web Content Manager), any other portlets, or any other Portal enterprise applications, if these were customized prior to installing the cumulative fix.

  3. If we have set up a remote search server or document conversion server for use with HCL WebSphere Portal v8.5, then whenever you apply a cumulative fix to the portal server, you should also apply the corresponding cumulative fix to the remote server. Refer to the HCL WebSphere Portal v8.5 combined cumulative fix instructions: remote search for the details of applying a cumulative fix to the remote server.

  4. Go and log in to HCL Software Support to find documentation to see if Configuration Changes and Options introduced in HCL WebSphere Portal v8.5 Combined Cumulative Fixes applies to the environment.

  5. If using HCL Web Content Manager and have installed any official extensions (such as the WCM Multilingual Solution (MLS) or WCM Social Media Publisher (SMP)), then run the following task to update them. This task needs to be run for primary and additional nodes.

      <profile_root>/ConfigEngine/ConfigEngine.sh action-update-wcm-extensions -DWasPassword=<password> -DPortalAdminPwd=<password>

    The task can be run even if we are not sure if you had the extensions enabled. To check if they were enabled the following tasks can be used:

    • For MLS use ConfigEngine.sh|bat action-is-wcm-mls-enabled
    • or SMP use ConfigEngine.sh|bat action-is-wcm-smp-enabled

  6. If you brought down the entire cluster to perform the upgrade (not maintaining 24 x 7 on a single cluster), and the automatic plug-in generation and propagation are disabled on the web server Plug-in properties, we will need to manually generate and/or propagate the plugin-cfg.xml file to the Web servers.

  7. Clear the browser cache.

  8. Go to Recommended Updates for HCL WebSphere Portal to review and apply any recommended fixes.

  9. Prior to CF07, it was recommended to set the DB2 database configuration parameter "dft_queryopt" to a value of 2 as this was tested to provide the best balance of query optimization time and query execution time for the SQL produced by the JCR. For CF07 or later, this recommendation has been changed to use a value of 5 in conjunction with the testing and changes made to the JCR and JCR schema. This setting is NOT updated automatically within the JCR Database Domain configuration as part of the CF07 (or later) upgrade. This can be done manually by customers by executing the following SQL against the JCR Domain Database:

      db2 update db cfg for JCRDBNAME using DFT_QUERYOPT 5

    ...Or it can also be done by running the following Config Engine Task:

      configure-jcr-db2-dft-queryopt


Before you begin roll back

The steps in these sections for rolling back the cumulative fix describe how to roll back from a successful update to a previous level. However, rolling back from a failed update does not guarantee return to a dependable state. When an update fails, it is advised that you fix the cause of the failure and try again for a successful update; to return to a previous level, we must depend on a system and database backup and restore.

Versions of Portal prior to CF12 do not support JDK 8. Therefore, if JDK 8 has been enabled in CF12 or later, the managesdk command must be used to switch back to JDK 7 or 7.1 before performing a rollback to CF11 or earlier. Limitations

Ensure wkplc properties files are correct for roll back The HCL WebSphere Portal roll back will run several ConfigEngine scripts. These scripts depend on the wkplc.properties being up to date and accurate on each node in the cluster, particularly with the password properties. If we are using multiple profiles, verify that the information in each profile is correct. These steps need to be performed on all nodes.

  1. Edit the <wp_profile root>/ConfigEngine/properties/wkplc.properties file and ensure the following values are set correctly: 

      WasRemoteHostName=<the hostname of the Dmgr>
WasSoapPort=<the soap port of the Dmgr>
WasUserid=<WAS admin user>
WasPassword=<WAS admin pwd>
PortalAdminId=<the Portal Admin ID>
PortalAdminPwd=<the Portal Admin password>
WpsHostName=<Your Portal hostname>
WpsHostPort=<The port we use to access Portal>
WpsContextRoot=<the Portal context root>

  2. Edit the <wp_profile root>/ConfigEngine/properties/wkplc_dbdomain.properties file and ensure the following values are set correctly: 

      release.DbPassword=<the database user password>
community.DbPassword=<the database user password>
customization.DbPassword=<the database user password>
jcr.DbPassword=<the database user password>
likeminds.DbPassword=<the database user password>
feedback.DbPassword=<the database user password>

  3. Edit the <wp_profile root>/ConfigEngine/properties/wkplc_comp.properties file and ensure the following values are set correctly: 

      XmlAccessHost=<the Portal hostname>
XmlAccessPort=<the port we use to access Portal>

Unix, Linux, Windows, and IBM i: The update process removes plain text passwords from the wkplc*.properties files. To keep these passwords in the properties files, include the following line in the wkplc.properties file: PWordDelete=false


Disable automatic synchronization and stopping the node agents for roll back

Ensure that automatic synchronization is disabled and that all node agents are stopped for all Portal clusters in the cell. When the automatic synchronization is enabled, the node agent on each node automatically contacts the deployment manager at startup and at every synchronization interval to attempt to synchronize the node's configuration repository with the master repository managed by the deployment manager.

  1. In the administrative console for the deployment manager, select System administration > Node agents in the navigation tree.

  2. Click nodeagent for the required node.

  3. Click File Synchronization Service.
  4. Uncheck the Automatic Synchronization check box and uncheck the Enable service at server startup check box on the File Synchronization Service page to disable the automatic synchronization feature and synchronization service at server startup and then click OK.

  5. Repeat these steps for all other nodes to be downgraded.

  6. Click Save to save the configuration changes to the master repository.

  7. Select System administration > Nodes in the navigation tree.

  8. Select all nodes that are not synchronized, and click on Synchronize.

  9. Select System administration > Node agents in the navigation tree.

  10. For the primary node and all additional nodes in all Portal clusters in the cell, select the node agents and click Stop. If we do not stop the node agents the cumulative fix configuration might fail.


Steps to roll back the Primary node

There are several different methods to roll back the cumulative fix, and they are:

Start with the step "Stopping IP traffic for roll back" then choose one method that is available for the system. Follow the detailed steps for that option, and then proceed with the Post Rollback Steps.

Note: Do not attempt to combine the steps for primary and secondary nodes. The roll back must be performed first on the primary node and then on the additional nodes, according to the following instructions. Stopping IP traffic for roll back (Required only if following the 24x7 single cluster roll back.)

If we are using the Web server plug-in for load balancing, perform the following steps to stop traffic to the node:

  1. In the Deployment Manager administrative console, click Servers > Clusters > WebSphere application server clusters > cluster_name > Cluster members to obtain a view of the collection of cluster members.

  2. Locate the cluster member we are downgrading and change the value in the Configured weight column to zero. Do record the previous value to restore the setting when the downgrade is complete.

  3. Click Update to apply the change.

Note that the web server plug-in will check periodically for configuration updates based on the value of Refresh Configuration Interval property for the Web server plug-in (default value is 60 seconds). We can check this value on the Deployment Manager administrative console by selecting...'

If automatic propagation of the plug-in configuration file is enabled on the web server(s) disable it from the Deployment Manager administrative console by going to...

...and unchecking...

Once automatic plug-in generation and propagation is disabled, we will have ot manually generate and/or propagate the plugin-cfg.xml file to the Web servers.

Use a Graphical User Interface to roll back (available on Windows, Linux, and Unix operating systems)

  1. Stop any active application servers and node agents using the stopServer and stopNode commands. To see which application servers are active, use the serverStatus command from the <wp_profile>/bin directory and again from the <cw_profile>/bin directory. If the Deployment Manager is installed on the same server as one of the cluster nodes, also stop the Deployment Manager using the stopManager command from the <dmgr>/bin directory.

      ./serverStatus.sh -all

  2. Launch the IBM Installation Manager that was used to install HCL WebSphere Portal v8.5.

  3. Select "Roll Back" on the Installation Manager main window and follow the prompts to roll HCL WebSphere Portal back to the desired level.

  4. After rollback completes, proceed with the"Post Rollback Steps."
Use a command line to roll back (available on Windows, Linux, and Unix operating systems)

  1. Stop any active application servers and node agents using the stopServer and stopNode commands. To see which application servers are active, use the serverStatus command from the <wp_profile>/bin directory and again from the <cw_profile>/bin directory. If the Deployment Manager is installed on the same server as one of the cluster nodes, also stop the Deployment Manager using the stopManager command from the <dmgr>/bin directory.

      ./serverStatus.sh -all

  2. Open a command window and switch to the eclipse/tools subdirectory of Installation Manager. By default, this is:

      /opt/IBM/InstallationManager/eclipse/tools

  3. If we are rolling back the cumulative fix on HCL WebSphere Portal Express, skip to Step 5. Otherwise, run the following command to launch the installation program of Installation Manager. Do note that the commands are shown here on multiple lines for clarity, but the entire command must be entered on one line. Include quotation marks around file paths that include spaces. For Unix/Linux:

      ./imcl rollback com.ibm.websphere.PORTAL.SERVER.v85 -installationDirectory <portal_server_root>

  4. HCL WebSphere Portal Express only (IBM i must use silent or console mode method): Launch the installation program of Installation Manager. Do note that the commands are shown here on multiple lines for clarity, but the entire command must be entered on one line. Include quotation marks around file paths that include spaces. For Linux:

      ./imcl rollback com.hcl.websphere.PORTAL.EXPRESS.v85 -installationDirectory <portal_server_root>

  5. After roll back completes, proceed with the "Post Rollback Steps."
Use silent mode to roll back (available on Windows, Linux, Unix, and IBM i operating systems)

  1. Stop any active application servers and node agents using the stopServer and stopNode commands. To see which application servers are active, use the serverStatus command from the <wp_profile>/bin directory and again from the <cw_profile>/bin directory. If the Deployment Manager is installed on the same server as one of the cluster nodes, also stop the Deployment Manager using the stopManager command from the <dmgr>/bin directory.

      ./serverStatus.sh -all

  2. Open a command window and switch to the eclipse/tools subdirectory of Installation Manager. By default, this is:

      /opt/IBM/InstallationManager/eclipse/tools

  3. Update the sample response file packaged with the cumulative fix level according to the comments in the file.

  4. Run the following command to roll back in silent mode:

      imcl -input <Full_path_to_response_file> -log <Full_Path_to_a_log_file> -showProgress

  5. After roll back completes, proceed with the "Post Rollback Steps."
Use Console Mode to roll back (available on Windows, Linux, Unix and IBM i operating systems)

  1. Stop any active application servers and node agents using the stopServer and stopNode commands. To see which application servers are active, use the serverStatus command from the <wp_profile>/bin directory and again from the <cw_profile>/bin directory. If the Deployment Manager is installed on the same server as one of the cluster nodes, also stop the Deployment Manager using the stopManager command from the <dmgr>/bin directory.

      ./serverStatus.sh -all

  2. Open a command window and switch to the eclipse/tools subdirectory of Installation Manager. By default, this is:

      /opt/IBM/InstallationManager/eclipse/tools

  3. Run the command to start the IBM Installation Manager in console mode.

      ./imcl -c

  4. Select Roll back and follow the prompts to roll back HCL WebSphere Portal.

  5. After installation completes, proceed with the "Post Rollback Steps."


Post Rollback Steps

Use the following commands to roll back all profiles. These steps must be repeated for each profile, if multiple profiles exist. All cluster members and all profiles that share the same Portal installation directory (multiple profile option) must be updated to the same level to complete the CF installation.

The following configuration steps should be run as the user who normally administers the Portal Server, which may or may not be the same user who runs the installation program.

If a remote search server is used within this environment, it should be started before running the following commands.

  1. Ensure the nodeagent and HCL WebSphere Portal and HCL Web Content Manager servers are stopped on the profile you intend to rollback. The Deployment Manager must be started.

  2. Run the following command from within the path of the profile to configure. Do note that if we are rolling back the CF on an empty portal then many of the expected artifacts will not exist and the rollbackCF command will fail. In this case define the "isEmptyPortal" property on the command line. Example:

      rollbackCF.sh -DisEmptyPortal=true

      <profile_root>/PortalServer/bin/rollbackCF.sh -DPortalAdminPwd=<password> -DWasPassword=<password>

    If the rollbackCF command fails for any reason, check the error logs and correct error conditions, then stop HCL WebSphere Portal and HCL Web Content Manager before re-running.

  3. If you previously customized any configuration files in the wp_profile_root/PortalServer/config directory, check to see if rolling back the cumulative fix affected those files by restoring a version of the files that was saved when the cumulative fix was originally installed. If it did affect the files, perform the same customization on the restored version of each file.

  4. Verify that the system is operational by entering the server's URL in a browser and logging in to browse the content. Restoring IP traffic after roll back (Required only if following the 24x7 single cluster roll back.)

    • If we are using IP sprayers for load balancing, reconfigure the IP sprayers to restore traffic to the downgraded node.
    • If we are using the Web server plug-in for load balancing, perform the following steps to restore traffic to the downgraded node.

If we are using the Web server plug-in for load balancing, perform the following steps to restore traffic to the downgraded node:

  1. In the Deployment Manager administrative console, to obtain a view of the collection of cluster members, click...

      Servers > Clusters > WebSphere application server clusters > cluster_name > Cluster members

  2. Locate the cluster member you downgraded and change the value in the Configured weight column back to the original value.

  3. Click Update to apply the change.

    If you previously disabled automatic propagation of the Web server(s), re-enable it now using the Deployment Manager administration console by going to...

      Servers > Server Types > Web Servers > web_server_name > Plug-in Properties

    ...and checking Automatically propagate plug-in configuration file. If we are not using automatic generation and propagation for the Web server plug-in, manually generate and/or propagate the plugin-cfg.xml file to the Web servers.


Steps to roll back additional nodes

There are several different methods to roll back the cumulative fix on additional nodes, and they are:

Start with the step "Stopping IP traffic for roll back for additional nodes" then choose one method that is available for the system. Follow the detailed steps for that option, and then proceed with the Post Rollback Steps on additional nodes.

Note: Do not attempt to roll back additional nodes until after completing the roll back of the primary node. The roll back for the primary must be performed and completed before the roll back of any additional nodes. Additional node roll backs can be performed sequentially or in parallel. Roll back the additional nodes in accordance with the following instructions. Stopping IP traffic for roll back for additional nodes (Required only if following the 24x7 single cluster roll back.)

If we are using the Web server plug-in for load balancing, perform the following steps to stop traffic to the node:

  1. In the Deployment Manager administrative console, to obtain a view of the collection of cluster members, click...

      Servers > Clusters > WebSphere application server clusters > cluster_name > Cluster members

  2. Locate the cluster member we are downgrading and change the value in the Configured weight column to zero. Record the previous value to restore the setting when the downgrade is complete.

  3. Click Update to apply the change.

Note that the web server plug-in will check periodically for configuration updates based on the value of Refresh Configuration Interval property for the Web server plug-in (default value is 60 seconds). We can check this value on the Deployment Manager administrative console by selecting...

Once automatic plug-in generation and propagation is disabled, we will need to manually generate and/or propagate the plugin-cfg.xml file to the Web servers. Use a Graphical User Interface to roll back on additional nodes (available on Windows, Linux, and Unix operating systems)

  1. Stop any active application servers and node agents using the stopServer and stopNode commands. To see which application servers are active, use the serverStatus command from the <wp_profile>/bin directory and again from the <cw_profile>/bin directory. If the Deployment Manager is installed on the same server as one of the cluster nodes, also stop the Deployment Manager using the stopManager command from the <dmgr>/bin directory.

      ./serverStatus.sh -all

  2. Launch the IBM Installation Manager that was used to install HCL WebSphere Portal v8.5.

  3. Select "Roll Back" on the Installation Manager main window and follow the prompts to roll HCL WebSphere Portal back to the desired level.

  4. After roll back completes, proceed with the "Post Rollback Steps on additional nodes."
Use a command line to roll back on additional nodes (available on Windows, Linux, and Unix operating systems)

  1. Stop any active application servers and node agents using the stopServer and stopNode commands. To see which application servers are active, use the serverStatus command from the <wp_profile>/bin directory and again from the <cw_profile>/bin directory. If the Deployment Manager is installed on the same server as one of the cluster nodes, also stop the Deployment Manager using the stopManager command from the <dmgr>/bin directory.

      ./serverStatus.sh -all

  2. cd /opt/IBM/InstallationManager/eclipse/tools

  3. If we are rolling back the cumulative fix on HCL WebSphere Portal Express, skip to Step 5. Otherwise, run the following command to launch the installation program of Installation Manager. Do note that the commands are shown here on multiple lines for clarity, but the entire command must be entered on one line. Include quotation marks around file paths that include spaces. For Unix/Linux:

      ./imcl rollback com.ibm.websphere.PORTAL.SERVER.v85 -installationDirectory <portal_server_root>

  4. HCL WebSphere Portal Express only (IBM i must use silent or console mode method): Launch the installation program of Installation Manager. Do note that the commands are shown here on multiple lines for clarity, but the entire command must be entered on one line. Include quotation marks around file paths that include spaces. For Linux:

      ./imcl rollback com.hcl.websphere.PORTAL.EXPRESS.v85 -installationDirectory <portal_server_root>

  5. After roll back completes, proceed with the "Post Rollback Steps on additional nodes."
Use silent mode to roll back on additional nodes (available on Windows, Linux, Unix, and IBM i operating systems)

  1. Stop any active application servers and node agents using the stopServer and stopNode commands. To see which application servers are active, use the serverStatus command from the <wp_profile>/bin directory and again from the <cw_profile>/bin directory. If the Deployment Manager is installed on the same server as one of the cluster nodes, also stop the Deployment Manager using the stopManager command from the <dmgr>/bin directory.

      ./serverStatus.sh -all

  2. cd /opt/IBM/InstallationManager/eclipse/tools
  3. Update the sample response file packaged with the cumulative fix level according to the comments in the file.

  4. Run the following command to roll back in silent mode:

      imcl -input <Full_path_to_response_file> -log <Full_Path_to_a_log_file> -showProgress

  5. After roll back completes, proceed with the "Post Rollback Steps on additional nodes."
Use Console Mode to roll back on additional nodes (available on Windows, Linux, Unix and IBM i operating systems)

  1. Stop any active application servers and node agents using the stopServer and stopNode commands. To see which application servers are active, use the serverStatus command from the <wp_profile>/bin directory and again from the <cw_profile>/bin directory. If the Deployment Manager is installed on the same server as one of the cluster nodes, also stop the Deployment Manager using the stopManager command from the <dmgr>/bin directory.

      ./serverStatus.sh -all

  2. cd /opt/IBM/InstallationManager/eclipse/tools

  3. Start the IBM Installation Manager in console mode.

      ./imcl -c

  4. Select Roll back and follow the prompts to roll back HCL WebSphere Portal.

  5. After installation completes, proceed with the "Post Rollback Steps."


Post Rollback Steps on additional nodes

Linux, Unix, Windows or IBM i Use the following commands to roll back all profiles. These steps must be repeated for each profile, if multiple profiles exist. All cluster members and all profiles that share the same Portal installation directory (multiple profile option) must be updated to the same level to complete the CF installation.

Note: The following configuration steps should be run as the user who normally administers the Portal Server, which may or may not be the same user who runs the installation program.

Note: If a remote search server is used within this environment, it should be started before running the following commands.

  1. Ensure the nodeagent and HCL WebSphere Portal and HCL Web Content Manager servers are stopped on the profile you intend to rollback. The Deployment Manager must be started.

  2. Run the following command from within the path of the profile to configure. Do note that if we are rolling back the CF on an empty portal then many of the expected artifacts will not exist and the rollbackCF command will fail. In this case define the "isEmptyPortal" property on the command line. Example: rollbackCF.sh -DisEmptyPortal=true

      <profile_root>/PortalServer/bin/rollbackCF.sh -DPortalAdminPwd=<password> -DWasPassword=<password>

    Important: If the rollbackCF command fails for any reason, check the error logs and correct error conditions, then stop HCL WebSphere Portal and HCL Web Content Manager before re-running.

  3. If you previously customized any configuration files in the wp_profile_root/PortalServer/config directory, check to see if rolling back the cumulative fix affected those files by restoring a version of the files that was saved when the cumulative fix was originally installed. If it did affect the files, perform the same customization on the restored version of each file.

  4. Verify that the system is operational by entering the server's URL in a browser and logging in to browse the content.
Restoring IP traffic after roll back for additional nodes (Required only if following the 24x7 single cluster roll back.)

If we are using the Web server plug-in for load balancing, perform the following steps to restore traffic to the downgraded node:

  1. In the Deployment Manager administrative console, to obtain a view of the collection of cluster members...

      Servers > Clusters > WebSphere application server clusters > cluster_name > Cluster members

    • Locate the cluster member you downgraded and change the value in the Configured weight column back to the original value.

    • Click Update to apply the change. If we are not using automatic generation and propagation for the Web server plug-in, manually generate and/or propagate the plugin-cfg.xml file to the Web servers.


Finalizing the roll back

  1. Re-enable automatic synchronization on all nodes in the cluster if you disabled it earlier.

    • In the administrative console for the deployment manager, select...

        System administration > Node agents > nodeagent

    • Click File Synchronization Service.
    • Check the Automatic Synchronization check box to enable the automatic synchronization feature and check the Enable service at server startup check box to enable the synchronization service at server startup on the File Synchronization Service page and then click OK.

    • Repeat these steps for all remaining nodes.

    • Click Save to save the configuration changes to the master repository.

    • Select...

        System administration > Nodes > nodes that are not synchronized > Synchronize

    • Select...

        System administration > Node agents > node agents where automatic synchronization has been re-enabled > Restart.

  2. If necessary, redeploy any customizations, including JSPs, to the WCM portlets (if using HCL Web Content Manager), any other portlets, or any other Portal enterprise applications, if these were customized prior to rolling back the cumulative fix.

  3. If we have set up a remote search server or document conversion server for use with HCL WebSphere Portal v8.5, then whenever you roll back a cumulative fix to the portal server, you should also roll back the corresponding cumulative fix to the remote server. Refer to the HCL WebSphere Portal v8.5 combined cumulative fix instructions: remote search for the details of rolling back a cumulative fix to the remote server.

  4. If using HCL Web Content Manager and have installed any official extensions (such as the WCM Multilingual Solution (MLS) or WCM Social Media Publisher (SMP)), then run the following task to update them. This task needs to be run for primary and additional nodes.

      <profile_root>/ConfigEngine/ConfigEngine.sh action-update-wcm-extensions -DWasPassword=<password> -DPortalAdminPwd=<password>

    The task can be run even if we are not sure if you had the extensions enabled. To check if they were enabled the following tasks can be used:

    • for MLS use ConfigEngine.sh|bat action-is-wcm-mls-enabled
    • for SMP use ConfigEngine.sh|bat action-is-wcm-smp-enabled

  5. For rollback to CF03 or earlier level only: If the Brightcove integration was enabled perform the following steps:

    • Uninstall the old Brightcove plugins.

    • Install the new Brightcove plugins by following the install steps in the Configuring topic section to use Brightcove.

  6. For rollback to CF03 or earlier level only: If using Rich Media Edition, perform the following steps:

    • Uninstall the Rich Media Edition plugins

    • Restart Portal Server.
    • Reinstall the Rich Media Edition plugins.

  7. If you brought down the entire cluster to perform the rollback (not maintaining 24 x 7 on a single cluster), and the automatic plug-in generation and propagation are disabled on the web server Plug-in properties, we will need to manually generate and/or propagate the plugin-cfg.xml file to the Web servers.

  8. Clear the browser cache.

Parent topic: Combined Cumulative Fix (CF) strategy