PlanetNTF

Gelegentlich kommt es vor, dass Benutzer registiert werden (z.B. Schreibfehler im Namen). Bis der Account noch nicht Betrieb ist (Notes Client konfiguriert ist), stelle ich mir als Administrator stets die Farge, wei ich den Fehler am einfachsten (schnellsten) beseitigen kann und somit kurzfristig der richtigen Account zur Verfügung stellen kann. Hier bieten sich aus meiner Sicht grundsätzlich zwei Vorgehensweisen an:

1. Arbeitsplatz in Betrieb nehmen und dann kurzfristig die Umbenennung durchführen
2. Account löschen und neu anlegen

Meistens verwende ich Vorgehenswiese 1 (oder entdecke den Fehler erst zu spät und kann nur noch diesen Weg wählen). Doch heute habe ich den Fehler früh erkannt und gemeint, dass ich mich einer Löschung und Neuanlage am schnellsten zum Ziel komme. Weit gefehlt! Gerade die Löschung des Benutzers benötigt in einer Mehrserver-Umgebung geraume Zeit (meistens erkennt man ich nicht spontan, ob die Löschung vollständig zum Ende gekommen ist). So kann (und wird es) passieren, dass bei erneuter Anlage eines Benutzers einzelne Komponenten (Personendokument, Mailfile, RoamingFiles, ID File im Vault) noch nicht vollständig gelöscht wurden. Somit sind im Domino Adminstrator entsprechende Optionen für die Neuregistrierung zu setzen:


Trotzdem erhielt ich dann den Hinweis, dass der Upload der neu registrieren ID in den Vault fehlgeschlagen ist. Eine Kontrolle des ID-Vaut ergab:

- weder die bisherige ID
noch
- die neue ID

ist im Vault zu finden. Ein blick in das lokale Log-File des Administrator Clients gibt ein wenig mehr Aufschluss:

  
24.04.2015 12:31:39   ID 'E:\Local\Temp\notes5D3EFE\16693602.id' konnte nicht in die Vault '' auf Server 'CN=DOMINO1/O=TEST' hochgeladen werden. 'John Doe/ADMIN/TEST' hat die Anforderung gestellt. Fehler: Dokument wurde gelöscht auf dem Remote-Server 
 

Klar, ich hatte einmal einen ID-Vault Eintrag für den zu registrierenden Benutzer, den ich zuvor gelöscht hatte. Doch warum erlaubt man mir nicht, ein neues Dokument im Vault anzulegen? Die Antwort kann ich nur erahnen, doch hat mir der Konsolenbefehl

 
 >Dbcache flush 
 

gute Dienste geleistet. Danach konnte ich den Benutzer erneut registrieren (auch wenn ich es ohne zu probieren nicht geglaubt hätte). Gut zu wissen!

Gelegentlich kommt es vor, dass Benutzer registiert werden (z.B. Schreibfehler im Namen). Bis der Account noch nicht Betrieb ist (Notes Client konfiguriert ist), stelle ich mir als Administrator stets die Farge, wei ich den Fehler am einfachsten (schnellsten) beseitigen kann und somit kurzfristig der richtigen Account zur Verfügung stellen kann. Hier bieten sich aus meiner Sicht grundsätzlich zwei Vorgehensweisen an:

1. Arbeitsplatz in Betrieb nehmen und dann kurzfristig die Umbenennung durchführen
2. Account löschen und neu anlegen

Meistens verwende ich Vorgehenswiese 1 (oder entdecke den Fehler erst zu spät und kann nur noch diesen Weg wählen). Doch heute habe ich den Fehler früh erkannt und gemeint, dass ich mich einer Löschung und Neuanlage am schnellsten zum Ziel komme. Weit gefehlt! Gerade die Löschung des Benutzers benötigt in einer Mehrserver-Umgebung geraume Zeit (meistens erkennt man ich nicht spontan, ob die Löschung vollständig zum Ende gekommen ist). So kann (und wird es) passieren, dass bei erneuter Anlage eines Benutzers einzelne Komponenten (Personendokument, Mailfile, RoamingFiles, ID File im Vault) noch nicht vollständig gelöscht wurden. Somit sind im Domino Adminstrator entsprechende Optionen für die Neuregistrierung zu setzen:


Trotzdem erhielt ich dann den Hinweis, dass der Upload der neu registrieren ID in den Vault fehlgeschlagen ist. Eine Kontrolle des ID-Vaut ergab:

- weder die bisherige ID
noch
- die neue ID

ist im Vault zu finden. Ein blick in das lokale Log-File des Administrator Clients gibt ein wenig mehr Aufschluss:

  
24.04.2015 12:31:39   ID 'E:\Local\Temp\notes5D3EFE\16693602.id' konnte nicht in die Vault '' auf Server 'CN=DOMINO1/O=TEST' hochgeladen werden. 'John Doe/ADMIN/TEST' hat die Anforderung gestellt. Fehler: Dokument wurde gelöscht auf dem Remote-Server 
 

Klar, ich hatte einmal einen ID-Vault Eintrag für den zu registrierenden Benutzer, den ich zuvor gelöscht hatte. Doch warum erlaubt man mir nicht, ein neues Dokument im Vault anzulegen? Die Antwort kann ich nur erahnen, doch hat mir der Konsolenbefehl

 
 >Dbcache flush 
 

gute Dienste geleistet. Danach konnte ich den Benutzer erneut registrieren (auch wenn ich es ohne zu probieren nicht geglaubt hätte). Gut zu wissen!

Gelegentlich kommt es vor, dass Benutzer registiert werden (z.B. Schreibfehler im Namen). Bis der Account noch nicht Betrieb ist (Notes Client konfiguriert ist), stelle ich mir als Administrator stets die Farge, wei ich den Fehler am einfachsten (schnellsten) beseitigen kann und somit kurzfristig der richtigen Account zur Verfügung stellen kann. Hier bieten sich aus meiner Sicht grundsätzlich zwei Vorgehensweisen an:

1. Arbeitsplatz in Betrieb nehmen und dann kurzfristig die Umbenennung durchführen
2. Account löschen und neu anlegen

Meistens verwende ich Vorgehenswiese 1 (oder entdecke den Fehler erst zu spät und kann nur noch diesen Weg wählen). Doch heute habe ich den Fehler früh erkannt und gemeint, dass ich mich einer Löschung und Neuanlage am schnellsten zum Ziel komme. Weit gefehlt! Gerade die Löschung des Benutzers benötigt in einer Mehrserver-Umgebung geraume Zeit (meistens erkennt man ich nicht spontan, ob die Löschung vollständig zum Ende gekommen ist). So kann (und wird es) passieren, dass bei erneuter Anlage eines Benutzers einzelne Komponenten (Personendokument, Mailfile, RoamingFiles, ID File im Vault) noch nicht vollständig gelöscht wurden. Somit sind im Domino Adminstrator entsprechende Optionen für die Neuregistrierung zu setzen:


Trotzdem erhielt ich dann den Hinweis, dass der Upload der neu registrieren ID in den Vault fehlgeschlagen ist. Eine Kontrolle des ID-Vaut ergab:

- weder die bisherige ID
noch
- die neue ID

ist im Vault zu finden. Ein blick in das lokale Log-File des Administrator Clients gibt ein wenig mehr Aufschluss:

  
24.04.2015 12:31:39   ID 'E:LocalTempnotes5D3EFE16693602.id' konnte nicht in die Vault '' auf Server 'CN=DOMINO1/O=TEST' hochgeladen werden. 'John Doe/ADMIN/TEST' hat die Anforderung gestellt. Fehler: Dokument wurde gelöscht auf dem Remote-Server 
 

Klar, ich hatte einmal einen ID-Vault Eintrag für den zu registrierenden Benutzer, den ich zuvor gelöscht hatte. Doch warum erlaubt man mir nicht, ein neues Dokument im Vault anzulegen? Die Antwort kann ich nur erahnen, doch hat mir der Konsolenbefehl

 
 >Dbcache flush 
 

gute Dienste geleistet. Danach konnte ich den Benutzer erneut registrieren (auch wenn ich es ohne zu probieren nicht geglaubt hätte). Gut zu wissen!

Gelegentlich kommt es vor, dass Benutzer registiert werden (z.B. Schreibfehler im Namen). Bis der Account noch nicht Betrieb ist (Notes Client konfiguriert ist), stelle ich mir als Administrator stets die Farge, wei ich den Fehler am einfachsten (schnellsten) beseitigen kann und somit kurzfristig der richtigen Account zur Verfügung stellen kann. Hier bieten sich aus meiner Sicht grundsätzlich zwei Vorgehensweisen an:

1. Arbeitsplatz in Betrieb nehmen und dann kurzfristig die Umbenennung durchfĂĽhren
2. Account löschen und neu anlegen

Meistens verwende ich Vorgehenswiese 1 (oder entdecke den Fehler erst zu spät und kann nur noch diesen Weg wählen). Doch heute habe ich den Fehler früh erkannt und gemeint, dass ich mich einer Löschung und Neuanlage am schnellsten zum Ziel komme. Weit gefehlt! Gerade die Löschung des Benutzers benötigt in einer Mehrserver-Umgebung geraume Zeit (meistens erkennt man ich nicht spontan, ob die Löschung vollständig zum Ende gekommen ist). So kann (und wird es) passieren, dass bei erneuter Anlage eines Benutzers einzelne Komponenten (Personendokument, Mailfile, RoamingFiles, ID File im Vault) noch nicht vollständig gelöscht wurden. Somit sind im Domino Adminstrator entsprechende Optionen für die Neuregistrierung zu setzen:


Trotzdem erhielt ich dann den Hinweis, dass der Upload der neu registrieren ID in den Vault fehlgeschlagen ist. Eine Kontrolle des ID-Vaut ergab:

- weder die bisherige ID
noch
- die neue ID

ist im Vault zu finden. Ein blick in das lokale Log-File des Administrator Clients gibt ein wenig mehr Aufschluss:

  
24.04.2015 12:31:39   ID 'E:\Local\Temp\notes5D3EFE\16693602.id' konnte nicht in die Vault '' auf Server 'CN=DOMINO1/O=TEST' hochgeladen werden. 'John Doe/ADMIN/TEST' hat die Anforderung gestellt. Fehler: Dokument wurde gelöscht auf dem Remote-Server 
 

Klar, ich hatte einmal einen ID-Vault Eintrag für den zu registrierenden Benutzer, den ich zuvor gelöscht hatte. Doch warum erlaubt man mir nicht, ein neues Dokument im Vault anzulegen? Die Antwort kann ich nur erahnen, doch hat mir der Konsolenbefehl

 
 >Dbcache flush 
 

gute Dienste geleistet. Danach konnte ich den Benutzer erneut registrieren (auch wenn ich es ohne zu probieren nicht geglaubt hätte). Gut zu wissen!

Gelegentlich kommt es vor, dass Benutzer registiert werden (z.B. Schreibfehler im Namen). Bis der Account noch nicht Betrieb ist (Notes Client konfiguriert ist), stelle ich mir als Administrator stets die Farge, wei ich den Fehler am einfachsten (schnellsten) beseitigen kann und somit kurzfristig der richtigen Account zur Verfügung stellen kann. Hier bieten sich aus meiner Sicht grundsätzlich zwei Vorgehensweisen an:

1. Arbeitsplatz in Betrieb nehmen und dann kurzfristig die Umbenennung durchführen
2. Account löschen und neu anlegen

Meistens verwende ich Vorgehenswiese 1 (oder entdecke den Fehler erst zu spät und kann nur noch diesen Weg wählen). Doch heute habe ich den Fehler früh erkannt und gemeint, dass ich mich einer Löschung und Neuanlage am schnellsten zum Ziel komme. Weit gefehlt! Gerade die Löschung des Benutzers benötigt in einer Mehrserver-Umgebung geraume Zeit (meistens erkennt man ich nicht spontan, ob die Löschung vollständig zum Ende gekommen ist). So kann (und wird es) passieren, dass bei erneuter Anlage eines Benutzers einzelne Komponenten (Personendokument, Mailfile, RoamingFiles, ID File im Vault) noch nicht vollständig gelöscht wurden. Somit sind im Domino Adminstrator entsprechende Optionen für die Neuregistrierung zu setzen:


Trotzdem erhielt ich dann den Hinweis, dass der Upload der neu registrieren ID in den Vault fehlgeschlagen ist. Eine Kontrolle des ID-Vaut ergab:

- weder die bisherige ID
noch
- die neue ID

ist im Vault zu finden. Ein blick in das lokale Log-File des Administrator Clients gibt ein wenig mehr Aufschluss:

  
24.04.2015 12:31:39   ID 'E:\Local\Temp\notes5D3EFE\16693602.id' konnte nicht in die Vault '' auf Server 'CN=DOMINO1/O=TEST' hochgeladen werden. 'John Doe/ADMIN/TEST' hat die Anforderung gestellt. Fehler: Dokument wurde gelöscht auf dem Remote-Server 
 

Klar, ich hatte einmal einen ID-Vault Eintrag für den zu registrierenden Benutzer, den ich zuvor gelöscht hatte. Doch warum erlaubt man mir nicht, ein neues Dokument im Vault anzulegen? Die Antwort kann ich nur erahnen, doch hat mir der Konsolenbefehl

 
 >Dbcache flush 
 

gute Dienste geleistet. Danach konnte ich den Benutzer erneut registrieren (auch wenn ich es ohne zu probieren nicht geglaubt hätte). Gut zu wissen!

Gelegentlich kommt es vor, dass Benutzer registiert werden (z.B. Schreibfehler im Namen). Bis der Account noch nicht Betrieb ist (Notes Client konfiguriert ist), stelle ich mir als Administrator stets die Farge, wei ich den Fehler am einfachsten (schnellsten) beseitigen kann und somit kurzfristig der richtigen Account zur Verfügung stellen kann. Hier bieten sich aus meiner Sicht grundsätzlich zwei Vorgehensweisen an:

1. Arbeitsplatz in Betrieb nehmen und dann kurzfristig die Umbenennung durchfĂĽhren
2. Account löschen und neu anlegen

Meistens verwende ich Vorgehenswiese 1 (oder entdecke den Fehler erst zu spät und kann nur noch diesen Weg wählen). Doch heute habe ich den Fehler früh erkannt und gemeint, dass ich mich einer Löschung und Neuanlage am schnellsten zum Ziel komme. Weit gefehlt! Gerade die Löschung des Benutzers benötigt in einer Mehrserver-Umgebung geraume Zeit (meistens erkennt man ich nicht spontan, ob die Löschung vollständig zum Ende gekommen ist). So kann (und wird es) passieren, dass bei erneuter Anlage eines Benutzers einzelne Komponenten (Personendokument, Mailfile, RoamingFiles, ID File im Vault) noch nicht vollständig gelöscht wurden. Somit sind im Domino Adminstrator entsprechende Optionen für die Neuregistrierung zu setzen:


Trotzdem erhielt ich dann den Hinweis, dass der Upload der neu registrieren ID in den Vault fehlgeschlagen ist. Eine Kontrolle des ID-Vaut ergab:

- weder die bisherige ID
noch
- die neue ID

ist im Vault zu finden. Ein blick in das lokale Log-File des Administrator Clients gibt ein wenig mehr Aufschluss:

  
24.04.2015 12:31:39   ID 'E:\Local\Temp\notes5D3EFE\16693602.id' konnte nicht in die Vault '' auf Server 'CN=DOMINO1/O=TEST' hochgeladen werden. 'John Doe/ADMIN/TEST' hat die Anforderung gestellt. Fehler: Dokument wurde gelöscht auf dem Remote-Server 
 

Klar, ich hatte einmal einen ID-Vault Eintrag für den zu registrierenden Benutzer, den ich zuvor gelöscht hatte. Doch warum erlaubt man mir nicht, ein neues Dokument im Vault anzulegen? Die Antwort kann ich nur erahnen, doch hat mir der Konsolenbefehl

 
 >Dbcache flush 
 

gute Dienste geleistet. Danach konnte ich den Benutzer erneut registrieren (auch wenn ich es ohne zu probieren nicht geglaubt hätte). Gut zu wissen!

Im Verlauf des "Lebenszyklus" eines Domino Benutzer ist klar, dass dieser nicht nur irgendwann neu angelegt wird, sondern möglicherweise auch einmal gelöscht/deaktiviert werden will. In seltenen Fällen sollen anschließend die gelöschten/deaktivierten Benutzer wieder reaktiviert werden und möglichst unverändert so weiter arbeiten wie zuletzt. Abhängig davon, wie die Benutzer zuvor gelöscht/deaktiviert worden sind, mag sich dieses jedoch schwierig gestalten:

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  wieder in den aktiven Zustand (für einen Download im Rahmen der Client Inbetriebnahme) zu versetzen. Fehlt diese, ist nur die Methode "1. Neuregistrierung des Benutzers" mit allen seinen Nachteilen an. Das Verfahren eine zuvor bei der Registrierung im Dateisystem des Administrator gesicherte Benutzer-ID zu verwenden mag hier als noch größere Fehlerquelle nicht weiter beleuchtet werden.

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ß.

Im Verlauf des "Lebenszyklus" eines Domino Benutzer ist klar, dass dieser nicht nur irgendwann neu angelegt wird, sondern möglicherweise auch einmal gelöscht/deaktiviert werden will. In seltenen Fällen sollen anschließend die gelöschten/deaktivierten Benutzer wieder reaktiviert werden und möglichst unverändert so weiter arbeiten wie zuletzt. Abhängig davon, wie die Benutzer zuvor gelöscht/deaktiviert worden sind, mag sich dieses jedoch schwierig gestalten:

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  wieder in den aktiven Zustand (für einen Download im Rahmen der Client Inbetriebnahme) zu versetzen. Fehlt diese, ist nur die Methode "1. Neuregistrierung des Benutzers" mit allen seinen Nachteilen an. Das Verfahren eine zuvor bei der Registrierung im Dateisystem des Administrator gesicherte Benutzer-ID zu verwenden mag hier als noch größere Fehlerquelle nicht weiter beleuchtet werden.

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ß.

Im Verlauf des "Lebenszyklus" eines Domino Benutzer ist klar, dass dieser nicht nur irgendwann neu angelegt wird, sondern möglicherweise auch einmal gelöscht/deaktiviert werden will. In seltenen Fällen sollen anschließend die gelöschten/deaktivierten Benutzer wieder reaktiviert werden und möglichst unverändert so weiter arbeiten wie zuletzt. Abhängig davon, wie die Benutzer zuvor gelöscht/deaktiviert worden sind, mag sich dieses jedoch schwierig gestalten:

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  wieder in den aktiven Zustand (für einen Download im Rahmen der Client Inbetriebnahme) zu versetzen. Fehlt diese, ist nur die Methode "1. Neuregistrierung des Benutzers" mit allen seinen Nachteilen an. Das Verfahren eine zuvor bei der Registrierung im Dateisystem des Administrator gesicherte Benutzer-ID zu verwenden mag hier als noch größere Fehlerquelle nicht weiter beleuchtet werden.

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ß.

Im Verlauf des "Lebenszyklus" eines Domino Benutzer ist klar, dass dieser nicht nur irgendwann neu angelegt wird, sondern möglicherweise auch einmal gelöscht/deaktiviert werden will. In seltenen Fällen sollen anschließend die gelöschten/deaktivierten Benutzer wieder reaktiviert werden und möglichst unverändert so weiter arbeiten wie zuletzt. Abhängig davon, wie die Benutzer zuvor gelöscht/deaktiviert worden sind, mag sich dieses jedoch schwierig gestalten:

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  wieder in den aktiven Zustand (fĂĽr einen Download im Rahmen der Client Inbetriebnahme) zu versetzen. Fehlt diese, ist nur die Methode "1. Neuregistrierung des Benutzers" mit allen seinen Nachteilen an. Das Verfahren eine zuvor bei der Registrierung im Dateisystem des Administrator gesicherte Benutzer-ID zu verwenden mag hier als noch größere Fehlerquelle nicht weiter beleuchtet werden.

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ß.

Mit Hilfe von Feiertagsdokumenten kann Ihrer Organisation eine zentral verwaltete Dokumentsammlung mit Informationen zu Feiertagen und geplanten Ereignissen unterhalten. Benutzer whlen den Typ der zu importierenden Feiertagsdokumente aus und fgen die Informationen ihren persnlichen Kalendern hinzu.

Soweit die Admin-Hilfe. Leider sind diese vordefinierten Feiertagsdokumente nur in englischer Sprache im Domino Verzeichniss vorhanden.

Ausserdem hat in Deutschland  jedes Bundesland auch wieder unterschiedliche Feiertage.
Darum haben wir unsere FeiertagsDB auf den neuesten Stand gebracht.  Die deutschen Feiertage sind nach Bundesland bis 2018 sortiert.


Der Download ist hier zu finden.

Mit Hilfe von Feiertagsdokumenten kann Ihrer Organisation eine zentral verwaltete Dokumentsammlung mit Informationen zu Feiertagen und geplanten Ereignissen unterhalten. Benutzer wählen den Typ der zu importierenden Feiertagsdokumente aus und fügen die Informationen ihren persönlichen Kalendern hinzu.

Soweit die Admin-Hilfe. Leider sind diese vordefinierten Feiertagsdokumente nur in englischer Sprache im Domino Verzeichniss vorhanden.

Ausserdem hat in Deutschland  jedes Bundesland auch wieder unterschiedliche Feiertage.
Darum haben wir unsere FeiertagsDB auf den neuesten Stand gebracht.  Die deutschen Feiertage sind nach Bundesland bis 2018 sortiert.


Der Download ist hier zu finden.

Mit Hilfe von Feiertagsdokumenten kann Ihrer Organisation eine zentral verwaltete Dokumentsammlung mit Informationen zu Feiertagen und geplanten Ereignissen unterhalten. Benutzer wählen den Typ der zu importierenden Feiertagsdokumente aus und fügen die Informationen ihren persönlichen Kalendern hinzu.

Soweit die Admin-Hilfe. Leider sind diese vordefinierten Feiertagsdokumente nur in englischer Sprache im Domino Verzeichniss vorhanden.

Ausserdem hat in Deutschland  jedes Bundesland auch wieder unterschiedliche Feiertage.
Darum haben wir unsere FeiertagsDB auf den neuesten Stand gebracht.  Die deutschen Feiertage sind nach Bundesland bis 2018 sortiert.


Der Download ist hier zu finden.

Mit Hilfe von Feiertagsdokumenten kann Ihrer Organisation eine zentral verwaltete Dokumentsammlung mit Informationen zu Feiertagen und geplanten Ereignissen unterhalten. Benutzer wählen den Typ der zu importierenden Feiertagsdokumente aus und fügen die Informationen ihren persönlichen Kalendern hinzu.

Soweit die Admin-Hilfe. Leider sind diese vordefinierten Feiertagsdokumente nur in englischer Sprache im Domino Verzeichniss vorhanden.

Ausserdem hat in Deutschland  jedes Bundesland auch wieder unterschiedliche Feiertage.
Darum haben wir unsere FeiertagsDB auf den neuesten Stand gebracht.  Die deutschen Feiertage sind nach Bundesland bis 2018 sortiert.


Der Download ist hier zu finden.

Mit Hilfe von Feiertagsdokumenten kann Ihrer Organisation eine zentral verwaltete Dokumentsammlung mit Informationen zu Feiertagen und geplanten Ereignissen unterhalten. Benutzer wählen den Typ der zu importierenden Feiertagsdokumente aus und fügen die Informationen ihren persönlichen Kalendern hinzu.

Soweit die Admin-Hilfe. Leider sind diese vordefinierten Feiertagsdokumente nur in englischer Sprache im Domino Verzeichniss vorhanden.

Ausserdem hat in Deutschland  jedes Bundesland auch wieder unterschiedliche Feiertage.
Darum haben wir unsere FeiertagsDB auf den neuesten Stand gebracht.  Die deutschen Feiertage sind nach Bundesland bis 2018 sortiert.


Der Download ist hier zu finden.