|
|
|
|
|
|
|
Features OverviewFeatures New to
For a list of Portal patches that are obsoleted by refer to the included patch is not a standalone installation and does not include Portal Server 6.2. Portal Server 6.2 must be installed prior to upgrading to or installing . can be installed on top of previous patches as it is cumulative. Refer to the section titled New Portal Patching Methodology for additional information. Pre-installation ConsiderationsIn addition to the profile and flatfile changes listed in the Template Modifications Required section of the this document, there are also internal changes made that may directly affect how you use, test, or evaluate the product. Most of these behavioral changes tend to be directly related to the rewriter component, but there are other parts of the product that may be affected, as well. As such, it is important that this patch, as with any other, be test thoroughly on a development or QA system prior to being put in to production. Additionally, because of the nature of Portal 6x distribution and the customization requirements for the product, special attention should be given to JSP files that must be modified by the patch installer in order to fix defects, and/or for the product to continue functioning normally. Noticeable Behavioral Changes after Installing
Installation InformationThese installation instructions provide steps to install For other document information about Sun Portal Server 6.1 software products, visit: http://docs.sun.com/db/coll/S1_PortalServer_61?q=portalFor Portal Server software packages, visit: http://www.sun.com/downloads System Requirements This section describes the system requirements for
Installation Overview Please familiarize yourself completelly with the release notes prior to attempting either installation of, or upgrade to,
The following directories and files are included in
:
Installation Instructions
NOTES:
STEPS:
Template Modifications RequiredEvery attempt is made by the patch installer to both preserve customized template information and automate the update of that 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, /etc/opt/SUNWps/desktop/default/MyFrontPageTabPanelContainer \ /Netlet/display.template might be backed up to /etc/opt/SUNWps/desktop/default/MyFrontPageTabPanelContainer/ \ /Netlet/display.template.pre . The backup files are also copied back to their original location upon patch removal. To help avoid potential content-related customization problems, refer to the Tips for Customizing Templates section of this document. The following template files, .properties files, jsps, xml files, and platform files are modified by this patch consolidation:
Tips for Customizing TemplatesBecause the Portal Server itself is so customizable, you should follow some precautions
to insure 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.
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. Checking the Current Product Install Leveland subsequent patch consolidations make changes to both the gateway, and version scripts necessary to print additional information about the current install level. In previous versions of Portal, this information had to be gathered from a variety of sources including the package versions, patchadd -p output, or from a flatfile that was not updated by patches themselves. Portal patches will now update the version files when they are installed and again when they are backed out. To get the version information for the Gateway node, from node itself as root, type: # /etc/init.d/gateway versionTo get the version information for the Portal Server node, from the node itself as root, type: # <install_dir>/SUNWps/bin/versionTo get the version information for the Identity Server node, from the node itself as root, type: # /etc/init.d/amserver version An RFE has been filed to modify the Identity Server version information to match that which is available in Portal Server. The First line of the version output contains the major version information that may also include the product build date. Each remaining line of output represents a patch that has been applied to the major version. The comma separated list in order includes the actual patchID (currently a Solaris patch ID), the patch name, and the patch install date. All of this information is important for supportability purposes and to help Portal administrators in product maintainance.  Back to top
Enabling Exchange 2003 Support Through the RewriterThis section covers the rewriter integration with Microsoft Outlook Web Access that is delivered as a part of Microsoft Exchange 2003. For integrations with other versions of Microsoft Exchange Server refer to the Sun Blueprints online article titled Sun ONE Portal Server and Microsoft Exchange Integration Cookbook. Follow the steps bellow in enable Microsoft Exchange 2003 support through the rewriter.
As a part of the patch installation, an additional ruleset has been added to the Portal Service in the Identity Server. A new rule association can be created from the Rewriter tab of the Gateway profile Service Configuration. For instance, to create the association for the default Gateway profile:
NTLM Authentication must be disabled on the Exchange Server if Internet Explorer browser clients will be used. NTLM is a Windows domain based proprietary authentication protocol that is not supported by the Gateway reverse proxy. HTTP Basic Authentication can be used instead and the Portal Server can cache the authentication credentials to achieve SSO functionality for remote users. For information on enabling HTTP Basic Authentication Caching refer to the SRA Administrator's Guide. To disable NTLM authentication in Microsoft Exchange 2003 perform the following steps: Back to top
Fixing Problems With Portlet ChannelsPatch fixes the following problems with portlet channels.
Back to top
|
|||||||||||||||||||||||||||||||||||||||||||||||||||