Beiträge von Romy

Hallo,

also strg-umschalt-f9 brachte leider keine Lösung.

Das Problem scheint jetzt aber behoben zu sein:

Lösung:
1) DB-Backup, lokal öffnen, Inhalt Posteingang in neuen Ordner verschieben
2) auf produktiver DB 2. Ordner anlegen, den ggf. vorhandenen Mails aus Posteingang hinein verschieben
3) Replizieren von lokal nach produktiv (nur in eine Richtung)
4) im Designer $inbox löschen
5) Schablone der produktiven DB wechseln
6) Inhalt der beiden neuen Ordner in den Posteingang kopieren
7) im Administrator die compact -D drüber laufen lassen
Testmail schicken... und alles ist ok :-)))

Es hat sich nach Recherchen herausgestellt, dass nach dem Restore alles ok ist und auch die Mails in der Inbox ankommen. Erst am nächsten Tag liegt das Problem wieder vor. (Nachts läuft der Designer)
Ich vermute das es daran liegen könnte.

Ich werde jetzt nochmal eine Sicherung zurück holen, alles in einen Ordner kopieren, replizieren und dann zunächst einen Schablonenwechsel vornehmen und dann erst die mails aus dem Ordner in die Inbox stellen.

Hallo Bastian,

wir benutzen die deutsche Schablone.

Leider kann deine Lösung ausgeschlossen werden, da dies bereits getestet wurde und keine Abhilfe geschafft hatte.

Leider ist es auch so, dass das Backup, das zurückgesichert wurde zum Zeitpunkt X, als alles ok war.. (und danach eine lokale Kopieraktion der Inbox-Mails in einen neuen Ordner, Replizierung und danach zurückkopieren aus dem Ordner in den Posteingang) mittlerweile auch hinfällig war, denn die so bereinigten Mailboxen weisen den Fehler erneut auf.

Also wenn das irgend wer auch schonmal hatte, oder ne Lösung weiß... bitte an mich

PS:
In der IBM Knowledgebase hab ich leider nichts brauchbares gefunden.

Gruß Romy

Hi,

vielleicht hilft es dir weiter..
unsere Frima ist auch von Trend Micro weg und benutzen jetzt den Webwasher. Vielleicht findest du ja auf deren Seiten Infos.

Die Bibliotheken und Verweise wurden überprüft, ebenso alle Rechte auf Dateien und Verzeichnisse, alle erforderlichen Dateien waren vorhanden und fehlerfrei. Jedoch war der Fehler nicht zu beheben.

Also:
Nachdem ziemlich viel Zeit in die Fehlersuche gesteckt wurde und keiner sich die Ursache erklären konnte, wurde entschieden das Problem durch die Deinstallation und danach Neuinstallation zu beheben.

Dies nahm inkl. Einrichtung ca. 30 min. in Anspruch, da die /usr/bin/dsm.sys - Einträge und die Knotenregistrierung bestehen bleiben konnte. Es musste nur das leidige Rechtesetzen/ Besitzerwechsel noch ausgefürhrt werden (chown / chmod) und die entsprechenden Einträge in der domdsm.cfg /dsm.opt ergänzt werden.

kleiner Tipp:
Die Installation wird als Root durchgeführt und TDP selbst läuft unter dem Dominouser---- in jedem Fall die Rechte des domdsmerror.log (/var/tmp/) überprüfen... stehen meist noch auf Root

Nach ausgiebigen Tests konnte der "alte" Fehler nicht reproduziert werden und bis heute läuft TDP fehlerfrei :-)))

Also wenn da wer noch Fragen zu TDP hat .. dann :-)))

Bei einigen User trat das Problem auf, das keine Mails mehr im Posteingang sind. Unter Alle Dokumente sind sie jedoch auffindbar.

bereits getätigte Maßnahmen/ Überprüfungen:
--> im Designer geprüft, ob nur eine $Inbox vorhanden ist
--> eine Sicherung unter einem anderen Verzeichnis zurück gesichert, lokal alle Mails aus dem Posteingang in einen neuen Ordner kopiert und danach repliziert
--> Problem war damit anscheinend behoben

Bei einigen trat der Effekt erneut auf, dass die Mails nicht im Posteingang landen, sondern nur unter alle Dokumente zu sehen sind.
Wie kann ich da Abhilfe schaffen???

Danke

Hat sich erledigt, Problem beseitigt

Bezieht sich auf TDP ( Tivoli Data protection for Mail)
Lotus Notes : 6.5.4
BOS: Solaris 9

Nach Installation von TDP funktioniert der erste der beiden user
wunderbar und der 2. bringt folgenden Fehler:

Befehl: domdsmc query adsmserver /adsmpwd=xxxxxxxx
Ausgabe: ld.so.1: domdsmc: fatal: libndgts.so: open failed

Maßnahmen:
- Alle Rechte wurden überprüft, stimmen
- ld.so.1 und libndgts.so existieren, Rechte ok
- dsmc --> rwsrwsrw- Rechte für beide User ok

Hat wer Ahnung, woran das liegen könnte????

Danke!

Die Lösung ist einfach:

also bei LN 6.5:
im Postfach auf
--> Werkzeuge --> Vorgaben gehen
unter dem Reiter Mail --> Allgemein ganz unten das Häkchen bei wiederherstellbare Löschungen setzen und (ich hab da 48h reingesetzt, klappt prima) die Stunden setzen.

Wenn jetzt jemand was löscht, wird es erst nach Ablauf dieser Zeit endgültig gelöscht und du hast keinen Ärger mehr :-))))

Die Programmdokumente (also compact) sind eingestellt und richtig, damit wird die serverbasierte Archivierung ausgeführt/ angestossen. Es ist auch klar, das per Policy nur das eine oder andere ausgeführt werden kann.

Jedoch:
Bei mir als normaler User ist es trotzdem möglich manuell über den o.g. Weg die Archivierung auszulösen ( Was ja erwünscht ist!!!)

Nur warum klappt das bei den anderen Usern nicht???

Wir haben testweise die serverbasierte Archivierung eingestellt. Jetzt soll zusätzlich das manuelle Auslösen der Archivierung möglich sein. Das wäre alles kein Problem: Bei mir funktioniert es einwandfrei, jedoch bei meinen Testkandidaten kommt immer die Fehlermeldung:
"Serverbasierte Archivierung aktiviert- Archivierung von lokaler Workstation aus nicht möglich"

Es wurde auch schon getestet, ob sie diese händisch genauso auslösen, wie ich. ( das tun sie)
Mails auswählen --> Aktionen --> Archiv --> ausgewählte Dokumente archivieren

Fakts:
--> Bei mir wird alles tadellos in die Archivdatenbank geschoben.
--> Die Policies sind bei allen Testern identisch!
--> Die Archivierungseinstellungen auch
--> Die Serverbasierte wird bei allen über Programmdokumente
gesteuert
--> bei allen wird vom Server x auf den Archivserver y archiviert
--> Archivdatenbank und Logdatenbank bei allen fehlerfrei
angelegt
--> habe mir einen User nur mit Standardrechten angelegt,
darunter funktioniert es ebenso, wie mit Adminrechten

Frage:

Wer kann mir einen Denkanstoß geben, woran es liegen kann, dass die manuelle Archivierung bei den anderen nicht geht?

Danke