Namenumbennung wegen Heirat manchmal nicht komplett erfolgreich

[Sierra]

Hallo,

wir haben aktuell das Problem das es manchmal vorkommt, das Mitarbeiter nach einer Umbennung wegen Heirat noch immer unter Ihrem alten und neuen Namen in der clubusy.nsf stehen. Natürlich klappt so auch nicht die Planung von Terminen / Freie Zeit.

Der Grund dafür ist, das bisherige Dokumente in der Mailbox immer noch den alten Namen im Feld Busyname beinhaltet.

Komisch das wir vor kurzen eine andere Umbennung liefen hatten, die aber komplett erfolgreich verlief. Alle Termine wurden auf den neuen Namen abgehändert. Die beiden verglichenen User liegen auf unterschiedlichen Homemailservern, aber eingetlich sollte das nicht wichtig sein, oder?

Hat jemand eine Idee, wodran das liegen könnte?
Wie kann man das Problem nachträglich beheben?


Gruss,
Michael

[Cebe1]

Ist die Option in der ACL möglicherweise nicht gesetzt "Alle Leser- und Autorenfelder ändern"
bzw. "Alle Namensfelder ändern" ?

[Sierra]

Ja, aber da steht nicht der Homemailserver des betreffenden Mitarbeiters drin, sondern der Hauptserver.

EDIT: Es steht auf "Alle Lese- und Autorenfelder ändern".

[Glombi]

Wenn dort der Hauptserver steht, dann muss auch dort eine Replik der Maildatenbank liegen. Ansonsten muss der Mailserver als Administrationsserver eingetragen sein.

Die admin4.nsf muss natürlich als Replik auf allen Servern liegen und der AdminP Task auf allen Servern laufen.

Andreas

[Sierra]

Vielen Dank für Eure Hinweise.

Sieht alles eigentlich richtig aus, die admin4.nsf ist auf allen Servern und der AdminP läuft auch.

[gossifu]

Hallo,

wir hatten das Problem auch mal und da lag es am Löschintervall in den Repliziereinstellungen der admin4.nsf.
Die standen auf 7 Tagen, und wenn die Umbenennung veranlasst wurde und die User im Honeymoon waren und sich nicht innerhalb dieser 7 Tage anmelden konnten, wurden die Dokumente aus der admin4.nsf geschmissen, ohne dass die Umbenennung komplett durchlief.
Intervall auf 30 Tage gestellt und es lief wieder.

Kjeld

[Cebe1]

Wie Glombi schon richtig sagt, muss die DB auf dem Server liegen der eingetragen ist (Hauptserver).
Diese Replik muss dann natürlich auch mit allen anderen möglichen Servern replizieren.
Oder den Eintrag ändern ("Hauptserver"  entfernen und den Server dort eintragen auf dem die DB liegt).

[Sierra]

Kann man das nachträglich nochmal beheben? Bzw. gibt es da einen Agenten den man starten kann, um die Maildatenbank nachträglich zu durchsuchen?

[Cebe1]

Da gibt es den Teamstudio Configurator, damit haben wir nachträglich den Namen in der Mail-DB geändert, das ist aber mit (Lizenz-)Kosten verbunden.
Per Agent sollte es auch möglich sein.

[WernerMo]

Hallo,

beim Mitlesen ist mir noch eine Frage gekommen, die bisher hier noch nicht zur Sprache kam.

Was ist mit Notesdokumenten in eigenen Appllikationen mit Leserfeldern, in denen direkt der NotesUsername steht, die werden ja (im Unterschied zu Mail und Kalender) nicht vom AdminP behandelt?

Wir hatten den Fall bisher noch nicht, aber schon mal vorausschauende gefragt, müsste man dann alle Datenbanken "durchforsten" ob der "alte" Name in Readersfeldern vor kommt und diese dann alle "umschreiben"?

Sorry, aber wenn man das zu Ende denkt kommt man auf solche Fragen zwangsläufig.

Gruß Werner

[koehlerbv]

Solange in der ACL eingetragen ist, dass es einen Adminserver gibt und Namensfelder (oder nur Leser und Autoren) ausgetauscht werden sollen, erledigt das der AdminP auch ganz brav - egal, in welcher DB.

Bernhard

[WernerMo]

Hallo Bernhard,

Da ich nach den Leserfeldern einzelner Dokumente gefragt hatte, du aber schreibst:

...egal, in welcher DB.

darf ich das nochmals ganz genau nachfragen, würde das auch für alle Dokumente gelten, wenn man den User Umzertifiziert,

z.B. von Davd Xxxxx/NUE/BY/DE auf Davd Xxxx/MUE/BY/DE
werden dann in allen Readersfeldern aller Dokumente (einer Datenbank mit Adminservereintrag ....) die Einträge geändert? (Anhang zeigt als Beispiel so ein Readersfeld, das ich meine)

Vielen Dank für die Mühen im voraus.
Gruß Werner

[koehlerbv]

Naja, Leserfelder (Readers items) gibt es ja nur in Dokumenten, daher sollte das eigentlich klar sein. Sind die Voraussetzungen erfüllt, werden alle Namens- oder alle Leser- und Autorem-Items aktualisiert in allen in Frage kommenden Dokumenten.

Bernhard

[WernerMo]

Hallo,

danke, danke, danke und woh,

ich glaube das werde ich bei Gelegenheit mal in einer Testumgebung ausprobieren.

Wie lange dauert das, bevor ich dann prüfen kann (reichen 24h)?

Gruß Werner

[koehlerbv]

IIRC werden die letzten Änderungen am Sonntag der laufenden Woche ausgeführt.

Bernhard

[LN4ever]

Aus leidvoller Erfahrung meiner letzten Umzertifizierung kann ich sagen, daß der AdminP ein Problem bekommt, wenn der Log aller Änderungen, die er bei einem User vornimmt, größer al 64 kB wird. Er hört dann auf - irgendwo - mittendrin.

Änderungen an Namens-, Autoren- und Leserfelder werden nur am Wochenende durchgeführt. Deshalb: Umbenennungen Freitags vormittags anleiern. Dann kriegt der Benutzer die Meldung am Mittag und alle Prozesse sind Montags morgens abgeschlossen.

Gruß

Norbert

[WernerMo]

Hallo Norbert,

danke für die Info:

... daß der AdminP ein Problem bekommt, wenn der Log aller Änderungen, die er bei einem User vornimmt, größer al 64 kB wird. Er hört dann auf - irgendwo - mittendrin.

Wann tritt das auf? bzw. womit kann man das verhindern?

Gruß Werner

[LN4ever]

Hallo Werner,

das tritt auf, wenn zu dem Benutzer sehr viele Aktionen gemacht werden müssen (ich stehe halt in vielen Datenbanken namentlich drin - da hatte der AdminP-Task etwas zu tun). Verhindern kann man es meines Wissens nach nicht.

Gruß

Norbert