Cumulative fix instructions: Farm 9.5
Read the installation instructions to learn how to apply a cumulative fix to a portal farm installation or to roll back the cumulative fix.
About HCL WebSphere Portal 8.5 and 9.0 Combined Cumulative Fixes
This cumulative fix can only be applied to an existing functional version of HCL WebSphere Portal 8.5 and 9.0 with a previous cumulative fix applied.
As of CF14, this cumulative fix can also be applied to either an 8.5 environment above, or on top of a 9.0 level as well.
Overview
Applying the cumulative fix is a multi-step process. First update the product files using IBM Installation Manager, and then we must use the Portal ConfigEngine tool to apply the changes to each profile in the system. The update is not complete until we have performed both steps! Likewise, to roll back a fix, first use IBM Installation Manager to restore the older product files and then use ConfigEngine to apply the rollback to each profile.
The procedures below describe these steps in detail.
9.0
Note: After CF13 or later is fully installed and Portal runtime is operational, HCL Portal 9.0 can be installed. Visit HCL WebSphere Portal 9.0 Product Documentation for product base documentation on concepts, instructions, procedures, tips to configure, maintain, troubleshoot and use HCL WebSphere Portal.
9.5
Note: After CF213 or later is fully installed and Portal runtime is operational, HCL Portal 9.5 can be installed. Visit HCL WebSphere Portal 9.5 Product Documentation for instructions, procedures, tips to configure, maintain, troubleshoot and use the latest version of HCL WebSphere Portal.
Note: Unless we are migrating from a previous release or plan to add this node to an existing cluster, we must 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 8.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.
Note: In Portal 8.5 CF12 or later, the blacklist settings have become more restrictive. For inquiries, go to HCL Software Support page.
Space Requirements
Ensure that enough disk space is available in the following directories:
- For all platforms: 2.0 GB in the download directory to download the cumulative fix, 1.5 GB in Portal_Install_Root, 1 GB temporary disk space in (wp_profile_root), and 1.66 GB in the shared data space, which is the directory where Installation Manager temporarily stores downloaded files for use during the update.
- For Solaris: HCL recommends that you allocate swap space equal to at least twice your physical RAM to avoid memory errors during the configuration of this cumulative fix.
Best Practices
Go to the HCL Software Support page for Portal Upgrade Best Practices.
Syndicator/Subscriber Information
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 Version 8.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:
- <wp_profile root>/ConfigEngine/ConfigEngine.sh|.bat disable-syndication-auto-scheduler
- <wp_profile root>/ConfigEngine/ConfigEngine.sh|.bat enable-syndication-auto-scheduler
Search Crawler Information
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.
Backing 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:
- Windows: C:\ProgramData\IBM\InstallationManager
- Linux/UNIX root users: /var/ibm/InstallationManager
- Linux/UNIX non-root users: /home/(user id)/var/ibm/InstallationManager
- IBM i: Installation location: /QIBM/ProdData/InstallationManager
- IBM i: Agent data location: /QIBM/UserData/InstallationManager
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 the Supported 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.
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.
- Edit the <wp_profile root>/ConfigEngine/properties/wkplc.properties file and ensure the following values are set correctly:
WasRemoteHostName=<the hostname of your WAS instance> WasSoapPort=<the soap port of your WAS instance> WasUserid=<your WAS admin user> WasPassword=<your 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>- 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>- 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>- 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>
Note: In a Farm Portal environment, the WasRemoteHostName should be the local hostname and the WasSoapPort should be the soap port of the HCL WebSphere Portal server.
Note: If the server is configured with database runtime users, for example, feedback.DbRuntimeUser=<your feedback database runtime user>, ensure to set their password values correctly as well, for example, in feedback.DbRuntimePassword=<your feedback database runtime user password>.
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:
- If we are installing as a non-root user on Unix or Linux, the umask setting for your login session must be set to 0022 or better. (umask is a setting that controls what file permissions are set for newly created files and directories. A value of 0022 correspond to permission settings of (rwxr-xr-x).) If the umask is not set appropriately by default, we must set it when we start Installation Manager or when we open a command-line utility to run Installation Manager commands.
- The non-root user has a "ulimit - n" setting of at least 18192. This must be a number and not "unlimited".
- The non-root user owns 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.
- Do not use "sudo" or "su" to install the fix pack. Either use root explicitly or use a non-root user that meets the above conditions.
To open a command-line utility to run Installation Manager commands:
- Open a command line window.
- Run this command to check your current umask setting:
umask
- If necessary, run this command 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. We recommend 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.
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:
- Open a command Window and switch to the ConfigEngine home directory. By default this is:
Unix/Linux: /opt/IBM/WebSphere/ConfigEngine Windows: C:\IBM\WebSphere\ConfigEngine IBM i: /QIBM/ProdData/WebSphere/ConfigEngine- Make a backup copy of the ConfigEngine script. This file is named ConfigEngine.bat for Windows and ConfigEngine.sh for all other platforms.
- Make sure the user has write permissions for the script file and open it in a text editor.
- 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.)
- 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.
- Download the latest zip file that corresponds to the installation on the system, as shown in this table. We can also find more information about the latest fixes on the HCL Software page.
Installed Offering HCL WebSphere Portal Server Cumulative fix to download
- 8.5-WP-WCM-Combined-CFPInnnnn-Server-CFnn.zip
- 8.5-9.0-WP-WCM-Combined-CFPInnnnn-Server-CFnn.zip CF14 or later
- Create a directory and extract the zip file(s) into this directory. Inside the zip file is a readme file, sample response files (Server only), and the actual cumulative fix file itself. The cumulative fix files are named as follows, where nn represents the CF number associated with this cumulative fix:
- WP8500CFnn_Server.zip (HCL WebSphere Portal Server)
- 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.
Steps for installing the cumulative fix
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
Choose one method that is available for the system. Follow the detailed steps for that option, and then proceed with the additional configuration steps.
Use a Graphical User Interface (available on Windows, Linux, and Unix operating systems)
- If we are running an external web server such as IBM HTTP server, stop the web server.
- Stop any active application servers by using the stopServer command. 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:
- Unix/Linux: ./serverStatus.sh -all
- Windows: serverStatus.bat -all
- Launch the IBM Installation Manager that was used to install HCL WebSphere Portal V8.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.
Use a live repository via the Graphical User Interface (available on Windows, Linux, and Unix operating systems for CFs prior to CF213)
- If we are running an external web server such as IBM HTTP server, stop the web server.
- Stop any active application servers using the stopServer command. 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:
- Unix/Linux: ./serverStatus.sh -all
- Windows: serverStatus.bat -all
- Launch the IBM Installation Manager that was used to install HCL WebSphere Portal V8.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".
Use a command line (available on Windows, Linux, and Unix operating systems)
- If we are running an external web server such as IBM HTTP server, stop the web server.
- Stop any active application servers using the stopServer command. To see which application servers are active, use the serverStatus command from the (wp_profile)/bin directory and again from the (cw_profile)/bindirectory:
- Unix/Linux: ./serverStatus.sh -all
- Windows: serverStatus.bat -all
- Open a command window and switch to the eclipse/tools subdirectory of Installation Manager. By default, this is:
- Unix/Linux: /opt/IBM/InstallationManager/eclipse/tools
- Windows: C:\Program Files\IBM\Installation Manager\eclipse\tools
- Launch the installation program of IBM Installation Manager: NOTE: 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.
- Unix/Linux: ./imcl install com.ibm.websphere.PORTAL.SERVER.v85 -repositories (fullpath/to/repository.config) -installationDirectory (portal_server_root) -acceptLicense
- Windows: imcl.exe install com.ibm.websphere.PORTAL.SERVER.v85 -repositories (fullpath/to/repository.config) -installationDirectory (portal_server_root) -acceptLicense
- After installation completes, proceed with the "Additional configuration steps".
Use silent mode installation (available on Windows, Linux, Unix, and IBM i operating systems)
- If we are running an external web server such as IBM HTTP server, stop the web server.
- Stop any active application servers using the stopServer command. 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:
- Unix/Linux: ./serverStatus.sh -all
- Windows: serverStatus.bat -all
- IBM i: serverStatus -all
- For IBM i only, Run the following command from qshell:
chown QEJBSVR /QIBM/UserData/WebSphere/AppServer/V85/ND/profiles/cw_profile/ConfigEngine/properties/wkplc.properties- Open a command window and switch to the eclipse/tools subdirectory of Installation Manager. By default, this is:
- Unix/Linux: /opt/IBM/InstallationManager/eclipse/tools
- Windows: C:\Program Files\IBM\Installation Manager\eclipse\tools
- IBM i: /QIBM/ProdData/InstallationManager/eclipse/tools
- Update the sample response file packaged with your 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. Go to HCL Software Support page for detailed instructions for recording an IBM Installation Manager response file.
Note: The feature set listed in your 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 creating multiple profiles, or you originally installed Portal 8.5 as a binary install), then you should remove the 'portal.profile' feature from this list: features='ce.install,portal.binary'.
- Install in silent mode:
imcl -acceptLicense -input (Full_path_to_your_response_file) -log (Full_Path_to_a_log_file) -showProgress.- After installation completes, proceed with the "Additional configuration steps".
Use Console Mode Interface (available on Windows, Linux, Unix and IBM i operating systems)
- If we are running an external web server such as IBM HTTP server, stop the web server.
- Stop any active application servers using the stopServer command. 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:
- Unix/Linux: ./serverStatus.sh -all
- Windows: serverStatus.bat -all
- IBM i: serverStatus -all
- For IBM i only, Run the following command from qshell:
chown QEJBSVR /QIBM/UserData/WebSphere/AppServer/V85/ND/profiles/cw_profile/ConfigEngine/properties/wkplc.properties- Open a command window and switch to the eclipse/tools subdirectory of Installation Manager. By default, this is:
- Unix/Linux: /opt/IBM/InstallationManager/eclipse/tools
- Windows: C:\Program Files\IBM\Installation Manager\eclipse\tools
- IBM i: /QIBM/ProdData/InstallationManager/eclipse/tools
- Run the command to start the IBM Installation Manager in console mode: Unix/Linux:
./imcl -cWindows:imcl.exe -cIBM i:./imcl -c
- 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 Portal v8.5. CF repository file.
- Enter A to apply your 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".
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"Post installation steps".
If we are in the process of a migration, we will need to follow these additional configuration steps after running upgrade-profile for your migrated environment.
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 profiles that share the same Portal installation directory (multiple profile option) must be at the same level for future upgrades to be applied.
Notes: 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, HCL recommends to run the following task: (profile_root)/bin/osgiCfgInit.sh|bat Optional
Note: To skip regeneration of the profile template, add the following flag to the CF update command: ex.
applyCF.sh -Dskip.profile.template.update=trueIf an updated template is needed at a later time, this command can be run to do so at any time: ex.ConfigEngine.sh cf-create-profile-templatesEnsure the HCL WebSphere Portal server is stopped on the profile you intend to upgrade. On the Farm Master Server Execute the following command from within the path of the profile to configure:
Note: If we are installing the CF on an empty portal, see the *Special Considerations* below before running applyCF.
- Unix/Linux: (profile_root)/PortalServer/bin/applyCF.sh -DPortalAdminPwd=(password) -DWasPassword=(password)
- Windows: (profile_root)\PortalServer\bin\applyCF.bat -DPortalAdminPwd=(password -DWasPassword=(password)
- IBM i: (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. *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:
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.xmlUpgrade 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: Unix/Linux: <profile_root>/PortalServer/bin/applyCF.sh -DisEmptyPortal=true -DPortalAdminPwd=<password> -DWasPassword=<password> Windows: <profile_root>\PortalServer\bin\applyCF.bat -DisEmptyPortal=true -DPortalAdminPwd=<password> -DWasPassword=<password> IBM i: <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.
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. Unix/Linux : <profile_root>/ConfigEngine/ ./ConfigEngine.sh empty-portal -DWasPassword=<password> -DPortalAdminPwd=<password> Windows: <profile_root>/ConfigEngine/ ConfigEngine.bat empty-portal -DWasPassword=<password> -DPortalAdminPwd=<password> IBM i: <profile_root>/ConfigEngine/ ConfigEngine.sh empty-portal -DWasPassword=<password> -DPortalAdminPwd=<password>
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.xmlFarm Support Server setup 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.
Note: If we are installing the CF on an empty portal, see the *Special Considerations* below before running applyCF.
Unix/Linux: <profile_root>/PortalServer/bin/applyCF.sh -DPortalAdminPwd=<password> -DWasPassword=<password> Windows: <profile_root>\PortalServer\bin\applyCF.bat -DPortalAdminPwd=<password> -DWasPassword=<password> IBM i: <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. *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:
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.xmlUpgrade 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: Unix/Linux: <profile_root>/PortalServer/bin/applyCF.sh -DisEmptyPortal=true -DPortalAdminPwd=<password> -DWasPassword=<password> Windows: <profile_root>\PortalServer\bin\applyCF.bat -DisEmptyPortal=true -DPortalAdminPwd=<password> -DWasPassword=<password> IBM i: <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.
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. Unix/Linux : <profile_root>/ConfigEngine/ ./ConfigEngine.sh empty-portal -DWasPassword=<password> -DPortalAdminPwd=<password> Windows: <profile_root>/ConfigEngine/ ConfigEngine.bat empty-portal -DWasPassword=<password> -DPortalAdminPwd=<password> IBM i: <profile_root>/ConfigEngine/ ConfigEngine.sh empty-portal -DWasPassword=<password> -DPortalAdminPwd=<password>
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
Post installation steps
1. If we are running an external web server such as IBM HTTP Server and we are using the WebSphere Application Server automatic generation and propagation of the plug-in, then restart the web server. If we are not using the automatic generation and propagation, then perform the following steps:
- Regenerate the web server plug-in.
- Copy the plugin-cfg.xml file to the plugin directory.
- Restart the web server.
2. If there is a custom theme that contains a static content WAR and the com.ibm.portal.resource.blacklist and com.ibm.portal.resource.whitelist context parameters have not yet been added to the web.xml file, go to HCL Software Support page to fix security vulnerability. The changes associated with this 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. Go to HCL Software Support page to see if the Configuration Changes and Options introduced in the HCL Web Content Manager 8.5 Combined Cumulative Fixes apply to the environment.
5. If you modified the permissions on the PortalServer home directory tree to install the cumulative fix as non-root, restore the original permissions. 6. If using 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.
Unix/Linux: <profile_root>/ConfigEngine/ConfigEngine.sh action-update-wcm-extensions -DWasPassword=<password> -DPortalAdminPwd=<password> Windows: <profile_root>\ConfigEngine\ConfigEngine.bat action-update-wcm-extensions -DWasPassword=<password> -DPortalAdminPwd=<password> IBM i: <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
7. If we have set up a remote search server or document conversion server for use with HCL WebSphere Portal 8.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 8.5 Combined cumulative fix instructions: remote search for the details of applying a cumulative fix to the remote server.
8. Clear the browser cache.
9. Go to HCL Software Support page for Recommended Updates for HCL WebSphere Portal and HCL Web Content Manager v8.5 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 your 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 5OR It can also be done by running the following Config Engine Task:configure-jcr-db2-dft-queryopt
Steps for rolling back the cumulative fix
NOTE: 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.
NOTE: 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
Before you begin rollback
- Change 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 we 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 we 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 your previous CF level was CF07 or prior.
- Configure HCL WebSphere Portal from a stand-alone environment to a clustered environment after upgrading is an unsupported rollback path.
- The HCL WebSphere Portal rollback 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.
- Edit the <wp_profile root>/ConfigEngine/properties/wkplc.properties file and ensure the following values are set correctly:
WasRemoteHostName=<the hostname of your WAS instance> WasSoapPort=<the soap port of your WAS instance> WasUserid=<your WAS admin user> WasPassword=<your 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>
Note: In a Farm Portal environment, the WasRemoteHostName should be the local hostname and the WasSoapPort should be the soap port of the HCL WebSphere Portal server.
- 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>- 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 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
Choose one method that is available for the system. Follow the detailed steps for that option, and then proceed with the Post Rollback Steps. Use a Graphical User Interface to roll back (available on Windows, Linux, and Unix operating systems)
Use a command line to roll back (available on Windows, Linux, and Unix operating systems)
- If we are running an external web server, stop the web server.
- 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 Windows: serverStatus.bat -all- 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 Portal back to the desired level.
- After rollback completes, proceed with the "Post Rollback Steps."
Use silent mode to roll back (available on Windows, Linux, Unix, and IBM i operating systems)
- If we are running an external web server, stop the web server.
- 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 Windows: serverStatus.bat -all- Open a command window and switch to the eclipse/tools subdirectory of Installation Manager. By default, this is:
Unix/Linux: /opt/IBM/InstallationManager/eclipse/tools Windows: C:\Program Files\IBM\Installation Manager\eclipse\tools- Launch the installation program of IBM Installation Manager. 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>Windows:imcl.exe rollback com.ibm.websphere.PORTAL.SERVER.v85 -installationDirectory <portal_server_root>- 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)
- If we are running an external web server, stop the web server.
- 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 Windows: serverStatus.bat -all IBM i: serverStatus -all- For IBM i only, Run the following command from qshell:
chown QEJBSVR /QIBM/UserData/WebSphere/AppServer/V85/ND/profiles/cw_profile/ConfigEngine/properties/wkplc.properties- Open a command window and switch to the eclipse/tools subdirectory of Installation Manager. By default, this is:
Unix/Linux: /opt/IBM/InstallationManager/eclipse/tools Windows: C:\Program Files\IBM\Installation Manager\eclipse\tools IBM i: /QIBM/ProdData/InstallationManager/eclipse/tools- Update the sample response file packaged with your cumulative fix level according to the comments in the file.
- Run the following command to roll back in silent mode:
imcl -input <Full_path_to_your_response_file> -log <Full_Path_to_a_log_file> -showProgress- After roll back completes, proceed with the "Post Rollback Steps."
- If we are running an external web server, stop the web server.
- 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 Windows: serverStatus.bat -all IBM i: serverStatus -all- For IBM i only, Run the following command from qshell:
chown QEJBSVR /QIBM/UserData/WebSphere/AppServer/V85/ND/profiles/cw_profile/ConfigEngine/properties/wkplc.properties- Open a command window and switch to the eclipse/tools subdirectory of Installation Manager. By default, this is:
Unix/Linux: /opt/IBM/InstallationManager/eclipse/tools Windows: C:\Program Files\IBM\Installation Manager\eclipse\tools IBM i: /QIBM/ProdData/InstallationManager/eclipse/tools- Run the command to start the IBM Installation Manager in console mode. For Unix/Linux:
./imcl -cWindows:imcl.exe -cIBM i:./imcl -c- 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
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.
- On the Farm Master Server execute the following command from within the path of the profile to configure.
Note: 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=trueUnix/Linux: (profile_root/PortalServer/bin/rollbackCF.sh -DPortalAdminPwd=(password) -DWasPassword=(password) Windows: (profile_root)\PortalServer\bin\rollbackCF.bat -DPortalAdminPwd=(password) -DWasPassword=(password) IBM i: (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 before re-running.
- On the Farm Support Server execute the following command from within the path of the profile to configure.
Note: 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
Note: If the Farm Support Server only has read-only access to the Portal Binaries use the -DSharedBinaries=true flag with the rollbackCF command.
Unix/Linux: (profile_root)/PortalServer/bin/rollbackCF.sh -DPortalAdminPwd=(password) -DWasPassword=(password) Windows: (profile_root)\PortalServer\bin\rollbackCF.bat -DPortalAdminPwd=(password) -DWasPassword=(password) IBM i: (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 before re-running.
- 3. If we are running an external web server, and we are using the WebSphere Application Server automatic generation and propagation of the plug-in, then restart the web server. If we are not using the automatic generation and propagation, then perform the following steps:
- Regenerate the web server plugin.
- Copy the plugin-cfg.xml file to the plugin directory.
- Restart the web server.
- 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.
- 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.
- 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.
Unix/Linux: (profile_root)/ConfigEngine/ConfigEngine.sh action-update-wcm-extensions -DWasPassword=(password) -DPortalAdminPwd=(password) Windows: (profile_root)\ConfigEngine\ConfigEngine.bat action-update-wcm-extensions -DWasPassword=(password) -DPortalAdminPwd=(password) IBM i: (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
- For rollback to CF03 or earlier level only: If the Brightcove integration was enabled, remove the old Brightcove plugins, then configure HCL WebSphere Portal to add the new Brightcove plugins.
- For rollback to CF03 or earlier level only: If using Rich Media Edition, remove the Rich Media Edition plugin, restart the Portal Server, then configure HCL WebSphere Portal to add the Rich Media Edition plugins.
- If we have set up a remote search server or document conversion server for use with HCL WebSphere Portal 8.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.
- Clear the browser cache.
Parent topic: Combined Cumulative Fix (CF) strategy