Beiträge von rumtifusel

Beim Versuch via AdminP Gruppen umzubennen bekomme ich mit nerviger Regelmäßigkeit diese Fehlermeldung vom AdminP:

Error looking up name on LDAP Server; See server log for further details

Dabei ist es egal, ob es eine Gruppe ist, die schon seit Ewigkeiten existiert, oder erst gerade erstellt worden ist. Ebenso ist es egal, ob die Gruppe Sonderzeichen enthält, einen sehr kurzen Namen trägt oder ein halber Roman als Gruppenname Verwendung findet.

Im Server Log ist dazu dann folgendes zu finden:

05.02.2013 15:07:32   GTR search error for "E:\Data\Dominodata\names.ft\ftgi": Query syntax error.: Query is not understandable
05.02.2013 15:07:32   Admin Process: Received the following error performing a Gruppe im Domino-Verzeichnis umbenennen request on #ACL_Mail-In_xxx_Editor_oL_Ordner_Ansichten_erstellen (Path: names.nsf): Error looking up name on LDAP Server; See server log for further details.
05.02.2013 15:07:32   Full Text message: Query syntax error.
05.02.2013 15:07:32   GTR search error for "E:\Data\Dominodata\names.ft\ftgi": Query syntax error.: Query is not understandable
05.02.2013 15:07:32   Admin Process: Received the following error performing a Gruppe im Domino-Verzeichnis umbenennen request on #ACL_Mail-In_zzz_Editor_oL_Ordner_Ansichten_erstellen (Path: names.nsf): Error looking up name on LDAP Server; See server log for further details.
05.02.2013 15:07:33   Full Text message: Query syntax error.
05.02.2013 15:07:33   GTR search error for "E:\Data\Dominodata\names.ft\ftgi": Query syntax error.: Query is not understandable
05.02.2013 15:07:33   Admin Process: Received the following error performing a Gruppe im Domino-Verzeichnis umbenennen request on #ACL_Mail-In_yyy_Editor_oL (Path: names.nsf): Error looking up name on LDAP Server; See server log for further details.

Hier im Forum konnte ich dazu leider nichts finden. Bei IBM gibt es dazu zwar einen Eintrag / eine Fehlermeldung, allerdings keine Lösung.

Kennt jemand von Euch diesen Fehler und weiß wie man ihn abstellen / beheben kann? Bei über 1000 Gruppen ist es unschön, wenn man sich nicht bei einer Umbenennung auf den AdminP verlassen kann.

hmmmm.... nach dem restart ist die anzeige jetzt auch im admin ok und tell router o zeigt auch an, dass kein OoO Service mehr läuft... komische Sache...

Aber den Server durchstarten wenn dieses Problem auftritt kann auch keine dauerhafte Lösung sein. gibt es auch eine Alternativlösung?

das muss ich testen... kann aber etwas dauern

Update: Beim Restart des Routers ändert sich nichts daran (hätte mich auch gewundert)

Der Serverneustart erfolgt heute um 20:30 Uhr. Also gibt es das nächste Update erst morgen...

Szenario:

• Anwender deaktiviert seinen OoO Service
• Es erfolgt eine Erfolgsmeldung
• Im Adminclient prüfe ich, ob es geklappt hat und der Admin Client behauptet, der OoO Service sei aktiv -auch ein Tell Router O zeigt an, dass der Service aktiv ist-
• Anwender öffnet seine Abwessenheitseinstellungen und ihm wird angezeigt, dass der OoO Service Inaktiv ist

Just in diesem Moment getestet! Das ist es ja, was ich völlig verwirrend finde

Daruf habe ich peinlichst genau geachtet, dass das nicht passiert, als wir gewechselt haben. (Umstellung an einem WE, alle Agenten deaktiviert, Status ausgelesen und weggesichert, im Service wieder alles so aktiviert, damit kein User irgendwas merkt....)

Hallo zusammen,

bei einigen unserer Anwender kommt es immer wieder zu Problemen mit dem OoO Service (nicht Agent!). Der Anwender deaktiviert den OoO eigenständig, seine Aktion wird mit einer Erfolgsmeldung quittiert aber im Admin Client wird nach wie vor angezeigt, dass der Service aktiv sei. Auch tell router O zeigt eindeutig, dass der Service noch aktiv ist. (Auch wenn zwischen dem Deaktivieren und der Abfrage 30 Minuten liegen)

Wenn nun eine neue Abwesenheit ansteht und der Serice wieder vom Anwender aktiviert werden soll, funktioniert dies auch wieder tadellos... nur hat der Service dann keine Funktion. Es werden keine Benachrichtigungen versendet.

Server: 8.5.2 FP 3
Client: 8.5.2 FP 3

Template: 8.5.2

Hat von Euch jemand eine Idee, wie man diesem Ärgernis beikommen kann?

Gruß

rUmti

Wie bekomme ich denn dann diese automatisch erstellte Gruppe aus dem Adressbuch ausgeblendet, damit sie keine Verwirkkung bei den Nutzern verursachen?!

wo finde ich denn diese beschränkung, damit genau das nicht passiert und untergruppen erstellt werden?

Auf unserem Admin Server habe ich eine Auto Populate Mail-Gruppe erstellt. Nach dem Aufruf von tell autopop process wurde sie auch schnell und nach meinen Vorstellungen gefüllt.

Jetzt habe ich aber einen Fehler in der Verarbeitung und zwei Herausforderungen, die ich noch nicht ganz durchdringe. Vielleicht hat ja von Euch einer eine Idee..

Zu erst das Problem:

• Nach dem Lauf von "tell autopop process" wurde eine neue Gruppe erstellt, die ich weder haben wollte noch verstehe ich den Grund für die Erstellung. Meine neue Gruppe trägt den Namen ZZ_Test. Die automatisch neu erstellte Gruppe nennt sich ZZ_Test-APG00001. Wieso wird deise Gruppe erstellt und wie kann ich das verhindern?

Nun die Herausforderung:

• Wir verfügen über drei Maildomains Domainname.de, Aussendienst.Domainname.de, Sonstiges.Domainname.de. Für jede dieser drei Domains möchte ich eine Autopopulate Mail-Gruppe erstellen, damit im Bedarfsfall einfach alle Personen im Haus oder in einem Teilbereich per Mail adressiert werden können. Aber um das zu erreichen fällt mir gerade nichts brauchbares ein. Zumal die Homeserver dieser drei Domains bunt bei uns gemischt sind. Die User von Domainname.de liegen auf Server A als Homeserver, die User von Aussendienst.Domainname.de liegen auf Server B und die User von Sonstiges.Domainname.de liegen auf beiden Server verstreut.

da merkt man wer ahnung hat und wer nur im dunkeln stochert...

nach dem tausch des agentes hat er immer noch nicht funktioniert. nach dem gestaltungsupdate rennt er endlich wieder.

:danke:

gelöst!

was genau das problem nun gewesen ist, kann ich zwar nicht nachvollziehen, aber ich habe den OoO Agenten in der MailDB gelöscht und durch einen Agenten einer anderen MailDB ersetzt. In den Sicherheitseinstellungen des Agenten noch die Berechtigungen angepasst und siehe da... es funktioniert wieder.

Thread kann als gelöst markiert werden.

treffer versenkt... :danke:

es war eine alte ansicht, die der anwender vor ewigkeiten selbst erstellt hat. ich vermute, dass das problem schon seit unserem wechsel auf 8.5.2 besteht, aber erst jetz aufgefallen ist. die defekte ansicht habe ich bereinigt und jetzt ist zumindest dieses problem behoben.
bleibt nur noch die macke mit der fehlermeldung beim aktivieren / deaktivieren des abwesenheitsdienstes... (s. erster post, zweiter anhang). und damit verbunden auch, dass der abwesenheitsdienst seiner aufgabe nicht nachkommt und versuchte kontaktaufnahmen, während der abwesenheit somit nicht beantwortet.

ok.. sowas dachte ich mir schon. und wie komme ich diesem problem jetzt auf die schliche um es zu beseitigen?

fixup -O -F und ein anschließendes updall -R habe das problem auch nicht behoben.

für ideen und vorschläge bin ich dankbar

ps: wo gibt es eine brauchbare doku zu den piktogrammen des designers? ich habe nichts im web oder der onlinehilfe gefunden

Na dann erstelle ich mal meinen ersten Post mit einer Frage zu den Piktogrammen vom Designer 8.5.2.

Wenn ich eine MailDB im Designer öffne wird mir ein kleines weißes X auf rotem Grund (s. Anhang - Designer-Piktogramm) angezeigt. Das ist lediglich bei dieser einen MailDB der fall. Auch schließen, speichern und erneutes öffnen bereinigt diesen Umstand nicht. Die MailDB scheint grundsätzlich ein Problem zu haben, da der Abwesenheitsdienst "zickt" (s. zweiten Anhang - FM-Designer). Sowohl der Anwender als auch ich als Admin bekommen die beigefügte FM beim Versuch den Dienst zu aktivieren / deaktivieren. Das Aktualisieren der Gestaltung blieb ohne Erfolg. Updall / Fixup habe ich "noch" nicht über die DB laufen lassen.