Probleme mit einer irre gelaufenen Namensänderung

[(h)uMan]

Aktuell haben wir bei einem Benutzer Probleme mit einer irre gelaufenen Namensänderung (neuer Nachname)

1. Benutzer: hat die Namensänderung vom Notes Client (Menü Sicherheit ...) angestossen (Mail an den Admin mit einer Kopie der ID)
2. Admin: hat die Anforderung "Peter Persil" ergänzt mit der OU, also Peter Persil/OU (die OU fehlte im Step 1) und bestätigt (Mail mit ID an Benutzer)
3. Benutzer: Anmeldung (1 Tag nach der Änderung) klappt erstmal nicht wg. alter ID, im DD PersDok ist die Änderung schon durch, allerdings nicht als Mailfile Owner und in der ID-Vault ist ebenfalls die alte ID drin.
4. Admin: Mailfile Owner manuell geändert, Benutzer hat die neue ID "aufgenommen".
5. Benutzer: kein Kalenderzugriff mehr in anderen MailDB, da in den ACLs der Name nicht aktualisiert, Traveler zeigt keine Einträge mit dem alten Namen mehr an, ...

In der admin4 stehen keine Name change Request drin. Die Namensänderung liegt jetzt 5 Tage zurück.

Ich bin etwas verwirrt bzgl. der empfohlenen Einstellung in der DB ACL im Register "Advanced", Abschnitt "Admin Server" -> "Action":
1. Do not modify Name fields
2. Modify all Readers an Authors fields
3. Modify all Name fields

Der Administration Server hat in folgenden DBs aktuell die Einstellung:
- im Domino Directory: Option 2
- in der admin4.nsf: Option 2
- in den MailDBs: Option 1

Sind diese Einstellung so in Ordnung oder ist die allgemeine Empfehlung eine andere?

Die Namensänderung würden wir dann erneut durchführen, allerdings vom Admin aus getriggert.

Für Tipps danke ich schon mal!

[Heiggo]

Tja, leider hat ein Nutzer nach wie vor die Möglichkeit (aus alten Zeiten von R4/5) die Möglichkeit, einen neuen Namen anzufordern. Leider eine extrem manuelle Angelegenheit, da dann der AdminP nicht greift. Als aufmerksamer Admin arbeitet man derartige Anforderungen nicht ab, sondern setzt die kurz um in einen AdminP-Prozess. Kostet nur eine Rückfrage beim Nutzer und 3 mausklicks im Admin-Client.

Greetz

Heiggo

[(h)uMan]

das hat der Admin jetzt kennengelernt ;-)

Aber wie verhält es sich mit den ACL Einstellungen bzgl. Änderung der Leser, Author, Name Felder?

[(h)uMan]

wir haben das Aktionsfeld in der ACL jetzt wie von IBM empfohlen eingestellt.
siehe http://publib.boulder.ibm.com/infocenter/domhelp/v8r0/index.jsp?topic=/com.ibm.help.domino.admin.doc/

- im Domino Directory: Do not modify Name fields
- in der admin4.nsf: Do not modify Name fields
- in den MailDBs: Modify all Name fields

Dann schauen wir mal, wie die erneute Namensänderung läuft ...

[Driri]

In den Maildatenbanken ist es aber unglücklich, alle Namensfelder ändern zu lassen. Z.B. ist "From" ein Namensfeld und wenn ein Benutzer gelöscht wird, fliegt der bei dieser Einstellung auch aus dem From-Feld in den Mails heraus.

[Axel]

In den Maildatenbanken ist es aber unglücklich, alle Namensfelder ändern zu lassen. Z.B. ist "From" ein Namensfeld und wenn ein Benutzer gelöscht wird, fliegt der bei dieser Einstellung auch aus dem From-Feld in den Mails heraus.

Ja schon, aber was pasiert mit den ganzen Kalendereinträgen des Users wenn sich der Name ändert?

Ich stehe bei uns hier in absehbarer Zeit vor der Aufgabe fasst alle User umzubenennen bzw. den Certifier zu wechseln. Ich bin mir hier etwas unsicher welche Option bei den Mail-DBs die beste ist.

Axel

[MCPvsTron]

Hallo,

wie Driri schon sagte ist dies keine glückliche Option. Dies war bei uns aus versehen mal eingeschaltet, dann fehlte jegliche Historie bei gelöschten Anwendern, auch kann dann nach deren Mails nicht mehr gesucht werden.
Die relevanten Felder für den Kalender werden durch den AdminP doch abgearbeitet.

Viele Grüße
Christian

[Driri]

Wir hatten bei unserer großen Rezertifizierungsaktion vor ein paar Jahren auch zuerst die Einstellung "Alle Namensfelder ändern" gesetzt und dann bei den ersten Rezertifizierungen halt genau das beschriebene Problem.

Daraufhin haben wir die Einstellung geändert auf "Nur Leser- und Autorenfelder ändern" und damit werden die wichtigstens Felder vom Adminp abgearbeitet.

Dadurch bleiben ggf. an einigen Stellen alte Namen zurück. Das finde ich aber immer noch besser verkraftbar, als plötzlich in den Mails den Absender nicht mehr sehen zu können.

[(h)uMan]

aufgrund der hier mitgeteilten Empfehlungen bzw. Hinweise haben wir die Einstellung nun wie folgt festgelegt:

- im Domino Directory: Do not modify Name fields
- in der admin4.nsf: Do not modify Name fields
- in den MailDBs: Modify all Readers an Authors fields

Allerdings kann einfach so eine erneute Namensänderung mit gleichem Namen natürlich nicht durchgeführt werden. Wenn`s keine Änderung beim Namen oder der OU gibt, kann die Namensänderung im Admin Client nicht ausgeführt werden :-)

In einigen DBs sind die Rechte in der ACL leider nicht über Gruppen eingetragen, sonder direkt über den Notes Benutzernamen.
Wie bekommt man nun in den ACLs der anderen DBs den alten Namen mit dem schon vorhanden neuen Namen ersetzt, ohne das manuell in jeder DB machen zu müssen?

[Driri]

Ich bin kein Admin, aber konnte man einzelne Adminp-Prozesse nicht erneut ausführen lassen ?

[(h)uMan]

wenn die relevanten adminp Prozesse noch in der admin4.nsf stehen, dann ja.

Aber wenn diese nicht drinstehen, was dann?

[MCPvsTron]

Hallo,

du könntest einfach einmalig zurück auf den alten Namen ändern. Warten bis dafür alle AdminP Prozesse durchgelaufen sind und erneut die Änderung auf den neuen Namen initiieren.
Dank unserer tollen strategischen Umstrukturierungen sind bei uns manche Anwender bestimtm schon 4-5mal umbenannt (Certifier gehört ja auch dazu) worden...

Grüße
Christian

[(h)uMan]

haben den User neu mit Angabe der OU über den Admin Client zertifiziert. Damit ist seine jetzt User.ID, sein Name in den Gruppen und die Einträge in der ACL seiner MailDB ok.

Rest manuell geändert.

Bei zukünftigen Namensänderung wird es besser laufen.

Danke an alle für die Tipps!!!