In der letzten Woche meldete ein Kunde ein Problem mit einem seiner IBM Domino Server. Nach einem Neustart erfolgte im Sekunden Takt immer folgende Meldung:
Abb. 1: Zensierter Auszug aus dem Serverlog
Der Domino Server wiederholte diese Meldungen über einen Zeitraum von mehreren Stunden bis er schlussendlich abstürzte.
Der Kunde bat uns nun um eine Problemlösung und eine Erläuterung, worauf dieses Verhalten zurückzuführen sei.
Kurz zur Umgebung: der Server ist auf der Notes und Domino Version 8.5, Shared Mail ist deaktiviert, DAOS (Domino attachment and object service) ist aktiviert.
Shared Mail war ein Feature, das zu den Ursprüngen von DAOS gerechnet werden kann. Mit Hilfe von Shared Mail konnten Attachments von E-Mails über verschiedene Postfächer geteilt werden und somit Speicherplatz eingespart werden. Mit der heutigen Domino Version wird dieses Feature nicht mehr weiter unterstützt, ersatzweise wurde die bessere DAOS Technik implementiert. Soviel zur Historie von "Gemeinsame Mail".
Die Kunst bei Shared Mail liegt vor allem in dessen Deaktivierung. Ist der Shared Mail Object Storage nämlich einmal gelöscht ist dies nicht mehr so einfach möglich.
Um das Feature ordnungsgemäß zu deaktivieren, muss man alle Postfächer, welche diese Technik mit nutzen, sozusagen "unlinken". Dies erfolgt mittels dreier Konsolen Befehle (Vgl. IBM Technote)
Load Object collect -force <mail>
<Mail> ist dabei der Ordner, in welchem die Postfächer liegen, bzw. kann auch eine explizite Datei sein.
Load Object Unlink <shared_directory>
<shared_directory> ist dabei der Ordner, welcher im Serverdokument unter dem Reiter "Gemeinsame Mail" konfiguriert ist.
Abb. 2: Serverdokument, Reiter "Gemeinsame Mail", an den gelb markierten Stellen stehen ggf. die konfigurierten Ordner.
Load Object Unlink <mail>
<Mail> ist dabei der Ordner, in welchem die Postfächer liegen, bzw. kann auch eine explizite Datei sein.
Nachdem diese Befehle abgearbeitet sind, kann Shared Mail im Konfigurationsdokument des IBM Domino Server deaktiviert werden.
Deaktiviert man so das "Gemeinsame Mail" Feature, wird man zukünftig nie wieder damit belästigt und kann ganz in Ruhe weiterarbeiten. Tut man dies hingegen nicht, indem man zum Beispiel nur im Serverdokument die Einstellung entfernt und ggf. sogar noch den Shared Mail Storage löscht, kann man zukünftig an die Probleme geraten, die wir nun beim Kunden zu lösen hatten.
Fakt war, dass der Shared Mail Storage nicht mehr vorhanden war. Somit brachte die von IBM empfohlene Vorgehensweise keine Erfolge, schließlich gab es keine Tickets im Object Store welche zurück in das Postfach migriert hätten werden können. In Absprache mit dem Kunden haben wir nicht versucht die Daten aus alten Sicherungen wieder herzustellen, sondern sind auf seinen Wunsch das Thema radikaler angegangen. Alle E-Mails, welche noch Verweise auf den ObjectStore enthielten, sollten restlos gelöscht werden.
Die Frage bestand nun darin wie man entsprechende E-Mails identifizieren kann. IBM liefert die Antwort (Vgl. IBM Technote).
E-Mails, welche Gebrauch vom Shared Mail Object Store machen, haben ein Feld mit dem Namen "$ObjectStoreSize".
Abb. 3: Dokumenten Eigenschaften, Feld "$ObjectStoreSize" identifiziert betroffene Dokumente.
Also wurde ein Agent programmiert, welcher alle entsprechenden Dokumente in den Datenbanken löscht. Anschließend wurde der "unlink"-Befehl auf die Datenbank ausgeführt. Beim nächsten Neustart waren die Fehlermeldungen verschwunden.
Abb. 4: Unlink Object Store vom Postfach, es mussten keine Notes mehr verarbeitet werden.
Gerade Features wie DAOS oder auch Shared Mail sollten nicht ohne tiefer gehende Kenntnisse deaktiviert oder gar nach der Deaktivierung ihrer Stores/Repositorys einfach gelöscht werden. Dadurch entstehen an den Datenbanken und dem Datenbestand ggf. irreparable oder nur mit immensem Aufwand zu behebende Schäden.
Da DAOS deaktiviertes Shared Mail als Voraussetzung hat, passiert gerade dies aber in letzter Zeit sicherlich in der ein oder anderen Domino Umgebung recht schnell. Sprecht uns lieber an, wir helfen gerne mit unserem KnowHow und stehen euch bei der Deaktivierung, Rekonfiguration und auch Wiederherstellung tatkräftig zur Seite!