Installing WebSphere Application Server version 8 web components

This topic provides instructions for installing new instances of IBM WebSphere Application Server version 8 for use with the RequisiteWeb application server in Rational® RequisitePro® version 7.1.3.1 or later.

About this task

WebSphere Application Server and IBM HTTP Server are installed using IBM Installation Manager. You must install WebSphere and HTTP Server first, and then install Rational RequisitePro web components.

Note: WebSphere Application Server version 8 is not compatible with Rational RequisitePro version 7.1.3.0 or earlier.

You can obtain WebSphere Application Server and HTTP Server V8 from IBM Passport Advantage at http://www.ibm.com/software/passportadvantage. Fixpacks are available from IBM Support Fix Central at http://www.ibm.com/support/fixcentral/.

Here is an overview of the steps you will use to install web server components for Rational ClearCase, Rational ClearQuest, and Rational RequisitePro:

1. Using Installation Manager, install the following products and components:
   • IBM WebSphere Application Server
   • IBM HTTP Server for WebSphere Application Server
   • Web Server Plug-ins for IBM WebSphere Application Server
   • WebSphere Customization Toolbox
2. Run the Web Server Plug-ins Configuration Tool, which is part of the Toolbox, to configure the web server to communicate with the application server.
3. Install or upgrade Rational RequisitePro, including web server components.

Restrictions

Before you begin an installation of WebSphere Application Server version 8, review the following restrictions:

• Prepare your operating system for WebSphere and IBM HTTP Server.
• Refer to technote 1573966 "Known issues and limitations found while installing or configuring WebSphere Application Server and IBM HTTP Server v8.0 to work with IBM Rational ClearCase 8.0.0.1, IBM Rational ClearQuest 8.0.0.1 or IBM Rational RequisitePro 7.1.3.1".
• Do not use symbolic links as the destination directory. Symbolic links are not supported.
• Do not use a semicolon in the directory name. WebSphere Application Server cannot install properly if the target directory includes a semicolon. A semicolon is the character used to construct the class path on Windows systems.
• The maximum path length for the installation location on the Windows Server 2008, Windows Vista, and Windows 7 operating systems is 60 characters.
• Deleting the default target location and leaving an installation-directory field empty prevents you from continuing.

Procedure

To install WebSphere Application Server components:

1. Launch Installation Manager.
2. Select File > Preferences and add the installation repository for WebSphere Application Server in the Repositories section on the Preferences panel.
   Tip: In Installation Manager, select Search service repositories during installation and updates on the Installation Manager Repository preference page. Then, if you are connected to the Internet while you install, you can click Check for Other Versions and Extensions to search for updates in the default update repositories for the selected packages. In this case, you do not need to add the specific service-repository URL to the Installation Manager Repository preference page. Select the fixes to install. Any recommended fixes are selected by default. If there are recommended fixes, you can select the option to show only recommended fixes and hide non-recommended fixes.
3. Click Install at the main Installation Manager screen.
4. At the Install Packages panel, select the following packages to install, and then click Next to continue the installation.
   • IBM HTTP Server for WebSphere Application Server, Version 8.0.0.0 (or later)
   • IBM WebSphere Application Server, Version 8.0.0.0 (or later)
   • Web Server Plug-ins for IBM WebSphere Application Server, Version 8.0.0.0 (or later)
   • WebSphere Customization Toolbox, Version 8.0.0.0 (or later)
5. If you want to install a fix pack for WebSphere Application Server and IBM HTTP Server, such as version 8.0.0.1, select the Check all versions and Check for Other Versions and Extensions check boxes. The fix pack versions are displayed in the list of packages. If they do not appear then the required repository is not included in the preferences; in this case, see Installation Manager tip in step 2. If package list is correct, click Next.
6. If there are any fixes available, you are prompted to choose which ones to install. You should install all listed fixes. Choose the fixes to install and click Next.
7. Accept the license agreement and click Next.
8. At the next panel, you can change the default installation directory by selecting a package group name and specifying a new pathname in the Installation Directory field. Click Next.
   Note: If you change the install location of either the AppServer, Plug-ins, or Toolbox, you might need to make the same change for the others. Do not use locations that are already in use by another version of WebSphere Application Server and IBM HTTP Server on the same machine.
9. Select your translation choices and click Next.
10. At the Select the features to install panel, verify that IBM HTTP Server, IBM WebSphere Application Server, Web Server Plug-ins, and WebSphere Customization Toolbox are selected. Accept default selections. Click Next.
11. On the Configuration for IBM HTTP Server panel, specify your web server configuration.
12. Specify a port number on which IBM HTTP Server will communicate. Use the default port 80, unless you must use an alternate port to avoid a conflict.
13. Choose whether to run the IBM HTTP Server as a Windows service. You can configure the service to run as local system account or a user ID that you specify. The user ID requires the following advanced user rights:
    • Act as part of the operating system.
    • Log on as a service
14. Choose startup type Automatic.
    Important: If you do not select Run IBM HTTP Server as a Windows Service, this instance of IBM HTTP Server cannot be stopped or started by the WebSphere Application Server administrative console. At any time after installation, you can create a new service by running the following command: ihs_root/bin/httpd.exe -n new_service_name -k install and then update the web server definition in the administrative console to reflect the new service name.
15. Click Next. Review the summary information and click Install. When the install completes successfully, you typically see a choice of post-installation tools:
    • WebSphere Customization Toolbox. You need this tool to configure the HTTP plug-ins. This tool must be run on Windows as built-in Administrator or as a local user in the Administrator group. For details, see APAR PM46369.
    • Profile Management Tool. You can use this tool to create a WebSphere Application Server profile if a web component will be deployed into an existing profile.
16. Choose the WebSphere Customization Toolbox to configure the plug-in and click Finish.
    Note: If you do not see an option to run the WebSphere Customization Toolbox, click the Windows Start menu: All Programs > IBM WebSphere > WebSphere Customization Toolbox V8.0 > Tools > WebSphere Plug-ins Configuration Tool.

IBM Customer Experience Suite, IBM WebSphere Portal, and IBM Web Content Manager V8.0

Hey WebSpherians!

So I have decided to venture into the WCM and Portal 8 Realm.Don't forget that I will still be responding to all the WCM/Portal 6 and 7 questions that get submitted.

I decided to add this article plus the source as it does provide some interesting information about my next adventure.

Source :https://www.ibm.com/developerworks/mydeveloperworks/blogs/WebSpherePortal/?lang=en 


Take a look at the latest updates available with the IBM Customer Experience Suite, WebSphere Portal and Web Content Manager Beta Two release. 

This beta release operates on WebSphere Application Server Version 8, and includes updates that can provide your users with a more social, mobile and integrated experience.
Version 8.0 Beta two highlights include

• Managed Pages
  • A simplified way to create and manage portal pages and web content using a new integrated toolbar.
  • New page draft and approval process lets you preview and approve changes to pages before publishing them.
• Site Area Templates
  • Create site area templates that define the authoring settings, such as the design of the form, elements and fields on a form, and default values.
  • Restrict authoring templates usage. For example, use site area templates to only allow "news" items to be created within a "news" site area of a website.
• Enhanced Projects
  • Add users as approvers for a project and send a project through a review state before publishing.
• Simplified Business Process Management
  • Users access relevant tasks and activities for multiple Business Process Management solutions from a single user interface, the Unified Task List portlet.
  • Integrate your site with several Process Management solutions.
• Enhanced SAP integration
  • Support for the new IBM WebSphere Portal Integrator for SAP lets you expose elements from SAP Netweaver Portal directly into WebSphere Portal.
• IBM Installation Manager
  • Manage the software life cycle with a single tool: Install, Update, Rollback, Modify, and Uninstall.
  • Faster installation performance and better integration with other IBM products.
• Social Business in Context
  • New Community Page support lets you more readily scope and place IBM Connections portlets in the right Portal and WCM context.
    • IBM Connections Community Pages portlets are available for Profiles and Blogs with Beta 2.
  • A consistent tagging and rating experience between WebSphere Portal, Web Content Manager, and IBM Connections.
  • OpenID Authentication lets portal users authenticate with public social network credentials, such as a Facebook ID, Google ID or Yahoo ID.

Access the details, Beta software, documentation and support forum here:  http://tinyurl.com/ybmsqkz
 We look forward to your impressions and experiences with the latest updates.

ConfigServiceException: javax.management.JMRuntimeException: ADMN0022E: Access is denied for the resolve operation on ConfigService MBean because of insufficient or empty credentials.

 So WCM 7 Post migration step fail Right?Complaining about access and credentials?

The command you were running:

ConfigEngine.sh wcm-post-migration-data-update -DPortalAdminPwd=xxx 

-DWasPassword=xxx -DPreviousPortalVersion=6.1.0.0 -DtransferDomainList=jcr

The Core Error : 

com.ibm.websphere.management.exception.ConfigServiceException: javax.management.JMRuntimeException: ADMN0022E: Access is denied for the resolve operation on ConfigService MBean because of insufficient or empty credentials.

The Full write-out in your migration log :

com.ibm.websphere.management.exception.ConfigServiceException: javax.management.JMRuntimeException: ADMN0022E: Access is denied for the resolve operation on ConfigService MBean because of insufficient or empty credentials.
        at com.ibm.websphere.management.configservice.ConfigServiceProxy.resolve(ConfigServiceProxy.java:477)
        at com.ibm.wkplc.was.registry.AdminConfigRegistry.getExistingRegistry(AdminConfigRegistry.java:104)
        at com.ibm.wkplc.models.compregistry.ResourceWidget.loadRegistryFromWAS(ResourceWidget.java:200)
        at com.ibm.wkplc.models.compregistry.GenerateNodeRegistryXML.cacheWASRegistry(GenerateNodeRegistryXML.java:243)
        at com.ibm.wkplc.models.compregistry.RegistryHelper.getWasRegistry(RegistryHelper.java:132)
        at com.ibm.wps.config.ConfigEngine.loadRegistry(ConfigEngine.java:1250)
        at com.ibm.wps.config.ConfigEngine.process(ConfigEngine.java:707)
        at com.ibm.wps.config.ConfigEngine.main(ConfigEngine.java:247)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:600)
        at com.ibm.ws.bootstrap.WSLauncher.main(WSLauncher.java:260)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:600)
        at com.ibm.wps.config.launch.ConfigEngineLauncher.process(ConfigEngineLauncher.java:269)
        at com.ibm.wps.config.launch.ConfigEngineLauncher.main(ConfigEngineLauncher.java:311)
Caused by: javax.management.JMRuntimeException: ADMN0022E: Access is denied for the resolve operation on ConfigService MBean because of insufficient or empty credentials.
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.handleAdminFault(SOAPConnectorClient.java:935)
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invokeTemplateOnce(SOAPConnectorClient.java:903)
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invokeTemplate(SOAPConnectorClient.java:669)
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invokeTemplate(SOAPConnectorClient.java:659)
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invoke(SOAPConnectorClient.java:645)
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invoke(SOAPConnectorClient.java:467)
        at $Proxy0.invoke(Unknown Source)
        at com.ibm.ws.management.AdminClientImpl.invoke(AdminClientImpl.java:224)
        at com.ibm.websphere.management.configservice.ConfigServiceProxy.resolve(ConfigServiceProxy.java:452)
        ... 18 more
com.ibm.websphere.management.exception.ConfigServiceException: javax.management.JMRuntimeException: ADMN0022E: Access is denied for the resolve operation on ConfigService MBean because of insufficient or empty credentials.
        at com.ibm.websphere.management.configservice.ConfigServiceProxy.resolve(ConfigServiceProxy.java:477)
        at com.ibm.wkplc.was.registry.AdminConfigRegistry.getExistingRegistry(AdminConfigRegistry.java:104)
        at com.ibm.wkplc.models.compregistry.ResourceWidget.loadRegistryFromWAS(ResourceWidget.java:200)
        at com.ibm.wkplc.models.compregistry.GenerateNodeRegistryXML.cacheWASRegistry(GenerateNodeRegistryXML.java:243)
        at com.ibm.wkplc.models.compregistry.RegistryHelper.getWasRegistry(RegistryHelper.java:132)
        at com.ibm.wps.config.ConfigEngine.loadRegistry(ConfigEngine.java:1250)
        at com.ibm.wps.config.ConfigEngine.process(ConfigEngine.java:707)
        at com.ibm.wps.config.ConfigEngine.main(ConfigEngine.java:247)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:600)
        at com.ibm.ws.bootstrap.WSLauncher.main(WSLauncher.java:260)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:600)
        at com.ibm.wps.config.launch.ConfigEngineLauncher.process(ConfigEngineLauncher.java:269)
        at com.ibm.wps.config.launch.ConfigEngineLauncher.main(ConfigEngineLauncher.java:311)
Caused by: javax.management.JMRuntimeException: ADMN0022E: Access is denied for the resolve operation on ConfigService MBean because of insufficient or empty credentials.
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.handleAdminFault(SOAPConnectorClient.java:935)
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invokeTemplateOnce(SOAPConnectorClient.java:903)
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invokeTemplate(SOAPConnectorClient.java:669)
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invokeTemplate(SOAPConnectorClient.java:659)
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invoke(SOAPConnectorClient.java:645)
        at com.ibm.ws.management.connector.soap.SOAPConnectorClient.invoke(SOAPConnectorClient.java:467)
        at $Proxy0.invoke(Unknown Source)
        at com.ibm.ws.management.AdminClientImpl.invoke(AdminClientImpl.java:224)
        at com.ibm.websphere.management.configservice.ConfigServiceProxy.resolve(ConfigServiceProxy.java:452)
        ... 18 more
Registry could not be loaded from WAS using current connection information.
Please verify your WAS connection properties and retry the operation.  Current input:
WasUserId: xxxxxx


The Solution:

Add the -DWasUserid=user_id  -DWasPassword=password  parameters to the task, and then rerun the task. Verify that the task ran without any exceptions.

Happy Trails!!!

Yours in WebSphere
Jerome Slinger

IBM WCM 6 to 7 Migration - Commands - Unix

Hi Y'all

Please find attached the commands I used during migration form version 6.0.1.X  to 7.0.0.1

• ./ConfigEngine.sh validate-database-connection -DTransferDomainList=jcr -DWasPassword=XXXXXX -DPortalAdminPwd=XXXXXX

• ./ConfigEngine.sh connect-database-jcr-migration

• ./ConfigEngine.sh create-wcm-persistence-tables
• This is not part of the IBM listed steps...you will thank me later :-)

• ./ConfigEngine.sh upgrade-jcr-datastore-601x-to-6100-jcr

• ./ConfigEngine.sh configure-wcm-migration

• ./ConfigEngine.sh configure-wcm-remote-admin

• ./ConfigEngine.sh action-create-schema-applyMIG7000-wp.migration.jcr.db -DPreviousPortalVersion=XXX -DCurrentPortalVersion=7.0.0.x -DWasPassword=Password -DPortalAdminPwd=Password
• Please add your Portal versions where the xx's are.

• ./ConfigEngine.sh wcm-post-migration-data-update -DPortalAdminPwd=Password-DWasPassword=Password-DPreviousPortalVersion=6.1.0.x -DtransferDomainList=jcr
• This step fails - Build Failed

The attached error can be found in your migration log.

Error: 

MigrationSQLExecutor: ERROR ->DB2 SQL error: SQLCODE: -204, SQLSTATE: 42704, 

SQLERRMC: JCR.ICMSTJCRNODELOCKSX

Migration Log :

/WebSphere/WP_PROFILE/ConfigEngine/log/Migration.log

The Fix:

You can resolve the issue by binding the JCRDB, executing the following commands from a DB2 command line window:

==db2 terminate 

==db2 connect to jcrDB (this is the newly copied database from 6.0.x to 7.0)

==db2 bind PATH\db2schema.bnd blocking all grant public sqlerror continue db2 terminate 

Substitute "PATH" with the install path for your DB2, and make sure you find the db2schema.bnd in the path before running the command.

Also, verify that all the Datasource passwords are correct before running the next task. You can verify this in the security.xml at cell scope:

\config\cells\\security.xml:

Find this entry for the JCR datasource and make sure the encrypted password is the same as the other datasources; if not, set it to the clear text password, and it will be encrypted at the next restart:

authDataEntries xmi:id="JAASAuthData_1296387511109"

alias="jcrdbDSJAASAuth" userId="db2admin" password="setPasswordHere”

description="JAAS Alias for DataSource jcrdbDS"

Happy Trails and Yours in WebSphere

Jerome Slinger

IBM WCM 7 : Migrating from WCM 6.0 to 7 - Release Not Found

Error received during migration: Release not found

Error Example String:

/WebSphere/PortalServer/base/wp.db.impl/config/templates/updatedb/6.0.1.6-7.0.0.1/db2/release

 not found.

Solution:

The issue is caused by missing files for migration from 6.1.0.6 to  7.0.0.1. This happened, because fixpack 6.1.0.6 is newer and so not  known by current 7.0.0.1. An APAR is requested.

As there are no database changes in the affected area between 6.1.0.5  and 6.1.0.6, you could duplicate the files in

/base/wp.db.impl/config/templates/updatedb/6.1.0.5-7.0.0.1

to the new directory

/base/wp.db.impl/config/templates/updatedb/6.1.0.6-7.0.0.1

as a workaround.

This is obviously not ideal but will resolve your problem.

...so how does one end up with this problem.IBM recommends that clients/customers need to be at the most recent fix pack level and as 6.0.1.7 is the most latest users are running into problems.

I hope that this has helped.

Yours in WebSphere

Jerome Slinger

Migration version 6.0 to & - Checking your Versions

Hello Everyone

I am currently busy with a migration from version 6.0 to 7.

Prior to your migration it is important to ensure that you are on the most recent Fixpacks for both your 6 and 7 environment.

Finding your current Portal Version:

On Windows : run %WPS_HOME%\bin\WPVersionInfo.bat (e.g) c:\WebSphere\PortalServer\bin\WPVersionInfo.bat

On Unix : run $WPS_HOME/bin/versionInfo.sh (e.g) /opt/WebSphere/PortalServer/bin/WPVersionInfo.sh

What your report looks like:

--------------------------------------------------------------------------------
IBM WebSphere Portal Product Installation Status Report
--------------------------------------------------------------------------------

Report at date and time 2011-10-06T10:55:59+02:00

Installation
--------------------------------------------------------------------------------
Product Directory /WebSphere/PortalServer
Version Directory /WebSphere/PortalServer/version
DTD Directory /WebSphere/PortalServer/version/dtd
Log Directory /WebSphere/PortalServer/version/log
Backup Directory /WebSphere/PortalServer/version/backup
TMP Directory /tmp

Installation Platform
--------------------------------------------------------------------------------
Name IBM WebSphere Portal
Version 6.0

Technology List
--------------------------------------------------------------------------------
MP installed
PDM installed
WCM installed
PZN installed

Installed Product
--------------------------------------------------------------------------------
Name IBM WebSphere Portal MultiPlatform
Version 6.0.1.5
ID MP
Build Level wp6015_008_02
Build Date 11/08/2008

Installed Product
--------------------------------------------------------------------------------
Name IBM WebSphere Portal Document Manager
Version 6.0.1.5
ID PDM
Build Level wp6015_008_02
Build Date 11/08/2008

Installed Product
--------------------------------------------------------------------------------
Name IBM WebSphere Portal Personalization
Version 6.0.1.5
ID PZN
Build Level wp6015_008_02
Build Date 11/08/2008

Installed Product
--------------------------------------------------------------------------------
Name IBM WebSphere WebSphere Portal Web Content Manager
Version 6.0.1.5
ID WCM
Build Level wp6015_008_02
Build Date 11/08/2008

--------------------------------------------------------------------------------
End Installation Status Report
--------------------------------------------------------------------------------

You will notice that my current fix pack level is 6.0.1.5 so it's installing more fixpacks for me :-)

Will add that process as well.

Yours in WebSphere
Jerome Slinger

Preparing to migrate - 6.0.x to 7

Before starting the migration, go through this checklist:

Apply the latest cumulative fixpack on the 7.0 server. Refer to the IBM Support document, “Recommended Updates for WebSphere Portal and Web Content Management V7.0,” for more details.

Both the 6.x and 7.x servers should be using IBM DB2®. We tested these steps using DB2, but you can try the same with other relational databases (CloudScape is not supported).

Back up the JavaTM Content Repository (JCR) database on the 6.x server, and back up all the databases on the 7.0 server. So, in case there is a problem, you can restore the 7.0 databases to their previous working state and start over.

Verify that database-related properties in the Wkplc properties files on the 7.0 server have the correct information on all current databases being used besides the JCR database (JCRDB).

Delete the subscriber and syndicator pairs from the 6.x server before attempting the migration.

Check for any duplicate entries in the JCRSTLINKS table using following query:

select WSID , SIID , TNSID , TNAME , TIX, count(*)
from .ICMSTJCRLINKS
group by WSID , SIID , TNSID , TNAME , TIX having count(*) > 1

If you get any results from the above query, find the content with the name in TNAME column and delete it from the Authoring UI before backing up the 6.x database.

Original Article

System event logging: WebSphere Portal 7

The system event logging facility of IBM® WebSphere® Portal enables the recording of information about the operation of WebSphere Portal.

Event logs provide administrators with information on important or abnormal events, especially errors that occur during the operation of the product. In addition, event logs gather debugging information that helps IBM support to resolve problems.

WebSphere Portal provides two types of logging: logging of messages and logging of debugging messages called traces.

For information about how to use log files and a list of trace logger strings refer to the topic about WebSphere Portal logs.

This topic has the following sections:

Message logging
WebSphere Portal provides the logging of messages that report errors and status information.

The following types of messages are provided:

Informational

A condition worth noting but does not require the user to perform an action.

Warning

An abnormal condition has been detected. The user may have to take action. However, WebSphere Portal code is able to handle the condition without failing.

Error

A serious failure in the execution of the application that requires further action.

Messages for WebSphere Portal are logged in the following files:

SystemOut.log

Contains information that is useful for monitor the health of the WebSphere Portal server and all running processes.

System.err

Contains exception stack trace information that is useful when performing problem analysis.

Locating the log files: Log files for WebSphere Portal, including SystemOut.log and System.err are located in the following directory: wp_profile_root/logs/WebSphere_Portal

Trace logging
WebSphere Portal provides the logging of debugging messages called traces. These traces are useful for fixing problems. However, to save system resources, they are switched off by default.

Traces can be set for different durations:

Temporary

Traces can be set for a temporary period by using the administration portlet Enable Tracing or the IBM WebSphere Application Server administrative console. To set traces by using the portlet, proceed by the following steps:
Log in as the administrator.
Click Administration -> Portal Analysis -> Enable Tracing. The Enable Tracing portlet appears.
Type the required trace string into the field Append these trace settings:. For example, this can be com.ibm.wps.command.credentialvault.*=finest
Click the Add icon. Enable Tracing updates the field Current trace settings:
Note: Restarting WebSphere Portal will remove traces that were set by using the Enable Tracing Administration portlet.

To disable tracing, do either of the following:
Select the current trace settings under Current trace settings: and click the Remove icon. By the example given above, the current setting can be com.ibm.wps.command.credentialvault.*=finest.
Type the trace string *=info into the field Append these trace settings: and click the Add icon. This trace string overwrites all settings listed under Current trace settings: and resets it to the default.

Extended

To enable trace settings for a longer period of time, that is, for more than one session, switch them on in the WebSphere Application Server configuration. Proceed by the following steps:
Access the WebSphere Application Server Administrative Console by using this URL: http://hostname:port_number/ibm/console
Click Servers -> Server Types -> WebSphere application servers.
Select the application server.
Click Troubleshooting -> Change Log Detail Levels.
Specify the required trace settings. For example, this can be com.ibm.wps.command.credentialvault.*=finest
Save your updates.
Restart WebSphere Portal.
To disable tracing, specify tracestring: *=info and restart WebSphere Portal.

Changing the log file name and location
You can change the locations of the log files by configuring them in the WebSphere Application Server administrative console. Select Troubleshooting -> Logs and Trace -> server_name and select the logger type that you want to change. In the configuration dialog change the path for the log file as required. For a description of the available types of log files refer to the WebSphere Application Server information center.

Changing the language used in the log file
By default, information in the log file is written in the language that was used for the WebSphere Portal installation. However, because WebSphere Portal supports a number of languages, you can choose to have the log file information written in a language other than that used during installation.

To change the language used for the log file, edit the file log.properties. This file is located in the following WebSphere Portal directory:

UNIX: wp_profile_root/PortalServer/config/config
i: wp_profile_root/PortalServer/config/config
Windows: wp_profile_root\\PortalServer\\config\\config

Add the following line:

locale=xx

where xxis the two-letter abbreviation for the locale. For a list of the locale abbreviations used with WebSphere Portal, refer to Directories for languages. For example, to have log information generated in English, you would add the following line:

locale=en

Reference: Log file format
If the logs are written to the log file of WebSphere Portal and not redirected to the logging facility WebSphere Application Server, the log file consists of a sequence log records that are separated by blank lines.

The log records have the following format:

timestamp classification classname method threadID

messagecode: logmessage



Where:

timestamp is the time (to the millisecond) when the log record was created.
classification is one of the following letters:
E for error messages
W for warning messages
I for informational messages
l for traces (low details)
m for traces (medium details)
h for traces (high details)
classname is the Java class containing the code that triggered the log event.
method is the name of the Java method containing the code that triggered the log event.
messagecode is a unique identifier for this message, to uniquely identify the specific message and refer to it when consulting documentation or support. The message code is only available for error, warning, or informational messages, and not for traces. It consists of:
a four-character identifier for the component that defines the message.
a four-digit number identifying the message in the component.
a one-letter classification code, which can be E, W or I , as defined above.
logmessage is the actual log message describing the logged event. Error, warning, and informational messages are translated into the system locale. Trace messages are not translated.
threadID is the identification of the thread that triggered the log event.

Note:

Traces are written only if the specific tracing facility is enabled; all other messages are written unconditionally.
The system locale is part of the general internationalization features of WebSphere Portal and can be configured via LocalizerService. For more information refer to the topics about Setting service configuration properties and about the Portal configuration services.

The following is an example of a log record:

2003.05.16 13:36:14.449 W com.ibm.wps.services.datastore.DataStoreServiceImpl init 0000003a

DSTO0063W: The transaction isolation level is not set to READ_COMMITTED.
The current value is TRANSACTION_REPEATABLE_READ.

Source: http://www-10.lotus.com/ldd/portalwiki.nsf/dx/System_event_logging_wp7

Portal Add a New Language

If the date does not display correctly in Portal the locale might not be fully supported by Portal. To rectify this add the Language en_ZA. You access the XML configuration interface using a command line tool. This command line client is a small separate program that connects to the server using an HTTP connection or a secure HTTPS connection with SSL. It is therefore possible to configure the portal remotely.

Full syntax: /WebSphere/PortalServer/bin/xmlaccess.sh -url localhost:10038/wps/config -in CreatLanguage.xml -out /tmp/result.xml

Should run with: ./xmlaccess.sh -in /tmp/CreateLanguage.xml
respond to user/passwd prompts
must have admin rights to import the new lang.

Here is the CreateLanguage.xml file to add the lang/locale en_ZA:

Configuring and Integrating the Standalone Tivoli Directory Server with Websphere Portal : wp7

Step 1: Configuring the Tivoli Directory Server

a). Adding Suffixes
Go to Tivoli Web Admin Console --> ServerAdministration --> Manage Server Properties--> Suffixes --> Enter the Base DN name for the suffix (Like dc=yourcompany,dc=com)--> click add
Stop and Start the LDAP server from LDAP admin console
b). Importing the portaluser.ldif
copy the portalusers.ldif file , and change the dc=yourcompany,dc=com with your sepecific details.
stop the ldap server , go to LDAP admin console-->manage-->LDIF Tasks-->import LDIF data-->browse for the portalusers.ldif

LDAP suffix="dc=yourco,dc=com"
user prefix="uid"
user suffix="cn=users"
group prefix="cn"
group suffix="cn=groups"
Portal administrator DN ="uid=wpsadmin,cn=users, dc=yourco,dc=com"
Portal administrator group ="cn=wpsadmins,cn=groups, dc=yourco,dc=com"


Step 2: Integrating the Tivoli Directory Server with Portal (replacing the default filebasedrepository to TDS)

a). Update C:\IBM\WebSphere\wp_profile\ConfigEngine\config\helpers\wp_security_ids.properties file with corresponding values like below (Instead of modifying the wkplc.properties file, you can update this properties file)

standalone.ldap.id=localtds
standalone.ldap.host=sivavaka.com
standalone.ldap.port=389
standalone.ldap.bindDN=cn=root
standalone.ldap.bindPassword=ldappwd
standalone.ldap.ldapServerType=IDS
standalone.ldap.userIdMap=*:uid
standalone.ldap.groupIdMap=*:cn
standalone.ldap.groupMemberIdMap=
standalone.ldap.userFilter=(&(uid=%v)(objectclass=inetOrgPerson))
standalone.ldap.groupFilter=(&(cn=%v)(objectclass=groupOfUniqueNames))
standalone.ldap.serverId=uid=root,cn=users,dc=sivavaka,dc=com
standalone.ldap.serverPassword=Passw0rd

standalone.ldap.realm=sivavaka_portal
standalone.ldap.primaryAdminId=uid=wpsadmin,cn=users,dc=sivavaka,dc=com
standalone.ldap.primaryAdminPassword=wpsadminpwd
standalone.ldap.primaryPortalAdminId=uid=wpsadmin,cn=users,dc=sivavaka,dc=com
standalone.ldap.primaryPortalAdminPassword=wpsadminpwd
standalone.ldap.primaryPortalAdminGroup=cn=wpsadmins,cn=groups,dc=sivavaka,dc=com
standalone.ldap.baseDN=dc=sivavaka,dc=com

standalone.ldap.et.group.searchFilter=
standalone.ldap.et.group.objectClasses=groupOfUniqueNames
standalone.ldap.et.group.objectClassesForCreate=
standalone.ldap.et.group.searchBases=
standalone.ldap.et.personaccount.searchFilter=
standalone.ldap.et.personaccount.objectClasses=inetOrgPerson
standalone.ldap.et.personaccount.objectClassesForCreate=
standalone.ldap.et.personaccount.searchBases=

standalone.ldap.gm.groupMemberName=uniqueMember
standalone.ldap.gm.objectClass=groupOfUniqueNames
standalone.ldap.gm.scope=direct
standalone.ldap.gm.dummyMember=uid=dummy


standalone.ldap.personAccountParent=cn=users,dc=sivavaka,dc=com
standalone.ldap.groupParent=cn=groups,dc=sivavaka,dc=com
standalone.ldap.personAccountRdnProperties=uid
standalone.ldap.groupRdnProperties=cn

standalone.ldap.gc.name=
standalone.ldap.gc.updateGroupMembership=
standalone.ldap.gc.scope=direct
standalone.ldap.derefAliases=always
standalone.ldap.authentication=simple

standalone.ldap.referral=ignore
standalone.ldap.delimiter=/
standalone.ldap.ignoreCase=true

standalone.ldap.sslEnabled=false
standalone.ldap.sslConfiguration=
standalone.ldap.certificateMapMode=EXACT_DN
standalone.ldap.certificateFilter=
standalone.ldap.reuseConnection=true
standalone.ldap.searchTimeLimit=120000
standalone.ldap.connectionPool=false
standalone.ldap.supportSorting=false
standalone.ldap.supportPaging=false
standalone.ldap.supportTransactions=false
standalone.ldap.isExtIdUnique=true
standalone.ldap.supportExternalName=false
standalone.ldap.translateRDN=false
standalone.ldap.searchCountLimit=500
standalone.ldap.searchPageSize=
standalone.ldap.returnToPrimaryServer=
standalone.ldap.primaryServerQueryTimeInterval=
standalone.ldap.loginProperties=uid
standalone.ldap.cp.maxPoolSize=20

b). Execute the following commands to validate and update

#Validates the updated properties
ConfigEngine.bat validate-standalone-ldap -DWasPassword=wpsadmin -DparentProperties=C:\IBM\WebSphere\wp_profile\ConfigEngine\config\helpers\wp_security_ids.properties

#Below command will change the portal filebased repository toTDS
ConfigEngine.bat wp-modify-ldap-security -DWasPassword=wpsadmin -DparentProperties=C:\IBM\WebSphere\wp_profile\ConfigEngine\config\helpers\wp_security_ids.properties

Note: If any problems while executing the above commands,
a) make sure above properties proper (like LDAP admin ID(bindDN), PWD).
b) check the C:\IBM\WebSphere\wp_profile\ConfigEngine\properties\wkplc.properties and file and make sure Stand alone LDAP properties are valid and same as entered above

Once the above commands executed successfully, restart the portal and application server if its already started.

Resolving the "myportal" and "portal" issues

Following are the steps to handle the "myportal" and "portal" in WCM generated links using tags like above

1. Go to \wp_profile\PortalServer\config
2. Open ConfigService.properties using text editing tool.
3. Uncomment this property :uri.home.substitution and set it to true (initially it is commented.)
uri.home.substitution = true
4. Open CMD goto \wp_profile\ConfigEngine
5. Type ConfigEngine.bat update-properties
6. Restart your portal server for your changes to effect.

This property automatically handles this portal myportal issue. i.e if user is logged it will be myportal, if logged out then portal.

Check out this link for more information on this:
http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1m0/index.jsp?topic=/com.ibm.wp.ent.doc_v6101/admin/srvcfgref.html

Yours in WebSphere

Jerome Slinger