Das ist leider alles andere als trivial. Bei einem Einzel-Meeting hast Du es mit einem einzigen Dokument zu tun. Ein Serientermin besteht aus einem Haupt-Dokument (unsichtbar für den Benutzer) und mindestens einem Antwortdokument, das in der Kalenderansicht angezeigt wird.

Hier im "Calendaring & Scheduling Schema" ist das alles sehr genau beschrieben... Du musst Dich -fürchte ich- damit beschäftigen, um eine "einfache" Weiterleitung umzusetzen.

Meist genügt es, eine neu Dummy-Regel zu aktivieren, zu deaktivieren und dann zu löschen. Dabei werden die Felder bereinigt.

Check doch mal das CalenderProfile und suche nach Feldern $FilterFormula_. $FilterFormula_0 ist intern reserviert! Alles oberhalb, also $FilterFormula_1-x sind aktive(!) Regeln. Ich habe im Profil schon Regeln gefunden, für die im Client kein Regel-Dokument mehr existierte.

Im besten Fall viele Fehlermeldungen und im schlimmsten Fall sind Dinge unbrauchbar.
Kümmert euch früh darum und löscht den Admin User erstmal nicht, sondern entzieht ihm nur die Rechte. Dann lassen sich durch die Fehlermeldungen im Log die Datenbanken finden, die man vergessen hatte

Noch besser ist es aber, wenn ihr vor dem Ausscheiden der Person (oder wenigstens vor dem Löschen des Personendokuments) mit einem entsprechenden Tool die Signaturen prüft und umstellt.

Ist aber auch leichter gesagt, als getan. Ich finde nach zwei Jahren immer nochmal etwas, dass neu signiert werden muss.

Hallo Poldy_06,
 
die Meldung "Die gemeinsame Notes-Anmeldung mit dieser ID-Datei ist fehlgeschlagen."
impliziert das Ihr NSL (Notes Shared Login), also SSO nutzt. Das bedeutet, dass die ID mit Microsoft Kerberos
lokal auf dem PC bzw. der virtuellen Maschine (falls TS und/oder VDI) verschlüsselt wird.
 
Wenn man diese ID nun nimmt und auf einen anderen PC kopiert, so wie das vermutlich
über MarvelClient Roaming bei euch konfiguriert ist, wird diese verschlüsselte ID auf einem anderen PC bzw. einer anderen virtuellen Maschine nicht mehr lesbar, da sie dort nicht entschlüssselt werden kann. Daher die Meldung
vom Notes Client.
 
Wir können das allerdings so konfigurieren, dass die ID in so einem Fall automatisch erneut vom IDVault heruntergeladen wird, ohne dabei die Benutzerkonfiguration bzw. Clientkonfiguration zu verlieren.
 
An der einmaligen Passwort Eingabe auf einem anderen/neuen PC kommt der Benutzer
aber nicht herum. Das liegt an der Implementierung und Mechanik von NSL. Wichtig, falls es sich hierbei um eine TS bzw. VDI Installation handelt, kann die verschlüsselte ID erfolgreich geroamt werden, dann muss man allerdings auch die benötigte .bin Datei mit einbeziehen, so dass man am Ende von Maschine zu Maschine wechselt und SSO durchgehend funktioniert.
 
Ich würde mich freuen wenn Du einfach auf uns zukommst, damit wir Dich dabei unterstützen können. Schreib uns doch bitte eine eMail an support@panagenda.com , einfach mit einem Hinweis auf diesen Thread.

Viele liebe Grüße
Christoph & Marc von panagenda

Moin!
Danke für Deine Antwort.
Nein, es gab keine Änderungen, daher glaube ich nicht, dass die obere Richtlinie sich durchsetzt. Aber ich habe einen Case bei HCL aufgemacht und werde mal sehen, was da raus kommt.
Gruß
Poldy