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.

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 118263-19

   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

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.pre118263-19.

Check the patch README.118263-19 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

This patch includes a new option to configure a fixed timeout for the network socket that is opened between the Gateway and Netlet Proxy if the Netlet Proxy is in use. This option was included to reduce socket depletion resulting from sockets on the Netlet Proxy node remaining indefinitely in an ESTABLISHED state.

For example, prior to this fix, if a Telnet session was opened via the Netlet and there was no activity for 2-4 minutes, the Telnet session would timeout as a result of the idle timout being reached. However, the socket opened between Gateway and Netlet Proxy would remain in an ESTABLISHED state. The same behavior would result from a user explicitly exiting the Telnet session as well.

The new option included with this patch gives portal administrators the ability to explicitly set a timeout for how long the abandoned socket should remain open. The default value of this timeout is 10 minutes. So, if there is no activity between the Gateway and Netlet Proxy socket for 10 minutes, the socket will be closed. If this value needs to be changed, an entry for gateway.netletproxy.socket.timeout can be added to the platform.conf file on the Gateway with the new value specifi ed in milliseconds.

Example:
To change the value to five minutes, the following step should be performed on the Gateway instance(s) which require modification.

1. Change directory to /etc/opt/SUNWps on a Solaris machine, or /etc/opt/sun on a Linux machine
2. Backup the platform.conf.<gateway_instance> file; where gateway_instance is the instance you want to configure this option for.
3. Edit the platform.conf.<gateway_instance> file and add the following entry:
   
   gateway.netletproxy.socket.timeout=300000
   
   
4. Restart the gateway Instance

NOTE: If the socket timeout is set too high, the socket depletion could be significant enough to cause Netlet connections to hang.

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

If PS (Portal Server) and IS (Identity Server) are installed on seperate machines and either of these machines are behind a load balancer then the following needs to be done.

If IS is behind a load balancer, then the URL of the load balancer needs to be added to the Platform Profile list in IS Admin Console and gateway.ignoreServerList=true should be set in the platform.conf file of the Gateway instance.

If PS is behind a load balancer, then the URL of the load balancer needs to be added to the Gateway Profile Portal Server list under the IS Admin Console for the gateway instance.

The above steps are needed only when PS and IS are on seperate machines and either PS or IS is behind a load balancer.

Back to top

By default, the Gateway requires a specific instance of Portal Server and a specific instance of Identity Server to be available when the Gateway starts up (although on systems where Portal and Identity have not been seperated, these will be one and the same). This creates single points of failure for each Gateway instance that prevent it from properly restarting should either the Portal or Identity Server be temporarily unavailable.

To provide an additional level of redundancy, it is now possible to specify additional Portal and Identity Servers for each Gateway to use during startup should the defaults be unavailable by adding them to the /etc/opt/SUNWps/platform.conf.<gateway_instance> file.

Additional Portal Servers are specified by adding additional gateway.dsame.agent.? entries, each numbered sequentially. The first entry (which will already exist) must be numbered 0.

gateway.dsame.agent.0=http://portalserver1:80/portal/RemoteConfigServlet
gateway.dsame.agent.1=http://portalserver2:80/portal/RemoteConfigServlet

Additional Identity Servers are specified by adding additional gateway.identity.server.? entries, each also numbered sequentially from 0.

gateway.identity.server.0=http://identityserver1:80/
gateway.identity.server.1=http://identityserver2:80/

Additional Identity Server instances must also be added to the /opt/SUNWam/lib/AMConfig.properties file, by changing:

com.iplanet.am.naming.url=http://identityserver1:80/amserver/namingservice

to:

com.iplanet.am.naming.url=http://identityserver1:80/amserver/namingservice http://identityserver2:80/amserver/namingservice

and:

com.iplanet.am.notification.url=http://identityserver1:80/amserver/notificationservice

to:

com.iplanet.am.notification.url=http://identityserver1:80/amserver/notificationservice http://identityserver2:80/amserver/notificationservice

It is necessary to specify all available Portal/Identity server instances in all the locations specified above to achieve redundancy. If the Portal and Identity servers have not been seperated, the set of instances given for gateway.dsame.agent.?, gateway.identity.server.? and in AMConfig.properties should be the same.

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

Patch 118263-19 fixes issues of title value for the portlet channel.

The title value of the portlet channel will now be fetched depending on this priority:

1. getTitle() implementation by the user
2. javax.portlet.title declared in the resource bundle
3. title value from display profile
4. title value from portlet.xml

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

For this patch to get effective, its essential to redeploy the portlets.
You can redeploy the portlet applications as follows:
1. <install_dir>/SUNWps/bin/pdeploy undeploy -u<admin user> -w<password> -p<webcontainer pwd> -g portletappname
2. <install_dir>/SUNWps/bin/pdeploy deploy -u<admin user> -w<password> -p<webcontainer pwd> -g portletapp.war
3. Restart all the servers

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

As part of the normal operation of the Portlet Container, an existing http session may be invalidated. This is typically done during the transition between an "Authless Anonymous" desktop and an authenticated desktop that uses the Portlet Container. This is to insure that the http session provided to the Portlet Container is in a known and safe state appropriate to the (non-)authenticated principal that may be in effect at the time.

Some customers may wish to deploy web applications that share the same http session as the Portal and Portlet web applications. Such web applications may find it necessary to disable the session invalidation logic implemented by the Portlet Container.

To disable the Portlet Container's session invalidation logic, a web application will need to perform the following operation:

...
HttpSession session = req.getSession();
session.setAttribute("javax.portlet.do_not_invalidate_http_session", "true");
...

Web applications that perform this operation will need to assume the responsibility for managing the security of an http session during the transition between non-authenticated and authenticated states. If the customer does not wish the state stored in the http session of a non-authenticated user to become available within the http session following authentication, then the web application should invalidate the existing http session, and create a new http session, before any requests are presented to the authenticated Portal Desktop.

Following application of this patch, the customer must redeploy both the Portal and Portlet web applications for the changes to become completely effective.

Back to top