Benutzer mit den meisten Antworten
Der Microsoft Exchange-Transportdienst weist Nachrichtenübermittlungen zurück, weil der verfügbare Speicherplatz den konfigurierten Schwellenwert unterschritten hat.

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
RolandDer 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]
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
-
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
-
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
-
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
-
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
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
-
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
-
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
-
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 -
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
-
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
-
Hi Roland,
die folgenden Punkte kannst du mal durchgehen:
http://www.msxfaq.de/notfall/diskfull.htm
Viele Grüße
ChristianHi 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 -
-
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 -
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
-
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 -
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
-
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 -
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 -
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
-
@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 -
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
-
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 -
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
-
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 -
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
-
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 -
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
-
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 -
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
-
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
Gruesse aus Berlin schickt Robert - MVP Exchange Server
-
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 -
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