Cumulative Fix instructions: Cluster | HCL Digital Experience 8.5
Read the installation instructions to learn how to apply a cumulative fix to a clustered portal installation or to roll back the cumulative fix.
Cluster upgrade planning
There are two options for performing upgrade in a clustered environment. One option is to upgrade the cluster while the entire cluster has been taken offline from receiving user traffic. The upgrade is performed on every node in the cluster using the single-cluster procedure documented below before the cluster is brought back online to receive user traffic. This is the recommended approach for an environment with multiple Portal clusters since 24x7 availability can be maintained. It is also the simplest approach to use in a single cluster environment if maintenance windows allow for the Portal cluster to be taken offline.
Assumptions for maintaining 24x7 operation during the upgrade process
- If you want to preserve current user sessions during the upgrade process, make sure that WebSphere Application Server distributed session support is enabled to recover 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 before stopping the cluster node for upgrade to minimize the disruption to existing user sessions.
- Load balancing must be enabled in the clustered environment.
- The cluster has at least two horizontal cluster members.
Limitations on 24x7 maintenance
- 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 with the Portal JCR search crawler (typically we recommend to disable textsearch for JCR for rendering systems)
- 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 you have not implemented horizontal scaling and have implemented only vertical scaling in your environment such that all cluster members reside on the same node, the cumulative fix installation process will result in a temporary outage for your end users due to a required restart. In this case, you will be unable to upgrade while maintaining 24x7 availability.
3. If you have a single local Web server in your environment, maintaining 24x7 availability during the cluster upgrade may not be possible since you 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 it is recommended that you test your 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. In order to maintain 24x7 operations in a clustered environment, it is required that you stop HCL 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. It is recommended that you test your 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.
Before you begin
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: It is recommended 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
It is recommended 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 Digital Experience Version 8.5 product documentation for more information. Syndication should then be re-enabled after the update is complete.
-
<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
It is recommended 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 you are upgrading in the event you lose connection during the upgrade, as this could corrupt the data directory.
- 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 Portal Version 8.5 CF releases.
Review supported hardware/software requirements
For Portal Version 8.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.
EJBDeploy tool for pre-EJB 3.0
modules
is installed.Check fixes installed on your system
All temporary or interim fixes on your system must be removed before installing this cumulative fix.
Also check whether the fixes installed on your system are included in the list of fixes provided in this cumulative fix. If you have temporary or interim fixes on your 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 Digital Experience Patterns
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.
- 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.
- Run the Installation Manager update for the Portal Version 8.5 CF as the user that owns PortalServer.
- 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)
- Run
applyCF.sh
as portaladmin the same owner as (wp_profile).Note: /opt/HCL/WebSphere will vary depending on what the installation directory actually is.Note:OSUser
will vary depending on which user owns the PortalServer directory.
Ensure wkplc properties files are correct
The HCL 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 you 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=<your Portal Admin ID>
- PortalAdminPwd=<your Portal Admin password>
- WpsHostName=<Your Portal hostname>
- WpsHostPort=<The port you use to access Portal>
- WpsContextRoot=<your Portal context root>
- Edit the <wp_profile
root>/ConfigEngine/properties/wkplc_dbdomain.properties
file and ensure the following values are set correctly:
- release.DbPassword=<your database user password>
- community.DbPassword=<your database user password>
- customization.DbPassword=<your database user password>
- jcr.DbPassword=<your database user password>
- likeminds.DbPassword=<your database user password>
- feedback.DbPassword=<your database user password>
- Edit the <wp_profile
root>/ConfigEngine/properties/wkplc_comp.properties file
and ensure the following values are set correctly:
- XmlAccessHost=<your Portal hostname>
- XmlAccessPort=<the port you use to access Portal>
Note: If your 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:
PWordDelete=false
Multiple profile considerations
Verify that all of your 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
- If you 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 theumask
is not set appropriately by default, you must set it when you start Installation Manager or when you 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 notunlimited
. - 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
orsu
to install the fix pack. Either use root explicitly or use a non-root user that meets the above conditions.
- 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)
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 you need to apply Portal Cumulative Fix 15 or earlier to a WAS v8.5.5.14 installation, you will need to perform an additional manual step during the upgrade.
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 namedConfigEngine.bat
for Windows andConfigEngine.sh
for all other platforms. - Make sure your 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 you do not find it, no further action is necessary and you can continue with the installation. If you do find it, delete every line that contains the textEJBDEPLOY_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
- Go and log in to HCL Software Support and download the latest zip file that corresponds to the installation on your system.
- 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.
- Create a sub-directory and extract the appropriate WP8500CFnn_ zip file
to this directory. The extraction results in a
repository.config
file that is used by IBM Installation Manager during the update.
Disabling automatic synchronization and stopping the node agents
- In the administrative console for the deployment manager, select System administration then Node agents in the navigation tree.
- Click nodeagent for the required node.
- Click File Synchronization Service.
- 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.
- Repeat these steps for all other nodes to be upgraded.
- Click Save to save the configuration changes to the master repository.
- Select System administration then Nodes in the navigation tree.
- Select all nodes that are not synchronized, and click on Synchronize.
- Select System administration then Node agents in the navigation tree.
- For the primary node and all additional nodes in all Portal clusters in the cell, select the node agents and click Stop. If you do not stop the node agents the cumulative fix configuration might fail.
Upgrading the primary node
- 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 then choose one method that is available for your system. Follow the detailed steps for that option, and then proceed with the Additional configuration steps.
- If you 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 you are using the Web server plug-in for load balancing, perform the following steps below to stop traffic to the node.
- 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.
- 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.
- Click Update to apply the change.
Use a Graphical User Interface (available on Windows, Linux, and Unix operating systems)
- Stop any active application servers and node agents by using the
stopServer
andstopNode
commands. To see which application servers are active, use theserverStatus
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 thestopManager
command from the <dmgr>/bin directory:- Unix/Linux:
./serverStatus.sh -all
- Windows:
serverStatus.bat -all
- Unix/Linux:
- Launch the IBM Installation Manager that was used to install HCL Portal Version 8.5.
- Using Installation Manager, select File > Preferences.
- Go to the Repositories panel and select Add Repository.
- Navigate to the repository.config file mentioned earlier and select it.
- Select Update and follow the prompts to update HCL Portal.
- After installation completes, proceed with the Additional configuration steps.
Use a command line (available on Windows, Linux, and Unix operating systems)
- If you are running an external web server, stop the web server.
- Stop any active application servers and node agents by using the
stopServer
andstopNode
commands. To see which application servers are active, use theserverStatus
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 thestopManager
command from the (dmgr)/bin directory:- Unix/Linux:
./serverStatus.sh -all
- Windows:
serverStatus.bat -all
- Unix/Linux:
- Open a command window and switch to the eclipse/tools
sub-directory of Installation Manager. By default, this is:
- Unix/Linux: /opt/IBM/InstallationManager/eclipse/tools
- Windows: C:\Program Files\IBM\Installation Manager\eclipse\tools
- If you are installing the cumulative fix on HCL Portal Express, skip to Step 5.
Otherwise, run the following command to launch the installation program of
Installation Manager . For Unix/Linux:For Windows:
./imcl install com.ibm.websphere.PORTAL.SERVER.v85 -repositories <fullpath/to/repository.config> -installationDirectory <portal_server_root> -acceptLicense
imcl.exe install com.ibm.websphere.PORTAL.SERVER.v85 -repositories <fullpath/to/repository.config> -installationDirectory <portal_server_root> -acceptLicense
- For HCL Portal Express only (IBM i must use silent or console mode method): Run
the following command to launch the installation program of Installation
Manager. In Linux:In Windows:
./imcl install com.ibm.websphere.PORTAL.EXPRESS.v85 -repositories (fullpath/to/repository.config) -installationDirectory (portal_server_root) -acceptLicense
imcl.exe install com.ibm.websphere.PORTAL.EXPRESS.v85 -repositories <fullpath/to/repository.config> -installationDirectory <portal_server_root> -acceptLicense
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. - After installation completes, proceed with the Additional configuration steps.
Use silent mode installation (available on Windows, Linux, Unix, and IBM i operating systems)
- Stop any active application servers and node agents by using the
stopServer
andstopNode
commands. To see which application servers are active, use theserverStatus
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 thestopManager
command from the <dmgr>/bin directory:- Unix/Linux:
./serverStatus.sh -all
- Windows:
serverStatus.bat -all
- IBM i:
serverStatus -all
- Unix/Linux:
- 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
sub-directory 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 that is packaged with your 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. Do note that the feature set
listed in your 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
features='ce.install,portal.binary,portal.profile'
. If you do not have any profiles on this node (because you are in the process of migration from a previous version of HCL Portal, or installing an additional node for a cluster, or creating multiple profiles, or you originally installed HCL Portal Version 8.5 as a binary install), then you should remove theportal.profile
feature from thefeatures='ce.install,portal.binary'
list. - Run the following command to 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 installation (available on Windows, Linux, Unix and IBM i operating systems)
- Stop any active application servers and node agents by using the
stopServer
andstopNode
commands. To see which application servers are active, use theserverStatus
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 thestopManager
command from the (dmgr)/bin directory:- Unix/Linux:
./serverStatus.sh -all
- Windows:
serverStatus.bat -all
- IBM i:
serverStatus -all
- Unix/Linux:
- 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
sub-directory 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:For Windows:
./imcl -c
For IBM i:imcl.exe -c
./imcl -c
- Add the repositories.
- Select Update and follow the prompts to update HCL Portal.
- After installation completes, proceed with the Additional configuration steps.
- 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 your HCL Portal Version 8.5 CF repository file.
- Enter A to apply your repositories and return to the Preferences menu.
- Enter R to return to the Main menu.
Additional configuration steps
If you have any profiles the following configuration steps are mandatory.
If you do not have any profiles at this point (because you are in the process of migration from a previous version of HCL Portal), no additional configuration steps are necessary and you can continue with the Restoring IP traffic steps described below.
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.
- 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:
<profile_root>/bin/osgiCfgInit.sh|bat
applyCF.sh -Dskip.profile.template.update=true
ConfigEngine.sh cf-create-profile-templates
- Ensure the
nodeagent
and HCL Portal servers are stopped on the profile you intend to upgrade. The Deployment Manager must be started. - On the Farm Master Server execute the following command from within the path of the profile
to configure: If you 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>
applyCF
command fails for any reason, check the error logs and correct error conditions before re-running. - Unix/Linux:
- 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 theapplyCF
command.- 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 Notes:- If you are applying CF200 to fix an SSRF security vulnerability, ensure that you run
the following
command:
where /opt/IBM/WebSphere/PortalServer/ is the installation directory path../ConfigEngine.sh delete-outbound-http-connection-config -DOutboundProfileType=system -DConfigFileName=/opt/IBM/WebSphere/PortalServer/base/wp.proxy.config/config/templates/sys.delete.xml
- If the
applyCF
command fails for any reason, check the error logs and correct error conditions before re-running.
- Unix/Linux:
Special Consideration for empty portals
- If you have created any custom content on top of the empty portal, you must 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, you must define thexmlaccess.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
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>
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>
- Unix/Linux:
- If you exported custom content in step #1 above, you 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
- If you are using IP sprayers for load balancing, reconfigure the IP sprayers to restore traffic to the upgraded node.
- If you are using the Web server plug-in for load balancing, perform the following steps to restore traffic to the upgraded node.
- 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.
- Locate the cluster member you upgraded and change the value in the Configured weight column back to the original value.
- Click Update to apply the change.
Upgrading additional nodes
- 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
- If you 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 you are using the Web server plug-in for load balancing, perform the following steps to stop traffic to the node.
- 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.
- 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.
- Click Update to apply the change.
Use a Graphical User Interface on additional nodes (available on Windows, Linux, and Unix operating systems)
- Stop any active application servers and node agents by using the
stopServer
andstopNode
commands. To see which application servers are active, use theserverStatus
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 thestopManager
command from the (dmgr)/bin directory:- Unix/Linux:
./serverStatus.sh -all
- Windows:
serverStatus.bat -all
- Unix/Linux:
- Launch the IBM Installation Manager that was used to install HCL Portal Version 8.5
- Using Installation Manager, select File > Preferences.
- Go to the Repositories panel and select Add Repository.
- Navigate to the repository.config file mentioned earlier and select it.
- Select Update and follow the prompts to update HCL 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 (available on Windows, Linux, and Unix operating systems)
- Stop any active application servers and node agents by using the
stopServer
andstopNode
commands. To see which application servers are active, use theserverStatus
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 thestopManager
command from the (dmgr)/bin directory:- Unix/Linux:
./serverStatus.sh -all
- Windows:
serverStatus.bat -all
- Unix/Linux:
- Launch the IBM Installation Manager that was used to install HCL Portal Version 8.5
- Using Installation Manager, select File > Preferences.
- Go to the Repositories panel and select Search service repositories during installation and updates. Select Apply.
- Select Update and follow the prompts to update HCL Portal.
- 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)
- Stop any active application servers and node agents by using the
stopServer
andstopNode
commands. To see which application servers are active, use theserverStatus
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 thestopManager
command from the (dmgr)/bin directory:- Unix/Linux:
./serverStatus.sh -all
- Windows:
serverStatus.bat -all
- Unix/Linux:
- Open a command window and switch to the eclipse/tools
sub-directory of Installation Manager. By default, this is:
- Unix/Linux: /opt/IBM/InstallationManager/eclipse/tools
- Windows: C:\Program Files\IBM\Installation Manager\eclipse\tools
- If you are installing the cumulative fix on HCL 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 or Linux:For Windows:
./imcl install com.ibm.websphere.PORTAL.SERVER.v85 -repositories <fullpath/to/repository.config> -installationDirectory <portal_server_root> -acceptLicense
imcl.exe install com.ibm.websphere.PORTAL.SERVER.v85 -repositories <fullpath/to/repository.config> -installationDirectory <portal_server_root> -acceptLicense
- HCL Portal Express only (IBM i must use silent or console mode
method): 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 Linux:For Windows:
./imcl install com.ibm.websphere.PORTAL.EXPRESS.v85 -repositories <fullpath/to/repository.config> -installationDirectory <portal_server_root> -acceptLicense
imcl.exe install com.ibm.websphere.PORTAL.EXPRESS.v85 -repositories <fullpath/to/repository.config> -installationDirectory <portal_server_root> -acceptLicense
- 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)
- Stop any active application servers and node agents by using the
stopServer
andstopNode
commands. To see which application servers are active, use theserverStatus
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 thestopManager
command from the (dmgr)/bin directory:- Unix/Linux:
./serverStatus.sh -all
- Windows:
serverStatus.bat -all
- IBM i:
serverStatus -all
- Unix/Linux:
- 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
sub-directory 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 that is packaged with your 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. Do note that the feature set
listed in your 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 you do not have any profiles on this node (because you are in the process of migration from a previous version of HCL Portal, or installing an additional node for a cluster, or creating multiple profiles, or you originally installed HCL Portal Version 8.5 as a binary install), then you should remove thefeatures='ce.install,portal.binary,portal.profile'
portal.profile
feature from thefeatures='ce.install,portal.binary
list. - Run the following command to 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 on additional nodes.
Use Console Mode installation on additional nodes (available on Windows, Linux, Unix and IBM i operating systems)
- Stop any active application servers and node agents by using the
stopServer
andstopNode
commands. To see which application servers are active, use theserverStatus
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 thestopManager
command from the (dmgr)/bin directory:- Unix/Linux:
./serverStatus.sh -all
- Windows:
serverStatus.bat -all
- IBM i:
serverStatus -all
- Unix/Linux:
- 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
sub-directory 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
or Linux:
Windows:/imcl -c
IBM i:imcl.exe -c
./imcl -c
- Complete the following steps to add the repositories.
- Select Update and follow the prompts to update HCL Portal.
- After installation completes, proceed with the Additional configuration steps.
- 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 your HCL Portal Version 8.5 CF repository file.
- Enter A to apply your repositories and return to the Preferences menu.
- Enter R to return to the Main menu.
Additional configuration steps on additional nodes
If you have any profiles the following configuration steps are mandatory.
If you do not have any profiles at this point (because you are in the process of migration from a previous version of HCL Portal), no additional configuration steps are necessary and you can continue with the Restoring IP traffic steps described below.
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.
- 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:
<profile_root>/bin/osgiCfgInit.sh|bat
applyCF.sh -Dskip.profile.template.update=true
If an updated template is needed at a later time, this command can be run to do so
at any time:
ConfigEngine.sh cf-create-profile-templates
- Ensure the
nodeagent
and HCL Portal servers are stopped on the profile you intend to upgrade. The Deployment Manager must be started. - Execute the following command from within the path of the profile to configure. Do note
that if you 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>
- Unix/Linux:
- Verify that your 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 you are installing the CF on an empty portal then extra steps are required to avoid upgrade errors.
- If you have created any custom content on top of the empty portal, you must 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, you must 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>
- Unix/Linux:
- 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>
- Unix/Linux:
- If you exported custom content in step #1 above, you 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
- If you are using IP sprayers for load balancing, reconfigure the IP sprayers to restore traffic to the upgraded node.
- If you are using the Web server plug-in for load balancing, perform the following steps to restore traffic to the upgraded node.
- 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.
- Locate the cluster member you upgraded and change the value in the Configured weight column back to the original value.
- Click Update to apply the change.
Finalizing the upgrade
- In the administrative console for the deployment manager, select System administration > Node agents in the navigation tree.
- Click nodeagent for the required node.
- 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 select 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
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 you have set up a remote search server or document conversion server for use with HCL Portal Version 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 Portal Version 8.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 Digital Experience Version 8.5 Combined Cumulative Fixes applies to your environment.
- 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>
- For MLS use:
ConfigEngine.sh|bat action-is-wcm-mls-enabled
- or SMP
use:
ConfigEngine.sh|bat action-is-wcm-smp-enabled
7. 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 your web server Plug-in properties, you 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 Digital Experience to review and apply any recommended fixes.
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 5
Or it can also be done by running the following Config Engine Task:
configure-jcr-db2-dft-queryopt
The following step is required for CF12 and prior. It is not required for CF13 and later:
- Unix/Linux:
<profile_root>/ConfigEngine/ConfigEngine.sh reconfigure-jcr-for-hadr -DWasPassword=<password> -DPortalAdminPwd=<password>
- Windows:
<profile_root>\ConfigEngine\ConfigEngine.bat reconfigure-jcr-for-hadr -DWasPassword=<password> -DPortalAdminPwd=<password>
- IBM
i:
<profile_root>/ConfigEngine/ConfigEngine.sh reconfigure-jcr-for-hadr -DWasPassword=<password> -DPortalAdminPwd=<password>
Before you begin roll back
managesdk
command must be used
to switch back to JDK 7 or 7.1 before performing a rollback to CF11 or
earlier.- Changing the server context root after upgrading is an unsupported rollback path. To roll back after changing the context root, you must 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 you 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 you cannot rollback to CF07. If you have applied CF09 and have configured an empty context root you can roll back to CF08 but you would not be able to roll back if your previous CF level was CF07 or prior.
- Configuring HCL Portal from a stand-alone environment to a clustered environment after upgrading is an unsupported rollback path.
Ensure wkplc properties files are correct for roll back
- Edit the <wp_profile
root>/ConfigEngine/properties/wkplc.properties file and
ensure the following values are set correctly:
- WasRemoteHostName=<the hostname of your Dmgr>
- WasSoapPort=<the soap port of your Dmgr>
- WasUserid=<your WAS admin user>
- WasPassword=<your WAS admin pwd>
- PortalAdminId=<your Portal Admin ID>
- PortalAdminPwd=<your Portal Admin password>
- WpsHostName=<Your Portal hostname>
- WpsHostPort=<The port you use to access Portal>
- WpsContextRoot=<your Portal context root>
- Edit the <wp_profile
root>/ConfigEngine/properties/wkplc_dbdomain.properties
file and ensure the following values are set correctly:
- release.DbPassword=<your database user password>
- community.DbPassword=<your database user password>
- customization.DbPassword=<your database user password>
- jcr.DbPassword=<your database user password>
- likeminds.DbPassword=<your database user password>
- feedback.DbPassword=<your database user password>
- Edit the <wp_profile
root>/ConfigEngine/properties/wkplc_comp.properties file
and ensure the following values are set correctly:
- XmlAccessHost=<your Portal hostname>
- XmlAccessPort=<the port you use to access Portal>
Unix, Linux, Windows, and IBM i
PWordDelete=false
Disabling automatic synchronization and stopping the node agents for roll back
- In the administrative console for the deployment manager, select System administration > Node agents in the navigation tree.
- Click nodeagent for the required node.
- Click File Synchronization Service.
- 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.
- Repeat these steps for all other nodes to be downgraded.
- 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.
- For the primary node and all additional nodes in all Portal clusters in the cell, select the node agents and click Stop. If you do not stop the node agents the cumulative fix configuration might fail.
Steps to roll back the Primary node
- 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 your system. Follow the detailed steps for that option, and then proceed with the Post Rollback Steps.
- If you 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 you are using the Web server plug-in for load balancing, perform the following steps to stop traffic to the node.
- 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.
- 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.
- Click Update to apply the change.
Use a Graphical User Interface to roll back (available on Windows, Linux, and Unix operating systems)
- Stop any active application servers and node agents by using the
stopServer
andstopNode
commands. To see which application servers are active, use theserverStatus
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 thestopManager
command from the <dmgr>/bin directory:- Unix/Linux:
./serverStatus.sh -all
- Windows:
serverStatus.bat -all
- Unix/Linux:
- Launch the IBM Installation Manager that was used to install HCL Portal Version 8.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 a command line to roll back (available on Windows, Linux, and Unix operating systems)
- Stop any active application servers and node agents by using the
stopServer
andstopNode
commands. To see which application servers are active, use theserverStatus
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 thestopManager
command from the <dmgr>/bin directory:- Unix/Linux:
./serverStatus.sh -all
- Windows:
serverStatus.bat -all
- Unix/Linux:
- Open a command window and switch to the eclipse/tools
sub-directory of Installation Manager. By default, this is:
- Unix/Linux: /opt/IBM/InstallationManager/eclipse/tools
- Windows: C:\Program Files\IBM\Installation Manager\eclipse\tools
- If you are rolling back the cumulative fix on HCL 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:Windows:
./imcl rollback com.ibm.websphere.PORTAL.SERVER.v85 -installationDirectory <portal_server_root>
imcl.exe rollback com.ibm.websphere.PORTAL.SERVER.v85 -installationDirectory <portal_server_root>
- HCL Portal Express only (IBM i must use silent or console mode method): 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 Linux:
For Windows:./imcl rollback com.hcl.websphere.PORTAL.EXPRESS.v85 -installationDirectory <portal_server_root>
imcl.exe rollback com.ibm.websphere.PORTAL.EXPRESS.v85 -installationDirectory <portal_server_root>
- 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)
- Stop any active application servers and node agents by using the
stopServer
andstopNode
commands. To see which application servers are active, use theserverStatus
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 thestopManager
command from the <dmgr>/bin directory:- Unix/Linux:
./serverStatus.sh -all
- Windows:
serverStatus.bat -all
- IBM i:
serverStatus -all
- Unix/Linux:
- 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
sub-directory 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 that is 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.
Use Console Mode to roll back (available on Windows, Linux, Unix and IBM i operating systems)
- Stop any active application servers and node agents by using the
stopServer
andstopNode
commands. To see which application servers are active, use theserverStatus
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 thestopManager
command from the <dmgr>/bin directory:- Unix/Linux:
./serverStatus.sh -all
- Windows:
serverStatus.bat -all
- IBM i:
serverStatus -all
- Unix/Linux:
- For IBM i only: Run the following command from qshell:
chown QEJBSVR /IBM/UserData/WebSphere/AppServer/V85/ND/profiles/cw_profile/ConfigEngine/properties/wkplc.properties
- Open a command window and switch to the eclipse/tools
sub-directory 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:Windows:
./imcl -c
IBM i:imcl.exe -c
./imcl -c
- Select Roll back and follow the prompts to roll back HCL 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.
1. Ensure the nodeagent
and HCL Portal and HCL Web Content
Manager
servers are stopped on the profile you intend to rollback. The
Deployment Manager must be started.
isEmptyPortal
property on the command line (Example:
rollbackCF.sh -DisEmptyPortal=true
): - 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>
rollbackCF
command fails for any reason,
check the error logs and correct error conditions, then stop HCL 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, you must perform the same customization on the restored version of each file.
4. Verify that your system is operational by entering the server's URL in a browser and logging in to browse the content.
- If you are using IP sprayers for load balancing, reconfigure the IP sprayers to restore traffic to the downgraded node.
- If you are using the Web server plug-in for load balancing, perform the following steps to restore traffic to the downgraded node.
- If you are using the Web server plug-in for load balancing, perform the
following steps to restore traffic to the downgraded node:
- 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.
- 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 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 you 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
- 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 your system. Follow the detailed steps for that option, and then proceed with the Post Rollback Steps on additional nodes.
- If you 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 you are using the Web server plug-in for load balancing, perform the following steps to stop traffic to the node:
- 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.
- 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.
- Click Update to apply the change.
Use a Graphical User Interface to roll back on additional nodes (available on Windows, Linux, and Unix operating systems)
- Stop any active application servers and node agents by using the
stopServer
andstopNode
commands. To see which application servers are active, use theserverStatus
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 thestopManager
command from the <dmgr>/bin directory:- Unix/Linux:
./serverStatus.sh -all
- Windows:
serverStatus.bat -all
- Unix/Linux:
- Launch the IBM Installation Manager that was used to install HCL Portal Version 8.5.
- Select Roll Back on the Installation Manager main window and follow the prompts to roll HCL 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 (available on Windows, Linux, and Unix operating systems)
- Stop any active application servers and node agents by using the
stopServer
andstopNode
commands. To see which application servers are active, use theserverStatus
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 thestopManager
command from the <dmgr>/bin directory:- Unix/Linux:
./serverStatus.sh -all
- WIndows:
serverStatus.bat -all
- Unix/Linux:
- Open a command window and switch to the eclipse/tools sub-directory of
Installation Manager. By default, this is:
- Unix/Linux: /opt/IBM/InstallationManager/eclipse/tools
- Windows: C:\Program Files\IBM\Installation Manager\eclipse\tools
- If you are rolling back the cumulative fix on HCL 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:Windows:
./imcl rollback com.ibm.websphere.PORTAL.SERVER.v85 -installationDirectory <portal_server_root>
imcl.exe rollback com.hcl.websphere.PORTAL.SERVER.v85 -installationDirectory <portal_server_root>
- HCL Portal Express only (IBM i must use silent or console mode method): 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 Linux:Windows:
./imcl rollback com.hcl.websphere.PORTAL.EXPRESS.v85 -installationDirectory <portal_server_root>
imcl.exe rollback com.ibm.websphere.PORTAL.EXPRESS.v85 -installationDirectory <portal_server_root>
- 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)
- Stop any active application servers and node agents by using the
stopServer
andstopNode
commands. To see which application servers are active, use theserverStatus
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 thestopManager
command from the <dmgr>/bin directory:- Unix/Linux:
./serverStatus.sh -all
- Windows:
serverStatus.bat -all
- IBM i:
serverStatus -all
- Unix/Linux:
- 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
sub-directory 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 that is 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 on additional nodes.
Use Console Mode to roll back on additional nodes (available on Windows, Linux, Unix and IBM i operating systems)
- Stop any active application servers and node agents by using the
stopServer
andstopNode
commands. To see which application servers are active, use theserverStatus
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 thestopManager
command from the <dmgr>/bin directory:- Unix/Linux:
./serverStatus.sh -all
- Windows:
serverStatus.bat -all
- IBM i:
serverStatus -all
- Unix/Linux:
- 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
sub-directory 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:Windows:
./imcl -c
IBM i:imcl.exe -c
./imcl -c
- Select Roll back and follow the prompts to roll back HCL Portal.
- 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.
- Ensure the
nodeagent
andHCL Portal and HCL Web Content Manager
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
you must define the
isEmptyPortal
property on the command line (Example:rollbackCF.sh -DisEmptyPortal=true
):- 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>
rollbackCF
command fails for any reason, check the error logs and correct error conditions, then stopHCL Portal and HCL Web Content Manager
before re-running. - Unix/Linux:
- 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, you must perform the same customization on the restored version of each file.
- Verify that your system is operational by entering the server's URL in a browser and logging in to browse the content.
- If you are using IP sprayers for load balancing, reconfigure the IP sprayers to restore traffic to the downgraded node.
- If you are using the Web server plug-in for load balancing, perform the following steps to restore traffic to the downgraded node.
- 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.
- 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 you 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
- In the administrative console for the deployment manager, select System administration > Node agents in the navigation tree.
- Click nodeagent for the required node.
- 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 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 you have set up a remote search server or document conversion server for use with HCL Portal Version 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. Refer to the HCL Portal Version 8.5 combined cumulative fix instructions: remote search for the details of rolling back a cumulative fix to the remote server.
- 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>
- for MLS
use:
ConfigEngine.sh|bat action-is-wcm-mls-enabled
- for SMP
use:
ConfigEngine.sh|bat action-is-wcm-smp-enabled
- Uninstall the old Brightcove plugins.
- Install the new Brightcove plugins by following the install steps in the Configuring topic section to use Brightcove.
- 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 your web server Plug-in properties, you will need to manually generate and/or propagate the plugin-cfg.xml file to the Web servers.
8. Clear the browser cache.