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-23

   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-23 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-23.

Check the patch README.118950-23 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/SUNWuwc/sbin/patch-config /opt/SUNWuwc/install/patch/<patchid>
# /opt/SUNWuwc/sbin/install-newconfig /opt/SUNWuwc/install/patch/<patchid>

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

!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
9. Select Change Type...
1. Select host, clientPort, and domain in the Type: Merge text field
2. Select Move to default
3. Select Save
10. Specify values for host, clientPort, and domain in the Value column of the Properties table that identify the UWC Address book instance
11. Select Save

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

To configure Portal Server in SSL Mode, proceed as follows:

1. Install the web container, Access Manager, and Portal Server in SSL mode.
2. Ensure the /etc/opt/SUNWps/PSConfig.properties file is present once the installation is complete.
3. Install Java Enterprise System Portal Server 6 2005Q1/2005Q4 Patch 23.
4. Use the psconfig to configure the Portal in SSL mode:

   # 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, edit the /opt/SUNWps/web-src/WEB-INF/classes/SAALContext.properties file as follows, and redeploy your Portal web application:

clearCacheUsingNotification=true

Back to top

To enable search to work through filtered roles perform the following steps:

security-dsame-use-filtered-roles=true

Back to top

MailJSPProvider and UWCMailJSPProvider allow setting timeout values for IMAP and POP3 connections. The timeout values, which are specified in milliseconds, are used to directly set the Javamail properties as described below.

mail.imap.connectiontimeout = Socket connection timeout value in milliseconds
mail.imap.timeout = Socket I/O timeout value in milliseconds

mail.pop3.connectiontimeout = Socket connection timeout value in milliseconds
mail.pop3.timeout = Socket I/O timeout value in milliseconds

The mail.imap.timeout and mail.pop3.timeout values can be specified by adding a new default property timeout to the appropriate SSO Adapter template. Similarly for mail.imap.connectiontimeout and mail.pop3.connectiontimeout, a new default property connectiontimeout should be added to the appropriate SSO Adapter Template.

The steps below show how to add the timeout and connectiontimeout properties to an SSO adapter Template:

1. Login to amconsole
2. Click Service Configuration tab
3. Click the arrow next to SSO Adapter in the left panel
4. On the right panel, under SSO Adapter Templates click on Edit Properties of the desired SSO Adapter Template (e.g. SUN-ONE-MAIL)
5. On the right panel, click New Default button under Properties to bring up the form to add a new property
6. For timeout: Enter timeout under Name and click on Save
7. For connectiontimeout: Enter connectiontimeout under 1Name and click on Save
8. Return to the SSO adapter template properties editor, and add appropriate values (milliseconds) in the timeout and connectiontimeout fields.

Back to top

Under certain circumstances, IE can generate spontaneous requests for content. One example is when Microsoft Office is installed and the Disussion bar is enabled in IE. As these requests have not been rewritten, the gateway mistakes them for authentication requests, which can invalidate the user's session. To avoid this, it is now possible to configure the gateway to ignore certain URL paths, responding to any request for one of these paths with a 404 (File Not Found) response.

The URI ignore list is configured by adding the following entry to the platform.conf.<instance> file located in /etc/opt/SUNWps (Solaris) or /etc/opt/sun (Linux) and restarting the gateway:

gateway.ignoreURIList=<comma separated list of URL paths>

eg. To ignore the requests from IE when Microsoft Office is installed and the Discussion Bar is enabled add:

gateway.ignoreURIList=/MSOffice/cltreq.asp,/_vti_bin/owssvr.dll

Back to top

The title of a portlet channel is now determined using the first of the following sequence of lookups that returns a value:

1. portlet getTitle() implementation
2. value for javax.portlet.title as declared in the resource bundle
3. title given in the display profile
4. title given in the portlet.xml file

eg:

<portlet-info>
<title> MYPORTLET </title>
</portlet-info>

For this change to take affect, you must redeploy the portlets as follows, and then restart your web container instances:

# /opt/SUNWps/bin/pdeploy undeploy -u<admin user> -w<password> -p<webcontainer pwd> -g portletappname
# /opt/SUNWps/bin/pdeploy deploy -u<admin user> -w<password> -p<webcontainer pwd> -g portletapp.war

Back to top

Portal Server 2005Q1 supports Exchange 2003 out of the box.

To support Exchange 2003 SP1, its necessary to do the following :
1. Goto amconsole -> Service Configuration -> Portal Server Configuration/Rewriter ->
2. Edit the ruleset "exchange_2003_owa_ruleset"
3. Add <Variable name="g_sBase" type="URL"/> below <JSRules>
4. Save the ruleset
5. Restart all your servers

Back to top

The process of deploying Portal Server into an Application Server cluster has been improved and bug fixes are provided that permit the PortletSession mechanism to utilize the http session failover service provided by an Application Server cluster configured for HA operation.

Requirements

These requirements reflect the scenarios in which Portal Server has been tested using an HA enabled Application Server cluster. Deviations from these requirements may be possible, but cannot be guaranteed to work in all cases.

1. You must complete installation and configuration of all components Portal Server depends upon prior to beginning Portal Server installation using an Application Server cluster. In general terms, this includes the following:
   • Directory Server
   • Application Server
   • Access Manager
   It is assumed that an appropriate installation of these components will be performed using their respective installation documents. Special attention should be paid to the instructions provided for Access manager for those deployments requiring session failover.
2. All machines/zones on which Portal Server is to be installed must include at least the following:
   • Access Manager SDK
   • Application Server Node Agent
3. An appropriate HA enabled Application Server cluster and its constituent Server Instances must be created before beginning Portal Server installation.
   • If JES Application Server 2005Q1 is used, patch 119166-13 or later must be applied prior to starting Portal installation.
4. An appropriate load balancer configured for sticky sessions should be provided. E.g., the Load Balancer plugin for Web Server.
5. The primary Portal Server installation must be performed on a machine on which a Node Agent installation and Server Instance instantiation are co-located with the Domain Administration Server installation that manages the cluster into which Portal will be deployed.
6. All secondary Portal Server installations should be located on machines that do not include a Domain Administration Server installation.

Limitations

1. Do not attempt to install and configure Portal Server simultaneously with other components except as specified.
2. It is suggested that the installations on the machines/zones hosting the pertinent Application Server Server Instances be kept as simple as possible. E.g., try to install Portal Server Secure Remote Access components on a separate machine from that which is used to host a Server Instance used by Portal Server.
3. These instructions do not apply to Linux installations at this time.

Portal Server Installation Process

1. Complete installation and configuration of all non-Portal components prior to proceeding, according to the requirements described above.
2. On the machine supporting the primary portal installation:
   1. Using the JES installer, install either JES Portal Server 2005Q1 or 2005Q4 using "Configure Later" mode. Do not configure using the installer
   2. Apply patch 118950-23.
   3. Create an appropriate "silent" configuration file. See The Silent Configuration File below.
   4. Perform the following steps:
      • #JAVA_HOME= ; export JAVA_HOME
      • #cd /opt/SUNWps/lib
      • #./psconfig -s <silent-file>
      • #/opt/SUNWps/bin/deploy redeploy -ha -instance <cluster-name>
      Note: the "-ha" option may be ommitted for deployments into a cluster not requiring HA service.
   5. Restart the cluster. Verify first portal instance is working by accessing the anonymous desktop on the specific server instance.
3. On all machines supporting secondary portal installations:
   1. Using the JES installer, install the same version of JES Portal Server as was installed for the primary installation using the "Configure Later" mode. Do not configure using the installer
   2. Apply patch 118950-23.
   3. Create an appropriate "silent" configuration file. See The Silent Configuration File below. Note: Be sure the following line is present in all silent configuration files used for secondary Portal Server installations.
   • PS_DEPLOY_INSTANCE_ONLY=true
   4. Perform the following steps:
      • #JAVA_HOME= ; export JAVA_HOME
      • #cd /opt/SUNWps/lib
      • #./psconfig -s <silent-file>
   5. Verify that the file "/etc/opt/SUNWam/config/AMConfig.properties" contains appropriate entries for the following:
      • com.iplanet.am.notification.url=http://<am-server-host>:<am-server-port>/amserver/notificationservice Where <am-server-host> and <am-server-port> refer to the Access Manager service.
      • com.iplanet.am.cookie.encode=true Required for Application Server.
   6. Repeat the above steps for a secondary installation on each machine hosting a server instance in the cluster into which Portal Server is being deployed.
   7. Restart the cluster. Assuming that the load balancer has been properly configured, Portal Server should now be fully functional in the HA Application Server cluster.

The Silent Configuration File

• COMPONENTS=1 Indicates that Portal will be configured.
• PS_DEPLOY_INSTANCE=<cluster-name> Where <cluster-name> identifies the Application Server cluster into which Portal will be or has been deployed.
• PS_DEPLOY_ADMIN_HOST=<domain-admin-server-host> Where <domain-admin-server-host> identifies the Domain Administration Server that is managing the cluster into which Portal will be or has been deployed.
• PS_DEPLOY_ADMIN_PORT=<domain-admin-server-port> Where <domain-admin-server-port> identifies the port of the Domain Administration Server that is managing the cluster into which Portal will be or has been deployed. This is typically 4849.
• PS_DEPLOY_PRODUCT_DIR=/var/opt/SUNWappserver/domains/domain1 Should be the same value as PS_DEPLOY_INSTANCE_DIR.
• PS_LOAD_BALANCER_URL=http://<lb-host>:<lb-port>/portal Where <lb-host> and <lb-port> refer to the host and port providing load balancer service.
• PS_HOST=<ps-host> Where <ps-host> specifies the host name on which this particular instance of Portal Server is being installed.
• PS_PORT=<ps-port> Where <ps-port> specifies the port that will provide service for this particular instance of Portal Server.
• PS_IDSAME_ADMIN_PASSWORD=<am-admin-password> Where <am-admin-password> specifies the password that will be used when performing administrative changes to the Access Manager service as the "amadmin" user.
• PS_IDSAME_LDAPUSER_PASSWORD=<am-ldapuser-password> Where <am-ldapuser-password> specifies the password that will be used when performing administrative changes to the Access Manager service as the "amldapuser" user.
• PS_DS_DIRMGR_PASSWORD=<dir-mgr-password> Where <dir-mgr-password> specifies the password that will be used when performing administrative changes to the Directory Server.
• PS_DEPLOY_ADMIN_PASSWORD=<das-password> Where <das-password> specifies the password that will be used when performing administrative changes using the Domain Administration Server.
• PS_DEPLOY_INSTANCE_ONLY=<boolean> When <boolean> is "true", psconfig will perform no directory server or web container related configuration, though certain local filesystem based configurations will still be performed. All secondary Portal installations should be performed with <boolean> set to "true". All primary Portal installations should make sure <boolean> is not set to "true".

Changes to The "deploy" Command

The following changes have been incorporated into the "deploy" command:

1. -ha option: When the -ha option is specified, the Portal web app will be deployed in such a fashion as to permit operation with an HA enabled Application Server cluster. This option only takes effect when used in conjunction with the JES Application Server.
2. When the file "/etc/opt/SUNWps/PSConfig.properties" contains "DEPLOY_INSTANCE_ONLY=true", the deploy command will no longer actually deploy the Portal web app. This is the normal case for secondary Portal installations. I.e., the "deploy" command should only be used from the primary Portal installation.

Comments Regarding Maintenance Procedures

The maintenance patches for Portal contain content that is deployed as part of the Portal web application, as well as content that may be deployed as part of a customer's Portlet web application.

Any given maintenance patch should be applied to all machines hosting a Server Instance that is part of a cluster into which Portal related web applications have been deployed.

After applying a maintenance patch to all pertinent machines, remember to redeploy the Portal web application and all affected Portlet web applications from the machine hosting the primary Portal installation.

Back to top