SBL-SEC-00102: Error loading the security adapter library

Applies to:

Siebel System Software - Version 8.0.0.1 [20408] to 8.2.2.2 SIA[23016] [Release V8]
Information in this document applies to any platform.

Product Release: V8 (Enterprise)

Version: 8.0 [20405]

Database: Oracle 10.1.0.4

Application Server OS: Red Hat Linux 4.0

Database Server OS: Sun Solaris 9



This document was previously published as Siebel SR 38-3467659813.

Symptoms

Hi, we're trying to setup a PoC of Siebel 8.0 on Linux Redhat 4.0 and
had encountered issue while trying to config LDAP authentication and an
error had ocurred in the OM log file. IBM LDAP 6.0 Client is installed
and is using OID 10.1.2 as the LDAP Server.

We have repreatedly verified LDAPparameters many times and believed we have setup the right parmeters.

We got the following error in the log file:

SBL-SEC-00102 An error occurred loading the security adapter library. Please contact your system administrator for assistance.

SBL-DAT-00562 An error occurred loading the security adapter library. Please contact your system administrator for assistance


Btw, logfile and siebns are attached for your reference..

Cause

Change Request 12-1LDF7SJ

Solution

Message 1

Please assign this SR as soon as possible. This is becoming critical for the customer .

Many Thanks

Message 2

For the benefit of other readers

The customer was implementing LDAP authentication with Siebel 8.0 on Red Hat Linux 4.0 with Oracle Internet Directory.


After configuring the LDAP Adapter and restarting the Siebel Server the
Object Manager startup would fail with the following errors:


GenericLog GenericError 1 0000000646fb2542:0 2007-09-27 20:38:39
(secmgr.cpp (2407) err=4587622 sys=0) SBL-SEC-00102: An error occurred
loading the security adapter library. Please contact your system
administrator for assistance.
ObjMgrSessionLog Error 1
0000000646fb2542:0 2007-09-27 20:38:39 (physmod.cpp (9244))
SBL-DAT-00562: An error occurred loading the security adapter library.
Please contact your system administrator for assistance.

ObjMgrSessionLog Error 1 0000000646fb2542:0 2007-09-27 20:38:39
(model.cpp (5867)) SBL-DAT-00562: An error occurred loading the security
adapter library. Please contact your system administrator for
assistance.
ObjMgrCTLog Error 1 0000000646fb2542:0 2007-09-27 20:38:39 (ctxtmgr.cpp (4492)) SBL-SVC-00208: Please login first.


The customer confirmed that the IBM LDAP Client 6.0 was already
installed. After further investigation it was found that the LDAP Client
libraries needed to be added to the LD_LIBRARY_PATH set in
/siebsrvr/siebenv.sh. siebenv.sh was modified as follows:

[....]

Message 3

[....]

if [ a${LD_LIBRARY_PATH} = ${LD_LIBRARY_PATH}a ] then

LD_LIBRARY_PATH=${SIEBEL_ROOT}/lib:${SIEBEL_ROOT}/lib/odbc/merant:/opt/ibm/ldap/V6.0/lib:${MWHOME}/lib:${SQLANY}/lib:/usr/lib

else
LD_LIBRARY_PATH=${SIEBEL_ROOT}/lib:${SIEBEL_ROOT}/lib/odbc/merant:/opt/ibm/ldap/V6.0/lib:${MWHOME}/lib:${SQLANY}/lib:/usr/lib:${LD_LIBRARY_PATH}
Fi

After making this change LDAP Authentication worked correctly. Change Request 12-1LDF7SJ was logged for a documentation defect.

Applies to:

Siebel CRM - Version 7.5.3.4 [16180] and later
Information in this document applies to any platform.

*** Checked for relevance on 29-JAN-2013 ***

Symptoms

Customer is trying to implement the LDAP security adapter
(LDAPSecAdpt) for use with the Siebel application.  The application
object manager is failing to bring up a login screen and the following
error is appearing in the log file:

SBL-SEC-00102: Error loading the security adapter library. Please contact your system administrator.

The desired behavior is that the security adapter library should load successfully and a login page be presented to the user.

Cause

This behavior occurred because the server had to be physically
rebooted after the installation of the IBM LDAP Client and/or GSKit
software.

Solution

After some investigation, we determined that it is necessary to
physically reboot the server after the installation of the IBM LDAP
Client or GSKit software. Once this was done, everything worked
correctly.

This requirement is not documented in the Siebel Bookshelf documentation.


Document Enhancement Request Bug:10575898/ 12-1UX6R4P to update the Security Guide with this information.

Applies to:

Siebel Financial Services CRM - Version 8.0.0.1 [20408] to 8.1.1.2[21215] [Release V8]
Information in this document applies to any platform.

***Checked for relevance on 03-Jan-2011***

***Checked for relevance on 23-Nov-2012***

Symptoms

We are trying to implement a Custom Security Adapter to perform
application login authentication. We have downloaded the sample SDK from
support web, compiled and deployed to our testing environment. We have
also configured one of the AOM to test out the compiled security
adapter. Unfortunately, we are unable to load the application login
page. Based on the attached log file, the error message is as below:

"SBL-SEC-00102:
An error occurred loading the security adapter library. Please contact
your system administrator for assistance."

Cause

Incorrect setup/configuration on the custom security adapter named
subsystem and configuration file or security adapter library compilation
issue.

Solution

Verify the following is correct.


- Parameter setting in custom security adapter named subsystem


- Setting in the configuration file reference in ConfigFileName parameter in custom security adapter named subsystem


- LIBPATH environment variable setting

Setup the sdk custom
adapter authentication and configuration in-house and successfully
reproduce the issue when using the same compiler (g++) and makefile as
customer.


Further research on these and found the issue on the sdk compilation. The makefile from customer is like this.

libsampsdk.so: secsamp.o secutil.o
g++ secutil.o secsamp.o -o libsampsdk.so

secsamp.o: secsamp.cpp secutil.h ssecurity.h
g++ -c secsamp.cpp

secutil.o: secutil.cpp secutil.h ssecurity.h
g++ -c secutil.cpp

Note
that after compiling the secsamp.cpp and secutil.cpp with g++ -c swtich
and option, it will create the .o file. Once this dependencies
(secsamp.o and secutil.o) for the shared object secsamp.so have been
created, there is need to invoke the linker using additional switch and
option to create a dynamic library. So modify the makefile as below and
recompile the sample code.

libsampsdk.so: secsamp.o secutil.o
g++ -fPIC -shared secutil.o secsamp.o -o libsampsdk.so

secsamp.o: secsamp.cpp secutil.h ssecurity.h
g++ -c secsamp.cpp

secutil.o: secutil.cpp secutil.h ssecurity.h
g++ -c secutil.cpp

Using this newly compiled library file, object manager and application succesfully loaded and login works fine.

pplies to:

Siebel Communications Service - Version 8.0.0.2 [20412] to 8.1.1.8 SIA [23012] [Release V8]
Information in this document applies to any platform.

Symptoms

Siebel version 8.0 application does not start when the LDAP security
adaptor is configured at enterprise level, although the mandatory IBM
LDAP client version 6.0 has been installed. The following error messages
are logged as a result,


a) SBL-SEC-00102: An error occurred loading the security adapter
library. Please contact your system administrator for assistance.
b)
SBL-DAT-00562: An error occurred loading the security adapter library.
Please contact your system administrator for assistance.

Cause

The Siebel security adaptor library aka. libsscfldap.so could not be
loaded because of the installation and configuration (LD_LIBRARY_PATH)
of the 64bit libraries that are part of the IBM LDAP client software.

Solution

Ensure that the LD_LIBRARY_PATH in the siebenv.sh shell script only
references the 32-bit libraries of the IBM LDAP Client version 6.0
because this ensures that the Siebel modules, which are based on 32-bit
processing - do not conflict with the 64-bit library versions of the IBM
LDAP Client software - as documented in Siebel
Bookshelf version 8.0 > Siebel Security Guide > Security Adapter
Authentication > Installing LDAP Client Software > Configuring the
siebenv.csh and siebenv.sh Scripts for the LDAP Client - where it
states, "Siebel supports only the IBM 32-bit LDAP Client so you can use
only the 32-bit LDAP Client libraries with your Siebel applications."

Please follow the following steps, also outlined in the Siebel Bookshelf reference,
1) Navigate to the Siebel server root installation directory
2) Open a text editor on your UNIX system e.g. vi
3)
For both the shell script files; SIEBENV.SH and SIEBENV.CSH edit them
and ensure that ONLY the location to the IBM LDAP Client 32bit libraries
are referenced.

NOTE: The 64-bit libraries can be explicitly identified from the directory path naming convention - that is,
32-bit  =  /opt/IBM/ldap/V6.0/lib
64-bit  =  /optIBM/ldap/V6.0/lib64

Applies to:

Siebel CRM - Version 8.0.0.1 SIA [20408] and later
Information in this document applies to any platform.

Symptoms

Siebel Login Page fails to display



ERRORS


1) The server you are trying to access is either busy or experiencing
difficulties. Please close the Web browser, open a new browser window,
and try logging in again.[08:22:46]

2) SBL-SEC-00102: An error occurred loading the security adapter
library. Please contact your system administrator for assistance.

Cause

The IBM LDAP Client installation on UNIX defaults to /opt/ibm/ldap/V6.0.


The environment variables in the SIEBENV.SH referenced the wrong directory for the IBM LDAP libraries - namely /opt/ibm/ldap/v6.0/lib as opposed to /opt/ibm/ldap/V6.0/lib.


Because the resolution of filename paths on UNIX systems is case
sensitive the difference between v6.0 and V6.0 caused the error.


Bug 14651929
has been logged requesting that the Security Guide be updated
accordingly under Security Adapter Authentication > Process of
Installing and Configuring LDAP Client Software > Configuring the
siebenv.csh and siebenv.sh Scripts for the LDAP Client.

Solution

Modify the SIEBENV.SH to reference /V6.0/lib as opposed to /v6.0/lib

Applies to:

Siebel CRM Call Center - Version: 8.1.1.5 [21229] and later   [Release: V8 and later ]
Information in this document applies to any platform.

Symptoms

=== ODM Issue Clarification ===

This is in relation to a 8.1.1.5 siebel enterprise environment deployed on a RHEL 5.5 linux platform (64-bit).





When accessing the EAIObjMgr_enu component fails when using an external
Java based command line utility, which is accessing the EAI component
via EAI_enu SWSE web server.



Looking at the EAIObjMgr component we can see mainly authentication errors like the following error messages:

"An error occurred loading the security adapter library. Please contact
your system administrator for assistance.(SBL-DAT-00562)" and before
this error ".....err=4587622....SBL-SEC-00102..."

Cause

=== ODM Cause Determination ===



Executed: strace against start_server and EAI OM PID. There was no evidence that <custom adapter>.so lib was loaded.



Executed: file <custom adapter>.so

This showed: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped



Executed: ldd -v <custom adpater>.so

This showed:

>>>

      libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002b536dd51000)

      libm.so.6 => /lib64/libm.so.6 (0x00002b536e051000)

      libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002b536e2d4000)

      libc.so.6 => /lib64/libc.so.6 (0x00002b536e4e3000)

      /lib64/ld-linux-x86-64.so.2 (0x0000003d04c00000)



      Version information:

      ./cdetsnopassword.so:

              libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6

...

<<<

=== ODM Cause Justification ===



Looking at the file and ldd output, we can see that 64-bit libraries are used:



Siebel product is only 32-bit and will only work with 32-bit libraries.

Solution

=== ODM Solution / Action Plan ===



Compile the custom security adapter as per SDK documented compile commands.

Also ensure that modifications are implemented as per published article:
1062497.1 - Changes to Siebel Custom Security Adapter SDK in Siebel
8.1.1

Also, if on a 64-bit operation system,  ensure to modify the compiler
instructions to compile in 32-bit mode. There could be different ways
this can be done pending on the OS vendor. For any clarification please
consult with the OS vendor support.



In this specific case the following compiler instructions helped to resolve the issue.

g++ -m32 -c -fPIC secsamp.cpp

g++ -m32 -c -fPIC secutil.cpp

g++ -m32 -fPIC -shared secutil.o secsamp.o -o <custom security adapter>.so

Please note, Oracle  is providing the SDK and compiler instructions solely as a convenience to our customers and

Oracle  makes no warranties or representations of any kind regarding the

results customers may achieve by using the SDK. Siebel is not responsible

for any failure of any security adapter written using the SDK.



Check with file and ldd command (library dependency check on Linux) to ensure no 64-bit library is being used.

For example in this case the output after compiling in 32-bit mode confirmed that there was no 64-bit library involved.

$ ldd <custom security adapter>.so

linux-gate.so.1 =>  (0xffffe000)

libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xf7e82000)

libm.so.6 => /lib/libm.so.6 (0xf7e5b000)

libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf7e4f000)

libc.so.6 => /lib/libc.so.6 (0xf7d09000)

/lib/ld-linux.so.2 (0x00473000)



Stop the siebel application server service.

Replaced this on the siebsrvr/lib

Start the siebel application server service



Test the siebel application authentication process.

SBL-SMI-00152: TIMEOUT Component Initialization for Priority Level %1 Timed Out After %2

Applies to:

Siebel System Software - Version: 8.0.0.1 [20408] and later   [Release: V8 and later ]
Information in this document applies to any platform.

Error Message Area:Server Management Infrastructure - SMI

Version:Siebel 8.0

Purpose

This document is intended to provide cause and corrective action
information about Siebel Error Message SBL-SMI-00152: TIMEOUT Component
initialization for priority level %1 timed out after %2 s.

SBL-SMI-00152: TIMEOUT Component Initialization for Priority Level %1 Timed Out After %2 s.

Explanation

Startup of components for this priority level timed out.

Corrective Action

Check the enterprise server log to see which component timed-out during initialization.
An example of a trace from the ent81.ss81[1].log log file may be similar to the following:

ent81.ss81[1].log:GenericLog
GenericError 1 0000132b4b4c68fa:0 2010-01-12 11:37:55 (schedule.cpp
(2162) err=1376408 sys=0) SBL-SMI-00152: TIMEOUT Component
initialization for priority level 1 timed out after 300 s.

ent81.ss81[1].log:ServerLog
ProcessExit 1 0000132c4b4c68fa:0 2010-01-12 11:43:00 SvrTblCleanup
26931 SBL-OMS-00101 Process 26931 exited with error - Error %1 loading
product configuration information

In this case, a
cursory review of the log files in the Siebel log directory indicated
the the SCBroker log was updated at about the same time as the
enterprise log file.  Reviewing the contents of the latest SCBroker log
file, SCBroker_0002_2097155[1].log, revealed the following trace:

SCBroker ScbInfo 3 000000044b4c6929:0 2010-01-12 11:36:24 Processing url: http://appserver:2381/ent81/sccobjmgr_enu

SCBroker_0002_2097155[1].log:GenericLog
GenericError 1 000000044b4c6929:0 2010-01-12 11:36:24 (scbcomp.cpp
(445) err=4653071 sys=0) SBL-SCB-00015: The component is down or not
available on this server

From the above trace, it
appears the SCBroker cannot establish a session with the call center
object manager via this URL: http://appserver:2381/ent81/sccobjmgr_enu

To troubleshoot this issue, try the following:

Option
1. Confirm that the Object Manager and SRBroker are up and available on
the application server. Restart these components, if necessary, and see
if this resolves the issue.  It is also a good idea to try to ping the
application server with the full URL and confirm it is available.  If
these steps do not resolve the issue, continue to Option 2, below:

Option 2. Setup Environment To Capture Detailed Traces at SWSE, APP and OS Level:

1. Turn up event logging for SWSE from the command shell:
Enter the following commands and set the following environment variables:

SIEBEL_LOG_EVENTS=4; export SIEBEL_LOG_EVENTS
SIEBEL_SESSMGR_TRACE=1; export SIEBEL_SESSMGR_TRACE
SIEBEL_SISNAPI_TRACE=1; export SIEBEL_SISNAPI_TRACE


B. Turn up event logging on the OM and the following components to level 4:


1. Open a command shell and start the “srvrmgr” CLI utility (should
be under the $SIEBEL_ROOT/siebsrvr/bin) and then enter the following
commands (substitute your parameters between <> marks):

(On UNIX): srvrmgr -g <gateway_name> -e <enterprise_name> -u <sadmin> -p <password>
(On Windows): srvrmgr /g <gateway_name> /e <enterprise_name> /u <sadmin> /p <password>

spool srvrmgr_trace.txt
list servers
list components
change evtloglvl % = 4 for comp SCCObjMgr_enu
change evtloglvl % = 4 for comp SRBroker
change evtloglvl % = 4 for comp SCBroker
change evtloglvl % = 4 for comp SCProc
change evtloglvl % = 4 for comp CommSessionMgr
change evtloglvl % = 4 for comp SvrTblCleanup
spool off
quit

C. Note date and time. Stop and restart the web server and siebsrvr. Wait 5 minutes.

D. Reproduce the issue end-to-end, indicate date and time per step, attach log files:


1. Note date and time. Open a browser window, and try to access the
application (call center) in the usual manner, and reproduce the issue,
and be sure to capture a complete screen shot

2. Note date and time. Open a command shell on the server running the OM and execute:
netstat -an > netstat_siebsrvr_<name>.out

3. Note date and time. Stop the web server and siebsrvr.
Compress and attach to this SR for review:
* screen shot
* srvrmgr_trace.txt
* netstat*.out files
* all the log files generated during this trace session from the web server and application server log directories
(please aggregate the files by server name, or type (eg. websrvr_<name>, siebsrvr_<name>)

4. Repeat steps A and B, but return to normal logging levels.

E. Note date and time. Restart the web server and siebsrvr.

F.
Indicate which enterprise components are running on which OS (eg. Web
server on UNIX, etc.).  Zip-up and attach the log files to the SR for
review.

SBL-SMI-00151: System component initialization timed out. System will shut down.

Applies to:

Siebel System Software - Version 8.0 [20405] to 8.2.2.2 SIA[23016] [Release V8]
Information in this document applies to any platform.

Error Message Area:Server Management Infrastructure - SMI

Version:Siebel 8.0

***Checked for relevance on 20-Feb-2013***

Purpose

This document is intended to provide cause and corrective action
information about Siebel Error Message SBL-SMI-00151: System component
initialization timed out. System will shut down.

Scope

This document is informational and intended for any user.

Details

Explanation

Startup of system components timed out.

Corrective Action

Check the server log file for any errors related to system
components. If there are no errors or a system component is expected to
take a long time to start, increase the Component Priority Level Timeout
parameter.

Applies to:

Siebel eCommunications - Version: 8.0.0.3 [20416] and later   [Release: V8 and later ]
Information in this document applies to any platform.

Symptoms

==== ODM Issue Clarification ====



On : 8.0.0.10 [20436] version, System Admin



When attempting to start siebel apps server after patching to 8.0.0.10,

the following error occurs.



ERROR

-----------------------

GenericLog GenericError 1 000092164eeab1a0:0 2011-12-15 20:36:11
(sccnmsys.cpp (1305) err=2883609 sys=0) SBL-SCC-00025: No value found in
the Gateway. Default value in the repository is used.

ror 1 0000369c4eea7146:0 2011-12-15 20:54:48 (schedule.cpp (944)
err=1376408 sys=0) SBL-SMI-00152: TIMEOUT Component initialization
for priority level 2 timed out after 300 s.

GenericLog GenericFatal 0 0000369c4eea7146:0 2011-12-15 20:54:48
(schedule.cpp (955) err=1376407 sys=0) SBL-SMI-00151: System component
initialization timed out. System will shut down.



STEPS

-----------------------

The issue can be reproduced at will with the following steps:

1. Patch from 8.0.0.3 to 8.0.0.10FP

2. Start enterprise

3. Not starting the enterprise

Cause

After further investigation, it was found that home directory for
the siebel user was pointing to a wrong directory path other than the
directory having the siebel server installed

Solution

Resolution steps :



1. Home directory for the siebel user must point to same directory where siebel installed

2. Once point to correct directory restart the enterprise

SBL-SMI-00147: Version check failed.

Applies to:

Siebel eCommunications - Version: 8.1.1.3
SIA[21219] and later   [Release: V8 and later ]

Information in
this document applies to any platform.

Symptoms

Unable to start the Siebel Server
as



SRBroker and SCBroker logs are showing the following
error:

-----------------------------------------------------------------

Error:
cannot get version of installed components ( sia)

SBL-SMI-00147: Version
check failed because: Error: cannot get version of installed components (
sia)

Cause

The customer found the following root
problem himself:



Inside the <Siebel Server
Root>'s BIN folder, the sub-folders SIA and PTK had (accidentally) been moved
to the PTB sub-folder.

PTK was not necessary, because they only used ENU
and PTG, but SIA was.

Solution

restoring the SIA subfolder with its
original content in <Siebel Server Root> fixed the
error



SBL-SMI-00147: Version check failed because: Error: cannot get
version of installed components ( sia)

Applies to:

Siebel System Software - Version 7.5.3.1 SIA
[16161] and later

z*OBSOLETE: Microsoft Windows 2000

Product Release: V7
(Enterprise)

Version: 7.5.3.1 [16161] Fin Svcs

Database: All Databases (
Oracle DB/MS SQL / DB2 )

Application Server OS: Applicable to all Platforms (
Unix and Windows )

Database Server OS: Applicable to all Platforms ( Unix and
Windows )



This document was previously published as Siebel SR
38-1746031351.



***Checked for relevance on 02-NOV-2012***

Symptoms

SBL-SCC-00025, SBL-SVR-00106, SBL-SMI-00147

We have two app servers load balanced with Resonate. Today around noon our
application server 1 (app1) went down with a handshake error. We recycled the
siebel services tonight but now the app1 server is not coming up. All server
components in this server are exiting with the following error:

Error: can't
get version of installed components (ENU sia)

errors at the enterprise log
are:

GenericLog    GenericError    1    2005-01-31 23:59:32    (schedule.cpp
17(793) err=2100096 sys=0) SBL-SMI-00096: The maximum number of restarts (10)
for MinUpTime has been reached. The component CommSessionMgr will not be
restarted again.



We searched in SupportWeb and even restored a backup of
our siebns.dat file with no avail.

I have attached all log files before and
after recycling the services.



We have configured all our objects managers
and external connection to point to app2 in the meantime, however some of the
sertvices like to outbound communication manager are not working (Communication
Request) which impact our service levels to our clients. Please contact us as
soon as possible.

Thank you.

Cause

Configuration/ Setup

Solution

Message 1

For the benefits of other users:



All the components on one of the
application servers, app1, were exiting with error. Reviewed of all the
components log files show the following error
messages,



GenericLog    GenericError    1    2005-01-31
23:25:28    Error: can't get version of installed components (ENU
sia)



GenericLog    GenericError    1    2005-01-31
23:25:29    (smimtsrv.cpp 57(533) err=2100147 sys=0) SBL-SMI-00147:
(smimtsrv.cpp 57: 533) error code = 2100147, system error = 0, msg1 = Error:
can't get version of installed components (ENU sia), msg2 = (null), msg3 =
(null), msg4 = (null)



GenericLog    GenericError    1    2005-01-31
23:25:28    (smiutil.cpp 20(156) err=2000106 sys=0) SBL-SVR-00106: Internal:The
requested Parameter/event was not found.



Resolution:



It was found
that the ENUSIA folder was missing or moved from
<SIEBEL_ROOT_DIRECTORY>/siebsrvr/bin directory in app1. After copying the
ENUSIA folder from a working application server to app1, all the components
started successfully.



The customer then tried to restart the whole
environment including the two application server. However, this time a different
issue occurred. It was the second application server, app2, that was not able to
start up. Reviewed of the siebsrvr.log showed the following error
message,



GenericLog    GenericError    1    2005-02-01
05:15:12    (sccnmsys.cpp 9(1295) err=4400025 sys=0) SBL-SCC-00025: No value
found in the Gateway. Default value in the repository is
used.



[More...]

Message 2

[Continue...]



The customer was advised to replace the siebns.dat with
a backup copy and app2 was able to startup successfully.



Keywords:
srlcver.dll SBL-SMI-00147 SBL-SCC-00025 SBL-SCC-00025

Applies to:

Siebel System Software - Version: 7.5.3.8 SIA
[16192] and later   [Release: V7 and later ]
IBM AIX on POWER
Systems (64-bit)
Product Release: V7 (Enterprise)
Version: 7.5.3.8 [16192]
Cons Sec
Database: Oracle 9.2.0.4
Application Server OS: IBM AIX 5L
5.1
Database Server OS: IBM AIX 5L 5.1

This document was previously
published as Siebel SR 38-1604114011.

***Checked for relevance on
11-Aug-2011***

Symptoms

I have installed MR 7.5.3.8 over
7.5.3.3. I decided to uninstall MR to go back to 7.5.3.3. Ran uninstaller and
selected MR-uninstall.
Now I get the following error message when I try to
start the Siebel Server. I do not get any error starting the gateway.
I have
done a grep on all base.txt-files, and everyone reports SIA
7.5.3.3.
<siebel@tyfon1> cat ES_TST3.SS_TST3.log
1021 2004-11-10
13:50:03 2004-11-10 13:50:13 +0100 00000003 001 001f 0001 09 SiebSrvr 63501
38308 1
/siebel/siebtst3/siebsrvr/enterprises/ES_TST3/SS_TST3/log/ES_TST3.SS_TST3.log
7.5.3.8 [16192] ENU
GenericLog      GenericError    1       2004-11-10
13:50:03     Error: versions of installed components do not match (wanted
version: 7.5.3.3, actual version: 7.5.3.8 ENU
)
GenericLog      GenericError    1       2004-11-10
13:50:03     (lstnsvc.cpp 8(113) err=2100147 sys=0) SBL-SMI-00147: (lstnsvc.cpp
8: 113) error code = 2100147, system error = 0, msg1 = Error: versions of
installed components do not match (wanted version: 7.5.3.3, actual version:
7.5.3.8 ENU ), msg2 = (null), msg3 = (null), msg4 =
(null)
GenericLog      GenericError    1       2004-11-10
13:50:13     (siebsvc.cpp 12(218) err=2100147 sys=0) SBL-SMI-00147: (siebsvc.cpp
12: 218) error code = 2100147, system error = 0, msg1 = (null), msg2 = (null),
msg3 = (null), msg4 = (null)

<siebel@tyfon1>
pwd
/siebel/siebtst3
<siebel@tyfon1>
<siebel@tyfon1> find
. -name base.txt | xargs -I {} cat {} | grep 7.5.3.8
<siebel@tyfon1>

Cause

Incorrect Execution.

Solution

For the benefit of other users, the
customer found that after uninstalling the 7.5.3.8 Maintenance Release to
rollback to 7.5.3.3, the log files on the Siebel Server stated they were
operating at 7.5.3.8 while the remainder of the environment indicated the latest
Maintenance Release installed is 7.5.3.3.

Summary:

This issue was
resolved by performing the following steps:
•    Restoring the 7.5.3.8
environment
•    Stopping all Siebel Services operating on the machine i.e.
Siebel Gateway, Siebel Server and Web Server (if applicable)
•    Running
slibclean as root to ensure the Siebel library files on the AIX Application
Server were no longer in use
•    Execute the 7.5.3.8
uninstaller

Customers are advised to run slibclean after stopping
services on an AIX machine before applying or uninstalling Siebel
software.


Keywords: slibclean, uninstall, library,
AIX

Applies to:

Siebel CRM - Version: 8.1.1.5 [21229] to 7.8.2.6
[19230] - Release: V8 to V7

IBM AIX on POWER Systems (64-bit)

Symptoms

When installing 7.8.2.6 onto
7.8.2.4 on AIX5.3, some library files were not copied.



This caues failing
to start up Siebel Server service with following error.



GenericLog GenericError 1 0 2007-05-15 21:42:38 Error:
versions of installed components do not match (wanted version: 7.8.2.6, actual
version: 7.8.2.4 JPN)
GenericLog GenericError 1 0 2007-05-15 21:42:38
(lstnsvc.cpp (113) err=2100147 sys=2) SBL-SMI-00147: Version check failed
because: Error: versions of installed components do not match (wanted version:
7.8.2.6, actual version: 7.8.2.4 JPN)

Cause

The files have unique timestamp.




For example:

7.8.2 : Jun 16 2005

7.8.2.4 : Sep 27 2006


7.8.2.6 : Apr 13 2007



When installing the target patch, the
installer checks the time stamp of the files and it does not copy the new files
when the time stamp of the target file does not match the unique time stamp on
the original version has.



Furthermore, not only the files are not copied
from the target installer, there is no output (e.g. alert, logfile) and it
cannot be confirmed whether the problem has occurred.  It would be useful to log
files to troubleshoot the issue. 

 

Solution

An enhancement request 12-1REE5EX has been logged to output the log file or
alert when the files are not copied successfully.

Applies to:

Siebel Life Sciences CRM - Version: 8.1.1
[21112] and later   [Release: V8 and later ]
Information in
this document applies to any platform.

Symptoms

The errors recorded when an
attempt is made to start the localised AOM, in both the enterprise and AOM log,
indicates only the older version (8.1.1.1) is
recognised:

 "...ePharmaObjMgr_enb 656 SBL-SMI-00147
Process 656 exited with error - Version check failed because: %1" -- error
recorded in enterprise log

"... Error: versions of installed components
do not match (wanted version: 8.1.1.3, actual version: 8.1.1.1 ENB )" -- error
recorded in AOM log.

Changes

Fix Pack 8.1.1.3 was applied to a
pre-existing multilingual environment

Cause

British English is an unshipped
language
In this instance, the localized application based on it  was not
correctly updated after applying Fix Pack 8.1.1.3

Solution

To correct this problem, do review and
work through recommended guidelines relating to unshipped languages, Siebel
Global Deployment Guide > Localizing Global Deployments > Localizing an
Unshipped Language > Creating New Language Subdirectories,
paying particular attention to steps which need to be revisited every time a new
patch is applied.

Applies to:

Product Release: V7 (Enterprise)

Version:
7.7.2.3 [18361]

Database: Microsoft SQL Server 2000 SP3

Application Server
OS: Microsoft Windows 2000 Advanced Server SP 2

Database Server OS: Microsoft
Windows 2000 Advanced Server SP 2



This document was previously published
as Siebel SR 38-3065016531.

Symptoms

We are trying to run the 7.7.2.6
upgrade to fix the IE Active-X control issue. After running the install we can
not get Siebel to come up. We get the following error in the log
file:



2021 2006-06-06 13:16:02 2006-06-06 13:16:02 -0400 00000003 001
003f 0001 09 SiebSrvr 53252 3332 3748
D:\Siebel\TBH\HCB\siebsrvr\log\HCB_DEV.UNSER.log 7.7.2.6 [18372]
ENU

GenericLog    GenericError    1    0    2006-06-06 13:16:02    Error:
versions of installed components do not match (wanted version: 7.7.2.0, actual
version: 7.7.2.6 ENU )

GenericLog    GenericError    1    0    2006-06-06
13:16:02    (lstnsvc.cpp (113) err=2100147 sys=126) SBL-SMI-00147: Version check
failed because: Error: versions of installed components do not match (wanted
version: 7.7.2.0, actual version: 7.7.2.6 ENU )



As you can see, the
startup fails immediately.



Attached to this SR is a copy of the log file
from the install. It looks like there are some files that the installer can not
find during the upgrade process. It looks like the upgrade didn't really
work.   Could you review the upgrade log and let us know what to do. We
downloaded our media from the edelivery site.



Thanks,

Solution

Message 1

For the benefit of other
users:



The customer downloaded the Siebel 7.7.2.6 fix pack from
http://edelivery.oracle.com.

After running the installation, it was noted
that the following error message had been written several times by the installer
to SIEBEL_ROOT\log.txt:



Setup.product.install, SiebelFiles, err,
java.io.IOException: Could not obtain resource:
D:\Downloads\Siebel\7726sia\Windows\Server\Siebel_Enterprise_Server\setup\588de701b9a711024751e8ba2dc50d11\md5\2120e1666ea49dcea663a975d538160c
(The system cannot find the file specified) STACK_TRACE: 18 ...





After
downloading the installation software again from http://edelivery.oracle.com,
the customer was able to apply the fix pack successfully.





Best
Regards,

SBL-SMI-00140: Internal: The MT Server has been disabled

Applies to:

Siebel Workflow - Version: 7.7.2.10 [18385] to 8.0
[20405] - Release: V7 to V8
Information in this document applies to any
platform.
** Checked for relevance on 27 February 2012**

Symptoms

Customer is facing recent and
intermittent unavailability of WfProcMgr component installed in one server.
Customer has noticed one occurrence this Sunday 02/15 at 10:30 AM and  02/16
3:20 AM. When it occurred they were able to restart the server. Customer is not
able to always restart the siebel server because the application does not
respond in a timely manner.

Since WfProcMgr seems unavailable for some
reason SISNAPI errors in SRBroker logs were found also as a consequence of this
component being unavailable it seems that records in S_ESCL_REC are
increasing.

The records in S_ESCL_REC seems to be associated to triggers
created for assignment of campaigns. No recent changes were made on wf policies
or configuration.



In the enterprise log and confirmed that
WfProcMgr became unavailable.

From the Enterprise logs the related
WfProcMgr logs and this analysis resulted in 3 groups of enterprise +wfprocmgr
logs:

In WfProcMgr_58975.3.log  can also find the error SBL-SMI-00140:
Internal: The MT Server has been disabled.
Customer can see from
WfProcMgr_80330.log that the same instance'1-6E1YM0' was still not able to be
resumed even after several hours > SBL-BPR-00124: Cannot resume process
instance '1-6E1YM0'. Verify that it does exist and has a 'Waiting', 'Suspended'
or 'In Error' status.

A3, B3: For the Workflow Process Manager created by
the Siebel Server Scheduler at 2009-02-16 03:19:36 with task id 80973 and exited
at 2009-02-16 03:20:37.

Finally here Customer were able to find the error
SBL-SMI-00062: Internal: No more process (multithreaded server) slots available
in WfProcMgr_80973.log.


Customer checked the memory limits and found
that memory limits are not being reached (or reached only 20% below the limit)
which indicate that the cause does not seem memory related.

Cause

There were 2 problems associated to this workflow component
crash;hang:

1. Associated to the jobs executed by workflow process SMCC -
List Import is consuming too many threads. At some point max tasks limit is
reached and as a consequence no more threads can be created to continue trying
to process these records. This would explain why we saw the error SBL-BPR-00124:
Cannot resume process instance '1-6E1YM0'.



2. After this problem was solved it seems that a crash was found. This
crash was associated to the workflow process "SMCC Sync PEM Status - Contact
Phone Status" fails.


The error seems to happen when the method "'SyncPEMStatus" updates a business
component field with a picklist with a value that is not available in this
picklist. The pick lists name is "Response Outcome PickList".

Solution

1. By stopping the instances in
loop from the workflow instance view have helped to free up some threads and
avoid the Max Tasks limit to be reached. This means that this job that is
processing List Import records must be reviewed in order to ensure that it will
not keep in loop and allocating a high number of threads until the limit is
reached.

2. The suggestion here is to ensure that the value being used
(by workflow process "SMCC Sync PEM Status - Contact Phone Status") to update
the field (by the method "'SyncPEMStatus") exists in the picklist associated to
this field ("Response Outcome PickList"). 

 

 

 

 

Applies to:

Siebel System Software - Version: 7.8.2.3 SIA
[19221] and later   [Release: V7 and later ]
z*OBSOLETE:
Microsoft Windows Server 2003
Product Release: V7 (Enterprise)
Version:
7.8.2.3 [19221] Fin Svcs
Database: Oracle 9.2.0.6
Application Server OS:
Microsoft Windows 2003 Server SP1
Database Server OS: IBM AIX 5L
5.2

This document was previously published as Siebel SR 38-3208039791.

Symptoms

SBL-SMI-00140
Our Production system "stopped" processing today at 12:07 AM. There were 8
active PIMSI engine tasks processing, but did not completed for 8
hours.

One PIMSI Engine log showed the
following:
GenericLog    GenericError    1    0    2006-11-24
11:56:18    (smimtreq.cpp (457) err=2100140 sys=0) SBL-SMI-00140: Internal: The
MT Server has been disabled.

We stopped and started our PIMSI processes
and after a Recovery, the SSSE appears to be working and completing all 640 sync
enabled users.

I searched support web but did not find anything relating
to the error. Could you please:

a) describe the error
b) what is the
appropriate action to take
c) is there any document where we can find all of
the many errors/warnings that come from SSSE and details of what to do about the
same?

Cause

Documentation enhancement

Solution

Message 1

For the benefit
of other users:

Customer was looking for an SSSE document where they can
find all of the many errors/warnings that come from SSSE and details of what to
do about the same.

Currently there is no such document available either
on the Supportweb or such section in the Siebel Server Sync Guide.


Although SSSE is a fairly new product offering, if there is a
documentation with errors/warnings and troubleshooting steps, that would
facilitate various end users like administrators and developers to support SSSE
in a Production environment easily.

Please note that a Change Request,
CR#: 10515531: “SSSE documentation with errors/warnings and appropriate actions
to take (troubleshooting)” has been logged for documentation enhancement for a
SSSE document with errors/warnings and troubleshooting steps.

Thank
you.
 

 

Applies to:

Siebel CTI - Version 7.7.2.6 [18372] and
later
Information in this document applies to any platform.
Upon upgrading
of Cisco CTI Driver we started experiencing higher than normal task counts for
Siebel CSM
processes. However since the upgrade on Friday we have had 5 of
our 20 CSM have task counts approach the limit that we are configured for which
is 25.
Today they have seen the issue on 6 different Comm Servers and
multiple times on one of them.

Issue Impact
If these hung pids are not
killed and they reach their max tasks of 25 the Comm Server Manager will crash.
It has happened on 6 different servers today. The customer is considering
backing out the upgrade.

Snippet from scomm logs
5:13:34 PM
100289106_28719[03/26/2011 13:28:03]:INFO:Trust Client Hostname
(RMDTV2594)
100289106_28719[03/26/2011 13:28:03]:INFO:Client login from
IP(10.137.157.43), Host(RMDTV2594)
100289106_28719[03/26/2011
13:28:04]:INFO:UpdateAgentActiveInfo ok, CfgID:1-9OAW39J,
TelesetID:1-EML18SW
100289106_28719[03/26/2011
13:32:40]:INFO:ResetAgentActiveInfo ok
100289106_28719[03/26/2011
13:32:48]:INFO:UpdateAgentActiveInfo ok, CfgID:1-9OAW39J,
TelesetID:1-EML18SW
100289106_28719[03/26/2011 13:42:53]:FATAL:SRM request
time out in 600 seconds. No response from Comm. Session
Manager
100289106_28719[03/26/2011 13:42:53]:FATAL:Failed to submit SRM
request(InvokeCommand) to server, or Comm. Session Manager failed on processing
request, ccfErrCode(1300001, input-args={

CSM Logs ' GenericLog
GenericError 1 0 2011-03-26 13:45:07 (smimtreq.cpp (457) err=2100140 sys=0)
SBL-SMI-00140: Internal: The MT Server has been disabled
GenericLog
GenericError 1 0 2011-03-26 13:45:13 (smimtreq.cpp (457) err=2100140 sys=0)
SBL-SMI-00140: Internal: The MT Server has been disabled

Symptoms

On : 7.7.2.6 [18372] version, CTI

When attempting to use CTI
functionality
the following error
occurs.

ERROR
-----------------------
100289106_28719[03/26/2011
13:42:53]:FATAL:SRM request time out in 600 seconds. No response from Comm.
Session Manager
100289106_28719[03/26/2011 13:42:53]:FATAL:Failed to submit
SRM request(InvokeCommand) to server, or Comm. Session Manager failed on
processing request, ccfErrCode(1300001, input-args={

Changes

none

Cause

version 7.5 ICM (latest version of the driver) on older version of Siebel
7.7.x

Solution

Driver provider Cisco was involved in this to look into supportability of the
version 7.5 ICM (since it is their latest version) on older version of Siebel
7.7.x as there are CSM hangs using this particular combination only. Cisco was
going to perform a round of tests and provide the solution.

Note : Since
ICM 6 is working fine customer was staying with that version for the
timebeing.

Applies to:

Siebel CTI - Version: 7.7.2.6 [18372] to 8.1.1
[21112] - Release: V7 to V8
z*OBSOLETE: Microsoft Windows 2000
This
document was previously published as Siebel SR 38-3198235381.

Symptoms

Customer system is based on multi
Communication Session Manager (CSM) components running on the same server.

Agents assigned to a given CSM are being logged out and try to login back
are connected to a different CSM than the one defined in CommSessionMgr
parameter of the Communications Configuration.

Here the log fragments
verified by customer:

GenericLog GenericError 1 0 2006-11-09 08:56:48
(smimtreq.cpp (457) err=2100140 sys=0) SBL-SMI-00140: Internal: The MT Server
has been disabled

This started around 8am yesterday on one component and
today around 8am today on the other.

Agent logins to Siebel
and CommSessionMgr that uses I3 CTI Driver then started failing because the
object manager apparently to start using the wrong comm session manager to
attempt to login to I3 CTI middleware.

Example agent1 is configured to
use CommSessionMgrOne. When agent1 logged into Siebel, then tried to log into
the CTI toolbar and login failed. The i3 logs indicate that the agents login
request was coming from CommSessionMgr, not CommSessionMgrOne component. And
since CommSessionMgr uses a different cti server than CommSessionMgrOne, the
logins failed.

Could you please explain what would all the sudden cause
the error above and what do to to mitigate it?

Cause

Customer had an implementation on I3
with several Communication Session Manager component placed on the same server
that included the Siebel Gateway Name Server.

Agents are organized in
separate CSM components: CommSessionMgr and CommSessionMgrOne

From the
information send we could analyze the log fragment and found an entry for the
issue.
Considering the fragment form file:


DS020_SComm_TMARSHA2.txt.log

...
TMARSHA2_40769[12/01/2006
11:35:51:421]:FATAL:Failed to establish session to GateWay(siebelgateway),
Enterprise(siebel), Server(cridds020), Component(CommSessionMgrOne),
ccfErrCode(2100140)
TMARSHA2_40769[12/01/2006 11:35:51:437]:DEBUG:About to
connect to Server Request Broker at GateWay(siebelgateway), Enterprise(siebel),
Server(cridds020) with user(TMARSHA2),
key(ea4|457059e7|0)
TMARSHA2_40769[12/01/2006 11:35:51:468]:INFO:Successfully
established session to Backup Server at GateWay(siebelgateway),
Enterprise(siebel), Server(cridds020), Component(CommSessionMgr)

Solution

By default the Siebel Gateway Name
Server in the absence of the primary CSM CommSessionMgrOne for example if the
component is down or not available it will try to connect the Object Manager
session to default CSM that is: CommSessionMgr

This explains why the
agent got connected to the other CSM component/instance.

 

 

Applies to:

Siebel
Information in this document applies to
any platform.

Purpose

This document describes how to troubleshoot the behavior where the
Communications Session Manager (CommSessionMgr component alias) component
process hangs/freeze.

When this type of behavior occurs the
CommSessionMgr component tasks in running status will start to increase. You can
verify that in Site Map>Administration – Server Management >
Components> select Communications Session Manager and verify column Running
Normal Tasks.


The CommSessionMgr component tasks correspond to a CTI Command or Event and
should be processed in less than 1 second, so during normal operations you
should see 0 or 1 or 2 tasks running even for very large deployments. If you see
several tasks running and just increasing the CommSessionMgr hang or freeze is
identified.

This behavior could also generate error messages in Siebel
log files similar to bellow:

In CommSessionMgr component log files
message like:

• “SBL-SMI-00140: Internal: The MT Server has been disabled”, when
  CommSessionMgr component reaches MaxTasks component parameter.

In SComm_<used id>.log:

• “FATAL:SRM request time out in 600 seconds. No response from Comm. Session
  Manager”, indicating that the Siebel Object Manager made a request to the
  CommSessionMgr component but it did not respond in 600 seconds (default value
  for CommReqTimeout component parameter)

For the end user a Communications Session Manager hang has high impact in the
whole Siebel Enterprise operation, unlike a CTI Toolbar hang described in Note 477899.1 or
Internet Explorer hang described in Note 477510.1
that usually are very sporadically affecting few users at a time.


A Communications Session Manager hang will affect several users at the same
time or the whole Enterprise with high impact in the production environment. For
the end user usually this cause users not able to use the CTI Toolbar (CTI
Toolbar buttons disabled), Siebel Application hang for several minutes when
trying to login CTI users, Siebel Application freeze when trying to use CTI
Toolbar, High CPU in Siebel Servers.

Troubleshooting Steps

Cause

The CommSessionMgr component acts like a gateway between the Siebel
Application Object Manager component and the CTI Driver. The Application Object
Manager sends the CTI commands/request to CommSessionMgr component that forward
it to the CTI Driver to be processed. In case of CTI events the CTI Driver will
received the CTI events from the Switch/CTI Middleware Server and send it to
CommSessionMgr component that will forward the event to the Application Object
Manager to be processed. There is not processing of CTI Commands or Events by
the Communications Session Manager component itself. In the majority of the
scenario the root cause for a CSM hang is the CTI Driver stop responding or
Siebel Application Object Manager or Service Request Broker component stop
responding to CommSessionMgr.

The CommSessionMgr component loads the CTI
driver library that usually is provided by a third party CTI Middleware vendor
(Cisco, Avaya, I3, Syntellect, Nortel...). In the majority of the
CommSessionManager hang scenarios the CTI Driver stop responding causing the
CommSessionMgr tasks running for more than 1 second.



One way to verify if the root cause is related to the CTI Driver or
Siebel Application Object Manager/SRBroker component freeze is to verify in a
Siebel Server with multiple instances of CommSessionMgr component if ALL
instances hang at the same time or just one instance at a time on a given Siebel
Server. If just one or not all CommSessionMgr component instances are affected
most likely the CTI Driver stopped responding. In case ALL CommSessionMgr
instances show tasks running increasing at the same time most likely an
Application Object Manager or SRBroker hang is affecting the CommSessionMgr
component. For Application Object Manager hang scenario you can also refer to Note
478050.1.

Troubleshooting

For Communications Session Manager component hang is highly recommended
verifying with the CTI Driver Provider if you are running the CTI Driver with
the latest patches available for the current version or if there are upgrade
recommendations to a newer version of the CTI Driver. There are several calls
scenario and CTI Driver parameters setttings detected by the CTI Driver
providers that could lead to CTI Driver stop responding and thathas been fixed
though patches to the CTI Driver or new version of the CTI Driver(new
libraries).


There are no know issues
related to Communications Session Manager itself reported causing the component
hang.

How to recover and improve stability for CommSessionManager hang
scenarios:

• The recommended approach is to manually kill the Communications
Session Manager process hanging to immediately avoid new CTI operation been
redirect to the hang CSM instance. You can identify the CommSessionMgr process
ID from Site Map>Administration – Server Management>Component>select
Communications Session Manager>Tasks and verify the PID for the tasks
Running. The PID is the siebmtshmw process that needs to be killed in Windows
Task Manager or "kill -9 <PID>" command in Unix. If component advanced
parameter Auto Restart is set to True (default value), a new CommSessionMgr
instance will be launch. Trying to shutdown the component may not respond since
the CSM instance is on hang status and this could shutdown health CSM instances
too.
• To improve stability is high recommended to launch more than one
CommSessionMgr component instance per Siebel Server. In most of the CSM hang
scenario only one instance is affected at a time and this way it would only
affect CTI users connected or trying to connect to the hang CommSessionMgr
instance. Please refer to Note 477606.1 How
Do You Use the MaxMTServers and MinMTServers Parameters To Improve Stability of
the Communications Session Manager and To Manage Multiple CommSessionMgr
Processes?.

Gathering Information for Technical Support

If you have verified that you are running the CTI Driver with the latest
patches and still observer the issue, log a new Service Request with Siebel
Technical Support, supplying as much of the following information as
possible:

• Your current Communications Configuration file (.def). You can
export that on Site Map>Communications Administration>All
Configurations>select your current configuration and click Export
Configuration so I can review all your Communications Configuration parameters,
Profiles, Commands and Events.
• A copy of your siebns.dat file located at
Siebel Gateway Root Folder\Admin (Windows) and \sys for Unix.
• For one
incident the following matching information:

o A list of CSM tasks running, you can generated that using the Siebel Server
Manager Command Line tool with the commands:

spool CSMTasksRunning.txt
list tasks for comp
CommSessionMgr
spool off

o Enable the event trace log level Server Requests Routing Info (SRMRouting
event trace alias) for CommSessionMgr component to level 4 and set the parameter
“Use Shared Log File” to False. Provide all CommSessionMgr component log files
from the Siebel Server



o Enable the SComm.log debug mode as per Note 476563.1 How
Can Users Activate Debug Level of Log Messages When Using CTI Functionality? and
provide ALL SComm*.log from the Siebel Server having issues. If the
CommSessionMgr component is not running on the same Siebel Server that
Application Object Manager is running, provide ALL SComm.log from the Siebel
Servers running the Object Manager component too.

o The CTI Driver log files if available, please refer to CTI Driver
manual and CTI Driver provided Technical Support to verify how to enable debug
tracing on CTI Driver log files.

o Siebel Enterprise Server log covering the component crash, the Siebel
Enterprise Server log is located on Siebel Server log folder with the name
<Siebel Enterprise Name>.<Siebel Server Name>.log.


o Notice that is very important to collect this information covering the
first CommSessionMgr task in running status for more than couple of seconds,
since the first task indicates the time stamp for when the hang started. As the
SComm.log store up to 1MB of information by default that usually keep couple of
hours you must collect the log files as soon as task running is
detected.

SBL-SMI-00126: The session has timed out

Applies to:

Siebel System Software - Version 7.8.2.5 [19227] and later

z*OBSOLETE: Microsoft Windows Server 2003

Product Release: V7 (Enterprise)

Version: 7.8.2.5 [19227]

Database: Oracle 10.1.0.4

Application Server OS: Microsoft Windows 2003 Server SP1

Database Server OS: Sun Solaris 9



This document was previously published as Siebel SR 38-3388527211.

""""Checked for relevance on 23-MAY-2012""""

Symptoms

The connections from webMethods to Siebel are intermittently failing
with an error code 8234 on webMethods. Here is a sequence of events
observed in logs:

1. webMethods attemps to login and open a connection.

2. a new session is instantiated in Siebel and waits, but does not proceed with authentication.

3. webMethods request reports 8234 with a timeout after 2 mins.

4. webmethods opens another connection. This goes through successfully.

5. The first Siebel session terminates with a timeout after 45 mins.



The siebel log prints the typical parameters for the session and then the following two statements:

2021
2007-06-28 16:21:23 2007-06-28 17:06:24 -0400 0000014a 001 003f 0001 09
eMediaObjMgrWM_enu 25802 4040 6004
D:\sea78\siebsrvr\log\eMediaObjMgrWM_enu_25802.log 7.8.2.5 [19227] ENU

TaskConfig    TaskCfgParamInit    4    0    2007-06-28 16:21:23    The Parameters for the current task are :

TaskConfig    TaskCfgParamInit    4    0    2007-06-28 16:21:23        Enterprise                                    : SiebelINT

TaskConfig    TaskCfgParamInit    4    0    2007-06-28 16:21:23        Server                                        : SBINT2

TaskConfig    TaskCfgParamInit    4    0    2007-06-28
16:21:23        Siebel Home                                   :
D:\sea78\siebsrvr

....

prints other parameters

...

TaskConfig    TaskCfgParamInit    4    0    2007-06-28 16:21:23        Eligibility Display Mode                      : 1

TaskEvents    TaskCreation    3    0    2007-06-28 16:21:23    Created
context for task 25802 with session timeout = 2700 (thrdId 6004,
timestamp 1183062083)

TaskEvents    TaskTimeout    3    0    2007-06-28 17:06:24    SBL-SMI-00126: The session has timed out.

Further investigation in the Webmethods logs showed the following errors:

2007-06-28 13:02:12 EDT [ISC.0066.0024V5] FSMTValuesHash.getEntryLock(): id=24381839 lock request granted

2007-06-28 13:02:14 EDT [ART.0114.1007E] Adapter Runtime: Error Logged.
See Error log for details. Error: [ADA.448.1000]
SiebelJavaConnection.connectFromValues -
dataBean.login(siebel.tcpip.none.none://sbwsint01:2321/SiebelINT/eMediaObjMgrWM_enu)
threw a SiebelException: code(8234), msg(Logon Request 394 was
abandoned after 68991 ms. Connection: 6481 due to connection shutdown
request Connection timed out (SBL-JCA-303) )

2007-06-28 13:02:14 EDT [SCC.0126.0119E] An error occurred while
attempting to create connections for
IEEEBMSConnections.Siebel:Siebel_eMedia

2007-06-28 13:02:14 EDT [SCC.0126.0106E] An error occurred while
attempting to retrieve a connection from
IEEEBMSConnections.Siebel:Siebel_eMedia

2007-06-28 13:02:14 EDT [SCC.0126.0202V1] SCC ConnectionManager pool IEEEBMSConnections.Siebel:Siebel_eMedia reset

2007-06-28 13:02:14 EDT [ART.0114.1007E] Adapter Runtime: Error Logged.
See Error log for details. Error: [ART.118.5053] Adapter Runtime
(Connection): Unable to get a connection to resource
IEEEBMSConnections.Siebel:Siebel_eMedia.

[ADA.448.1000] SiebelJavaConnection.connectFromValues -
dataBean.login(siebel.tcpip.none.none://sbwsint01:2321/SiebelINT/eMediaObjMgrWM_enu)
threw a SiebelException: code(8234), msg(Logon Request 394 was
abandoned after 68991 ms. Connection: 6481 due to connection shutdown
request Connection timed out (SBL-JCA-303) )

2007-06-28 13:02:14 EDT [ART.0114.1007E] Adapter Runtime: Error Logged.
See Error log for details. Error: [ART.117.4012] Adapter Runtime
(Adapter Service): Unable to run adapter service. Error occurred when
connecting to resource IEEEBMSConnections.Siebel:Siebel_eMedia.

[ART.118.5053] Adapter Runtime (Connection): Unable to get a connection to resource IEEEBMSConnections.Siebel:Siebel_eMedia.

[ADA.448.1000] SiebelJavaConnection.connectFromValues -
dataBean.login(siebel.tcpip.none.none://sbwsint01:2321/SiebelINT/eMediaObjMgrWM_enu)
threw a SiebelException: code(8234), msg(Logon Request 394 was
abandoned after 68991 ms. Connection: 6481 due to connection shutdown
request Connection timed out (SBL-JCA-303) )





Cause

This customer was using a connector developed by webmethods, which
uses the underlying technology of "Siebel Java Data Beans" to connect to
the siebel object manager.



A thorough review of java data beans timeout settings has not helped.



Java Data Beans timeouts are described at

Transports and Interfaces: Siebel Enterprise Application Integration
> Integrating with Java > About Running the Java Data Bean >Connection Parameters for the SiebelDataBean



They did not help though.

PLEASE NOTE: siebel.properties file is not the first in precedence.

If the java code provides values for these parameters, they are used.

If the java code does not provide values, the next step is to look up siebel.properties. If found, it is used.

If not found, then default values described in the above bookshelf reference apply.

See also Utilizing the siebel.properties did not succeeded in our J2EE application (Doc ID 536387.1)

The customer network experts further investigated the issue and found
out there were timeout settings at a firewall between the 2
applications:



"We worked with our network team to install a sniffer, capture tcp
traces on the webMethods servers, review them along with the logs from
Siebel and webMethods.

The traces show retransmissions and a reset on the tcp ports at times of
failure and the problem seems to be with either webmethods
adapter/Siebel java data bean trying to communicate on tcp ports that no
longer have an active Siebel session on the other end or our network
configuration with a firewall and two routers in between these two
servers blocking reuse of the tcp ports.



We seem to run into this condition because webMethods adapter does not
honor the expire timeout and close the connection nor recognize the
termination of the target Siebel session."

Conclusion :

"the connections are getting dropped due to a timeout setting on our
firewall. We have not seen any connection failures after we increased
the timeout."

Applies to:

Siebel Wireless - Version: 7.8.2 [19213] and later   [Release: V7 and later ]

z*OBSOLETE: Microsoft Windows Server 2003

Product Release: V7 (Enterprise)

Version: 7.8.2 [19213]

Database: Oracle 9.2.0.6

Application Server OS: Microsoft Windows 2003 Server SP1

Database Server OS: HP-UX 11i



This document was previously published as Siebel SR 38-3106277661.

Symptoms

SBL-SMI-00126Dear Supportweb,



We’re dealing with loss of information during synchronization in our
environment. Please see attached log file (CGCEObjMgr_esn_24409.log). As you can see, for some
reason the connection was interrupted (error SBL-SMI-00126) after 30 minutes.



Analyzing
the log file, we can see that some Orders were uploaded, but one Receipt (BC UH Receipt) and
another Order were lost.



Problems:



1) This loss of information is unacceptable.
Orders and Receipts are critical in Unilever operations;



2) No errors were raised during
and after synchronization, in the iPaq or at the server. No errors were reported in the
Administration – Server Management -> Sessions and in the Administration – Mobile ->
Session Administration. Error was discovered because the user noticed that the receipt wasn’t at
the server.



This SR is being logged with maximum priority because we cannot guarantee that
errors like this aren’t occurring for other users. Also, no errors are raised in Administration
Views.



Regards,

Felipe Lazaretti

Cause

Change Request 12-1FLGF8L

Solution

Message 1

Following behavior has been observed.



User runs batchsync selecting uploadonly.

- Transactions are uploaded and are written to the Prevtxns.txt.

- GetEventList is fired.

- Time out occurs.

- OM is trying to process the transactions but there is no Commit statement.

- User tries to run full sync

- OM starts extracting database with no upload transactions.

- SynSummary.txt shows LastTranId as the last transaction that is uploaded and processed.

- OM assumes that all these transactions have uploaded and committed and therefore starts extracting database.

- Records are lost.



This has been determined to be product defect. Change Request 12-1FLGF8L
has been logged to address this defect in future release.



Also, FR 12-1FW1G29 and FR 12-1FLGF9Y have been logged to address this defect in 7.8.2.3 QF and 7.8.2 QF respectively.



Thank you

Applies to:

Siebel System Software - Version: 7.7.2.1 SIA [18353] and later   [Release: V7 and later ]

Oracle Solaris on SPARC (64-bit)

Product Release: V7 (Enterprise)

Version: 7.7.2.1 [18353] ESN Com/Med

Database: Oracle 9.2.0.4

Application Server OS: Sun Solaris 9

Database Server OS: Sun Solaris 9



This document was previously published as Siebel SR 38-2663369531.

Symptoms

SBL-DAT-00398, SBL-SMI-00126Hello support,



we have installed eSales Application with LDAP authentication. We would
like to know how to enable the "Forgot your password" functionallity. When we click the link
forgot your password we find SBL-UIF-00335 error in object manager log file.



We followed
the indications regarding adding the group of views to the user responsability but this does not
work either.



User Registration Forget Pwd Info View

User Registration Forget Pwd
Challenge Ques View

User Registration Forget Pwd Confirm View

User Registration Forget Pwd
Challenge Answer Error View

User Registration Forget Pwd Decline View



Thanks in
advance

David

Cause

Configuration/ Setup

Solution

Message 1

For the benefit of other users:



After enabling a group of workflows the customer got the problem resolved





User Registration Initial Process

User Registration Forgot Password Process

User Registration Process

CUT Exception Handling Process

LOY User Registration Member Process

User Registration SubProcess



Thanks and Regards,



Siebel Technical Support

Applies to:

Siebel System Software - Version: 8.0 [20405] to 8.1 [21039] - Release: V8 to V8
Information in this document applies to any platform.

Product Release: V8 (Enterprise)

Version: 8.0 [20405]

Database: Oracle 10.2.0.1

Application Server OS: Novell SUSE Linux Enterprise 9.0

Database Server OS: Novell SUSE Linux Enterprise 9.0



This document was previously published as Siebel SR 38-3325861536.

*** Reviewed for relevance on 7-Mar-2012 ***

Symptoms

After installation of Siebel 8.0, subsequent Object Manager login sessions appear to hang until they ultimately
timeout, resulting in error message SBL-NET-10407.

Eventually the Object Manager session reported the following message :

MessageFlow MsgFlowDetail 4
0000000d461d2f53:0 2007-04-11 11:10:47 1302858672: Returned from
SessionHandleMsg(1514) for task 11534352, pErrStack = 0x0940d3e0

TaskEvents TaskTimeout 3 00000603461d23d9:0 2007-04-11 12:10:51 SBL-SMI-00126: The session has timed out.

MessageFlow
MsgFlowDetail 4 00000603461d23d9:0 2007-04-11 12:10:51
1302858672: Calling SessionCleanup for task 11534352, pErrStack =
0x0940d3e0

Solution

On further investigation it was established that the customer was
running with a modified HTTP port due to the port access restrictions
for non-root users.

For further information on this please Refer to the Siebel Bookshelf for
your specific version:  'Siebel Installation Guide for UNIX: Servers,
Mobile Web Clients, Tools > Installing the Siebel Web Server
Extension > Postinstallation Tasks for the SWSE > Granting User
Permissions on the Web Server'.



In addition to make the change to the httpd.conf file it was necessary to modify the HTTPPort setting within the eapps.cfg
file on the web server. Once this change was made the customer was able
to establish a connection to the Object Manager and establish a single
session. Subsequent sessions would then receive 'Server Busy' messages.



In order to investigate this behavior an analysis was made of both the
Web Server logs and of the SWSE logs and the following error messages
were evident:


(Web Server Logs)

[Mon May 21 12:36:55 2007] [error] [client
xxx.xxx.xxx.xxx] File does not exist:
/siebel/sweapp/public/enu/images/aGIF, referer:
http://xxxx.xxxx.xxxx.xxxx:nnnn/sales_enu/start.swe?SWECmd=GetViewLayout&SWEView=Server%20Server/Compgroup%20View&SWEVI=&SWEVLC=0-1_Siebel%2bSales%2bEnterprise_43%257c1166247115%257c0_0_20405_00_L

The above message occurs a few times and concerns me a little less than the error below :

[Mon May 21 12:37:14 2007] [warn] child process 25541 still did not exit, sending a SIGTERM

OSDWaitTid: pthread_create failed: Cannot allocate memory

[Mon May 21 12:37:14 2007] [notice] caught SIGTERM, shutting down

(SWSE Logs)

SisnapiLayerLog    Trace    3    0000062a465139af:0    2007-05-21
12:37:05     1133542320: [SISNAPI] Creating SISNAPI Async Thread for
connection (0x8af81f0)

SisnapiLayerLog    Error    1    0000062a465139af:0    2007-05-21
12:37:05     1133542320: [SISNAPI]: connection (0x8af81f0)
OSDCreateThread() failed with errCode = 852173 sysError 12

SisnapiLayerLog    Trace    3    0000062a465139af:0    2007-05-21
12:37:05     1133542320: [SISNAPI]: releasing connection (0x8af81f0),
refCount = 1

SessMgr    ConnOpen    3    0000062a465139af:0    2007-05-21
12:37:05    [SMCONN] Hello handshake to
(siebel.TCPIP.None.None://xxxx.xxxx.xxxx.xxxx:nnnn/SBA_80/SSEObjMgr_enu/RR)
failed in 0 secs

GenericLog    GenericError    1    0000062a465139af:0    2007-05-21
12:37:05    (smconn.cpp (318) err=1180695 sys=0) SBL-NET-01047:
Internal: failed to create async listener thread

These errors suggested memory shortages on the web server and so a
review was made of the configuration and memory consumption. During this
review checks were made for the recommended settings in the httpd.conf file and it was established that there was a difference within the <IfModule worker.c> section :


<IfModule worker.c>

ThreadLimit      1000

ServerLimit        10

StartServers        1

MaxClients       1000

MinSpareThreads     1

MaxSpareThreads  1000

ThreadsPerChild  1000

MaxRequestsPerChild 0

</IfModule>



The customer had configured a ServerLimit of 10 whereas the recommended settings within the Siebel Bookshelf were for StartServers and ServerLimit to be set to 1.



Once this change was made and the Web Server restarted the customer was
able to connect to their Siebel 8.0 environment on the first and
subsequent connection attempts.

Applies to:

Siebel System Software - Version: 7.5.3.13 SIA [16275] and later   [Release: V7 and later ]

Oracle Solaris on SPARC (64-bit)

Product Release: V7 (Enterprise)

Version: 7.5.3.13 [16275] Auto

Database: Oracle 9.2.0.6

Application Server OS: Sun Solaris 2.8

Database Server OS: Sun Solaris 2.8



This document was previously published as Siebel SR 38-3289921981.

Symptoms

SBL-DAT-00144, SBL-EXL-00145, SBL-DAT-00306, SBL-DAT-00315,
SBL-DAT-00322, SBL-DAT-00501, SBL-OSD-00204, SBL-SVR-04000,
SBL-SVR-01004, SBL-SMI-00034, SBL-SMI-00126, SBL-GEN-09103,
SBL-NET-01023, SBL-NET-01201, SBL-NET-01204Our thin clients are presenting error "page can not be displayed” after loggin and doing

some
navigation.



We first thought this is because of the SRF, so we have changed the SRF also.
But still the same error persists.



I am attaching the log files of the Web server and
Siebel eAutomotive object manager.

Some of the errors from the log files
are:

----------------------------------------------------------------------------------------------------

SBL-NET-01204:
Internal: recv() failed: Connection timed out

SBL-SMI-00034: Internal: Error (null) reading a
message from the client

[SWSE] New anon session open failed

SWSE] Could not get an anon
session...PROBLEM

[SWSE] after the timeout/broken anonymous connection impersonate failed.
Could not open repository file '%1'.\n\nFile does not exist or may be in use by another
process?

-----------------------------------------------------------------------------------------------------



We
already tried by recycling the whole environment also.

Cause

Configuration/ Setup

Solution

Message 1

For the benefit of other readers:



After extensive troubleshooting with Resonate environment variables,
Resonate password variables in Unix OS and comparing errors in the web
server and OM logs, customer was able to identify the server which was
presenting the behavior.



Customer had three load balancers in the environment (A, B, C). Due to
some activities they were not using the C load balancer. When shutting
down the A LB, where only B LB was running, the thin client worked
properly without any issue.

When we shut down B and put only A LB up. At that time started getting same error for the thin client.



Customer resolved the issue by removing the defecting node from Resonate and added it back.

It also found that CFGClientRootDir for the defective node was set to
%SIEBEL_ROOT% while searching Siebns.dat. This value was also changed.



Thank you and best reagrds,

Applies to:

Siebel CRM - Version: 7.7.2.4 [18365] to 7.7.2.6 [18372]   [Release: V7 to V7]
z*OBSOLETE: Microsoft Windows Server 2003

Product Release: V7 (Professional)

Version: 7.7.2.6 [18372]

Database: Oracle 9.2.0.7

Application Server OS: Microsoft Windows 2003 Server

Database Server OS: Sun Solaris 2.6



This document was previously published as Siebel SR 38-3205106281.

Symptoms

SBL-DAT-00808, SBL-UIF-00296, SBL-UIF-00501, SBL-UIF-00314, SBL-SMI-00126

Hello,

We have a hyperlink to our Siebel Application on a Web Portal Application.
This
functionality was working fine with 7.7.2.3 Fix Pack level, but now we
are getting a Session Timeout error message after upgrading to 7.7.2.6.
We need immediate attention since users in production environment are affected.

Thanks!

Cause

On Siebel 7.7.2.4 and later versions, the session gets closed at AOM
level when clicking the “X” button, so after clicking the link for the
second time, the user can successfully open a new Siebel session, but he
always gets the “Your session timed out because you were idle for too
long” message first.
Clicking “File > Log Out” in these versions
is working fine, but the "X" button is expected to work just like “File
> Log Out”, which is not happening.

Change Request #
12-1HCLZNP (“Reusing shortcut with SWECmd=GotoView after X-ing the first
session gives session timeout error”) has been logged to address this
issue.
When a product defect or enhancement request is logged, it is
reviewed, prioritized, and considered for incorporation into a future
maintenance or major release.

Solution

Message 1

For the benefit of other readers:

The end user accesses a Web Portal Application.
The
home page of this Portal contains a “New Activity” hyperlink, which
opens a new web browser window and successfully takes the user to a new
Siebel session.
The “New Activity” hyperlink is defined in the following format:

<html>
<a

href="http://hostname/callcenter_enu/start.swe?SWECmd=GotoView&SWEView=Activity+List+View&SWERF=1&SWEHo=hostname&SWEBU=1&SWEApplet0=Activity+List+Applet+With+Navigation"
target="_blank">New Activity</a>
</html>

This hyperlink works fine only for the first time.
After
completing the task with Siebel Application, the user clicks the “X”
button on the web browser window to exit the Siebel Application.
At this stage, he does not use “File > Log Out” menu option to exit the Siebel Application.

When
the user clicks the “New Activity” hyperlink again on the original Web
Portal Application browser window, the following error message is shown
in a pop-up dialog box:

“Your session timed out because you were idle for too long. Please log in again to resume.
If
you had a Siebel attachment open, your changes may have been lost.
Please save the file locally, close it, and reattach it to the
appropriate record.”

After clicking the “OK” button, the Siebel Application is launched normally.
End users started noticing this behavior after applying 7.7.2.6 Fix Pack on top of Siebel Version 7.7.2.3.


According
to Change Request # 12-PUDQB1 (“X-ing out browser window should
terminate a session on OM”), an Enhancement Request was implemented in
7.7.2.4 Fix Pack (Fix Request # 12-10GRFKR) and 7.8.2 Version (Fix
Request # 12-T8C4UR), which causes the “X” button in the web browser
window to behave just as if the user was clicking “File > Log Out”
menu.
This information can be found in the Maintenance Release Guide for Siebel 7.7.

If the user closes the first Siebel session by going to “File > Log Out” menu, he gets successfully logged out.
Then, if he clicks the link again on the same Web Portal page, he does not get the “Session Timeout” message.
Customer
environment uses Web Single Sign-On, so the “File > Log Out” menu
should not be enabled when using Web SSO, and the user must use the “X”
button in this case.

This behavior can be reproduced on a
standard environment, regardless of the Security Adapter being used,
even with Database Authentication without SSO.
We could reproduce
this behavior with a pure HTML file containing a simple HREF link to the
Siebel URL, but only on some environments, and only if the hyperlink
includes the “start.swe?SWECmd=...” part of the URL.
If the URL in
the hyperlink does not contain a “SWECmd” string, everything works as
expected, and no error is shown after closing the session through either
“File > Log Out” or the “X” button.


After performing
further tests, we noticed that the session does get successfully closed
in the Application Object Manager at Siebel Server level after clicking
the “X” button on the web browser window when using Siebel Version
7.7.2.4 or later.
On Siebel Versions prior to 7.7.2.4, the session keeps open until it times out, as expected.

On
Siebel 7.7.2.3 and earlier versions, the session is not closed at AOM
level when clicking the “X” button, since this functionality was
implemented in 7.7.2.4.
So after clicking the link for the second
time in those versions, the following error message used to be
displayed, and users had to click the hyperlink again to open another
Siebel session:

“Your Siebel shortcut cannot be opened in this window.
Please
drag and drop your Siebel shortcut to a window where Siebel is already
running. If you want a second Siebel window, please select the Internet
Explorer Browser icon from your Desktop or select the Internet Explorer
Browser option from your Programs list to create a new window. You may
then drag and drop the Siebel shortcut to this new window.”


This
behavior has been resolved by Siebel Engineering on Fix Request #
12-1HPGG7Z, and a patch is available on Siebel Version 7.7.2.6 [18372]
QF0682.

Customer applied Quick Fix 0682 on top of 7.7.2.6 Fix Pack, and now the application behaves as expected.

Thank you

Applies to:

Product Release: V7 (Enterprise)

Version: 7.5.2.211 [16061]

Database: Microsoft SQL Server 2000 SP 2

Application Server OS: Microsoft Windows 2000 Advanced Server SP 3

Database Server OS: Microsoft Windows 2000 Advanced Server SP 3



This document was previously published as Siebel SR 38-992780051.

Symptoms

SBL-SMI-00126In SI mode: I Logged out using the Ctrl + Shift + X and when I log back in using the same login
page that was served after the logout, it shows the session time out mesage. However, If I log
out by going to the File menu in the Application Menubar and choosing Log out and then log back
again, this problem does not happen.


Here what I found. After logging out using Ctrl +
Shift + X, if I close the login window that is served by the logout and start a new page and
login, it works fine..

Here are the links that is returned after the
logouts.

Logging out using File menu returns this


http://10.15.122.107/system_std/start.swe?File=SWESubmitForm%28document.SWEAppMenuForm%2Cc_14%2C%22%22%2C%22%22%29&Edit=&View=&Help=&SWECmd=Logoff&SWEMethod=*Browser**Logoff**&SWEVI=&SWEView=&SWEApplet=&SWEField=&SWERowId=&SWERowIds=&SWEReqRowId=&SWESeq=&SWESP=&SWETargetView=&SWETVI=&SWETA=&SWEM=&SWEH=&SWEW=&SWEContainer=&SWEPOC=&SWENeedContext=&SWEKeepContext=&SWEService=SWE+Command+Manager&SWEDIC=&_sn=9jnYBu0uPDWNVlkzUP5PomMUgdi6OtIiT1fid8k.qUM_

Logging
out using Ctrl + Shift + X returns this


http://10.15.122.107/system_std/start.swe?File=&Edit=&View=&Help=&SWECmd=KeyCode&SWEMethod=11088&SWEVI=&SWEView=&SWEApplet=Salutation+Applet+%28WCC+Home%29&SWEField=&SWERowId=&SWERowIds=&SWEReqRowId=&SWESeq=&SWESP=&SWETargetView=&SWETVI=&SWETA=&SWEM=&SWEH=&SWEW=&SWEContainer=&SWEPOC=&SWENeedContext=&SWEKeepContext=&SWEService=&SWEDIC=&_sn=pr9Rq93W8-tY0FMd34319QLoRaUZI8LE4KmJPMstjKU_


Thanks
Aabid

Solution

Message 1

For the benefit of other users:



This problem was reproduced as follows:



1) Set in uagent.cfg:



[SWE]

HighInteractivity=FALSE



2) Restart Siebel server.



3) Login - SADMIN\SADMIN

4) Log out using the Ctrl + Shift + X,

5) Log back in - SADMIN\SADMIN

6) You get a session time out error

when you log back in using the same login page that was served after the logout, it shows the session time out mesage:



"The session timed out because you were idle for too long. Please log in again to resume"

7) If you log in again everything is fine.



Repeat the above test using File > Log out rather than Ctrl + Shift +
X and the time out error is not seen. Change Request 12-GII41X has been
raised to address this Product Defect.