we are facing persistend connection-error in OAC0 when test-Connectiong a new-installed ContentServer.
„Error in HTTP Access: IF_HTTP_CLIENT->RECEIVE 1 ICM_HTTP_CONNECTION_BROKEN
Message no. CMS166"
The ContentServer is installed with User „CS-Admin“, which is in group „Administrators“ on an English Windows 2008 R2, 64bit.
The installation went fine and finished with no errors.
After installation the driver is registered successfully with odbcreg as follows:
"odbcreg.exe CSMaxDB -i -p "E:\sapdb\SDB\db\pgm" -d sdbodbcw.dll"
An idea is, that there still might be failours in right-administrations
For example CS-Admin had no rights for some partitions. Also some directories where excluded from permission inheritance (Berechtigungsvererbung) after first installation. Furthermore the user CS-Admin had no rights to execute the odbcreg-command.
Also the contentserver.ini was not editable for CS-Admin after installation,
But finally there was no error in installation-process (?!).
And all this is solved now by the Person, who has installed Windows on that machine.
I have reinstalled the ContentServer after this with CS-Admin, I have also deinstalled and again installed the contentserver, but the connection-error remains.
The Network-Connection seems to be fine. SAP-Ping (OS01) is ok. Also Telnet works fine.
Please do not doubt the IIS-Installation, this is ok.
Can somebody give advice, how we can find out, what breakes up the connection between SAP-Server and CS-Server?
Systemdata: Linux / SYBASE / NW731 SPS11
Kernel: 721 PL201
No entries in Syslog (SM21)
No entries in RFC-Trace (SM59) after activation of Trace for RFC-Destination „SAPHTTPA", also with rdisp/TRACE=2
No entries in „cs_trace.txt", only request by URL in Webbrowser generates entries in cs_trace.txt.
- ContentServer.ini: [ContentServer]
Report RSHTTP05 is OK
Report RSHTTP20 gives "Response Data 0"
794919 - Fehleranalyse: ICM_HTTP_TIMEOUT und interner Fehler
164203 - Probleme mit SAPHTTP
761387 - Support-Informationen fuer den SAP Content Server
thanks for help, we found the error located in Firewall:
Even when telnet to port 1090 is stable, the connection can be cut by the firewall afterwards.
The firewall first checks, which kind of application wants to connect to the port. When this is clear, the firewall is cutting connection anyway, if the Port is not opened by definations. Maybe this is a new feature in Firewall-technologies...
Thanks so far.