Apply cumulative fix to HCL v9.0 on AIX/Linux

Note that in Portal v8.5 CF12 or later, the blacklist settings have become more restrictive. For inquiries, go to HCL Software Support page.

Upgrade the primary node

Stop IP traffic (Prod and Stage cluster upgrade)

If we are using IP sprayers for load balancing to the cluster members, reconfigure the IP sprayers to stop routing new requests to the Portal cluster member(s) on this node.
If we are using the Web server plug-in for load balancing, perform the following steps below to stop traffic to the node:
1. To obtain a view of the collection of cluster members, in the Deployment Manager administrative console, click...
  - Locate the cluster member you are upgrading and change the value in the Configured weight column to zero.
    Record the previous value to restore the setting when the upgrade is complete.
  - 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). You can check this value on the Deployment Manager administrative console by selecting...

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

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...

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

...and clearing the Automatically propagate plug-in configuration file check box. 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 server.

Set umask and ulimit

Install the cumulative fix as the same user which used to install HCL WebSphere Portal originally. This install assumes we are using a non-root user. The non-root user will own the AppServer, PortalServer, ConfigEngine, and Portal profile directories and has read/write access to all files in these directories. Permission settings of 755 (rwxr-xr-x) are sufficient.

The umask setting for the login session must be set to 0022 or better. A value of 0022 correspond to permission settings of -rwxr-xr-x. Before running Installation Manager commands.
1. Check the current umask setting: umask
2. If necessary, set umask: umask 0022
Check ulimit: ulimit
If necessary, set ulimit:
This must be a number and not unlimited.

Use Console mode for first upgrade

We perform the first upgrade using the console, selecting the option to generate a response file. We then will use response file to apply CFs silently in other environments.

Stop any active application servers and node agents using stopServer and stopNode
To see active application servers from wp_profile/bin and again from cw_profile/bin., run
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:
cd Installation_Manager/eclipse/tools. By default, this is:
Start the IBM Installation Manager in console mode.
Add the repositories.
To add the repositories:
- Enter P to go to the Preferences menu.
- Enter 1 to go to the Repositories menu.
- Enter D to add repositories.
- Type the path for the HCL WebSphere Portal v8.5 CF repository file.
- Enter A to apply the repositories and return to the Preferences menu.
- Enter R to return to the Main menu.
Select Update and follow the prompts to update HCL WebSphere Portal.
After installation completes, proceed with the Additional Configuration Steps.

Use silent mode for additional upgrades

Stop any active application servers and node agents using stopServer and stopNode
To see which application servers are active, from $WP_PROFILE/bin and $CW_PROFILE/bin.
If the Deployment Manager is installed on the same server as one of the cluster nodes, also stop the Deployment Manager using $DMGR/bin/stopManager command
Go to IM tools directory...
By default, this is:
Install in silent mode:
After installation completes, proceed with the Additional Configuration Steps.

Additional configuration steps for profiles

At this point ONLY the Portal binaries have been updated. The IIM only manages the binaries so we will need to run a Portal script to upgrade the profile.

For any profiles the following configuration steps are mandatory.

If we do not have any profiles at this point, no additional configuration steps are necessary and we can continue with the Restore IP traffic steps described below.

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.

Additional configuration: Update process

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.

If a remote search server is used within this environment, it should be started before running the following commands.
Also, if a WAS update has occurred prior to running the CF update, it is recommended to run the following task:
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:

Apply Cumulative Fix (CF)

If we are installing the CF on an empty portal, see the Special Considerations below before running.

Ensure the nodeagent and HCL WebSphere Portal servers are stopped on the profile you intend to upgrade. The Deployment Manager must be started.
On the primary node run applyCF.sh.
If the applyCF command fails for any reason, check the error logs and correct error conditions before re-running.
On the primary node execute the following command from within the path of the profile to configure.
If the secondary notes only has read-only access to the Portal Binaries use the -DSharedBinaries=true flag with the applyCF command.
Important Notes:
- If we are applying CF200 to fix an SSRF security vulnerability, ensure that we run the following command:
  ...where /opt/IBM/WebSphere/PortalServer/ is the installation directory path.
- If the applyCF command fails for any reason, check the error logs and correct error conditions before re-running.

Additional configuration: Special consideration for empty portals

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

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:
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:
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:
If we 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:

Additional configuration: Restore IP traffic (Prod and Stage cluster upgrade)

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

To restore traffic to the upgraded node:

Obtain a view of the collection of cluster members. In the Deployment Manager administrative console, click...
Change the value in the Configured weight column back to the original value.
Click Update to apply the change.

If we 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.

Upgrade additional nodes

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

Use a Graphical User Interface (GUI)
Use a live repository via the Graphical User Interface
Use a command line
Use silent mode installation
Use console mode installation

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.

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.

Additional configuration: Stop IP traffic for additional nodes (Prod and Stage upgrade only)

If we are using IP sprayers for load balancing to the cluster members, reconfigure the IP sprayers to stop routing new requests to the Portal cluster member(s) on this node.
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.
2. Locate the cluster member you 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.

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

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

Stop any active application servers and node agents using stopServer and stopNode.
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:
Launch the IBM Installation Manager that was used to install HCL WebSphere Portal 8.5.
Use Installation Manager, click File > Preferences .
Go to the Repositories panel and click Add Repository.
Navigate to the repository.config file mentioned earlier and select it.
Select Update and follow the prompts to update HCL WebSphere Portal.
After installation completes, proceed with the Additional configuration steps on additional nodes.

Use a live repository via the Graphical User Interface on additional nodes

Stop any active application servers and node agents using stopServer and stopNode.
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:
Launch the IBM Installation Manager that was used to install HCL WebSphere Portal Version 8.5
Use Installation Manager, click File > Preferences.
Go to the Repositories panel and click Search service repositories during installation and updates. Click apply.
Select Update and follow the prompts to update HCL WebSphere Portal.
After installation completes, proceed with the Additional configuration steps on additional nodes.

Use a command line on additional nodes

Stop any active application servers and node agents using stopServer and stopNode.
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:
Open a command window and switch to the eclipse/tools sub-directory of Installation Manager. By default, this is:
- Linux: /opt/IBM/InstallationManager/eclipse/tools
Launch the installation program of Installation Manager.
After installation completes, proceed with the Additional configuration steps on additional nodes.

Use silent mode installation on additional nodes

Stop any active application servers and node agents using stopServer and stopNode
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:
Open a command window and switch to the eclipse/tools sub-directory of Installation Manager. By default, this is:
Update the sample response file packaged with the cumulative fix level according to the comments in the file. You 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 you have installed. You cannot add or remove features during the cumulative fix update. The feature set listed in the sample response file is:
If we do not have any profiles on the node, remove the 'portal.profile' feature from the features='ce.install,portal.binary' list.
Install in silent mode:
After installation completes, proceed with the Additional configuration steps on additional nodes.

Use Console Mode installation on additional nodes

Stop any active application servers and node agents using stopServer and stopNode
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, you must also stop the Deployment Manager using the stopManager command from the (dmgr)/bin directory:
cd Installation_Manater/eclipse/tools
By default, this is:
Start the IBM Installation Manager in console mode.
Add the repositories.
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 8.5 CF repository file.
5. Enter A to apply the repositories and return to the Preferences menu.
6. Enter R to return to the Main menu.
Select Update and follow the prompts to update HCL WebSphere Portal.
After installation completes, proceed with the Additional Configuration Steps.

Additional configuration steps on additional nodes for profiles

For any profiles the following configuration steps are mandatory.

If we do not have any profiles at this point, no additional configuration steps are necessary and we can continue with the Restore IP traffic steps described below.

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.

Additional configuration: Update process (Linux and Windows)

If a remote search server is used within this environment, it should be started before running the following commands.
Also, if a WAS update has occurred prior to running the CF update, it is recommended to run the following task:
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. Run...
  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.

Additional configuration: Special consideration for empty portals

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

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:
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:
- Linux:
  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:
- If we 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:

Additional configuration: Restore IP traffic (Prod and Stage upgrade only)

If we are using IP sprayers for load balancing, reconfigure the IP sprayers to restore traffic to the upgraded node.
If we are using the Web server plug-in for load balancing, perform the following steps to restore traffic to the upgraded node.
1. Obtain a view of the collection of cluster members. In the Deployment Manager administrative console, click...
2. 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.

Finalize the upgrade

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...
Check boxes for...
- Automatic Synchronization
- Enable service at server startup check box
Click OK.
Repeat these steps for all remaining nodes.
Click Save to save the configuration changes to the master repository.
Select System administration > Nodes in the navigation tree.
Select all nodes that are not synchronized, and click on Synchronize.
Select System administration > Node agents in the navigation tree.
Select all node agents where automatic synchronization has been re-enabled and click Restart.

2. 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.

3. 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.

4. 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.

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

6. 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 you are not sure if you had the extensions enabled. To check if they were enabled the following tasks can be used:

For MLS use:
For SMP use

7. If we 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.

8. Clear the browser cache.

9. Please go to Recommended Updates for HCL DX to review and apply any recommended fixes.

10. 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 beginning a 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, 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 in CF rollback

Changing the server context root after upgrading is an unsupported rollback path. To roll back after changing the context root, first change the server context root to the values of the previous version.
When rolling back a CF install, if you have configured an empty context root we cannot roll back to a CF level that does not support the empty context root capability. For instance, if you have applied CF08 and have configured an empty context root we cannot rollback to CF07. For applied CF09 and have configured an empty context root we can roll back to CF08 but you would not be able to roll back if the previous CF level was CF07 or prior.
Configuring HCL WebSphere Portal from a stand-alone environment to a clustered environment after upgrading is an unsupported rollback path.

Ensure wkplc properties files are correct for rollback

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.

Edit..
...and ensure the following values are set correctly:
- WasRemoteHostName=<the host name of your Dmgr>
- WasSoapPort=<the soap port of your Dmgr>
- WasUserid=<the WAS admin user>
- WasPassword=<the WAS admin pwd>
- PortalAdminId=<the Portal Admin ID>
- PortalAdminPwd=<the Portal Admin password>
- WpsHostName=<Your Portal host name>
- WpsHostPort=<port used to access portal>
- WpsContextRoot=<the Portal context root>
Edit...

Update process in CF rollback (Linux and WIndows)

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 start up and at every synchronization interval to attempt to synchronize the node's configuration repository with the master repository managed by the deployment manager.

Disable the automatic synchronization feature and synchronization service at server start up.
In the administrative console for the deployment manager, select...
Clear the check boxes...
- Automatic Synchronization check box
- Enable service at server start up
Repeat these steps for all other nodes to be downgraded.
Click Save to save the configuration changes to the master repository.
Select...
Select all nodes that are not synchronized, and click on Synchronize.
Select...
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.

Stop IP traffic for roll back (Required only if following the Prod and Stage cluster roll back)

If we are using IP sprayers for load balancing to the cluster members, reconfigure the IP sprayers to stop routing new requests to the Portal cluster member(s) on this node.
If we are using the Web server plug-in for load balancing, perform the following steps to stop traffic to the node:
1. To obtain a view of the collection of cluster, in the Deployment Manager administrative console,
2. Locate the cluster member you 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.

If we are using the Web server plug-in for load balancing, perform the following steps to stop traffic to the node: 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). You can check this value on the Deployment Manager administrative console by selecting...

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

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...

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

...and clear the Automatically propagate plug-in configuration file check box. 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.

Steps to roll back the Primary node

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

Use a Graphical User Interface (GUI) to roll back
Use a command line roll back
Use silent mode roll back
Use console mode roll back

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.

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.

Use a Graphical User Interface to roll back

Stop any active application servers and node agents by using stopServer and stopNode.
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:
Launch the IBM Installation Manager that was used to install HCL WebSphere Portal Version 8.5.
Select Roll Back on the Installation Manager main window and follow the prompts to roll HCL WebSphere Portal back to the desired level.
After rollback completes, proceed with the Post Rollback Steps.

Use a command line to roll back

Stop any active application servers and node agents by 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:
Open a command window and switch to the eclipse/tools sub-directory of Installation Manager. By default, this is:
- Linux: /opt/IBM/InstallationManager/eclipse/tools
- Windows: C:\Program Files\IBM\Installation Manager\eclipse\tools
Launch the installation program of Installation Manager.
After roll back completes, proceed with the Post Rollback Steps.

Use silent mode to roll back

Stop any active application servers and node agents using stopServer and stopNode
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:
Open a command window and switch to the eclipse/tools sub-directory of Installation Manager. By default, this is:
Update the sample response file packaged with the cumulative fix level according to the comments in the file.
Roll back in silent mode:
After roll back completes, proceed with the Post Rollback Steps.

Use Console Mode to roll back

Stop any active application servers and node agents by 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, you must also stop the Deployment Manager using the stopManager command from the $DMGR/bin directory:
Open a command window and switch to the eclipse/tools sub-directory of Installation Manager. By default, this is:
Start the IBM Installation Manager in console mode.
For
Select Roll back and follow the prompts to roll back HCL WebSphere Portal.
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 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.

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

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.

rollbackCF.sh -DisEmptyPortal=true

Important: If the rollbackCF command fails for any reason, check the error logs and correct error conditions, then stop HCL Digital Experience before re-running.

3. If we 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.

Restore IP traffic after roll back Prod and Stage cluster rollback only)

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:
1. To obtain a view of the collection of cluster members, in the Deployment Manager administrative console, click...
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 we previously disabled automatic propagation of the Web server(s), re-enable it now using the Deployment Manager administration console by going to...
  ...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.

Stop IP traffic for roll back for additional nodes Prod and Stage cluster rollback only)

If we are using IP sprayers for load balancing to the cluster members, reconfigure the IP sprayers to stop routing new requests to the Portal cluster member(s) on this node.
If we are using the Web server plug-in for load balancing, perform the following steps to stop traffic to the node:
1. To obtain a view of the collection of cluster, in the Deployment Manager administrative console, click...
2. Locate the cluster member you 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.

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

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.

Steps to roll back additional nodes

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

Use a Graphical User Interface (GUI) to roll back on additional nodes
Use a command line roll back on additional nodes
Use silent mode roll back on additional nodes
Use console mode roll back on additional nodes

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.

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.

Use a Graphical User Interface to roll back on additional nodes

Stop any active application servers and node agents by 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, you must also stop the Deployment Manager using the stopManager command from the $DMGR/bin directory:
Launch the IBM Installation Manager that was used to install HCL WebSphere Portal v8.5.
Select Roll Back on the Installation Manager main window and follow the prompts to roll HCL WebSphere Portal back to the desired level.
After roll back completes, proceed with the Post Rollback Steps on additional nodes.

Use a command line to roll back on additional nodes

Stop any active application servers and node agents by 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:
Open a command window and switch to the eclipse/tools sub-directory of Installation Manager. By default, this is:
- Linux: /opt/IBM/InstallationManager/eclipse/tools
- Windows: C:\Program Files\IBM\Installation Manager\eclipse\tools
Launch the installation program of Installation Manager.
After roll back completes, proceed with the Post Rollback Steps on additional nodes.

Use silent mode to roll back on additional nodes

Stop any active application servers and node agents using stopServer and stopNode
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:
Open a command window and switch to the eclipse/tools sub-directory of Installation Manager. By default, this is:
- Linux: /opt/IBM/InstallationManager/eclipse/tools
- Windows: C:\Program Files\IBM\Installation Manager\eclipse\tools
Update the sample response file packaged with the cumulative fix level according to the comments in the file.
Roll back in silent mode:
After roll back completes, proceed with the Post Rollback Steps on additional nodes.

Use Console Mode to roll back on additional nodes

Stop any active application servers and node agents using stopServer and stopNode
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, you must also stop the Deployment Manager using the stopManager command from the $DMGR/bin directory:
Open a command window and switch to the eclipse/tools sub-directory of Installation Manager. By default, this is:
Start the IBM Installation Manager in console mode.
Select Roll back and follow the prompts to roll back HCL WebSphere Portal.
After installation completes, proceed with the Post Rollback Steps.

Post Rollback Steps on additional nodes (Linux and Windows)

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.

Ensure the nodeagent and HCL WebSphere Portal servers are stopped on the profile you intend to rollback. The Deployment Manager must be started.
Run the following command from within the path of the profile to configure. Do note that if you 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:
Important: If the rollbackCF command fails for any reason, check the error logs and correct error conditions, then stop HCL DX before re-running.
If we 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.
Verify that the system is operational by entering the server's URL in a browser and logging in to browse the content.

Restore IP traffic after roll back for additional nodes (Prod and Stage cluster rollback only)

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:
1. To obtain a view of the collection of cluster members, in the Deployment Manager administrative console, click...
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 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.

Finalize 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...
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 in the navigation tree.
Select all nodes that are not synchronized, and click on Synchronize.
Select System administration > Node agents in the navigation tree.
Select all node agents where automatic synchronization has been re-enabled and click 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 you are not sure if you had the extensions enabled. To check if they were enabled the following tasks can be used:

For MLS, use:
For SMP, use:
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 we 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.

Single cluster	Upgrade the cluster while the entire cluster has been taken offline from receiving user traffic. HCL recommended approach.
Prod and Stage availability	For environments which cannot tolerate outages.