Persönliches Adressbuch aktuell halten

Hi,

Notes-Bordmittel gibt es hierfuer nicht.

Andreas

Der Trick ist, das globale Adressbuch runterzureplizieren und sich das als persönliches Adressbuch einzubinden.

Wie du schon selber geschrieben hast, wenn man einen Datensatz kopiert, dann stehen die 2 Datensätze in keinem Zusammenhang mehr zueinander

Also das globale Adressbuch runter zu replizieren kann eine sehr gefährliche Aktion werden. Vor allem bei Benutzern, da wenn diese es lange Zeit nicht mehr replizieren auf einmal gelöschte Personen/Gruppen wieder auftauchen.

Besser ist es einen mobilen Verzeichniskatalgo zu erstellen und diesen dann auf die Clients zu verteilen.
Damit hat jeder alle Firmenadressen lokal zur Verfügung, muß diese nicht ins persönliche Adressbuch kopieren und es kommt zu keinen Replizierungsproblemen

[color=CC0000]Bitte aufs Themenpräfix achten[/color]

Natürlich nichts gegen den mobilen Verzeichniskatalog (genau dafür ist er ja da), aber wenn jemand eine lokale Replik des DD hat und dadurch durch längere Nicht-Replikation Leichen fröhliche Urständ feiern können, dann sind da in der Administration schwerste Fehler gemacht wurden: Vorrangig zu hohe Rechte für Benutzer (Erstellen von Dokumenten), Nicht-Anfassen der Standard-Lebenszeit für Deletion Stubs und so weiter.

Bernhard

koehlerbv

Also an falschen Rechten liegt das definitiv nicht, da die Dokumente ja auch von einem Admin angelegt wurden und damit bei fehlenden DeletionStubs auf dem Server deswegen auch wieder hochrepliziert werden. Das funktioniert selbst dann wenn der replizierende Benutzer keine Recht zum Erstellen von Dokumenten hat.

Und wie hoch soll man denn die Lebenszeit von Deletion Stubs setzen um jedem Problem aus dem Weg zu gehen ? Auf x Jahre ?

Ich hatte es schon oft genug, daß ein User so eine lokale Replik hatte, irgendwann mal die Replizierung deaktiviert wurde (z.T. auch von ihm selbst) und dann erst nach einem Jahr wieder eingeschalten wurde, weil es ihm vorher nicht aufgefallen ist

Zitat

taurec schrieb:
Also an falschen Rechten liegt das definitiv nicht, da die Dokumente ja auch von einem Admin angelegt wurden und damit bei fehlenden DeletionStubs auf dem Server deswegen auch wieder hochrepliziert werden. Das funktioniert selbst dann wenn der replizierende Benutzer keine Recht zum Erstellen von Dokumenten hat.

Wenn der Benutzer kein Recht hat, Dokumente anzulegen, dann wird da nix wieder von lokal auf den Server repliziert - egal, ob es sich lokal um ein Dokument handelt, das auf dem Server gelöscht wurde (vor langer Zeit) oder ob man sich lokal an diese DB mit einer ID mit den entsprechenden Rechten setzt und ein neues Dokument erstellt (und dann wieder mit der minderbemittelten ID repliziert).

Zudem: Hier scheint es sich ja auch nicht um das DD zu handeln, sondern weitere Adressbücher - es wurden ja "Kundenadressen" genannt.

Völlig ausser Frage ist natürlich, dass der mobile Verzeichniskatalog die bessere Lösung ist - wenn dessen Angaben ausreichen (Telefonnummer, Geburtstag, Anschrift ...).

Wegen der Frist zum Entfernen der Deletion Stubs: Natürlich gibt es da keine absolute Sicherheit, und auch ein lieber Admin kann irgendwo eine Uralt-Replik lokal rumkullern haben und erwischt die nach Jahren zum Replizieren. Mit diesen Fristen verfahre ich (insofern das überhaupt mein Job ist) eher pragmatisch: Wenn in einer Anwendung schon zu erwarten ist, dass es Anwender mit bestimmten Rechten gibt, die aber ... naja, unbedarft sind und auch mal auf der Replikatorseite herumklicken, dann setze ich die Frist auf einen praktikablen Wert hoch. In anderen Fällen mache ich das, wenn es geknallt hat - aus "disziplinarischen Gründen"

Bernhard

Das Problem lässt sich unabhängig von den Rechten und dem CutOffInterval sehr pragmatisch verhackstücken: es wird schlicht und ergreifend der Haken "Replicate or Copy documents" entfernt für die Usergruppe.