Über den Kurs
Weiterführende Themen der Domino Administration.
Geeignet für Domino Version 9.0.1 bis 14.x
Falls Dir der Kurs nützlich ist:
Was lerne ich in diesem Kurs?
- Arbeiten mit mehreren Domänen/Organisationen
- Benutzerverwaltung (inkl. ID-Vault)
- Mailrouting (SMTP Mailrouting, Nachrichtenrückruf)
- Notes/Domino Datenbanken (ODS, Komprimierung Design/Nutzdaten, Transaktionsprotokollierung, DAOS, Domänenkatalog- und suche)
- Überwachung von Domino Servern (Konsolen, klassisches Monitoring, Domino Domain Monitoring - DDM)
- Domino Cluster (Konzept, Voraussetzungen, Komponenten, Einrichtung, spezielle Einstellungen/Befehle, Cluster auflösen)
- Domino Server – weitere Funktionen und Tools (Ressourcen für Beprechungsplanung, LDAP-Schema anpassen, Automatischer Neustart, Stillegungsanalyse, DCT)
Welche Anforderungen oder Voraussetzungen gelten für diesen Kurs?
- Inhalte des Kurses HCL Domino Systemadministration 1 sollten bekannt oder vergleichbare Kenntnisse vorhanden sein
- Falls Du die im Seminar gezeigten Schritte selbst umsetzen möchtest, ist Windows 10/11 Pro und die HCL Notes/Domino Software erforderlich
An wen richtet sich dieser Kurs?
- Personen, welche die Grundlagen der HCL Domino Administration kennen und sich mit weiterführenden Themen beschäftigen möchten
- Personen, welche spezielle Funktionen des Domino Servers in ihrer Umgebung nutzen möchten.
Passend zum Kurs: Mein Buch als gedruckte Ausgabe oder PDF-Datei
HCL Domino 12 Systemadministration 2
1. Einführung
1.1. Herzlich Willkommen!
Ich freue mich, dass Du dich für meinen Kurs "HCL Domino Systemadministration 2" entschieden hast und heiße Dich herzlich Willkommen!
Da ich schon unzählige Seminare mit zwischenzeitlich über 1.000 Teilnehmer*Innen durchgeführt habe, bin ich mir ziemlich sicher, dass auch Dir dieser Kurs sehr nützlich sein wird.
Falls Du Fragen hast oder bestimmte Inhalte für Dich nicht verständlich sind, sende mir eine Mail an eLearning@madicon.de - ich werde schnellstmöglich antworten.
Nun wünsche ich Dir bei meinem Kurs ganz viel Freude und einen maximalen Lernerfolg!
Viele Grüße,
Manfred
Manfred
1.2. Was ist für die Durchführung dieses Kurses erforderlich?
Der Kurs soll als Workshop einen hohen Praxisbezug haben und daher werden wir eine komplett neue Notes/Domino Umgebung installieren. Ich weiss von vielen Einsteiger*Innen, dass man im Unternehmen die existierende Domino-Infrastruktur schon "etwas gezeigt" bekommen hat, aber überhaupt keine Ahnung hat, wie so ein Domino Server "ans Laufen" kommt. In diesem Kurs wirst Du das alles kennenlernen.
Normalerweise ist ein Domino Server laut HCL-Vorgaben auf einem Windows Server (oder einem der anderen möglichen Serverbetriebssystemen - z.B. Linux) zu installieren.
Da wir im Seminar lediglich eine "Spielumgebung" implementieren, eignet sich auch Windows 10/11 Pro sehr gut. Ausgestattet mit einer halbwegs aktuellen CPU und mit 3-4 GByte RAM werden alle im Kurs gezeigten Funktionen flüssig laufen.
Falls Du auch bei Dir eine "Spielumgebung" installieren möchtest, benötigst Du folgendes:
- Windows 10/11 Pro (das müssen keine physischen PC's sein - eine virtuelle Maschine ist auch geeignet)Einen Domino Server + Domino Administrator Client kann man auf einer Windows-Instanz installieren - falls es mehrere Domino Server werden sollen, gilt als Regel:
1 x Windows 10/11 Pro für jeden Domino Server
- Notes Client (inkl. Administrator) und Domino Server Version 9.0.1.x bis 14.x
Bevor jemand fragt: Notes und Domino sind kommerzielle Produkte der Firma HCL und können nicht "einfach so" irgendwo heruntergeladen werden.
Da Du aber vermutlich als Mitarbeiter eines Unternehmens an diesem Kurs teilnimmst (Notes/Domino wird kaum von Privatpersonen genutzt),sollte
die Software im Unternehmen verfügbar sein.
die Software im Unternehmen verfügbar sein.
2. Arbeiten mit mehreren Domänen/Organisationen
2.1. Kursumgebung für Lektionen in diesen Kapitel + Server-Setup
2.2. Kommunikation zwischen fremden Domänen/Organisationen
2.3. Auswahl der Ebene für die Gegenzertifizierung (O, OU, User- bzw. Server-ID)
2.4. Einrichtung der Gegenzertifizierung
2.5. Mailrouting zwischen fremden Domänen
2.6. Replikation zwischen fremden Domänen
2.7. Domänendokumente
2.8. Einbindung fremder Verzeichnisse (Directories)
2.9. Zusammenführung von Domänen/Organisationen
2.10. Kursumgebung für alle weiteren Lektionen in diesem Kurs
2.11. PDFs zu diesem Kapitel
3. Benutzerverwaltung
4. Benutzerverwaltung: ID Vault
4.1. Was ist der ID Vault?
4.2. Voraussetzungen für den ID Vault
4.3. Wie funktioniert der ID Vault?
- Bestehende Notes Anwender: Nachdem die Richtlinien wirksam sind, wird die Anwender ID-Datei beim ersten Anmelden des Anwenders in den Vault kopiert (zufallsgesteuerter Zeitpunkt, kann bis zu 8 Stunden dauern).
- Neu registrierte Anwender: Die Anwender ID-Datei wird schon während der Registrierung in den Vault kopiert.
Synchronisation der lokalen Anwender ID-Datei mit dem ID Vault
Bei Änderung des Passwortes, Einfügen eines Zertifikates o.ä. erfolgt die Synchronisation in den ID Vault sofort (Voraussetzung: der Homeserver
ist im Arbeitsumgebungsdokument korrekt eingetragen).
ist im Arbeitsumgebungsdokument korrekt eingetragen).
Bei einem Fehlschlag (z.B. Verbindungsproblemen o.ä.) werden 3 weitere Versuche nach jeweils 5 Minuten unternommen. Sind diese Versuche erfolglos,
erfolgen weitere Versuche erst nach ca. 8 Stunden.
erfolgen weitere Versuche erst nach ca. 8 Stunden.
Da es in der Praxis zu längeren Verzögerungen kommen kann, sollte die ID Vault Datenbank regelmäßig durch die Administration kontrolliert werden.
Bei Passwortänderung im Offline-Betrieb wird die Anwender ID-Datei bei der nächsten Verbindung mit dem Server in den Vault kopiert.
Synchronisation von geänderten Anwender ID-Dateien
Wird eine Anwender ID-Datei geändert (z.B. Passwortänderung, Umzertifizierung des Anwenders oder Verlängerung der Gültigkeit), so ist diese Änderung sofort an jedem Arbeitsplatz (z.B. wahlweise Nutzung eines Notebooks oder eines stationären Arbeitsplatzes) verfügbar. Dies
gilt unter der Voraussetzung, dass der ID Vault erreichbar ist.
gilt unter der Voraussetzung, dass der ID Vault erreichbar ist.
Wiederherstellung von gelöschten Anwender ID-Dateien
Wird eine Anwender ID-Datei versehentlich gelöscht, so wird diese beim nächsten Start des Notes Clients automatisch aus dem ID Vault auf den Notes Client kopiert. Es sind hierbei keine weiteren Schritte der Administration erforderlich.
4.4. Einrichtung des ID Vaults
4.5. Überprüfung der ID Vault Einrichtung
4.6. Hochladen der Anwender ID-Dateien in den ID Vault
4.7. Nutzung des ID Vaults: Anwender hat das Kennwort vergessen
4.8. Nutzung des ID Vaults: Anwender ID-Datei wurde gelöscht
4.9. Nutzung des ID Vaults: Anwender ID-Datei extrahieren
4.10. Umsetzung von Änderungen an der ID Vault Konfiguration
4.11. Dokumentation: Neuerungen des ID Vaults ab Domino Version 10
Um was geht es?
Wenn sich Passwörter von Notes User-IDs von den im ID-Vault gespeicherten ID-Dateien unterscheiden, stoppt die Synchronisation von
ID-Informationen zwischen Notes Clients und dem ID-Vault.
ID-Informationen zwischen Notes Clients und dem ID-Vault.
Typischerweise lösen folgende Vorgänge unterschiedliche Passwörter aus:
- Ein Administrator führt einen Passwortreset durch, aber der Anwender verwendet nicht das neue Passwort.
- Ein Anwender ändert sein Passwort und synchronisiert erfolgreich mit dem ID-Vault. Später verwendet er eine ältere Variante seiner ID-Datei mit einem alten Passwort.
Mit Domino Version 10 können Sie den automatischen Neustart der Synchronisation aktivieren, falls die Passwörter nicht mehr synchron sind. Sie können auch Konsolenbefehle oder den Domino Administrator verwenden, um die ID-Synchronisierung zu überwachen und zu verwalten.
Neustart der Synchronisation - Aktivierung
Um die im ID-Vault gespeicherte Notes-ID Datei im Falle unterschiedlicher Passwörter durch die aktuelle Notes-ID Datei des Anwenders zu ersetzen,
kann folgender Eintrag in der Datei NOTES.INI verwendet werden.
kann folgender Eintrag in der Datei NOTES.INI verwendet werden.
Enable_Autorecovery_FromBadPassword=1
Der Austausch der Notes-ID erfolgt erst, wenn die die Synchronisation für mehr als 7 Tage nicht mehr funktioniert hat.
Neustart der Synchronisation - Funktionsweise
Sobald aufgrund eines unterschiedlichen Passworts die Synchronisation fehlschlägt, wird dies im ID-Vault im entsprechenden Anwenderdokument verbucht (z.B. im Feld FirstBadPassword).
Nachdem mehr als 7 Tage ohne erfolgreiche Synchronisation vergangen sind, wird das entsprechende Anwenderdokument im ID-Vault so umbenannt, dass der Titel mit einer Tilde (˜) beginnt. Solche Dokumente werden Archivdokumente genannt.
Beim nächsten Versuch einer Synchronisierung wird das Anwenderdokument wegen der Umbenennung nicht mehr im ID-Vault gefunden und die Notes-ID wird
erneut hochgeladen. Hiernach sollte die Synchronisation wieder einwandfrei funktionieren.
erneut hochgeladen. Hiernach sollte die Synchronisation wieder einwandfrei funktionieren.
Neustart der Synchronisation - Verwaltung
Durch den Konsolenbefehl load qvault sowie durch eine neue Option im Domino Administrator können verschiedene Optionen beim Management des ID-Vault genutzt werden.
Zunächst muss der Datei NOTES.INI der folgende Eintrag hinzugefügt werden:
IDV_Enable_Vault_Scan=1
Nun kann der Konsoltenbefehl
load qvault
verwendet werden (ggf. Servern-Neustart erforderlich).Abbildung 1: ID-Vault - Optionen des Konsolenbefehls load qvault
Beispiel (Achte auf die Nutzung von kanonischen Notes-Namen):
load qvault -x O=IDTresor -u "CN=Hans Tester/O=Training"
Bei Aufruf nur mit dem Parameter -x <vaultname> werden alle Dokumente im angegebenen ID-Vault gescannt und Informationen (Bezug zum Vault, letzter Änderungszeitpunkt des VaultDokumentes) in die Personendokumente im Domino Verzeichnis (names.nsf) geschrieben.
Durch die zusätzlichen Parameter lassen sich die Anwender- und Archivdokumente auch verwalten - so kann ein Anwenderdokument im Vault z.B. mit dem
Parameter
Parameter
-a
in den Archivierungsmodus (es wird die Tilde (˜) angezeigt) gesetzt werden.Im Gegensatz zum Konsolenbefehl kann mit dem Domino Administrator lediglich eine Aktualisierung der Personendokumente im Domino Directory
vorgenommen werden.
vorgenommen werden.
Abbildung 2: ID-Vault - Verwaltung im Domino Administrator
Wie im Screenshot zu sehen, kann die Aktualisierung einzelner Anwender in der Personenübersicht durchgeführt werden.
Um Informationen für alle in einem bestimmten ID-Vault gespeicherten Anwender zu aktualisieren, wählen Sie auf dem Register »Konfiguration« die Optionen »Sicherheit« ⇒ »ID-Vaults« und dann rechts bei den Werkzeugen »ID-Vaults« ⇒ »Tresor scannen«.
4.12. Video: Neuerungen des ID Vaults ab Domino Version 10
4.13. PDFs zu diesem Kapitel
5. Mailrouting
6. Mailrouting: SMTP
7. Datenbanken: ODS (On Disk Structure)
8. Datenbanken: Transaktionsprotokollierung
9. Datenbanken: DAOS
9.1. Voraussetzungen für die Nutzung von DAOS
Für den Einsatz von DAOS auf einem Domino Server sind folgende Voraussetzungen erforderlich.
- Domino Server Version 8.5 oder höher.
- Aktualisierung der für die Nutzung von DAOS vorgesehenen Datenbanken auf mindestens ODS 51.
- Aktivierung der Transaktionsprotokollierung.
- Aktivierung der Datenbankeigenschaft
Use Domino Attachment and Object Service
bei den Datenbanken, welche für die Nutzung von DAOS vorgesehen sind.
9.2. Einsatz von DAOS bei unterschiedlichen Versionen der Domino Server
9.3. DAOS auf dem Domino Server einrichten
9.4. DAOS für gewünschte Datenbanken aktivieren
9.5. Reduzierung des erforderlichen Speicherplatzes (Beispiel)
9.6. Herauslösen von älteren Dateianhängen aus der NSF-Datei
9.7. Besonderheiten bei DAOS NLO-Dateien
9.8. DAOS Konsolenbefehle und ein Tipp
9.9. PDF zu diesem Kapitel
10. Datenbanken: Domänenkatalog und Domänensuche
10.1. Domänensuche und die Datenbank CATALOG.NSF
10.2. Aktivierung der Domänensuche für Datenbanken
10.3. Aktivieren der Domänensuche auf einem Domino Server
10.4. Erstellung des Domänensuchindex durch den Domänen Indexer Task
10.5. Problemlösung: Aufnahme von Datenbanken in den Domänensuchindex
10.6. Settings und Durchführen einer Domänensuche im Notes Client
11. Monitoring: Domino Konsolen
12. Monitoring klassisch: Statistik- und Ereignisüberwachung
12.1. Domino Designer optional: Navigation in der EVENTS4.NSF umbauen
12.2. Statistikwerte des Domino Servers
12.3. Speichern der Statistikwerte in der Datenbank 'Monitoring Results' (STATREP.NSF)
12.4. Überwachung selbst definierter Statistik-Grenzwerte durch Alarmdokumente
12.5. Benachrichtigungen (z.B. eMail) und mögliche Serveraktivitäten
12.6. Ereignisse: Datenbank
12.7. Ereignisse: Domino Server
12.8. Ereignisse: TCP Server
12.9. Ereignisse - Mailrouting
12.10. Ereignisse: Task Status
12.11. Weitere Ansichten der EVENTS4.NSF unter Navigationspunkt 'Advanced’
12.12. Setup Wizards
13. Monitoring: DDM (Domino Domain Monitoring)
14. Domino Cluster
14.1. Konzept, Voraussetzungen und Komponenten
Konzept
Die Idee hinter einem Domino Cluster ist, eine 100-prozentige Verfügbarkeit der Domino Ressourcen für die Anwender zu gewährleisten. Hierzu werden mehrere Domino Server in einen Verbund (den Cluster) gestellt und können sich unter dem Aspekt der zur Verfügung stehenden Performance (Load Balancing) oder bei
Fehlern (Failover) unterstützen.
Fehlern (Failover) unterstützen.
Beim Domino Cluster handelt es sich um einen aktiven Cluster, d.h. alle Domino Server sind in Betrieb und können so ohne Verzögerung Anwender von einem anderen Domino Server im Cluster übernehmen. Obgleich man für die Clusterreplikation ein privates/separates LAN verwenden kann, gibt es grundsätzlich keine
besonderen Hardware Voraussetzungen.
besonderen Hardware Voraussetzungen.
Voraussetzungen
Für den Betrieb eines Domino Servers gelten die folgenden Voraussetzungen.
- Alle Domino Server in einem Cluster müssen mit dem Lizenztyp 'Enterprise' oder 'Utility' installiert sein.
- Alle Domino Server müssen über eine schnelle LAN oder WAN Verbindung miteinander kommunizieren. Für die Replikation im Cluster kann zur Reduzierung der Last im Netzwerk ein privates LAN (separate Netzwerkadapter mit dedizierter LAN-Verbindung) verwendet werden.
- Alle Domino Server müssen das Protokoll TCP/IP verwenden und sich im selben benannten Netzwerk (NNN/DNN) befinden.
- Alle Domino Server müssen sich in derselben Domäne befinden und ein Verzeichnis (NAMES.NSF) benutzen.
- Für die Domäne muss ein Administrationsserver spezifiziert sein. Dieser muss NICHT zwingend ein Mitglied des Clusters sein.
- Ein Domino Server kann zu einem Zeitpunkt nur in EINEM Cluster Mitglied sein.
- Jeder Domino Server sollte über ausreichend Plattenplatz verfügen. Im Cluster müssen viele Datenbanken (z.B. Maildatenbanken der Anwender) als Replik erteilt werden.
- Zur Verarbeitung der zusätzlichen Aufgaben als Mitglied eines Clusters sollten die Domino Server ausreichend dimensioniert sein.
Komponenten
Im Cluster werden folgende Komponenten verwendet. Diese sind entweder automatisch durch die Installation eines 'Enterprise' oder 'Utility' Servers verfügbar oder werden beim Aktivieren des Clusters erstellt.
- Cluster Manager
Der Cluster Manager Task läuft auf jedem Domino Server im Cluster und beobachtet den Status der anderen Cluster-Mitglieder - hierbei führt der Cluster Manager eine Liste mit der Verfügbarkeit und der aktuellen Last der anderen Domino Server im Cluster.
- Cluster Database Directory
Die Cluster Database Directory Datenbank (CLDBDIR.NSF) existiert als Replik auf allen Domino Servern eine Clusters. In dieser Datenbank wird für jede Datenbank und deren Repliken ein Dokument mit Informationen zum Datenbank-Titel, zum Dateinamen, zur Replik-ID und zum Domino Server gespeichert - somit wissen alle Domino Server, welche Cluster-Mitglieder über eine Replik einer bestimmten Datenbank verfügen.
- Cluster Database Directory Manager
Der Cluster Database Directory Manager erstellt das Cluster Database Directory und hält diese Datenbank auf dem aktuellen Stand.
- Cluster Administrator
Der Cluster Administrator verwaltet als kontrollierende Instanz die auf einem Cluster-Mitglied aktivierten Komponenten. So startet der Cluster Administrator z.B. beim Hinzufügen eines Domino Servers zum Cluster den Task Cluster Database Directory Manager und den Task Cluster Replicator.
- Cluster Replicator
Der Cluster Replicator sorgt durch eine Echtzeit-Replikation für einen Gleichstand der Datenbankrepliken in einem Cluster. Sobald ein Cluster in einer Datenbank Änderungen an einer Datenbank feststellt, werden diese Änderungen sofort an alle im Cluster befindlichen Repliken verteilt.
Hinweis
Wir werden den Cluster zunächst OHNE die ab Domino Version 10 verfügbaren Funktionen (z.B. automatisch Verteilung von Repkliken im Cluster sowie Reparatur von Datenbanken im Cluster) erstellen und Nutzen. So können auch Teilnehmer, welche aktuell noch Domino 9 nutzen, allen Schritten folgen.
In der letzten Lektion zum Domino Cluster schauen wir uns die Neuerungen ab Domino Version 10 an.
14.2. Erstellen eines Clusters / Hinzufügen von Servern zum Cluster
14.3. Was passiert während der Einrichtung des Clusters?
14.4. Die Datenbank CLDBDIR.NSF (Cluster Database Directory)
14.5. Verteilen der Datenbanken im Cluster
14.6. Test des Clusters (Cluster-Replikator und Failover)
14.7. Spezielle Einstellungen / Befehle
Das Verhalten des Clusters kann durch Einträge der Datei NOTES.INI der einzelnen Clusterserver beeinflusst werden. Zusätzlich existieren auch Konsolenbefehle zur Anzeige von Cluster-Details.
SERVER_RESTRICTED - Manuelles Failover erzwingen
Wenn es aufgrund von z.B. Wartungsarbeiten erforderlich ist, einen Cluster-Server "außer Dienst" zu stellen, kann dies durch den Parameter SERVER_RESTRICED in der Datei NOTES.INI erfolgen. Zulässige Werte sind:
SERVER_RESTRICTED=0
Der Server arbeitet normal und nimmt Benutzeranfragen entgegen.
SERVER_RESTRICTED=1
Der Server verhält sich, als sei er vollständig ausgelastet und leitet weitere Benutzeranfragen an andere Domino Server im Cluster. Dieser Wert gilt nur für den aktuellen Serverlauf und wird nach einem Neustart des ervers wieder auf Null gesetzt.
SERVER_RESTRICTED=2
Der Server verhält sich, als sei er vollständig ausgelastet und leitet weitere Benutzeranfragen an andere Domino Server im Cluster. Dieser Wert bleibt auch nach einem Serverneustart erhalten.
SERVER_AVAILABILITY_THRESHOLD - Lastverteilung im Cluster
Ein Domino Server verwaltet intern einen Statistikparameter bzgl. seiner Verfügbarkeit - dieser Wert kann zwischen 0 (nicht verfügbar) und 100 (sehr gut verfügbar) liegen.
Hinweis
Diesen Availabilityindex kann man sich jederzeit über den Konsolenbefehl
SHOW SERVER
anschauen.Durch den Eintrag
Ausfall des Domino Servers ein Failover durchgeführt) und 100 liegen.
SERVER_AVAILABILITY_THRESHOLD
in der Datei NOTES.INI, kannst Du festlegen, welch minimaler Availabilityindex für den Domino Server akzeptabel ist. Fällt der Availabilityindex unter den Wert des SERVER_AVAILABILITY_THRESHOLD
, so wird der Server als BUSY eingestuft und weitere Anwender werden auf einen anderen Domino Server im Cluster umgeleitet (Load Balancing). Der Wert darf zwischen 0 (Server ist immer verfügbar, es wird nur beimAusfall des Domino Servers ein Failover durchgeführt) und 100 liegen.
Beispiel
SERVER_AVAILABILITY_THRESHOLD=30
RTR_LOGGING - Mehr Details zum Cluster-Replikation
Um weitere Details zur Cluster-Replikation zu erhalten kann der Eintrag
RTR_LOGGING
in der Datei NOTES.INI des Domino Servers verwendet werden.Folgende Paramter sind zulässig (original Beschreibung von IBM):
RTR_Logging= 1
Default level of logging (major routines, events, etc.)
RTR_Logging= 2
Log all context structure changes
RTR_Logging= 4
Log replications: attempted & performed
RTR_Logging= 8
Log iterations through main polling loop
RTR_Logging=16
Verbose debug logging 'RTR_Logging=32'. Log all lock operations
Example
For verbose logging and default logging, set the value to 16 + 1 = 17. The highest value you could set is 1 + 2 + 4 + 8 + 16 + 32 = 63.
Konsolenbefehl TELL CLREPL
Durch den Konsolenbefehl
TELL CLREPL [options]
können z.B. Statusinformationen des Cluster-Replicators abgerufen oder die Clusterreplikation pausiert oder erneut gestartet werden.