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 Posted by Roswitha Boldt

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 Integrationsmöglichkeiten zwischen SAP Netweaver Gateway und IBM in Kontext von Alloy-ähnlichen Funktionen  beleuchten. Hierzu werden wir die theoretische Basis von Netweaver Gateway anschauen sowie Technologien, um mit Gateway zu interagieren. Ebenso werden wir uns verschiedene Beispiele und den zugrunde liegenden Code live anschauen.

Migration 2.0 von Notes zu Outlook, Change Management statt technischer Umstellung
Jörg Stappert. harmon.ie
Anhand verschiedener Kundenbeispiele werden im Vortrag Wege aufgezeigt, zusätzlich zur technischen Migration auch die User zu „migrieren“.


Domino/Notes --> Exchange/Outlook - Erfahrungen aus einem Migrationsprojekt
Jörg Allmann, holistic-net GmbH
Der Projektbericht über eine Migration in einem mittelständischen Unternehmen umfasst alle Schritte vom vorbereitenden Assessment, über Aufräumarbeiten vor der Migration, Toolauswahl, Aufbau der Migrationsinfrastruktur, Planung und Durchführung der Migration, Supportstrategie, Hürden und Fallen, Providerkoordination, Logistik und viele Lessons Learned.


Leitung der Veranstaltung
Jörg Allmann, holistic-net GmbH
Gabor Pribil, ALLSET Enterprise Services
Stefan Lattermann, TÜV Rheinland Service GmbH

 

Link zur Anmeldung

 

Kickerturnier Revival bei der DNUG Konferenz in Berlin

30. April 2013 Posted by Jörg Allmann

image

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

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

Termin: Mittwoch, 5.6. - Start ist um 18:30

Anmeldungen werden ab sofort entgegengenommen. Das DNUG-Büro wird  noch ein Anmeldeformular auf die DNUG-Website hängen. Es reicht aber auch ein Kommentar zu diesem Blogpost als Anmeldung. Da wir nicht bis in die Puppen kickern können, zumal die Teilnehmer ja am nächsten Morgen frisch und ausgeruht auf der Matte stehen sollen, müssen wir die Teilnehmerzahl auf 40 begrenzen. 

Henry Walther wird mich wie gewohnt in der Abwicklung unterstützen. Bekanntlich braucht man zur Koordination der euphorisierten Teilnehmerschar eine starke Hand und gute Nerven.

Ich freue mich auf ein spannendes Turnier.

CU in Berlin

Jörg Allmann

 

 

 

Wie finde ich SMTP Sender an meinen Domino Server heraus ?

30. April 2013 Posted by Michael Siegrist

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 Posted by Michael Siegrist

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 Posted by Michael Siegrist

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 Posted by Michael Siegrist

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.

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

30. April 2013 Posted by Thomas Bahn

Quick-TippLotus Domino
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% binär-kompatibel zu sein) und ich hatte bis jetzt noch keine größeren Probleme damit.

Es gab nur eine kleinere Ungereimtheit: Ich konnte den grafischen Installer für den Domino-Server nie starten. Alle Installationen habe ich deshalb im Konsolenmodus durchgeführt. Heute habe ich herausgefunden, dass mir lediglich ein Paket fehlte: libXp. Ein schnelles yum -y install libXp und ich kann endlich auch den grafischen Installer benutzen. Yay!  

Quelle: Domino 8.5 - Required Linux packages and updates

Einladung zur “Social Collaboration 2013” (DNUG Konferenz)

30. April 2013 Posted by Stefan Krueger

Bild

 

 

 

 

 

 

 

 

 

 

 

 

Der Einsatz von Social Media und Social Software gehört bei vielen Kunden mittlerweile zum Standard. Doch was hält die Zukunft für sie bereit?
Welche Trends und Entwicklungen in Sachen Collaboration und Social Business dürfen sie erwarten?

Über diese und weitere Themen möchten wir mit Ihren Kunden diskutieren –
auf der Konferenz „Social Collaboration 2013“ am 6. und 7. Juni 2013 im SEMINARIS CampusHotel in Berlin-Dahlem.

Beim Social Business Day am 6. Juni 2013 dreht sich alles um Social Business Software und wie sie die Zusammenarbeit beeinflusst:

Wie vielfältig ihre Anwendungsfälle sind, erklärt Prof. Dr. Andrea Back (Universität St. Gallen) in ihrer Keynote „Social Business Software Leben einhauchen – wer macht’s und warum?”.

Sie erfahren zudem in meiner Keynote, „wie sich Collaboration in den nächsten Jahren verändern wird“.

Darüber hinaus dürfen sie sich auf spannende Vorträge wie „The Business value of the next Generation of E-Mail: IBM Notes and Domino 9 Social Edition“ (Scott Souder, IBM) und

Smarter Workforce: Recruitment, Social Learning und Talent Management mit Kenexa“ (Matthias Schultz, IBM Kenexa) freuen.

Wer einen direkten Erfahrungsaustausch mit anderen Kunden oder IBM Experten sucht, kann an verschiedenen Workshops unserer Arbeitskreise teilnehmen.

Weitere Informationen zur Veranstaltung der Agenda.

Viel Erfolg und beste Grüße wünschen Ihnen

Maria Gomez
Director IBM Social Business
and Collaboration Solutions
Software Sales Group Germany

 

Michael Schikorra
Brand Sales Leader DACH IMT
IBM Collaboration Solutions
IBM Deutschland GmbH

 

Gelöschte Benutzer wieder reaktivieren

30. April 2013 Posted by Manfred Meise

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 Posted by Manfred Meise

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 Posted by Manfred Meise

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 Posted by Manfred Meise

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 Posted by Thomas Bahn

Quick-Tipp
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 man einen Dienst, der die gewünschten Informationen als iCal-Feed anbietet. Ich nehme dafür http://www.feiertage-online.de/ical/,

Ein Rechtsklick auf die Verknüpfung öffnet das Kontextmenü, in dem man "Link-Adresse kopieren" ("Adresse des Links kopieren", "Verknüpfung kopieren", o. ä.) aufruft:
A picture named M2


Im Notes-Client kann man dann in seinem Kalender einen "Kalender hinzufügen...":
A picture named M3


Im erscheinenden Dialogfenster wählt man "iCalendar-Feed", gibt eine passende Bezeichnung ein und fügt mit Strg-V die zwischengespeicherte URL in das entsprechende Feld ein. Den Rest kann man nach eigenen Gutdünken ausfüllen:
A picture named M4


Für die Ferien in Schleswig-Holstein 2013 sieht das dann ganz ähnlich aus. Schließlich sieht der Navigator im Kalender bei mir so aus:
A picture named M5


Die letzte Woche 2013 in meinem Kalender:
A picture named M6

 

Firefox 20 vs iNotes 8.5.x

30. April 2013 Posted by Michael Siegrist

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 Posted by Michael Siegrist

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.