Trage den Namen aus der ID ins Pers-Dok als ersten ein
Kopiere den Schlüssel aus der ID und füge ihn ins Pers-Dok ein
Passe den Besitzer in der Mail-DB an
Repliziere ggf. das names.nsf durch die Domäne
Nun kannst du das ganze noch einmal durchführen.
Wie man im Ablaufdiagramm (zu finden in jeder Admin-Hilfe) wunderschön sehen kann, ist bis zum Punkt "Nutzerbestätigung", die seit Notes 6 standardmäßig auf "automatisch zustimmen" gesetzt ist, noch nichts weiter passiert, als im Domino Directory Änderungen vorzunehmen. Diese werden nicht von allein komplett "zurückgedreht", hier muß also händisch korrigiert werden.
Wichtig ist vor allem, dass man das Personendokument wieder auf den Stand vor der Umbenennung bringt. Dazu muß mit Hilfe der noch beim Nutzer (oder die sichere Kopie verwenden, falls ihr ID-Recovery benutzt) der öffentliche Schlüssel exportiert und wieder ins Personendokument eingefügt werden.
Weiterhin muß der neue Benutzername wieder aus allen Feldern des Personendokuments entfernt werden. Falls die Umbenennung bereits in allen Gruppen erfolgt ist (was vom Admin abhängt, wie er die diesbezügliche Frage beim Umbenennen auf seinem Bildschirm beantwortet hat), muß diese händisch zurückgedreht werden (einfach mal nach dem neuen Namen suchen in den Gruppendokumenten).
Außerdem solltest du prüfen, ob sich in dem Personendokument noch versteckte Felder finden, die mit dem Namen "AdminpOld....." beginnen. Wenn ja, ist der Prozeß hängen geblieben. In diesem Fall vor einem erneuten Umbenennen einen Agenten/eine Aktion schreiben, die in dem betroffenen Personendokument die folgenden Felder löscht. Die Schaltfläche/der Agent sollte per Aktionsmenü auf das markierte Dokument laufen und folgenden Inhalt (Notes-Formelsprache) haben:
FIELD AdminpOldCertificate :=@DeleteField;
FIELD AdminpOldFirstName :=@DeleteField;
FIELD AdminpOldLastName :=@DeleteField;
FIELD AdminpOldMI :=@DeleteField;
FIELD AdminpOldFullName :=@DeleteField;
FIELD AdminpOldAltFullName :=@DeleteField;
FIELD AdminpOldAltFullNameLanguage :=@DeleteField;
FIELD AdminpOldOwner :=@DeleteField;
FIELD AdminpOldInternetAddress :=@DeleteField;
FIELD AdminpOldShortName :=@DeleteField;
@Success
Danach die Umbennenung erneut anstoßen und sicherstellen dass der Nutzer auch inerhalb der nächsten 3 Wochen mindestens 1 Tag anwesend ist, damit sein Client die Umbenennung mitbekommt. Sonst geht nach 21 Tagen das Spiel von vorn los.
Danke für die Detailierten Antworten.
Leider geht die Geschichte weiter, und nun ist es wesentlich interessanter, warum das Umbennen des Namens in der ID fehlschlägt.
Die Clients sind auf automatische Annahme eingestellt. Ist der Anwender im Netz habe ich die Änderung im Adressbuch sofort. Nun stellt sich mir die Frage, warum der Name nicht geändert wird.
Liegt das am Client?
Ich hab keine Idee mehr. Leider sprechen wir nciht um einen Einzelfall..... 
Denn laut der Zeichnung dürfte nach dem Akzeptieren ja nichts mehr schief gehen.....Oder doch?
Fragen über Fragen.
Die Frage ist:
Wird nach dem Akzeptieren ( egal, ob manuell oder automatisiert ) ein neuer Request in der admin4.nsf erzeugt??
Nur dann kann es auch weitergehen!
Du sprichst von Netz...
Kann es sein, dass die betroffenen User eine offline-Arbeitsumgebung gewählt haben
und der Admin-Request in der LOKALEN mail.box auf die Auslieferung wartet??
Wie sehen die Einstellungen in der Arbeitsumgebung des Nutzers aus, wichtig sind hier die Reiter Server und Mail.
Ist überall dort, wo ein Servername in der Arbeitsumgebung eingetragen wurde auch dessen hierarchischer Name oder nur die Kurzform eingetragen?
Öffne die admin4.nsf auf dem Home-Server des Nutzers laut obiger Arbeitsumgebung und, falls mehrere Server vorhanden sind, die Replik der admin4.nsf auf dem Administrationsserver (das ist der, der in der ACL des Domino Directories [names.nsf] mit Namen und mit Schlüsselsymbol eingetragen ist). Replizieren die admin4.nsf auch zwischen allen beteiligten Servern (Replizierprotokolle checken, Anzahl der Dokumente vergleichen usw.).
Sofern die admin4.nsf korrekt repliziert wirf als nächstes einen Blick in die Ansicht Anforderungen \ Alle Anforderungen nach Name und suche dort den alten und/oder neuen Namen des umbenannten Nutzers. Klappe die Darstellung auf. Jetzt sollten die Anforderungen in der Reihenfolge zu sehen sein wie in der obigen Darstellung. Zu jedem Teilprozeß gibt es darunter ein Antwortdokument, das den Erfolg/Fehlschlag mit einem Symbol darstellt. Bei Fehlschlägen kann man im Dokument selbst den Grund auslesen. Fehlt das Antwortdokument zu einem Teilschritt dann fehlt die Voraussetzung zur Durchführung des Teilschrittes. Diese Voraussetzungen sind genau in dem Hilfe-Dokument in der Admin-Hilfe erklärt, aus dem ich den Ablaufplan als Bild hier eingestellt habe. Im Posting #2 von Rockwilder ist auch nochmal ein Link in englischer Beschreibung dazu .
Zur Frage der Anzahl der möglichen "zeitgleichen" Umbenennungen: diese sind prinzipiell bis auf den letzten Schritt "In Leser-/Autorenfeldern umbenennen" relativ unkritisch. Solange du hier nicht von tausenden Nutzern sprichst sollte das egal sein. Allerdings frage ich mich dann ob du wirklich Umbenennen (CN) meinst und nicht ein Verschieben in der Namenshierarchie (OU/O). Falls nicht mehrere Tausend Personen gleichzeitig heiraten würde mir sonst kein Grund dazu einfallen und dann hätten wir sicher schon in den Nachrichten von deiner Firma gehört...
Da der letzte Schritt "In Leser-/Autorenfeldern umbenennen" die einzige wirklich ressourcenintensive Aktion ist wird diese auch auf die entsprechenden Server aufgeteilt und zeitversetzt "wöchentlich", per default ist das der Sonntag, ausgeführt. Wann genau die einzelnen Schritte der Umbenennung durchgeführt werden, die laut Grafik mit stündlich, täglich, wöchentlich bezeichnet sind läßt sich im Serverdokument jedes Servers einzeln festlegen und damit Lastverteilung durchführen. Dort kann man ebenfalls die Anzahl der AdminP-Threads festlegen, die gleichzeit aktiv sein dürfen. Bei größeren Umbenennungsaktionen kann man hier die Anzahl auch temporär etwas hochschrauben und an den Intervallen etwas drehen. Mit etwas Verstand versteht sich dabei von selbst, damit nicht andere ressourcenintensive Prozesse wie Indexer, Datenbank-Virenscann oder Backups zur gleichen Zeit laufen.
