Umzug eines Users in der Noteshierarchie - Bearbeiten von Besprechungen

[maxritti]

Hallo zusammen,

augenscheinlich haben wir gerade ein kleines Problemchen.
Und zwar haben wir einen Teil unserer Notesuser in der Hierarchie verschoben.
Bislang waren die User so aufgebaut: "Max Chef/OUa/OU1/ORG". Also in der OU-Ebene bis Tiefe 2.
Nun wollen und haben wir die nach "Max Chef/OU1/ORG" normiert.

Mit der Folge, dass eine Sekretärin bei ihrem Chef im Kalender keine existierenden Besprechungen mehr ändern kann.
Also keine Teilnehmer mehr hinzufügen oder entfernen kann.
Dabei ist die Sekretärin in der OU-Ebene schon korrekt, nur der Chef wurde umgezogen.

Im Kalenderprofil steht der Chef bereits richtig mit dem neuen Namen drin.

Versucht habe ich mal das Design der Maske bei Hide-When Formel zu untersuchen.
Aber da geht es ja ganz schön hin und her mit temporären Felder.
Da komme ich nicht wirklich weiter.

Hat dazu jemand eine Idee, warum der Umzug des Chefs in der OU so ein Problem nach sich zieht?

[maxritti]

Ich habe gerade diese Technote gefunden:

http://www-01.ibm.com/support/docview.wss?uid=swg21258435

Passt aus meiner Sicht nicht wirklich, denn die DB vom Chef wurde ja bearbeitet.
Aber die dort genannten Felder haben in der Tat noch den alten Wert.

Dann werde ich den Agent wohl mal rennen lassen...

[maxritti]

Nur der Vollständigkeit halber.

Der Agent, den IBM da gebaut hat, funktioniert. Nun sind die Benutzer wieder glücklich.

[Pfefferminz-T]

Ich würde empfehlen, dass ihr mal den AdminP überprüft... Einstellungen für eure Maildatenbanken, AdminServer, Zugriffsberechtigungen, die Prozesse in der admin4.nsf, ...

Normalerweise ist hier kein manuelles Eingreifen notwendig.

[maxritti]

Hi Thorsten,

jau. Werden wir mal machen.
Eigentlich hätte ich auch keine Probleme erwartet. 

Eventuell liegt das momentan bei uns an dem Versionsmischmasch.
Dominoserver 9.0.1FP3, Notes Client 8.5.3FP5 und Mailtemplate 8.5.3.

Leider kommen wir mit dem Update der Clients auf 9.0.1 und dem Mailfile nicht nach, da wir da noch abhängig von anderen Applikationen sind.

[Pfefferminz-T]

Die verschiedenen Versionen haben da meiner Meinung nach keinen Einfluss. Bei den Administrationsprozessen gab es fast keine Änderungen. Wichtig ist, dass die Vorgaben für den AdminP stimmen und dass ihr versteht, was welcher einzelne Unterprozeß macht. Die Admin-Hilfe gibt da schon einige Informationen zu.

[maxritti]

Wenn ich mir den Agenten so anschaue, aktualisiert der die Einträge im Kalender des Benutzers von dem alten Namen zum neuen Namen.
Das müsste dann ja der AdminP Eintrag "Person in den Kalendereinträgen und Profilen der Maildatei umbenennen" sein.
Und der ist bei dem User, wo es das Problem gab, grün abgehackt. So wie anderen Einträge zu der Person in der Admin4.nsf auch.

Einzig ein Eintrag bei dem User in der Admin4.nsf "In Personendokument umbenennen" ist noch mit einem Kalendersymbol versehen.
Die Adminhilfe sagt als Auslöser, "Die Person greift auf einen Server zu und bestätigt den neuen Namen".
Merkwürdigerweise bekommt der Benutzer diese Frage nicht, ist aber auf seinem Mailserver aktiv.
Aber das Personendokument im NAB wurde geändert. Dort steht der neue Name an Position 1 des Fullnames.

Als Adminserver auf der Mail-DB ist der Mailserver des Benutzers eingetragen.
LocalDomainServers haben ebenfalls Managerrechte auf dem Mailfile.

Aber ich lese auch noch mal in der Admin-Hilfe. Versprochen.   
Eventuell findet sich dort noch eine Erklärung.

Danke auf jeden Fall schon mal für Deine Einschätzung.

[Pfefferminz-T]

Bitte dann auch genau lesen 

Personen im Domino-Verzeichnis umbenennen
Auslöser: Person, die auf einen Server zugreift und den neuen Namen bestätigt.
Durchführung: Gemäß der Einstellung "Intervall" im Abschnitt "Administrationsprozess" des Serverdokuments.
Ergebnis: Der Name des Benutzers wird im entsprechenden Personendokument und in den Gruppen im Domino-Verzeichnis aktualisiert. Die Administrationsanforderungen "In Personendokumenten umbenennen" und "Person in der Liste der ungelesenen Dokumente umbenennen" werden gestellt.

In Personendokumenten umbenennen
Auslöser: Erfolgreiche Ausführung "Person im Domino-Verzeichnis umbenennen".
Durchführung: Gemäß der Einstellung "Ausführung von Anforderungen einmal täglich um"
Ergebnis: Der Name des Benutzers wird im Domino-Verzeichnis in anderen Personendokumenten, aber nicht im eigenen Personendokument, aktualisiert. Wenn es sich bei dem Benutzer beispielsweise um einen Administrator handelt, kann der Name im Feld "Besitzer" oder "Administrator" im Personendokument eines anderen Benutzers enthalten sein.

In Deiner Beschreibung bringst Du beide durcheinander. Der eine ändert das Personendokument des Nutzers, der andere ändert den Namen in anderen Personendokumenten. Meines Wissens nach kommt seit der Version 6.5 nicht mehr die Anfrage, ob der Anwender den neuen Namen übernehmen will. Aber der Anwender muss sich am Server authentifizieren...

[maxritti]

Bitte dann auch genau lesen 

Okay, das werde ich dann (hoffentlich) beherzigen. 

Aber ist es denn nicht so, dass folgende Anforderung, die ja bei uns und dem User erfolgreich abgearbeitet wurde, eigentlich das hätte machen sollen, was der Agent dann manuell nachgezogen hat?

Person in Kalendereinträgen und Profilen der Maildatei umbenennen
Auslöser: erfolgreiche Ausführung der Anforderung Person in Datenbank für freie Zeit umbenennen.
Ausführung auf: dem Home-Server der Person.
Ausführung: sofort
Ergebnis: Der Name der Person wird im Kalenderprofil ihrer Maildatei und in Termindokumenten geändert. Wenn der allgemeine Name der Person geändert wurde und sich der allgemeine Name im Titel der Maildatei befindet, ändert sich der Titel der Maildatei, um dem neuen Namen zu entsprechen. Der Name wird auch geändert, wenn er im Feld Leitung für künftige Besprechungseinladungen enthalten ist.