SBL-SSM-00004: SISNAPI Hello failed.
Applies to:
Siebel eConfigurator - Version 8.1.1 SIA [21111] and later
Information in this document applies to any platform.
Symptoms
Errors with Remote Configurator when using WebServices
ERRORS FROM THE LOG:
- StpExec Create 4 00000007504f6a50:0 2012-09-11 18:42:25 Creazione istanza della definizione del passo 'Begin Configuration'.
GenericLog GenericError 1 00000002504f1e77:0 2012-09-11 18:42:26 ( (0) err=4653064 sys=0) SBL-SCB-00008: Componente ((null)) non disponibile su questo server.GenericLog GenericError 1 00000002504f4126:0 2012-09-11 18:42:26 ( (0) err=4653064 sys=0) SBL-SCB-00008: Componente ((null)) non disponibile su questo server.GenericLog GenericError 1 00000002504f1e82:0 2012-09-11 18:42:26 ( (0) err=4653064 sys=0) SBL-SCB-00008: Componente ((null)) non disponibile su questo server.GenericLog GenericError 1 00000002504f1e82:0 2012-09-11 18:42:26 (ssmsismgr.cpp (626) err=3670020 sys=0) SBL-SSM-00004: Si è verificato un errore relativo a SISNAPI Hello. Il componente server potrebbe non essere disponibile.ObjMgrLog Error 1 00000002504f1e82:0 2012-09-11 18:42:27 (rmodel.cpp (2239)) SBL-SVC-00213: Login fallito.ObjMgrLog Error 1 00000002504f1e82:0 2012-09-11 18:42:27 (rmodel.cpp (2279)) SBL-SVC-00209: Login non riuscito durante il tentativo di connessione a siebel://VirtualServer/ENTPRE81/eProdCfgObjMgr_ITAError Error 1 00000002504f1e82:0 2012-09-11)
18:42:27 Cfg Server Manager error: unable to connect to server
eProdCfgObjMgr_ITA for product 1-134L7F using connect string
siebel://VirtualServer/ENTPRE81/eProdCfgObjMgr_ITA - Login non riuscito
durante il tentativo di connessione a
siebel://VirtualServer/ENTPRE81/eProdCfgObjMgr_ITA(SBL-SVC-00209ObjMgrBusServiceLog Error 1 00000002504f1e82:0 2012-09-11 18:42:27 (configsvc.cpp (1486)) SBL-CFG-00155: Complex Object Instance Service Internal Error:ObjMgrLog Error 1 00000002504f1e82:0 2012-09-11 18:42:27 (stepexec.cpp (1572)) SBL-BPR-00162: Errore nel richiamo del servizio 'Configurator Web Service', metodo 'BeginConfiguration' al passo 'Begin Configuration'.
STEPS
The issue can be reproduced with the following steps:
1. Enable Remote Configurator
2. Run a WebService like BeginConfiugration
=> Errors
Cause
EAI Object Manager is trying to launch the default Configurator Component: eProdCfgObjMgr_ITA
However, this component was disabled. Instead cloned components have
been enabled like eProdCfgObjMgr2_ita, eProdCfgObjMgr3_ita,
eProdCfgObjMgr4_ita. But the application is not trying to start it.
The EAI didn't follow the routing of the ecfgserver.txt because it was
automatically deployed by Administration Cache view only on the Siebel
File System set at the Enterprise level and not also on the local Siebel
File System indicated on "Product Configurator - FS location" parameter
of the EAI Object Manager.
Solution
"Product Configurator - FS location" parameter of the EAI Object Manager need to be set appropriately.
Applies to:
Siebel System Software - Version: 7.5.3 [16131] to 7.5.3.17 [16285] - Release: V7 to V7
IBM AIX on POWER Systems (64-bit)
Product Release: V7 (Enterprise)
Version: 7.5.3 [16157] Fin Svcs
Database: IBM DB2 7.2 FixPack 3SA
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-1297856927.
*** Reviewed for relevance on 7-Mar-2012 ***
Symptoms
Customer reported connectivity and response times with one of their notes on the Resonate Site.
Recently, they we added one node to an existing Resonate site to this Siebel Architecture consisting of three servers:
1 Siebel Enterprise Server as the Primary Scheduler
2 Load-balanced Siebel Servers
0 Servers performing backup scheduling
For testing purposes, they disabled Application Server 2.
Application
Server1 receiving traffic and in seconds, and failover worked as
expected. When the App Server 3 (a new one) was connected, Application
Server l
rules were correctly registered and everything was working as it
should.
When a URL request was sent, customer saw Application
Server 3 receiving the request (Open Connection) but the Siebel login
process took a very long time to connect, and eventually timed-out.
Customer certified the NIC and its hardware Checksum.
Upon review, the SWSE log file contained the following entries:
SisnTcpIp SisnSockError 1 2004-05-18
15:51:44 85326: [TCPIP-client] recv() failed for sd=41 (err=73 |
Connection reset by
peer)
GenericLog GenericError 1 2004-05-18
15:51:44 (smconn.cpp 5(399) err=1801023 sys=0) SBL-NET-01023: Peer
disconnected
GenericLog GenericError 1 2004-05-18
15:51:44 (ssmsismgr.cpp 83(435) err=5600004 sys=0) SBL-SSM-00004: SISNAPI
Hello failed. The server component could be
down.
GenericLog GenericError 1 2004-05-18
15:51:44 (ssmsismgr.cpp 83(1189) err=5600006 sys=0) SBL-SSM-00006: error
sending
message
SisnTcpIp SisnSockError 1 2004-05-18
15:51:44 82242: [TCPIP-client] recv() failed for sd=22 (err=73 |
Connection reset by
peer)
GenericLog GenericError 1 2004-05-18
15:51:44 (smconn.cpp 5(399) err=1801023 sys=0) SBL-NET-01023: Peer
disconnected
GenericLog GenericError 1 2004-05-18
15:51:44 (ssmsismgr.cpp 83(435) err=5600004 sys=0) SBL-SSM-00004: SISNAPI
Hello failed. The server component could be
down.
GenericLog GenericLog 0 2004-05-18
15:51:44 ERROR 82242: [SWSE] Set Error Response (User: sadmin Session:
!4.4bfa.3021.40aa65ad Error: 00028344 Message: Not connected to the server.\nSBL-SS
The Object Manager log file contained the following, coinciding log entries:
SBL-SSM-00004: SISNAPI Hello failed. The server component could be down.
...
SBL-SSM-00004: SISNAPI Hello failed. The server component could be down
Changes
SBL-SSM-00004: SISNAPI Hello failed. The server component could be down.
...
SBL-SSM-00004: SISNAPI Hello failed. The server component could be down.
Cause
This is caused by CR #12-LVXBLX (Bug ID 10641666), which occurred on an IBM AIX System running DB2.
In
this environment, the customer was facing login hangs when they
introduced a new NIC (Network Interface Controller), the "IBM
10/100/1000 Base-TX Ethernet PCI-X Adapter - feature code 5701,
14106902" with the features Checksum_OFFLOAD and LARGE_SEND disabled.
While troubleshooting the issue, customer followed the steps documented in My Oracle Support document DOCUMENT 476898.1
in Section II, Steps 6 ("Hardware NIC checksums on AIX"), and 14
("Central Dispatch heartbeat interval too large") but this did not
completely resolve the issue. This document has since been since
revised, since the command ipconfig -a did not provide information about the LARGE_SEND option.
Solution
When using this NIC adapter with Resonate you must manually set the NIC features accordingly:
1. Execute lsattr -E -l 'deviceName'
Make sure it is set to 'NO'.
2. Recalling that the value of Checksum_offload must be "DISABLED", and it is not displayed by executing ipconfig -a, you must set the value manually.CR- 12-LVXBLX (Bug ID 10641666) was originally opened to fix this but
has since been closed as not feasible to fix in Siebel. Resonate is no
longer officially supported after Siebel release 7.5.
Applies to:
Siebel CRM - Version 8.1.1.1 SIA [21211] and later
Information in this document applies to any platform.
Symptoms
Number of srvrmgr command session (CP_NUM_RUN_TASKS for ServerMgr
component) may reach Maxtasks (20 by default) even though the number of
actual sessions are much less. As a result, following error is reported.
-------------------------------------------------
Connected to 0 server(s) out of a total of 4 server(s) in the enterprise
SBL-NET-01023: Peer disconnected
SBL-SSM-00004: SISNAPI Hello failed. The server component could be down.
-------------------------------------------------
Cause
It is possible to start srvrmgr command without /S parameter then
specify the Siebel Server name to run various operation such as "run
task". Doing so the number of active tasks on ServerMgr component on
each Siebel Server is increased. If /S parameter is specified to start
srvrmgr command, the active task count is increased only on the
specified Siebel Server. Here are some examples for each scenario.
<Example>: There are two Siebel Servers A and B. It is assumed
all srvrmgr command sessions keep running simultaneously, because tasks
are started by "run task" and they take some time to finish. Here is how
the number of active tasks on ServerMgr component is increased.
1) With /S parameter.
Number of active tasks for ServerMgr component
A B
- srvrmgr /s A 1 0
- srvrmgr /s B 1 1
- srvrmgr /s B 1 2
- srvrmgr /s A 2 2
2) Without /S parameter
Number of active tasks for ServerMgr component
A B
- srvrmgr 1 1
- srvrmgr 2 2
- srvrmgr 3 3
- srvrmgr 4 4
3) combination of 1) and 2)
Number of active tasks for ServerMgr component
A B
- srvrmgr 1 1
- srvrmgr /s B 1 2
- srvrmgr /s A 2 2
- srvrmgr 3 3
Even though all the scenario run four srvrmgr commands, the number of
active tasks for ServerMgr component have different values.
By default, Maxtasks parameter for ServerMgr component is set to 20.
If the number of Siebel Server is four and each runs five srvrmgr
command simultaneously, it reaches the maxtasks (4 * 5 = 20) therefore
starting the next srvrmgr command fails with the following error.
-------------------------------------------------
Connected to 0 server(s) out of a total of 4 server(s) in the enterprise
SBL-NET-01023: Peer disconnected
SBL-SSM-00004: SISNAPI Hello failed. The server component could be down.
-------------------------------------------------
To verify if this is the case, please monitor the value on CP_NUM_RUN_TASKS for ServerMgr component.
Solution
Here are several ways to resolve this behavior.
1) Increase number of Maxtasks parameter for component ServerMgr on each Siebel Server.
2) Specify /S parameter to start srvrmgr command.
3) Decrease the number of srvrmgr sessions that run simultaneously.
4) Use "start task" instead of "run task" to minimize the session time for srvrmgr.
Applies to:
Siebel CRM - Version 7.5.2 [16007] to 8.1 [21039] [Release V7 to V8]
Oracle Solaris on SPARC (64-bit)
Product Release: V7 (Enterprise)
Version: 7.5.3.8 [16192]
Database: Oracle 9.2.0.4
Application Server OS: Sun Solaris 8
Database Server OS: Sun Solaris 8
This document was previously published as Siebel SR 38-3155380661.
*** Reviewed relevance on 6-Feb-2012 ***
Symptoms
Customer reported the following:
Siebel CRM version 7.5.3.15 id using Resonate and Netegrity Siteminder for Web Single Sign-On.
Users are getting Server Busy Error when trying to log into Sales and eChannel Applications, but only for ENU locale.
Currently
logged users are working fine, and users are able to successfully log
into applications for other locales, such as FRA.
If the system is rebooted, everything comes up again and users can log in normally.
This behavior is being reproduced every day, during peak hours.
We have reviewed Siebel Web Server Extension log files, and found several occurrences of SISNAPI Hello handshake timing out:
Hello handshake to (...) timed out in 60 secs
SBL-NET-01033: The SISNAPI handshake timed out, the Siebel Service may not be running
After 11 retries, the following is being logged by SWSE:
SBL-SSM-00004: SISNAPI Hello failed. The server component could be down.
Open(..., 60, 3600) = [NULL, 2100101]
Open Session failed (0x6ce5) after 711.2367 seconds.
OpenSession Timing: 711.23671 seconds
New anon session open failed.
Could not get an anon session...PROBLEM
after the timeout/broken anonymous connection impersonate failed. Login failed attempting to connect to %1
Set Error Response (User: Session: Error: 00027877 Message: Login failed attempting to connect to...)
Login failed. SBL-SMI-00101: The server is busy, please try again later.
No Application Object Manager log files are being generated for those failing connections.
We noticed that all Siebel Servers contain many 5 MB core dump files.
According to pstack and pmap outputs, the complete Call Stack of the processes that crashed is always the following:
libkernel32.so sys_setup (be395d50, be392d4c, 0, be395cf4, 0, be3a65a0) + 498
libkernel32.so MwKernel32Init (3, be39aa60, be39aa5c, be39aab0, b9ca0, ffbef147) + 4b8
libgdiuser32.so MwMainwinInit (1, be73f6f0, 2, 3, a89b4, ffbeea80) + 298
siebmtshmw mainwin_init (0, 0, 0, 0, 0, 51e40) + 8c
libkernel32.so MwInitDLL (be744980, be722478, 0, be78cabc, be392d4c, bdfeae98) + 20
libgdiuser32.so void _Initializergdiuser_33_32::pre_construct() (be73f6f0, bdfeaf74, 15688, 20, 13984, be7448e0) + 44
libgdiuser32.so _init (0, bfbde7a8, bfbde0c4, bfbde7a8, 31fcc, bfbb00ac) + 48
ld.so.1 call_init (0, 0, bfbde270, bfbde7a8, 200000, bdc000a8) + 198
ld.so.1 setup (bfbde0d0, bfbde190, bfbde7a8, bfbe0f20, 0, bfbde0c4) + 13a8
ld.so.1 _setup (7, b00, ffffffff, ffffffff, bfba0000, ffbef070) + 3e8
ld.so.1 _rt_boot (0, 0, 0, 0, 0, 0) + 88
???????? (0, 0, 0, 0, 0, 0)
Error messages related to the crashes were logged in the Enterprise Server log file:
This means that a Server Component needed to
start a new process in order to handle more tasks, but the process
startup failed during Main Win Initialization.
This caused the Component to crash.
The log file does not show us the Component name, but if this was
an Object Manager, new users would be unable to login, while current
sessions would not be affected.
A new Multithreaded Server
Process is started for an Object Manager whenever the process currently
running reaches the MaxTasks/MaxMTServers ratio.
This happens only for Components with a certain amount of concurrent user sessions.
That
could explain why this behavior affects only some specific Object
Managers (probably the ones with higher demand for user sessions).
It also explains the timeout error messages we found in the Siebel Web Server Extension log files.
There are some known situations that could cause this behavior to happen, as described in the following document:
- MainWin Crashes Causes Component Restart Failure: Document 478173.1).
- Customer checked all possible causes in Document 478173.1, but everything seemed fine.
Cause
Memory segment used by Mainwin was defined too small.
Solution
This was determined as being caused by a memory segment used by Mainwin which was defined too small.
The resolution is to set $MW_GMA_SEGSIZE environment variable in siebmtshw shell script.
We suggest to add the following to $SIEBEL_ROOT/bin/siebmtshw, above the "exec siebmtshmw $@" line:
export MW_GMA_SEGSIZE=0x1000000
Then, restart the Siebel Server for this change to take effect.
Applies to:
Siebel System Software - Version 7.5.3 [16157] and later
z*OBSOLETE: Microsoft Windows 2000
Product Release: V7 (Enterprise)
Version: 7.5.3 [16157]
Database: Microsoft SQL Server 2000 SP3
Application Server OS: Microsoft Windows 2000 Advanced Server SP 4
Database Server OS: Microsoft Windows 2000 Advanced Server SP 4
This document was previously published as Siebel SR 38-1183053761.
***Checked for relevance on 02-NOV-2012***
Symptoms
SBL-SMI-00107, SBL-NET-01023, SBL-SSM-00004, SBL-SSM-00003, SBL-SSM-00006
Dear Tech Support,
We are having a serious issue with our Production url.
http://10.190.170.66/erm_enu
When we login to the url for the very first time,
We get a "Page Cannot Be Displayed" error
[Please look at the Screen shot -Error1.jpg]
When we look at the ERM Object Manager logs, we dont see any new task triggered for the ERM task.
If we refresh the screen, we get the login box, but with a "Page Cannot be Displayed" above the box.
[Please look at the Screen shot -Error2.jpg]
Now, the ERM object Manager log shows the following data:
"2021
2004-02-06 15:03:07 2004-02-06 15:23:14 +0530 00000009 001 001f 0001 09
ERMObjMgr_enu 43120 2640 3088
D:\sea753\siebsrvr\log\ERMObjMgr_enu_43120.log 7.5.3 [16157]
ENUGenericLog GenericError 1 2004-02-06 15:03:07 Invocation
of Applet Menu New Service::NewExpense is not
allowed.GenericLog GenericError 1 2004-02-06
15:03:07 Invocation of Applet Menu New Service::NewTimeSheet is not
allowed.GenericLog GenericError 1 2004-02-06
15:03:07 Invocation of Applet Menu New Service::NewCommunication is
not allowed.GenericLog GenericError 1 2004-02-06
15:03:07 Invocation of Applet Menu New Service::NewCorrespondence is
not allowed.GenericLog GenericError 1 2004-02-06
15:03:07 Invocation of Search Client Service::OpenSrchCenter is not
allowed.GenericLog GenericError 1 2004-02-06
15:03:07 Invocation of Persistent Customer Dashboard::OpenDashboard
is not allowed.GenericLog GenericError 1 2004-02-06
15:03:07 Invocation of Persistent Customer Dashboard::ClearDashboard
is not allowed.GenericLog GenericError 1 2004-02-06
15:03:07 Invocation of Persistent Customer Dashboard::CloseDashboard
is not allowed.GenericLog GenericError 1 2004-02-06
15:03:07 Invocation of Search Client Service::AutoSearch is not
allowed."
If we finally refresh the screen for the third time, we could finally get into the application.
Can you Please get back to us as soon as possible because this is seriously affecting our production environment.
Cause
Configuration/ Setup
Solution
Message 1
For the benefit of other readers:
The customer had to refresh the browser three times before the Siebel Application login page would load.
We
initially determined that the cause of this problem was experienced
outside of the scope of the Siebel Application, as the customer
experienced the same behavior when attempting to display the default
page of their Web Server.
It was determined that the customer was
using a Cisco switch, configured with a Virtual IP address (VIP), to
load balance two Web Servers. The initial page loading problem only
occured when the client connection hit the VIP - if the client went to
the Web Server specific URLs, the pages loaded on the first hit.
The load balanced configuration on the switch was verified as correct.
It
transpired that one of the Web Server's Network cards did not have a
Default Gateway Server IP Address. This was determined by running
ipconfig on that machine. After providing the Default Gateway Server
value and restarting the IIS Services, the initial hit and thus
rendering the Siebel Login page, worked when using the VIP based URL.
Applies to:
Siebel CRM - Version 7.8.2 [19213] to 8.1.1 SIA [21111] [Release V7 to V8]
z*OBSOLETE: Microsoft Windows Server 2003
Product Release: V7 (Professional) and later
Version: 7.8.2 [19213]
Database: Microsoft SQL Server 2005
Application Server OS: Microsoft Windows 2003 Server
Database Server OS: Microsoft Windows 2003 Server
This document was previously published as Siebel SR 38-3304776353.
*** Checked for Relevance on 11-Sep-2012 ***
Symptoms
SBL-NET-01023, SBL-SCB-00011, SBL-SSM-00004, SBL-SSM-00006
We have launched Siebel today. Users are seeing 4 problems:
1. Server busy or problem experienced browser error
2. White screen with progress bar
3. Siebel splash screen with progress bar (no login box)
4. Users get into the system and then get booted out.
When first launched, we had serious avaikability issues as above.
We then changed the following settings:
1. MAX TASKS params for all object managers from 20 to 100 (as recommended in PRR) except fo UK OM which was changd to 200.
2. MAX TASKS for connection broker from 1 to 2.
Since these changes users have been able to access, but within last 1 hour we have again seen the same issues.
Cause
Encryption for the communication between Siebel web server and Siebel servers is set to MSCRYPTO
Solution
Message 1
As per the client description their siebel web client became unavailable at certain times.
After investigations the symptoms were found to be as follows:
On the siebel application server there was a siebmtshmw process that
became to use 100% CPU. This process did not became unresponsive but
instead to became idle when no requests where processed it went to
100%CPU. On a 4 processor box when there were 4 siebmtshmw processes
that went in this state the machine begun to respond very slow this
resulting in dropping new sessions and overall log responses to
incomming requests.
On the web server machine (IIS) there was present the same situation
(the siebel extensions out of process begun to consume 100%CPU)
The thread that consumed CPU was identified from the performance monitor
logs and then core dump where taken from these processes. The thread
was a communication thread between the siebel web extensions (SWSE) and
object manager (OM). The call stack for the corresponding thread was:
sslcnapi!compress_write+0xdb
sslcnapi!zlib_inflate+0x8d
sslcnapi!CSSSISConn::_DecodeRawMsg+0x158
sslcnapi!CSSSISConn::SisAsyncThreadMain+0x8d
sslcosd!OSDThreadStart+0x1c0 sslcosd!OSDNTThreadStart+0xc
msvcr70!beginthreadex+0xba
kernel32!GetModuleFileNameA+0xeb
...
The relevant line in the communication call stack is
CSSSISConn::_DecodeRawMsg. The customer had the encryption for the
communication set to MSCRYPTO. This encryption is not largely used or
recommended by Siebel. After setting the encryption to NONE the problem
did not re-occurred.
Resolution:
The customer choose to check if they need encrypted communication
between the web server and the application servers and if this is the
case use SSL instead.
Applies to:
Siebel System Software - Version: 7.5.3.6 [16186] to 8.1.1.3[21219] - Release: V7 to V8
z*OBSOLETE: Microsoft Windows 2000
Product Release: V7 (Enterprise)
Version: 7.5.3.6 [16186]
Database: Microsoft SQL Server 2000
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-1657913758.
Symptoms
Hi,
We are trying to renew the certificates, which will expire
on 12/22/05, for SSL encryption on our Siebel Enterprise Server. Before
implementing the new certificate to production, we are testing the
process in QA environment. We replaced the old certificate file,
certificate authority file and private key file with the new certificate
files on Siebel Server and SWSE (Web Server), but we have connection
issue. Please advise.
Attached please find the swse logs, eapps.cfg and siebns.dat. Please let me know if you need any other information.
Thanks!!
Cause
SBL-NET-01562: Unable to load private key D:\SSL\365key.pem
Solution
For the benefits of other users:
Customer is trying
to renew the certificate which is used for SISNAPI SSL encryption on
the Siebel Enterprise Server. SWSE log reported following error.
SBL-NET-01023: Peer disconnected
SBL-SSM-00004: SISNAPI Hello failed. The server component could be down.
SBL-SSM-00006: error sending message
Customer had been suggested to perform the following:
- Check and verify that the Object Manager is running.
- Increased the event logging for the correspondence Object Manager. Error below was reported on the Object Manager log.
SBL-NET-01562: Unable to load private key D:\SSL\365key.pem
Solution:
The
corrective action of the above error is to verify that the key is in
PEM format, and that the password for the key is correct. There is a
parameter named "keyfilepassword" which need to be set correspondence to
the password entered when generate the key. This parameter can be set
using srvrmgr command below.
srvrmgr /g gateway /e enterprise /s server /u username /p password
srvrmgr> change params keyfilepassword=<password> for server <server>
After setting the correct password, the system is backed up and running.
תגובות
הוסף רשומת תגובה