HCL Domino Systemadministration 2
Herzlich Willkommen!/eLearning/HCL Domino Systemadministration 2

HCL Domino Systemadministration 2

Ü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?

  • 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

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

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.

2. Arbeiten mit mehreren Domänen/Organisationen

2.1. Kursumgebung für Lektionen in diesen Kapitel + Server-Setup

Dauer: 9m 51s

2.2. Kommunikation zwischen fremden Domänen/Organisationen

Dauer: 2m 25s

2.3. Auswahl der Ebene für die Gegenzertifizierung (O, OU, User- bzw. Server-ID)

Dauer: 8m 2s

2.4. Einrichtung der Gegenzertifizierung

Dauer: 19m 36s

2.5. Mailrouting zwischen fremden Domänen

Dauer: 9m 28s

2.6. Replikation zwischen fremden Domänen

2.7. Domänendokumente

Dauer: 12m 53s

2.8. Einbindung fremder Verzeichnisse (Directories)

Dauer: 27m 2s

2.9. Zusammenführung von Domänen/Organisationen

Dauer: 4m 38s

2.10. Kursumgebung für alle weiteren Lektionen in diesem Kurs

Dauer: 4m 26s
 

2.11. PDFs zu diesem Kapitel

3. Benutzerverwaltung

3.1. Automatisches Befüllen von Gruppen

Dauer: 8m 21s

3.2. Rekursive Auflösung von Gruppenmitgliedschaften

Dauer: 6m 12s

3.3. Abwesenheitsservice generiert Out-of-Office Meldungen

Dauer: 9m 53s

3.4. Überwachung der Anwenderlizenzen - Lizenzverfolgung

Dauer: 10m 16s

4. Benutzerverwaltung: ID Vault

4.1. Was ist der ID Vault?

Dauer: 4m 32s

4.2. Voraussetzungen für den ID Vault

Dauer: 2m 33s

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

Dauer: 14m 3s

4.5. Überprüfung der ID Vault Einrichtung

Dauer: 6m 33s

4.6. Hochladen der Anwender ID-Dateien in den ID Vault

Dauer: 7m 21s

4.7. Nutzung des ID Vaults: Anwender hat das Kennwort vergessen

Dauer: 6m 9s

4.8. Nutzung des ID Vaults: Anwender ID-Datei wurde gelöscht

Dauer: 5m 16s

4.9. Nutzung des ID Vaults: Anwender ID-Datei extrahieren

Dauer: 4m 25s

4.10. Umsetzung von Änderungen an der ID Vault Konfiguration

Dauer: 4m 36s

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.
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.
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.
 
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).
notion image
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 -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.
 
notion image
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

Dauer: 16m 59s

4.13. PDFs zu diesem Kapitel

5. Mailrouting

5.1. Mehr Details zu gerouteten Mails in der Datenbank LOG.NSF

Dauer: 5m 42s

5.2. Rückruf von Nachrichten

10m 43s

5.3. Nachrichtenverfolgung (Message Tracking)

Dauer: 19m 57s

6. Mailrouting: SMTP

6.1. Eingehende SMTP Nachrichten

Dauer: 16m 20s

6.2. Ausgehende SMTP Nachrichten beim Einsatz eines Domino Servers

Dauer: 9m 9s

6.3. Ausgehende SMTP Nachrichten beim Einsatz mehrerer Domino Server

Dauer: 14m 44s

7. Datenbanken: ODS (On Disk Structure)

7.1. Was genau ist die ODS?

Dauer: 10m 58s

7.2. Aktuelle ODS Versionen

Dauer: 7m 46s

7.3. Ändern der ODS

Dauer: 10m 14s

7.4. Ändern der ODS für alle Datenbanken (System-DBs, Templates, Mailboxen)

Dauer: 7m 19s

7.5. Design- und Nutzdatenkomprimierung

Dauer: 4m 56s

7.6. PDF zu diesem Kapitel

8. Datenbanken: Transaktionsprotokollierung

8.1. Was ist die Transaktionsprotokollierung?

Dauer: 4m 56s

8.2. Aktivierung der Transaktionsprotokollierung

Dauer: 13m 18s

8.3. Bedeutung der Datenbank Instanz-ID (DBIID)

Dauer: 3m 37s

8.4. PDF zu diesem Kapitel

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

Dauer: 2m 13s

9.3. DAOS auf dem Domino Server einrichten

Dauer: 15m 41s

9.4. DAOS für gewünschte Datenbanken aktivieren

Dauer: 3m 7s

9.5. Reduzierung des erforderlichen Speicherplatzes (Beispiel)

Dauer: 4m 13s

9.6. Herauslösen von älteren Dateianhängen aus der NSF-Datei

Dauer: 5m 13s

9.7. Besonderheiten bei DAOS NLO-Dateien

Dauer: 8m 30s

9.8. DAOS Konsolenbefehle und ein Tipp

Dauer: 6m 17s

9.9. PDF zu diesem Kapitel

10. Datenbanken: Domänenkatalog und Domänensuche

10.1. Domänensuche und die Datenbank CATALOG.NSF

Dauer: 8m 25s

10.2. Aktivierung der Domänensuche für Datenbanken

Dauer: 1m 58s

10.3. Aktivieren der Domänensuche auf einem Domino Server

Dauer: 5m 52s

10.4. Erstellung des Domänensuchindex durch den Domänen Indexer Task

Dauer: 3m 51s

10.5. Problemlösung: Aufnahme von Datenbanken in den Domänensuchindex

Dauer: 10m 39s

10.6. Settings und Durchführen einer Domänensuche im Notes Client

Dauer: 6m 11s

11. Monitoring: Domino Konsolen

11.1. Allgemeine Einstellungen für die Domino Server Konsolen

Dauer: 11m 29s

11.2. Konsole im Domino Administrator Client

Dauer: 3m 21s

11.3. HCL Domino Konsole

Dauer: 13m 43s

11.4. LOG Filter

Dauer: 7m 14s

12. Monitoring klassisch: Statistik- und Ereignisüberwachung

12.1. Domino Designer optional: Navigation in der EVENTS4.NSF umbauen

Dauer: 7m 59s

12.2. Statistikwerte des Domino Servers

Dauer: 4m 37s

12.3. Speichern der Statistikwerte in der Datenbank 'Monitoring Results' (STATREP.NSF)

Dauer: 12m 16s

12.4. Überwachung selbst definierter Statistik-Grenzwerte durch Alarmdokumente

Dauer: 10m 54s

12.5. Benachrichtigungen (z.B. eMail) und mögliche Serveraktivitäten

Dauer: 16m 54s

12.6. Ereignisse: Datenbank

Dauer: 8m 16s

12.7. Ereignisse: Domino Server

Dauer: 2m 10s

12.8. Ereignisse: TCP Server

Dauer: 2m 12s

12.9. Ereignisse - Mailrouting

Dauer: 1m 42s

12.10. Ereignisse: Task Status

Dauer: 1m 27s

12.11. Weitere Ansichten der EVENTS4.NSF unter Navigationspunkt 'Advanced’

Dauer: 10m 2s

12.12. Setup Wizards

Dauer: 2m 5s

13. Monitoring: DDM (Domino Domain Monitoring)

13.1. Was ist Domino Domain Monitoring?

Dauer: 6m 20s

13.2. DDM Ereignisse

Dauer: 15m 6s

13.3. DDM Probes - was soll zusätzlich überwacht werden?

Dauer: 9m 9s

13.4. DDM Filter - welche Ereignisse in der Datenbank DDM.NSF speichern?

Dauer: 3m 31s

13.5. DDM - Hierarchische Serverstruktur für das Sammeln der DDM Ereignisse

Dauer: 7m 5s

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

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

Dauer: 5m 43s

14.3. Was passiert während der Einrichtung des Clusters?

Dauer: 3m 43s

14.4. Die Datenbank CLDBDIR.NSF (Cluster Database Directory)

Dauer: 4m 41s

14.5. Verteilen der Datenbanken im Cluster

Dauer: 4m 0s

14.6. Test des Clusters (Cluster-Replikator und Failover)

Dauer: 10m 37s

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 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 beim
Ausfall 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

notion image
Durch den Konsolenbefehl TELL CLREPL [options] können z.B. Statusinformationen des Cluster-Replicators abgerufen oder die Clusterreplikation pausiert oder erneut gestartet werden.

14.8. Domino Cluster auflösen

Dauer: 2m 10s

14.9. Neue Funktion ab Domino Version 10 - Symmetrischer Cluster

Dauer: 24m 13s

15. Domino Server: weitere Funktionen und Tools

15.1. Ressourcen – Besprechungsplanung erweitert um Unternehmensressourcen

Dauer: 20m 7s

15.2. Domino Server als LDAP Server - Änderung des LDAP Schemas

Dauer: 10m 29s

15.3. Automatischer Neustart nach Abstürzen

Dauer: 3m 40s

15.4. Domino Server konsolidieren - Stilllegungsanalyse

Dauer: 4m 54s

15.5. DCT - Domino Configuration Tuner

5m 42