6.1.0.5: Readme for IBM WebSphere Portal 6.1 fix pack 5 (6.1.0.5) - cluster

Content

6.1.0.5: Readme for IBM WebSphere Portal 6.1 fix pack 5 (6.1.0.5) - cluster

Table of Contents

• About Fix Pack 6.1.0.5
• Space requirements
• Stand-alone installation instructions
• Cluster upgrade planning
• Steps for installing Fix Pack 6.1.0.5
• Steps for uninstalling Fix Pack 6.1.0.5
• Known issues
• Change History
• Additional information
• Trademarks and service marks

---

About Fix Pack 6.1.0.5

• Installing Fix Pack 6.1.0.5 with the latest WebSphere Portal Update Installer for version 6.1 raises the fix level of your product to version 6.1.0.5. If the 6.1.5 feature pack is enabled on 6.1.0.3, this fix pack upgrades the 6.1.5 features to the level 6.1.5.2. If you are upgrading to 6.1.0.5 from version 6.1.0, 6.1.0.1, or 6.1.0.2 and you want to enable the feature pack, first upgrade to 6.1.0.5 and then perform the steps to install the Feature Pack 6.1.5 fix pack 2.
• Refer to the installation instructions in the Steps for installing Fix Pack 6.1.0.5 section for information.
• Fix packs can be downloaded from the version 6.1.0.5 download page, also linked above on the "Download" tab of this document.

Warning:

• You must use the latest Portal Update Installer in order to successfully install this fix pack.

Special note:

• This fix pack and these instructions can also be used for a WebSphere Portal Express - Idle Standby deployment. However, the terminology used in this document is different. IBM WebSphere Portal Express is licensed for use in a single-server configuration and may not be used in either a cloned or a clustered configuration except when you implement Idle Standby for purposes of failover. Implementing the Idle Standby functionality requires purchase of a separate WebSphere Portal Express Idle Standby License Option.
  
• The following items are included in this fix pack:

• Updated underlying supported hardware and software. Refer to supported hardware and software requirements for details
• Included APARs from many WebSphere Portal components
• WebSphere Portal can be upgraded to 6.1.5.2. After upgrading to Portal 6.1.0.5, to upgrade to Portal 6.1.5.2 see 6.1.5.2: Readme for IBM WebSphere Portal 6.1.5 fix pack 2 (6.1.5.2) - cluster for details.
• The complete list of fixes integrated into this fix pack is found on the "Fix List" tab of this document.

Back to top

---

Space requirements

• Ensure that enough space is available in the following directories: 2 GB in the directory that you download the fix pack to, 1 GB in <Portal_Install_Root>, 1 GB in <wp_profile> temporarily disk space and 1 GB in your system temp directory, such as /tmp on Unix or Linux platforms or C:\temp on the Microsoft Windows platform.

Back to top

---

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 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. Please see the following document for details: Multiple Cluster Setup with WebSphere Portal
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.

For single cluster environments, which cannot tolerate the outage required to take a cluster offline and perform the upgrade, you can utilize the single-cluster 24x7 availability process. Review the following requirements and limitations for performing product upgrades while maintaining 24x7 availability in a single cluster (NOTE: Ensure that you understand this information before upgrading your cluster):

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:
• 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 fix pack 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.
• 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.
• When installing the fix pack in a clustered environment, the portlets are only deployed when installing the fix pack on the primary node. The fix pack 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 fix pack installation on the primary node and the installation of the fix pack on the additional node.
• In order to maintain 24x7 operations in a clustered environment, it is required that you stop WebSphere Portal on one node at a time and upgrade it. It is also required that during the upgrade of the primary node, you manually stop node agents on all other cluster nodes that continue to service user requests. Failure to do so may result in portlets being shown as unavailable on nodes having the node agent running.
• When uninstalling the fix pack in a clustered environment, the portlets are only redeployed when uninstalling the fix pack on the primary node. The fix pack uninstall 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 uninstalling 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.

Back to top

---

Steps for installing Fix Pack 6.1.0.5 (single-cluster procedure)


NOTE: When instructed to stop or start the WebSphere_Portal server, stop or start all Portal server instances including vertical cluster members on the node.

1. Perform the following steps before upgrading to Version 6.1.0.5:
1. Review the supported hardware and software requirements for this fix pack. If necessary, upgrade all hardware and software before applying this fix pack. If updates are required to WebSphere Application Server level, perform that update on all nodes and on the Deployment Manager accordingly. NOTE: You can download the latest WebSphere Application Server interim fixes from http://www.ibm.com/software/webservers/appserv/was/support/.
2. Check to see that wp.base.jar file exists on the deployment mananger in the <was_home>/plugins directory. If the file does not exists then run the following steps:
1. Stop the deployment manager.
2. Copy the following file from the Primary Node to AppServer/plugins on the deployment manager:
• Primary Node: <wp_home>/base/wp.base/shared/app/wp.base.jar
• Deployment Manager: <was_home>/plugins/wp.base.jar
  
3. Start the deployment manager.
3. Verify that the information in the wkplc.properties, wkplc_dbtype.properties, and wkplc_comp.properties files is correct on each node in the cluster:
1. Enter a value for the PortalAdminPwd and WasPassword parameters in the wkplc.properties file.
2. Ensure that the DbUser (database name) and DbPassword (database password) parameters are defined correctly for all database domains in the wkplc_comp.properties file.
3. The WebSphere Portal Update Installer 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.
4. Ensure that the value of the XmlAccessPort property in wkplc_comp.properties matches the value of the port used for HTTP connections to the WebSphere Portal server.
4. Perform the following steps to download the fix pack and the WebSphere Portal Update Installer:
1. Download the fix pack file, the ptflist file, and latest WebSphere Portal Update Installer from http://www.ibm.com/support/docview.wss?uid=swg24027475.
2. Create the portal_server_root/update directory and extract the WebSphere Portal Update Installer file into this directory.
3. Create the portal_server_root/update/fixpacks directory and copy the WP_PTF_6105.jar file and the ptflist file into this directory.
5. The WebSphere Portal 6.1.0.5 fix pack performs index (schema) modifications to the Portal databases during the fix pack application. Please see the following documentation for the details: http://www.ibm.com/support/docview.wss?uid=swg27019861. It is possible to disable the automatic application and instead manually apply the indexes. For that, make sure the following property is set on the primary node in wkplc_dbtype.properties before starting the fix pack application: DbSafeMode=true. If DbSafeMode is not set to true then ensure that the DbUser in the wkplc_comp.properties file for all domains on DB2 has explicit DBADM authority.
6. Ensure that all nodes have been synchronized before starting to upgrade.
   
2. Ensure that automatic synchronization is disabled on all nodes to be upgraded. When the automatic synchronization is enabled, the node agent on each node automatically contacts the deployment manager at startup and then every synchronization interval to attempt to synchronize the node's configuration repository with the master repository managed by the deployment manager.
1. In the administrative console for the deployment manager, select System administration > Node agents in the navigation tree.
2. Click nodeagent for the required node.
3. Click File Synchronization Service.
4. Uncheck the Automatic Synchronization check box on the File Synchronization Service page to disable the automatic synchronization feature and then click OK.
5. Repeat these steps for all other nodes to be upgraded.
6. Click Save to save the configuration changes to the master repository.
7. Select System administration > Nodes in the navigation tree
8. Select all nodes that are not synchronized, and click on Synchronize
9. Select System administration > Node agents in the navigation tree
10. For the primary node, select the nodeagent and click Restart
11. Select the nodeagents of all additional nodes and click Stop
    
    
    NOTE: Do not attempt to combine steps 3 and 4 together! The update must be performed first on the primary node then on the additional nodes, in accordance with the below instructions.
    
    
3. Perform the following steps to upgrade WebSphere Portal on the primary node:
1. Only Required if following the 24x7 single cluster upgrade: Stop IP traffic to the node you are upgrading:
• 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:
1. In the Deployment Manager administrative console, click Servers>Clusters>cluster_name>Cluster members to obtain a view of the collection of cluster members. When using WAS 7.x (for the editions that support WAS 7.x see the hardware&software requirements doc) use the following path: click Servers>Clusters>WebSphere application server clusters>cluster_name>Cluster members.
2. Locate the cluster member you are upgrading and change the value in the Configured weight column to zero. NOTE: Record the previous value to restore the setting when the upgrade is complete.
3. Click Update to apply the change.
• If automatic plug-in generation and propagation is disabled, manually generate and/or propagate the plugin-cfg.xml file to the Web servers.
• Note that the web server plug-in will check periodically for configuration updates based on the value of Refresh Configuration Interval property for the Web server plug-in (default value is 60 seconds). You can check this value on the Deployment Manager administrative console by selecting Servers>Web Servers>web_server_name>Plug-in Properties. When using WAS 7.x (for the editions that support WAS 7.x see the hardware&software requirements doc) use the following path: click Servers>Server Types>Web Servers>web_server_name>Plug-in Properties.
• If automatic propagation of the plug-in configuration file is enabled on the web server(s) disable it from the Deployment Manager administrative console by going to Servers>Web Servers>web_server_name>Plug-in Properties and unchecking Automatically propagate plug-in configuration file. When using WAS 7.x (for the editions that support WAS 7.x see the hardware&software requirements doc) use the following path: click Servers>Server Types>Web Servers>web_server_name>Plug-in Properties.
  
  
2. Choose either the graphical user interface installation option or the command line installation option:
   
   NOTE: If the installation fails, use the IBM Support Assistant to access support-related information and serviceability tools for problem determination. For i5/OS, download ISA on a system other than i5/OS. On the Support Assistant Welcome page, click Service. Then click the Create Portable Collector link to create a remotely collect the data from your i5/OS system. Fix what is causing the problem and then rerun the installation task.
   
   
   If using the Universal PUI, (which does not include the bundled Java environment), run the following command, setupCmdLine.bat for Windows or . ./setupCmdLine.sh for Unix/Linux from the was_profile_root/bin directory to set up the Java environment for the graphical user interface installation program.
   
   
   Enter the following command to launch the graphical user interface installation program:
• Windows: portal_server_root\update> updatePortalWizard.bat
• Unix/Linux: portal_server_root/update> ./updatePortalWizard.sh
  
  -- OR --
• Perform the following steps to launch the installation program from the command line:
1. Ensure to stop any active application servers using the stopServer command. To see which application servers are active use the serverStatus command.
2. Enter the following command to launch the installation program (NOTE: Enter the command on one line):
• Windows: PortalServer_root\update> updatePortal.bat -install
  -installDir "<PortalServer_root>"
  -fixpack
  -fixpackDir "<PortalServer_root>\update\fixpacks"
  -fixpackID WP_PTF_6105
• Unix/Linux: portal_server_root/update> ./updatePortal.sh -install
  -installDir "<PortalServer_root>"
  -fixpack
  -fixpackDir "<PortalServer_root>/update/fixpacks"
  -fixpackID WP_PTF_6105
• i5/OS: portal_server_root/update> updatePortal.sh -install
  -installDir "<PortalServer_root_user>"
  -fixpack
  -fixpackDir "<portal_server_root>/update/fixpacks"
  -fixpackID WP_PTF_6105
  
  
3. Verify that your system is operational by entering the server's URL in a browser and logging in to browse the content.
4. If you upgraded from a prior release with additional interim fixes installed, you must reinstall any interim fixes that were not integrated into the version 6.1.0.5 installation. Open the CheckAdditionalEfixes_date_time.log file, located in the portal_server_root/version/log directory, for the list of interim fixes that must be reinstalled. Before reinstalling the interim fix, go to the WebSphere Portal product support page to see if there is a newer version of the interim fix because these are often specific to a version and release of the product; and search on the APAR number to find more information.
5. Install any APARs that must be applied. Refer to the Recommended fixes and updates for the WebSphere Portal and Web Content Manager page.
6. Only Required if following the 24x7 single cluster upgrade: Restore IP traffic to the node you upgraded:
• 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:
1. In the Deployment Manager administrative console, click Servers>Clusters>cluster_name>Cluster members to obtain a view of the collection of cluster members. When using WAS 7.x (for the editions that support WAS 7.x see the hardware&software requirements doc) use the following path: click Servers>Clusters>WebSphere application server clusters>cluster_name>Cluster members.
2. Locate the cluster member you upgraded and change the value in the Configured weight column back to the original value.
3. Click Update to apply the change.
• If you previously disabled automatic propagation of the Web server(s), re-enable it now using the Deployment Manager administration console by going to Servers>Web Servers>web_server_name>Plug-in Properties and checking Automatically propagate plug-in configuration file . When using WAS 7.x (for the editions that support WAS 7.x see the hardware&software requirements doc) use the following path: click Servers>Server Types>Web Servers>web_server_name>Plug-in Properties.
• 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.
  
  NOTE: Do not attempt to upgrade additional nodes until after completing Step 3 (Primary Node)! The update for the primary must be performed and completed first then upgrade any additional nodes. Additional nodes upgrades can be performed sequentially or in parallel. Update the additional nodes in accordance with the below instructions.
4. Perform the following steps to upgrade WebSphere Portal on each additional node after completing the upgrade on the primary node:
1. Only Required if following the 24x7 single cluster upgrade: Stop IP traffic to the node you are upgrading:
• If you are using IP sprayers for load balancing, reconfigure the IP sprayers to stop routing new requests to the node.
• If you are using the Web server plug-in for load balancing, perform the following steps to stop traffic to the node:
1. In the Deployment Manager administrative console, click Servers>Clusters>cluster_name>Cluster members to obtain a view of the collection of cluster members. When using WAS 7.x (for the editions that support WAS 7.x see the hardware&software requirements doc) use the following path: click Servers>Clusters>WebSphere application server clusters>cluster_name>Cluster members.
2. Locate the cluster member you are upgrading and change the value in the Configured weight column to zero. NOTE: Record the previous value to restore the setting when the upgrade is complete.
3. Click Update to apply the change.
• If automatic plug-in generation and propagation is disabled, manually generate and/or propagate the plugin-cfg.xml file to the Web servers.
• Note that the web server plug-in will check periodically for configuration updates based on the value of Refresh Configuration Interval property for the Web server plug-in (default value is 60 seconds). You can check this value on the Deployment Manager administrative console by selecting Servers>Web Servers>web_server_name>Plug-in Properties. When using WAS 7.x (for the editions that support WAS 7.x see the hardware&software requirements doc) use the following path: click Servers>Server Types>Web Servers>web_server_name>Plug-in Properties.
2. Choose either the graphical user interface installation option or the command line installation option:
   
   NOTE: If the installation fails, use the IBM Support Assistant to access support-related information and serviceability tools for problem determination. For i5/OS, download ISA on a system other than i5/OS. On the Support Assistant Welcome page, click Service. Then click the Create Portable Collector link to create a remotely collect the data from your i5/OS system. Fix what is causing the problem and then rerun the installation task.
   
   If using the Universal PUI, (which does not include the bundled Java environment), run the following command, setupCmdLine.bat for Windows or . ./setupCmdLine.sh for Unix/Linux from the was_profile_root/bin directory to set up the Java environment for the graphical user interface installation program.
   
   Enter the following command to launch the graphical user interface installation program:
• Windows: portal_server_root\update> updatePortalWizard.bat
• Unix/Linux: portal_server_root/update> ./updatePortalWizard.sh
  
  -- OR --
• Perform the following steps to launch the installation program from the command line:
1. Ensure to stop any active application servers using the stopServer command. To see which application servers are active use the serverStatus command.
2. Enter the following command to launch the installation program (NOTE: Enter the command on one line):
• Windows: PortalServer_root\update> updatePortal.bat -install
  -installDir "<PortalServer_root>"
  -fixpack
  -fixpackDir "<PortalServer_root>\update\fixpacks"
  -fixpackID WP_PTF_6105
• Unix/Linux: PortalServer_root/update> ./updatePortal.sh -install
  -installDir "<PortalServer_root>"
  -fixpack
  -fixpackDir "<PortalServer_root>/update/fixpacks"
  -fixpackID WP_PTF_6105
• i5/OS: portal_server_root/update> updatePortal.sh -install
  -installDir "<PortalServer_root_user>"
  -fixpack
  -fixpackDir "<portal_server_root>/update/fixpacks"
  -fixpackID WP_PTF_6105
  
  
3. Verify that your system is operational by entering the server's URL in a browser and logging in to browse the content.
4. If you upgraded from a prior release with additional interim fixes installed, you must reinstall any interim fixes that were not integrated into the version 6.1.0.5 installation. The following list shows you which fixes were not integrated. You can also check later by opening the CheckAdditionalEfixes_date_time.log file, located in the portal_server_root/version/log directory, for the list of interim fixes that must be reinstalled. Before reinstalling the interim fix, go to the WebSphere Portal product support page to see if there is a newer version of the interim fix because these are often specific to a version and release of the product; and search on the APAR number to find more information.
5. Install any APARs that must be applied. See the Recommended fixes and updates for the WebSphere Portal and Web Content Manager page.
6. Only Required if following the 24x7 single cluster upgrade: Restore IP traffic to the node you upgraded:
• 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:
1. In the Deployment Manager administrative console, click Servers>Clusters>cluster_name>Cluster members to obtain a view of the collection of cluster members. When using WAS 7.x (for the editions that support WAS 7.x see the hardware&software requirements doc) use the following path: click Servers>Clusters>WebSphere application server clusters>cluster_name>Cluster members.
2. Locate the cluster member you upgraded and change the value in the Configured weight column back to the original value.
3. Click Update to apply the change.
• If automatic plug-in generation and propagation is disabled, manually generate and/or propagate the plugin-cfg.xml file to the Web servers.
5. Perform the following post-cluster installation upgrade steps:
1. Re-enable automatic synchronization on all nodes in the cluster if you disabled it earlier.
1. In the administrative console for the deployment manager, select System administration > Node agents in the navigation tree.
2. Click nodeagent for the required node.
3. Click File Synchronization Service.
4. Check the Automatic Synchronization check box on the File Synchronization Service page to enable the automatic synchronization feature and then click OK.
5. Repeat these steps for all remaining nodes.
6. Click Save to save the configuration changes to the master repository.
7. Select System administration > Nodes in the navigation tree
8. Select all nodes that are not synchronized, and click on Synchronize
9. Select System administration > Node agents in the navigation tree
10. Select all node agents where automatic synchronization has been re-enabled and click Restart.
    
2. Perform the following steps if you are using Web Content Manager and you created content on the release you upgraded from:
   
1. Redeploy your customization, including JSPs, to the local rendering portlet.
2. Run ConfigEngine.sh|bat update-properties on the primary node.
3. Restart all Portal Servers in the Cluster.
4. If the portal version you are upgrading from is lower than 6.1.0.1 plus PK76129 (Cumulative iFix 1 for WCM v6.1.0.1) and the portal has Web Content data, then run the following steps:
   
   To ensure all scheduled actions are reset, run the run-wcm-admin-task-schedule-actions task from the wp_profile_root/ConfigEngine directory.
   
   To reschedule all libraries and preserve the last saved date of each item:
• Windows : ConfigEngine.bat run-wcm-admin-task-schedule-actions -DallLibraries=true -DpreserveDates=true -DPortalAdminId=username -DPortalAdminPwd=password
• UNIX: ./ConfigEngine.sh run-wcm-admin-task-schedule-actions -DallLibraries=true -DpreserveDates=true -DPortalAdminId=username -DPortalAdminPwd=password
• i5/OS: ConfigEngine.sh -profileName profile_root run-wcm-admin-task-schedule-actions -DallLibraries=true -DpreserveDates=true -DPortalAdminId=username -DPortalAdminPwd=password
  where profile_root is the name of the IBM WebSphere Application Server profile where WebSphere Portal is installed; for example, wp_profile
  
  
  To reschedule a single library and preserve the last saved date of each item:
• Windows: ConfigEngine.bat run-wcm-admin-task-schedule-actions -Dlibrary=libraryname -DpreserveDates=true -DPortalAdminId=username -DPortalAdminPwd=password
• UNIX: ./ConfigEngine.sh run-wcm-admin-task-schedule-actions -Dlibrary=libraryname -DpreserveDates=true -DPortalAdminId=username -DPortalAdminPwd=password
• i5/OS: ConfigEngine.sh -profileName profile_root run-wcm-admin-task-schedule-actions -Dlibrary=libraryname -DpreserveDates=true -DPortalAdminId=username -DPortalAdminPwd=password
  where profile_root is the name of the IBM WebSphere Application Server profile where WebSphere Portal is installed; for example, wp_profile.
  
3. Optional: The WebSphere Portal 6.1.0.5 fix pack does not update any of the business portlets or Web Clipping portlet as these are served from the IBM WebSphere Portal Business Solutions catalog. If this fix pack is updating a fresh installation of WebSphere Portal, you should download the latest available portlets and portlet applications from the Portal Catalog. If you already have the version of the business portlets or Web Clipping portlet you need or if you are not using these functions at all, no additional steps are necessary.
   
4. If you have customized the AJAX proxy (by editing proxy-config.xml) you must redo the customizations after the 6.1.0.5 fix pack upgrade. Follow these steps:
1. Compare the backup copy of your customized file that is stored in the directory ${WP_PROFILE}/ConfigEngine/config/backup_files/<date>/... with the new 6.1.0.5 file in ${WP_PROFILE}/config/cells/<cell>/applications/AJAX Proxy Configuration.ear/deployments/AJAX Proxy Configuration/wp.proxy.config.war/WEB-INF/proxy-config.xml
2. Merge your customization into the new file
3. Deploy the updated proxy-config.xml with the following steps described in the InfoCenter http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1/topic/com.ibm.wp.ent.doc_v615/dev/ajax_proxy_globl_cfg.html.
   
5. If you disabled database updates during the 6105 upgrade by setting DbSafeMode=true,then do the following:
1. Edit wkplc_dbtype.properties and set DbSafeMode=false.
2. Manually apply all database changes manually as explained here: http://www.ibm.com/support/docview.wss?uid=swg27019861
   
6. Optional: If coming from a release prior to 6.1.0.4 and when using the Web Content Manager JSR 286 portlet and using the default Portal theme for Web Content Manager Rendering, see the following document for improving the rendering performance: WebSphere Portal 6.1.0.5 Base Tag change.
   
7. If upgrading from WebSphere Portal 6.1.5 to 6.1.5.2 and using the share pages feature or the creation of templates in mashups: With WebSphere Portal 6.1.5.1, the default access control default behavior was changed to prevent possible security exposures in case of malicious users. With the changed behavior certain functions in WebSphere Portal cannot be used any more by non admin users. See the following document for details on those changes and how to enable the functionality again for certain users: WebSphere Portal Access Control default behavior changes to prevent security exposure.
   
8. Optional: If using Web Content Manager and this step was not done in 6.1.0.4, you can apply indexes to the JCR database that will help with performance: Run the JCR database schema migration to update the database indexes on the primary node (there is no need to run the task on the secondary nodes). Run the following task - replace <previous version> with 6.1.0.0 or 6.1.0.1 or 6.1.0.2 or 6.1.0.3 or 6.1.0.4 depending which release you are upgrading from. If you are upgrading from 6.1.5 use 6.1.0.3 for <previous version>:
   
• Windows: ConfigEngine.bat upgrade-jcr-database-601x-to-6100 -DPreviousPortalVersion=<previous version> -DWasPassword=<WasPassword> -Djcr.DbPassword=<jcrdb password>
• Unix/Linux: ./ConfigEngine.sh upgrade-jcr-database-601x-to-6100 -DPreviousPortalVersion=<previous version> -DWasPassword=<WasPassword> -Djcr.DbPassword=<jcrdb password>
• i5/OS: ConfigEngine.sh upgrade-jcr-database-601x-to-6100 -DPreviousPortalVersion=<previous version> -DWasPassword=<WasPassword> -Djcr.DbPassword=<jcrdb password>
  
9. After performing upgrade to 6105, refer to database specific product information to ensure a reorg/runstats command has been run to ensure proper database performance.

Back to top

---

Steps for uninstalling Fix Pack 6.1.0.5 (single-cluster procedure)

Perform the following steps to uninstall a fix pack from a clustered environment:

NOTE: If WebSphere Portal feature pack 6.1.5.x has been enabled after a fix pack upgrade then before the fix pack can be uninstalled the WebSphere Portal feature pack 6.1.5.x must be uninstalled first. For example: If the WebSphere Portal feature pack 6.1.5.2 is enabled after upgrading to 6.1.0.5, then 6.1.5.2 must be uninstalled before uninstalling 6.1.0.5. See 6.1.5.2: Readme for IBM WebSphere Portal 6.1.5 fix pack 2 (6.1.5.2) - cluster for details on uninstalling feature pack.

NOTE: Changing the server context root after upgrading is an unsupported uninstall path. To uninstall after changing the context root, you must first change the server context root back to the values of the previous version.
An example of an unsupported uninstall path is: Install Portal 6.1.0 or 6.1.0.1 --> upgrade Portal --> change server context root --> uninstall upgrade.
An example of a supported uninstall path is: Install Portal 6.1.0 or 6.1.0.1 --> change server context root --> upgrade Portal --> uninstall upgrade.

NOTE: Configuring Portal Server from a stand-alone environment to a cluster environment after upgrading is an unsupported uninstall path.

NOTE: When instructed to stop or start the WebSphere_Portal server, stop or start all Portal server instances including vertical cluster members on the node.

1. Perform the following steps before you uninstall the Version 6.1.0.5 fix pack:
   
   NOTE: The steps listed in this point must be performed on all nodes.
1. Ensure that you have enough free space allocated for your operating system in the appropriate directories.
2. Verify that the information in the wkplc.properties, wkplc_dbtype.properties, and wkplc_comp.properties files are correct on each node in the cluster.
• Enter a value for the PortalAdminPwd and WasPassword parameters in the wkplc.properties file.
• Ensure that the DbUser (database name) and DbPassword (database_password) properties are defined correctly for all database domains in the wkplc_comp.properties file.
• The WebSphere Portal Update Installer 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.
• Ensure that the value of the XmlAccessPort property in wkplc_comp.properties matches the value of the port used for HTTP connections to the WebSphere Portal server.
3. Ensure that all nodes have been synchronized before starting to uninstall.
4. The WebSphere Portal 6.1.0.5 fix pack performs index (schema) modifications to the Portal databases during the fix pack application. Please see the following documentation for the details: http://www.ibm.com/support/docview.wss?uid=swg27019861. It is possible to disable the automatic application and instead manually apply the indexes. For that, make sure the following property is set on the primary node in wkplc_dbtype.properties before starting the fix pack application: DbSafeMode=true. If DbSafeMode is not set to true then ensure that the DbUser in the wkplc_comp.properties file for all domains on DB2 has explicit DBADM authority.
2. Perform the following steps to disable automatic synchronization:
1. In the administrative console for the deployment manager, select System administration>Node agents in the navigation tree.
2. Click nodeagent for the required node.
3. Click File Synchronization Service.
4. Uncheck the Automatic Synchronization check box on the File Synchronization Service page to disable the automatic synchronization feature and then click OK.
5. Repeat these steps for all other nodes to be downgraded.
6. Click Save to save the configuration changes to the master repository.
7. Select System administration > Nodes in the navigation tree.
8. Select all nodes that are not synchronized, and click on Synchronize.
9. Select System administration > Node agents in the navigation tree.
10. For the primary node, select the nodeagent and click Restart.
11. Select the nodeagents of all additional nodes and click Stop.
    
    
    
    NOTE: Do not attempt to combine steps 3 and 4 together! The uninstall must be performed first on the primary node then on the additional nodes, in accordance with the below instructions.
    
3. Perform the following steps to uninstall the fix pack on the primary node:
1. Only Required if following the 24x7 single cluster uninstall: Stop IP traffic to the node where you are uninstalling:
• If you are using IP sprayers for load balancing, reconfigure the IP sprayers to stop routing new requests to the node.
• If you are using the Web server plug-in for load balancing, perform the following steps to stop traffic to the node:
1. In the Deployment Manager administrative console, click Servers>Clusters>cluster_name>Cluster members to obtain a view of the collection of cluster members. When using WAS 7.x (for the editions that support WAS 7.x see the hardware&software requirements doc) use the following path: click Servers>Clusters>WebSphere application server clusters>cluster_name>Cluster members.
2. Locate the cluster member you are downgrading and change the value in the Configured weight column to zero. NOTE: Record the previous value to restore the setting when the downgrade is complete.
3. Click Update to apply the change.
• If automatic plug-in generation and propagation is disabled, manually generate and/or propagate the plugin-cfg.xml file to the Web servers.
• Note that the web server plug-in will check periodically for configuration updates based on the value of Refresh Configuration Interval property for the Web server plug-in (default value is 60 seconds). You can check this value on the Deployment Manager administrative console by selecting Servers>Web Servers>web_server_name>Plug-in Properties. When using WAS 7.x (for the editions that support WAS 7.x see the hardware&software requirements doc) use the following path: click Servers>Server Types>Web Servers>web_server_name>Plug-in Properties.
• If automatic propagation of the plug-in configuration file is enabled on the web server(s) disable it from the Deployment Manager administrative console by going to Servers>Web Servers>web_server_name>Plug-in Properties and unchecking Automatically propagate plug-in configuration file. When using WAS 7.x (for the editions that support WAS 7.x see the hardware&software requirements doc) use the following path: click Servers>Server Types>Web Servers>web_server_name>Plug-in Properties.
2. Choose either the graphical user interface uninstallation option or the command line uninstallation option:
   
   NOTE: If the uninstallation fails, use the IBM Support Assistant to access support-related information and serviceability tools for problem determination. For i5/OS, download ISA on a system other than i5/OS. On the Support Assistant Welcome page, click Service. Then click the Create Portable Collector link to create a remotely collect the data from your i5/OS system. Fix what is causing the problem and then rerun the installation task.
   
   
   If using the Universal PUI, (which does not include the bundled Java environment), run the following command, setupCmdLine.bat for Windows or . ./setupCmdLine.sh for Unix/Linux from the was_profile_root/bin directory to set up the Java environment for the graphical user interface installation program.
• Enter the following command to launch the graphical user interface uninstallation program:
• Windows: portal_server_root\update> updatePortalWizard.bat
• Unix/Linux: portal_server_root/update> ./updatePortalWizard.sh
  
  - OR -
• Perform the following steps to launch the uninstallation program from the command line:
1. Ensure to stop any active application servers using the stopServer command. To see which application servers are active use the serverStatus command.
2. Enter the following command to launch the uninstallation program (NOTE: Enter the command on one line):
• Windows: PortalServer_root\update> updatePortal.bat -uninstall
  -installDir "<PortalServer_root>"
  -fixpack
  -fixpackID WP_PTF_6105
• Unix/Linux: PortalServer_root/update> ./updatePortal.sh -uninstall
  -installDir "<PortalServer_root>"
  -fixpack
  -fixpackID WP_PTF_6105
• i5/OS: portal_server_root/update> updatePortal.sh -uninstall
  -installDir "<PortalServer_root_user>"
  -fixpack
  -fixpackID WP_PTF_6105
3. If you previously customized any configuration files in the portal_server_root/config directory (<portal_server_root_user>/config directory for iSeries), check to see if uninstalling the fix pack 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.
5. Only Required if following the 24x7 single cluster uninstall: Restore IP traffic to the node where you uninstalled:
• If you are using the 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:
1. In the Deployment Manager administrative console, click Servers>Clusters>cluster_name>Cluster members to obtain a view of the collection of cluster members. When using WAS 7.x (for the editions that support WAS 7.x see the hardware&software requirements doc) use the following path: click Servers>Clusters>WebSphere application server clusters>cluster_name>Cluster members.
2. Locate the cluster member you downgraded and change the value in the Configured weight column back to the original value.
3. Click Update to apply the change.
• If you previously disabled automatic propagation of the Web server(s), re-enable it now using the Deployment Manager administration console by going to Servers>Web Servers>web_server_name>Plug-in Properties and checking Automatically propagate plug-in configuration file. When using WAS 7.x (for the editions that support WAS 7.x see the hardware&software requirements doc) use the following path: click Servers>Server Types>Web Servers>web_server_name>Plug-in Properties.
• If automatic plug-in generation and propagation is disabled, manually generate and/or propagate the plugin-cfg.xml file to the Web servers.
  
  NOTE: Do not attempt to uninstall additional nodes until after completing the Step 3 (Primary Node)! The uninstall for the primary must be performed and completed first then uninstall any additional nodes. Additional nodes uninstalls can be performed sequentially or in parallel. uninstall the additional nodes in accordance with the below instructions.
4. Perform the following steps to uninstall the fix pack on the additional node; NOTE: Repeat this step for each additional node:
1. Only Required if following the 24x7 single cluster uninstall: Stop IP traffic to the node where you are uninstalling:
• If you are using IP sprayers for load balancing, reconfigure the IP sprayers to stop routing new requests to the node.
• If you are using the Web server plug-in for load balancing, perform the following steps to stop traffic to the node:
1. In the Deployment Manager administrative console, click Servers>Clusters>cluster_name>Cluster members to obtain a view of the collection of cluster members. When using WAS 7.x (for the editions that support WAS 7.x see the hardware&software requirements doc) use the following path: click Servers>Clusters>WebSphere application server clusters>cluster_name>Cluster members.
2. Locate the cluster member you are downgrading and change the value in the Configured weight column to zero. NOTE: Record the previous value to restore the setting when the downgrade is complete.
3. Click Update to apply the change.
• If automatic plug-in generation and propagation is disabled, manually generate and/or propagate the plugin-cfg.xml file to the Web servers.
• Note that the web server plug-in will check periodically for configuration updates based on the value of Refresh Configuration Interval property for the Web server plug-in (default value is 60 seconds). You can check this value on the Deployment Manager administrative console by selecting Servers>Web Servers>web_server_name>Plug-in Properties. When using WAS 7.x (for the editions that support WAS 7.x see the hardware&software requirements doc) use the following path: click Servers>Server Types>Web Servers>web_server_name>Plug-in Properties.
2. Choose either the graphical user interface uninstallation option or the command line uninstallation option:
   
   NOTE: If the uninstallation fails, use the IBM Support Assistant to access support-related information and serviceability tools for problem determination. For i5/OS, download ISA on a system other than i5/OS. On the Support Assistant Welcome page, click Service. Then click the Create Portable Collector link to create a remotely collect the data from your i5/OS system. Fix what is causing the problem and then rerun the installation task.
   
   
   If using the Universal PUI, (which does not include the bundled Java environment), run the following command, setupCmdLine.bat for Windows or . ./setupCmdLine.sh for Unix/Linux from the was_profile_root/bin directory to set up the Java environment for the graphical user interface installation program.
• Enter the following command to launch the graphical user interface uninstallation program:
• Windows: portal_server_root\update> updatePortalWizard.bat
• Unix/Linux: portal_server_root/update> ./updatePortalWizard.sh
  
  - OR -
• Perform the following steps to launch the uninstallation program from the command line:
1. Ensure to stop any active application servers using the stopServer command. To see which application servers are active use the serverStatus command.
2. Enter the following command to launch the uninstallation program (NOTE: Enter the command on one line):
• Windows: PortalServer_root\update> updatePortal.bat -uninstall
  -installDir "<PortalServer_root>"
  -fixpack
  -fixpackID WP_PTF_6105
• Unix/Linux: PortalServer_root/update> ./updatePortal.sh -uninstall
  -installDir "<PortalServer_root>"
  -fixpack
  -fixpackID WP_PTF_6105
• i5/OS: portal_server_root/update> updatePortal.sh -uninstall
  -installDir "<PortalServer_root_user>"
  -fixpack
  -fixpackID WP_PTF_6105
3. If you previously customized any configuration files in the portal_server_root/config directory (<portal_server_root_user>/config directory for iSeries), check to see if uninstalling the fix pack 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.
5. Only Required if following the 24x7 single cluster downgrade: Restore IP traffic to the node where you uninstalled:
• If you are using the 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:
1. In the Deployment Manager administrative console, click Servers > Clusters > cluster_name > Cluster members to obtain a view of the collection of cluster members. When using WAS 7.x (for the editions that support WAS 7.x see the hardware&software requirements doc) use the following path: click Servers>Clusters>WebSphere application server clusters>cluster_name>Cluster members.
2. Locate the cluster member you downgraded and change the value in the Configured weight column back to the original value.
3. Click Update to apply the change.
• If automatic plug-in generation and propagation is disabled, manually generate and/or propagate the plugin-cfg.xml file to the Web servers.
5. Perform the following post-uninstallation steps
1. Re-enable automatic synchronization on all nodes in the cluster if you disabled it earlier.
1. In the administrative console for the deployment manager, select System administration > Node agents in the navigation tree.
2. Click nodeagent for the required node.
3. Click File Synchronization Service.
4. Check the Automatic Synchronization check box on the File Synchronization Service page to enable the automatic synchronization feature and then click OK.
5. Repeat these steps for all remaining nodes.
6. Click Save to save the configuration changes to the master repository.
7. Select System administration > Nodes in the navigation tree.
8. Select all nodes that are not synchronized, and click on Synchronize.
9. Select System administration > Node agents in the navigation tree.
10. Select all node agents where automatic synchronization has been re-enabled and click Restart.
2. Note: Required for Express edition only: In order to restore the ability to create Virtual Portals, run the following commands on the primary node:
• Windows: ConfigEngine.bat action-express-update-vp -DWasPassword=password
• Unix/Linux: ./ConfigEngine.sh action-express-update-vp -DWasPassword=password
• i5/OS: ConfigEngine.sh action-express-update-vp -DWasPassword=password
  
  Restart PortalServer.
  
3. When uninstalling from 6105 to 6101 and if 6101 was an upgrade from 6100 (eg. the problem does not happen if 6101 was initially a Full Install) then run the following on the primary node.
• Windows: ConfigEngine.bat update-ear -DconfigExtensionList=-applyPTF6101 -DComponentList=wp.ear,prereq.odc,wp.oob.content/packager
• Unix/Linux: ./ConfigEngine.sh update-ear -DconfigExtensionList=-applyPTF6101 -DComponentList=wp.ear,prereq.odc,wp.oob.content/packager
• i5/OS: ConfigEngine.sh -profileName profile_root update-ear -DconfigExtensionList=-applyPTF6101 -DComponentList=wp.ear,prereq.odc,wp.oob.content/packager
4. Perform the following steps if you are using Web Content Manager and you created content on the release you downgraded from:
1. Redeploy your customization, including JSPs, to the local rendering portlet.
2. If the portal version is lower than 6.1.0.1 plus PK76129 (Cumulative iFix 1 for WCM v6.1.0.1) and the portal has Web Content data, then run the following steps:
   
   To ensure all scheduled actions are reset, run the run-wcm-admin-task-schedule-actions task from the wp_profile_root/ConfigEngine directory.
   
   To reschedule all libraries and preserve the last saved date of each item:
• Windows: ConfigEngine.bat run-wcm-admin-task-schedule-actions -DallLibraries=true -DpreserveDates=true -DPortalAdminId=username -DPortalAdminPwd=password
• Unix: ./ConfigEngine.sh run-wcm-admin-task-schedule-actions -DallLibraries=true -DpreserveDates=true -DPortalAdminId=username -DPortalAdminPwd=password
• i5/OS: ConfigEngine.sh -profileName profile_root run-wcm-admin-task-schedule-actions -DallLibraries=true -DpreserveDates=true -DPortalAdminId=username -DPortalAdminPwd=password
  where profile_root is the name of the IBM WebSphere Application Server profile where WebSphere Portal is installed; for example, wp_profile.
  
  
  To reschedule a single library and preserve the last saved date of each item:
• Windows: ConfigEngine.bat run-wcm-admin-task-schedule-actions -Dlibrary=libraryname -DpreserveDates=true -DPortalAdminId=username -DPortalAdminPwd=password
• Unix: ./ConfigEngine.sh run-wcm-admin-task-schedule-actions -Dlibrary=libraryname -DpreserveDates=true -DPortalAdminId=username -DPortalAdminPwd=password
• i5/OS: ConfigEngine.sh -profileName profile_root run-wcm-admin-task-schedule-actions -Dlibrary=libraryname -DpreserveDates=true -DPortalAdminId=username -DPortalAdminPwd=password
  where profile_root is the name of the IBM WebSphere Application Server profile where WebSphere Portal is installed; for example, wp_profile.
5. If you disabled database updates during the uninstall of 6105 by setting DbSafeMode=true,then do the following:
1. Edit wkplc_dbtype.properties and set DbSafeMode=false.
2. Manually apply all database changes manually as explained here: http://www.ibm.com/support/docview.wss?uid=swg27019861

Back to top

---

Known issues

For a list of known runtime issues for WebSphere Portal 6.1.0.5/6.1.5.2, see IBM WebSphere Portal 6.1.0.5/6.1.5.2 Known Runtime Issues for details.

For a list of known install and uninstall issues for WebSphere Portal 6.1.0.5/6.1.5.2, see IBM WebSphere Portal 6.1.0.5/6.1.5.2 Known Install/Uninstall Issues for details.

Back to top

---

Change History
Initial Release

Back to top

---

Additional information
You can find additional information on the WebSphere Portal support page.

Back to top

---

Trademarks and service marks
For trademark attribution, visit the IBM Terms of Use Web site.

Back to top