Problem mit Letzte Kontakte bei Domain-Wechsel lösbar?

[schroederk]

Hallo liebe Forumsgemeinde,

wir beabsichtigen unsere eigene Mail-Domain zu vereinfachen. Aktuell haben wir noch ein Länderkürzel als Subdomain vor der Domain. Dies soll sich aber nun ändern. Grundsätzlich ein wenig Fleißarbeit oder auch ein kleiner Agent, der die alte Adresse beim Kurznamen einträgt und die neue bei Internetadresse.
Wäre da nicht die von vielen genutzten Letzte Kontakte (Recent Contacts). Damit erscheint nämlich bei jedem internen Empfänger eine Auswahlliste mit der alten und der neuen Mail-Adresse.

Meine erste und bisher einzige Idee (außer komplett löschen) wäre per Mail einen Agenten zu schicken, der die Liste bereinigt und alle Einträge mit der alten Domain rauswirft.
Oder gibt es vielleicht eine andere Lösung?

[Tode]

Theoretisch müsste es so klappen:

DBapRemoveDPABRemoveRuleSetting=1
DPABRemoveRule=komplettealtedomain.de

an alle Clients per Desktop- Policy verteilen.
Hatte allerdings gerade einen Fall, wo das trotzdem nicht alle Recent Contacts mit der alten Adresse entfernt hat... Hatte aber keine Zeit, das näher zu untersuchen.

[schroederk]

Lieben Dank für den Tipp.
Mittlerweile ist der Wunsch (warum auch immer), dass die Recent Contacts Liste korrigiert wird. Es sollen also die Einträge bearbeitet und gespeichert werden.
Damit bleibt wohl nur der Weg über einen Agenten. Ist jetzt auch kein Hexenwerk, aber jenachdem recht aufwändig, wenn und in welchem Umfang protokolliert werden soll.

[Rolandino]

Hallo Tode,
heißt der erste Eintrag nicht DPABRemoveRuleSetting=1 ?
Oder irre ich?

[schroederk]

Ich hatte mir schon gedacht, dass der Eintrag so nicht ganz korrekt sein konnte.
Eine kurze Google-Suche lieferte dann auch den Beweis.

Das Problem: Es werden wohl nur zukünftige Einträge nicht aufgenommen und nicht auch vorhandene gelöscht.
Obwohl der Name der Regel "Remove" anstelle von "Filter" etwas anderes vermuten ließe.

Ich habe daher ein kleines LotusScript geschrieben, das die Einträge löscht. (Wir konnten uns doch darauf einigen, dass die Einträge gelöscht werden können).

Auch wenn ich vermute, dass es nicht gehen wird, stelle ich dennoch mal die Frage: Kann man den Agenten automatisch starten lassen, ohne das Zutun des Anwenders?
Es wird befürchtet, dass es massig Anrufe geben wird, dass es beim Senden doppelte Vorschläge gibt, weil die Mail ignoriert und nicht auf den Löschen-Action-Hotspot geklickt wurde.

[CarstenH]

Das Problem: Es werden wohl nur zukünftige Einträge nicht aufgenommen und nicht auch vorhandene gelöscht.
Obwohl der Name der Regel "Remove" anstelle von "Filter" etwas anderes vermuten ließe.

Das war wohl nur ab der Einführung des Parameters bis zur 851 so, seit 852 macht der Parameter wohl auch das wonach er klingt, also löschen.

Ein gescriptetes Ändern/Löschen bringt ohne einen solchen Parameter im Übrigen nicht viel wenn man nicht auch die Mailadressen in sämtlichen Mails rückwirkend ändert da sich die Recent Contacts ja dynamisch immer wieder neu mit den alten Adressen füllen würden. Und gegen das rückwirkende Ändern von Mails spricht so einiges - aber das ist eine andere Baustelle

HTH
Carsten

[schroederk]

Ich muss mich doch nochmal melden.

Ich habe über die Policy die beiden Einträge bei allen Mitarbeitern gesetzt.
Gelöscht wurden dabei bisher bei keinem die bestehenden Einträge.

Daher habe ich auch ein kleines Script geschrieben, dass einfach diese Einträge rauslöscht.
Das Script funktioniert auch prima, alles wird gelöscht, aber bei einigen (nicht allen) tauchen die alten Adressen doch wieder auf.

Für 8.5.x gab es mal einen SPR dafür, aber scheinbar ist das Problem nicht gelöst. Ist bei uns nachstellbar mit Notes 9.0.1FPx und Notes 10.0.1FP3.
Dummerweise hat es bei meinen Tests ausgerechnet bei den Testkandidaten funktioniert.

Ein Ticket habe ich auch schon eröffnet, aber HCL versucht im Moment nur es mir schmackhaft zu machen die Recent Contacts komplett zu deaktivieren.
Da es etwas unter den Nägeln brennt, hat jemand noch eine Idee, wie ich vermeiden kann, dass beim Senden an einen internen Mitarbeiter die Meldung "Eintrag nicht eindeutig" kommt? Im Moment rufen die täglich (teils mehrfach) den Button zum Löschen erneut auf.

Nachtrag: Wie ich gerade feststellen durfte, kommen die Kontakte bei allen wieder rein. Nur dauert es bei dem einen oder anderen etwas länger (in Tagen)

[CarstenH]

Bei Rudi gibt's ein schönes Dokument, das die Wirkung der Parameter ganz gut erklärt - insbesondere WANN sie evaluiert werden:
https://admincamp.de/customer/notesini.nsf/85255a87005060c585255a850068ca6f/6868f00ff40835c6c125773b004d3b5c?OpenDocument

Wenn alles nichts hilft, und die Recent Contacts abzuschalten keine Option ist, kannst du deinem Script auch statt der Löschung eine Feldänderung beibringen. Das ist auf lange Sicht eh die bessere Version um ungeliebte Vorschläge loszuwerden statt sie immer wieder zu löschen oder die Ignore-Regeln immer wieder anpassen zu müssen.

Einfach den Maskennamen der falschen Vorschläge in "DPABIgnorePerson" ändern, dann sollte der Eintrag nicht mehr vorgeschlagen werden.
Falls der neue auch noch gebraucht wird muss man den Eintrag vorher duplizieren, einmal ohne Form-Änderung mit neuem Namen anlegen und mit der angegebenen Form den alten Namen "unbrauchbar" machen. Das macht ja normalerweise auch das X hinter dem Namensvorschlag den man ausblenden möchte.

HTH
Carsten

[schroederk]

Bei Rudi gibt's ein schönes Dokument, das die Wirkung der Parameter ganz gut erklärt - insbesondere WANN sie evaluiert werden:
https://admincamp.de/customer/notesini.nsf/85255a87005060c585255a850068ca6f/6868f00ff40835c6c125773b004d3b5c?OpenDocument

Wichtig wäre also der folgende Eintrag?:
NABEntriesSyncInterval=7*24*60 defaults 7 days in minutes when not present.

Ich hatte bisher nur von DPAB_PROMOTE_INC=30 gelesen, dass eine Aktualisierung auf 30 Minuten erzwingt.

Wenn alles nichts hilft, und die Recent Contacts abzuschalten keine Option ist, kannst du deinem Script auch statt der Löschung eine Feldänderung beibringen. Das ist auf lange Sicht eh die bessere Version um ungeliebte Vorschläge loszuwerden statt sie immer wieder zu löschen oder die Ignore-Regeln immer wieder anpassen zu müssen.

Würde eine Feldänderung denn tatsächlich verhindern, dass die alten Einträge wieder reinkommen? Ich würde vermuten, dass dann zwei Einträge erstellt sind: Der geänderte Eintrag und dann wieder neu der ursprüngliche.

Einfach den Maskennamen der falschen Vorschläge in "DPABIgnorePerson" ändern, dann sollte der Eintrag nicht mehr vorgeschlagen werden.
Falls der neue auch noch gebraucht wird muss man den Eintrag vorher duplizieren, einmal ohne Form-Änderung mit neuem Namen anlegen und mit der angegebenen Form den alten Namen "unbrauchbar" machen. Das macht ja normalerweise auch das X hinter dem Namensvorschlag den man ausblenden möchte.

Ich hab zu diesem Eintrag so gut wie nichts gefunden. Kannst Du mir ein Beispiel nennen?
Würde ein DPABIgnorePerson= domain verhindern, dass dieser als Vorschlag genannt wird?

[CarstenH]

Wichtig wäre also der folgende Eintrag?:
NABEntriesSyncInterval=7*24*60 defaults 7 days in minutes when not present.

Ich selbst habe bisher nur DPABRemoveRuleSetting und DPABRemoveRule benutzt, daher kann ich zu den anderen Parametern nichts sagen - schlechter kann's damit bei dir zumindest nicht werden.

Würde eine Feldänderung denn tatsächlich verhindern, dass die alten Einträge wieder reinkommen?

Nein, das ist aber auch gar nicht der Zweck. Die Erklärung lieferst du ja selbst im nächsten Satz.

Ich würde vermuten, dass dann zwei Einträge erstellt sind: Der geänderte Eintrag und dann wieder neu der ursprüngliche.

Genauso ist es. Nur mit dem Unterschied zu vorher, dass einer davon nicht mehr als Vorschlag auftauchen wird.

Einfach den Maskennamen der falschen Vorschläge in "DPABIgnorePerson" ändern, dann sollte der Eintrag nicht mehr vorgeschlagen werden.
Falls der neue auch noch gebraucht wird muss man den Eintrag vorher duplizieren, einmal ohne Form-Änderung mit neuem Namen anlegen und mit der angegebenen Form den alten Namen "unbrauchbar" machen. Das macht ja normalerweise auch das X hinter dem Namensvorschlag den man ausblenden möchte.

Ich hab zu diesem Eintrag so gut wie nichts gefunden. Kannst Du mir ein Beispiel nennen?
Würde ein DPABIgnorePerson= domain verhindern, dass dieser als Vorschlag genannt wird?

Du hast meinen Vorschlag nicht korrekt verstanden, ich erkläre es nochmal anders.

Einzelne Adressen, die der Nutzer nicht (mehr) vorgeschlagen bekommen möchte, kann er verbergen, wahlweise direkt im Vorschlag ("x" am Ende der Vorschlagszeile) oder im PAB mittels Aktion "in Schnelladressierung verbergen". Die verborgenen Adressen bekommen im PAB eine Markierung (Verbotssymbol) zur Visualisierung.

Hinweis => der Unterschied zwischen Verbergen und Löschen ist einfach aber wichtig: Löschen hilft nichts, da die Adressen wieder neu gefunden und aufgenommen werden und das Spiel von vorn losgeht. Über INI-Schalter kann man zwar rudimentär ein paar Dinge blocken aber zum einen funktioniert das nicht immer so wie gedacht und zum anderen ist die Länge eines INI-Eintrags auch begrenzt, die INI's sind schwer zu kontrollieren und so weiter.

Mein Vorschlag war jetzt schlicht die Idee, die Funktion der Aktion "in Schnelladressierung verbergen" nachzustellen, die zwei Dinge tut:
1) das Feld "Form" des Adressvorschlagsdokuments wird von "DPABperson" auf "DPABIgnorePerson" geändert bzw. bei Gruppen von "DPABGroup" auf "DPABIgnoreGroup"
2) das Feld "$DPABState" kann mehrere Werte annehmen, "50" ist der normale Wert für aktive Vorschläge, die Werte "20" und "70" verbergen. Bei meinen Tests war es immer die "70", die würde ich empfehlen.
Vermutlich aus Kompatibilitätsgründen gibt es das Feld "$DPABState" nochmal als "$DPAB_State" mit identischen Werten, also ebenfalls auf "70" setzen.

Zusammengefasst: verberge die unerwünschten Einträge statt sie zu ändern oder zu löschen, dein Script sollte da nur rudimentäre Anpassung brauchen; damit bist du auch in der Übergangsphase unabhängig von den INI-Einträgen, wenn sie denn nicht funktionieren

HTH
Carsten

[schroederk]

2) das Feld "$DPABState" kann mehrere Werte annehmen, "50" ist der normale Wert für aktive Vorschläge, die Werte "20" und "70" verbergen. Bei meinen Tests war es immer die "70", die würde ich empfehlen.
Vermutlich aus Kompatibilitätsgründen gibt es das Feld "$DPABState" nochmal als "$DPAB_State" mit identischen Werten, also ebenfalls auf "70" setzen.

Zusammengefasst: verberge die unerwünschten Einträge statt sie zu ändern oder zu löschen, dein Script sollte da nur rudimentäre Anpassung brauchen; damit bist du auch in der Übergangsphase unabhängig von den INI-Einträgen, wenn sie denn nicht funktionieren

Herzlichsten Dank, Ich habe es in meinem Script direkt umgesetzt und bin somit wieder in der Testphase. Aber das scheint mir der mit Abstand beste Lösungsansatz zu sein. 

[schroederk]

Vielleicht für alle als Hinweis, neben den beiden Feldern "$DPABState" und "$DPAB_State" mit Wert "70", muss auch noch das Feld "Form" mit "DPABIgnorePerson" anstelle von "DPABPerson" belegt werden.

Wir haben aber noch ein Problem, was ich vorher nicht so wirklich bedacht habe:
Wenn nun von extern eine Mail an meine alte Adresse gesendet wird (und ich die Mail erhalte, da ich die alte Adresse im Alias eingetragen habe)
und ich auf "Allen antworten" klicke, dann wird im CC meine alte Adresse angezeigt. D.h. ich schicke mir dann die Antwort auch immer mir selber nochmal zu.

Kann das vielleicht noch abgestellt werden, dass eigene Adressen automatisch im CC erscheinen?

[CarstenH]

Vielleicht für alle als Hinweis, neben den beiden Feldern "$DPABState" und "$DPAB_State" mit Wert "70", muss auch noch das Feld "Form" mit "DPABIgnorePerson" anstelle von "DPABPerson" belegt werden.

Das hatte ich in meiner ersten Antwort schon beschrieben, da fehlten allerdings noch die anderen Felder da ich nur flüchtig geschaut hatte was der Button macht.

Wenn nun von extern eine Mail an meine alte Adresse gesendet wird (und ich die Mail erhalte, da ich die alte Adresse im Alias eingetragen habe)
und ich auf "Allen antworten" klicke, dann wird im CC meine alte Adresse angezeigt. D.h. ich schicke mir dann die Antwort auch immer mir selber nochmal zu.

Kann das vielleicht noch abgestellt werden, dass eigene Adressen automatisch im CC erscheinen?

Das ist vermutlich kaum mit vertretbarem Aufwand zu lösen, die eigene Adresse kann sich ja nicht nur im Alias sondern auch in Gruppen oder je nach Konfiguration sogar in diversen Alias-Domains (siehe Global Domain Doc) verbergen ohne direkt im Personendokument zu stehen.