Sametime Community 8.5.2 lässt kein Login mehr zu

[Tode]

Ich habe einen Sametime- Server neu installiert (vorher Sametime 8.0.2, jetzt Sametime 8.5.2).

Dabei bin ich nach "from zero to hero" vorgegangen.

Der Server läuft auch (hatte den alten deinstalliert und das ganze komplett neu gemacht):
Alle Dienste laufen, ich kann mich im Web anmelden (auch mit den Benutzern, die nachher Sametime verwenden sollen),
aber am Sametime kann ich mich nicht anmelden:

Fehler:

Dringlichkeit: Very Low
Community-Server-Ereignistyp: FailedLogin
Datum und Zeit: 06.02.2012 14:58
IP-Adresse: 10.4.8.119
Anwendungsname: UIM 8.0.2-Notes 8.5.2
Ursache: Unknown reason code :
Benutzer-ID: CN=Hans Wurst,OU=MyOU,O=Orga
IBM Lotus Sametime-Verbindung:
Client-Version:
Protokollversion:

Ich habe nach dem Fehler im Web gesucht, und da steht, VP_SECURITY_LEVEL und VP_SECURITY_ALLOW_USER sind Schuld.
Also habe ich beide Werte auf den Niedrigsten überhaupt möglichen Wert gesetzt... NIX.
Dann habe ich bei VPS_ALLOWED_LOGIN_TYPES alles hinzugefügt was ich finden konnte (Wert war vorher nicht in der Sametime.ini, aber auch hier wieder: Kein Erfolg...

Was mich wundert: Bei Client-Version im Log steht immer ""...
Kann es das sein?

Bin für jeden Tipp dankbar...

[m3]

Ich vermute mal, Du meldest Dich von einem Client aus an, der schon eine Community eingetragen hat?
Dann nimm in der SSC in der Default-Policy den Eintrag raus, dank dessen die Community die einzige Community im Client sein will.

(Nicht, dass mir das schon mal passiert waere  ).

[Tode]

OK... Server startet gerade neu... Da der Server und damit die Community wieder genau gleich heisst, hatte ich das nicht in Erwägung gezogen... Gleich wiess ich Bescheid, obs das war...

[Tode]

So: Das wars nicht... Weitere Ideen?
Warum kommt denn überhaupt beim Sametime- Server keine Client- Version an?
Was könnte das verhindern?

Argh...

[m3]

Kannst Du dich am Web Interface des Domino mit den Usern anmelden?

[Tode]

ja, das kann ich...

habe grade mal das LDAP- Logging hochgesetzt, und das zeigt erfolgreiche Login- Versuche... Keinerlei Fehler da drin. Trotzdem kann ich mich nicht verbinden... Das ist echt zum Mäuse melken...

[Tode]

Zusatz- Info: Ich bekomme folgenden Trace, wenn ich am Client das Logging hochdrehe:

Code

14:36:27.206 3 WARNUNG com.lotus.sametime.core.util.connection.SocketReceiver
run Exception on Receiver: 
java.io.EOFException
	at java.io.DataInputStream.readFully(Unknown Source)
	at java.io.DataInputStream.readFully(Unknown Source)
	at com.lotus.sametime.core.util.connection.SocketReceiver.readFully(Unknown Source)
	at com.lotus.sametime.core.util.connection.SocketReceiver.receive(Unknown Source)
	at com.lotus.sametime.core.util.connection.Receiver.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

 stjavatk.Receiver 
14:36:27.206 3 WARNUNG com.lotus.sametime.core.util.connection.SocketReceiver
run Buffer [1] that caused exception: 
 stjavatk.Receiver 
14:36:27.206 3 WARNUNG com.lotus.sametime.core.util.connection.SocketReceiver
run Read data from input stream: false
 stjavatk.Receiver 
14:36:27.206 3 WARNUNG com.lotus.sametime.throwable.ThrowableReporter
caughtThrowable Notifying listeners about caught throwable: java.io.EOFException

Und wenn ich wiederum danach google, dann scheint es ein Problem mit dem Client- Type / VPS_ALLOWED_LOGIN_TYPES zu sein... aber das ist ja schon nciht mehr gesetzt... ich drehe mich echt im Kreis...

[m3]

Welchen Client verwendets Du denn fuer den Test? Hofffentlich eh den 8.5.2 Connect Client (Standalone), oder?

How to determine the Client type that is connecting to a Sametime server

The flags affect all logins where this Sametime server is the home server. By default (if this flag is not specified), all login types are allowed. (After introducing any changes to the sametime.ini file, the Sametime server must be restarted for the new configuration to take effect.)

Firewall und so kannst Du ausschliessen?

[Tode]

Für den Test verwende ich sowohl den im Client 8.5.3 integrierten 8.5.1- Client als auch den Web- Client über den installierten Proxy- Server...

Und die VPS_ALLOWED_LOGIN_TYPES ist wie gesagt leer...

Firewall kann ich insofern ausschliessen, dass ich ja im Log des Servers die Fehlgeschlagenen Logins sehe...

[Pfefferminz-T]

Hallo Torsten,

setze mal die VPS_ALLOWED_LOGIN_TYPES auf folgenden Wert:

VPS_ALLOWED_LOGIN_TYPES=100A,1010,1200,1201,1202,1203,1204,1205,1206,1207,1214,1215,1216,1217,1218,1220,1230,1231,1232,1233,1234,1235,1236,1237,1238,1239,123A,123B,123C,123D,123E,123F,1243,1244

Falls das nicht hilft... die Beschreibung aus dieser Technote entspricht zwar nicht Deiner Umgebung aber die Exception entspricht der aus Deinem Posting (https://www-304.ibm.com/support/docview.wss?uid=swg21474586).

Grüsse,
Thorsten

[Tode]

Ich habe es jetzt vorerst aufgegeben und werde mich nächsten Montag wieder damit beschäftigen.
@Thorsten: danke, den Eintrag hatte ich schon gefunden, und auch das sso- Dokument neu erstellt sowie das Serverdokument ergänzt... Hat alles nix geholfen.
Ich wollte rausfinden, was den Fehler verursacht hatte, deshalb bin ich schrittweise rückwärts gegangen:
1. Sametime 8.5.2 deinstalliert und neu installiert, dieses mal ohne system console, aber immer noch mit ldap directory - gleicher fehler.
2. Sametime 8.5.2 deinstalliert und neu installiert, ohne system console mit Domino Directory - gleicher Fehler
3. Sametime 8.5.2 deinstalliert, sametime 8.0.2 installiert, natürlich ohne console, mit domino directory - login funktionierte sofort wieder

Zwischen den Versuchen habe ich natürlich immer die richtlinien angepasst und die sametime.ini gecheckt.

Jetzt läuft also eine -nicht supportete- Konstellation:
Sametime 8.0.2 auf Domino 8.5.2FP4...
Und alle können sich wieder anmelden.

Nächste Woche gehe ich das ganze Thema nochmal an...
Vielleicht hat ja nochmal jemand nen Tipp zum nachlesen...
Client debug habe ich schon gemacht, Serverseitiges ldap- debug auch,
Weitere Tipps (feedback kommt dann am nächsten Montag)?

[Pfefferminz-T]

Hmmm, hast Du eine Möglichkeit, den Server auf einem frischen Betriebssystem (ohne Deinstallation Sametime 8.0.x) aufzusetzen? Als Variablen zum Debugging am Client hast Du wahrscheinlich die Parameter aus http://www-01.ibm.com/support/docview.wss?uid=swg21320442 verwendet? Falls nicht, bitte hier mal auf "FINEST" setzen.

Grüsse,
Thorsten

[Tode]

Genau das habe ich gerade mal gemacht... Neue Virtuelle Maschine (hier bei uns in der Test- Umgebung), Notes- Relevante Daten übernommen und alles neu aufgesetzt (gleiche Versionen, alles gleich, ausser Betriebssystem). Und siehe da: Funktioniert auf Anhieb...

Genau den Artikel hatte ich für Debugging verwendet, FINEST hatte ich noch nicht verwendet, die Datenflut von "FINE" hatte mir schon gereicht.
Da der Sametime- Server ja gross keine Daten vorhält und man deshalb nicht viel Zeit mit Datenkopieren verschwendet, werden wir die Kiste jetzt am Montag neu aufsetzen (ist eh alles Virtuell, da kann man das Ding sogar bei abgehängtem Netz voll durchinstallieren, ohne dass man den Produktiv- Server damit stört).

Dann geht das wahrscheinlich auf Anhieb... Was bei der aktuellen Kiste stört, werde ich wohl nie erfahren (zumindest laut telnet waren alle Ports offen und erreichbar, die da so notwendig sind)...

Gruss und Danke für die Unterstützung.

[Tode]

So, ich mal wieder... ich dreh bald am Rad: Alles mit neuer Maschine ganz neu angefangen... und wieder die selbe Sch... Auch Logging auf Finest bringt mich keinen Schritt weiter: Ich bekomme im Log des Servers eine Erfolgsrückmeldung, und am Client dann den schon geposteten Trace...

Jetzt probier ich alles nochmal mit einem neuen Hostnamen und einer komplett neuen Installation...

EDIT: Vergesst die logs (haben nur den Thread zugemüllt)... ich habe endlich ne Spur... melde mich, wenn sich die bewahrheitet...

[m3]

Setzt mal nur SSC und Community Server auf.
Was koennte die Spur sein? Lokale Firewall?
Ev. mal Connect Client am Server installieren, damit Du Netzwerk-Issues ausschliessen kannst.
Dein Community Server ist eh nicht der LDAP Server, oder?

[Tode]

GELÖST !!!!
Vorgeschichte: Es sind wie immer die Kleinigkeiten. Der Server war vorher ein Standalone Domino- basierter Server.
Dann habe ich ihn in die Community aufgenommen. Um die Buddylisten nicht zu verlieren, habe ich diese mittels stnamechange.cmd und domToLDPAPchange.csv konvertiert.

Und diese konvertierte vpuserinfo.nsf habe ich zwischen allen Versuchen mitgeschleppt (auch nach den kompletten Neuinstallationen)...
Aber diese Datenbank hat die Anmeldung verhindert, fragt mich nicht wieso.

Neue vpuserinfo auf neuem Server -> Login funktioniert sofort.

Ich habe dann mal das Dokument für meinen Benutzer aus der alten DB kopiert, und jetzt bin ich der Ursache auf der Spur, warum diese vpuserinfo nicht funktioniert hat.

Das Problem mit dem Login ist aber GELÖST.

Danke Dir Martin für Deine rege Anteilnahme...

[m3]

Bin ja neugierig, man lernt ja nie aus - gerade bei ST.

[Tode]

Also: Obwohl die Datenbank ok ist, was ACL und content angeht, scheint dem Server irgendwas nicht zu passen... Ich kann die beliebig hin und her tauschen, und mit einer DB geht es, mit der anderen nicht. Was aber das beste daran ist: Kopiere ich Dokumente per Notes- Client aus der "defekten" in die "intakte" Datenbank, dann hat der Benutzer seine Buddy- Liste wieder... Es muss also irgendwo in irgendeinem Dokument innerhalb der Datenbank liegen. Strg + Copy habe ich aber noch nicht probiert...

Taste mich da jetzt vorsichtig ran.