SBL-NET-01218: The connection was refused by server %1. No component is listening on port %sysError.

Applies to:

Siebel System Software - Version: 7.7.1 [18306] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows 2000

Product Release: V7 (Enterprise)

Version: 7.7.1 [18306]

Database: Oracle 9.2.0.4

Application Server OS: Microsoft Windows 2000 Server SP 4

Database Server OS: Sun Solaris 8



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

Symptoms

SBL-NET-01218Hi,

     Have managed to change DSConnectString from
"SiebSrvr_css77hkes" to "siebel" but still not working until I went to update the passwords again
for both sadmin and siebel from the Administration screen. Now all the services are running from
GUI. Refer to attachment. captured by using delicated web client.
20040816screen.doc

     However, I still can't login via web
client.(http://[Server Name]/fins_enu) It gives me the familiar 'sys busy message'. Refer to
20040816screen.doc
      a) I have checked the swse log, it
complains about login failed for GUESTCST. I have tried to login via sqlplus without problem.
Result shown in 20040816screen.doc. I have also launched "Siebel Web server extension
configuration" to re-configure it again but still with no luck. Have used: i) employment
anonymous login name/password=GUESTCST/GUESTCST; ii) Contact Login/Password=GUESTCST/GUESTCST;
web update projection key=GUESTCST.

      b) Had checked the
siebsrvr logs, have found a raft of errors on SBL-NET-01218 and SBL-SVR-01051. Tried to sync the
Components per stated in SR38-1358013887 but still in
vain.

     Attached are the logs and screen shot. In the zip file
of 20040816, you will find
     1) 20040816screen.doc : the screen
capture.
     2) eapps: contain eapps.cfg and eapps_sia.cfg. I can't
find eapps_fins.cfg and
eapps_sis.cfg as it stated in
eapps.cfg.
     3) siebns: the
siebns.dat.
     4) siebsrvr-log: the sibsrvr
logs
     5) swse-log: the swse log.

regards,

Cause

Change Request 12-O6HYF2

Solution

Message 1

For the benefit of the other,



Description:

Based on reviewing this behavior, there is incorrect port number in
ConnectString parameter in eapps_sia.cfg and there are some error
messages in FINSObjMgr_enu_26640.log.



Resolution:

1/ As per your ConnectString for fins_enu in eapps._sia.cfg, the port
number is different from SCBroker port number (default 2321). Therefore,
the unexpected behavior on connecting to Siebel Server with Web Client
is resolved after changing to port number 2321 same to SCBroker port
number.



ex)eapps_sia.cfg

[/fins_enu]

ConnectString = siebel.TCPIP.None.None://[Server Name]:2320/css77hke/FINSObjMgr_enu



For more information, please refer to Siebel Installation Guide for
Microsoft Windows:Servers, Mobile Web Clients, Tools Version 7.7,
Chapter 8. Installing the Siebel Web Server Extension, Configuring the
Siebel Web Server Extension, Configuring the Siebel Web Server
Extension;



“3. Enter the hostname for the Siebel Server and the port number
(default 2321) for the SCBroker component. Click Next and proceed to
Step 6."



For some incorrect port number examples on ConnectString parameter in
eapps.cfg file, Change Request 12-O1FMXZ has been raised to address the
Documentation Defect.



2/ As per error messages (SBL-NET-01218 and SBL-SVR-01051) in OM log
files, these are benign error messages. Change Request 12-O6HYF2 has
been raised to address these error messages.



Regards,

Applies to:

Siebel System Software - Version: 7.7.1 SIA [18306] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows 2000

Product Release: V7 (Enterprise)

Version: 7.7.1 [18306] Cons Goods

Database: Microsoft SQL Server 2000 SP3

Application Server OS: Microsoft Windows 2000 Server SP 3

Database Server OS: Microsoft Windows 2000 Server SP 3



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

Symptoms

SBL-NET-01218I'm currently trying to install a second Siebel server withing our test environment (to test so
that I can ultimately do the same in our production environment). The installation seems to go
OK, without errors. After installing, I can manually reassign component groups to the new server
in the Server Config Admin views. But after restarting the Siebel services on both servers and
synching the enterprise settings, I can't log in using the web client anymore (I've assigned the
object managers to the new server). I'm attaching the log files to this SR.

Some
specs:

SASN132 is our existing server, which runs the gateway server and the first siebel
server. SASN142 is our new server which runs our second siebel server.

I already went
through Troubleshooting steps 24, but that didn't help me any further.

Regards,

Cause

Configuration/ Setup

Solution

Message 1

For the benefits of other users:



Customer installed a second server and tried to assign the component
group to the second server. However, after restarting the servers, the
customer was not even able to login to the first server and it was found
that the reassignment of component group did not really succeed.



Resolution:



Review of the siebns.dat file showed that a server that was supposed to
be uninstalled still exists in the siebns.dat. After this uninstalled
server was removed from the siebns.dat by Siebel Technical Support and
was used to replace the existing siebns.dat, the customer was able to
connect to the first server. Please note that the siebns.dat file should
not be edited manually in a text editor.



However, the assignment of the components groups did not succeed. The
customer was then advised not to unassign the Component Group While the
Components are still running as indicated in Alert 1042 “Do Not Delete
Component Definitions or Unassign Component Groups While Components Are
Still Running”. In addition, the customer was also advised to restart
the Siebel Server System Service after assigning.



After restarting the service, the assignment of component group was
successful and the customer was able to establish connection to the
second server after making modifications to the eapps.cfg file.





Siebel Technical Support.

Applies to:

Siebel System Software - Version: 7.7.1 SIA [18306] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows 2000

Product Release: V7 (Enterprise)

Version: 7.7.1 [18306] Life Sci

Database: Oracle 9i

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-1558315001.

Symptoms

After we rebooted the server, we could not longer to access to siebel thru browser.

Here is the error we got:

"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.[10:03:02] "



Web server and app server are on the same machine.

We increased the log level on the SWEAPP, but we did not get any log
files. Obviously we cannot establish the connection between siebel
server and web servber.



I checked the permissions on the SWEAPP, and prior to reboot, we could login to siebel.



Please call me as there are no people who can wok with siebel, and install dedicated web client is not the option for us now.

Cause

Configuration/ Setup

Solution

Message 1

For the benefit of the reader:



The users were not able to login using thin client. The siebel web server log file has following errors:



*********

SessMgr    ConnOpen    3    0    2004-10-15 10:41:45     2536:
[SESSMGR]
Open(siebel.TCPIP.None.None://usdfswdsbl1:2321/SiebelDev/eMedicalObjMgr_enu,
60, 300) SisnTcpIp    SisnSockWarning    2    0    2004-10-15
10:41:46     2536: [TCPIP-client] connect() to usdfswdsbl1:2321 failed
(err=10061 | Connection refused.)
SessMgr    ConnOpen    3    0    2004-10-15 10:41:46     2536: [SMCONN]
Failed to open connection to
(siebel.TCPIP.None.None://usdfswdsbl1:2321/SiebelDev/eMedicalObjMgr_enu)
in 1 sec(s) GenericLog    GenericError    1    0    2004-10-15
10:41:46    (smconn.cpp (271) err=1801218 sys=2321) SBL-NET-01218: The
connection was refused by server usdfswdsbl1. No component is listening
on port 2321.

            *************



Also this log file has error

            ***************

GenericLog    GenericError    1    0    2004-10-15
11:18:34    (ssmsismgr.cpp (627) err=5600003 sys=0) SBL-SSM-00003: Error
opening SISNAPI connection.

SessMgr    ConnOpen    3    0    2004-10-15 11:18:34     2076: [SESSMGR]

Open(siebel.TCPIP.None.None://usdfswdsbl1:2321/SiebelDev/eMedicalObjMgr_enu,
60, 300) = [NULL, 5600003]

ObjMgrSessionLog    Error    1    0    2004-10-15 11:18:34    Login failed for Login name : sadmin

            *************



The root case of this behavior was determined as component “Siebel
Connection Broker” which was not running. After we enabled the component
and re-cycled the environment users were able to connect.

Applies to:

Siebel Life Sciences CRM - Version: 8.0.0.2 [20412] to 8.1.1.4 [21225] - Release: V8 to V8
Information in this document applies to any platform.

***Checked for relevance on 22-Mar-2011***

Symptoms

When trying to enable automation via Server Manager, the following error messages were returned :
srvrmgr> change param EnableAutomation=true for server ent_dev comp sccobjmgr_enu

SBL-ADM-60070: Error reported on server 'Gateway Server' follows:
SBL-SCM-00028: Key not found
SBL-SCC-00005: Internal:No more items found.
SBL-NET-01218: The connection was refused by server ctmsdevapp. No component is listening on port 49168.

SBL-SCM-00028: Key not found
SBL-SSM-00003: Error opening SISNAPI connection.
SBL-NET-01218: The connection was refused by server ctmsdevapp. No component is listening on port 49168.

SBL-SCM-00028: Key not found
SBL-SCC-00005: Internal:No more items found.
SBL-NET-01218: The connection was refused by server ctmsdevapp. No component is listening on port 49168.

SBL-SCM-00028: Key not found
SBL-SSM-00003: Error opening SISNAPI connection.
SBL-NET-01218: The connection was refused by server ctmsdevapp. No component is listening on port 49168.


change param EnableAutomation=true for comp sccobjmgr_enu
SBL-ADM-02077: Server name must be specified for this operation

Cause

A separate license is required for Siebel Test Automation module.

Solution

1. Verify that a Siebel Test Automation license is included as part of the license keys.



Alternatively, a temporary solution is to use the all-inclusive
license codes from http://licensecodes.oracle.com/siebel_master.html to
eliminate any issues with licensing.

2. Run the following commands in srvrmgr and restart the Siebel Server:

change param EnableAutomation=true for comp <component name>
change param AllowAnonUsers=true for comp <component name>

Restart Siebel Server.

In Windows, launch using http://hostname/eclinical_enu/start.swe?SWECmd=AutoOn
SiebelAx_Test_Automation_xxxxx.exe process should appeared in Task Manager.

Applies to:

Siebel CRM - Version: 8.1 [21039] and later   [Release: V8 and later ]
Information in this document applies to any platform.

Server busy error with custom OM -ACSWMTObjMgr_enu

Symptoms

When try get the Siebel login by using custom component - customer Object Manager -ACSWMTObjMgr_enu ,we get following error



http://10.203.168.143/acswmt_enu/start.swe?" URL getting the following error message:

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.[23:24:13]

In OM logs, these errors were found

 2009-10-11 23:07:37 Login failed for Login name : anonemp
 2009-10-11 23:07:39 (ctxtmgr.cpp (4504)) SBL-SVC-00208: Please login first

In SWSE logs, these errors where found

2009-10-11 22:53:16 ( (0) err=4653071 sys=0) SBL-SCB-00015: The component is down or not available on this server

2009-10-11
22:56:21 (smconn.cpp (283) err=1180866 sys=2321) SBL-NET-01218: The
connection was refused by server hcmblysun004a. No component is
listening on port 2321.

 2009-10-11 22:56:21 (ssmsismgr.cpp (773) err=3670019 sys=0) SBL-SSM-00003: Error opening SISNAPI connection.
 2009-10-11 22:56:21 (ssmsismgr.cpp (1761) err=3670022 sys=0) SBL-SSM-00006: Error while sending message to server.
 2009-10-11
22:56:21 (smconn.cpp (283) err=1180866 sys=2321) SBL-NET-01218: The
connection was refused by server hcmblysun004a. No component is
listening on port 2321.

Changes

Created custom Object manager -ACSWMTObjMgr_enu

Cause

Incorrect value for Siebel Repository File parameter



.

Solution

Setting the correct value for Siebel Repository File parameter resolved this issue. 

Applies to:

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

***Checked for relevance on 17-Feb-2012***

Symptoms

The Gateway daemon for Siebel Industry Applications version 8.1.1
running on IBM AIX 5.3 against Oracle 11g shows high CPU. This can be
observed after starting a Siebel server, which has a duration of 2-3
minutes. After the Siebel server has started the CPU of the Gateway
daemon reduces and stabilizes, however the Siebel Workflow components
fail after startup. If these failed components are restarted manually
via Siebel Server Manager then the CPU increases on the Gateway as
before.

ERROR MESSAGES

1. SBL-DAT-00173: An invalid key was entered.


2. SBL-NET-01218: The connection was refused by server %1. No component is listening on port %2.


3. SBL-SRB-00040: Cannot open asynchronous SISNAPI connection.


4. SBL-GEN-05009: Unable to connect to the gateway server.


5. SBL-SVR-00052: Internal: Invalid proc handle

Cause

Issue caused by extremely large SIEBNS.DAT which can be seen by the high
CPU in the gateway process originating from the reads performed by the
NSClient.

Bug 10643323 has been logged to address a Product
Enhancement Request so that the size of the SIEBNS.DAT does not grow
excessively and if it does then to provide means to reduce the size - in
particular removing event log level entries.

The large amounts of reads being performed by the NSClient are directly related to the high CPU observed on the gateway

Solution

To reduce the size of the SIEBNS.DAT, the following can be employed to resolve the issue:
1. Restore backup of SIEBNS.DAT after changing event log levels for large amount of server components
2. Remove unnessary component definitions

Applies to:

Siebel CRM - Version: 8.1.1.3[21219] and later   [Release: V8 and later ]
Information in this document applies to any platform.

Symptoms

On : 8.1.1.3[21219] version, System Admin



When attempting to access the sales application after performing new
installation of the siebel server on an existing enterprise, the
connection to the application was unsuccessful. The login to the
application was displaying the following error message:



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.



The SWSE log displayed the following error message:



GenericLog GenericError 1 000000024d371324:0 2011-01-19 13:11:24
(smconn.cpp (283) err=1180866 sys=2320) SBL-NET-01218: The connection
was refused by server hqsblt05. No component is listening on port 2320.

GenericLog GenericError 1 000000024d371324:0 2011-01-19 13:11:24
(ssmsismgr.cpp (626) err=3670019 sys=0) SBL-SSM-00003: Error opening
SISNAPI connection.

ObjMgrSessionLog Error 1 000000024d371324:0 2011-01-19 13:11:24 Login failed for Login name : SADMIN



The eSales Object Manager (OM) displayed the following error message:



ObjMgrLog Error 1 0000000a4d2e0ad0:0 2011-01-13 07:17:54 (oracon.cpp
(3246)) SBL-DBC-00107: An Oracle database error has occurred. Please
continue or ask your systems administrator to check your application
configuration if the problem persists.

GenericLog GenericError 1 0000000a4d2e0ad0:0 2011-01-13 07:17:54
(secmgr.cpp (2679) err=4597538 sys=0) SBL-SEC-10018: An Oracle database
error has occurred.

Please continue or ask your systems administrator to check your
application configuration if the problem persists.(SBL-DBC-00107)
ORA-12154: TNS:could not resolve the connect identifier specified



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

1. Perform the siebel server configuration by adding a new server to an
existing enterprise. Make sure that the existing siebel server in the
enterprise was configured with a different DSN name.

2. Complete the installation and configuration of the siebel server using the configuration wizard.

3. Try to access the eSales application OM

Cause

The cause of the issue was determined to be with the DSN name entry for
the Siebel enterprise which was pointing to the incorrect TNS names
entry.

The original siebel server in the customer environment
was first configured with sblt_internal and then changed. However, when
the second siebel server was configured in the same enterprise, the
default value during the siebel server configuration was taken which was
"sblt_internal" and this was causing the problem. Once the DSN value
was changed "SBA_81_TEST_DSN", the connection was successful and the
application was accessible. The following error in the log justifies the
fact that the issue was with the database connection and TNS names
file:



ObjMgrLog Error 1 0000000a4d2e0ad0:0 2011-01-13 07:17:54 (oracon.cpp
(3246)) SBL-DBC-00107: An Oracle database error has occurred. Please
continue or ask your systems administrator to check your application
configuration if the problem persists.

GenericLog GenericError 1 0000000a4d2e0ad0:0 2011-01-13 07:17:54
(secmgr.cpp (2679) err=4597538 sys=0) SBL-SEC-10018: An Oracle database
error has occurred.

Please continue or ask your systems administrator to check your
application configuration if the problem persists.(SBL-DBC-00107)
ORA-12154: TNS:could not resolve the connect identifier specified



Also, looking into the siebns.dat file, the DSN name was incorrect as
the value was pointing to "sblt_internal" which is an incorrect DSN
pointing to a non-existent TNS names entry.



[/enterprises/SBA_81_TEST/parameters/Connect]

Persistence=full

Type=string

Value="sblt_internal"

Solution

The solution action plan for the issue is as below:



1. Perform the installation/configuration of the siebel server on the existing enterprise.

2. Make sure that the DSN name for the new siebel server configuration
is the same as the existing siebel server on the enterprise.

3. Make sure that the tnsnames.ora file has the correct information
pointing to the correct value pertaining to the DSN name that has been
defined in the siebel configuration.

4. Once the configuration is completed, try to access the eSales application and make sure that the connection is established.

References

NOTE:476703.1
- What Are the Steps To Troubleshoot the Error Message: The Server You
Are Accessing is Either Busy or Experiencing Difficulties...in a Siebel
Web Client User Browser?

NOTE:507612.1 - ORA-12154: TNS:could not resolve service name

SBL-NET-01201: Internal: connect() failed: %1

Applies to:

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

Symptoms

Customer reported the following:

In our new Siebel TEST environment, 2 Application Servers failing with Handshake failed error.



This is newly built Siebel environment, we have multiple servers

Ntsydasu304 - gateway and app server

Ntsydasu303 - App Server

Ntsydasu1186 - App Server

Ntsydwbu117 - Web Server



The Siebel gateway is up and running, all the application servers are
started. But 2 application servers Ntsydasu304 and Ntsydasu1186 are
failing with handshake Failed error

Cause

The issue seems to be caused by either port number being used by
other non Siebel process, or the mapping between the hostname of the
servers and the IP addresses. This analysis was based on the fact that
when srvrmgr tried to communicate with the ServerMgr, it threw errors
below:


- Handshake(siebel://ntsydasu1186:49162/es_obfstsb1/servermgr/ntsydasu1186) on conn 0x3121330 ok

- connect() to ntsydasu303:49168 failed (err=10060 | Connection timed out.

- connect() to ntsydasu304:49168 failed (err=10060 | Connection timed out.

Solution

For the benefit of other readers:

It was suggested to the customer to try the following:

telnet ntsydasu1186 49162
telnet ntsydasu303 49168
telnet ntsydasu304 49168

It
is expected that the first one should be successful. If the 2nd and 3rd
are also successful, please shutdown the Siebel servers and run the
telnet again on the last 2 servers, to verify if other non Siebel
process is listening on port 49168.

If the second and third fails
or not responding, please try telnet the IP address. If successful,
then there seems to be problem with the host-IP mapping, please verify.



By following the above steps, customer was able to identify the
cause of the problem, They opened up all the required ports and the
problem could be resolved.

Applies to:

Siebel System Software - Version: 7.7.2.1 SIA [18353] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows Server 2003

Product Release: V7 (Enterprise)

Version: 7.7.2.1 [18353] Hi Tech

Database: Oracle 9.2.0.6

Application Server OS: Microsoft Windows 2003 Server SP1

Database Server OS: Sun Solaris 9



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

Symptoms

SBL-SMI-00033, SBL-NET-01201Hello,

In migrating from Siebel 6.3 to 7.7 the environment was taken from regional
servers one in the US and one in Sweden to a single Siebel server in Germany. The reason that I
have opened this SR is that we are having connectivity problems when users access Siebel from the
non European companies that did not exist in 6.3.

We are looking for suggestions on how to
trace this issue or solve this issue. Our users use VPN software to access the network and
therefore Siebel. We have problems with the connected clients but the are worse for Siebel Mobile
Web Clients. We have no Siebel Dedicated Web Clients.


Best regards-

Cause

Configuration/ Setup

Solution

Message 1

For the benefit of other readers. The customer found that during
synchronization over VPN several clients would experience disconnection.




Analysis of the log files on the client revealed the following:

SisnTcpIp    SisnSockWarning    2    0    2005-07-13 13:16:15     1380:
[TCPIP-client] connect() to 163.157.2.202:40400 failed (err=10060 |
Connection timed out.)

GenericLog    GenericError    1    0    2005-07-13
13:16:15    (commapi.cpp (298) err=1801201 sys=10060) SBL-NET-01201:
Internal: connect() failed: Connection timed out.

GenericLog    GenericError    1    0    2005-07-13
13:16:15    (commapi.cpp (298) err=1700175 sys=2) SBL-DCK-00175: Cannot
open connection to 163.157.2.202. The Synch Manager component on the
server is most likely unavailable.



These errors indicate a network related behavior and not a problem or defect with the Siebel Software.



After further troubleshooting we believed that possibly packets were being dropped due to size.



The customer was referred to SR # 38-743187351. Here is some additional information on this registry setting:

http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/Default.asp?url=/resources/documentation/Windows/2000/server/reskit/en-us/regentry/58752.asp





In addition the following suggestions were made and brought back to the Network group:



In order to test this theory out you can try a couple of things.



continued...

Message 2

continued...

1) Test if this may be an issue by changing the MTU setting as is
suggested in the SR on SW and the MS link provided. This is a client
side based fix. If the synch no longer fails after implementing the
change and a healthy connection can be established over and over then
you would have a good indication that this was the problem. A global fix
then would be required. This needs to be worked out by the Network
group in that case rather then going from Client PC to Client PC and
changing the setting.

2) You can try to run a 'netstat -a' during a synch session. A healthy
connection will have the value of ESTABLISHED or LISTENING. If you get a
value of SYN_SENT then this indicates a network connection problem and
most likely show that packets are being dropped.

3) DSL connections are more susceptible to this issue and it may be
possible to alter the MTU setting on the user's router. Again this is a
client side fix. You may get into the issue of user's having different
routers and setting so this approach is not as attractive.



Siebel Technical Support

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: Oracle 9i

Application Server OS: Microsoft Windows 2000 Advanced Server SP 4

Database Server OS: HP-UX 11i



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

***Checked for relevance on 11-NOV-2010***

Symptoms

SBL-NET-01201, SBL-SSM-00003


Hi,



We are experiencing occasional HTTP 500 errors with our Inbound HTTP EAI
interface. We have two web servers dedicated to EAI requests that are
load balanced using Windows 2000 NLB. These pass requests in a load
balanced Resonate environment to two application servers both of which
run the EAI Object Manager.



The vast majority of transactions are successful with each app server
processing 30,000+ tasks each day. However, both of our web server logs
show the following occasional error.

GenericLog
GenericError 1 2005-01-17 16:31:27 (smconn.cpp 5(367) err=1801201
sys=10060) SBL-NET-01201: Internal: connect() failed: Connection timed
out.

GenericLog GenericError 1 2005-01-17 16:31:27 (ssmsismgr.cpp 83(256)
err=5600003 sys=0) SBL-SSM-00003: Error opening SISNAPI connection

GenericLog GenericError 1 2005-01-17 16:31:27 Login failed for Login name : tibcoadmin

GenericLog GenericLog 0 2005-01-17 16:31:27 [3208] ERROR 3208: [SWSE] Open Session failed (0x6ce5) after 22.9520 seconds.

GenericLog GenericLog 0 2005-01-17 16:31:27 [3208] ERROR 3208: [SWSE]
Impersonate failed. Login failed attempting to connect to %1

GenericLog GenericLog 0 2005-01-17 16:31:27 [3208] ERROR 3208: [SWSE]
Set Error Response (User: tibcoadmin Session: Error: 00027877 Message:
Login failed attempting to connect to
siebel.TCPIP.None.None://10.97.251.155:2320/sbl01p/EAIObjMgr_enu)

GenericLog GenericLog 0 2005-01-17 16:31:27 [3208] ERROR 3208: [SWSE]
Error Child Messages : <0> Login failed attempting to connect to
siebel.TCPIP.None.None://10.97.251.155:2320/sbl01p/EAIObjMgr_enu<1>
Login failed. SBL-SSM-00003: Error opening SISNAPI connection

GenericLog GenericLog 0 2005-01-17 16:31:27 [3208] ERROR 3208: [SWSE]
HTTP Status 500 : Error The service request could not be processed.
Please check that the user name and password are correct, and that the
request format is correct





If the problem persists, please contact the system administrator to get
more detailed information and to check the system configuration.

GenericLog GenericLog 0 2005-01-17 16:31:27 [3208] ERROR 3208: [SWSE]
Login failed. SBL-SSM-00003: Error opening SISNAPI connection

This error happens approximately 30 times a day on each web server
and although this is a small % of total transactions it is important we
eliminate these errors.


At the times the errors occur, we have found nothing in the app
servers logs, nothing indicating a problem in the Resonate Message
console, none of our hardware is under load (every server has an
abundance of CPU and memory available), no indications of network
problems exist



We are also curious as to the time period it takes for the timeout. The
22.9xxx seconds consistently appears in our logs and are wondering where
this timeout is set. Is this configurable or this an internal value
with the SWSE?

Cause

recommended TCP/IP settings were not implemented.

Solution

Customer implemented the TCP/IP registry changes described by the EVT
tool on their web servers and application servers. After these changes
the timeouts was almost completely disappeared.



HTTP_INACTIVE_CONN_TIMEOUT and SERVER_INACTIVE_CONN_TIMEOUT parameters
only need to be set in each node (Machine) that is running Resonate in a
Siebel Enterprise application but EVT recommended them on Web Servers
too.

Change request # 12-SWZLYA has been logged to address this.



TCP* parameters are suggested for Windows platform and the information
is available about these parameters on the Microsoft site or What is true benefit, if any, of changing TCP registry parameters as recommended by EVT? (Doc ID 499134.1)



These parameters are important as Siebel Server must have network access
to other Siebel components, such as the Siebel Gateway Name Server, and
the Siebel Database server and SWEApps.

References

NOTE:499134.1 - Benefit of Changing TCP Registry Parameters as Recommended by EVT Utility

Applies to:

Siebel eConfigurator - Version: 7.8.2.8 SIA [19237] and later   [Release: V7 and later ]
Information in this document applies to any platform.

Goal

The set up at the customer’s end which are all on Solaris OS :

- The Production Environment has 4 Remote eConfigurator Servers (PRD_ISS1, PRD_ISS2, PRD_ISS3, PRD_ISS4)

- The following Parameters have been set on each of the 5 Production OMs (PRD_OM1, PRD_OM2, PRD_OM3, PRD_OM4, PRD_OM5):

* Product Configurator - Remote Server Name - PRD_ISS1;PRD_ISS2;PRD_ISS3;PRD_ISS4

* Product Configurator - Use Remote Service - True

Issue:

- We had a hardware failure of PRD_ISS4. The physical server was off-line.
- The OMs were still attempting to send requests to PRD_ISS4.
- The request was hanging on PRD_ISS4 for 4 minutes. This was causing 25% of Production user sessions to hang.

Questions for this:
Is this normal behavior? This is causing OMs dependent on the IIS session to hang.
Can we dynamically change this parameter to remove an IIS server from the pool?
Are there additional settings required to have this work correctly?
Let me know what needs to be rectified to prevent the 4-minute delay when a single eConfigurator server is offline.

The
issue is that Siebel Callcenter AppServers keep sending requests to an
ISS server that is no longer available. We need to develop a plan to get
a fix or workaround for this issue. Immediate questions are:

1) What is the recommendation on timeout value change? Is the timeout value change possible?

2) What does Oracle recommend in the case of another similar failure with one of the ISS servers becoming unavailable?

3)
Even with a lower timeout value, I suspect that we will still see a
delay and error with Callcenter trying to connect to the failed server.
How can this situation be avoided or minimized? (i.e. a patch with
smarter load-balancing mechanism?)

What we are seeing however
differs if the configurator server is down, as opposed to having just
the eConfigurator Component disabled.
ie eProdCfgTimeOut is set on the AOM to 5 seconds.
-
If the eCfg Server is shutdown we get a 4 minute timeout (user sees
this as a hang) before rerouting configurator session to another server.

- If the sCfg Server is online, but the Configurator Component is offline, we see the 5 second timeout.

Solution

EProdCfgTimeOut is the setting in Seconds that determines the
time for which the application server would try to initiate a connection
with the remote configurator server before returning error to user.
However, irrespective of the timeout setting, the requests would still
get routed to the remote server. This setting only determines for how
long it should try to contact the remote server before returning an
error.

Answers :

Regarding the timeout we need to distinguish between 2 scenarios:

1)
Siebel server is down but operating system is still up and running. In
this case parameter eProdCfgTimeOut is used to check whether a
connection can be made within the defined timeframe (i.e. 5 seconds).
Please note that here we still have a running tcp/ip stack (OS is up and
running) which can accept a connection and returns an error because of a
missing port (eCfg OM is down). So this will always work.

2)
This is the bad situation. The whole machine is down, away, destroyed,
not reachable etc. In this case no tcp/ip stack is running on the other
side and a tcp/ip request will simply wait for a specific time before it
returns with an error message. This is different for the used OS. For
Windows you have to wait around a minute. For Solaris about 3-4 minutes.
Anyway it is a OS parameter which can be changed but it is not a Siebel
parameter.

That's why we have this problem at customer’s side as they are using Solaris. There are some approaches for this issue:
a)
using a hardware balancer. This is not documented or tested. So we
cannot tell whether this will work for remote eConfigurator

b) changing the Solaris OS parameter for the tcp/ip timeout setting
Parameter = tcp_time_wait_interval
default 240000 (2MSL according to RFC 1122) = 4 minutes

Please
discuss this setting with Sun. You could change this to 10000. You will
find a description with google, i.e.
http://www.sean.de/Solaris/soltune.html#tcp_time_wait_interval

Additional Comments :

Whenever you see the error message

SBL-NET-01201: Internal: connect() failed: Connection timed out

in
the log file, then we are dealing with a network issue and not Siebel
issue. In this case we always see the delay, which is a TCP/IP issue and
Operating System dependent. This happens if the machine is down which
should answer.

Therefore, in your case, Siebel works fine. The
current issue is that the delay seems not to be reactive on your OS
specifications.
Again whenever we see error message "SBL-NET-01201:
Internal: connect() failed: Connection timed out" then this is not a
Siebel issue but a network issue (i.e. machine is down). In this case
the delay is dependent on the TCP/IP stack and it's implementation. This
is out of the control of Siebel and this is not an eConfigurator issue
anymore.

Therefore, if our earlier suggested parameter does not
show the effect it should, then kindly address this with a service
request in the Core Server Technologies area and also with Sun, as it is
a Solaris issue.

One of the possible solutions we discussed was
changing TCP/IP parameters but this has effect for the whole machine,
OS, and all software running on this machine. So this should be directly
discussed with Sun and customer as we can only discuss the part for
Siebel but a change of this parameter has effect for the whole machine
and systems installed here. Changing this parameter would probably need a
check of their network etc as well.


We have also raised an Enhancement Request # 10559309
to see if there is any possibility of addressing this in the long term.
Enhancement Requests are reviewed, prioritized and if found viable,
implemented in a future release.

Additional suggestion:

In cases when a machine is down and the administrator knows it, you may consider the following approaches:


a.) Remove the machine from network and put in a simple PC with the
same IP address. This should avoid 4 minutes time out problem.


b.) Try with Administration - Product > Cache Admin. The idea is
to set up the cache without using the broken machine. This would avoid
the time outs as well.
For more information about the Configurator
Caching please refer to Performance Tuning Guide 7.8 > Tuning Siebel
Configurator for Performance > Administering Siebel Configurator
Caching > Cache Management for Siebel Configurator
(http://download.oracle.com/docs/cd/B31104_02/books/PerformTun/PerformTunConfigISS13.html#wp1063160)

Applies to:

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

Symptoms

On : 8.1.1.5 [21229] version, System Admin



After installation and configuring Siebel application

the following error occurs.



ERROR

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

Server Status is "Handshake failed"


The following error appears on srvrmgr.log file :


SessMgr
ConnOpen 3 000000084f3e0040:0 2012-02-17 16:12:21 1: [SESSMGR]
Open(siebel://machine1:49174/mbprod/servermgr/machine1, 60, -1)

SisnTcpIp
SisnSockWarning 2 000000084f3e0040:0 2012-02-17 16:13:36 1:
[TCPIP-client] connect() to machine1:49174 failed (err=78 | Connection
timed out)

SessMgr ConnOpen 3 000000084f3e0040:0 2012-02-17
16:13:36 1: [SMCONN] Failed to open connection to
(siebel://machine1:49174/mbprod/servermgr/machine1) in 75 sec(s)

GenericLog
GenericError 1 000000084f3e0040:0 2012-02-17 16:13:36 (smconn.cpp (284)
err=1180849 sys=78) SBL-NET-01201: Internal: connect() failed:
Connection timed out

SisnTcpIp SisnSockDetail 4
000000084f3e0040:0 2012-02-17 16:13:36 1: [TCPIP-client] socket()
closed descriptor = 5 from :0 to :55452

SessMgr ConnOpen 3 000000084f3e0040:0 2012-02-17 16:13:36 1: [SESSMGR] Error closing connection object

SessMgr
MsgReceive 5 000000084f3e0040:0 2012-02-17 16:13:36 1: [SESSMGR]
CB: conn 0x0, url NULL, mbuf 0x0, mlen 0, err 3670029

SessMgr
SessMgrGeneric 4 000000084f3e0040:0 2012-02-17 16:13:36 1:
[SESSMGR] conn 0x0: found error code (3670029), error info (NULL)

SessMgr
ConnClose 5 000000084f3e0040:0 2012-02-17 16:13:36 1: [SESSMGR]
conn 0x0: ctx 0x20753b48, url 0x<?INT?> cleaned up

SisnapiLayerLog
Trace 3 000000084f3e0040:0 2012-02-17 16:13:36 1: [SISNAPI]:
releasing connection (0x20753e20), refCount = 0

SessMgr ConnOpen 3 000000084f3e0040:0 2012-02-17 16:13:36 1: [SESSMGR] Open has taken 74.9 seconds so far, timing out

GenericLog
GenericError 1 000000084f3e0040:0 2012-02-17 16:13:36 (ssmsismgr.cpp
(544536816) err=0 sys=-752920388) SBL-GEN-00000: (ssmsismgr.cpp:
544536816) error code = 0, system error = -752920388, msg1 = (null),
msg2 = (null), msg3 = (null), msg4 = (null)




STEPS

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

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


1. install siebel siebel application

2. configure

3. status is Handshake failed

Cause

Issue was caused by incorrect settings on hosts file

Solution

Customer resolved the issue , and updated the SR with the following information :


"The issue was resolved after rectifying the hosts file. It had two entries with two different IPs for the same hostname."

Thank you.

Oracle Product Support - Siebel CRM

 

SBL-NET-01034: The SISNAPI connection was closed by the peer

Applies to:

Siebel Finance Sales - Version: 8.1 SIA [21039] and later   [Release: V8 and later ]
Information in this document applies to any platform.

Symptoms

The customer upgraded their application from 8.0.0.5 to 8.0.0.9 and experienced the following issues:

a) The OM (Object Manager) stopped responding from time to time.
b)
All the logged in users were kicked out and no user could login
thereafter. The server busy error message was encountered and the
workaround was to restart the OM.



There were no exact sequence of steps to reproduce this issue. The error
was intermittent and was happening occasionally and whenever it
happened, it kicked out users and then no user could login.

The OM logs showed the following error:

SBL-NET-01034: The SISNAPI connection was closed by the peer

Cause

The customer was using Message Broadcast feature in their environment
and the issue was caused because of the incorrect parameter setting. The
problem was caused by the parameter "Application Enable Message
Broadcast Cache" setting which was reset to False. The customer was
using this setting to maintain keep alive.  Once the parameter was reset
to true, the issue was fixed.


The cause of the issue is justified as the bookshelf also mentions
something related to the parameter, however it does not explicitly
mentions that the OM will intermittently stop responding and the users
will be kicked off.



There are two methods for ways for the application to obtain the messages for display:



a) The default behavior is to have the messages read from the database
each time the message bar is refreshed. This method can adversely affect
performance if the message bar is set to refresh frequently.

b) Message Broadcast Caching stores messages in each application’s
object manager. The messages are then broadcast through the Service
Request Broker (SRBroker).



If this is not set to TRUE, it results in reads to the database.  That explains the traffic and the subsequent issues.

Solution

The following is the solution action plan for this issue:



1) Navigate to the Administration - Server Configuration screen > Enterprises view.

2) From the Enterprise Servers list, select the enterprise server that
runs the application whose message broadcasting settings you want to
modify.

3) Click the Component Definitions tab, then select a component whose Component Type value is Application Object Manager.

4) Select the Application Enable Message Broadcast Cache parameter in
the Component Parameters subview, and type the value as TRUE.

Applies to:

Siebel System Software - Version: 7.5.3.9 [16194] and later   [Release: V7 and later ]
Oracle Solaris on SPARC (64-bit)

Product Release: V7 (Enterprise)

Version: 7.5.3.9 [16194]

Database: Oracle 9.2.0.2

Application Server OS: Sun Solaris 8

Database Server OS: Sun Solaris 8



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

Symptoms

SBL-SVR-00027we lost accesses to the Server Admin screen and srvrmgr on multiple environment (dev, test,
staging, etc).

when accessing the server admin screen, we got error msg:
SBL-NET-01034:
The SISNAPI connection was closed by the peer

when accessing srvrmgr, we got
msg:
Connected to 0 server(s) out of a total of 1 server(s) in the enterprise

Failed to
connect server s3_intf_s1: Handshake failed

The srvrmgr.llog file shows:
2021
2006-02-07 10:11:35 2006-02-07 10:12:58 -0600 00000004 001 001f 0001 09
srvrmgr 29510 1
/u00/siebel/siebsrvr/log/srvrmgr.log 7.5.3.9 [16194]
ENU
GenericLog      GenericError    1       2006-02-07
10:11:35     (sasess.cpp 9(66
4) err=1801034 sys=0) SBL-NET-01034:
The SISNAPI connection was closed by the
pe
er
GenericLog      GenericError    1       2006-02-07
10:11:35     (sasess.cpp 9(66
4) err=902047 sys=0) SBL-ADM-02047:
Could not send SISNAPI
message
GenericLog      GenericError    1       2006-02-07
10:12:58     (sacmd.cpp 10(38
8) err=902049 sys=0) SBL-ADM-02049:
There is no connected server targeted for th
at
command
GenericLog      GenericError    1       2006-02-07
10:12:58     (sacmdl.cpp 29(6
71) err=902049 sys=0) SBL-ADM-02049:
There is no connected server targeted for t
hat command
$


(to be continued)

Cause

Configuration/ Setup

Solution

Message 1

(continuing...)



The enterprise log file shows:

...

ServerLog       ProcessExit     1       2005-12-07 14:31:27     S3SuspectAssigne

d46085     SBL-OSD-02010   Process exited with error - Process exited because of

a bus error (data alignment) SIGBUS

ServerLog       ProcessExit     1       2005-12-07 14:31:27     S3RouteNational

46090     SBL-OSD-02010   Process exited with error - Process exited because of

a bus error (data alignment) SIGBUS

ServerLog       ProcessExit     1       2005-12-07 14:31:27     IBSNCSTM

46088     SBL-OSD-02010   Process exited with error - Process exited because of

a bus error (data alignment) SIGBUS

ServerLog       ProcessExit     1       2005-12-07 14:31:28     IBSNEscalate

46087     SBL-OSD-02010   Process exited with error - Process exited because of

a bus error (data alignment) SIGBUS

...





(to be continued)

Message 2

(continuing ...)



The PSTACK of the coredump shows:

eagnmnsu257(ROOT)# pstack -F core.global.sun4u.eagnmnsu257.1138992838.5252.900.siebsess.7025

core 'core.global.sun4u.eagnmnsu257.1138992838.5252.900.siebsess.7025'
of 7025: siebsess 44 1
/u00/siebel/siebsrvr/admin/s3_dev_es.s3_dev_s1.shm 263 e

----------------- lwp# 1 / thread# 1 --------------------

b98c538c __1cJqeLicPath6FpkCpC_v_ (62656c2f, 62656c2f, 73696562, 73727672, 2f6d772f, 6c69623a) + 2c

----------------- lwp# 2 / thread# 2 --------------------

bfb1f090 _signotifywait (bf02c000, bfbe0b80, 0, bf6c0ef8, 2f, 7efefeff) + 8

bfb1a534 thr_errnop (0, 0, 0, 0, 0, 0) + 20

----------------- lwp# 3 --------------------------------

bf019300 private___lwp_cond_wait (bed65d98, bf02cd74, bf02c000, 0, 0, 4) + 8

bfb1cc8c _door_return (bed65cd8, bf00a380, 0, 0, 0, 0) + 68

----------------- lwp# 4 --------------------------------

bfb1cc34 _door_return (25, bf02c000, bf02d678, 3, bf02c000, 1) + 10

bf00a380 _lwp_start (bea0bd98, 0, 0, 0, 0, 0) + 18

bfb1a534 thr_errnop (0, 0, 0, 0, 0, 0) + 20

-------------------------- thread# 3 --------------------

bf00d9e0 _reap_wait (bf030988, 1e8fc, 0, bf02c000, 0, 0) + 38

bf00d738 _reaper (bf02ce08, bf032710, bf030988, bf02cde0, 1, fe400000) + 38

bf01b11c _thread_start (0, 0, 0, 0, 0, 0) + 40



(to be continued)

Message 3

Output of a truss on the srvrmgr is attached to this SR for your review.



Also, when we ran the odbcsql, we also got a core dump, the pstack is the same as the pstack for srvrmgr.



we are able to start the siebel servers and the callcenter OM, and
access screens other than the server admin screen. But the OM's with
SIGBUS do not work any more.



Even more confusing is that we we cold start (reboot the machines), the
error does not appear. However, this is not a acceptable solution.
Because we are running on Solaris machines, reboot the production won't
be thinkable.



If you can assist us in find and resolve the problems before we move to production, it's great.



Thanks,

Message 4

(1/2)



For the benefit of other readers:



It was found in the truss output and in the siebsrvr_xx.log logs located
in siebsrvr/log directory the error SBL-SVR-00027 error message found.
The error may be due to lack of file descriptors.



Based on above, the customer was recommended to follow the instructions
on the bookshelf below and adjust the kernel settings appropriately.



Siebel Server Installation Guide for UNIX > Tuning UNIX Operating
Systems for Siebel Installation > Tuning Siebel eBusiness
Applications for Solaris > Tuning Kernel Settings for Solaris



The kernel adjustments alleviated the problem for a while, but the SIGBUS error and core dumps start happening again.



Please, see below the findings that I have found about in the truss.out
file provided, within this file there is the _LD_LIBRARY_PATH value
used, as you can see below there is no reference for the
/u00/oracle/product/920/v64/lib32 directory, also it is repeating some
path directories some times. This is exactly what I would like to avoid
in the tests that I have asked you.



The LD_LIBRARY_PATH was reviewed and it was found a reference to the
Oracle 64 bit library directory. The customer was asked to remove the
reference to the Oracle 64 bit library keeping only the Oracle 32 bit
library as it is the only supported version of Oracle client libraries.



After removing the Oracle 64 bit library path from the LD_LIBRARY_PATH the SIGBUS error and core dumps did not appear anymore.

Message 5

(2/2)



The following is found in the Bookshelf > SIEBEL SERVER INSTALLATION
GUIDE FOR UNIX VERSION 7.5.3 JULY 2003 12-FN585F > Installing the
Siebel Server.



NOTE: Siebel applications support the Oracle 32-bit client, but if you
have installed the Oracle 64-bit client on your Siebel Server, you need
to add $ORACLE_HOME/lib32 instead of $ORACLE_HOME/lib to your
LD_LIBRARY_PATH (Solaris),SHLIB_PATH (HP-UX), or LIBPATH (AIX).



Kind Regards,

Applies to:

Siebel System Software - Version 7.8.2.3 SIA [19221] and later
Oracle Solaris on SPARC (64-bit)

Product Release: V7 (Enterprise)

Version: 7.8.2.3 [19221] Com/Med

Database: Oracle 9.2.0.7

Application Server OS: Sun Solaris 9

Database Server OS: Sun Solaris 8



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

Symptoms

SBL-DAT-00803, SBL-JCA-00317, SBL-SMI-00126, SBL-NET-01034


Hi,



We are experiencing two unexpected behaviors when attempting to log into eCommunications:



1) The Login Page is not displayed. "Page Cannot Be Displayed" error after about 10 minutes.

2) The Login Page is displayed, but "Page Cannot Be Displayed" error after attempting to log in.



We are able to access the database via a Dedicated Client and can use the ServerManager commands.

We have already tried bypassing all Load Balancers and the LDAP Server unsuccessfully.

We are currently getting JCA Connection errors from Portal to Siebel.

We are seeing excessive CPU for Kernal and IOWait.



We are seeing some discrepancies with the mounted file system.

After removing the Anonymous User *.spf file from the userpref directory, we started getting the Home Page.

However, the system attempted to create the new file but it has 0 byte,
and the file name convention is different, for example,
<username>&<application>.spf_<hostname>_14084_13.



This seems to be related to file access rights, but we made everything 777 and still get the same error.

We know that this UNIX machine had some problems with this mount point after a power outage, but we do not know the details.

We turned up logging for eComm and SCBroker and the logs stop just prior to getting access the UserPref file.



For eCustomer, it looks like we can connect via JCA for the initial
request (GetMDN), but then for the GetHierarchy we get an error and lose
the JCA connection:



[SIEBEL ERROR] [2007-05-25 12:25:55.892] [SiebelConnection(1230636829)]
Complex Account Hierarchy - Portal Services.GetHierarchyByUser FAILED on
Connection
(siebel.tcpip.none.none://<hostname>:2321/esblr/eCustomerCMEObjMgr_enu/!3.6e01.4893.46570dcc,
INT_PORTAL with message <com.siebel.om.sisnapi.RequestException>

<Error><ErrorCode>8236</ErrorCode> <ErrMsg>OMRPC
Request 4 on connection 18579 was abandoned after 60070 ms because it
timed out. (SBL-JCA-317) </ErrMsg></Error>

</com.siebel.om.sisnapi.RequestException>



Thanks!

Cause

Configuration/ Setup

Solution

Message 1

For the benefit of other readers:



Users are getting “This page cannot be displayed – Cannot find server or
DNS error” error message when trying to load the login page or after
providing username and password.



After deleting the User Preferences File, this behavior was resolved,
but the new user preference file was created with zero byte.

We have ruled out the possibility of this behavior being related to the
situation described in Alert 1025: Siebel Server Components That Read or
Write to Files on Solaris May Encounter Fopen() Behaviors.

We have checked all Operating System user limits.



After further investigation, customer found out that a lockd daemon
process was not running on the server where the shared Siebel File
System resides after the power outage.

All the other Siebel Servers have NFS mounts pointing to this server to access the shared File System.

Once lockd was started on that server, the behavior was no longer observed.



The following Service Requests helped troubleshooting this behavior:



    - Doc ID 504354.1: Unable to connect to Public Sector with SisnSockError

    - Doc ID 495979.1: Web client hangs when trying to login



Thank you,

Applies to:

Siebel System Software - Version: 7.8.2.2 [19219] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows Server 2003

Product Release: V7 (Enterprise)

Version: 7.8.2.2 [19219]

Database: Oracle 9i

Application Server OS: Microsoft Windows 2003 Server SP1

Database Server OS: Sun Solaris 9



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

Symptoms

SBL-SVR-01015, SBL-SVR-01043, SBL-SMI-00033, SBL-NET-01034, SBL-NET-01033, SBL-ADM-01044, SBL-SCB-00015, SBL-SCB-00011Hi,

Each night a cold DB backup is taken on each environment. This is affecting a number
of components on the Siebel server:

Transaction Processor
Transaction
Merger
Transaction Router
Server Tables Cleanup

These components need to be
restarted each morning as the backup is affecting them. I decided to use scripts to shutdown the
siebel server 15 mins before backup is taken and another to restart it in the morning. I have
tested these script on one environment and this works fine. On another environmnet the shutdown
script appears to hang (i.e batch job does not complete). All the parameters are correct as the
command would not run otherwise. I have attached the script and the log files at the time it
executed (01:45). As you can see from the log file at 06:00 created after the startup script is
executed, the server is still shutting down. Can you please inform me what the issue
is?

Kind regards

Cause

Configuration/ Setup

Solution

Message 1

For the benefit of other readers:



The customer's script:



D:\sea78\test\siebsrvr\BIN\srvrmgr /g UKGateway /e siebtest /s SiebTest1 /u sadmin /p password /c "shutdown appserver SiebTest1"



In review of the customer's component log files, we could see that there
was a problem with one or more components shutting down. As stated in
SupportWeb SR 38-1147657941 [Siebel Servers stick in "Shutting down"
state], the "shutdown appserver" command issued from the Server manager
command-line is a synchronous process, thus the command will block until
all tasks in the server have exited. There could be a problem stopping
one or more components, caused either by the components themselves, or
caused by the synchronous nature of the shutdown process (ie. one
component is waiting on a response from another component, or the Siebel
server - that may have already been shutdown).



The customer was recommended to use the Windows command, net stop. The net stop command is used as follows:



net stop <service>



For example:



net stop SiebSrvr



Which would stop the service called SiebSrvr.



Assuming you do not have any problem stopping your Siebel Server service
using the Windows' Services utility, then you should not experience a
problem with using the net stop command to stop the Siebel Server
service. You can schedule the command using the Windows command, at.



This information resolved this for the customer.



Regards,

Applies to:

Siebel System Software - Version 7.7.1 [18306] to 8.2.2.1 SIA[23012] [Release V7 to V8]
Information in this document applies to any platform.

Error Message Area:Networking Layer - NET

Version:Siebel 7.7

Purpose

This document is intended to provide cause and corrective action
information about Siebel Error Message SBL-NET-01034: The SISNAPI
connection was closed by the peer.

Scope

This document is informational and intended for any user.

Details

Explanation

The connection to the server has been explicitly closed by the
client. This may be due to server or client process termination. This
error could also occur in any Siebel Server component such as MQ or
Remote Synchronization, due to incorrect installation or a time out
condition.

Corrective Action

Investigate whether this error occurs for multiple clients on
different machines or for multiple server components. Determine the
steps that led up to the error and determine if a long period of waiting
or network interruption coincides with the error.



Depending on the cause, verify the installation requirements or verify network connectivity and re-attempt the operation.

Applies to:

Siebel Remote - Version: 7.5.3.4 [16180] to 8.1 [21039] - Release: V7 to V8
IBM AIX on POWER Systems (64-bit)

Product Release: V7 (Enterprise)

Version: 7.5.3.4 [16180]

Database: Oracle 8.1.7.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-1923792601.

Symptoms

SBL-GDB-00004, SBL-SMI-00024, SBL-SRB-00061, SBL-GEN-09103Hi,

I am running "GenNewDb" and immediately, I got this following
error.

srvrmgr:nytids007tst> start task for component GenNewDb

start task for
component GenNewDb
SBL-NET-01034: The SISNAPI connection was closed by the peer

When I
checked the "GenNewDb_xxxx.log",I can see the following error
message.

ContextInit     ContextInit     0       2005-04-18
23:15:50     SIEBEL_ASSERT_MODE =
0
GenericLog      GenericWarn     2       2005-04-18
23:15:50     (smisched.cpp 17(266) err=9103 sys=0) SBL-GEN-09103:
Parameter value
was never set (i.e. is
null)
GenericLog      GenericWarn     2       2005-04-18
23:15:50     (smisched.cpp 17(269) err=9103 sys=0) SBL-GEN-09103:
Parameter value
was never set (i.e. is
null)
GenericLog      GenericError    1       2005-04-18
23:15:50     (smisched.cpp 17(285) err=2100024 sys=0) SBL-SMI-00024:
Unable to lo
ad gennewdb

Please look into this ASAP as we need to provide the extract
to TAM for review.

Thanks & Regards

Cause

Missing siebel server files

a] \siebsrvr\lib\libgennewdb.so
b] \siebsrvr\dbtempl\sse_utf8.dbf

Solution

Message 1

1 of 2



For the benefit of other readers, the issue and resolution are as follows.



Issue Description:

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

When the GenNewDB was run, wither from the UI or from server manager, an
error occurred alomost immediately. In this case, customer ran from the
server manager prompt as follows. Customer encountered errors as
described below.



srvrmgr:nytids007tst> start task for component GenNewDb



start task for component GenNewDb

SBL-NET-01034: The SISNAPI connection was closed by the peer



When I checked the "GenNewDb_xxxx.log",I can see the following error message.



ContextInit     ContextInit     0       2005-04-18 23:15:50     SIEBEL_ASSERT_MODE = 0

GenericLog      GenericWarn     2       2005-04-18
23:15:50     (smisched.cpp 17(266) err=9103 sys=0) SBL-GEN-09103:
Parameter value

was never set (i.e. is null)

GenericLog      GenericWarn     2       2005-04-18
23:15:50     (smisched.cpp 17(269) err=9103 sys=0) SBL-GEN-09103:
Parameter value

was never set (i.e. is null)

GenericLog      GenericError    1       2005-04-18
23:15:50     (smisched.cpp 17(285) err=2100024 sys=0) SBL-SMI-00024:
Unable to lo

ad gennewdb



Resolution:

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



After detailed analysis, Siebel Technical Support discovered the following.



1. Customer environment was missing the following files



a] \siebsrvr\lib\libgennewdb.so

b] \siebsrvr\dbtempl\sse_utf8.dbf



Contd...

Message 2

2 of 2 - Contd from previous..



Customer had another environment similar to this one, where everything
was working. Since this non working environment was a test environment
and not a production environment, Siebel Technical Support recommended
copying the missing libray file \siebsrvr\lib\libgennewdb.so and
\siebsrvr\DBTEMPL\sse_utf8.dbf from the working environment.



After the copy was done, customer restarted the siebel server and gateway and ran the GenNewDB and it worked successfully.



Recommendations:

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



Other recommendations made to the customer were as follows



1. Refer Alert 899: Maintenance Level Update Recommended for AIX 5L v5.1



According to the Alert 899, which refers Alert 851, Customers have to
ensure Siebel deployment is running the latest C++ runtime libraries
(6.0.0.12) or later, if they are on AIX 5L v5.1



2. Other recommendation made was to not copy missing files, if the
environment is production. If missing files are noticed in production,
then for long term stability, customers must consider reinstallign their
Siebel environment.



Thank you

SBL-NET-01023: Peer disconnected

Applies to:

Error Message Area:Networking Layer - NET

Version:Siebel 7.5.3

Purpose

This document is intended to provide cause and corrective action
information about Siebel Error Message SBL-NET-01023: Peer disconnected

Scope

This document is informational and intended for any user.

SBL-NET-01023: Peer disconnected

Explanation

The server has closed the network connection.



Below is a list of common causes for the error message:



1. The Web Server's Network cards did not have a Default Gateway Server IP Address configured correctly.



2. The 3rd party network connectivity software installed on the Siebel
server machine (for example Oracle's SQL*Net software and Resonate), was
not installed correctly. Additionally, the customer was encountering a
"Handshake Failed" error when trying to access the Server Administration
screens and one of the Siebel Object Managers had crashed and produced a
call stack.



3. Resonate is used for load balancing and the customer is using a
Network Interface Card (NIC) that is not certified. Additionally, the
customer has configured to use IPMP (Internet Protocol Network
Multipathing).



4. The customer had configured their Siebel application to allow for
anonymous browsing however the Anonymous Employee account GUESTCST was
not defined in the database. (Note: GUESTCST is only one possible user
name for anonymous browsing). Check the eapps.cfg file and see what
values you have defined for the AnonUserName parameter. Verify the
database user account exists in the Siebel database.



5. Resonate is used for load balancing between multiple Siebel servers
and some of the Resonate parameters and environment variables are not
configured correctly for example "Heartbeat Until down" and
RES_PERSIST_BLOCK_SIZE.

Corrective Action

Check the network configuration and restart the server process if necessary.



Below are some additional corrective actions to review and confirm:



1. Confirm the IP addresses are correct by running the ipconfig command
on the Web server machine. [Note: ipconfig exists on Windows machines
only - ifconfig may be required on UNIX machines]. Make any necessary
changes and restart the Siebel Web Server and IIS Services.



2. Use the Environment Verification Tool (EVT) to confirm that the 3rd
party network software is certified and installed properly. For
information about EVT, refer to Technical Note 467 or Siebel Bookshelf
version 7.7 > Siebel Installation Guide for (Microsoft Windows OR
UNIX): Servers, Mobile Web Clients, Tools > Verifying Your System
Using the Environment Verification Tool. If you are using Resonate for
load balancing, confirm it is installed and configured properly. You can
refer to Technical Notes 316, 543 and 419 for installation and
troubleshooting information on Resonate. Check the SRSP for a list of
certified versions and check the installation log files for any errors.
Reinstall the software if necessary.



3. If Resonate is installed, confirm the NIC card is certified by
reviewing the NIC Support Matrix document found on SupportWeb under
Product Documentation > Siebel System Requirements and Support
Platforms Guide & Miscellaneous Documentation > Network Interface
Card Support Matrix. Disable IPMP if it is enabled.



4. Make sure the value for the AnonUserName parameter exists in the
Siebel database. Or try setting the AnonUserName value to an account
that you know exists in the Siebel database. For more information, refer
to the following Siebel Bookshelf references:



- Siebel Bookshelf version 7.7 > Security Guide for Siebel eBusiness
Applications > User Administration > Configuring Anonymous
Browsing > Implementing Anonymous Browsing.



- Siebel Bookshelf version 7.5.3 > Security Guide for Siebel
eBusiness Applications > User Administration > Unregistered Users
and Anonymous Browsing > Implementing Anonymous Browsing.



5. For more information about troubleshooting and configuring Resonate, refer to Technical Note 419, 316 and 543.

Applies to:

Siebel System Software - Version: 7.8.2.3 [19221] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows Server 2003

Product Release: V7 (Enterprise)

Version: 7.8.2.3 [19221]

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-3196279459.

Symptoms

SBL-MBL-02087, SBL-MBL-00211, SBL-OMS-00203, SBL-SVR-01014, SBL-NET-01023We have installed SSSE in our acceptance environment, by following exactly the same process, we
try to install it into our production environment but it fails because the PIMSI Engine component
remains unavailable.

I join the log file to the SR

Cause

Configuration/ Setup

Solution

Message 1

For the benefit of other users:



Customer installed SSSE in their acceptance environment without any
problems but when they tried to install it into their production
environment, by following exactly the same process, it failed because
the PIMSI Engine component remained unavailable.



We found following errors in PIMSIEng*.log.



“An existing connection was forcibly closed by the remote host (peer)”.



SBL-NET-01023: Peer disconnected

SBL-SVR-01014: Internal: Could not send the HELLO message: (null)



SBL-MBL-51024: Opened compound file: \\MSAPP024P\WINSHARE\pimsimon.exc.

SBL-MBL-00211: Method GetRunningApps (), Error = 0x8000401A.

SBL-MBL-00211: Method RefreshAppMap (), Error = 0x8000401A.

SBL-MBL-02087: Exchange 2000 connector failed to initialize. Error = 0x8000401A.

DataMgr: Connector Manager Failed to load the connectors ErrCode: 0x7d3

SBL-OMS-00203: Error 2008 invoking method "BusSvcMgrInit" for Business Service "PIMSI Engine Service"

“Terminate process due to unrecoverable error: 4300203. (Main Thread)”



According to the Error messages knowledge base, following are the causes and corrective actions for these errors:



==================================================================

SBL-NET-01023

Cause: The server has closed the connection.



Corrective actions: Restart the server process if necessary and check the network configuration.



SBL-SVR-01014

Cause: SISNAPI hello failed. %1 in the error message is replaced by the ...





Cause: SISNAPI hello failed. %1 in the error message is replaced by the error code from the SISNAPI layer.



Corrective actions: The error is meant for internal diagnostic and
debugging by Siebel Engineering. If you encounter it, please contact
Siebel Technical Support.

=====================================================================



We got customer to check whether they have experienced any Network
problems in their environment before encountering these errors and also
whether they have any major differences between their acceptance
environment and the production environment.



Customer checked and confirmed that in the security setting for the dcom
object, the domain was missing into the user name and by adding this
domain to the user the PIMSI Engine component started correctly and
stayed in available status and the behaviour is resolved with this.



Thank you.



Oracle | Siebel Technical Support



Keywords: SSSE, PIMSI Engine component, unavailable, SBL-NET-01023,
SBL-SVR-01014, SBL-MBL-51024, SBL-MBL-00211, SBL-MBL-02087,
SBL-OMS-00203.

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 System Software - Version: 7.5.3.5 [16183] to 8.1.1.3[21219] - Release: V7 to V8
z*OBSOLETE: Microsoft Windows 2000

Product Release: V7 (Enterprise)

Version: 7.5.3.5 [16183]

Database: Oracle 9.2.0.4

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-1490194987.



***Checked for relevance on 20-Oct-2010***

Symptoms

Hi,
   I have configured the Web Server , Siebel Enterprise and
Siebel Server to communicate using SSL. But it doesn't seem to be able
to connect from the Web Server to the Enterprise and Server.
I get this error below.

User : SADMIN Attempting ( 7) to open a session ...
SSL not supported by server, failing connection.
SBL-SSM-00003: Error opening SISNAPI connection
Login failed for Login name : SADMIN
[SWSE] Open Session failed (0x6ce5) after      0.0057 seconds.

In
the Bookshelf, Security Guide for eBusiness Applications, on Page 70,
It mentions to Set the Additional Name Server Parameters for Siebel
Server SSL.

I am unclear on how to perform this. As there are no clear instructions.
We are using the "ePharma Object Manager (ENU)".
I tried to set the "Is Using Secure HTTP Connection = TRUE " but the value cannot be commited.

Please help.

Cause

Incorrect SSL setup.

Solution

For the benefits of other users:

Customer intends
to configure SSL for Siebel Enterprise and Siebel Server and set the
parameter "Communication Transport” to “SSL” for the respective Object
Manager. Error “SBL-NET-01023: Peer disconnected” reported.

Solution:

The
root cause of the issue is customer just rename the *.cer file
generated by Win2k Certificate Authority to *.pem file. It is documented
in Security Guide for Siebel eBusiness Applications that
1) Certificate files must use either ASN (Abstract Syntax Notation) or PEM  (Privacy Enhanced Mail) format.
2) Private key files must use PEM format.

You
can't just rename the file name to .pem extension as the format of the
certificate file is encoding with different method. There are some tools
available on the Internet that can help to do the conversion; one of
the tools is Win32OpenSSL.

After corrected the certificate and
private key files; customers are able to connect and login with SSL
enabled. However, errors “SBL-NET-01559: Internal Error: CN entry does
not match hostname” reported in SWSE log.

This benign error
indicated that the value entered for common name when creating a new
certificate does not match the actual hostname. The normal practice for
web server certificate is it will tie to the actual hostname and there
should be a valid DNS entry. The error can be ignored and if there is
concern please generate a new certificate and enter the actual hostname
when prompted for the common name.

Thank you,

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.