Hallo miteinander,
wir wollen unsere Notes Client Konfiguration automatisieren.
Wir nutzen dafür eine vorgefertigte Notes.ini mit dem Parameter
"ConfigFile=config.txt". Das ganze funktioniert auch recht gut nur ein Punkt gefällt uns nicht.
Wir möchten gern, daß der Pfad zum ID-File im Arbeitsumgebungsdokument gespeichert wird.
Igend jemand eine Ahnung welcher Parameter dafür notwendig ist?
Gruß Enrico
Ich würde dringend abraten, in den Arbeitsumgebungen die ID standardmäßig mit Pfad und Dateiname zu hinterlegen. Der NOTES.INI-Eintrag
KeyFilename=X:\appsuser\notes\xxx.id
reicht dafür voll und ganz aus.
Bei einer Restrukturierung der Notes-Umgebung kommst du an die NOTES.INI der Benutzer leicht dran, an die Einträge im persönlichen Adreßbuch hingegen nur mit Notes-Mitteln - aber genau da liegt die Schwierigkeit des Unterfangens. Nach einer Umstellung muß der ANwender erst einmal Notes starten (und dafür brauct er die ID), damit deine in weiter Zukunft liegende Routine Änderungen vornehmen kann.
Ist rein prinzipiell richtig. Das Problem mit der Anpassung der Persönlichen Adreßbücher ist für uns keines, da wir die komplette Konfiguration(Notes-Data) auf Netzlaufwerken liegen haben.
...und für die Anpassung der names.nsf haben wir ein uns ein Tool gebastelt, welches die notwendigen Änderungen vornimmt.
Also da keine Angst. Das Problem ist, das User teilweise noch mit einer alten ID arbeiten, um verschlüsselte Dokumente zu lesen.
...und jedes mal, wenn sie Notes mit dieser alten ID beenden, startet es natürlich auch wieder mit dieser.
Dem entsprechend, wäre es die einfachste Lösung, meines Erachtens, daß richtige File in der Arbeitsumgebung anzugeben.
Gruß Enrico
Da bastelt mit dem Tool doch die komplette Bezeichnung von Pfad und richtiger UserID-Bezeichnung in die Arbeitsumgebungsdokumente der Benutzer in das Feld USERID rein.
Wenn das Tool zur Bearbeitung der persönlichen NABs allerdings von denen gemacht wurde, die euch den Bock mit einer "Umbenennung durch Neuerstellung" von ID-Files geschossen haben, wäre ich vorsichtig.
Ihr habt da nämlich ein Riesenproblem. Die geschäftsrelevanten Mails müssen heutzutage aus rechtlichen Gründen oft 10 Jahre aufgehoben werden. Und Aufheben heißt an der Stelle auch "entschlüsselbar halten".
Und wenn ihr dafür nach Tools Ausschau haltet, scheint der Bock ja nicht nur zwei oder drei Benutzer getroffen zu haben, sondern vielleicht ein paar Hundert.
Ich kann mir lebhaft vorstellen, wie ihr derzeit den Fehler aushaltet. Macht besser ein Projekt daraus, alle mit alten IDs verschlüsselten Dokumente aufzuspüren und in den Datenbanken in Ordner zu schieben und dann zu entschlüsseln und mit der neuen, gültigen ID wieder zu verschlüsseln und anschließend die alten IDs einzustampfen.
Das kostet vielleicht ein paar Beratertage, aber danach seid ihr ein Problem los, während ihr jetzt wurschtelt und nur darauf hofft, daß das Prolem irgendwie von selbst immer kleiner wird und schließlich ganz verschwindet.
Da die Mitarbeiter immer wieder einmal die alte ID verwenden müssen, werden sie damit teilweise auch neue Dokumente erstellen, in denen Personen mit falschem (altem) Namen in Workflows und Leserfeldern stehen usw., denn wenn die "verfluchten verschlüsselten Mails" nicht in lokalen Repliken liegen, müssen die Menschen ja auf den Server kommen können.
