Das Notes Forum
Lotus Notes / Domino Sonstiges => Companion Products => Thema gestartet von: hallo.dirk am 18.05.10 - 23:54:47
-
Hallo,
ich sammle diese Woche auch meine ersten Erfahrungen mit 8.5:
Nachdem, wieder IBM Erwartung, der DB2 und der Consolen Server problemlos unter Linux zu installieren waren, habe ich beim Community Server (8.5 Fp1 unter Win2003) kleinere Probleme die eigentlich alle irgendetwas mit der LDAP (Domino)Auflösung zu tun haben müssen:
(Ach so, ich habe mich an die Anleitung im Info Center gehalten)
a) Personen sind übder die Suche nur noch nach Vorname zu finden
Durch hinzufügen von (sn=%s*) im LDAP Suchstring gelöst. Ist das bei mir nur so?
b) Notes 7 Clients bekommen keinen Suchserver mehr mitgeteilt, daher können die keine neuen Personen zu ihren Kontaklisten mehr hinzufügen....
Durch hinzufügen von ST_LDAP_BROWSE_ENABLED=1 in der Sametime.ini zwingend als erstes unter [DEBUG] und Ändern von VPDIR_IGNORE_BROWSE=0
gelöst.
c)Unter Notes 8.5.1 FP1 sehe ich keine onlinestati von Personen im z.B. Maileingang. (Im Plugin sehe ich sie aber)
d)Ich bekomme keine Gruppen im ST Client mehr aufgelöst????
e)Unter Notes 7 konnte man sich bisher mit "User Name/OU/O" am ST Server anmelden.
Das geht nun nur noch mit "User Name". Der Parameter ST_DB_LDAP_ALLOW_SEARCH_ON_DN=1 hat noch keinen Erfolg gebacht.
Hat noch jemand Ideen was wir falsch machen oder wo etwas fehlen könnte?
Danke!
-
Hi Dirk,
ehrlich gesagt bin ich froh, dass Du diese Probleme aufzeigst. Ich habe einige davon nämlich auch bei einem Kunden und bin mir bis heute nicht sicher, ob Unwissenheit meinerseits dahintersteckt oder ob es sich um Sametime Bugs handelt.
a) Personen sind übder die Suche nur noch nach Vorname zu finden
Durch hinzufügen von (sn=%s*) im LDAP Suchstring gelöst. Ist das bei mir nur so?
Nein, auch in meinem Fall war das so.
b) Notes 7 Clients bekommen keinen Suchserver mehr mitgeteilt, daher können die keine neuen Personen zu ihren Kontaklisten mehr hinzufügen....
Das Directory Browse Feature bei LDAP Authentifizierung ist im Standard deaktiviert, im Gegensatz zur Domino Authentifizierung. Was IBM sich hier wieder gedacht hat... ich will's gar nicht wissen. Füge in der sametime.ini folgendes hinzu, bzw. ändere es ab.
VPDIR_IGNORE_BROWSE=0
ST_LDAP_BROWSE_ENABLED=1
Folge dabei unbedingt dieser Anleitung, sonst funktioniert es nicht --> Anleitung (http://www-01.ibm.com/support/docview.wss?rs=0&uid=swg21244112)
c)Unter Notes 8.5.1 FP1 sehe ich keine onlinestati von Personen im z.B. Maileingang. (Im Plugin sehe ich sie aber)
Genau dieses Problem habe ich auch beim Kunden und noch keine Lösung dafür. Bei einigen wenigen Benutzern wird der Online Status angezeigt, bei den meisten aber nicht, obwohl sie online sind. In unserer eigenen Sametime 8.5 Community Server Installation funktioniert das einwandfrei. Bei uns handelt es sich allerdings um eine komplette Neueinführung. Den Kunden habe ich von einem Sametime 8.0.2 mit Domino Authentifizierung auf Sametime 8.5 migriert. Dabei habe ich allerdings ebenfalls eine komplette Neuinstallation des Community Servers durchgeführt und wollte lediglich die Buddylisten aus der vpuserinfo.nsf übernehmen. Nach Umstellung auf die LDAP Auth ist mir dann aufgefallen, dass damit die Personendokumente in der vpuserinfo.nsf eine andere Notation im Benutzernamen hatten.
Statt: CN=Vorname Nachname/OU=OU/O=O stand da jetzt: CN=Vorname Nachname,OU=OU,O=O
Dadurch wurde für jede Person die sich am Community Server angemeldet hat, ein neues Dokument erzeugt und somit auch eine neue leere Buddyliste. Ich habe dann mit einem Agenten alle vorhanden Dokumente auf diese Notation umgeschossen, womit die Buddylisten auch wieder bei jedem verfügbar waren. Allerdings bestanden diese überwiegend aus öffentlichen Gruppen, die nicht mehr aufgelöst wurden. Jeder Benutzer musste die Gruppen aus der Buddyliste löschen und neu hinzufügen, erst dann wurden sie wieder aufgelöst. Ich sehe das Problem erstmal bei der LDAP Auth. Gegenüber der Domino Auth läuft da sicherlich vieles ganz anders.
e)Unter Notes 7 konnte man sich bisher mit "User Name/OU/O" am ST Server anmelden.
Das geht nun nur noch mit "User Name". Der Parameter ST_DB_LDAP_ALLOW_SEARCH_ON_DN=1 hat noch keinen Erfolg gebacht.
Auch dieses Problem habe ich bei dem Kunden. Allerdings nicht bei allen Benutzern! Diejenigen, die in den Sametime Vorgaben des Clients für die Anmeldung Domino SSO aktiv haben, hatten keine Probleme bei der Anmeldung. Bei einigen funktionierte der Login aber nicht und man konnte nur noch Vorname Nachname zur Anmeldung verwenden. Allerdings handelt es sich hier überwiegend um den 8.0.2 Basic Client, nicht um Notes 7.
P.S.:
Vergiss nicht den von Ulrich erwähnten Hotfix bezgl. der Gruppenauflösung auf dem Community Server einzuspielen:
http://atnotes.de/index.php/topic,48359.0.html (http://atnotes.de/index.php/topic,48359.0.html)
Hier müssen 3 JAR-Dateien ausgetauscht werden.
-
c)Unter Notes 8.5.1 FP1 sehe ich keine onlinestati von Personen im z.B. Maileingang. (Im Plugin sehe ich sie aber)
Genau dieses Problem habe ich auch beim Kunden und noch keine Lösung dafür. Bei einigen wenigen Benutzern wird der Online Status angezeigt, bei den meisten aber nicht, obwohl sie online sind. In unserer eigenen Sametime 8.5 Community Server Installation funktioniert das einwandfrei. Bei uns handelt es sich allerdings um eine komplette Neueinführung. Den Kunden habe ich von einem Sametime 8.0.2 mit Domino Authentifizierung auf Sametime 8.5 migriert. Dabei habe ich allerdings ebenfalls eine komplette Neuinstallation des Community Servers durchgeführt und wollte lediglich die Buddylisten aus der vpuserinfo.nsf übernehmen. Nach Umstellung auf die LDAP Auth ist mir dann aufgefallen, dass damit die Personendokumente in der vpuserinfo.nsf eine andere Notation im Benutzernamen hatten.
Statt: CN=Vorname Nachname/OU=OU/O=O stand da jetzt: CN=Vorname Nachname,OU=OU,O=O
Dadurch wurde für jede Person die sich am Community Server angemeldet hat, ein neues Dokument erzeugt und somit auch eine neue leere Buddyliste. Ich habe dann mit einem Agenten alle vorhanden Dokumente auf diese Notation umgeschossen, womit die Buddylisten auch wieder bei jedem verfügbar waren. Allerdings bestanden diese überwiegend aus öffentlichen Gruppen, die nicht mehr aufgelöst wurden. Jeder Benutzer musste die Gruppen aus der Buddyliste löschen und neu hinzufügen, erst dann wurden sie wieder aufgelöst. Ich sehe das Problem erstmal bei der LDAP Auth. Gegenüber der Domino Auth läuft da sicherlich vieles ganz anders.
Da kann ich Dir etwas zu sagen: Im Domino Verzeichnis gibt es eine stnamechange.cmd, die das bei uns gemacht hat.
Allerdings musste ich noch eine mit dem Wort LDAP gefüllte ldap.csv erstellen, die im der Console bei dem Community server hochladen (Tab Name Change).
Dann ST beenden und die stnamechange.cmd starten..
-
Punkt b) ist erledigt und fuktioniert nun, danke!
Der Hotfix ist drinnen....
-
Da kann ich Dir etwas zu sagen: Im Domino Verzeichnis gibt es eine stnamechange.cmd, die das bei uns gemacht hat.
Allerdings musste ich noch eine mit dem Wort LDAP gefüllte ldap.csv erstellen, die im der Console bei dem Community server hochladen (Tab Name Change).
Dann ST beenden und die stnamechange.cmd starten..
Klasse. Danke für den Tipp Dirk!
-
Durch hinzufügen von (sn=%s*) im LDAP Suchstring gelöst. Ist das bei mir nur so?
Wo trägst du das in der System Console ein?
-
In der System Console geht das meines Wissens nicht. Nur über die Serververwaltung in der stcenter.nsf des Community Servers.
LDAP-Verzeichnis - Suche - Suchfilter zum Auflösen von Personennamen
-
Geht evtl. doch über die Console. Kann aber jetzt hier den Server nicht durchstarten
-
Stimmt. Wenn er sich intern daraus den Suchstring bastelt... daran hab ich nicht gedacht. Danke.
-
Jau, klappt. Ich kann jetzt zwar auch den Server nicht neu starten aber er trägt es brav in den Suchstring ein. Habs in der Serververwaltung vom Community Server geprüft.
-
Prima, danke für's testen.
-
Irgendwo da müsste doch auch die Ursache für das Problem mit dem Anmeldenamen und der Awareness-Anzeige in der MailDB zu suchen sein. Man kann ja auch die Attribute für die Authentifizierung konfigurieren. Dass die Awareness nicht korrekt funktioniert, könnte an eine fehlerhaften Auflösung des jeweiligen Benutzernamens liegen.
Ich meine diese Probleme hier, die Dirk und ich haben.
c)Unter Notes 8.5.1 FP1 sehe ich keine onlinestati von Personen im z.B. Maileingang. (Im Plugin sehe ich sie aber)
e)Unter Notes 7 konnte man sich bisher mit "User Name/OU/O" am ST Server anmelden.
Das geht nun nur noch mit "User Name". Der Parameter ST_DB_LDAP_ALLOW_SEARCH_ON_DN=1 hat noch keinen Erfolg gebacht.
Geht das bei Dir alles, Ulrich?
-
DWA habe ich noch nicht angebunden. Bin gerade dabei, zuhause für meine Session auf dem AdminCamp eine neue Umgebung aufzusetzen ( zum gefühlten 1.023 mal ).
Wenn ich an die Stelle komme wird sich sicherlich auch eine Lösung auftun.
-
Ich versuche mal das Problem mit der Authentifizierung nachzuvollziehen und komme zu folgendem Schluss:
Im Standard ist der LDAP Suchstring für die Authentifizierung dieser hier:
(&(objectclass=organizationalPerson)(|(mail=%s)(cn=%s)(uid=%s)))
Ein ldapsearch auf meine Person ergibt für diese Attribute als Ergebnis:
mail=Vorname.Nachname@domain.de
cn=Vorname Nachname,O=O
cn=Vorname Nachname
uid=Shortname
uid=weitere Mailadressen
Somit wundert es mich nicht, dass man sich mit "Vorname Nachname/OU/O" nicht mehr anmelden kann. Diese Notation erhalte ich nur noch über das Attribut "displayName". Ergo müsste man doch dieses Attribut auch noch zum String für die Authentifizierung hinzufügen.
-
Von der Logik her müsste es also in der System Console hier rein
-
DWA habe ich noch nicht angebunden. Bin gerade dabei, zuhause für meine Session auf dem AdminCamp eine neue Umgebung aufzusetzen ( zum gefühlten 1.023 mal ).
Wenn ich an die Stelle komme wird sich sicherlich auch eine Lösung auftun.
Zumindest in meinem Fall hat das mit DWA gar nichts zu tun Ulrich.
Bei einem Kunden von mir funktioniert unternehmensweit die Awarenessanzeige in der MailDB, bei Zugriff über den Notes Client - egal ob Basic oder Standard - nur noch für sehr wenige Benutzer. Damit meine ich nicht, dass bei sehr wenigen Benutzern die Awareness für alle die online sind funktioniert, sondern dass bei allen Benutzern nur noch eine Hand voll online User z. B. im Posteingang angezeigt werden. Und das obwohl viel mehr Mitarbeiter online sind, von denen auch Mails im Posteingang liegen.
Oh je, den Satz verstehe ich jetzt selbst kaum mehr :)
Das zweite Problem betrifft die Anmeldung am Community Server über den Connect Client oder den embedded Client. Hier verwendete der Kunde früher immer Vorname Nachname/OU/O. Seit der Umstellung auf Sametime 8.5 und damit auf LDAP Auth, funktioniert das nicht mehr. Aber das habe ich ja gerade im letzten Post versucht zu verstehen. Getestet habe ich es noch nicht.
-
Von der Logik her müsste es also in der System Console hier rein
Genau das vermute ich, ja
-
Oh je, den Satz verstehe ich jetzt selbst kaum mehr
Hab's schon verstanden ...
Es hat sich bei uns bisher noch keiner beschwert, dass ihm da was fehlt. Aber das mag nichts heissen.
Ist das bei allen Notes Versionen so, oder nur bei einzelnen?
Update: Auf die Schnelle habe das hier gefunden http://www-01.ibm.com/support/docview.wss?uid=swg21294734 und http://www-01.ibm.com/support/docview.wss?uid=swg21302993
-
Das hier http://www-10.lotus.com/ldd/stforum.nsf/55c38d716d632d9b8525689b005ba1c0/4116b7cdee5bfaf28525758c004ba0aa?OpenDocument könnte auch noch hilfreich sein
-
Es hat sich bei uns bisher noch keiner beschwert, dass ihm da was fehlt. Aber das mag nichts heissen.
Ist das bei allen Notes Versionen so, oder nur bei einzelnen?
Tritt auf im 8.0.2 Basic & Standard und im 8.5.1 Basic und Standard Client. Es betrifft alle Benutzer.
Update: Auf die Schnelle habe das hier gefunden http://www-01.ibm.com/support/docview.wss?uid=swg21294734 und http://www-01.ibm.com/support/docview.wss?uid=swg21302993
Danke! Das ist schonmal kein schlechter Hinweis. Was in meinem Fall dagegen spricht:
- Es tritt auch in Datenbanken mit 8.5.1er Mailtemplate auf
- Es sind alle Ordner und Ansichten betroffen, die Awareness bieten. Nicht nur die Inbox
Auf den Fehler der in der Sametime Server Konsole angeblich aufteten soll werde ich mal achten. Bisher war mir nichts aufgefallen.
-
Das hier http://www-10.lotus.com/ldd/stforum.nsf/55c38d716d632d9b8525689b005ba1c0/4116b7cdee5bfaf28525758c004ba0aa?OpenDocument könnte auch noch hilfreich sein
Klasse, danke. Kannte ich auch noch nicht.
Das hier zu aktivieren "Use Cananoical name for instant messaging status lookup", hatte ich allerdings bereits versucht. Das brachte nicht die Lösung. Werde das aber noch mal ausführlich prüfen. Der Server defensive Fix von IBM passt zumindest weder zur Client noch zur Sametime Server Version.
-
Nach dem Hinzufügen von "displayname" zu den Authentifizierungsattributen kann ich mich jetzt sowohl mit First Last als auch mt First Last/Org anmelden.
-
Super, danke für die Info!
-
Auch die Suche über den Nachnamen funktioniert mit der Erweiterung des Suchstrings über die System Console
-
Hui hier gehts aber ab :D
Nun nochmal zusammenfassend für Anfänger (also für mich):
Genauso wie Daniel, hab ist das alles in der stconfig getestet. Zumal auch IBM der Meinung ist, dass hier die Quelle meine Probleme ist.....
Also so wie ich es verstanden hab, trage ich alles in in die WAS Console ein, richtig?
Was steht nun bei Euch in der Sametime Console genau drin?
Und wie sieht es in der stconfig.nsf aus?
Danke.
-
Hi Dirk,
im Prinzip ist es egal aber über die ST System Console ist es auf jeden Fall der saubere Weg. Bei mir siehts jetzt so aus wie auf dem Bild.
Am ST Console Server anmelden --> Sametime System Console --> Voraussetzungen für Sametime --> Verbindung zu LDAP-Server herstellen --> vorhandene Verbindung bearbeiten --> durcklicken bis zu Personeneinstellungen erfassen.
Die Authentifizierungsattribute sind bei mir jetzt:
mail;cn;uid;displayName
Die Suchattribute sind bei mir jetzt:
mail;cn;uid;sn;displayName
Den displayName bei der Suche will ich wegen dem Awarenessproblem in der MailDB testen. Ein Ergebnis habe ich noch nicht.
-
Sieht bei mir auch so aus, wie bei Daniel
im Prinzip ist es egal aber über die ST System Console ist es auf jeden Fall der saubere Weg.
Richtig, weil der String in der stconfig über diesen Weg aktualisiert wird. Umgekehrt siehst du in der Console die Änderungen nicht, die du in der stconfig gemacht hast. Dadurch ergeben sich Inkonsistenzen bei der Konfiguration ( oder zumindest bei der Dokumentation der Installation ).
Wichtig ist auch, dass mail immer zuerst aufgeführt ist, weil es sonst Probleme mit dem Meeting Server gibt.
-
Ich habe bei dem Kunden jetzt auch alles so wie hier besprochen implementiert. Außerdem habe ich das Awareness Thema nochmal genauer betrachtet. Schlau geworden bin ich nicht daraus aber kann folgendes mal festhalten.
Die Awareness für Personen die auch wirklich online sind, funktioniert auf dem Client des Admins (Notes Standard 8.5.1FP2, Sametime 8.5 embedded, Mailtemplate 8.5.1) auf dem ich dort arbeite so:
- Manche Personen die online sind, werden in der Inbox und in diversen Ansichten auch online angezeigt
- Die meisten Personen die online sind, werden aber offline angezeigt
- Angenommen es gibt 10 Mails vom Absender X in der Inbox, dann kann es sein, dass in einer davon der Absender X als online angezeigt wird.
Bei letzterem Punkt bin ich stutzig geworden und hab mir die Mails genauer angeschaut. Zumindest hier ist ganz klar eine Regelmäßigkeit zu erkennen. Kommt die Mail des Absenders X von dessen SMTP-Mailadresse (Vorname.Nachname@domain.de) funktioniert die Awarenessanzeige. Kommt sie von seiner internen Adresse (Vorname Nachname/OU/O) funktioniert sie nicht.
Der Clou ist: Es gibt Personen, für die ist es genau umgekehrt. Da funktioniert die Awarenessanzeige wenn die Mail im From-Feld die interne Adresse stehen hat, aber nicht wenn es die SMTP-Adresse ist. Das Verhalten ist also pro Person unterschiedlich.
Ein ldapsearch auf diese Personen, um evtl. Unterschiede festzustellen, brachte mir keine Erkenntnisse. Ich kann keine Unterschiede sehen.
In den Sametime Community Vorgaben am Notes Client die Option "Use Cananoical name for instant messaging status lookup" zu aktivieren oder deaktivieren ändert gar nichts.
Das Attribut "displayName" bei den Suchattributen mit aufzunehmen brachte auch nichts.
Da ich leider nicht permanent Zugriff auf die Kundenumgebung habe, komme ich im Moment nicht weiter. Falls hier jemand dieses Verhalten irgendwie nachstellen oder bestätigen kann, wäre ich sehr dankbar.
Danke für die tolle Zusammenarbeit hier!
-
Wenn ich displayName nun hinzufügen bekomme ich diese Meldung wenn ich "weiter" betätige...?
Im Domino Konfigurationsdokument habe ich displayName aufgenommen.
Egal ersteinmal Pfingsten.....
-
Das N wird klein geschrieben in displayname. Ldap task neu gestartet?
-
bin sicher, beides Probiert zu haben...
Werde es nochmal testen...
-
Mit der Schreibweise hat es wohl nichts zu tun. Allerdings erhalte ich die Fehlermeldung für den Fall, dass ich ein Attribut angeben, das nicht vom LDAP angeboten wird.
Spricht also dafür, dass displayname nicht verfügbar war, als du die Konfiguration gespeichert hast. Du sagst, da hast es im KonfigDoc neu hinzugefügt. Dann sollte ein Neustart des LDAP task am Domino das Problem beheben.
-
Also nach einer Woche Testen klappt das mit dem Displaname immer noch nicht :-[
Auch wenn ich mit einem LDAP Tool auf den Server zugreife liefert mir die Suche nach dem Feld (Displayname=*) nichts zurück. :-:
(Server neu gestartet, Ansichten aktualisiert, tests mit neuem LDAP Server..)
Nun habe ich aber gesehen, dass es ja noch das Feld Fullname gibt, den kann ich zumindest in der WAS Console eintragen.
Nun muss ich nur noch den ST Server neu starten....
-
Gehst du mit anonymer Bindung auf den LDAP los? Dann kontrolliere doch mal, ob das Attribut überhaupt in der Liste für den anonymen Zugriff enthalten ist.
Wenn du schreibst, dass du das Attribut nicht einmal im LDAP Browser siehst, muss es in diese Richtung gehen.
-
Hi Dirk,
mach mal ne ldapsearch -h server.domain.de cn="Vorname Nachname" und schau Dir die ganzen Attribute an, die zurückgegeben werden. Wenn da displayName nicht dabei ist, ist dieses Attribut wahrscheinlich nicht im Konfigdokument des Servers auf dem LDAP Tab konfiguriert. Schau Dir einfach die Attributliste dort an und wenn es fehlt, füge es hinzu.
-
Danke Daniel, aber ob nun ldapsearch oder ein LDAP Browser liefen nicht den Wert und im konfig Dokument steht es definitiv drinnen. :-\
Aber:
Eure LDAP Server sind doch alle 8er, oder?
Mein LDAP Server stammt noch aus Quickplace Zeiten und ist immer noch Version 7. Ich habe so das Gefühl, dass hier die Ursache zu suchen ist......
Auf einem 8.5er Testsystem bekomme ich nun endlich den DisplayName angezeigt. Ein in der gleichen Domain befindlicher 7.03er Server gibt mir diesen Wert nicht zurück.
Edit: Ah nun klappt es auch unter 7, wenn ich das DD mit in der Directory Assistance aufnehme :) Habe ich da etwas verpasst??
Nun habe ich die LDAP Task auf unserem Admin Server (8.5.1.FP2) gestartet aber der gibt mir den DisplayName auch nicht zurück :-\ Oh manno ???
-
Ist da an der schema.ntf irgendwie geschraubt worden ?
-
nein s.o. :)
Einen kleinen Teilerfolg habe ich schon zumindest im Testsystem, nun muss ich das alles noch im Live einstellen....
-
Es ist der LDAP Server selber, bzw das Domino Relesase, welches den Wert nicht liefert.
Ich muss den LDAP Server mindestens auf 7.0.3 bringen, dann bekomme ich endlich meinen displayname.... :)
Hätte ich mal gleich einen 8er Server genommen. :-\
-
So Fall erledigt :D
Danke an alle Beteiligten für diese Erkenntnisse.....
@Daniel
Bisher konnte ich die Online Stati in den Ansichten mit IM_USE_CANONICAL_NAME=1 (bzw click auf diese Option in der Community) wieder sichtbar machen.
Allerdings habe ich letzte Woche FP3 installiert und nun ist wieder alles weg :-\.
Ich muss aber erst noch einen 2. Client ausfetzen, um das zu verifizieren.
@all
Hat schon einer mit den Richtlinien in der WAS Console experimentiert? Nun kann hier keine Domino Gruppen auflösen...argh....
Fehlen hier auch noch Attribute?
P.S.: Im Sametime Client werden die Gruppen aber richtig aufgelöst ???
P.P.S.: Oder hat das etwas mit der SearchBase von O=Cert zu tun?? Gruppen haben keine O=Cert
-
Das hat definitiv damit zu tun. Lege mal eine neue searchbase zusaetzlich an c= US.
Wenn du Glieck hast, funktioniert es dann. Wenn nicht musst du die ldap anbindung neu aufbauen. Ich habe dazu alles neu installieren duerfen.
-
Wenn nicht musst du die ldap anbindung neu aufbauen. Ich habe dazu alles neu installieren duerfen.
Oh ja,...
Weil ich vergessen habe, für den LDAP Server einen neuen Alias Namen zu vergeben versuchen wir uns auch drann.
Es kann doch nicht sein, dass man alle Server neu aufsetzen muss, nur wenn sich der Hostname des LDAP Servers ändert >:(, hier sehe ich Verbesserungspotenzial......
Ob ich mal einen PMR aufmache...ich hab schon so viel 8) :-\
-
Das geht auch anders Unregister, um alle Bindungen zu loesen. Dann die Deploymentplaene manuell anpassen und die Server wieder registrieren. Habe es noch nicht gemacht, aber in der Theorie ...
-
Aber man legt doch erst eine LDAP Verbindung an, den Hostnamen dieser Verbindung konnte ich bisher noch nicht verändern.
Ich müsste dann doch alle darauf verbundenen Deployments (Community und Meeting) unregistrieren, löschen, dann neu Anlegen und wieder registrieren, damit diese einen neuen LDAP Host nehmen. hmmmmm
Ich bn mir noch nicht sicher, ob ich das "Ergonomisch" finde..
die deploymentplaene manuell anpassen
Oder meinst Du direkt in der DB2 diese Veränderungen vornehmen? Ich habe noch keine Stelle gefunden wo man dem Deployment eine andere LDAP Verbindung zuweisen kann.....
Aber ich werde morgen mal weiter forschen...
-
@Daniel
Bisher konnte ich die Online Stati in den Ansichten mit IM_USE_CANONICAL_NAME=1 (bzw click auf diese Option in der Community) wieder sichtbar machen.
Allerdings habe ich letzte Woche FP3 installiert und nun ist wieder alles weg :-\.
Ich muss aber erst noch einen 2. Client ausfetzen, um das zu verifizieren.
Danke für die Info Dirk. Mittlerweile hat mich mein Kunde angerufen und doch tatsächlich berichtet, dass die Awareness jetzt auch bei ihnen wieder klappt. Allerdings hat das ein paar Tage gedauert bis es funktionierte... nun weiß ich erst nicht was genau die Ursache war.
Das mit dem FP3 hört sich ja nicht toll an. Ich versuche das auch mal zu reproduzieren.
-
Also......
Es geht relativ simpel den LDAP Server zu ändern (dies gilt zunächst nur für den Community Server unter Win):
-In der Console eine neue LDAP Anbindung definieren.
-Auf dem ST Server Domino nicht beenden!
(folgender Schritt scheint mir ein Fehler zu sein, es ist aber anders nicht lösbar)
-Im Verzeichnis Console (unter Domino Programverzeichnis) die Datei productConfig.properties
editieren und unter NodeHostName den Namen des ST Servers eintragen, bzw den in der
Konfiguration eingetragen Hostnamen verwenden.
-Starten der unregisterProductNode.bat dir nur noch nach der notes.ini fragt.
-Nun kann man in der Console die Sametime Konfiguration ändern.
-Dann wieder an dem Server die registerSTServerNode.bat starten. Diese fragt nach der Notes.ini und nach einer Notes Admin
ID.
-Fertig, ST neu starten und schon wird der neue LDAP Server genutzt.
Diese Schritte muss ich zumindest bei dem Meeting Server wiederholen.