WebSphere Application Server 8.5.5: Changing the console session expiration

The idle period, before the administrative console session expires, is referred to as session timeout. The default session timeout value for the administrative console is 15 minutes. The timeout value can be modified by using a JACL script that is available at the information center. [From: WebSphere Application Server V8.5 Administration and Configuration Guide for the Full Profile]

Run this JACL script to set how long Integrated Solutions Console can be used until the login session expires.

About this task

The following JACL script serves as an example of how to set the duration that an Integrated Solutions Console can be used until the login session expires. Other scripting types, such as JYTHON, could be used.


  1. Copy the following script into a file.
    set dep [$AdminConfig getid /Deployment:isclite/]
    set appDep [$AdminConfig list ApplicationDeployment $dep]
    set sesMgmt [$AdminConfig list SessionManager $appDep] 
    # check if existing sesMgmt there or not, if not then create a new one, if exist then modify it
    if {$sesMgmt == ""} {
         # get applicationConfig to create new SessionManager
         set appConfig [$AdminConfig list ApplicationConfig $appDep]
         if {$appConfig == ""} {
             # create a new one
             set appConfig [$AdminConfig create ApplicationConfig $appDep {}]
             # then create a new SessionManager using new Application Config just created
             set sesMgmt [$AdminConfig create SessionManager $appConfig {}]   
         } else {
              #  create new SessionManager using the existing ApplicationConfig
              set sesMgmt [$AdminConfig create SessionManager $appConfig {}] 
    # get tuningParams config id
    set tuningParams [$AdminConfig showAttribute $sesMgmt tuningParams]
    if {$tuningParams == ""} {
        # create a new tuningParams 
        $AdminConfig  create TuningParams  $sesMgmt {{invalidationTimeout <timeout value>}}  
    } else {
         #modify the existing one
         $AdminConfig modify $tuningParams {{invalidationTimeout <timeout value>}}  
    # saving the configuration changes
    $AdminConfig save
  2. Change the <timeout value> on the two lines of this sample to the new session expiration value. This number specifies the number of minutes the console preserves the session during inactivity.
  3. Save the file to any directory using, for example, the filename timeout.jacl.
  4. Start the wsadmin scripting client from the <WAS-install>/profiles/<profile_name>/bin directory.
  5. Issue the following command.
    wsadmin -f <path to jacl file>/timeout.jacl

Source: http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=%2Fcom.ibm.websphere.nd.doc%2Fisc%2Fcons_sessionto.html

IBM Content Navigator 2.0.2 Ping page


To access the Ping page to find version information for IBM Content Navigator:

Enter the URL from any browser with the following format:


By default, the context root is navigator.

Tip: If you are using SSL, the protocol of the URL is HTTPS:




Source: http://www-01.ibm.com/support/knowledgecenter/SSNW2F_5.1.0/com.ibm.installingeuc.doc/eucts019.htm?lang=en

A user authenticated as anonymous has attempted to access a session owned by

Please see this link for the entire details of the cause and solution.

Resolving the problem

Disable the IBM Websphere Application Server 8.x Security Integration feature for WorkplaceXT:

  1. In the IBM Websphere Administrative Console navigate to Applications->Websphere Enterprise Applications -> WorkplaceXT -> Session Management
  2. Check the Override session Management checkbox
  3. Uncheck the Security integration option
  4. Save the changes
  5. Restart the WorkplaceXT application

“The afpa service failed to start due to the following error: The system cannot find the file specified. “

Source: http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14729308

Occurs when you installed IHS 7.0 on Windows Server 2003 then restarted Windows.


AFPA/FRCA is deprecated in IHS 7.0
AFPA (Advanced Fast Path Architecture) has been deprecated starting with IBM HTTP Server 7.0. Though it has not been fully removed from the the product yet, its use is discouraged, and it may be fully removed in a future release.
Refer to the ‘Deprecated features’ page in the 7.0 InfoCenter for more details.

As a result of the deprecation, there are a few changes:

The IHS installation no longer copies the afpa.sys driver to the C:\Windows\system32\drivers directory
The default httpd.conf no longer contains any Afpa directives.
In prior releases, the configuration file had commented-out Afpa statements that could simply be uncommented to enable the Afpa support.
et voici la réponse faite par le lab à un client qui rencontrait un problème analogue au vôtre:

The resolution is documented here and it clearly states..”..resolved by
doing either of the following”

The error can be easily resolved by doing either of the following:
Run ‘AfpaCmd -u’ to remove the registry entry that attempts to load the
Afpa driver.
AfpaCmd.exe can be found in the \bin directory beneath the IHS
installation directory.
(This is the recommended solution)
Copy the afpa.sys driver from the IHS installation directory to the
C:\Windows\system32\drivers directory so that it can be loaded.

Therefore, the intended solution is do either one or the other, not
1. unregister it in the registry so IHS does not look for the driver
during startup


2. copy the afpa.sys to the directory so IHS can find it during startup.

FYI.. Since we no longer recommend using AFPA and it has been deprecated
in 7.0.

Inaccessible WebSphere Application Server 7.0

You may have experienced that you cannot access your WAS installation anymore for whatever reason. If you are sure that you haven’t changed the credentials or something like that, there’s still a way to fix it.

I tried to inspect the services.msc on Windows. You can see there the WebSphere Application Server service. If its startup type is Automatic, change it to Manual. Then restart the machine. Start the deployment manager or server (depends on your environment) manually. Based on my experience, this should be okay now. If WAS is inaccessible again, change the startup type to Automatic and then restart the machine.

If you still cannot login, there must be some problem with your WAS configuration.

If anyone know the exact solution, please comment! 😀