Search This Blog

Showing posts with label SBL-SSM-*****. Show all posts
Showing posts with label SBL-SSM-*****. Show all posts

SBL-SSM-00044: Virtual host is invalid.

Applies to:

Siebel System Software - Version 7.7.2 [18325] to 8.2.2 SIA[22320] [Release V7 to V8]
z*OBSOLETE: Microsoft Windows 2000
Product Release: V7 (Professional)
Version: 7.8.2.3 [19221] FRA
Database: Oracle 9.2.0.6
Application Server OS: Microsoft Windows 2000 Server SP 2
Database Server OS: HP-UX 11i




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

Symptoms

SBL-SSM-00044, SBL-SSM-00006

During benchmark tests to simulate login of numerous users, we experienced that after reaching one limit, no connections are allowed anymore. (the limit is not the same for each test)

The contengency seems to be at Web Server level, the connection attempt doesn't reach the Siebel Server.
The following error were reported in the SWSE logs:
Code= SBL-SSM-00044: Virtual host is invalid.


Solution

Message 1

The error message "SBL-SSM-00044: Virtual host is invalid" usually points to a problem with the configuration of the eapps.cfg file or lbconfig.txt file used for load balancing.

It was found that the Server SIDs in the Session Manager Rules under Section One of the lbconfig.txt file required reconfiguration. To verify the correct Server SIDs log into Server Manager at the enterprise level. Then run the following command to output the IDs

srvrmgr> list server show SBLSRVR_NAME, SV_SRVRID

More details on how to structure the lbconfig.txt file can be seen in the document "Siebel System Administration Guide > Structure of the lbconfig.txt File" on SupportWeb.

The customer was implementing Siebel Native Load-Balancing however they had configured Section Two of the lbconfig.txt file which is only used for Third Party Load Balancer Rules, so they also removed these references.

Following these changes there were no more errors experienced.




Applies to:

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

Symptoms

When running BI Publisher reports it was found that normal reports run from the UI would execute completely but that scheduled reports would fail.

Upon examination of the BI Publisher xdo.log the following error messages could be found :
[090811_090327227][][STATEMENT] initConfig(): config file used :null
[090811_090327227][][STATEMENT] initCustomFactories(): loading custom delivery channels :{}
[090811_090327228][][STATEMENT] initConfig(): config input stream was used.
[090811_090327228][][STATEMENT] initCustomFactories(): loading custom delivery channels :{}
[090811_090327228][oracle.apps.xdo.delivery.DeliveryManager][STATEMENT] initConfig(): loading default properties :{}
[090811_090327228][][EVENT] SiebelValidator(Properties prop)
[090811_090327229][][EVENT] endpoint:http://siebel.oracle.com/bipeai_enu/start.swe?SWEExtSource=WebService&SWEExtCmd=Execute
[090811_090327229][][EVENT] adminUsername:SADMIN
[090811_090327230][][EVENT] adminPassword:********
[090811_090327230][][EVENT] Endponit contains no UserName or Password, appending it with Admin's
[090811_090327243][][EXCEPTION] AxisFault
faultCode: {http://xml.apache.org/axis/}HTTP
faultSubcode:
faultString: (500)Internal Server Error
faultActor:
faultNode:
faultDetail:
{}:return code: 500
<html><head><title>Message:</title></head>
<body><h1>Message:</h1>
<p>An error occurred while trying to process your request. This error indicates a problem with the configuration of this server and should be reported to the webmaster (along with any errors listed below). We apologize for the inconvenience</p>
<p>Error(s):<ol><li>Login failed attempting to connect to siebel.TCPIP.None.None://ABC:1534/xyz/BIPEAIObjMgr_enu<li>Login failed.
SBL-SSM-00044: Virtual host is invalid.
</ol></p>
</body></html>
{http://xml.apache.org/axis/}HttpErrorCode:500

(500)Internal Server Error
at org.apache.axis.transport.http.HTTPSender.readFromSocket(HTTPSender.java:744)
at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:144)
at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
at org.apache.axis.client.AxisClient.invoke(AxisClient.java:165)
at org.apache.axis.client.Call.invokeEngine(Call.java:2784)
at org.apache.axis.client.Call.invoke(Call.java:2767)
at org.apache.axis.client.Call.invoke(Call.java:2443)
at org.apache.axis.client.Call.invoke(Call.java:2366)
at org.apache.axis.client.Call.invoke(Call.java:1812)
at com.siebel.apps.shared.xmlp.security.BIPSiebelSecurityWSPortStub.authenticate(BIPSiebelSecurityWSPortStub.java:298)
at oracle.apps.xdo.security.SiebelValidator.validate(SiebelValidator.java:124)
at oracle.apps.xdo.servlet.security.SecurityManagerImpl.getSiebelPrincipal(SecurityManagerImpl.java:1366)
at oracle.apps.xdo.servlet.security.SecurityManagerImpl.impersonate(SecurityManagerImpl.java:496)
at oracle.apps.xdo.servlet.scheduler.XDOJob.execute(XDOJob.java:325)
at org.quartz.core.JobRunShell.run(JobRunShell.java:195)
at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:520)

[090811_090327245][oracle.apps.xdo.servlet.scheduler.XDOJob][EXCEPTION] [ID:651] Unexpected exception occurred while running the job.
AxisFault

Cause

The xdo.log file shows the following error message being returned from the Siebel EAI Object Manager :
Login failed attempting to connect to siebel.TCPIP.None.None://ABC:1534/xyz/BIPEAIObjMgr_enu<li>Login failed.
SBL-SSM-00044: Virtual host is invalid.

From this it was confirmed that a custom EAI Object Manager was being used for which a custom virtual directory had been defined in the eapps.cfg file. Reviewing the configuration for this it was established that whilst the configuration showed that a VirtualServer should be used (through the 'EnableVirtualHosts=true' parameter) no VirtualServer existed in the lbconfig.txt with the name that was referenced in the ConnectString, in this case 'xyz'.



Solution

In order to resolve this behaviour it was necessary to ensure that the ConnectString for the virtual directory definition in the eapps.cfg included a reference to a valid VirtualServer definition in the lbconfig.txt

For further information on this topic please review the following documentation in the Siebel Bookshelf :
Siebel System Administration Guide > Configuring the System Architecture > Configuring Siebel Server Load Balancing





Applies to:

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

***Checked for relevance on 01-Mar-2013***

Symptoms


When load balancing is implemented, the following error is seen in the browser:
"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 following errors are reported in the SWSE log files:
SBL-NET-01020: Internal: unknown hostname
SBL-SSM-00044: Virtual host is invalid.

This occurs even when lbconfig.txt contains IP addresses instead of hostnames.

Changes

Implementing Load Balancing triggered the problem.

Cause

There is an error in the eapps.cfg file created by the SWSE installation. This has been identified in unpublished
Bug:10534386 VirtualHostsFile refers to lbconfig.cfg instead of lbconfig.txt

Solution

Making the following change to SWSE_ROOT/bin/eapps.cfg resolves the issue:

[ConnMgmt]

VirtualHostsFile = $(SWSE_ROOT)/admin/lbconfig.txt


That is, change lbconfig.cfg to lbconfig.txt and make sure that the path contains / instead of \. 

SBL-SSM-00006: Error while sending message to server

Applies to:

Siebel System Software - Version 7.8.2 [19213] and later
Information in this document applies to any platform.
Error Message Area:Session Manager - SSM
Version:Siebel 7.8


Purpose

This document is intended to provide cause and corrective action information about Siebel Error Message SBL-SSM-00006: Error while sending message to server.

Scope

This document is informational and intended for any user.

Details

Explanation

The above error is a generic message that is usually reported at times when an error occurs in the communication between the Siebel Web Server Extension (SWSE) and the Siebel Application Server. This error manifests itself in the SWSE logs files. To enable more tracing in the SWSE log files, refer to Document 477185.1 How To Turn Up Logging on the Siebel Web Server Extension in Siebel Versions 7.x and 8.x? for more information.

Below is a list of reported causes for this error message:

1. SWSE has incorrect information in the eapps.cfg file on how to connect to the object manager running on the Siebel Application Server. For example, the DoCompression parameter may not be set correctly and cause this error.

2. The object manager(s) on the Siebel Application Server are not running, or do not have sufficient resources to service new requests.

3. Possible incorrect settings for the parameters defined for the application object manager or for the ServerDataSrc Named Subsystem. For example, look at the Connect String which will be stored in the DSConnectString parameter of the ServerDataSrc Named Subsystem. For the application object manager, look at the parameter called Connect.

4. If external authentication is being used such as LDAP or ADSI, then make sure the external server is up and running and the username and password is correct.

5. The Web Server's Network cards did not have a Default Gateway Server IP Address configured correctly. This was determined by running ipconfig on that machine.

6. The customer had configured their Siebel application to allow for anonymous browsing however the Anonymous Employee account, in this example, GUESTCST was not defined in the database. NOTE: Any user name can be configured as the anonymous user to be used by the eapps.cfg file. Check the eapps.cfg file and see what you values you have defined for the AnonUserName parameter. Verify that the database user account exists in the Siebel database.

7. The Web Server had disk problems and on the client’s PC, the Siebel High Interactivity Framework (in versions prior to 7.7, it was called the IE Option pack) program file that was installed was damaged and caused the user to not be able to log into the Siebel application.

Corrective Action

Ensure that the server components are available and running with sufficient free tasks.

Below is a list of corrective actions for this error message. NOTE: The following bookshelf references are also applicable to the version listed in the header of this error message documentation:

1. Ensure that the connect string details and other information in the eapps.cfg file are accurate such as host name, application and enterprise server name, ports, VIP/IP addresses, sufficient anonymous user session settings, DoCompression, etc. For more information about these eapps parameters, refer to the Siebel Bookshelf > Siebel System Administration Guide > Structure of the eapps.cfg File.

2. Ensure the appropriate object managers on the Siebel server are running, and are configured properly as per the information in Document 476830.1 How to Configure Siebel Object Manager (AOM / SOM) in Siebel 7.x and 8.0.

3. Use the client GUI or the server manager command line utility to get the Connect or ConnectString parameters for the application object manager or the ServerDataSrc Named Subsystem respectively. Make any changes to these parameters if necessary. For more information, refer to the Siebel Bookshelf > Siebel System Administration Guide > Application Object Manager Administration > About Siebel Application Object Manager parameters > About AOM Named Subsystem Parameters.

4. For more information about external authentication, refer to Document 477424.1 What is the authentication flow when the standard LDAP/ADSI security adapter is being implemented for Siebel web client in Siebel 7.0 and 7.5? and Siebel Bookshelf > Security Guide for Siebel Business Applications > Security Adapter Authentication > About User Authentication.

5. Provide the Default Gateway Server value and restart the web services.

6. Ensure the Anonymous User account exists in the Siebel database, or try changing the AnonUserName value to another database account that you know exists. For more information about the anonymous user and browsing, refer to Siebel Bookshelf  > Security Guide for Siebel Business Application > User Administration > Configuring Anonymous Browsing > About Anonymous Browsing and Unregistered Users.

7. Fix the disk problems and remove any damaged program files on the client’s PC. Open a Web browser and go to Tools > Internet Options > Settings > View Objects to check the status of the Siebel High Interactivity Framework (IE Option pack) program file. To remove the damaged file, highlight the program file and click the delete button. Open a new browser and try to log into the Siebel application again.




Applies to:

Product Release: V7 (Enterprise)
Version: 7.5.3.3 [16172] Fin Svcs
Database: Oracle 8.1.7.4
Application Server OS: Sun Solaris 8
Database Server OS: HP-UX 11i

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

Symptoms

SBL-SSM-00006We are having problems viewing, and attaching files in Siebel. This problem started after we upgraded to 7.5.3.3. When we go to view or attach a file in Siebel (any area), and a new IE browser window is spawned, we receive an error (see attached "Error" file). When the file doesn't try to spawn a new browser window just the Siebel dialog box, the error doesn't occur. We haven't changed any code pertaining to file attachments, this problem just started happening after the upgrade.

Solution

Message 1

For the benefit of other users, the customer received error messages or had their connection to the Siebel Web Server time out when attempting to view or attach files in the 7.5.3.3 Siebel Zero Foot Print Web Client.

Summary:

The Siebel Web Server log files showed multiple occurrences of the error messages SBL-SSM-00039 and SBL-SSM-00006. Both these error messages are indicative of communication timeouts between the client and the Siebel Web Server. Furthermore, the SBL-SSM-00039 and SBL-SSM-00006 messages in the Siebel Web Server log files preceded a “SBL-SMI-00114: The Multithreaded Server has reached the maximum number of concurrent tasks ((null))” in the FinsObjMgr log file. Given these errors in the Siebel log files, it’s not surprising that the clients received the error message “The requested site is either unavailable or cannot be found.”  

Searching SupportWeb for assistance found Service Request #38-1144701021. The customer followed the resolution and unchecked the "Do not save encrypted pages to disk" security option checkbox via Internet Explorer Tools menu > Internet Options > Advanced tab > Scroll down to Security. This resolved the situation.

<Continued ...>

Message 2

<Continued ...>

However, as the customer wished to be able to view/add attachments with this box checked due to security concerns, Change Request 12-LVRDGH was raised with Engineering.

Regards,
Esther Small
Siebel Technical Support

Keywords: 12-LVRDGH, SBL-SSM-00006, SBL-SSM-00039, SBL-SMI-00114, The requested site is either unavailable or cannot be found, time outs, Do not save encrypted pages to disk




Applies to:

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

Symptoms

Environment :
-------------------

Siebel 7.8/8.x / Microsoft Windows 2003 R2 / Siebel Gateway in Clustered Environment.


Statement of Issue :
----------------------------
1)The issue is that the application errors out during the user working on it and then they need to relaunch a new web browser and then launch the application again.

2) The error screen is  "The server you are accessing is either busy or experiencing difficulties. Please close the web browser, start a new one and try logging in again " is populated

3) The Web Server and Siebel gateway response is slow.

The SWSE log files contained the following errors

1)GenericLog GenericError 1 00001a164dc80cdc:0 2011-05-09 19:07:54 (ssmsismgr.cpp (1761) err=3670022 sys=0) SBL-SSM-00006: Error while sending message to server.
2)SBL-NET-01204: Internal: recv() failed: (null)
3)SBL-SMI-00107: Internal: The context for the given task was not found.1*013*smimtpool.cpp3*8490*0*0*0*
4)Line 684167: ProcessPluginState ProcessPluginStateError 1 00003bac4dcf0ff4:0 2011-05-16 07:22:54 2276: [SWSE] Open Session failed (0xa600cb) after 19.2548 seconds.






Changes

Siebel Gateway's setting on the shared network drive are  troubleshooted so access of data is available from both of the network paths in the clustered environment.

Cause

The DNS and Network settings of the Web Servers are to be properly setup for Web Server routing to SWSE component and in between connection drops due to exceeding firewall idle timeout.

Following errors are also present at the SWSE component level

1)SBL-SSM-00006: Error while sending message to server
2)SBL-NET-01204: Internal: recv() failed: (null)
3)SBL-SMI-00107: Internal: The context for the given task was not found.1*013*smimtpool.cpp3*8490*0*0*0*

Solution


1)In the Siebel command line interface in order to be compliant with your internal firewall please set the following OM parameter:

change param connidletime=180 for comp <comp_name>

This will prevent connection drops due to exceeding firewall idle timeout.

Please also make sure to set the following event logs:

change evtloglvl EventContext=4 for comp <compname>

Then restart siebel service.

2) For SBL-SSM-00006 (ssmsismgr.cpp (1761) error , solution is The cfg file for the object manager does not exist under the SIEBEL_ROOT\siebsrvr\BIN\[LANG] directory. Copy another working cfg file to this directory and stop and restart the Siebel Server”

3) Check the DNS registry entries and Network settings.





Applies to:

Siebel System Software - Version 7.7.2 SIA [18325] and later
Oracle Solaris on SPARC (64-bit)
Product Release: V7 (Enterprise)
Version: 7.7.2 [18325] Com/Med
Database: Oracle 9.2.0.4
Application Server OS: Sun Solaris 9
Database Server OS: Sun Solaris 9

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


Symptoms

SBL-NET-01204, SBL-SSM-00006
HI,

Please look into this as an extremely urgent issue :-

We are facing some serious problem with our production environment, which is about to go live.

Our setup is;

Siebel 7.7.2 with QF 1007.

We use thin client only.
Around 20 + application server, out of which 8 have eCommunication Object Manager running on them.
3 Sunone web servers with SWSE plugin. CISCO load balancing switches between web & application servers & also between clients & web servers.

When we start the servers running eCommunication OMs, everything works fine for some time (1 or 2 hours).We can hit all 4 OM servers, can see user logged on each of them. But after some time we start getting server busy error as below.
“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.[16:41:34]”

We can still connect with server manager from command line & see all components
including eCommunication OM running.

If we bounce eComm OM servers, then again it works for some time.
The eCommunication OM logs on all servers have connection time out messages.

The log files from siebel web server extension & application server attached.

Cause

Configuration/ Setup

Solution

Message 1

For the benefit of other users:

The customer experienced server busy messages after a certain period of inactivity regarding network traffic between the web server and the application server. The customer has installed a Cisco hardware load balancer between the Siebel web extension and the object manager.

The reason for the interruption of the tcp connection was that Cisco switch is using a timeout feature by default that is dropping unused network connections after a while.

Resolution:

The following setup has resolved the problem with the dropped connections: the deployed Cisco model must support the flow-timeout-multiplier feature. This is not true for all types of Cisco switches. A model that supports this feature is CSS11503.
See an example for a rule implementing one application server:

owner siebelprod
content name-of-servcie
    add service app-server1
    vip address xx.xx.xx.xx
    advanced-balance url
    protocol tcp
    port 2321
    url "/*"
    flow-timeout-multiplier 700
    active

service app-server1
ip address xx.xx.xx.xx
keepalive port 2321
keepalive type tcp
string /!2.
active


The flow active multiplier will drop the connection after 11200 seconds idle time.

The object manager parameter connidletime has to be set to a slightly smaller value, 11000, to close and reopen the sisnapi connection properly.









Applies to:

Siebel CRM - Version 5.0.0.2 Finance 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 via
http://<web server hostname>/acswmt_enu
results in 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
Could not find 'Application' named 'Custom Application Name'. This object is inactive or nonexistent.
...

 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 parameter "Application Repository File" - this needs to reference an .srf that contains the Application used.

Solution


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

While the error messages above occurred on Siebel 8.1, the requirement to set the "Application Repository File" to the correct .srf name exists for all Siebel versions.




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



Applies to:

Siebel CRM - Version: 7.8.2.14 SIA[19251] and later   [Release: V7 and later ]
This problem can occur on any platform.

Symptoms


Statement of Issue:
-----------------------------
When access siebel throuth web UI, there is an error message pop up (server busy error).

Environment:
-------------------
7.8.2.14 SIA[19251]

Steps:
---------
1. Launch web client login to application (http://xx/econsumersector_enu/)
2. Server busy related error returned
3. Click refresh, login page displayed and login success

Error:
-------
The server you are trying to access is either busy or experiencing difficulties.

Expected Behavior:
---------------------------
Login page displayed without click on refresh.

Actual Behavior:
-----------------------
Error message below returned and only upon refresh login page displayed properly
The server you are trying to access is either busy or experiencing difficulties.

Business Impact:
-------------------------
Server busy error when launch web client login and need refresh intervention to get login page.

Cause


The cause of the issue is improper timeout setting.

SWSE log attached reported following error.

SisnTcpIp SisnSockError 1 0 2011-11-15 17:17:54 79: [TCPIP-client] recv() failed for sd=24 (err=145 | Connection timed out)
GenericLog GenericError 1 0 2011-11-15 17:17:55 (ssmsismgr.cpp (863) err=1801204 sys=0) SBL-NET-01204: Internal: recv() failed: (null)
GenericLog GenericError 1 0 2011-11-15 17:17:55 (ssmsismgr.cpp (1726) err=5600006 sys=0) SBL-SSM-00006: Error while sending message to server.

And timeout setting gather from customer as follow.

Firewall - TCP session timout : 3600 seconds  
eapps.cfg SessionTimeout      = 900
ALTEON switch timeout (in front of web server) is 10 minutes (600 seconds)

Refer "Frequent Connectivity Problem with Thin Client on Production error SBL-NET-01204 (Doc ID 527426.1)" for similar issue.

Solution


1) Review "Siebel Application Timeout Setting Guideline (Doc ID 838460.1)" for the recommended and guideline for timeout setting

2) Adjust timeout setting for Connidletime(AOM paramater), ALTEON switch and/or eapps.cfg SessionTimeout. For example, to keep the current ALTEON switch timeout setting to 600 seconds (10 minutes), adjust eapps.cfg timeout setting to 500 seconds and application object manager Connidletime parameter setting to 550.

Customer confirm issue resolved after implement the change suggested as above.


 



 

SBL-SSM-00005: Timeout occurred while opening SISNAPI connection

Applies to:

Siebel Communications CRM - Version 8.1.1.3 SIA[21219] and later
Information in this document applies to any platform.

Symptoms

Siebel 8.1.1.3 SIA[21219] is installed on IBM AIX on POWER Systems (64-bit)

Connected to srvrmgr at server level and "list comp" command is executed. Which resoluted in below errors:

SBL-SCM-00028: Key not found
SBL-SSM-00005: Timeout occurred while opening SISNAPI connection.



Changes

 No changes were happened and evevry thins was working as expected

Cause

srvrmgr might show SBL-SSM-00005 or SBL-ADM-02049 errors when trying to run simultaneously.

Solution

Rebooting all application servers including gateway resolved the issue.






Applies to:

Siebel System Software - Version 8.0.0.9[20433] and later
Siebel CRM - Version 8.0.0.9[20433] and later
Information in this document applies to any platform.

Purpose

This note is only applicable to version Siebel 8.0.0.9 and 8.1 and above, and illustrates troubleshooting steps including a workaround for the behavior described in the following alert:

Siebel Connection Broker May Be Blocked by a Hanging Object Manager Process Document 473950.1.

The scenario that SCBroker can not connect a new session to an existing object manager process because this process itself is hanging, can usually be determined by the following entry in the swse log file:
2011-05-13 16:31:54 56: [SWSE] Open Session failed (0xa600d1) after 60.1958 seconds.
ProcessPluginRequest ProcessPluginRequestError 1 000010844d5a0a7a:0 2011-05-13 16:31:54 56: [SWSE] Failed to obtain a session ID. Login failed attempting to connect to %1
ProcessPluginRequest ProcessPluginRequestError 1 000010844d5a0a7a:0 2011-05-13 16:31:54 56: [SWSE] Set Error Response (Session: Error: 10879185 Message: Login failed attempting to connect to siebel.TCPIP.None.None://hostname:2361/enterprise/SCCObjMgr_enu)
ProcessPluginRequest ProcessPluginRequestError 1 000010844d5a0a7a:0 2011-05-13 16:31:54 56: [SWSE] Login failed.
SBL-SSM-00005: Timeout occurred while opening SISNAPI connection.
SisnapiLayerLog Error 1 000010894d5a0a7a:0 2011-05-13 16:32:10108: [SISNAPI] Async Thread: connection (0x2cdadb8), error (1180682) while reading message
GenericLog GenericError 1 0000108a4d5a0a7a:0 2011-05-13 16:33:24 (ssmsismgr.cpp (0) err=0 sys=0) SBL-GEN-00000: (ssmsismgr.cpp: 0) errorcode = 0, system error = 0, msg1 = (null), msg2 = (null), msg3 = (null), msg4 =(null)
ObjMgrSessionLog Error 1 0000108a4d5a0a7a:0 2011-05-13 16:33:24 Login failed for Login name : SADMIN
ProcessPluginState ProcessPluginStateError 1 0000108a4d5a0a7a:02011-05-13 16:33:24 71: [SWSE] Open Session failed (0xa600d1) after 60.0111 seconds.

Note the last line where we see a connection timeout of 60 seconds displayed.

This is the built in timeout of 60 seconds after which a request from SWSE plugin to the SCBroker is cancelled.

From that message we can conclude that SCBroker was not able to transfer a login request to a working object manager on node 'hostname'

We can also conclude that the object manager process is still running since it is still in SCBrokers routing table, however it does not accept new connections.

This is usually caused by an MT process hang scenario.

Now we are facing two challenges:

a) which process id exactly  is hanging  ? Imagine if we have for example 25 MT server processes running on that node, this is not easy to determine.

and

b) why is this process hanging ?

In the next section we will describe how we can find out which pid is hanging, how to mitigate the situation and what diagnostic data should be captured to help with investigation of b)

Troubleshooting Steps

To help us in this situation there is a new SCBroker parameter that has been introduced with the Fixpacks as indicated above. Its name is ConnForwardAlgorithm or "Connection Forward algorithm for SCBroker".

This is a hidden parameter.

This parameter determines which algorithm is used to forward incoming login requests to MT server processes. There are two possible methods:

a) Least Loaded "LL", the default
and
b) Round Robin "RR"

Note that this parameter is an advanced parameter as can be seen in following srvrmgr example:
srvrmgr> list advanced param ConnForwardAlgorithm for comp SCBroker show PA_ALIAS, PA_VALUE, PA_NAME
PA_ALIAS                   PA_VALUE       PA_NAME
--------------------       --------       -----------------------------------------
ConnForwardAlgorithm       LL             Connection Forward algorithm for SCBroker



Although LL is advisable in terms of performance, in case of a SCBroker hang this is causing unwanted behavior: once SCBroker has identified the least loaded process, it will reconnect to this particular pid until next session is established. Now in the case that the supposed to be least loaded process is hanging, SCBroker will try that process again and again and we might see stalling logins on all web servers.

In this situation, the algorithm should be changed to "RR".
This has two advantages:

1) The hanging process will only be contacted once. Next attempt is going to next available pid as described in the routing table. The effect will be that only one login is affected, and the consecutive logins will be successful until the hanging process is revisited. In that way, all requests will be distributed among the remaining, non-hanging processes and end users should get server busy message only once and a retry should them connect to a working process.

2) By monitoring the task distribution you can identify the process id that is not getting additional hits.
This process id is very likely the culprit.

Now you can take a userdump or pstack  as per Document 478050.1 or Document 478027.1 for exactly this one single process and then bounce that pid afterwards. This should greatly reduce the effort to get the right call stack of the hanging process to TechSupport in order to do root cause analysis.


The following srvrmgr command can be used in order to switch the forwarding mode:
Using srvrmgr with the /s switch, connect to the siebel server corresponding to the hostname as identified by the hostname in the swse error message.

Then change the parameter:

change param ConnForwardAlgorithm=RR for comp SCBroker

Now restart SCBroker component:

shutdown fast comp SCBroker
startup comp SCBroker

Now you can monitor for which particular process id the number of running tasks value is not increasing anymore:

list procs for comp <interactive_comp_name> show TK_PID,TK_NUM_NORMAL_TASKS

If you encounter hanging processes on multiple server nodes, then you need to change the parameter value to RR on all of these nodes.

Please note that the SCBroker forwarding mode is local to each siebel server in the enterprise, so you can have mixed LL and RR configuration within an enterprise.

It should also be mentioned that existing, established sessions are not affected by the SCBroker component  bounce.

Established session will continue to work even when the SCBroker is temporarily unavailable.

By running the round robin scheduler mode  of versions as stated above, it is possible to distribute incoming login requests to all processes that in this moment are still able to process requests.

This new parameter is documented in the following documentation:
     Siebel 8.0 Deployment Planning Guide > Siebel Architecture Overview > About Siebel Connection Broker
     Siebel 8.1 Deployment Planning Guide > Siebel Architecture Overview > About Siebel Connection Broker

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_ITA
  • Error 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-00209)
  • ObjMgrBusServiceLog 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:

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.



 

SBL-SSM-00003: Error opening SISNAPI connection

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




Applies to:

Siebel CRM - Version: 7.5.3 [100] and later   [Release: V7 and later ]
Information in this document applies to any platform.
This document was previously published as Siebel Alert 924.

Description

In Siebel eBusiness Applications version 7.5 and higher, the Siebel Sync application must be installed on each client machine where it connects to the Object Manager on the Server using a connect string. The connect string is of the following format:
siebel.TCPIP.None.None://<Gateway host>:2320/<Enterprise>/<ObjMgr>/<Siebel Server>
There are situations, however, when the Gateway and Siebel Server host names need to be succeeded by a domain name such as:
siebel.TCPIP.None.None://ABC.xyz.us.com:2320/<Enterprise>/<ObjMgr>/<Siebel Server>
In this example, xyz.us.com is the domain and ABC is the Gateway host name. When using this type of connect string, users receive the following login error when they try to login to the Siebel Sync application:
Login failed attempting to connect to siebel.TCPIP.None.None://ABC.xyz.us.com:2320/<Enterprise>/<ObjMgr>/<Siebel Server> (SBL-SVC-00209)
Next error:
Login failed.
SBL-SSM-00003: (rmodel.cpp 92: 2226) error code = 5600003, system error = 0, msg1 = (null), msg2 = (null), msg3 = (null), msg4 = (null)(SBL-SVC-00213)
Change Request 12-J2NJAS has been logged to address this product defect.

Likelihood of Occurrence

This behavior occurs when there is a requirement to have the Gateway and Siebel Server host names succeeded by a domain name in the connect string when running Siebel Sync on version 7.5 and higher.

Possible Symptoms

Users are unable to log into the Siebel Sync Application and receive the errors specified above.

Workaround or Resolution

In situations where the requirement is to have the Gateway and Siebel Server host names succeeded by a domain name in the connect string, the domain should be added to the DNS list on the local machine (client) where Siebel Sync runs to workaround this issue.
To do this in Microsoft Windows 2000 (the procedure is similar in Microsoft Windows XP and in Microsoft Windows NT):
  1. Right click on My Network Places and select Properties.
  2. In the Network and Dial-up Connections window, select the connection used (Local Area Connection or your VPN connection), right click and select Properties.
  3. In the Local Area Connection Properties window, select Internet Protocol (TCP/IP) and click Properties, then click Advanced.
  4. Select the DNS tab.
  5. In the lower half, check: Append these DNS suffixes (in order) and add your suffix here.
    For example, if the Siebel Server machine's fully qualified name is siebsrvrhostname.domain.comm then add domain.com here.
This setting requires a restart of the machine to become fully effective. The reason for this is that the Gateway Server will just return siebsrvrhostname (the hostname of the Siebel Server machine on which the object manager used for PIMSync is running).
Without the configuration to add the DNS suffix as above, the client machine will not be able to resolve siebsrvrhostname. With the added suffix the client should be able to resolve the resulting siebsrvrhostname.domain.com, which is required for successful PIMSync communication.
Alternatively, the network administrator can configure the DNS server so that it will resolve the unqualified hostnames.
NOTE: This behavior does not occur in Siebel eBusiness Applications version 7.0.4.x or 7.0.5.x.
Keywords:SBL-SSM-00003, login failed, attempting, connect, string, gateway host name, DNS





Applies to:

Siebel Life Sciences CRM - Version 8.0.0.2 [20412] to 8.1.1.4 [21225] [Release V8]
Information in this document applies to any platform.
***Checked for relevance on 22-Mar-2011***
CHECKED FOR RELEVANCE ON 31-JAN-2013

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





Applies to:

Siebel System Software - Version 7.5.3.4 [16180] to 7.5.3.17 [16285] [Release V7]
Oracle Solaris on SPARC (64-bit)
Product Release: V7 (Enterprise)
Version: 7.5.3.4 [16180]
Database: Oracle 9i
Application Server OS: Sun Solaris 8
Database Server OS: Sun Solaris 8

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


Symptoms

Customer installing a testing environment composed on 5 servers solaris (SUN FIRE V240 with Solaris 5.8):

1: web server
2: gateway server
3: application server
4: database server

Two application servers are balanced by Resonate. Customer installed the resonate agents on two servers. Customer has following problems:
1. Able to connect using a thin client to application and application reporting a timeout error on logs (appear the usual page 'Server Busy....')
2. If eapps_sia.cfg file gets changed for not to use the VIP Resonate (Customer uses the gateway hostname and the siebel server name) the thin client connection works
3. using the dedicated client customer can see all component up.

The problem seem to be related to Resonate-Web-Application chain.

Cause

Configuration/ Setup

Solution

The on-board NIC for Broadcom is supported (below), however Resonate 3.x does not support IPMP (Internet Protocol Network Multipathing).

This is defined on the Sun Microsystems Website.

http://www.sun.com/solutions/blueprints/1102/806-7230.pdf

Central Dispatch version: 3.2.2e
OS and SP level: SunOS 5.8 Generic_108528-27
NIC manufacturer: Sun Microsystems
NIC model bge (BCM570x)
NIC driver version bge (BCM570x driver v0.22)
Teaming capabilities ? Not in use
Machine make/model: Sun-Fire-V240 (in produzione Sun-Fire-V480)

The Siebel log files showed errors the following when IPMP was enabled.

SBL-GEN-09103: Parameter value was never set (i.e. is null)
SBL-OSD-00204:    Internal waitpid() failed with error 0
SBL-GEN-00000: (listener.cpp 21: 0) error code = 0, system error = 2123331884, msg1 = (null), msg2 = (null), msg3 = (null), msg4 = (null)
SBL-SRB-00053: time out in connecting to SRProc, will try to connect again after SRProc starts completely
SBL-SRB-00040: can't open asynchronous SISNAPI connection
SBL-GEN-03006: Error calling function: DICFindTable m_pReqTbl
SBL-OSD-00001: Internal: Function call timed out (0)
SBL-NET-01023: Peer disconnected
SBL-SSM-00003: Error opening SISNAPI connection
SBL-NET-01201: Internal: connect() failed: Connection timed out
The system works (disabling both IPMP and the other NIC which was also onboard) otherwise a kernel panic is experienced.

panic string: BAD TRAP: type=31 rp=2a1000bd6b0 addr=28 mmu_fsr=0 occurred in
module "rxp" due to a NULL pointer dereference ==== panic kernel thread:
0x2a1000bdd20 pid: 0 on cpu: 28 ==== cmd: sched







Applies to:

Siebel System Software - Version 7.8.2.5 [19227] to 8.2.2.2 SIA[23016] [Release V7 to V8]
z*OBSOLETE: Microsoft Windows 2000
Product Release: V7 (Enterprise)
Version: 7.8.2.5 [19227]
Database: Oracle 9.2.0.8
Application Server OS: Microsoft Windows 2000 Server SP 4
Database Server OS: Microsoft Windows 2003 Server SP2

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

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


Symptoms

Hi,
During the upgrade we have installed our web servers on a new machines. After moving external web server to DMZ zone we cannot log to echannel , eservice or wireless application.
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.[21:02:58]
The web server log shows:
GenericLog    GenericError    1    0    2007-05-23 22:23:02    (smconn.cpp (271) err=1801020 sys=1300230) SBL-NET-01020: Internal: unknown hostname
GenericLog    GenericError    1    0    2007-05-23 22:23:04    (smconn.cpp (271) err=1801020 sys=1300230) SBL-NET-01020: Internal: unknown hostname
GenericLog    GenericError    1    0    2007-05-23 22:23:07    (smconn.cpp (271) err=1801020 sys=1300230) SBL-NET-01020: Internal: unknown hostname
GenericLog    GenericError    1    0    2007-05-23 22:23:09    (smconn.cpp (271) err=1801020 sys=1300230) SBL-NET-01020: Internal: unknown hostname
GenericLog    GenericError    1    0    2007-05-23 22:23:11    (smconn.cpp (271) err=1801020 sys=1300230) SBL-NET-01020: Internal: unknown hostname
GenericLog    GenericError    1    0    2007-05-23 22:23:11    (ssmsismgr.cpp (635) err=5600003 sys=0) SBL-SSM-00003: Error opening SISNAPI connection.

.....cont

Cause

Configuration/ Setup

Solution


ObjMgrSessionLog    Error    1    0    2007-05-23 22:23:11    Login failed for Login name : SiebelAnontst
ProcessPluginState    ProcessPluginStateError    1    0    2007-05-23 22:23:11     3908: [SWSE] Open Session failed (0x56bf) after     11.2381 seconds.
......
ProcessPluginRequest    ProcessPluginRequestError    1    0    2007-05-23 22:23:56     3548: [SWSE] Failed to obtain a session ID. Login failed attempting to connect to %1
ProcessPluginRequest    ProcessPluginRequestError    1    0    2007-05-23 22:23:56     3548: [SWSE] Set Error Response (Session: Error: 00022207 Message: Login failed attempting to connect to siebel.TCPIP.None.None://xxxxxxxx:2321/sieb78tst/WirelessServiceObjMgr_enu)


We have 2 load balanced application servers running call center OM that are accessed via internal web server and one external web server that connects to echannel, eservice and Siebel wireless using the external web server (xxxxxxxx) .  
Before moving the external web server to the dmz we could successfully test the access to those 3 applications using internal network.
We have opened port 2320 and 3 Static ports for each application (specified in the OMs configuration).
The network configuration seems to be fine.
The xxxxxxxx server referenced in the error log is our apps server
Please could you help us with this problem.
Please note attached files.

Comment:

According to the description:

The client had moved the web server to a DMZ and since that moment they haven’t been able to access eChannel , eService and Wireless applications.
They have opened port 2320 and 3 Static ports for each application and they were using a load balancing solution.

Solution:
   
    When a load balancing solution is used the web server must be able to access the SCBroker port on each Siebel Server. After the ScBroker(2321) port was opened they have been able to access the applications.





Applies to:

Siebel CRM - Version 5.0.0.2 Finance 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 via
http://<web server hostname>/acswmt_enu
results in 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
Could not find 'Application' named 'Custom Application Name'. This object is inactive or nonexistent.
...

 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 parameter "Application Repository File" - this needs to reference an .srf that contains the Application used.

Solution


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

While the error messages above occurred on Siebel 8.1, the requirement to set the "Application Repository File" to the correct .srf name exists for all Siebel versions.




Applies to:

Siebel CRM - Version 8.1.1.3[21219] and later
Information in this document applies to any platform.
***Checked for relevance on 28-02-2013***

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 <Server Name>. 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" as DSN name and then changed. However, when the second siebel server was configured in the same enterprise, the default value for DSN name ("sblt_internal") during the siebel server configuration was taken and this was causing the problem. Once the DSN value was changed to "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.






Applies to:

Siebel System Software - Version 7.5.2.218 SIA [16087] and later
z*OBSOLETE: Microsoft Windows 2000
Product Release: V7 (Enterprise)
Version: 7.5.2.218 [16087] PTG Com/Med
Database: Oracle 9.2.0.2
Application Server OS: Microsoft Windows 2000 Advanced Server SP 3
Database Server OS: Sun Solaris 5.8

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


Symptoms

While testing inbound web services, errors were reported in the Siebel Web Engine (SWE) logs :-

SBL-NET-01020: Internal: unknown hostname
SBL-SSM-00003: Error opening SISNAPI connection.

The requests being made were attempting to run a web service through the EAI Object Manager. But on another web server, the EAI requests were successful (no errors in the SWE logs).

Cause

One of the web servers did not have network connectivity to the siebel server.
The hostname provided in eapps.cfg could not be resolved, thus the error SBL-NET-01020: Internal: unknown hostname

Solution

Please review eapps.cfg and ensure it is pointing to a valid hostname that can be accessed through the network.


Further information regarding verifying network connectivity in a load balanced environment can be found in Siebel Server Installation Guide for Microsoft Windows > Implementing Load-Balancing with Central Dispatch > Planning Your Central Dispatch Site > Network Connectivity for Central Dispatch.