Beiträge von Berlin142

    Ich sage mal so: Das Problem liegt offenbar an gaanz anderer Stelle, ausserhalb dem, was man so machen kann.


    Ja, ich habe Circullar Logging aktiviert und sehe auch, dass jeden Tag max. 2 Logfiles (d.h. max. 210 MB TA-Volumen) "produziert" werden. Maintanance zu ändern macht keinen Sinn, weil ja gar keine mails über den Server laufen. Logging habe ich schon mal hochgesetzt, Ergebnis ist quasi Null. Und Message Tracking - es werden keine nachrichten über den Server gesendet, er dient nur zur F/B Abfrage in Notes. Deshalb liegt auch nichts in den Queues e.g.. Was ich nicht weis ist, wie sich der Konnektor in Bezug auf Turf-Objekte verhält (und nach den Erfahrungen mit den RedBull Migrationstools bin ich sicher etwas vorsichtig). Allerdings sollte hier Tombstone greifen, so dass da eigentlich auch kein Problem auftauchen sollte.


    Wie schon geschrieben - ein edbview zeigt gar nichts an. Und Komprimierung der DB hilft nicht. Ich werde sie wohl oder über mal löschen.


    Jens

    Moin!


    Wie ich schon schrieb - die Sache ist mystisch. Ich werde wahrscheinlich einfach den Notes-Konnektor stoppen und die datenbank löschen. Startet man dann den IS neu, so sollte die DB ja wieder angelegt werden. Allerdings befürchte ich, dass es dann wieder so wird....


    Die Datenbank enthält lt. edbview gar nichts - zumindest kann nichts angezeigt werden. Die einzige Postfach enthält dei Mails. Tombstone steht auf einem Tag, kann es also auch nicht sein. Und die DB enthält nicht einmal 200 MB frein Speicher (nach Defragmentierung). Ein Versuch einer Offline-Kompaktierung brachte gar nicht, das Teil wächst nach wie vor ca. 100 MB pro Tag. Wer weis, was das ist, ich werde vielleicht die datei mal nach Redmond zur Product group senden. :)


    Jens

    Ein newsletter-Script versendet ja Mails. Wenn du also sicherstellst, dass die mail an eine für Exchange inbound gültige Addresse gesendet wird, gibt es kein Problem. Um zu verhindern, dass trotzdem Mails nach aussen geraten, verbiete Relaying. Dann bleibt spätestens auf MSX alles stecken.


    Jens

    Nun ist das problem, dass es keine mailboxen auf dem Server gibt. Das TA-Volumen ist minimal (<10 MB pro Tag, da eben nur F/B Abfragen). Und die Systempostfächer sind quasi leer.


    Ich habe bereits in die Datenbank hineingesehen, kann nur gar nichts finden - scheinbar sind keine daten vorhanden und in der stm ist nur Un fug zu finden (dort kann man ansonsten schon einige "Spässe" machen).


    Wenn man mich fragen würde, was ich sehe: die DB ist leer. nur "glaubt" exchange nicht daran. Es ist einfach niht nachvollziehbar, wo die Daten liegen.


    Jens

    Ein -1018 Fehler ist definitiv nicht mit ISINTEG zu beheben, sondern nur mit ESEUTIL. Und hier solltest du (nach Offline backup!!) die Option /P verwenden.


    -1018 ist immer ein Bug auf physischem level - die fehlen schlicht ein paar seiten deiner Speicherstruktur. Nach der reparatur werden so wohl auch ein paar daten fehlen, was aber i.A. niemand merkt.


    Es gibt eigentlich 2 Gründe für den fehler: Lesefehler und Plattendefekt. Der erste Grund ist i.A. temporärer Natur, nach einem Online-Backup sollte solch ein Fehler behoben sein (die Checksummen der Pages werden dabei neu berechnet und geschrieben). da aber bei dir das Backup versagt, liegt wohl ein fehler auf dem medium (HDD) vor. Hier solltest du einmal ein chkdsk laufen lassen und dann ggf. die Platte wechseln.


    Jens

    Nimm's mal nicht so wörtlich. Er meint offenbar, dass der MX Record auf sein Gateway zeigt und deshalb via DNS die Mails direkt und nicht über ein anderes Gateway zugestellt werden. Und die Lösung im SP2 ist zwar ganz nett, aber vieeeellll zu träge. Oder wird bei dir die Blacklist alle 15' korrigiert? Spammer sind sehr schnell, dehalnb gibt es Lösungen wie MIMESweüer oder BrightMail.