Archive for: ‘Dezember 2010’

Wie bewältigen wir "Information overload"

28. Dezember 2010, 14:58 Erstellt von Herbert Wagger (260 clicks)

Ein interessanter Artikel von Thomas Pelkman (CIO.de) – siehe weiter unten. Dieser Zunahme der Datenflut (Verdoppelung innherhalb 18 Monaten) vor allem durch die neuen sozialen Netzwerke und andere W …

dojo und Notes: Artikel 10 – dojo.dnd.Source – Drag\’n\’Drop mit drei Zeilen JavaScript

27. Dezember 2010, 13:14 Erstellt von Bernd Hort (353 clicks)

Während der letzte
Artikel in der dojo-Serie
sich mit den dijit.Dialog beschäftigte, komme wir nun zu einem meiner Lieblingsthemen
bei dojo: Drag & Drop. Es ist deswegen mein Lieblingsthema, weil es
so unglaublich einfach zu benutzen ist. Wie wir …

Wie funktioniert die "Client Aufrumfunktion" von Lotus Notes?

23. Dezember 2010, 15:59 Erstellt von Manfred Meise (25 clicks)

Vermeiden Sie den Verlust lokaler Daten (die nur hier existieren), indem Sie diese Konfiguration vollstndig verstehen, bevor Sie diese einsetzen. Seit Einfhrung von Multi-User Installationen und Roaming Funktion in Release 6 knnen Administratoren di…

Wie funktioniert die „Client Aufräumfunktion“ von Lotus Notes?

23. Dezember 2010, 13:59 Erstellt von Manfred Meise (14 clicks)

Vermeiden Sie den Verlust lokaler Daten (die nur hier existieren), indem Sie diese Konfiguration vollständig verstehen, bevor Sie diese einsetzen.

Seit Einführung von Multi-User Installationen und Roaming Funktion in Release 6 können Administratoren die „Client Aufräumfunktion“ nutzen, um die Flut lokaler Dateien verschiedener Benutzer einzudämmen, Hierzu ist bei z.B. der nachträglichen Einrichtung der Roaming Funktion für einen Benutzer diese Option auszuwählen:

Image:Wie funktioniert die "Client Aufräumfunktion" von Lotus Notes?
Im Rahmen eines Kundenprojektes, wo man auf diese Option gesteigerten Wert legte, frage ich mich nun, wie diese Funktion genau arbeitet und wie sie gesteuert wird.

Rahmenbedingungen:

Damit die Aufräumfunktion lokal zur Verfügung steht, ist eine MultiUser Installation des Clients durchzuführen, um das notwendige Programm „NtMulti.exe“ in das Programmverzeichnis installiert und als Windows Dienst eingerichtet zu bekommen.

Mit Einrichtung von Domino Roaming (bei der Registrierung oder nachträglich) wird der Administrationsprozeß beauftragt, die Funktion zu parametrisieren (im obigen Beispiel mit 10 Tagen). Diese Daten werden im Personendokument des Benutzers hinterlegt.

Verhalten im Alltag:

Wenn ein Benutzer an einem PC Lotus Notes eingerichtet hat, werden seine lokalen Daten nach 10 Tagen gelöscht. Diese Löschung umfasst sein gesamtes lokales Notes Datenverzeichnis (somit z.B. auch lokale Mail-Archive, wenn Benutzer lokal archivieren !!!! (ACHTUNG: Gefahr des Verlustes von Unternehmensdaten!)

Nach Ablauf von 10 Tagen durchläuft der Lotus Notes Client eine Konfiguration und repliziert seine Roaming Dateien von Roaming Server.

Offene Fragen und meine Erkenntnisse:

Um die Arbeitsweise der Aufräumfunktion näher zu ermitteln half nach einer ergebnislosen Recherche in den einschlägigen Quellen nur noch „ausprobieren“ und „selbst ermitteln“. Hier der aktuelle Stand meiner Erkenntnisse (die ich erweitern werde, sofern neue Erkenntnisse hinzukommen):

Frage
Meine Erkenntnisse
Ab wann zählen die 10 Tage? Ab Einrichtung von Lotus Notes für den betroffenen Benutzer oder ab dem Zeitpunkt der letzten Nutzung? Anders als viele Administratoren erwarten aktualisiert der Lotus Notes Client die Konfigurationsdaten für die Aufräumdienst nicht. Somit zählt das konfigurierte Aufräumintervall seit dem Zeitpunkt der ersten Konfiguration des Benutzers als Roaming User auf dem betroffenen Rechner. Anders als erwartet, oder? Hätten Sie das vorab ohne Tests gewusst?
Hinweis: Durch den zusätzlichen Notes.ini Eintrag „Cleanup_Move=1“, den man z.B. über eine Desktop Richtlinie setzen kann, wird dieses Intervall nicht vom Zeitpunkt der Erstkonfiguration, sondern der letzten Verwendung (herunterfahren/replizieren) eines Roaming Clients gezählt.
Wo sind die Konfigurationsdaten für den Aufräumdienst „NTMulti.exe“ gespeichert? Mit Installation des MultiUser Clients wird das entsprechende Programm als Windows Dienst eingerichtet:

Mit Abschluss der ersten Replikation (z.B. beim Beenden von Lotus Notes) mit Roaming Konfiguration schreibt der Lotus Notes Client eine lokale Datei „.cln“ in „C:\Dokumente und Einstellungen\All Users\Dokumente“ an dem sich der Aufräumdienst orientiert.
Diese Datei enthält den Verzeichnisnamen des zu löschenden Benutzerprofiles sowie die Zeitangabe, wann dieses zu löschen ist. Ist der Client so konfiguriert, dass das Aufräumzeitintervall ab der letzten Verwendung zählt, so wird dieses Datei beim Herunterfahren von Lotus Notes erneut geschrieben.

Kann die Aufräumperiode nachträglich geändert werden? Nein und ja. Eine Änderung des Aufräumzyklus im Personendokument wirkt sich NICHT auf bereits konfigurierte Clients aus. Jedoch werden die Daten aus dem Personendokument interpretiert, wenn der betroffene Benutzer an einen anderen Rechner roamt (und dort die Erstkonfiguration durchläuft).

Wie funktioniert die „Client Aufräumfunktion“ von Lotus Notes?

23. Dezember 2010, 13:59 Erstellt von Manfred Meise (9 clicks)

Vermeiden Sie den Verlust lokaler Daten (die nur hier existieren), indem Sie diese Konfiguration vollständig verstehen, bevor Sie diese einsetzen.

Seit EinfĂĽhrung von Multi-User Installationen und Roaming Funktion in Release 6 können Administratoren die „Client Aufräumfunktion“ nutzen, um die Flut lokaler Dateien verschiedener Benutzer einzudämmen, Hierzu ist bei z.B. der nachträglichen Einrichtung der Roaming Funktion fĂĽr einen Benutzer diese Option auszuwählen:

Image:Wie funktioniert die "Client Aufräumfunktion" von Lotus Notes?
Im Rahmen eines Kundenprojektes, wo man auf diese Option gesteigerten Wert legte, frage ich mich nun, wie diese Funktion genau arbeitet und wie sie gesteuert wird.

Rahmenbedingungen:

Damit die Aufräumfunktion lokal zur VerfĂĽgung steht, ist eine MultiUser Installation des Clients durchzufĂĽhren, um das notwendige Programm „NtMulti.exe“ in das Programmverzeichnis installiert und als Windows Dienst eingerichtet zu bekommen.

Mit Einrichtung von Domino Roaming (bei der Registrierung oder nachträglich) wird der Administrationsprozeß beauftragt, die Funktion zu parametrisieren (im obigen Beispiel mit 10 Tagen). Diese Daten werden im Personendokument des Benutzers hinterlegt.

Verhalten im Alltag:

Wenn ein Benutzer an einem PC Lotus Notes eingerichtet hat, werden seine lokalen Daten nach 10 Tagen gelöscht. Diese Löschung umfasst sein gesamtes lokales Notes Datenverzeichnis (somit z.B. auch lokale Mail-Archive, wenn Benutzer lokal archivieren !!!! (ACHTUNG: Gefahr des Verlustes von Unternehmensdaten!)

Nach Ablauf von 10 Tagen durchläuft der Lotus Notes Client eine Konfiguration und repliziert seine Roaming Dateien von Roaming Server.

Offene Fragen und meine Erkenntnisse:

Um die Arbeitsweise der Aufräumfunktion näher zu ermitteln half nach einer ergebnislosen Recherche in den einschlägigen Quellen nur noch „ausprobieren“ und „selbst ermitteln“. Hier der aktuelle Stand meiner Erkenntnisse (die ich erweitern werde, sofern neue Erkenntnisse hinzukommen):

Frage
Meine Erkenntnisse
Ab wann zählen die 10 Tage? Ab Einrichtung von Lotus Notes für den betroffenen Benutzer oder ab dem Zeitpunkt der letzten Nutzung? Anders als viele Administratoren erwarten aktualisiert der Lotus Notes Client die Konfigurationsdaten für die Aufräumdienst nicht. Somit zählt das konfigurierte Aufräumintervall seit dem Zeitpunkt der ersten Konfiguration des Benutzers als Roaming User auf dem betroffenen Rechner. Anders als erwartet, oder? Hätten Sie das vorab ohne Tests gewusst?
Hinweis: Durch den zusätzlichen Notes.ini Eintrag „Cleanup_Move=1“, den man z.B. ĂĽber eine Desktop Richtlinie setzen kann, wird dieses Intervall nicht vom Zeitpunkt der Erstkonfiguration, sondern der letzten Verwendung (herunterfahren/replizieren) eines Roaming Clients gezählt.
Wo sind die Konfigurationsdaten fĂĽr den Aufräumdienst „NTMulti.exe“ gespeichert? Mit Installation des MultiUser Clients wird das entsprechende Programm als Windows Dienst eingerichtet:

Mit Abschluss der ersten Replikation (z.B. beim Beenden von Lotus Notes) mit Roaming Konfiguration schreibt der Lotus Notes Client eine lokale Datei „.cln“ in „C:\Dokumente und Einstellungen\All Users\Dokumente“ an dem sich der Aufräumdienst orientiert.
Diese Datei enthält den Verzeichnisnamen des zu löschenden Benutzerprofiles sowie die Zeitangabe, wann dieses zu löschen ist. Ist der Client so konfiguriert, dass das Aufräumzeitintervall ab der letzten Verwendung zählt, so wird dieses Datei beim Herunterfahren von Lotus Notes erneut geschrieben.

Kann die Aufräumperiode nachträglich geändert werden? Nein und ja. Eine Änderung des Aufräumzyklus im Personendokument wirkt sich NICHT auf bereits konfigurierte Clients aus. Jedoch werden die Daten aus dem Personendokument interpretiert, wenn der betroffene Benutzer an einen anderen Rechner roamt (und dort die Erstkonfiguration durchläuft).

Wie funktioniert die „Client Aufräumfunktion“ von Lotus Notes?

23. Dezember 2010, 13:59 Erstellt von Manfred Meise (10 clicks)

Vermeiden Sie den Verlust lokaler Daten (die nur hier existieren), indem Sie diese Konfiguration vollständig verstehen, bevor Sie diese einsetzen.

Seit Einführung von Multi-User Installationen und Roaming Funktion in Release 6 können Administratoren die „Client Aufräumfunktion“ nutzen, um die Flut lokaler Dateien verschiedener Benutzer einzudämmen, Hierzu ist bei z.B. der nachträglichen Einrichtung der Roaming Funktion für einen Benutzer diese Option auszuwählen:

Image:Wie funktioniert die "Client Aufräumfunktion" von Lotus Notes?
Im Rahmen eines Kundenprojektes, wo man auf diese Option gesteigerten Wert legte, frage ich mich nun, wie diese Funktion genau arbeitet und wie sie gesteuert wird.

Rahmenbedingungen:

Damit die Aufräumfunktion lokal zur Verfügung steht, ist eine MultiUser Installation des Clients durchzuführen, um das notwendige Programm „NtMulti.exe“ in das Programmverzeichnis installiert und als Windows Dienst eingerichtet zu bekommen.

Mit Einrichtung von Domino Roaming (bei der Registrierung oder nachträglich) wird der Administrationsprozeß beauftragt, die Funktion zu parametrisieren (im obigen Beispiel mit 10 Tagen). Diese Daten werden im Personendokument des Benutzers hinterlegt.

Verhalten im Alltag:

Wenn ein Benutzer an einem PC Lotus Notes eingerichtet hat, werden seine lokalen Daten nach 10 Tagen gelöscht. Diese Löschung umfasst sein gesamtes lokales Notes Datenverzeichnis (somit z.B. auch lokale Mail-Archive, wenn Benutzer lokal archivieren !!!! (ACHTUNG: Gefahr des Verlustes von Unternehmensdaten!)

Nach Ablauf von 10 Tagen durchläuft der Lotus Notes Client eine Konfiguration und repliziert seine Roaming Dateien von Roaming Server.

Offene Fragen und meine Erkenntnisse:

Um die Arbeitsweise der Aufräumfunktion näher zu ermitteln half nach einer ergebnislosen Recherche in den einschlägigen Quellen nur noch „ausprobieren“ und „selbst ermitteln“. Hier der aktuelle Stand meiner Erkenntnisse (die ich erweitern werde, sofern neue Erkenntnisse hinzukommen):

Frage
Meine Erkenntnisse
Ab wann zählen die 10 Tage? Ab Einrichtung von Lotus Notes für den betroffenen Benutzer oder ab dem Zeitpunkt der letzten Nutzung? Anders als viele Administratoren erwarten aktualisiert der Lotus Notes Client die Konfigurationsdaten für die Aufräumdienst nicht. Somit zählt das konfigurierte Aufräumintervall seit dem Zeitpunkt der ersten Konfiguration des Benutzers als Roaming User auf dem betroffenen Rechner. Anders als erwartet, oder? Hätten Sie das vorab ohne Tests gewusst?
Hinweis: Durch den zusätzlichen Notes.ini Eintrag „Cleanup_Move=1“, den man z.B. über eine Desktop Richtlinie setzen kann, wird dieses Intervall nicht vom Zeitpunkt der Erstkonfiguration, sondern der letzten Verwendung (herunterfahren/replizieren) eines Roaming Clients gezählt.
Wo sind die Konfigurationsdaten für den Aufräumdienst „NTMulti.exe“ gespeichert? Mit Installation des MultiUser Clients wird das entsprechende Programm als Windows Dienst eingerichtet:

Mit Abschluss der ersten Replikation (z.B. beim Beenden von Lotus Notes) mit Roaming Konfiguration schreibt der Lotus Notes Client eine lokale Datei „.cln“ in „C:\Dokumente und Einstellungen\All Users\Dokumente“ an dem sich der Aufräumdienst orientiert.
Diese Datei enthält den Verzeichnisnamen des zu löschenden Benutzerprofiles sowie die Zeitangabe, wann dieses zu löschen ist. Ist der Client so konfiguriert, dass das Aufräumzeitintervall ab der letzten Verwendung zählt, so wird dieses Datei beim Herunterfahren von Lotus Notes erneut geschrieben.

Kann die Aufräumperiode nachträglich geändert werden? Nein und ja. Eine Änderung des Aufräumzyklus im Personendokument wirkt sich NICHT auf bereits konfigurierte Clients aus. Jedoch werden die Daten aus dem Personendokument interpretiert, wenn der betroffene Benutzer an einen anderen Rechner roamt (und dort die Erstkonfiguration durchläuft).

Enterprise Software more like Facebook (#safebook)

20. Dezember 2010, 14:58 Erstellt von Herbert Wagger (256 clicks)

Facebook is easy to use, as well as being a robust tool. Grandparents can pick up enough to browse pictures of their grandchildren in a matter of minutes, while teenagers can manage their entire soci …

Wie kann ich Dialoge und Code in einer anderen Datenbank nutzen?

20. Dezember 2010, 13:44 Erstellt von Manfred Meise (28 clicks)

Dieses Codebeispiel zeigt die Bearbeitung von Dokumenten einer Datenbank mit bestehendem Code in der anderen Datenbank. Umfangreichere Anwendungen bestehen oftmals aus mehreren Datenbanken. Wie kann man nun whrend der  Arbeit in einer Datenbank…

Wie kann ich Dialoge und Code in einer anderen Datenbank nutzen?

20. Dezember 2010, 11:44 Erstellt von Manfred Meise (14 clicks)

Dieses Codebeispiel zeigt die Bearbeitung von Dokumenten einer Datenbank mit bestehendem Code in der anderen Datenbank.

Umfangreichere Anwendungen bestehen oftmals aus mehreren Datenbanken. Wie kann man nun während der  Arbeit in einer Datenbank dort Dokumente auswählen, die durch einen Dialog und damit verbundenen Funktionen einer anderen Datenbank bearbeitet werden?

Hierzu kann z.B. ein Agent eingesetzt werden, der auf selektierte Dokumente arbeitet und nachfolgenden Code ausführt:

 
Sub
Initialize
     
      Dim uiws         As New NotesUIWorkspace
      Dim s         As New NotesSession
      Dim col         As NotesDocumentCollection
     
      Dim docThis        As NotesDocument        
      Dim docThat        As NotesDocument
     
      Dim dbThis        As NotesDatabase
      Dim dbThat        As NotesDatabase
     
      Dim vArray() As variant
      Dim i         As integer
     
      Const strDatabaseToCall = "develop/mm/r82spielwiese"
     
      Set dbThis = s.Currentdatabase
      Set dbThat = s.Getdatabase(dbThis.Server, strDatabaseToCall)
     
      Set col = dbThis.Unprocesseddocuments
      ReDim vArray(col.Count) As Variant
     
      Set docThis = col.Getfirstdocument()
      i = 0
     
      While Not docThis Is Nothing
              vArray(i) = docThis.Universalid
             
              Set docThis = col.Getnextdocument(docThis)
              i = i + 1
             
      Wend
     
      Set docThat = dbThat.Createdocument()
     
      docThat.OtherDBServer         = dbThis.server        
      docThat.OtherDBPath                = dbThis.Filepath
      docThat.OtherDocs                 = vArray
     
      Call uiws.Dialogbox("Dialog", true, true,,,,, "Dialogaufruf aus einer fremden DB", docThat, true)
     
      MessageBox ("Getroffene Auswahl in Fremddialog: " & cstr(docThat.Selection(0)))
     
End
Sub

In der anderen Datenbank muss eine Maske „Dialog“ existieren, die z.B. lokale Scriptbibliotheken rufen kann und (für die Funktion des obigen Beispieles) auch Rückgabewerte anbieten kann.

Hintergrundinformation:
Diese Beispiel funktioniert deshalb, weil die „DialogBox“-Funktion ein vordefiniertes Dokument benötigt und abhängig davon, in welcher Datenbank dieses Dokument besteht, diese Datenbank verwendet, um benötigte Gestaltungselemente zu laden. Da der aufgerufene Dialog modal ist, kann diese Werte setzen, welche vom aufrufenden Code (in der Ursprungsdatenbank) verarbeitet werden kann.

Wie kann ich Dialoge und Code in einer anderen Datenbank nutzen?

20. Dezember 2010, 11:44 Erstellt von Manfred Meise (10 clicks)

Dieses Codebeispiel zeigt die Bearbeitung von Dokumenten einer Datenbank mit bestehendem Code in der anderen Datenbank.

Umfangreichere Anwendungen bestehen oftmals aus mehreren Datenbanken. Wie kann man nun während der  Arbeit in einer Datenbank dort Dokumente auswählen, die durch einen Dialog und damit verbundenen Funktionen einer anderen Datenbank bearbeitet werden?

Hierzu kann z.B. ein Agent eingesetzt werden, der auf selektierte Dokumente arbeitet und nachfolgenden Code ausführt:

 
Sub
Initialize
     
      Dim uiws         As New NotesUIWorkspace
      Dim s         As New NotesSession
      Dim col         As NotesDocumentCollection
     
      Dim docThis        As NotesDocument        
      Dim docThat        As NotesDocument
     
      Dim dbThis        As NotesDatabase
      Dim dbThat        As NotesDatabase
     
      Dim vArray() As variant
      Dim i         As integer
     
      Const strDatabaseToCall = "develop/mm/r82spielwiese"
     
      Set dbThis = s.Currentdatabase
      Set dbThat = s.Getdatabase(dbThis.Server, strDatabaseToCall)
     
      Set col = dbThis.Unprocesseddocuments
      ReDim vArray(col.Count) As Variant
     
      Set docThis = col.Getfirstdocument()
      i = 0
     
      While Not docThis Is Nothing
              vArray(i) = docThis.Universalid
             
              Set docThis = col.Getnextdocument(docThis)
              i = i + 1
             
      Wend
     
      Set docThat = dbThat.Createdocument()
     
      docThat.OtherDBServer         = dbThis.server        
      docThat.OtherDBPath                = dbThis.Filepath
      docThat.OtherDocs                 = vArray
     
      Call uiws.Dialogbox("Dialog", true, true,,,,, "Dialogaufruf aus einer fremden DB", docThat, true)
     
      MessageBox ("Getroffene Auswahl in Fremddialog: " & cstr(docThat.Selection(0)))
     
End
Sub

In der anderen Datenbank muss eine Maske „Dialog“ existieren, die z.B. lokale Scriptbibliotheken rufen kann und (für die Funktion des obigen Beispieles) auch Rückgabewerte anbieten kann.

Hintergrundinformation:
Diese Beispiel funktioniert deshalb, weil die „DialogBox“-Funktion ein vordefiniertes Dokument benötigt und abhängig davon, in welcher Datenbank dieses Dokument besteht, diese Datenbank verwendet, um benötigte Gestaltungselemente zu laden. Da der aufgerufene Dialog modal ist, kann diese Werte setzen, welche vom aufrufenden Code (in der Ursprungsdatenbank) verarbeitet werden kann.

Wie kann ich Dialoge und Code in einer anderen Datenbank nutzen?

20. Dezember 2010, 11:44 Erstellt von Manfred Meise (9 clicks)

Dieses Codebeispiel zeigt die Bearbeitung von Dokumenten einer Datenbank mit bestehendem Code in der anderen Datenbank.

Umfangreichere Anwendungen bestehen oftmals aus mehreren Datenbanken. Wie kann man nun während der  Arbeit in einer Datenbank dort Dokumente auswählen, die durch einen Dialog und damit verbundenen Funktionen einer anderen Datenbank bearbeitet werden?

Hierzu kann z.B. ein Agent eingesetzt werden, der auf selektierte Dokumente arbeitet und nachfolgenden Code ausfĂĽhrt:

 
Sub
Initialize
     
      Dim uiws         As New NotesUIWorkspace
      Dim s         As New NotesSession
      Dim col         As NotesDocumentCollection
     
      Dim docThis        As NotesDocument        
      Dim docThat        As NotesDocument
     
      Dim dbThis        As NotesDatabase
      Dim dbThat        As NotesDatabase
     
      Dim vArray() As variant
      Dim i         As integer
     
      Const strDatabaseToCall = "develop/mm/r82spielwiese"
     
      Set dbThis = s.Currentdatabase
      Set dbThat = s.Getdatabase(dbThis.Server, strDatabaseToCall)
     
      Set col = dbThis.Unprocesseddocuments
      ReDim vArray(col.Count) As Variant
     
      Set docThis = col.Getfirstdocument()
      i = 0
     
      While Not docThis Is Nothing
              vArray(i) = docThis.Universalid
             
              Set docThis = col.Getnextdocument(docThis)
              i = i + 1
             
      Wend
     
      Set docThat = dbThat.Createdocument()
     
      docThat.OtherDBServer         = dbThis.server        
      docThat.OtherDBPath                = dbThis.Filepath
      docThat.OtherDocs                 = vArray
     
      Call uiws.Dialogbox("Dialog", true, true,,,,, "Dialogaufruf aus einer fremden DB", docThat, true)
     
      MessageBox ("Getroffene Auswahl in Fremddialog: " & cstr(docThat.Selection(0)))
     
End
Sub

In der anderen Datenbank muss eine Maske „Dialog“ existieren, die z.B. lokale Scriptbibliotheken rufen kann und (fĂĽr die Funktion des obigen Beispieles) auch RĂĽckgabewerte anbieten kann.

Hintergrundinformation:
Diese Beispiel funktioniert deshalb, weil die „DialogBox“-Funktion ein vordefiniertes Dokument benötigt und abhängig davon, in welcher Datenbank dieses Dokument besteht, diese Datenbank verwendet, um benötigte Gestaltungselemente zu laden. Da der aufgerufene Dialog modal ist, kann diese Werte setzen, welche vom aufrufenden Code (in der Ursprungsdatenbank) verarbeitet werden kann.

Die "Goldenen Regeln" der Lotus Domino Administration

20. Dezember 2010, 10:15 Erstellt von Manfred Meise (28 clicks)

Um einen mglichst strungsfreien Betrieb der Lotus Notes/Domino Infrastruktur zu gewhrleisten, sind lediglich ein paar Grundregeln zu beachten und einzuhalten. Oder anders formuliert: wer gegen eine dieser Grundregeln verstt oder sie missachtet, schaff…

Die „Goldenen Regeln“ der Lotus Domino Administration

20. Dezember 2010, 08:15 Erstellt von Manfred Meise (9 clicks)

Um einen möglichst störungsfreien Betrieb der Lotus Notes/Domino Infrastruktur zu gewährleisten, sind lediglich ein paar Grundregeln zu beachten und einzuhalten. Oder anders formuliert: wer gegen eine dieser Grundregeln verstößt oder sie missachtet, schafft sich unnötigen zusätzlichen (potentiellen) Ärger.

Die Liste erhebt keinen Anspruch auf Vollständigkeit und wird (angereichert aus negativen Projekterfahrungen) erweitert werden.

Als verantwortungsvoller Lotus Domino Administrator werde ich …..

1. Niemals zwei Repliken einer Datenbank auf dem gleichen Server ablegen
2. Niemals Datenbankdateien eines Dominoservers auf Betriebssystemebene manipulieren (erstellen, umbenennen, löschen, kopieren)
3. RĂĽcksicherungen von Datenbanken aus Datensicherungen nicht auf den gleichen Domino-Server legen, von dem die Datenbank stammt (siehe Pkt 1)
4. Außerplanmäßige Replikationen zwischen Servern stets über einen Konsolenbefehl (z.B. Serverkonsole im Lotus Domino Administrator, nicht Replikatorseite des Lotus Notes Clients) anstoßen
5. Bei Einsatz von Transaktionsprotokollierung stets eine separate Festplatte (physikalisches Device)  einsetzen und ausreichend Platz fĂĽr die Transaktionsprotokollierung anbieten
6. Transaktionsprotokollierung von Typ „archivierend“ nur einsetzen, wenn auch eine Datensicherungssoftware eingesetzt wird, die dieses unterstĂĽtzt.
7. Um aus Schablonen eigene Datenbanken zu erstellen: „Datei -> Datenbank neu“ verwenden, und nicht auf Betriebssystemebene den Dateinamen umbenennen oder kopieren.
8. VerzeichnisverknĂĽpfungen (DIR-Links) stets so einrichten, dass das Ziel der VerknĂĽpfung auĂźerhalb des Notes/Domino Datenverzeichnisses zeigt. Nicht verschiedene DIR-Links auf das gleiche Ziel verweisen lassen.
9. Auf dem System des IBM Domino Servers keinen Lotus Notes/Domino Client installieren, oder den Client-Teil des Servers starten
10.  Datum/Uhrzeit auf allen Servern/Clients auf Betriebssystemebene und in Lotus Notes/Domino (Server und Client) auf „Sommerzeit gilt hier“ bzw. „von OS ĂĽbernehmen stellen“ und nach Inbetriebnahme der Software nicht mehr ändern (auch die Uhrzeiten nicht vor-/zurĂĽckstellen)
11. Stets alle Server physikalisch sichern, da Replikationen (auch ClusterReplikationen) niemals eine physikalische Datensicherung ersetzen.
12. Server stets durchgehend laufen lassen (besonders: Nachts nicht wegen eine OffLine Datensicherung ausschalten) um Housekeeping Functions durchzufĂĽhren zu lassen
13. Server, die längere Zeit nicht am Netz waren bzw. regelmäßig repliziert haben (z.B. länger als 6 Wochen) nicht wieder ans Netz (Replikationen) nehmen, sondern Datenbankreplikate neu holen.
14. Regelmäßig (mindestens 1/Tag) alle Systemdatenbanken replizieren.
15. Servern fremder Domino Domänen NICHT Manager-Berechtigung auf Datenbanken auf eigenen Servern einräumen.
16. Bei Verwendung verschiedener Releases auf verschiedenen Servern stets die Schablonen der höchsten Release für Systemdatenbanken einsetzen (Abwärtskompatibilität ist gegeben).
17. Bei Einsatz von Betriebssystem-Virenscannern (speziell auf Domino Servern) mindestens das Datenverzeichnis von einer Prüfung ausschließen. Bei Multiuser Installationen von Clients die Datenverzeichnisse aller Benutzer oder (wenn nicht möglich, mindestens *.nsf, *.ntf, *.box) ausnehmen, um korrupte Datenbanken zu vermeiden.
18. Jeden Domino Server mit einem spezialisierten Virenscanner ausstatten, der die Datenbankinhalte prĂĽft.
19. Nur die Servertasks aktivieren, die auch benötigt und sauber konfiguriert sind
20. FĂĽr ausscheidende Benutzer nicht lediglich das Personendokument löschen, sondern die dafĂĽr vorgesehene „Benutzer löschen“ verwenden, um den Administrationsprozess mit einer vollständigen Löschung des Benutzers und Eintrag in eine negativ-Gruppe zu beauftragen
21. Benutzer im Falle von vergessenen Kennwörtern keine ID  (aus „alten Zeiten“) zur VerfĂĽgung stellen, sondern den ID-Vault oder Kennwortwiederherstellung verwenden
22 keine Netzwerkfreigaben auf Serverfestplatten erlauben/konfigurieren, auf denen das Domino Directory (oder andere Datenbanken) des Servers gespeichert sind
23. Wenn Benutzer mit falschem Namen angelegt wurden (noch bevor ein Client in Betrieb genommen wurde), diesen nicht umbenennen, sondern entweder vollständig löschen oder eine Umbenennung erst nach der Client Inbetriebnahme anstoßen.

Die „Goldenen Regeln“ der Lotus Domino Administration

20. Dezember 2010, 08:15 Erstellt von Manfred Meise (14 clicks)

Um einen möglichst störungsfreien Betrieb der Lotus Notes/Domino Infrastruktur zu gewährleisten, sind lediglich ein paar Grundregeln zu beachten und einzuhalten. Oder anders formuliert: wer gegen eine dieser Grundregeln verstößt oder sie missachtet, schafft sich unnötigen zusätzlichen (potentiellen) Ärger.

Die Liste erhebt keinen Anspruch auf Vollständigkeit und wird (angereichert aus negativen Projekterfahrungen) erweitert werden.

Als verantwortungsvoller Lotus Domino Administrator werde ich …..

1. Niemals zwei Repliken einer Datenbank auf dem gleichen Server ablegen
2. Niemals Datenbankdateien eines Dominoservers auf Betriebssystemebene manipulieren (erstellen, umbenennen, löschen, kopieren)
3. Rücksicherungen von Datenbanken aus Datensicherungen nicht auf den gleichen Domino-Server legen, von dem die Datenbank stammt (siehe Pkt 1)
4. Außerplanmäßige Replikationen zwischen Servern stets über einen Konsolenbefehl (z.B. Serverkonsole im Lotus Domino Administrator, nicht Replikatorseite des Lotus Notes Clients) anstoßen
5. Bei Einsatz von Transaktionsprotokollierung stets eine separate Festplatte (physikalisches Device)  einsetzen und ausreichend Platz für die Transaktionsprotokollierung anbieten
6. Transaktionsprotokollierung von Typ „archivierend“ nur einsetzen, wenn auch eine Datensicherungssoftware eingesetzt wird, die dieses unterstützt.
7. Um aus Schablonen eigene Datenbanken zu erstellen: „Datei -> Datenbank neu“ verwenden, und nicht auf Betriebssystemebene den Dateinamen umbenennen oder kopieren.
8. Verzeichnisverknüpfungen (DIR-Links) stets so einrichten, dass das Ziel der Verknüpfung außerhalb des Notes/Domino Datenverzeichnisses zeigt. Nicht verschiedene DIR-Links auf das gleiche Ziel verweisen lassen.
9. Auf dem System des IBM Domino Servers keinen Lotus Notes/Domino Client installieren, oder den Client-Teil des Servers starten
10.  Datum/Uhrzeit auf allen Servern/Clients auf Betriebssystemebene und in Lotus Notes/Domino (Server und Client) auf „Sommerzeit gilt hier“ bzw. „von OS übernehmen stellen“ und nach Inbetriebnahme der Software nicht mehr ändern (auch die Uhrzeiten nicht vor-/zurückstellen)
11. Stets alle Server physikalisch sichern, da Replikationen (auch ClusterReplikationen) niemals eine physikalische Datensicherung ersetzen.
12. Server stets durchgehend laufen lassen (besonders: Nachts nicht wegen eine OffLine Datensicherung ausschalten) um Housekeeping Functions durchzuführen zu lassen
13. Server, die längere Zeit nicht am Netz waren bzw. regelmäßig repliziert haben (z.B. länger als 6 Wochen) nicht wieder ans Netz (Replikationen) nehmen, sondern Datenbankreplikate neu holen.
14. Regelmäßig (mindestens 1/Tag) alle Systemdatenbanken replizieren.
15. Servern fremder Domino Domänen NICHT Manager-Berechtigung auf Datenbanken auf eigenen Servern einräumen.
16. Bei Verwendung verschiedener Releases auf verschiedenen Servern stets die Schablonen der höchsten Release für Systemdatenbanken einsetzen (Abwärtskompatibilität ist gegeben).
17. Bei Einsatz von Betriebssystem-Virenscannern (speziell auf Domino Servern) mindestens das Datenverzeichnis von einer Prüfung ausschließen. Bei Multiuser Installationen von Clients die Datenverzeichnisse aller Benutzer oder (wenn nicht möglich, mindestens *.nsf, *.ntf, *.box) ausnehmen, um korrupte Datenbanken zu vermeiden.
18. Jeden Domino Server mit einem spezialisierten Virenscanner ausstatten, der die Datenbankinhalte prüft.
19. Nur die Servertasks aktivieren, die auch benötigt und sauber konfiguriert sind
20. Für ausscheidende Benutzer nicht lediglich das Personendokument löschen, sondern die dafür vorgesehene „Benutzer löschen“ verwenden, um den Administrationsprozess mit einer vollständigen Löschung des Benutzers und Eintrag in eine negativ-Gruppe zu beauftragen
21. Benutzer im Falle von vergessenen Kennwörtern keine ID  (aus „alten Zeiten“) zur Verfügung stellen, sondern den ID-Vault oder Kennwortwiederherstellung verwenden
22 keine Netzwerkfreigaben auf Serverfestplatten erlauben/konfigurieren, auf denen das Domino Directory (oder andere Datenbanken) des Servers gespeichert sind
23. Wenn Benutzer mit falschem Namen angelegt wurden (noch bevor ein Client in Betrieb genommen wurde), diesen nicht umbenennen, sondern entweder vollständig löschen oder eine Umbenennung erst nach der Client Inbetriebnahme anstoßen.

Die „Goldenen Regeln“ der Lotus Domino Administration

20. Dezember 2010, 08:15 Erstellt von Manfred Meise (14 clicks)

Um einen möglichst störungsfreien Betrieb der Lotus Notes/Domino Infrastruktur zu gewährleisten, sind lediglich ein paar Grundregeln zu beachten und einzuhalten. Oder anders formuliert: wer gegen eine dieser Grundregeln verstößt oder sie missachtet, schafft sich unnötigen zusätzlichen (potentiellen) Ärger.

Die Liste erhebt keinen Anspruch auf Vollständigkeit und wird (angereichert aus negativen Projekterfahrungen) erweitert werden.

Als verantwortungsvoller Lotus Domino Administrator werde ich …..

1. Niemals zwei Repliken einer Datenbank auf dem gleichen Server ablegen
2. Niemals Datenbankdateien eines Dominoservers auf Betriebssystemebene manipulieren (erstellen, umbenennen, löschen, kopieren)
3. Rücksicherungen von Datenbanken aus Datensicherungen nicht auf den gleichen Domino-Server legen, von dem die Datenbank stammt (siehe Pkt 1)
4. Außerplanmäßige Replikationen zwischen Servern stets über einen Konsolenbefehl (z.B. Serverkonsole im Lotus Domino Administrator, nicht Replikatorseite des Lotus Notes Clients) anstoßen
5. Bei Einsatz von Transaktionsprotokollierung stets eine separate Festplatte (physikalisches Device)  einsetzen und ausreichend Platz für die Transaktionsprotokollierung anbieten
6. Transaktionsprotokollierung von Typ „archivierend“ nur einsetzen, wenn auch eine Datensicherungssoftware eingesetzt wird, die dieses unterstützt.
7. Um aus Schablonen eigene Datenbanken zu erstellen: „Datei -> Datenbank neu“ verwenden, und nicht auf Betriebssystemebene den Dateinamen umbenennen oder kopieren.
8. Verzeichnisverknüpfungen (DIR-Links) stets so einrichten, dass das Ziel der Verknüpfung außerhalb des Notes/Domino Datenverzeichnisses zeigt. Nicht verschiedene DIR-Links auf das gleiche Ziel verweisen lassen.
9. Auf dem System des IBM Domino Servers keinen Lotus Notes/Domino Client installieren, oder den Client-Teil des Servers starten
10.  Datum/Uhrzeit auf allen Servern/Clients auf Betriebssystemebene und in Lotus Notes/Domino (Server und Client) auf „Sommerzeit gilt hier“ bzw. „von OS übernehmen stellen“ und nach Inbetriebnahme der Software nicht mehr ändern (auch die Uhrzeiten nicht vor-/zurückstellen)
11. Stets alle Server physikalisch sichern, da Replikationen (auch ClusterReplikationen) niemals eine physikalische Datensicherung ersetzen.
12. Server stets durchgehend laufen lassen (besonders: Nachts nicht wegen eine OffLine Datensicherung ausschalten) um Housekeeping Functions durchzuführen zu lassen
13. Server, die längere Zeit nicht am Netz waren bzw. regelmäßig repliziert haben (z.B. länger als 6 Wochen) nicht wieder ans Netz (Replikationen) nehmen, sondern Datenbankreplikate neu holen.
14. Regelmäßig (mindestens 1/Tag) alle Systemdatenbanken replizieren.
15. Servern fremder Domino Domänen NICHT Manager-Berechtigung auf Datenbanken auf eigenen Servern einräumen.
16. Bei Verwendung verschiedener Releases auf verschiedenen Servern stets die Schablonen der höchsten Release für Systemdatenbanken einsetzen (Abwärtskompatibilität ist gegeben).
17. Bei Einsatz von Betriebssystem-Virenscannern (speziell auf Domino Servern) mindestens das Datenverzeichnis von einer Prüfung ausschließen. Bei Multiuser Installationen von Clients die Datenverzeichnisse aller Benutzer oder (wenn nicht möglich, mindestens *.nsf, *.ntf, *.box) ausnehmen, um korrupte Datenbanken zu vermeiden.
18. Jeden Domino Server mit einem spezialisierten Virenscanner ausstatten, der die Datenbankinhalte prüft.
19. Nur die Servertasks aktivieren, die auch benötigt und sauber konfiguriert sind
20. Für ausscheidende Benutzer nicht lediglich das Personendokument löschen, sondern die dafür vorgesehene „Benutzer löschen“ verwenden, um den Administrationsprozess mit einer vollständigen Löschung des Benutzers und Eintrag in eine negativ-Gruppe zu beauftragen
21. Benutzer im Falle von vergessenen Kennwörtern keine ID  (aus „alten Zeiten“) zur Verfügung stellen, sondern den ID-Vault oder Kennwortwiederherstellung verwenden
22 keine Netzwerkfreigaben auf Serverfestplatten erlauben/konfigurieren, auf denen das Domino Directory (oder andere Datenbanken) des Servers gespeichert sind
23. Wenn Benutzer mit falschem Namen angelegt wurden (noch bevor ein Client in Betrieb genommen wurde), diesen nicht umbenennen, sondern entweder vollständig löschen oder eine Umbenennung erst nach der Client Inbetriebnahme anstoßen.

What's hot