Das Notes Forum
Lotus Notes / Domino Sonstiges => Companion Products => Thema gestartet von: Tomz am 31.08.07 - 13:10:31
-
Ich habe vorhin festgestellt, dass mein Sametime (aus dem Notes Client) mir nicht alle User anzeigt die wirklich online sind. Bei denen fehlt das grüne Pünktchen vor dem Namen. Ich dachte es ist vielleicht nur ein Anzeigeproblem aber ich kann auch keinen Chat mit denen starten.
Ich konnte das auf von anderen Clients nachvollziehen.
Kennt jemand das Phänomen und einen Workaround?
-
Hallo Tom,
im Notes Client gibt es eine Ad-Hoc Symbol in der Symbolleiste, wenn Du dort drauf klickst, bekommst Du eine Auswahlbox in der Du einen Vornamen / Nachname oder ein Namenskürzel eingeben kannst.
Wenn Du die Eingabe mit OK bestätigst, erscheint die Chatbox mit dem Benutzer bzw. eine Liste der Benutzer (z.B. alle mit Vornamen Tom).
Sind dort die Benutzer als online/offline/abwesend angezeigt?
-
Ich habe das auch schon probiert aber leider ohne Erfolg. Mir ist das ein echtes Rätsel.
Ich habe bei einer betroffenen Person sogar ins Personendokument jetzt schon eingetragen, welches der Sametime Server ist, obwohl ich das nicht für notwendig halte.
-
Hallo,
kannst Du bitte etwas mehr Details liefern?
Versionen, sind alle in der gleichen Notesdomain?
Woher weißt Du, dass die wirklich online sind?
Wurde was geändert - gibte evtl. zwei IM Server etc.
Alle an einem Standort ...
Grüße Werner
-
Hast Du mehrere Sametime Server am Laufen?
Könnte es sein, dass sich Personen am anderen Server angemeldet haben.
Hatte das selbe Phänomen, als ich Personen von einem auf den anderen Server umgezogen habe.
Werden die Einstellungen des Sametime Servers über eine Policy in den Notes Client gesetzt?
-
Hallo Werner,
du hast Recht meine Infos sind ein wenig dürftig ...
Wir setzen nur einen Sametime Server 7.5.1 CF1 auf einem Domino 7.0.2 FP2. User befinden sich in gleicher Domain und ich weiss, dass sie online sind, da ich mit denen telefoniert habe ;)
Geändert wurde garnix, da er erst (wieder) eingerichtet wurde.
@Martin
Die Clienteinstellungen haben wir via Workplace Control (workplace-control.com) angepasst.
-
Geändert wurde garnix, da er erst (wieder) eingerichtet wurde.
Hast Du den Server komplett neu installiert, oder einige Dinge übernommen?
Wo (im DD, in der Kontaktliste oder im Maileingang) hast Du gesehen, dass Benutzer, die angemeldet sind, nicht als online angezeigt werden?
-
Hallo,
und ich weiss, dass sie online sind, da ich mit denen telefoniert habe ;)
Welche Telefonanlage ist denn mit IM gekoppelt?
Gruß Werner
-
Wo (im DD, in der Kontaktliste oder im Maileingang) hast Du gesehen, dass Benutzer, die angemeldet sind, nicht als online angezeigt werden?
Ich habs bisher nur in der Kontaktliste überprüft und auch von da aus versucht mit ihm zu chatten.
Ich muss es mal im Log überprüfen, komme diese Woche aber nicht dazu - ich habe nächste Woche mehr Zeit dafür.
Welche Telefonanlage ist denn mit IM gekoppelt?
Unsere nicht, ich hab ganz analog des Benutzers Telefonnummer eingetippt und mit Ihm gequatscht, nachdem ich schon vorher wegen Sametime mit Ihm telefonisch in Kontakt war. Die Welt kann so einfach sein ;D
-
Da bin ich wieder ...
Wir haben ein neues Szenario: Der Sametimeserver befindet sich jetzt in einer Testumgebung in anderer Domain. Diese andere Domain ist via Directory Assistance an die eigentliche produktive Umgebung angebunden, in der sich der kleine Kreis von Sametimetestern befindet. In den Arbeitsumgebungen dieser ist also der Sametimeserver aus der anderen Domain eingetragen.
Das läuft scheinbar gut ABER ...
In dem Adressbuch aus der Testumgebung stehen viele Benutzer aus der produktiven Umgebung drin (die Dokumente hat irgendwann mal jemand da reinkopiert - warum entzieht sich meiner Kenntnis) und ein paar Benutzer stehen mit Namen aus der Testumgebung drin (also mit entsprechender OU und O für diese Umgebung).
Jetzt passiert es, dass einige Benutzer mit Eintrag für die Testumgebung sich aber mit Namen aus der produktiven Umgebung anmelden. Das passiert aber nicht bei allen, nur bei einer Hand voll Leuten. Da diese Leute aber mit anderem Namen (OU und O) im Adressbuch des Sametimeservers eingetragen sind kann mit denen nicht kommuniziert werden.
Mein zweites Problem: ich kann mich via Webfrontend nicht bei Sametime anmelden. Ich versuche micht dort mit vollem Namen und korrektem Passwort anzumelden, komme aber nicht weiter. Der Server sagt mir auch nicht, dass PW falsch wäre oder sonstiges. Das Loginfenster refreshed einfach. Mit flaschem Passwort sagt er mir auch, dass ich ein falsches eingegeben habe. Warum komme ich da nicht rein?
-
Hallo Tom,
Jetzt passiert es, dass einige Benutzer mit Eintrag für die Testumgebung sich aber mit Namen aus der produktiven Umgebung anmelden. Das passiert aber nicht bei allen, nur bei einer Hand voll Leuten. Da diese Leute aber mit anderem Namen (OU und O) im Adressbuch des Sametimeservers eingetragen sind kann mit denen nicht kommuniziert werden.
Du kannst den Benutzernamen im Produktiven Adressbuch blocken, in dem Du in das Feld "Sametime server" z.B. "-no access-" oder irgendwas anderes einträgst.
Wenn Du dem Benutzer im Adressbuch der Testumgebung explizit den Sametime Servernamen einträgst, dann muss er sich mit diesem Benutzer dort anmelden.
Mein zweites Problem: ich kann mich via Webfrontend nicht bei Sametime anmelden. Ich versuche micht dort mit vollem Namen und korrektem Passwort anzumelden, komme aber nicht weiter. Der Server sagt mir auch nicht, dass PW falsch wäre oder sonstiges. Das Loginfenster refreshed einfach. Mit flaschem Passwort sagt er mir auch, dass ich ein falsches eingegeben habe. Warum komme ich da nicht rein?
Vielleicht helfen Dir diese Links weiter:
Sametime: Unable to Administer the Server when Web SSO is Disabled
(http://www-1.ibm.com/support/docview.wss?rs=477&context=SSKTXQ&q1=login+error+web&uid=swg21090310&loc=en_US&cs=utf-8&lang=en)
Repeatedly prompted to log into Sametime web administration (http://www-1.ibm.com/support/docview.wss?rs=0&uid=swg21086545)
-
Danke martin für die schnelle Antwort.
Problem zwei war schnell geklärt, ich habe die URL mit voll qualifiziertem Servernamen aufgerufen und schon gehts.
Zu meinem ersten Problem ...
Wenn ich z.B. "-no access-" im produktiven Adressbuch eintrage, wird das auch in die Arbeitsumgebung übernommen und der Nutzer kann sich garnicht mehr verbinden. Wenn ich das im Adressbuch eintrage und in der Arbeitsumgebung aber den korrekten Server eintrage kann er sich nicht verbinden, selbst, wenn ich nach erfolgloser Anmeldung im Dialog für Benutzer und PW den korrekten Namen des Benutzers aus der Testumgebung eintrage.
Ich frage mich wirklich, wieso der Benutzername aus dem Adressbuch der produktiven Umgebung herangezogen wird, anstatt aus dem Adressbuch der Testumgebung. Bei anderen Benutzern geht es doch auch. Es betrifft wirklich nur ein paar.
-
Danke martin für die schnelle Antwort.
Bitte schön, gern geschehen. :)
Zu meinem ersten Problem ...
Wenn ich z.B. "-no access-" im produktiven Adressbuch eintrage, wird das auch in die Arbeitsumgebung übernommen und der Nutzer kann sich garnicht mehr verbinden.
Wenn Du "-no access-" einträgst, kann sich der Benutzer nicht am ST Server anmelden, da der Server vor der Anmeldung abprüft, ob der Benutzer, dass Recht hat auf den ST-Server zu zugreifen. Die Arbeitsumgebung wird nicht verändert, d.h. er wird bei der Anmeldung immer versuchen sich am "produktiven" in der Arbeitsumgebung eingetragenen ST Server anzumelden.
Dies führt zu der viel aussagenden "Fehlermeldung" ... "Ungültiges Kennwort. Name des Instant-Messaging-Servers wurde nicht gefunden."
Wenn ich das im Adressbuch eintrage und in der Arbeitsumgebung aber den korrekten Server eintrage kann er sich nicht verbinden, selbst, wenn ich nach erfolgloser Anmeldung im Dialog für Benutzer und PW den korrekten Namen des Benutzers aus der Testumgebung eintrage.
Ich frage mich wirklich, wieso der Benutzername aus dem Adressbuch der produktiven Umgebung herangezogen wird, anstatt aus dem Adressbuch der Testumgebung. Bei anderen Benutzern geht es doch auch. Es betrifft wirklich nur ein paar.
wurden alle Personendokumente mit dem Eintrag "-no access-" auf den ST Server komplett repliziert? ???
-
wurden alle Personendokumente mit dem Eintrag "-no access-" auf den ST Server komplett repliziert? ???
Nein, die Server replizieren ja nicht miteinander.
-
In dem Adressbuch aus der Testumgebung stehen viele Benutzer aus der produktiven Umgebung drin (die Dokumente hat irgendwann mal jemand da reinkopiert - warum entzieht sich meiner Kenntnis) und ein paar Benutzer stehen mit Namen aus der Testumgebung drin (also mit entsprechender OU und O für diese Umgebung).
könnte da der Hund begraben liegen? :-\
Ich würde die folgendes vorschlagen....
Bitte lösch alle reinkopierten Dokumente raus, und erstellte einen DA auf dem ST-Server mit einer Replik des DD.
-
Bitte lösch alle reinkopierten Dokumente raus, und erstellte einen DA auf dem ST-Server mit einer Replik des DD.
Das kann ich nicht einfach machen, da bekomm ich sicher was auf die Finger.
Die Sache ist ja die, dass es bei einigen Benutzern mit Namen aus der Testumgebung funktioniert und bei manchen nicht. Ich frage mich, worin unterscheiden die sich?
-
Die Sache ist ja die, dass es bei einigen Benutzern mit Namen aus der Testumgebung funktioniert und bei manchen nicht. Ich frage mich, worin unterscheiden die sich?
Ich würde mal prüfen, welche Benutzer genau betroffen sind.
- nur die Benutzer in der Testumgebung mit neuer O/OU
- nur die Benutzer, die in das DD reinkopiert worden sind
- oder beide "Benutzertypen"
-
Ich würde mal prüfen, welche Benutzer genau betroffen sind.
- nur die Benutzer in der Testumgebung mit neuer O/OU
Genau die betrifft es... ABER eben nicht alle und genau das macht mich stutzig. :-:
-
Sind die betroffenen Benutzer namentlich sowohl im DD der Testumgebung als auch in der produktiv Umgebungen vorhanden?
-
Sind die betroffenen Benutzer namentlich sowohl im DD der Testumgebung als auch in der produktiv Umgebungen vorhanden?
Ja haben aber aufgrund der unterschiedlichen Domain quasie einen unterschiedlichen Namen, also "PersonX/Hier/Dort" (produktive Umgebung) --> "PersonX/Test" (Testumgebung).
Ich hatte gerade einen Verdacht ...
Die Benutzer aus der Testumgebung bei denen es nicht funktioniert hatten kein Internetpasswort gesetzt. Das habe ich jetzt mal bei einem betroffenen Benutzer nachgeholt. Er hat sich daraufhin abgemeldet und wieder angemeldet. SSO funktionierte aber nicht und er bekam den Anmeldedialog. Als Benutzer war aber schon wieder der Name aus der Produktion drin. Er hat das auf den Namen der Testumgebung geändert und sich mit dem neuen Passwort angemeldet.
So weit so gut ...
Als er sich dann wieder abgemeldet hatte und wieder anmeldete funktionierte es wieder über SSO, allerdings war er wieder mit dem Namen aus der produktiven Umgebung unterwegs.
WARUM?
-
Welcher Server ist in Arbeitsumgebung (Notes Client) eingetragen?
Wurde das gespeicherte ST-Passwort gelöscht?
Wie meldet sich der Benutzer an? nur mit PersonX oder mit PersonX/Test?
-
Welcher Server ist in Arbeitsumgebung (Notes Client) eingetragen?
Wurde das gespeicherte ST-Passwort gelöscht?
Wie meldet sich der Benutzer an? nur mit PersonX oder mit PersonX/Test?
1. Der Server der Testumgebung.
2. Wenn ich das Passwort lösche kommt bei der nächsten Anmeldung eine Abfrage von Benutzernamen und PW. Wir tragen dort den Benutzer aus der Testumgebung ein, ohne Speicherung des PWs. Benutzer kann sich anmelden, ist auch als Testumgebungs-User unterwegs. Bei der nächsten Ab- und Anmeldung geht alles wieder ohne Abfrage aber Benutzer ist wieder der aus der produktiven Umgebung.
3. Wenn wir die Anmeldung nach der Passwortlöschung machen, dann mit PersonX/Test.
-
2. Wenn ich das Passwort lösche kommt bei der nächsten Anmeldung eine Abfrage von Benutzernamen und PW. Wir tragen dort den Benutzer aus der Testumgebung ein, ohne Speicherung des PWs. Benutzer kann sich anmelden, ist auch als Testumgebungs-User unterwegs. Bei der nächsten Ab- und Anmeldung geht alles wieder ohne Abfrage aber Benutzer ist wieder der aus der produktiven Umgebung.
Kann es sein, dass die Policy das "Instant Messaging Server" Feld nach der Neuanmeldung auf den produktiv ST-Server zurücksetzt? :-\
-
Kann es sein, dass die Policy das "Instant Messaging Server" Feld nach der Neuanmeldung auf den produktiv ST-Server zurücksetzt? :-\
Nee, das Feld ist normalerweise bei uns leer.
-
2. Wenn ich das Passwort lösche kommt bei der nächsten Anmeldung eine Abfrage von Benutzernamen und PW. Wir tragen dort den Benutzer aus der Testumgebung ein, ohne Speicherung des PWs. Benutzer kann sich anmelden, ist auch als Testumgebungs-User unterwegs. Bei der nächsten Ab- und Anmeldung geht alles wieder ohne Abfrage aber Benutzer ist wieder der aus der produktiven Umgebung.
Bei dem oben besagten Benutzer ist der Benutzernamen in der produktiven Umgebung PersonX und in der Testumgebung PersonX/Test. Richtig?
Wenn sich der Benutzer am Notes Client anmeldet, geht der Client davon aus, dass der Benutzer sich mit dem Namen der User-ID anmeldet.
Da in der Arbeitsumgebung "automatisches Anmeldung" statt "manuell anmelden" eingetragen ist und zugleich das Passwort des Benutzer abgespeichert wurde, meldet er sich ohne Abfrage am Server an.
Was passiert bei manueller Anmeldung?
Welcher Name steht im Login?
-
So, ich hab jetzt selber auf meinen Namen ein Personendokument in der Testumgebung angelegt, also mit entsprechender O. Ich teste jetzt also mit eigenem Namen. Vorher existierte noch mein Name aus der produktiven Umgebung im Adressbuch der testumgebung (damit gabs ja keine Probleme).
Bei dem oben besagten Benutzer ist der Benutzernamen in der produktiven Umgebung PersonX und in der Testumgebung PersonX/Test. Richtig?
Ja, gleicher Vor- und Nachname, nur OU und O unterscheiden sich.
Was passiert bei manueller Anmeldung?
Welcher Name steht im Login?
Die manuelle Anmeldung ist bei mir nur möglich, wenn ich SSO deaktiviere. Es steht der Name drin, den ich das letzte mal eingetragen habe. Kann also auch Mist sein.
-
Guten Morgen Tom,
da wir in diesem Thread so viele Dinge angesprochen haben, hatte ich mir diese Diskussion ausgedruckt, um einen Gesamtüberblick für eine (Lösungs-)Antwort geben zu können.
Um sicherzustellen, dass sich Notes Benutzer mit dem Testuser am ST Server anmelden, solltest Du das SSO deaktivieren. Bei der ersten Anmeldung am Instant Messaging soll der Benutzer den Testbenutzer eintragen und mit dem Setzen der Option "Kennwort speichern" das Passwort permanent speichern.
Somit wird der Benutzer automatisch (ohne Passwort-Abfrage) mit dem Testuseraccount an der ST Testumgebung angemeldet, nachdem er sich am Notes Client angemeldet hat.
Ich hoffe, dass hilft Dir weiter.
Abschließend möchte ich eine Zusammenfassung der Tipps und Erkenntnis aus diesem Threads zusammentragen:
SSO aktiviert am Notes Client für Instant Messaging Anmeldung:
Der Notes Benutzer wird mit seinem Benutzernamen und dem Notes Kennwort am Sametime Server automatisch angemeldet.(vorgesetzt Internet Passwort = Notes Passwort) Es gibt keine Möglichkeit während des Anmeldevorgangs sich mit einem anderen (Test-)Benutzer am ST Server anzumelden.
Ausgenommen der Benutzer deaktiviert SSO (löscht das Instant Messaging Passwort), trägt bei der ersten IM Anmeldung einen anderen Benutzer ein und setzt die Option "Kennwort speichern".
Sametime Benutzer auf bestimmten Server beschränken
Trägt man im DD in das Personendokument des Benutzers im Feld "Instant messaging server" (Sametime Server) einen bestimmten Sametime Server z.B. sametime/acme ein, kann sich der Benutzer nur an diesem ST Server anmelden.
Bleibt das Feld leer kann sich der Benutzer an mehreren ST Servern anmelden, sofern das DD, im dem der Benutzer eingetragen ist, auf diesem Server sich befindet.
Sametime Benutzer an Sametime Server aussperren
Ersetzt man im DD in das Personendokument des Benutzers im Feld "Instant messaging server" (Sametime Server) den Namen des Sametime Servers durch ein Wort z.B. -no access- kann sich der Benutzer an keinem Sametime Server mit seinem Benutzernamen anmelden.
-
Dank dir Martin für deine Bemühungen!!
Da diese Testumgebung wirklich nur Spielwiese ist und wir das SSO aber unbedingt aktiviert lassen wollen, haben wir es jetzt so gemacht, dass wir alle Personendokumente der Sametimebenutzer aus der produktiven Umgebung in das Adressbuch der Testumgebung kopiert haben - das sind nicht zu viele.
Das ist nicht ganz sauber, funktioniert aber einwandfrei.
Sollte der ST-Server aus seinem Nischendasein irgendwann mal aufwachen dürfen und den Weg ins gesamte Unternehmen finden (was ich nciht glaube), dann müssten wir uns auch keinen Kopf über zwei verschiedene Domains machen. ::)
Also, es bleibt jetzt wie es ist und (fast) alle sind glücklich.
-
Dank dir Martin für deine Bemühungen!!
Bitte schön
Da diese Testumgebung wirklich nur Spielwiese ist und wir das SSO aber unbedingt aktiviert lassen wollen, haben wir es jetzt so gemacht, dass wir alle Personendokumente der Sametimebenutzer aus der produktiven Umgebung in das Adressbuch der Testumgebung kopiert haben - das sind nicht zu viele.
Das ist nicht ganz sauber, funktioniert aber einwandfrei.
Wenn´s funktioniert, fragt keiner nach dem Lösungsweg :)
Doch bedenke, wie schnell einer Testumgebung eine produktive Umgebung werden kann.
Ich spreche da aus Erfahrung.
Zwar teilt man den Testusern mit, dass dieses System in einer Testphase ist, doch wenn man ihnen nach dem Test das System wegnimmt, schreien sie ganz laut auf... "Man kann doch nicht das so sehr geliebte System abbauen." ;)
Sollte der ST-Server aus seinem Nischendasein irgendwann mal aufwachen dürfen und den Weg ins gesamte Unternehmen finden (was ich nciht glaube), dann müssten wir uns auch keinen Kopf über zwei verschiedene Domains machen. ::)
Tom, Du hast Dir jetzt sehr viel Zeit und Arbeit mit dem Einrichten des ST Servers gemacht und dann kommt von Dir ".... (was ich nciht glaube), ..."
Wenn Du willst, dass Deine Arbeit nicht umsonst war, dann würde ich an Deiner Stelle das System positiv verkaufen.
Was meinst Du dazu?