mail.que wächst

1. offizieller Beitrag

    Hallo,


    ich habe auf einem Exchange Server Version 15.0 (Build 1178.4) das Problem, das die mail.que zu groß ist (80 GB :wacko: )
    Die beiden anderen Server in der DAG haben eine mail.que mit 30 GB und 35 GB.


    Mir ist noch nicht ganz klar woher das kommt, ich habe

    • SafetyNetHoldTime geprüft (2 Tage)
    • MessageExpirationTimeout geprüft (2 Tage)
    • Pipeline Tracing ist deaktiviert


    Der Anstieg ist nicht schnell sondern im Verlauf der letzten 2 Jahre gekommen, deshalb wäre mir primär wichtig die Datei wieder auf eine normale Größe zu bekommen.


    Ich hätte am kommenden Wochenende sowieso eine Downtime zum patchen und überlege, ob ich


    1. Stop Microsoft Exchange Transport service.
    2. Rename mail.que file (ie. mail.que.old).
    3. Start Microsoft Exchange Transport.
    4. Delete mail.que.old file.


    durchführe.
    Müssten dann auch die Log Files in diesem data/QUEUE Ordner gelöscht oder verschoben werden?


    Ist anscheinend auch eine Empfehlung von MS, allerdings habe ich auch Beiträge gefunden wo das vorgehen nicht funktioniert hat und die alte mail.que mit eseutil zu reparieren war.


    Gibt es noch eine andere Möglichkeit (außer Plattenplatz erweitern ;( )


    Stefan

    Hi Norbert,


    mit dem Script meinst du wahrscheinlich RedistributeActiveDatabases.ps1.


    Muss dann der komplette Inhalt des Ordners gelöscht werden oder nur die eine Datei mail.que?


    Danke schon mal
    Stefan

    • Offizieller Beitrag

    Moin,


    nein, das meine ich nicht.


    Das heißt Move-TransportDataBase.ps1


    Danach kannst du den ganzen Ordner endgültig löschen - natürlich vorher prüfen, ob am Zielort die DB-Struktur entsprechend der eingegebenen Parameter erzeugt wurde.


    ;)
    Nachtrag - die DB wird ganz gerne vergessen und auf C gelassen, das ggf. recht schnell zu klein sein kann, und fällt man in die Backpressure-Falle.

    Hi,


    ah jetzt habe ich das verstanden, Super Hinweis :thumbup:


    Eine Frage hätte ich noch zum Verständnis, ob ich da richtig bin mit meiner Überlegung :?:


    Eine der SafetyNet Funktionen ist ja das eine Mail in der mail.que gehalten wird, bis der nächste Hop den vollständigen Erhalt der Nachricht bestätigt.
    Dur das Verfahren das du beschreibst werden diese Informationen ja gehalten.
    Heist ja das selbst wenn der Speicherort gleich bleiben soll es sinnvoller ist erst mal zu verschieben, und dann wieder zurück an den ursprünglichen Ort zurück.
    Wenn ich nur den Transport Dienst anhalte und die Datei lösche, verliere ich diese Information von den nicht bestätigten Mails.


    Liege ich falsch ?(


    Stefan

    • Offizieller Beitrag

    Nein, hast du richtig verstanden.


    Und noch mal zur Sicherheit, die Transport-DB hat auf dem System-Laufwerk nichts zu suchen.


    Wenn man genug Ressourcen hat, packe ich die sogar auf ein eigenes Laufwerk / Volumen, die DB kann je nach Traffic auch schnell mal größer werden.


    ;)

    Hi Norbert,


    wie du schon geschrieben hast habe ich an die Datenbank bei der Installation nicht beachtet.


    Ich werde sie jetzt auf ein anderes Laufwerk legen.


    Grüße & Danke
    Stefan

    Hallo,


    habe heute Nacht die Verzeichnisse auf ein anderes Laufwerk gelegt.
    Es gab dann das Problem, das sich der Transportdienst nach ca 30 Sekunden ohne Fehler wieder beendet hat.


    Es lag dann an den Berechtigungen auf dem neuen Laufwerk.


    Die Verzeichnisse werden automatisch angelegt wenn sie nicht existieren.
    Das ist unabhängig ob man es mit Script oder durch Ändern der EdgeTransport.exe.config durchführt.


    Wenn man es durch Ändern der Config Datei macht muss der übergeordnete Ordner folgende Rechte haben:

    • Netzwerkdienst: Vollzugriff
    • System: Vollzugriff
    • Administratoren: Vollzugriff

    Da ich es mit dem Script gemacht habe bin ich davon ausgegangen, das die Rechte erstellt werden.
    Bei mir hatte der Netzwerkdienst gefehlt.


    Hat ein wenig gedauert bis ich es gefunden habe, deshalb hier nochmals zur Vollständigkeit.


    Stefan