Archive for: ‘April 2013’

DNUG AK Enterprise Integration am 5. Juni 2013 ab 13 Uhr in Berlin: SAP Netweaver Gateway, Changemanagement und Lessons Learned aus Migrationsprojekten

30. April 2013, 14:00 Erstellt von Roswitha Boldt (233 clicks)

Vortragsprogramm im Arbeitskreis am 5. Juni 2013

Seminaris CampusHotel Berlin-Dahlem, 13 – 18. Uhr

 

SAP Netweaver Gateway als Ersatz für Alloy
Christian Holsing, IBM SAP International Competence Center (ISICC)
Die Session wird die …

Kickerturnier Revival bei der DNUG Konferenz in Berlin

30. April 2013, 10:19 Erstellt von Jörg Allmann (252 clicks)

Auf Wunsch vieler Konferenzteilnehmer gibt es in Berlin wieder ein Kickerturnier.

Achtung: Abweichend von der früheren Praxis findet es nicht am Partyabend, sondern am Vorabend der eigentlichen Konferenz statt.

Termin: Mittwoch, 5.6. – St…

Wie finde ich SMTP Sender an meinen Domino Server heraus ?

30. April 2013, 10:12 Erstellt von Michael Siegrist (275 clicks)

Bei einer Servermigration/Umzug/Umkonfiguration eines mit SMTP betriebenen Domino Servers ist es hilfreich, im Vorfeld eine Liste aller SMTP Host zur Verfügung zu haben, die an den umzustellenden Server E-Mails versenden, da diese Server/Geräte möglicherweise auch umkonfiguriert werden müssen. Dies gilt vor Allem für die im Intranet betriebenen Server. Für die Erstellung einer solchen Liste bietet Domino von Hause aus keine ausreichenden Werkzeuge. Zwar wird die Kommunikation anderer SMTP Server mit einem Domino Server in dessen Log.nsf protokolliert, doch gelingt es nicht, diese Informationen mit der „LogAnalyse“ des Domino Administrator Clients zu extrahieren.

Für die Analyse der Daten bietet sich jedoch die Freeware http://www.virtualobjectives.com.au/notesdomino/loganalyser6.htm“ title=“Log Analyzer 6 V4″ />Log Analyzer 6 V4  von Virtual Objects an. Nach Erstellung eines „Report Settings Dokuments“ kann mit der Ansichtsaktion „Manual Analysis“ z.B. eine Analyse der letzten 3 Tage erfolgen.
Image:Wie finde ich SMTP Sender an meinen Domino Server heraus ?
Als Ergebnis der Analyse wird eine Dokument erzeugt, welches die Treffer anzeigt:
Image:Wie finde ich SMTP Sender an meinen Domino Server heraus ?
Somit ist ein Überblick über alle in dem Zeitraum erfolgten SMTP connects gegeben.

Wie finde ich SMTP Sender an meinen Domino Server heraus ?

30. April 2013, 10:12 Erstellt von Michael Siegrist (15 clicks)

Bei einer Servermigration/Umzug/Umkonfiguration eines mit SMTP betriebenen Domino Servers ist es hilfreich, im Vorfeld eine Liste aller SMTP Host zur Verfügung zu haben, die an den umzustellenden Server E-Mails versenden, da diese Server/Geräte möglicherweise auch umkonfiguriert werden müssen. Dies gilt vor Allem für die im Intranet betriebenen Server. Für die Erstellung einer solchen Liste bietet Domino von Hause aus keine ausreichenden Werkzeuge. Zwar wird die Kommunikation anderer SMTP Server mit einem Domino Server in dessen Log.nsf protokolliert, doch gelingt es nicht, diese Informationen mit der „LogAnalyse“ des Domino Administrator Clients zu extrahieren.

Für die Analyse der Daten bietet sich jedoch die Freeware http://www.virtualobjectives.com.au/notesdomino/loganalyser6.htm“  title=“Log Analyzer 6 V4″ />Log Analyzer 6 V4  von Virtual Objectives an. Nach Erstellung eines „Report Settings Dokuments“ kann mit der Ansichtsaktion „Manual Analysis“ z.B. eine Analyse der letzten 3 Tage erfolgen.
Image:Wie finde ich SMTP Sender an meinen Domino Server heraus ?
Als Ergebnis der Analyse wird eine Dokument erzeugt, welches die Treffer anzeigt:
Image:Wie finde ich SMTP Sender an meinen Domino Server heraus ?
Somit ist ein Überblick über alle in dem Zeitraum erfolgten SMTP connects gegeben.

Wie finde ich SMTP Sender an meinen Domino Server heraus ?

30. April 2013, 10:12 Erstellt von Michael Siegrist (12 clicks)

Bei einer Servermigration/Umzug/Umkonfiguration eines mit SMTP betriebenen Domino Servers ist es hilfreich, im Vorfeld eine Liste aller SMTP Host zur Verfügung zu haben, die an den umzustellenden Server E-Mails versenden, da diese Server/Geräte möglicherweise auch umkonfiguriert werden müssen. Dies gilt vor Allem für die im Intranet betriebenen Server. Für die Erstellung einer solchen Liste bietet Domino von Hause aus keine ausreichenden Werkzeuge. Zwar wird die Kommunikation anderer SMTP Server mit einem Domino Server in dessen Log.nsf protokolliert, doch gelingt es nicht, diese Informationen mit der „LogAnalyse“ des Domino Administrator Clients zu extrahieren.

Für die Analyse der Daten bietet sich jedoch die Freeware http://www.virtualobjectives.com.au/notesdomino/loganalyser6.htm“  title=“Log Analyzer 6 V4″ />Log Analyzer 6 V4  von Virtual Objectives an. Nach Erstellung eines „Report Settings Dokuments“ kann mit der Ansichtsaktion „Manual Analysis“ z.B. eine Analyse der letzten 3 Tage erfolgen.
Image:Wie finde ich SMTP Sender an meinen Domino Server heraus ?
Als Ergebnis der Analyse wird eine Dokument erzeugt, welches die Treffer anzeigt:
Image:Wie finde ich SMTP Sender an meinen Domino Server heraus ?
Somit ist ein Überblick über alle in dem Zeitraum erfolgten SMTP connects gegeben.

Wie finde ich SMTP Sender an meinen Domino Server heraus ?

30. April 2013, 10:12 Erstellt von Michael Siegrist (11 clicks)

Bei einer Servermigration/Umzug/Umkonfiguration eines mit SMTP betriebenen Domino Servers ist es hilfreich, im Vorfeld eine Liste aller SMTP Host zur VerfĂĽgung zu haben, die an den umzustellenden Server E-Mails versenden, da diese Server/Geräte möglicherweise auch umkonfiguriert werden mĂĽssen. Dies gilt vor Allem fĂĽr die im Intranet betriebenen Server. FĂĽr die Erstellung einer solchen Liste bietet Domino von Hause aus keine ausreichenden Werkzeuge. Zwar wird die Kommunikation anderer SMTP Server mit einem Domino Server in dessen Log.nsf protokolliert, doch gelingt es nicht, diese Informationen mit der „LogAnalyse“ des Domino Administrator Clients zu extrahieren.

FĂĽr die Analyse der Daten bietet sich jedoch die Freeware http://www.virtualobjectives.com.au/notesdomino/loganalyser6.htm“  title=“Log Analyzer 6 V4″ />Log Analyzer 6 V4  von Virtual Objectives an. Nach Erstellung eines „Report Settings Dokuments“ kann mit der Ansichtsaktion „Manual Analysis“ z.B. eine Analyse der letzten 3 Tage erfolgen.
Image:Wie finde ich SMTP Sender an meinen Domino Server heraus ?
Als Ergebnis der Analyse wird eine Dokument erzeugt, welches die Treffer anzeigt:
Image:Wie finde ich SMTP Sender an meinen Domino Server heraus ?
Somit ist ein Ăśberblick ĂĽber alle in dem Zeitraum erfolgten SMTP connects gegeben.

Quick-Tipp: IBM (Lotus) Domino unter CentOS 6.x installieren

30. April 2013, 09:47 Erstellt von Thomas Bahn (290 clicks)

Ich habe alle meine Domino-Test- und -Demo-Server in VMs installiert, die
unter CentOS
6.x laufen. Diese Linux-Distribution ist dem offiziell unterstützten RedHat
Enterprise Linux (RHEL)-Server 6 sehr, sehr ähnlich (sie strebt danach,
100% …

Einladung zur „Social Collaboration 2013“ (DNUG Konferenz)

30. April 2013, 08:01 Erstellt von Stefan Krueger (278 clicks)

 

 

 

 

 

 

 

 

 

 

 

 

Der Einsatz von Social Media und Social Software gehört bei vielen Kunden mittlerweile zum Standard. Doch was hält die Zukunft f&…

Gelöschte Benutzer wieder reaktivieren

30. April 2013, 07:20 Erstellt von Manfred Meise (275 clicks)

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:
Image:Gelöschte Benutzer wieder reaktivieren
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 Image:Gelöschte Benutzer wieder reaktivieren 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ß.

Gelöschte Benutzer wieder reaktivieren

30. April 2013, 07:20 Erstellt von Manfred Meise (16 clicks)

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:
Image:Gelöschte Benutzer wieder reaktivieren
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 Image:Gelöschte Benutzer wieder reaktivieren 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ß.

Gelöschte Benutzer wieder reaktivieren

30. April 2013, 07:20 Erstellt von Manfred Meise (16 clicks)

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:
Image:Gelöschte Benutzer wieder reaktivieren
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 Image:Gelöschte Benutzer wieder reaktivieren 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ß.

Gelöschte Benutzer wieder reaktivieren

30. April 2013, 07:20 Erstellt von Manfred Meise (11 clicks)

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:
Image:Gelöschte Benutzer wieder reaktivieren
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 Image:Gelöschte Benutzer wieder reaktivieren 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ß.

Quick-Tipp: Feiertage und Ferien im Notes-Kalender anzeigen

30. April 2013, 07:08 Erstellt von Thomas Bahn (315 clicks)

Ich habe ja schon gezeigt, wie man sich die Wettervorhersage
und den Facebook-Geburtstagskalender
in seinen Notes-Kalender einblenden lassen kann, was aber noch fehlte waren
die Feiertage und Ferien. Das möchte ich jetzt kurz nachholen:
Zunächst braucht …

Firefox 20 vs iNotes 8.5.x

30. April 2013, 07:03 Erstellt von Michael Siegrist (10 clicks)

Domino 8.5.x unterstĂĽtzt aktuelle Versionen des Firefox offiziell leider nicht. Versucht man trotzdem mit Firefox 20 „gegen“ iNotes von Domino 8.5.x zu arbeiten, funktioniert leider der Senden Button nicht. Beim Klick erfolgt keine Aktion.

Dieses Problem lässt sich mit einem notes.ini Eintrag auf Serverseite lösen. Der Eintrag

iNotes_WA_FirefoxSignedScript=0

löst zumindest dieses Problem, und mit einem aktuellen Firefox kann wieder Mail versandt werden.

Firefox 20 vs iNotes 8.5.x

30. April 2013, 07:03 Erstellt von Michael Siegrist (14 clicks)

Domino 8.5.x unterstützt aktuelle Versionen des Firefox offiziell leider nicht. Versucht man trotzdem mit Firefox 20 „gegen“ iNotes von Domino 8.5.x zu arbeiten, funktioniert leider der Senden Button nicht. Beim Klick erfolgt keine Aktion.

Dieses Problem lässt sich mit einem notes.ini Eintrag auf Serverseite lösen. Der Eintrag

iNotes_WA_FirefoxSignedScript=0

löst zumindest dieses Problem, und mit einem aktuellen Firefox kann wieder Mail versandt werden.

What's hot