IBM WebSphere Portal 7.0.0.2 Combined Cumulative Fix Readme - cluster

Product readme


Abstract

IBM WebSphere Portal 7.0.0.2 Combined Cumulative Fix cluster installation instructions for all editions, including WebSphere Portal Express- Idle Standby.

Content

7.0.0.2: Readme for IBM WebSphere Portal 7.0.0.2 Combined Cumulative fix - cluster

Table of Contents






About Combined Cumulative Fix


These are the instructions on how to install a WebSphere Portal Combined Cumulative Fix. The Combined Cumulative Fix is a package of WebSphere Portal fixes and Web Content Manager Cumulative fixes.

What's New

As of WebSphere Portal V7.0.0.2 Combined Cumulative Fix 26 (CF26), support has been added for syndicating to subscribers running WebSphere Portal V8.0.0.1 Combined Cumulative Fix 09 (CF09) or later.

Back to top





Space requirements


Ensure that enough disk space is available in the following directories:

z/OS: 625 cylinders in the directory where you download the cumulative fix, 625 cylinders in the <Portal Configuration HFS>, 625 cylinders in <WebSphere Configuration HFS> and 1250 cylinders in your system temp directory.

For other platforms: 2 GB in the directory where you download the cumulative fix, 1 GB in <Portal_Install_Root>, 1 GB in <wp_profile_root> temporary 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 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.
      • 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 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.
      • 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 cumulative fix in a clustered environment, the portlets are only redeployed when uninstalling the cumulative fix on the primary node. The cumulative fix 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 Combined Cumulative Fix (single-cluster procedure)

Before you begin:

Familiarize yourself with the Portal Upgrade Best Practices available from IBM Remote Technical Support for WebSphere Portal.

  • Portal Upgrades: Best Practices for V7.0
  • For instructions on how to validate your environment prior to the upgrade, see the instructions for running the Health Checker tool for WebSphere Portal at:

  • Health Checker tool for WebSphere Portal V7.0
  • IMPORTANT: Certain security configurations can cause failures with the upgrade. Please check the following technote to see if this may apply to your environment.

  • Fix Pack 7.0.0.1 fails at action-import-defaultnodes-wp.filestore/base task.


  • 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 installing to the Combined Cumulative Fix:
      1. Before you install this combined cumulative fix, check to see if the list of fixes already installed on your system is included in the list of fixes provided in this combined cumulative fix. If you have temporary, interim or cumulative fixes on your system that are not included in this Combined Cumulative Fix, then uninstall those fixes before installing this Combined Cumulative Fix and contact IBM Support for an updated version of that fix, or for more information.
      2. Verify that the information in the wkplc.properties, wkplc_dbtype.properties, wkplc_dbdomain.properties, and wkplc_comp.properties files is correct on each node in the cluster. If using multiple profiles, also verify that the information in each profile is correct. WebSphere Portal 7 introduced support for multiple profiles. See the following link for multiple profiles Supporting multiple profiles: wp7.
        • Enter a value for the PortalAdminPwd and WasPassword parameters in the wkplc.properties file.
        • Ensure that the DbUser (database user) and DbPassword (database password) parameters are defined correctly for all database domains in the wkplc_dbdomain.properties file.
        • Unix/Linux/Windows/IBM i Only: 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. Special considerations for multiple profiles or binary install or migration upgrade:
        1. If you did a binary installation and created a WebSphere Portal profile later, or your Portal 7.0.0.x was migrated from 6.1.x, ensure that the PortalServer/wps.properties file correctly references the profile. The Portal Update Installer uses the wps.properties file to determine which profile is the primary profile to update. Failure to complete this step could result in an inoperable Portal server after the Combined Cumulative Fix installation completes.
          1. Edit the <PortalServer root>/wps.properties file in a text editor
          2. Add these two properties if they do not already exist:
            ProfileName=<your profile name, e.g. wp_profile>
            ProfileDirectory=<your profile directory, e.g. /opt/IBM/WebSphere/wp_profile>

            Note: The ProfileDirectory property should use forward slash (/) instead of backslash (\) on Windows.
        2. If you have created multiple profiles. the Portal Update Installer will automatically upgrade all profiles. If you want to specify which profiles are updated, then complete the following steps:
          1. Edit the <PortalServer root>/wps.properties file in a text editor
          2. Add this property if it does not already exist:
            AutoUpdateMultipleProfiles=<comma separated list of profile names, e.g. wp_profile, wp_profile2, wp_profile3>
        3. If using Multiple Profiles, verify all your profiles are at the same level before starting upgrade.
      4. Perform the following steps to download the cumulative fix and the WebSphere Portal Update Installer:
        1. Download the latest Combined Cumulative fix (e.g. 7.0.0.2-WP-WCM-Combined-CFPMnnnnn-CFnnn), and the latest WebSphere Portal Update Installer from http://www.ibm.com/support/docview.wss?uid=swg24027857.
        2. Create the PortalServer_root/update directory and extract the WebSphere Portal Update Installer file into this directory.
        3. Create the PortalServer_root/update/fixes directory and extract the 7.0.0.2-WP-WCM-Combined-CFPMnnnnn-CFnnn.zip file into this directory, where n is the numbers associated with the version of the Combined Cumulative fix. Note for z/OS users: refer to Installing interim fixes on WebSphere Portal Enable for z/OS using Portal Update Installer for detailed descriptions of how to execute steps ii. and iii. above.
      5. Ensure that all nodes have been synchronized before starting to upgrade.

    2. Ensure that automatic synchronization is disabled on all nodes to be upgraded and that all node agents are stopped. When the automatic synchronization is enabled, the node agent on each node automatically contacts the deployment manager at startup and at every synchronization interval to attempt to synchronize the node's configuration repository with the master repository managed by the deployment manager.
      1. In the administrative console for the deployment manager, select System administration > Node agents in the navigation tree.
      2. Click nodeagent for the required node.
      3. Click File Synchronization Service.
      4. Uncheck the Automatic Synchronization check box 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. If you do not stop the node agents the cumulative fix configuration might fail.


        NOTE
        : Do not attempt to combine steps 3 and 4 together! The update must be performed first on the primary node and 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.
        • z/OS only: If you are using Sysplex Distributor, then
          VARY TCPIP,,SYSPLEX,QUIesce,JOBNAME=<WP_Controler> or
          VARY TCPIP,,SYSPLEX,QUIesce,POrt=<portnum>.
          Reactivate it by replacing the QUIesce with RESUME keyword.
        • 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>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>Server Types>Web Servers>web_server_name>Plug-in Properties.
        • If automatic propagation of the plug-in configuration file is enabled on the web server(s) disable it from the Deployment Manager administrative console by going to Servers>Server Types>Web Servers>web_server_name>Plug-in Properties. and unchecking Automatically propagate plug-in configuration file.
      2. Choose either the graphical user interface installation option or the command line installation option:

        NOTE: Not all platforms can use the graphical user interface (IBM i and z/OS can only use command line).

        NOTE: If the installation fails, use the IBM Support Assistant to access support-related information and serviceability tools for problem determination. For IBM i, download ISA on a system other than IBM i. On the Support Assistant Welcome page, click Service. Then click the Create Portable Collector link to create a remotely collect the data from your IBM i 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. When updating a Portal that does not have a profile because it was installed with isBinaryInstall="true", then run setupCmdLine.bat|.sh from PortalServer_root/bin. z/OS users can not use the Universal PUI.



        Enter the following command to launch the graphical user interface installation program:
        • Windows: PortalServer_root\update> updatePortalWizard.bat
        • Unix/Linux: PortalServer_root/update> ./updatePortalWizard.sh

          -- OR --
        • Perform the following steps to launch the installation program from the command line:
          1. 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>"
              -fix
              -fixDir "<PortalServer_root>\update\fixes"
              -fixes < Cumulative fix >
            • Unix/Linux: PortalServer_root/update> ./updatePortal.sh -install
              -installDir "<PortalServer_root>"
              -fix
              -fixDir "<PortalServer_root>/update/fixes"
              -fixes < Cumulative fix >
            • i5/OS: portal_server_root/update> updatePortal.sh -install
              -installDir "<portal_server_root>"
              -fix
              -fixDir "<portal_server_root>/update/fixes"
              -fixes < Cumulative fix >
            • z/OS: If the Health Checker Tool for WebSphere Portal V7.0 has not been run then it needs to be run before installing the Combined Cumulative Fix. Execute the following commands to install the Combined Cumulative Fix:
              1. From <was_profile_root>/bin directory:
                . ./setupCmdLine.sh
              2. PortalServer_root/update> ./updatePortal.sh -install
                -installDir "<PortalServer_root>"
                -fix
                -fixDir "<PortalServer_root>/update/fixes"
                -fixes <Cumulative fix>

                Alternatively, the steps i. and ii. above can be executed via JCL. Customize the JCL samples from the following link: Installing interim fixes on WebSphere Portal Enable for z/OS using Portal Update Installer. Submit the JCLs, and then return here to continue.

      3. If you do not have any profiles at this point (because you are in the process of migration from WebSphere Portal 6.1 or Installing an additional node for a cluster or creating multiple profiles) no post installation steps are necessary and you can continue with the next steps that create the profiles as outlined by the according documentation.
      4. z/OS: If doing an upgrade as part of a migration from a previous version (eg. 6.x), run ./ConfigEngine.sh gather-migration-files command from the <wp_profile_root>/ConfigEngine directory.
      5. Run the following command:
        • z/OS: <wp_profile_root>/PortalServer/bin/UpdateProfile.sh install CF skipPreCheckProfile
        • All other platforms: To update a profile after an upgrade, the following command can be used to update profiles that are not included in AutoUpdateMultipleProfiles. All profiles that were not included in AutoUpdateMultipleProfiles need to be updated after the upgrade is done. All profiles must be at the same level for future upgrades to be applied. See the following link for multiple profiles Supporting multiple profiles: wp7.

          <wp_profile_root>/PortalServer/bin/UpdateProfile.bat|.sh install CF

      6. This cumulative fix provides updates to OSGi bundles. After installing the cumulative fix, run "<profile location>/bin/osgiCfgInit.sh" (for IBM i the command is just osgiCfgInit, for Microsoft Windows the command is osgiCfgInit.bat) to clear the caches and make the OSGi container pick up the updates to the modified OSGi bundles. Note that it is recommended to stop the portal server before running the osgiCfgInit command.
      7. Verify that your system is operational by entering the server's URL in a browser and logging in to browse the content.
      8. 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.
        • z/OS Only: If you are using Sysplex Distributor, then
          VARY TCPIP,,SYSPLEX,RESUME,JOBNAME=<WP_Controler> or
          VARY TCPIP,,SYSPLEX,RESUME,POrt=<portnum>.
        • 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>WebSphere application server clusters>cluster_name>Cluster members to obtain a view of the collection of cluster members.
          2. Locate the cluster member you upgraded and change the value in the Configured weight column back to the original value.
          3. Click Update to apply the change.
        • If you previously disabled automatic propagation of the Web server(s), re-enable it now using the Deployment Manager administration console by going to Servers>Server Types>Web Servers>web_server_name>Plug-in Properties and checking Automatically propagate plug-in configuration file .
        • If 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.
        • z/OS only: If you are using Sysplex Distributor, then
          VARY TCPIP,,SYSPLEX,QUIesce,JOBNAME=<WP_Controler> or
          VARY TCPIP,,SYSPLEX,QUIesce,POrt=<portnum>.
          Reactivate it by replacing the QUIesce with RESUME keyword.
        • 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>WebSphere application server clusters>cluster_name>Cluster members to obtain a view of the collection of cluster members.
          2. Locate the cluster member you are upgrading and change the value in the Configured weight column to zero. NOTE: Record the previous value to restore the setting when the upgrade is complete.
          3. Click Update to apply the change.
        • 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>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: Not all platforms can use the graphical user interface (IBM i and z/OS can only use command line).

        NOTE: If the installation fails, use the IBM Support Assistant to access support-related information and serviceability tools for problem determination. For IBM i, download ISA on a system other than IBM i. On the Support Assistant Welcome page, click Service. Then click the Create Portable Collector link to create a remotely collect the data from your IBM i 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. When updating a Portal that does not have a profile because it was installed with isBinaryInstall="true", then run setupCmdLine.bat|.sh from PortalServer_root/bin. z/OS users can not use the Universal PUI.




        Enter the following command to launch the graphical user interface installation program:
        • Windows: PortalServer_root\update> updatePortalWizard.bat
        • Unix/Linux: PortalServer_root/update> ./updatePortalWizard.sh

          -- OR --
        • Perform the following steps to launch the installation program from the command line:
          1. 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>"
              -fix
              -fixDir "<PortalServer_root>\update\fixes"
              -fixes < Cumulative fix >
            • Unix/Linux: PortalServer_root/update> ./updatePortal.sh -install
              -installDir "<PortalServer_root>"
              -fix
              -fixDir "<PortalServer_root>/update/fixes"
              -fixes < Cumulative fix >
            • i5/OS: portal_server_root/update> updatePortal.sh -install
              -installDir "<portal_server_root>"
              -fix
              -fixDir "<portal_server_root>/update/fixes"
              -fixes < Cumulative fix >
            • z/OS: If the Health Checker Tool for WebSphere Portal V7.0 has not been run then it needs to be run before installing the Combined Cumulative Fix. Execute the following commands to install the Combined Cumulative Fix:
              1. From <was_profile_root>/bin directory:
                . ./setupCmdLine.sh
              2. PortalServer_root/update> ./updatePortal.sh -install
                -installDir "<PortalServer_root>"
                -fix
                -fixDir "<PortalServer_root>/update/fixes"
                -fixes <Cumulative fix>

                Alternatively, the steps i. and ii. above can be executed via JCL. Customize the JCL samples from the following link: Installing interim fixes on WebSphere Portal Enable for z/OS using Portal Update Installer. Submit the JCLs, and then return here to continue.

      3. If you do not have any profiles at this point (because you are in the process of migration from WebSphere Portal 6.1 or Installing an additional node for a cluster or creating mutliple profiles) no post installation steps are necessary and you can continue with the next steps that create the profiles as outlined by the according documentation.
      4. z/OS: If doing an upgrade as part of a migration from a previous version (eg. 6.x), run ./ConfigEngine.sh gather-migration-files command from the <wp_profile_root>/ConfigEngine directory.
      5. Run the following command:
        • z/OS: <wp_profile_root>/PortalServer/bin/UpdateProfile.sh install CF skipPreCheckProfile
        • All other platforms: To update a profile after an upgrade, the following command can be used to update profiles that are not included in AutoUpdateMultipleProfiles. All profiles that were not included in AutoUpdateMultipleProfiles need to be updated after the upgrade is done. All profiles must be at the same level for future upgrades to be applied. See the following link for multiple profiles Supporting multiple profiles: wp7.

          <wp_profile_root>/PortalServer/bin/UpdateProfile.bat|.sh install CF

      6. This cumulative fix provides updates to OSGi bundles. After installing the cumulative fix, run "<profile location>/bin/osgiCfgInit.sh" (for IBM i the command is just osgiCfgInit, for Microsoft Windows the command is osgiCfgInit.bat) to clear the caches and make the OSGi container pick up the updates to the modified OSGi bundles. Note that it is recommended to stop the portal server before running the osgiCfgInit command.
      7. Verify that your system is operational by entering the server's URL in a browser and logging in to browse the content.
      8. 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.
        • z/OS Only: If you are using Sysplex Distributor, then
          VARY TCPIP,,SYSPLEX,RESUME,JOBNAME=<WP_Controler> or
          VARY TCPIP,,SYSPLEX,RESUME,POrt=<portnum>.
        • 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>WebSphere application server clusters>cluster_name>Cluster members to obtain a view of the collection of cluster members.
          2. Locate the cluster member you upgraded and change the value in the Configured weight column back to the original value.
          3. Click Update to apply the change.
        • If 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. Redeploy your customization, including JSPs, to the WCM portlets if you are using Web Content Manager and you customized the portlets prior to installing the Combined Cumulative fix.
        1. To update the deployed remote rendering portlet:
          • Backup any files (e.g. custom JSPs) which have been copied to the deployed remote rendering portlet WAR directory
          • Log in to Portal as the Portal Administrator
          • Navigate to: Administration / Portlet Management / Web Modules
          • Find and select the remote rendering portlet web module
          • Click the Update Portlet Icon to the right of the selected portlet
          • Select the updated portlet WAR file located in: <PortalServer_root>/PortalServer/wcm/prereq.wcm/installableApps
          • Click Next and Finish
        2. To update the deployed PDM Doc List Portlet:
          • Backup any files (e.g. custom JSPs) which have been copied to the deployed remote rendering portlet WAR directory
          • Log in to Portal as the Portal Administrator
          • Navigate to: Administration / Portlet Management / Web Modules
          • Find and select the PDM Doc List Portlet web module
          • Click the Update Portlet Icon to the right of the selected portlet
          • Select the updated portlet WAR file located in: <PortalServer_root>/PortalServer/wcm/prereq.wcm/installableApps
          • Click Next and Finish
        3. Log out of Portal for changes to take effect.
      3. Clear the browser cache before using the updated Web Content Manager.
      4. Review the following documentation "Configuration Changes and Options introduced in WP/WCM V7.0.0.1 and 7.0.0.2 Combined Cumulative Fixes" to see if it applies to your environment.


      Back to top




      Steps for uninstalling
      Combined Cumulative Fix (single-cluster procedure)


      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.


      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 Combined Cumulative Fix:

        NOTE: The steps listed in this point need to be performed on all nodes.
        1. Verify that the information in the wkplc.properties, wkplc_dbtype.properties, wkplc_dbdomain.properties, and wkplc_comp.properties files are correct on each node in the cluster. If using multiple profiles, also verify that the information in each profile is correct. See the following link for multiple profiles Supporting multiple profiles: wp7.
          • Enter a value for the PortalAdminPwd and WasPassword parameters in the wkplc.properties file.
          • Ensure that the DbUser (database user) and DbPassword (database_password) properties are defined correctly for all database domains in the wkplc_dbdomain.properties file.
          • Unix/Linux/Windows/IBM i Only: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.
          • WebSphere Portal 7 introduced support for multiple profiles. During the Combined Cumulative Fix uninstall the primary profile is downgraded first if one exists (The Update Installer also supports the update case for a binary only install without profiles). The primary profile is identified by two properties, ProfileDirectory and ProfileName. Ensure these properties are set before starting the downgrade process.
          • If using Multiple Profiles, verify all your profiles are at the same level before starting downgrade.
        2. Ensure that all nodes have been synchronized before starting to uninstall.
      2. Perform the following steps to disable automatic synchronization and stopping the node agents:
        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. If you do not stop the node agents the cumulative fix configuration might fail.



          NOTE: Do not attempt to combine steps 3 and 4 together! The uninstall must be performed first on the primary node and then on the additional nodes, in accordance with the below instructions.
      3. Perform the following steps to uninstall the cumulative fix 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.
          • z/OS only: If you are using Sysplex Distributor, then
            VARY TCPIP,,SYSPLEX,QUIesce,JOBNAME=<WP_Controler> or
            VARY TCPIP,,SYSPLEX,QUIesce,POrt=<portnum>.
            Reactivate it by replacing the QUIesce with RESUME keyword.
          • 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>WebSphere application server clusters>cluster_name>Cluster members to obtain a view of the collection of 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>Server Types>Web Servers>web_server_name>Plug-in Properties.
          • If automatic propagation of the plug-in configuration file is enabled on the web server(s) disable it from the Deployment Manager administrative console by going to Servers>Server Types>Web Servers>web_server_name>Plug-in Properties and unchecking Automatically propagate plug-in configuration file.
        2. Choose either the graphical user interface uninstallation option or the command line uninstallation option:

          NOTE: Not all platforms can use the graphical user interface (IBM i and z/OS can only use command line).

          NOTE: If the uninstallation fails, use the IBM Support Assistant to access support-related information and serviceability tools for problem determination. For IBM i, download ISA on a system other than IBM i. On the Support Assistant Welcome page, click Service. Then click the Create Portable Collector link to create a remotely collect the data from your IBM i 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. When updating a Portal that does not have a profile because it was installed with isBinaryInstall="true", then run setupCmdLine.bat|.sh from PortalServer_root/bin. z/OS users can not use the Universal PUI.
          • Enter the following command to launch the graphical user interface uninstallation program:
            • Windows: PortalServer_root\update> updatePortalWizard.bat
            • Unix/Linux: PortalServer_root/update> ./updatePortalWizard.sh

              - OR -
          • Perform the following steps to launch the uninstallation program from the command line:
            1. 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>"
                -fix
                -fixes < Cumulative fix >
              • Unix/Linux: PortalServer_root/update> ./updatePortal.sh -uninstall
                -installDir "<PortalServer_root>"
                -fix
                -fixes < Cumulative fix >
              • i5/OS: portal_server_root/update> updatePortal.sh -uninstall
                -installDir "<portal_server_root>"
                -fix
                -fixes < Cumulative fix >
              • z/OS: If the Health Checker Tool for WebSphere Portal V7.0 has not been run then it needs to be run before uninstalling the Combined Cumulative Fix. Execute the following commands to uninstall the Combined Cumulative Fix:
                1. From <was_profile_root>/bin directory:
                  . ./setupCmdLine.sh
                2. PortalServer_root/update> ./updatePortal.sh -uninstall
                  -installDir "<PortalServer_root>"
                  -fix
                  -fixes <Cumulative fix>

                  Alternatively, the steps i. and ii. above can be executed via JCL. Customize the JCL samples from the following link: Installing interim fixes on WebSphere Portal Enable for z/OS using Portal Update Installer. Submit the JCLs, and then return here to continue.
        3. Run the following command:
          • z/OS: <wp_profile_root>/PortalServer/bin/UpdateProfile.sh uninstall CF skipPreCheckProfile
          • All other platforms: To downgrade a profile after an uninstall, the following command can be used to downgrade all profiles (including the primary profiles). See the following link for multiple profiles Supporting multiple profiles: wp7.

            <wp_profile_root>/PortalServer/bin/UpdateProfile.bat|.sh uninstall CF

        4. If you previously customized any configuration files in the wp_profile_root/PortalServer/config directory, check to see if uninstalling 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.
        5. Verify that your system is operational by entering the server's URL in a browser and logging in to browse the content.
        6. 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.
          • z/OS Only: If you are using Sysplex Distributor, then
            VARY TCPIP,,SYSPLEX,RESUME,JOBNAME=<WP_Controler> or
            VARY TCPIP,,SYSPLEX,RESUME,POrt=<portnum>.
          • 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>WebSphere application server clusters>cluster_name>Cluster members to obtain a view of the collection of cluster members.
            2. Locate the cluster member you downgraded and change the value in the Configured weight column back to the original value.
            3. Click Update to apply the change.
          • If you previously disabled automatic propagation of the Web server(s), re-enable it now using the Deployment Manager administration console by going to Servers>Server Types>Web Servers>web_server_name>Plug-in Properties and checking Automatically propagate plug-in configuration file.
          • If 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 cumulative fix 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.
          • z/OS only: If you are using Sysplex Distributor, then
            VARY TCPIP,,SYSPLEX,QUIesce,JOBNAME=<WP_Controler> or
            VARY TCPIP,,SYSPLEX,QUIesce,POrt=<portnum>.
            Reactivate it by replacing the QUIesce with RESUME keyword.
          • 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>WebSphere application server clusters>cluster_name>Cluster members to obtain a view of the collection of 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>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: Not all platforms can use the graphical user interface (IBM i and z/OS can only use command line).

          NOTE: If the uninstallation fails, use the IBM Support Assistant to access support-related information and serviceability tools for problem determination. For IBM i, download ISA on a system other than IBM i. On the Support Assistant Welcome page, click Service. Then click the Create Portable Collector link to create a remotely collect the data from your IBM i 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. When updating a Portal that does not have a profile because it was installed with isBinaryInstall="true", then run setupCmdLine.bat|.sh from PortalServer_root/bin. z/OS users can not use the Universal PUI.
          • Enter the following command to launch the graphical user interface uninstallation program:
            • Windows: PortalServer_root\update> updatePortalWizard.bat
            • Unix/Linux: PortalServer_root/update> ./updatePortalWizard.sh

              - OR -
          • Perform the following steps to launch the uninstallation program from the command line:
            1. 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>"
                -fix
                -fixes < Cumulative fix >
              • Unix/Linux: PortalServer_root/update> ./updatePortal.sh -uninstall
                -installDir "<PortalServer_root>"
                -fix
                -fixes < Cumulative fix >
              • i5/OS: portal_server_root/update> updatePortal.sh -uninstall
                -installDir "<portal_server_root>"
                -fix
                -fixes < Cumulative fix >
              • z/OS: If the Health Checker Tool for WebSphere Portal V7.0 has not been run then it needs to be run before uninstalling the Combined Cumulative Fix. Execute the following commands to uninstall the Combined Cumulative Fix:
                1. From <was_profile_root>/bin directory:
                  . ./setupCmdLine.sh
                2. PortalServer_root/update> ./updatePortal.sh -uninstall
                  -installDir "<PortalServer_root>"
                  -fix
                  -fixes <Cumulative fix>

                  Alternatively, the steps i. and ii. above can be executed via JCL. Customize the JCL samples from the following link: Installing interim fixes on WebSphere Portal Enable for z/OS using Portal Update Installer. Submit the JCLs, and then return here to continue.
        3. Run the following command:
          • z/OS: <wp_profile_root>/PortalServer/bin/UpdateProfile.sh uninstall CF skipPreCheckProfile
          • All other platforms: To downgrade a profile after an uninstall, the following command can be used to downgrade all profiles (including the primary profiles). See the following link for multiple profiles Supporting multiple profiles: wp7.

            <wp_profile_root>/PortalServer/bin/UpdateProfile.bat|.sh uninstall CF

        4. If you previously customized any configuration files in the wp_profile_root/PortalServer/config directory, check to see if uninstalling 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.
        5. Verify that your system is operational by entering the server's URL in a browser and logging in to browse the content.
        6. 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.
          • z/OS Only: If you are using Sysplex Distributor, then
            VARY TCPIP,,SYSPLEX,RESUME,JOBNAME=<WP_Controler> or
            VARY TCPIP,,SYSPLEX,RESUME,POrt=<portnum>.
          • 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>WebSphere application server clusters>cluster_name>Cluster members to obtain a view of the collection of 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. Redeploy your customization, including JSPs, to the WCM portlets if you are using Web Content Manager and you customized the portlets prior to uninstalling the Combined Cumulative fix.
          1. To update the deployed remote rendering portlet:
            • Backup any files (e.g. custom JSPs) which have been copied to the deployed remote rendering portlet WAR directory
            • Log in to Portal as the Portal Administrator
            • Navigate to: Administration / Portlet Management / Web Modules
            • Find and select the remote rendering portlet web module
            • Click the Update Portlet Icon to the right of the selected portlet
            • Select the updated portlet WAR file located in: <PortalServer_root>/PortalServer/wcm/prereq.wcm/installableApps
            • Click Next and Finish
          2. To update the deployed PDM Doc List Portlet:
            • Backup any files (e.g. custom JSPs) which have been copied to the deployed remote rendering portlet WAR directory
            • Log in to Portal as the Portal Administrator
            • Navigate to: Administration / Portlet Management / Web Modules
            • Find and select the PDM Doc List Portlet web module
            • Click the Update Portlet Icon to the right of the selected portlet
            • Select the updated portlet WAR file located in: <PortalServer_root>/PortalServer/wcm/prereq.wcm/installableApps
            • Click Next and Finish
          3. Log out of Portal for changes to take effect.
        3. Clear the browser cache before using the updated Web Content Manager.



      Back to top




      Known issues for latest Combined Cumulative Fix


      Problem: When using versions earlier than 'Java 6 update 45' or 'Java 7 update 51', a security pop-up dialog or error will be seen every time the WCM FileTransferApplet or Ephox EditLive editor is instantiated.
      Solution: It is recommended to upgrade the Java runtime environment level to either 'Java 6 update 45' or 'Java 7 update 51' or later. Please refer to the following URL: http://www.ibm.com/support/docview.wss?uid=swg21663838


      Problem: After you enter a number into the number element/component, and then save the content/component more than twice, you will notice that the number field gets populated with some dots, i.e. 123.456.78. If you then click on Save again, you will get the following error:
      'Enter a valid number. ( content/component name here)'
      Solution: The workaround is to remove the dots and save again.


      Problem: Page theme is changed to current Portal default theme when changing page content layout.
      Solution: The workaround would be to change the page theme back to "Inherit Parent Theme". A fix for this issue is scheduled to be included in a future Combined CF.


      Problem: After upgrading to a 7.0.0.2 Cumulative Fix and "Portal 7.0.0.2" theme has been set as the default portal theme, a user is unable to post to a blog or update a wiki using Microsoft Windows Internet Explorer.
      Solution: Perform the following steps to resolve the issue:
      1. Navigate to Administration -> Manage Pages -> Contenet_Root -> Hidden pages.
      2. Select "Edit Page Properties" for the hidden page named 'Web Content Management'.
      3. On the 'Edit page: Web Content Management' page, extend 'Theme:' drop-down list and select "-----Inherit Parent Theme-----".


      Problem: WCM Authoring Search may not work after an upgrade to a 7.0.0.2 Cumulative Fix
      Solution: Perform the following steps to resolve the issue:
      1. Edit the <wp_profile>/PortalServer/jcr/lib/com/ibm/icm/icm.properties file in a text editor to verify all properties are correct.
      2. Set jcr.textsearch.enabled=true
      3. Change jcr.textsearch.indexdirectory to a corresponding location in the filesystem
      4. Restart your Portal Server.
      5. Create a new library or make changes in existing libraries


      Problem: When configuring Portal for use with a remote DB2 on z/OS database, the sample job provided for the database creation does not contain the statements required to create the storage groups. These take the form:

      CREATE STOGROUP group
      VOLUMES(' volume')
      VCAT category;
      COMMIT;

      where,
      group is the name of the storage group for the database,
      volume is the volume serial number of * to let SMS select the volume where the database will reside,
      category is the category name of the Integrated Catalog Facility.

      Solution: When using the EJPSCRDB sample job add the above statements for each storage group to the final version. These should be added at the beginning of "Step 2" of the sample job, just before the CREATE statements for the actual databases.


      Problem: Theme Policies are not supported by the Portal 7.0.0.2 theme.
      Solution: This is a known limitation.


      Problem: Client-side aggregation is not supported by the Portal 7.0.0.2 theme.
      Solution: This is a known limitation.


      Problem: The WebSphere Portal 7.0.0.2 theme does not support Sametime 8.5.1
      Solution: This is a known limitation.


      Problem: Loading a page with the out of box default profile (Deferred) causes "dojo is not defined" error.
      Solution: Dojo is not available in view mode using the Deferred profile, which is the default out of box. Switch the page or theme to use the Full profile to access Dojo in view mode. For more information see URL: http://www.lotus.com/ldd/portalwiki.nsf/dx/Creating_the_module_profile_sdoc


      Problem: The Portal 7.0.0.2 drag-and-drop framework does not support multi-selection and copying resources.
      Solution: This is a known limitation. This can be enabled by creating a custom drag and drop source and enabling these features.


      Problem: The deploy-7002-theme task fails
      Solution: The Portal 7.0.0.2 theme requires several artifacts from the "Page Builder" theme to exist on the server. If you have removed the theme or if you are coming from a migrated environment where the theme never existed, you will need to add the Page Builder theme back to the system before running the deploy-7002-theme task. Please see the "Additional instructions for a migrated environment" section at the following URL for more information http://www.lotus.com/ldd/portalwiki.nsf/dx/Installing_a_new_theme_sdoc


      Problem: The Feedspace portlet in Portal 7.0.0.2 may show JavaScript issues.
      Solution: The Feedspace portlet needs to be redeployed to resolve this. Use the Portal administration area to update the the SyndicatedFeedPortlet.war. Use the PortalServer/bp/wp.bp.feedspace/installableApps/SyndicatedFeedPortlet.war to do this update.


      Problem: If a WCM cumulative fix is installed on a Websphere Portal 7.0.0.2 where the date of the install is later than the date on which the cumulative fix was packaged, then the update-wcm task will fail to overwrite the WCM war files from the base version.
      Solution: To workaround this problem, the war files from [PortalServer]\wcm\prereq.wcm\installableApps have to be manually copied to [PortalServer]\installableApps. Once this is done, the update-wcm task will execute successfully.


      Problem: Newly added WCM libraries might not be listed in the "Web Content Libraries" portlet on all nodes of the cluster due to an issue in cache replication.
      Solution
      : The workaround would be to restart nodes which have the stale library list. A fix for this issue is scheduled to be included in a future Combined CF.


      Problem: After uninstall of the combined cumulative fix, WPVersionInfo shows IBM WebSphere Portal Configuration Framework (CFGFW) at the upgraded version level.
      Solution: This is expected. The CFGFW version level shown after the uninstall of the combined cumulative fix remains at the upgraded level. There is no functional problem.


      Problem: If you plan to configure Computer Associates eTrust SiteMinder as your external security manager to handle authorization and authentication, the XML configuration interface may not be able to access WebSphere Portal through eTrust SiteMinder.
      Solution: To enable the XML configuration interface to access WebSphere Portal, use eTrust SiteMinder to define the configuration URL (/wps/config) as unprotected. Refer to the eTrust SiteMinder documentation for specific instructions. After the configuration URL is defined as unprotected, only WebSphere Portal enforces access control to this URL. Other resources such as the /wps/myportal URL are still protected by eTrust SiteMinder. If you already set up eTrust SiteMinder for external authorization and you want to use XMLConfiguration Interface (xmlaccess), make sure you have followed the procedure to allow for xmlaccess execution.


      Problem: If using the Firefox browser, portlets cannot be dragged to a page from the palette. It is necessary to click the + icon next to the portlet in the palette to add it to the page.
      Solution: This is documented as a known limitation.


      Problem: If an error is seen starting server "WebSphere_Portal" during the upgrade, a possible cause is that this server start is automatically enabled as part of the node reset state.
      The error would appear similar to the following as part of the "action-start-portal-server-standard" task : "ADMU3027E: An instance of the server may already be running: WebSphere_Portal"
      Solution: Log into the WAS Admin Console. Under Application Servers-> WebSphere_Portal, ensure that the Monitoring Policy for "Node restart state" is set to Stopped for all WebSphere Portal servers that are part of the environment.


      For a list of known issues for Previous WebSphere Portal 7.0.0.2 Combined Cumulative Fixes, see IBM WebSphere Portal 7.0.0.2 Combined Cumulative Fix Previous Known Issues for details.

      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

      Rate this page:

      (0 users)Average rating

      Add comments

      Document information


      More support for:

      WebSphere Portal

      Software version:

      7.0.0.2

      Operating system(s):

      AIX, IBM i, Linux, Solaris, Windows, z/OS

      Software edition:

      Enable, Express, Extend, Server

      Reference #:

      7023911

      Modified date:

      2014-09-17

      Translate my page

      Machine Translation

      Content navigation