Portal Upgrades: Best Practices

Answer

What to do:

• Ensure you have a working backup of your environment. This includes a full file structure backup AND a full database backup. Having only one or the other is no better than having no backup at all. Portal upgrades cannot be uninstalled if they fail.
  
  Customers using DB2 on z/OS: When taking the database backup starting 6.0.1.4 and higher fix packs it is sufficient to only take a backup of the data but not the DB2 catalog as separate SQL files are provided to revert changes applied to the database schema during fix pack installation.
• Ensure file permissions are set correctly for UNIX environments. If you are using a non-root user, ensure that the user owns the AppServer directory, the PortalServer directory and the profile directory. Ensure that the non-root user has full access to the /tmp directory.
• If the upgrade fails, fix the problem with the upgrade and finish it before attempting anything else with the system (unless you decide to restore a backup).
• Ensure you have followed all of the 'Before You Begin' steps from the upgrade instructions.
• Upgrade all WebSphere Application Server (WAS) environments and ensure Portal still functions before starting the Portal upgrades. For example, if you have a two node cluster, update the Deployment Manager, WAS on the primary node, and WAS on the secondary node first. Then verify your Portal cluster still works on the higher level of WAS. Then you can begin the Portal upgrades.
• For optimal performance and minimal network traffic when using the Portal Update Installer's graphical Wizard interface, the upgrade steps should be run from local displays. When using remote displays, it is recommended to use the command-line interface with the Update Installer.
• Optional for WebSphere Portal version 6.1: You can follow the instructions on the Administrator's Self-Help pages for IBM WebSphere Portal version 6.1 to download, extract, and configure the Administrator self help pages.
• If passwords are preserved during fix pack installation and you want to manually delete the passwords, open the wkplc.properties file and include the following line in the file: PWordDelete=true. Then run the following task from the <wp_profile_root>/ConfigEngine/ directory to delete the passwords
• Windows: ConfigEngine.bat action-delete-passwords-fixpack
• Unix/Linux: ./ConfigEngine.sh action-delete-passwords-fixpack
• i5/OS: ConfigEngine.sh -profileName profile_root action-delete-passwords-fixpack
• For i5/OS after the upgrade run the CHGJOBD JOBD(QWAS61/QWASJOBD) LOG(4 00 *NOLIST) command to disable WebSphere Application Server informational logging for WebSphere Application Server 6.x or run the CHGJOBD JOBD(QWAS7/QWASJOBD) LOG(4 00 *NOLIST) command to disable WebSphere Application Server informational logging for WebSphere Application Server 7.x
• For a cluster, all nodes in the cluster should have the same apar/PTF levels.
• For z/OS federated, unclustered nodes should be upgraded using the z/OS cluster Readme document. In the case of a single federated, unclustered node, the upgrade procedure is the same as upgrading the primary node of a z/OS cluster.
• If you are using Microsoft Internet Protocol (IP) Version 6 and you have specified the WpsHostName property as an Internet Protocol address, normalize the Internet Protocol address by placing square brackets around the IP address as follows: WpsHostName=[my.IPV6.IP.address].

• If upgrading a clustered environment, upgrade the primary node first. DO NOT upgrade a secondary first.
• For fix packs before 6.1.0.4: If upgrading a clustered environment, DO NOT upgrade cluster nodes simultaneously.
• If an upgrade fails, DO NOT attempt to apply a different fix pack on top of a fix pack failure. This is the most common action that results in a complete reinstall.
• Windows and UNIX only: Do NOT upgrade a node that is federated but not clustered. Create a cluster first, even if it is just one node.
• If an upgrade fails, DO NOT attempt to further configure the Portal server (reconfigure secuirty, transfer the database, etc) until you have resolved the upgrade failure.
• When restoring a backup, DO NOT simply overwrite the existing WebSphere directory with a backed up one. You run the risk of corrupting the environment since overwriting the directory might not remove new files that had been laid down by the failed upgrade.