none
Der Microsoft Exchange-Transportdienst weist Nachrichtenübermittlungen zurück, weil der verfügbare Speicherplatz den konfigurierten Schwellenwert unterschritten hat. RRS feed

  • Frage

  • Hallo,

    seit heute morgen geht die Nachrichtenübermittlung nicht mehr bei unserem Exchange 2010.
    In Ereignisprotokoll steht untenstehende Meldung.

    Die Warteschlange des Exchange enthält 0 Nachrichten.
    Was soll mir diese Meldung sagen, Festplatte voll ?

    Viele Grüße
    Roland

    Der Microsoft Exchange-Transportdienst weist Nachrichtenübermittlungen zurück, weil der verfügbare Speicherplatz den konfigurierten Schwellenwert unterschritten hat. 
    
    Die folgenden Ressourcen sind überlastet:
    Warteschlangen-Datenbankpfad ("C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\data\Queue\mail.que") = 97% [Medium] [Normal=95% Mittel=97% Hoch=99%]
    Warteschlangen-Datenbankprotokollierungspfad ("C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\data\Queue\") = 97% [Medium] [Normal=95% Mittel=97% Hoch=99%]
    
    Aufgrund von Rückstau wurden die folgenden Komponenten deaktiviert:
    Eingehende Nachrichtenübermittlung von Hub-Transport-Servern
    Eingehende Nachrichtenübermittlung aus dem Internet
    E-Mail-Übermittlung von PICKUP-Verzeichnis
    E-Mail-Übermittlung von Wiedergabeverzeichnis
    E-Mail-Übermittlung von Postfachserver
    E-Mail-Zustellung an Remotedomänen
    Der Ladevorgang für E-Mail aus der Warteschlangendatenbank wird fortgesetzt
    
    Die folgenden Ressourcen befinden sich im normalen Status:
    Version-Buckets = 0 [Normal] [Normal=80 Mittel=120 Hoch=200]
    Private Bytes = 0% [Normal] [Normal=71% Mittel=73% Hoch=75%]
    Auslastung des physikalischen Speichers = 12% [der Grenzwert ist 94%, bevor die Pausierung von Nachrichten gestartet wird.]
    Batchpunkt = 0 [Normal] [Standard = 2000 Mittel = 4000 Hoch = 8000]
    Übermittlungswarteschlange = 0 [Normal] [Normal = 1000 Mittel = 2000 Hoch = 4000]
    
    

    Montag, 29. September 2014 08:30

Antworten

  • Moin,

    korrekt. Die Meldung sagt, dass auf C: nicht mehr ausreichend freier Speicherplatz ist. Das nennt sich "Backpressure" (dt. schlecht mit "Rückstau" übersetzt):

    http://www.msexchange.org/articles-tutorials/exchange-server-2010/management-administration/back-pressure-exchange-2010-part1.html

    http://technet.microsoft.com/de-de/library/bb201658(v=exchg.141).aspx



    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    • Als Antwort markiert Roland_Schmid Montag, 29. September 2014 11:51
    Montag, 29. September 2014 08:49
  • Moin,

    natürlich musst Du das bei Dir mal konkret suchen.

    Aber bezogen auf Exchange:

     - Datenbank Transaktionsprotokolle, weil das Backup nicht läuft

     - IIS Logs, weil es dort seit 2008 keinen Standard mehr zum Löschen gibt

    Die normalen Exchange Logs (SMTP, Message Tracking, usw.) könnten ein Problem sein, wenn man die Standard-Einstellungen verändert hat.

    Nummer 1 auf der Liste ist aber ein menschliches Problem: Es hat sich schlicht keiner um den Server gekümmert. ;)


    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    • Als Antwort markiert Roland_Schmid Montag, 29. September 2014 11:52
    Montag, 29. September 2014 09:05
  • Hi Roland,

    die folgenden Punkte kannst du mal durchgehen:
    http://www.msxfaq.de/notfall/diskfull.htm


    Viele Grüße
    Christian

    • Als Antwort markiert Roland_Schmid Montag, 29. September 2014 11:52
    Montag, 29. September 2014 10:03
    Moderator
  • Richtig, die EDB wird nur bei einem Offline Defrag verkleinert. Wenn du Mails rauslöscht bekommst du halt "Whistespace" der dann wieder gefüllt wird und somit wächst die DB dann nicht so schnell.
    • Als Antwort markiert Roland_Schmid Montag, 29. September 2014 11:52
    Montag, 29. September 2014 10:27
  • Das muss man explizit bei Veeam einstellen, in der normalen "VSS" Sicherung werden die nicht gelöscht.

    http://www.veeam.com/kb1878 ist dir bekannt? 

    • Als Antwort markiert Roland_Schmid Montag, 29. September 2014 12:47
    Montag, 29. September 2014 12:35

Alle Antworten

  • Moin,

    korrekt. Die Meldung sagt, dass auf C: nicht mehr ausreichend freier Speicherplatz ist. Das nennt sich "Backpressure" (dt. schlecht mit "Rückstau" übersetzt):

    http://www.msexchange.org/articles-tutorials/exchange-server-2010/management-administration/back-pressure-exchange-2010-part1.html

    http://technet.microsoft.com/de-de/library/bb201658(v=exchg.141).aspx



    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    • Als Antwort markiert Roland_Schmid Montag, 29. September 2014 11:51
    Montag, 29. September 2014 08:49
  • Hi,

    was füllt den Festplatte so extrem?
    (natürlich nur auf den Exchange bezogen)

    Viele Grüße
    Roland

    Montag, 29. September 2014 09:00
  • Moin,

    natürlich musst Du das bei Dir mal konkret suchen.

    Aber bezogen auf Exchange:

     - Datenbank Transaktionsprotokolle, weil das Backup nicht läuft

     - IIS Logs, weil es dort seit 2008 keinen Standard mehr zum Löschen gibt

    Die normalen Exchange Logs (SMTP, Message Tracking, usw.) könnten ein Problem sein, wenn man die Standard-Einstellungen verändert hat.

    Nummer 1 auf der Liste ist aber ein menschliches Problem: Es hat sich schlicht keiner um den Server gekümmert. ;)


    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    • Als Antwort markiert Roland_Schmid Montag, 29. September 2014 11:52
    Montag, 29. September 2014 09:05
  • Nummer 1 auf der Liste ist aber ein menschliches Problem: Es hat sich schlicht keiner um den Server gekümmert. ;)

    ja, da gebe ich Dir Recht :-(

    Viele Grüße
    Roland

    Montag, 29. September 2014 09:26
  • Hi Roland,

    die folgenden Punkte kannst du mal durchgehen:
    http://www.msxfaq.de/notfall/diskfull.htm


    Viele Grüße
    Christian

    • Als Antwort markiert Roland_Schmid Montag, 29. September 2014 11:52
    Montag, 29. September 2014 10:03
    Moderator
  • Hi,

    ich habe noch eine Frage.
    Ist es richtig, dass beim Archivieren in eine pst Datei die Datenbank nicht kleiner, sondern nur "leerer" wird ?
    Die Idee ist, dass unsere User ihre Mails z.b. aus 2013 und 2012 archivieren, um die Postfachgröße zu verkleinern.

    Viele Grüße
    Roland

    Montag, 29. September 2014 10:14
  • Richtig, die EDB wird nur bei einem Offline Defrag verkleinert. Wenn du Mails rauslöscht bekommst du halt "Whistespace" der dann wieder gefüllt wird und somit wächst die DB dann nicht so schnell.
    • Als Antwort markiert Roland_Schmid Montag, 29. September 2014 11:52
    Montag, 29. September 2014 10:27
  • Moin,

    mal davon abgesehen, dass das kurzfristig nichts bringt (siehe Antwort von Christian und außerdem spielt hier noch die Aufbewahrungszeit gelöschter Elemente mit rein), würde ich an Deiner Stelle lieber die Datenbank von C: wegschieben.

    Zwei neue Platten mit Raid 1 und dahin die Datenbanken, bringt deutlich mehr, als 

    PST-Dateien sind nur eine Krücke und machen mehr Probleme, als sie lösen.


    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Montag, 29. September 2014 10:57
  • Hi Roland,

    die folgenden Punkte kannst du mal durchgehen:
    http://www.msxfaq.de/notfall/diskfull.htm


    Viele Grüße
    Christian

    Hi Christian,

    danke für den Tipp. Es sieht so aus, dass das Backup (veeam) die alten log files nicht löscht. Im Ordner eines Postfachspeichers liegen "Millionen" log files (E00000DE711 1.024 KB etc.)

    Viele Grüße
    Roland

    Montag, 29. September 2014 11:14
  • Sieh da, mein erste Spiegelstrich... ;)

    Mit Abstand die häufigste Ursache für vollgelaufene Platten. Das solltest auch zuerst beheben, bevor Du die Datenbank auf neue Platten umziehst.


    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Montag, 29. September 2014 11:17
  • Zwei neue Platten mit Raid 1 und dahin die Datenbanken, bringt deutlich mehr, als 

    PST-Dateien sind nur eine Krücke und machen mehr Probleme, als sie lösen.

    Hi,

    im vSphereHost ist noch ausreichend freier Platz im datastore vorhanden.
    Aber ich denke nach Löschen der ganzen logfiles des Mailboxstore sollte die Plattenplatz ausreichend sein. Zu klären bleibt, warum das backup die log files nicht löscht.

    Viele Grüße
    Roland Schmid

    Montag, 29. September 2014 12:15
  • Moin,

    bei Virtualisierung zählt zwar das Performance und Fragmentierungsargument nicht mehr, aber trotzdem sollten die Datenbank nicht auf C: liegen.

    Die Erklärung hast Du nun: Läuft Dir durch einen Fehler dadurch C voll, steht der ganze Server. Eventuell bekommst Du den nicht mal mehr gebootet.

    Lauft eine andere Partition voll, steht zwar Exchange, aber das BS läuft normal weiter.


    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Montag, 29. September 2014 12:21
  • Moin,

    bei Virtualisierung zählt zwar das Performance und Fragmentierungsargument nicht mehr, aber trotzdem sollten die Datenbank nicht auf C: liegen.

    Die Erklärung hast Du nun: Läuft Dir durch einen Fehler dadurch C voll, steht der ganze Server. Eventuell bekommst Du den nicht mal mehr gebootet.

    Lauft eine andere Partition voll, steht zwar Exchange, aber das BS läuft normal weiter.


    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Hi,

    ja das leuchtet ein.

    Viele Grüße
    Roland

    Montag, 29. September 2014 12:27
  • Das muss man explizit bei Veeam einstellen, in der normalen "VSS" Sicherung werden die nicht gelöscht.

    http://www.veeam.com/kb1878 ist dir bekannt? 

    • Als Antwort markiert Roland_Schmid Montag, 29. September 2014 12:47
    Montag, 29. September 2014 12:35
  • Das muss man explizit bei Veeam einstellen, in der normalen "VSS" Sicherung werden die nicht gelöscht.

    http://www.veeam.com/kb1878 ist dir bekannt? 

    nein wußte nicht, dass der Haken gesetzt werden muss
    das erklärt natürlich den Fehler! Danke schön für den Hinweis!

    Viele Grüße
    Roland

    Montag, 29. September 2014 12:46
  • Das muss man explizit bei Veeam einstellen, in der normalen "VSS" Sicherung werden die nicht gelöscht.

    http://www.veeam.com/kb1878 ist dir bekannt? 

    Hi,

    noch eine Frage hierzu. Die Application-Aware Haken ist jetzt gesetzt.
    Löscht mir der veeam task dann alle log files (auch die "Millionen" log files) ?
    Oder sollte ich die von Hand voher löschen ?

    Viele Grüße
    Roland

    Montag, 29. September 2014 13:54
  • Ob er das bei den "Millionen" schafft weiß ich nicht, aber normalerweise löscht er alle (tausende zumindest).

    Gruß

    Jörg

    Montag, 29. September 2014 14:54
  • Moin,

    Korinthenkackermodus: Veeam löscht gar keine Log-Dateien. Exchange löscht diese, nachdem ein Voll. oder danach ein Inkrementielles-Backup gelaufen ist. :P

    @Roland: Schau Dir die Eigenschaften der Datenbank an. Dort steht, wann das letzte Backup war. Wenn das durch ist und Exchange es anzeigt und dann immer noch Log-Dateien übrig sind, kannst Du die wahrscheinlich löschen.

    Aber vorher machen wir dann noch eine Kontrolle, melde Dich wieder, wenn die Log-Dateien nicht verschwinden.


    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Montag, 29. September 2014 15:15
  • Moin,

    Korinthenkackermodus: Veeam löscht gar keine Log-Dateien. Exchange löscht diese, nachdem ein Voll. oder danach ein Inkrementielles-Backup gelaufen ist. :P

    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Pffff.... :P
    Montag, 29. September 2014 15:35
  • @Roland: Schau Dir die Eigenschaften der Datenbank an. Dort steht, wann das letzte Backup war. Wenn das durch ist und Exchange es anzeigt und dann immer noch Log-Dateien übrig sind, kannst Du die wahrscheinlich löschen.

    Aber vorher machen wir dann noch eine Kontrolle, melde Dich wieder, wenn die Log-Dateien nicht verschwinden.


    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Hi,

    meine händisch gelöschten Logfiles bekomme ich nicht aus dem Papierkorb entfernt. Er meldet:

    c:\$Recycle.Bin\S-1-5-~2\$IPV4ULO.log - Der Prozess kann nicht auf die Datei zug
    reifen, da sie von einem anderen Prozess verwendet wird.

    Wer welcher Prozess verwendet die ?

    Viele Grüße
    Roland

    Dienstag, 30. September 2014 21:17
  • Moin,

    schrieb ich oben nicht, Du sollst Dich VOR DEM Löschen melden. ;)

    Wenn die Datei wirklich so heißt, dann ist die nicht von Exchange.


    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    • Als Antwort vorgeschlagen J. Schmitt Montag, 23. Oktober 2017 11:39
    Mittwoch, 1. Oktober 2014 06:50
  • Moin,

    schrieb ich oben nicht, Du sollst Dich VOR DEM Löschen melden. ;)

    Wenn die Datei wirklich so heißt, dann ist die nicht von Exchange.


    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Hi,

    ja, ich weiß Chef und Kollegen haben Druck gemacht, dass Mails wieder zugestellt werden sollen :-(
    (musst mit Gewalt unter die 97% Grenze des Speicherplatzes kommen)

    Sind die *.log files nicht vom Exchange, liegt unser Problem vielleicht ganz woanders!

    Viele Grüße
    Roland

    Mittwoch, 1. Oktober 2014 07:15
  • Wo die Log-Dateien der Datenbank liegen, kannst Du in den Eigenschaften der Datenbank sehen.

    Die sehen ungefähr so aus EYYXXXXXXXX.log

    YY ist ein zweistelliger Zähler, vermutlich 01. XXXXXXXX ist ein hezadezimaler Zähler.

    Beispiel:

    E0100001AD7.log


    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Mittwoch, 1. Oktober 2014 07:22
  • genau, so sehen die logs aus z.b. E000015FC2D.log und liegen unter C:\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database

    nur was liegt dann im Papierkorb des Windows Server 2008 auf dem Exchange 2010 installiert ist ?

    Viele Grüße
    Roland

    Mittwoch, 1. Oktober 2014 07:30
  • Ist denn das Backup durchgelaufen und wird als korrektes Backup auch in den Eigenschaften der Datenbank angezeigt?

    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Mittwoch, 1. Oktober 2014 07:34
  • Ist denn das Backup durchgelaufen und wird als korrektes Backup auch in den Eigenschaften der Datenbank angezeigt?

    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    ja, heute nacht letzte vollsicherung.

    Mittwoch, 1. Oktober 2014 07:37
  • OK.

    Dann hebe die Bereitstellung der Datenbank auf und geh in den Pfad "C:\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database"

    Dort führst Du "eseutil /mh NAME_DER_DATENBANK.edb" aus.

    Suche die Zeile "State" dort muss stehen. Clean Shutdown.

    Wenn nein -> abbrechen und melden

    Wenn ja:

    Nun kannst Du alle Logs löschen, auch die temporären und vor allem die Prüfpunktdatei: E00.chk.

    Im besten Fall ist am Ende in diesem Verzeichnis nur noch die EDB-Datei und ein Ordner "CatalogData-GUID". Diese beiden Dinge bleiben stehen.

    Falls Datenbank und Logs in unterschiedlichen Verzeichnissen liegen, ist das Log-Verzeichnis danach leer.

    Danach stellst Du die Datenbank wieder bereit.

    Wenn alle geklappt hat, sie die DB wieder Online und Exchange hat neue Log-Dateien angelegt, die nun wieder bei E0000000001.log beginnen.

    HINWEIS: Alle Aktionen auf eigene Gefahr! Sie funktionieren, ich habe sie bestimmt schon 100 Mal gemacht. Aber bei einer Fehlbedienung kann es Dir die Datenbank zerschießen!





    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Mittwoch, 1. Oktober 2014 07:44
  • danke für die Hilfe.

    wenn ich jetzt die Bereitstellung der Datenbank aufhebe killt mich unsere Geschäftsführung, wir stehen kurz vor Beginn der Frankfurter Buchmesse

    oder würde die mailzustellung weiter funktionieren, wenn die Bereitstellung der Datenbank aufgehoben ist ?

    Viele Grüße
    Roland

    Mittwoch, 1. Oktober 2014 08:10
  • Ich dachte, die Mailzustellung funktioniert nicht?

    Prinzipiell wäre SMTP weiterhinerreichbar und die Mails würde in der Exchange Warteschlange verbleiben, bis die Datenbank wieder online ist.

    Die Benutzer werden allerdings alle getrennt.

    BTW: Das bisherige Design erweckt nicht den Eindruck, als wäre E-Mail besonders wichtig bei Euch. Du kannst/solltest diesen Fall also zum Anlass nehmen, das Design mal zu überarbeiten und auch über Hochverfügbarkeit nachzudenken.


    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Mittwoch, 1. Oktober 2014 08:13
  • Ich dachte, die Mailzustellung funktioniert nicht?

    Hi,

    die Mailzustellung funktioniert wieder, weil ich mit Gewalt die Festplatte unter die 97% Grenze Speicherplatz freigemacht habe. Es ist aber nur eine Frage von Tagen bis die Festplatte wieder zu 97% voll ist und der Exchange-Transport keine Remote Mails mehr transportiert.

    bezüglich Design hier bei uns:
    doch die Mails sind sogar sehr wichtig! Unsere Geschäftsführung steckt allerdings immer nur minimal Gelder in das IT-System.
    klar werde ich den Fall zum Anlass nehmen, um das Design zu überarbeiten.

    Viele Grüße
    Roland

    Mittwoch, 1. Oktober 2014 08:33
  • Dort führst Du "eseutil /mh NAME_DER_DATENBANK.edb" aus.

    wie lange würde die Ausführung eseutil /mh NAME_DER_DATENBANK.edb ca. dauern ? NAME_DER_DATENBANK.edb hat in dem Fall eine Größe von 120GB.
    (mir ist klar, das keiner etwas aus der Ferne genau prognostizieren kann)

    Viele Grüße
    Roland

    Mittwoch, 1. Oktober 2014 09:31
  • wie lange würde die Ausführung eseutil /mh NAME_DER_DATENBANK.edb ca. dauern ? NAME_DER_DATENBANK.edb hat in dem Fall eine Größe von 120GB.

    (mir ist klar, das keiner etwas aus der Ferne genau prognostizieren kann)

    Viele Grüße
    Roland

    In diesem Fall schon. /mh zeigt nur eine Info aus dem Datenbankheader an, dass kommt sofort. /mh führt keine Aktionen gegen die Datei durch.

    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Mittwoch, 1. Oktober 2014 09:33
  • In diesem Fall schon. /mh zeigt nur eine Info aus dem Datenbankheader an, dass kommt sofort. /mh führt keine Aktionen gegen die Datei durch.
    danke!
    Mittwoch, 1. Oktober 2014 09:51
  • Hi Roland_Schmid,

    bevor ich Eseutil nutze, schalte ich lieber kurz die Umlaufprotokolierung an und lasse ihn die Logs löschen. Hinterher kannst du es wieder aktivieren.

    Hast du mal mit Treesize geschaut, was die HDD vollmüllt, denn die Vollsicherung hat ja nichts abgeschnitte, was bei einer korrekten Sicherung passieren sollte.


    Viele Grüße
    Christian

    Mittwoch, 1. Oktober 2014 13:07
    Moderator
  • Hi,

    ja, der Exchange Postfachspeicher und der Papierkorb nehmen den größten Speicher in Anspruch. Weiß nicht woher die 53242 Dateien im Papierkorb herkommen. Wie Exchange log files sehen sie nicht aus.

    Viele Grüße
    Roland

    d

    Mittwoch, 1. Oktober 2014 13:55
  • Dort führst Du "eseutil /mh NAME_DER_DATENBANK.edb" aus.

    Suche die Zeile "State" dort muss stehen. Clean Shutdown.

    Wenn nein -> abbrechen und melden

    Wenn ja:

    Nun kannst Du alle Logs löschen, auch die temporären und vor allem die Prüfpunktdatei: E00.chk.

    Im besten Fall ist am Ende in diesem Verzeichnis nur noch die EDB-Datei und ein Ordner "CatalogData-GUID". Diese beiden Dinge bleiben stehen.

    Falls Datenbank und Logs in unterschiedlichen Verzeichnissen liegen, ist das Log-Verzeichnis danach leer.

    Danach stellst Du die Datenbank wieder bereit.

    Wenn alle geklappt hat, sie die DB wieder Online und Exchange hat neue Log-Dateien angelegt, die nun wieder bei E0000000001.log beginnen.

    Hi,

    "State" war Clean Shutdown nach dem Aufheben der Bereitstellung.
    Hat perfekt geklappt gerade eben. Die überflüssigen Logfiles sind alle weg.
    Er zählt nun wieder bei E0000000001.log beginnend. Danke für die super Hilfe.
    (Umlaufprotokollierung ist aus)

    Viele Grüße
    Roland

    Mittwoch, 1. Oktober 2014 20:52