Domino Administratoren können mit Hilfe des Domino Administrator Clients Benutzer löschen und hierbei entscheiden,
- was mit dem Mailfile (sowie ggf. Den Roaming Files) des Benutzers geschehen soll
- wie die Benutzer-ID des Benutzers im Vault behandelt werden soll
- ob der Benutzer in eine Negativgruppe aufgenommen werden soll, um ihm die Zugriffberechtigungen auf sämtliche Server zu entziehen
Auf jeden Fall wird durch diesen Vorgang das Personendokument gelöscht.
Diese "Bordmittel" werfen dann mehr oder weniger große Fragen und Probleme auf, wenn der Benutzer nach einiger Zeit doch wieder "reaktiviert" werden soll (z.B. nach Rückkehr aus der Elternzeit oder Wiedereinstellung eines ausgeschiedenen Mitarbeiters). Hierzu haben wir unterschiedliche Vorgehensweisen bei unseren Kunden festgestellt:
1. Neuregistrierung des Benutzers
2. Wiederherstellung / Weiterverwendung früherer Daten
Beide Verfahren haben wir nachfolgend mit ihren Randbedingungen skizziert. Diese setzen voraus, dass auf den Servern die üblichen Funktionen (serverbasierte Zulassungsstelle, ID-Vault, MultiUser Client Installation, automatische Client Konfiguration) eingerichtet wurden:
1. Neuregistrierung des Benutzers
HINWEIS: Bei dieser Vorgehensweise ist vorab zu bemerken, dass die Neuregistrierung des Benutzers zur Erstellung einer neuen Benutzer-ID (mit neuen Schlüsseln) führt. Somit sind alle zuvor von diesem Benutzer (mit seiner ehemaligen ID) verschlüsselten Daten (Archive, lokale Datenbanken, etc.) sowie bislang vom Benutzer angelegten (und in seinem bisherigen ID File gespeicherten) Dokumentschlüssel verloren. Somit raten wir von dieser Methode DRINGEND ab, da es erfahrungsgemäß stets zu Folgeproblemem führt.
Bei der Registrierung prüft der der Domino Administrator Client, ob es einen Benutzer mit gleichem hierarchischem Namen im Directory oder im Vault gibt und läßt ggf. keine Registrierung zu, wenn der Name nicht eindeutig sein würde.
Stellt man nun fest, dass die bisherige Benutzer-ID noch im Vault vorhanden ist (entweder in Ansicht "Vault Users" oder Ansicht "Inactive User IDs") greifen Administroren nahezu logischerwiese dazu, diese noch vorhanden "Reste" aus dem Vault zu löschen und eine erneute Registrierung zu versuchen.
Das Ergebnis wird möglicherweise vergleichbar sein, da die Ansichtsindizes des Vault noch veraltet sein können/werden. Um diese zu aktualisieren, kann CRTL-SHIFT-F9 verwendet werden. So läßt sich der Benutzer im zweiten Anlauf registrieren (wenn man die ggf. zuvor schon angelegten Mailfile/Roaming Files mit anderem Namen erstellt oder überschreibt). Alles gut? Weit gefehlt.... Bei der Inbetriebnahme des Clients zeigen sich folgende Effekte:
Der Grund für die fehlgeschlagene Inbetriebnahme liegt nicht sofort auf der Hand, ist doch das Benutzer-ID File im Vault vorhanden. Die Ursache zeigt sich erst nach einem Blick in die Admin4.nsf:
Durch die beiden Versuche der erneuten Registrierung sind zwei Zertifizierungsaufträge erstellt worden (und der erste erfolgreich abgearbeitet). Die aktuell im Vault liegende Benutzer-ID ist somit noch nicht zertifziert. Um dieses zu erreichen, ist das oben markierte (zeitlich spätere) Auftragsdokument abzuarbeiten (>TE AdminP Process all). Vor einem erneuten Inbetriebnahmeversuch sind am IBM Notes Client alle bislang erstellten (unvollständigen) Konfigurations(teil)ergebnisse zu löschen (Windows Verzeichnis der MultiUser Installation).
Fazit: Einigermaßen aufwendig und störungsbehaftet !
2. Wiederherstellung / Weiterverwendung früherer Daten
Um einen zuvor gelöschten Benutzer wiederherzustellen sind:
- Mailfile (und ggf. Roaming Files) bereitzustellen
- Benutzer-ID (z.B. durch Aktivierung im Vault) bereitzustellen
- Personendokument (mit Referenzen auf MailFile, RoamingFiles, sowie Public Key entsprechend der im Vault vorliegenden Benutzer-ID) anzulegen oder wiederherzustellen
Mailfile und RoamingFiles bereitstelllen
Die einfachste Methode hierfür ist, diese beim Löschen eines Benutzers nicht mit zu löschen (oder die entsprechenden Löschaufträge in der "Admin4.nsf" nicht zu bestätigen). In diesem Fall sind bei Rückkehr des Benutzers alle ehemaligen Daten unverändert vorhanden. Wurden diese jedoch gelöscht, so kann nur eine Dateiwiederherstellung aus einem (hoffentlich vorhandenen) Backup helfen. Wenn auch dieses nicht möglich ist, bietet sich nur die Methode "1. Neuregistrierung des Benutzers" mit allen seinen Nachteilen an.
Benutzer-ID bereitstellen
Findet sich die Benutzer-ID noch im Vault (Ansicht "Inactive User IDs") , so ist diese durch die Ansichtsaktion
Personendokument bereitstellen
Personendokumente können interaktiv oder über die Benutzerregistrierung (Domino Administrator) erstellt werden. Bei interaktiver Erstellung ergibt sich die Schwierigkeit, dass die Felder für die Benennung der RoamingFiles nicht bearbeitbar sind. Bei Verwendung der Benutzerregistrierung werden jedoch neue Dateien (mit anderen Namen und neuem Inhalt) erstellt. In jedem Fall fehlen die Public Keys des Benutzers. Um dieses Problem zu umgehen, bleibt nur eine Empfehlung/Vorgehensweise: Vor der Löschung des Benutzers ist das Personendokument in eine separate Backup-Datenbank zu kopieren, um sie dann mit allen ehemaligen (korreten und vollständigen Informationen) in diesem Schritt wieder in das Domino Directory zurück zu kopieren.
Fazit: Vor der Löschung Personendokumente sichern, IDs im Vault deaktivieren bietet die besten Voraussetzungen, um ohne großen Aufwand ggf. alte Datensicherungen einzubringen und wenig Arbeit mit einer Reaktivierung zu haben ! Alles Andere produziert nicht unerheblichen Arbeitsaufwand und Streß.
