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.