Namensänderung/Löschung von Notesaccount und "Modify all Names fields"

[maxritti]

Hallo zusammen,

ich habe mal eine kleine Frage zu der Option in der ACL "Modify all Names fields".
Diese ist in einer Umgebung sowohl bei den Postfächern, als auch den Archiven aktiviert.

Dies bedeutet doch, dass wenn ein Benutzer umbenannt wird oder in der OU umzieht, dies auch in allen Dokumenten mögen sie auch noch so alt sein, geändert wird. Also auch in Archiven mit Mails aus bswps. 2012.
Zusätzlich werden doch auch Löschungen von Notesusern geändert. Heisst eine Mail von einem ausgeschiedenen Benutzer hat keine Absenderadresse mehr.

Denn ich habe hier in Archiven den Status, dass es alte Emails gibt, wo genau der Absender nicht mehr drin steht, da der Notesaccount gelöscht wurde.
Komischer Weise gibt es die Mail in anderen Archiven noch, da diese Beuntzer die Mail auch bekommen haben, mit der Absenderadresse.

Momentan habe ich noch keine Idee, warum dies so ist.

Die Admin4.nsf sagt nichts, da die Löschungen schon länger her sind.

[Tode]

Ähm: Mal ne blöde Frage: Wer hat Euch denn geraten, "Modify all Names fields" in Maildatenbanken und Archiven zu aktivieren?

Warum man das NICHT tut, hast Du ja gerade selbst erkannt: Dadurch werden Mails im Nachhinein verändert oder sogar "unkenntlich" gemacht... ganz schlechte Idee, besonders was die gesetzlichen Aufbewahrungsfristen / etc. angeht...

[maxritti]

Tjo, leider eine geerbte Umgebung.

Mal schauen, wie wir damit dann weiter umgehen.

[CarstenH]

Alle Leser- und Autorenfelder ändern ist hier die (m.E. auch sinnvolle) Voreinstellung.

Reine Namensfelder bleiben unangetastet aber Felder mit Steuer- und Zugriffsfunktionalität werden geändert. Nicht nur bei Namen sondern auch bei Gruppen oft nicht unwichtig.

Gegen eine Löschung ausgeschiedener MA helfen die beiden folgenden Parameter auf allen Servern (verteilt man z.B. via Konfig-Dok. damit das niemand rauswirft oder bei neuen Servern vergessen wird):

ADMINP_DISABLE_NAMEITEM_DELETE=1
ADMINP_DISABLE_READAUTH_DELETE=1

Haken beim ADMINP_DISABLE_READAUTH_DELETE: man ändert das Verhalten damit hier grundlegend.

Alt: Dokumente, in denen der ausgeschiedene MA der letzte Eintrag in einem Leserfeld war, wurden für alle sichtbar
Neu: Dokumente, in denen (beliebig viele) ausgeschiedene MA in einem Leserfeld stehen, bleiben unsichtbar und dadurch ggf. Waise falls hier nicht anderweitig vorgesorgt wurde.

Die Technote zu den beiden Parametern schweigt sich leider über das Release aus in dem sie eingeführt wurden.
https://support.hcltechsw.com/csm?sys_kb_id=7260a641dbd31854793ff381399619c6&id=kb_article_view&sysparm_rank=1&sysparm_tsqueryId=c2ea17151b5fdcd4a2f48661cd4bcb94

HTH
Carsten

[maxritti]

Danke Carsten für den Hinweis.

Eine Frage noch:
Was gibt es für Auswirkungen, wenn wir die ACLs entsprechend anpassen?
Außer, dass dieses Durcheinander nicht mehr entsteht.

Gibt's dann etwas was nicht mehr geht bei Namensänderung oder Umzug?

[maxritti]

Und wo wir schon mal dabei sind. 
Per Script kann die Einstellung nicht geändert werden?

Wir haben einen Mailcluster. Wenn ich per Adminclient die Einstellung ändere, muss auch der Adminserver angegeben werden.
Nur wie selektiere ich die Mailfiles von Cluster 1 um nur die umzustellen und danach die von Cluster 2?

[CarstenH]

Was gibt es für Auswirkungen, wenn wir die ACLs entsprechend anpassen?
Außer, dass dieses Durcheinander nicht mehr entsteht.

Gibt's dann etwas was nicht mehr geht bei Namensänderung oder Umzug?

Solange die alten Namen als Alias in den Personendokumenten stehen bleiben sehe ich da keine Probleme.
Anderenfalls könnte es beim Antworten auf alte Mails Probleme geben.

Bei Gruppen ist das schon (etwas) heikler, hier ist swiw bei Umbenennungen kein alter "Alias" vorgesehen.
Allerdings könnte man sich hier entweder angewöhnen den alten Namen manuell quasi als Alias hinterher wieder einzutragen oder man lebt damit dass das als Altlast gewollt verschwindet. Man hatte ja schließlich einen Grund die Gruppe umzubenennen - Heirat fällt da als Grund eher aus
Das manuelle Eintragen von Aliasbezeichnern bei Gruppen/Mail-In-DB's verwende ich z.B. gern für unterschiedliche Schreibweisen (mit und ohne "/Organisation" bei Mail-In's ist oder um beim Vorhandensein mehrsprachiger Clients auf die Tatsache zu reagieren, dass deutsche Clients den Eintrag "Administrationsanforderungen" suchen während englische eben "Administration Requests" erwarten. Ohne Gewähr ob das immer noch bei allen Clients, Releases und Sprachen so ist - einfach Erfahrung aus zig Jahren.

Und wo wir schon mal dabei sind. 
Per Script kann die Einstellung nicht geändert werden?

Wir haben einen Mailcluster. Wenn ich per Adminclient die Einstellung ändere, muss auch der Adminserver angegeben werden.
Nur wie selektiere ich die Mailfiles von Cluster 1 um nur die umzustellen und danach die von Cluster 2?

Das geht auch per Script. Ungetestet und ohne Errorhandling (aus der Hilfe zusammenkopiert) aber so in etwa sollte es gehen, den Rest mit Scheife zum durchlaufen aller Mail-DB's usw bekommst du sicher selbst hin.

Code

Sub Initialize
  Dim session As New NotesSession
  Dim db As NotesDatabase
  Dim acl As NotesACL
  Set db = session.CurrentDatabase
  Set acl = db.ACL
  If acl.AdministrationServer = "" Then
    Messagebox "No admin server",, "Can't change"
    Exit Sub
    If Not acl.IsAdminReaderAuthor Then
      acl.IsAdminReaderAuthor = True
    End If
    If acl.IsAdminNames Then
      acl.IsAdminNames= False
    End If
    Call acl.Save
  End If
  Print "Done"
End Sub

HTH
Carsten

[maxritti]

Solange die alten Namen als Alias in den Personendokumenten stehen bleiben sehe ich da keine Probleme.
Anderenfalls könnte es beim Antworten auf alte Mails Probleme geben.

Ist gott sei Dank so.

Bei Gruppen ist das schon (etwas) heikler, hier ist swiw bei Umbenennungen kein alter "Alias" vorgesehen.
Allerdings könnte man sich hier entweder angewöhnen den alten Namen manuell quasi als Alias hinterher wieder einzutragen oder man lebt damit dass das als Altlast gewollt verschwindet.

Guter Ansatz.

Man hatte ja schließlich einen Grund die Gruppe umzubenennen - Heirat fällt da als Grund eher aus

Das manuelle Eintragen von Aliasbezeichnern bei Gruppen/Mail-In-DB's verwende ich z.B. gern für unterschiedliche Schreibweisen (mit und ohne "/Organisation" bei Mail-In's ist oder um beim Vorhandensein mehrsprachiger Clients auf die Tatsache zu reagieren, dass deutsche Clients den Eintrag "Administrationsanforderungen" suchen während englische eben "Administration Requests" erwarten. Ohne Gewähr ob das immer noch bei allen Clients, Releases und Sprachen so ist - einfach Erfahrung aus zig Jahren.

Das geht auch per Script. Ungetestet und ohne Errorhandling (aus der Hilfe zusammenkopiert) aber so in etwa sollte es gehen, den Rest mit Scheife zum durchlaufen aller Mail-DB's usw bekommst du sicher selbst hin.

Code

Sub Initialize
  Dim session As New NotesSession
  Dim db As NotesDatabase
  Dim acl As NotesACL
  Set db = session.CurrentDatabase
  Set acl = db.ACL
  If acl.AdministrationServer = "" Then
    Messagebox "No admin server",, "Can't change"
    Exit Sub
    If Not acl.IsAdminReaderAuthor Then
      acl.IsAdminReaderAuthor = True
    End If
    If acl.IsAdminNames Then
      acl.IsAdminNames= False
    End If
    Call acl.Save
  End If
  Print "Done"
End Sub

Oh je, hätte ich mal intensiver gelesen. 
Dann wäre das Verständnis für die Properties auch Dank Deiner Hinweise im früheren Post bestimmt besser gewesen.
Wenn es beim coding Probleme gibt, weiß ich ja wo ich fragen kann. 

HTH
Carsten

Definitiv und wie immer 1000 Dank.

[maxritti]

Noch ein kleine abschließende Frage.

Gibt es hier von HCL eigentlich eine Empfehlung bzw Vorgabe, dass man das eben nicht macht wie hier?

Finde da nicht wirklich etwas.

Danke schön und eine schöne Restwoche.

[Pfefferminz-T]

Die Empfehlung von IBM/HCL dazu ist in der Admin-Hilfe schon seit den ersten Notes-Versionen und hat sich auch in 9, 10 und 11 nicht geändert:
https://help.hcltechsw.com/domino/11.0.0/admin/admn_modifyingtheactionfieldintheacldialogbox_c.html


In most cases, the Action field for the user's mail database should be set to Do not modify Names fields. It is recommended that the administration server of a mail database match the value in the Home Server field in the user's Person document.

Note: The AdminP request Rename person in calendar entries and profiles in mail file extended makes it unnecessary for client users to use the Modify All Names fields setting. For more information, see the related topics.
Special cases
Developers of custom applications may need to set the Action field for the user's mail database to Modify All Names fields.
CAUTION: This powerful setting should always be used with care. If a user is deleted from the Domino Directory and this option is set, anywhere the user's name appears, the name will be removed. This includes information about who created a document. Legal restrictions can preclude the use of this option. If this option is used in mail files, the information about who sent mail can be deleted.

[maxritti]

Danke Thorsten