For a list of Portal patches that are obsoleted by this patch, and any patches you must install prior to installing this patch, refer to the included patch README. This patch is not a standalone installation and does not include Portal Server 6.3. Portal Server 6.3 must be installed prior to patch installation.

It is important that this patch, as with any other, be tested thoroughly on a staging or pre-deployment system prior to being put in to production. Additionally, special attention should be given to JSP files you may have customised that must be modified by the patch installer in order to fix defects, and/or for the product to continue functioning normally.

If the system on which the patch is to be installed is being upgraded from Java Enterprise System Portal Server 6 2004Q2 to Java Enterprise System Portal Server 6 2005Q1, the patch should be installed before running the upgrade scripts, upgradePS04Q205Q1 and upgradeSRA-04Q2-05Q1.

Back to top

If the Portal Server installation contains more than one node including any mixture of platform nodes, Portal proxy nodes, and gateway nodes, then this patch should be applied on the platform nodes first, followed by all remaining nodes. Running different release levels on different nodes is not supported. Each node must be upgraded to the same revision.

1. In a terminal window, become root.

2. Ensure that all Portal services are running on the node on which you are installing the patch.

3. Solaris™

   Use the patchadd command to apply the patch.

   # patchadd 118950-15

   Linux:

   Use the update command included in the patch contents to freshen the installed Portal RPMs.

   # ./update

4. On Portal Server nodes, use the deploy command to deploy the updated web application.

   # <PS_INSTALL_DIR>/SUNWps/bin/deploy redeploy

5. On Portal Server nodes, restart all the webcontainer instances to complete the patch install.

Back to top

A small number of files in this patch are new since the original product release. Because there are no existing files on which the patchadd command can base the owner and group of these files, they must be added with owner and group of root and sys respectively. If the system on which this patch has been installed is running as a non-root user, it may be necessary to manually change the ownership of these files after the patch has been installed so that they match the rest of the environment.

As of the current patch revision, the complete list of files added across all revisions of the patch is:

/etc/opt/SUNWps/desktop/default/tld/wireless_ab.tld
/etc/opt/SUNWps/desktop/default/tld/wireless_cal.tld
/etc/opt/SUNWps/desktop/default/tld/wireless_socs.tld
/etc/opt/SUNWps/desktop/default/tld/wireless_mail.tld

NB. It may be necessary to change the ownership of these files back to root:sys prior to installing a future revision of the patch in order to avoid attribute verification errors. This is an unfortunate and unavoidable consequence of the limited support for non-root installs in the patchadd command.

Back to top

In order to provide an equivalent level of backout on the Linux platform as that available on the Solaris platform, the upgrade script uses the --repackage option to the rpm command. This creates backup rpm files of the installed Portal software at that point, including any customisations that have been made. The remove script can be used to rollback if the patch needs to be backed out.

However, due to an unavoidable rpm bug, this backout functionality does not function correctly if the Portal Server was installed in a location other than the default. Under these circumstances it is necessary to restore the original rpm files before running the remove script, and then recover any overwritten customisations manually.

The repackage process stores the rollback rpm files in the /var/spool/backup/118950-15 directory, which will be created if necessary. You should avoid deleting this directory, even if you are forced to remove the patch.

Back to top

Every attempt is made by the patch installer to both preserve customized template information. However, since the contents of the files cannot be accurately predetermined, any modified template files are backed up in the same directory as their updated counterparts with the patch name postfixed to the template name.

For example, when a patch is installed on the Solaris platform:
/etc/opt/SUNWps/desktop/default/MyFrontPageTabPanelContainer/Netlet/display.template
would be backed up to
/etc/opt/SUNWps/desktop/default/MyFrontPageTabPanelContainer/Netlet/display.template.pre118950-15.

Check the patch README.118950-15 file for the full list of files modified by this patch.

Back to top

Because the Portal Server itself is so customizable, you should follow some precautions to ensure that any customizations made to the Portal Server are preserved after a product upgrade. First, set up a customized template directory if you have not already done so. While this directory could be an entire subset of the default template directory, it is advisable to only copy over those template files that you will be customizing. This particular scheme would then use the default directory as a 'base' for all templates and would help insure that customized templates are not accidentally overwritten when the default templates are modified.

NOTE: Files in the default template directory should never be customized.

1. Create a directory at the same level as the /etc/opt/SUNWps/desktop/default/ on Solaris, or /etc/opt/sun/portal/desktop/default on Linux, with a new name such as mytemplates. In that directory, only copy the templates you need to modify in their proper directories. The other templates will be retrieved as needed from the default directory using Portal's own filelookup mechanism.
2. Edit the templates in the mytemplates directory according to your own preference.
3. Log into the administration console.
4. Select the appropriate services configuration screen. For example, select View: Services to administrate the desktop service globally. Alternately, select an organization, and then View: Services to administrate the desktop service for that organization only.
5. Expand the link next to Desktop under the Portal Server Configuration subheading on the left view pane
6. Modify the Desktop Type field located on the right view pane from default to mytemplates.
7. Select Save

As a general rule of thumb, avoid modifying templates that have only a functional purpose rather than a look and feel purpose. One example of a template that should not need modifications is the NetletProvider/display.template. This template contains only JavaScript necessary for the launching of the Netlet. The contents of the Netlet Pop-up window should instead be customized by modifying the associated .properties file. The reason for this is that there could be a functional change in the product that would overwrite a customization done specifically to that particular template file. This example also exhibits why it is important to only keep customized files in the customized template directory.

Back to top

The perftune now uses the amtune script supplied with Access Manager. However, for this to function correctly on Solaris, an Access Manager patch is required. The patchids are 119259-01 (sparc) and 119260-01 (x86). Alternatively, the following changes can be applied manually.

1. Edit /opt/SUNWam/bin/amtune/amtune-as8, changing the line:

   $ECHO $ASADMIN_PASSWORD > $ASADMIN_PASSFILE

   to:

   $ECHO "ASADMIN_PASSWORD=$ASADMIN_PASSWORD" > $ASADMIN_PASSFILE

2. Edit /opt/SUNWam/bin/amtune/amtune-env, changing the line:

   ASADMIN=$CONTAINER_BASE_DIR/bin/asadmin

   to:

   ASADMIN=/opt/SUNWappserver/appserver/bin/asadmin

Back to top

A small number of updates to the Portal Server branding are missing from Java Enterprise System Portal Server 6 2005Q1. Should you wish to apply those updates manually to avoid confusion, you can do so as follows.

1. Access the amconsole
2. For default org select the Services drop down menu
3. Select Portal Desktop
4. In the right panel select Edit xml directly
5. In the xml file, change the brandImage2BgColor attribute to white (#ffffff) from yellow (#FBE249)
6. Click on OK and then Save
7. Select the Service Configuration tab
8. Select Portal Desktop in the left pane
9. Click on Edit XML Directly on the right hand side
10. Search for 2004Q2 and replace it with 2005Q1 in all the instances of productName
11. Click on Identity Management tab
12. Select Portal Desktop in the left pane
13. Click on Edit XML Directly on the right side
14. Search for 2004Q2 and replace it with 2005Q1 in all the instances of productName

Back to top

After a system is upgraded from Java Enterprise System Portal Server 6 2004Q2 to Java Enterprise System Portal Server 6 2005Q1, the link to invoke the Proxylet rules will not appear until the Proxylet Service is reregistered as follows:

1. For the default org, select Services from the View drop down list
2. Select the Proxylet service and click Delete
3. Clicking the Add button, select the Proxylet service in the right hand frame and click OK

Back to top

The Launch Calendar link now opens the Communication Express page rather than directly opening the Calendar tab. The user must now manually navigate from the mail tab to the calendar tab.

Back to top

The fix for Bug Id 6211569 (UWC address book channel does not work with proxy auth) also requires Universal Web Client patch 118540-12 or later. After installing this patch, you will need to perform the following steps:

# /opt/SUWNuwc/sbin/patch-config /opt/SUNWuwc/install/patch/<patchid>
# /opt/SUWNuwc/sbin/install-newconfig /opt/SUNWuwc/install/patch/<patchid>

Uncomment the following line in <UWC-deploy-path>/WEB-INF/config/uwcauth.properties and add the uid (or list of uids) of the proxy admin:

!uwcauth.admins=<list of comma seperated admins>

Once both patches are installed, you will need to add additional attributes to the SUN-UWC-ADDRESS-BOOK SSOAdapter template as follows:

1. Authenticate to the Identity Server Administration Console
2. Select Service Configuration
3. Select SSO Adapter
4. Select Edit Properties... for the SUN-UWC-ADDRESS-BOOK SSO Adapter template
5. Select New Default...
1. Specify enableProxyAuth for Name
2. Specify true for Value
3. Select Create
6. Select New Default...
1. Specify proxyAdminUid for Name
2. Specify the proxy authentication Admin user id for Value
3. Select Create
7. Select New Default...
1. Specify proxyAdminPassword for Name
2. Specify the proxy authentication Admin user password for Value
3. Select Create
8. Select New Default...
1. Specify userAttribute for Name
2. Specify uid for Value
3. Select Create

Back to top

The fix for Bug Id 6229250 (MS Address Book is not accessible on Portal Desktop) requires the following changes to be made to the SUN-ONE-ADDRESS-BOOK SSO Adapter template:

1. Authenticate to the Identity Server Administration Console
2. Select Service Configuration
3. Select SSO Adapter
4. Select Edit Properties... for the SUN-ONE-ADDRESS-BOOK SSO Adapter template
5. Select New Merge...
1. Specify domain for Name
2. Select Create

Back to top

Some links on the Portal Server Desktop are generated using the server's port/host/protocol values. If a load balancer sitting in front of the Portal Server has been configured to perform SSL termination, there will be a port/protocol mismatch between LB and Portal Server. Due to which some links created on the desktop will be broken. To resolve this problem, the following properties needs to be added to the desktopconfig.properties file located at /etc/opt/SUNWps/desktop/desktopconfig.properties on a Solaris machine and at /etc/opt/sun/portal/desktop/desktopconfig.properties on Linux.

lbHosts=<list of LB Host>
lb.host1.protocol=<host1 protocol>
lb.host1.port=<host1 port>

Depending on the incoming request's host header, protocol and port are fetched from the properties file and passed on to form a link.

Example:
lbHosts=host1.com,host2.com
lb.host1.com.protocol=https
lb.host1.com.port=1443
lb.host2.com.protocol=https
lb.host2.com.port=442

To enable switching of protocol and port depending on the client, its necessary to make the authlessanonymous desktop cache free. To do that, set the refreshTime property as zero for JSPTabContainer in authlessanonymous' desktop.

Back to top

Prerequisite: Install web container, AM and PS in SSL mode. Make sure /etc/opt/SUNWps/PSConfig.properties file is present once the installation is complete.

Configuration of SSL mode in Portal Server 2005Q1 is broken. To overcome the problem, install PS6.3.1P10 (11895x-10). Then, run psconfig from /<basedir>/SUNWps/lib to configure the Portal in SSL mode.

For example:
# cd /opt/SUNWps/lib
# ./psconfig

Back to top

When multiple instances of Portal are to be deployed behind a load balancer, and it is not possible to configure the load balancer to support sticky sessions, then it is necessary to enable the notification system for SSOAdapter Configurations.

To enable the SSOAdapter Configuration notification system, perform the following steps:

1. Edit the following file:
   • (Solaris): /opt/SUNWps/web-src/WEB-INF/classes/SAALContext.properties
   • (Linux): /opt/sun/portal/web-src/WEB-INF/classes/SAALContext.properties
   To contain the following entry:

   clearCacheUsingNotification=true
   

2. Redeploy portal:

   #/opt/SUNWps/bin/deploy redeploy (On Solaris)
   or
   #/opt/sun/portal/bin/deploy redeploy (On Linux)
   

These steps must be performed on each portal instance.

Back to top