141986
08.02.2020, aktualisiert um 14:04:05 Uhr
3260
4
0
Exchange 2010 - Transportdienst stirbt nach 30 Minuten - riesige queuefile aber keine Mails in Warteschlange
Hallo Byteschubser,
habe hier einen virtualisierten SBS11 vor mir:
32GB; Exchange 2010 aktuellstes Patchlevel; Virtualisiert über ESX - Datenspeicher hängt auf einem RAID 1 (2x 600GB SAS)
dessen Exchange seit gestern - nachdem das Raid degraded wurde aufgrund ausgefallener Platte (Platte getauscht, rebuild erfolgreich) mächtige Probleme bereitet.
Nachdem ich TransportRoles\data\ geleert habe (Transportdienst beendet) startet der Dienst problemlos.
Nach kurzer Zeit füllt sich die mail.que aber enorm (bis zu 4,5GB) inkl. über 1000 Logfiles - anschließend gibts u.g. Fehler (keine Mails in der Warteschlange zu sehen - weder auf der Shell (get-queue) noch via Gui)
gefolgt von:
So sieht die aktuelle Auslastung aus (glücklichen Screenshotmoment erwischt - 2s. nach dem Screen hat sich der Dienst zum "neustarten in 5 Minuten vorbereitet" - ab hier klappt auch kein Mailverkehr mehr und der RAM wird schlagartig geleert (siehe angehängt Pics)
[queuesize.png]
Kurz danach sieht die Auslastung folgendermaßen aus:
[transportabsturz.png]
Nach diesen 5 Minuten startet der Transportdienst neu und es wird ein "queue.old" angelegt:
worin die ganze Geschichte erneut beginnt (queuefile füllt sich wieder bis ~4,5GB mit über 1000 Logfiles und verabschiedet sich dann wieder mit o.g. Event) -Da der Ordner beim nächsten "Fehlerevent" bereits besteht, stirbt der Transportdienst nun final und bleibt auch dabei.
Jetzt hilft nur noch händisches löschen/ordnerumbennen des /queue.old Ordners:
Meine Recherchen brachten folgende Unternehmungen mitsich.
Realisiert dass mail.cue viel zu groß ists - alleinerdings keine Mails in der Wartschlange zu finden sind.
Leider beginnt auch nach o.g. Lösungsansätzen der "loop" von vorn.
So sieht die aktuelle Konfig vom Exchange aus:
Habe mehrere Foren durchforstet aber scheinbar bin ich noch nicht über die Lösung gestolpert die ich brauche.
Darum nun auch mein "letzter" Ausweg in Richtung Euch, in der Hoffnung dass mich jemand auf den richtigen Pfad bringt denn bis Dato lief die Möhre (wenn auch EoL) wirklich gut und stabil.
Habe ich etwas essentielles übersehen? Gibt es alternativen die ich nicht bedacht habe zu probieren?
Gelesen habe ich viel darüber dass evtl. wer einen zu großen Anhang intern verschicken wollte (die Limits [MaxReceiveSize, MaxRecipientEnvelopeLimit, MaxSendSize] wurden erst von mir gesetzt als das Kind bereit im Brunnen lag - war zuvor wohl auf unlimited gesetzt, warum auch immer...): nur wie kann ich das am sinnvollsten prüfen? Mir wäre spontan nicht danach 200 Postfächer zu prüfen, ob da was dickes im Postausgang/Gesendet liegt.
Sorry für die Wall of Text. Ich habe bestimmt was vergessen, bitte kurzes Feedback damit ichs nachreichen kann.
Danke schon mal, dass Du dir den Text überhaupt bis hier her durchgelesen hast.
viele Grüße
Edita:
Momentan behelfe ich mir damit, dass ich den queue.old Ordner alle 15 Minuten löschen lasse. Was mir allerdings überhaupt nicht gefällt, da selbst der interne Mailversand massive Verzögerungen hat. Selbst wenn ich an mich selbst schreibe, kann es mal 5 Minuten dauern. Nach/von extern ähnlich.
Edita²: Soeben fiel mir zusätzlich noch auf, dass sich die Filegrößen der mail.cue unterscheiden bei jedem Neuvorgang. Während ich diesen Post hier schrieb, verabschiedete sich der Transportdienst mit ca. 4,5GB filesize.
Jetzt sind es schon 4,9GB bis der Dienst abschmiert.Jedoch besteht auch schon wieder ein queue.old Ordner der sich gerade wie schön füllt.
habe hier einen virtualisierten SBS11 vor mir:
32GB; Exchange 2010 aktuellstes Patchlevel; Virtualisiert über ESX - Datenspeicher hängt auf einem RAID 1 (2x 600GB SAS)
dessen Exchange seit gestern - nachdem das Raid degraded wurde aufgrund ausgefallener Platte (Platte getauscht, rebuild erfolgreich) mächtige Probleme bereitet.
Nachdem ich TransportRoles\data\ geleert habe (Transportdienst beendet) startet der Dienst problemlos.
Nach kurzer Zeit füllt sich die mail.que aber enorm (bis zu 4,5GB) inkl. über 1000 Logfiles - anschließend gibts u.g. Fehler (keine Mails in der Warteschlange zu sehen - weder auf der Shell (get-queue) noch via Gui)
Transportvorgang für Maildatenbank: Schwerwiegender fehler eines Datenbankvorgangs. Der Microsoft Exchange-Transportdienst wird beendet. Ausnahmedetails: Microsoft.Exchange.Isam.IsamCheckpointDepthTooDeepException: too many outstanding generations between checkpoint and current generation (-614)
bei Microsoft.Exchange.Isam.JetInterop.HandleError(Int32 errFn)
bei Microsoft.Exchange.Isam.JetInterop.MJetSetColumn(MJET_TABLEID tableid, MJET_COLUMNID columnid, Byte data, MJET_GRBIT grbit, MJET_SETINFO setinfo)
bei Microsoft.Exchange.Isam.Interop.MJetSetColumn(MJET_TABLEID tableid, MJET_COLUMNID columnid, Byte data, MJET_GRBIT grbit, MJET_SETINFO setinfo)
bei Microsoft.Exchange.Transport.Storage.DataStreamImmediateWriter.Write(Int64 position, Byte data)gefolgt von:
Vorübergehende Probleme bei Arbeitsprozess, weshalb der Neustart des Prozesses in 5 Minuten angefordert wurde.So sieht die aktuelle Auslastung aus (glücklichen Screenshotmoment erwischt - 2s. nach dem Screen hat sich der Dienst zum "neustarten in 5 Minuten vorbereitet" - ab hier klappt auch kein Mailverkehr mehr und der RAM wird schlagartig geleert (siehe angehängt Pics)
[queuesize.png]
Kurz danach sieht die Auslastung folgendermaßen aus:
[transportabsturz.png]
Nach diesen 5 Minuten startet der Transportdienst neu und es wird ein "queue.old" angelegt:
Transportvorgang für Maildatenbank: MSExchangeTransport hat einen kritischen Speicherfehler erkannt und eine automatisierte Wiederherstellungsaktion ausgeführt. Diese Wiederherstellungsaktion wird erst wiederholt, nachdem die Zielordner umbenannt oder gelöscht wurden. Verzeichnispfad:C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\data\Queue wird verschoben in Verzeichnispfad:C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\data\Queue\Queue.old.worin die ganze Geschichte erneut beginnt (queuefile füllt sich wieder bis ~4,5GB mit über 1000 Logfiles und verabschiedet sich dann wieder mit o.g. Event) -Da der Ordner beim nächsten "Fehlerevent" bereits besteht, stirbt der Transportdienst nun final und bleibt auch dabei.
Jetzt hilft nur noch händisches löschen/ordnerumbennen des /queue.old Ordners:
Meine Recherchen brachten folgende Unternehmungen mitsich.
Realisiert dass mail.cue viel zu groß ists - alleinerdings keine Mails in der Wartschlange zu finden sind.
- DB repariert via eseutl
- DB Prüfsummencheck via eseutil
- DB defragmentiert via eseutl
- Postfächer der DB geprüft via MSEX Mgnt Shell
- kein AV
Leider beginnt auch nach o.g. Lösungsansätzen der "loop" von vorn.
So sieht die aktuelle Konfig vom Exchange aus:
[PS] C:\Windows\system32>get-transportconfig
ClearCategories : True
ConvertDisclaimerWrapperToEml : False
DSNConversionMode : UseExchangeDSNs
ExternalDelayDsnEnabled : True
ExternalDsnDefaultLanguage :
ExternalDsnLanguageDetectionEnabled : True
ExternalDsnMaxMessageAttachSize : 10 MB (10,485,760 bytes)
ExternalDsnReportingAuthority :
ExternalDsnSendHtml : True
ExternalPostmasterAddress : postmaster@*snipped*
GenerateCopyOfDSNFor : {}
HygieneSuite : Standard
InternalDelayDsnEnabled : True
InternalDsnDefaultLanguage :
InternalDsnLanguageDetectionEnabled : True
InternalDsnMaxMessageAttachSize : 10 MB (10,485,760 bytes)
InternalDsnReportingAuthority :
InternalDsnSendHtml : True
InternalSMTPServers : {127.0.0.1}
JournalingReportNdrTo : <>
LegacyJournalingMigrationEnabled : False
MaxDumpsterSizePerDatabase : 25 MB (26,214,400 bytes)
MaxDumpsterTime : 3.00:00:00
MaxReceiveSize : 50 MB (52,428,800 bytes)
MaxRecipientEnvelopeLimit : 5000
MaxSendSize : 50 MB (52,428,800 bytes)
MigrationEnabled : False
OpenDomainRoutingEnabled : False
Rfc2231EncodingEnabled : False
ShadowHeartbeatRetryCount : 12
ShadowHeartbeatTimeoutInterval : 00:15:00
ShadowMessageAutoDiscardInterval : 2.00:00:00
ShadowRedundancyEnabled : True
SupervisionTags : {Reject, Allow}
TLSReceiveDomainSecureList : {}
TLSSendDomainSecureList : {}
VerifySecureSubmitEnabled : False
VoicemailJournalingEnabled : True
HeaderPromotionModeSetting : NoCreate
Xexch50Enabled : TrueHabe mehrere Foren durchforstet aber scheinbar bin ich noch nicht über die Lösung gestolpert die ich brauche.
Darum nun auch mein "letzter" Ausweg in Richtung Euch, in der Hoffnung dass mich jemand auf den richtigen Pfad bringt denn bis Dato lief die Möhre (wenn auch EoL) wirklich gut und stabil.
Habe ich etwas essentielles übersehen? Gibt es alternativen die ich nicht bedacht habe zu probieren?
Gelesen habe ich viel darüber dass evtl. wer einen zu großen Anhang intern verschicken wollte (die Limits [MaxReceiveSize, MaxRecipientEnvelopeLimit, MaxSendSize] wurden erst von mir gesetzt als das Kind bereit im Brunnen lag - war zuvor wohl auf unlimited gesetzt, warum auch immer...): nur wie kann ich das am sinnvollsten prüfen? Mir wäre spontan nicht danach 200 Postfächer zu prüfen, ob da was dickes im Postausgang/Gesendet liegt.
Sorry für die Wall of Text. Ich habe bestimmt was vergessen, bitte kurzes Feedback damit ichs nachreichen kann.
Danke schon mal, dass Du dir den Text überhaupt bis hier her durchgelesen hast.
viele Grüße
Edita:
Momentan behelfe ich mir damit, dass ich den queue.old Ordner alle 15 Minuten löschen lasse. Was mir allerdings überhaupt nicht gefällt, da selbst der interne Mailversand massive Verzögerungen hat. Selbst wenn ich an mich selbst schreibe, kann es mal 5 Minuten dauern. Nach/von extern ähnlich.
Edita²: Soeben fiel mir zusätzlich noch auf, dass sich die Filegrößen der mail.cue unterscheiden bei jedem Neuvorgang. Während ich diesen Post hier schrieb, verabschiedete sich der Transportdienst mit ca. 4,5GB filesize.
Jetzt sind es schon 4,9GB bis der Dienst abschmiert.Jedoch besteht auch schon wieder ein queue.old Ordner der sich gerade wie schön füllt.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 545081
Url: https://administrator.de/forum/exchange-2010-transportdienst-stirbt-nach-30-minuten-riesige-queuefile-aber-keine-mails-in-warteschlange-545081.html
Ausgedruckt am: 22.04.2025 um 00:04 Uhr
4 Kommentare
Neuester Kommentar
Hallo,
hatte ich vor einigen Jahren mal, müsste da stark überlegen, wie das gefixed wurde.
Alternativangebot: Wie wäre es das Backup von davor zurückzuspielen (wenn du sicher bist, dass davor alles i.O war).
(Allerdings ist damit dann fraglich, warum ein halblebiges RAID1 überhaupt Einfluss auf den SBS2011 hat - scheint noch was anderes im argen zu sein?)
Ergänzend: Der SBS muss weg, vielleicht der optimale Moment hierfür?
Viele Grüße,
Christian
certifiedit.net
Edit: Ram am A...?
hatte ich vor einigen Jahren mal, müsste da stark überlegen, wie das gefixed wurde.
Alternativangebot: Wie wäre es das Backup von davor zurückzuspielen (wenn du sicher bist, dass davor alles i.O war).
(Allerdings ist damit dann fraglich, warum ein halblebiges RAID1 überhaupt Einfluss auf den SBS2011 hat - scheint noch was anderes im argen zu sein?)
Ergänzend: Der SBS muss weg, vielleicht der optimale Moment hierfür?
Viele Grüße,
Christian
certifiedit.net
Edit: Ram am A...?
1
Hi Christian,
danke für dein Feedback.
Backup reroll wurde schon durchgeführt - brachte keine Besserung.
Mit anderen Worten: ich wäre hier eher an einer Lösung interessiert.
Besten Dank soweit und viele Grüße
Edita: warum die mail.que so massiv anwächst während ich wirklich keine Mails in der Queue sehe (und das sogar mit 2x2 Augen 8-) ) ist auch Dir ein Rätsel oder?
Edita²: Woher komm die riesen Anzahl an Logfiles? Warum steigt die mail.que so arg an? Kann man das nicht auf eine Art troubleshooten im Sinne von Logs (sind alle kryptisch) auslesen mit irgendeinem Tool oder ähnliches?
danke für dein Feedback.
Backup reroll wurde schon durchgeführt - brachte keine Besserung.
Allerdings ist damit dann fraglich, warum ein halblebiges RAID1
Bin ich ganz bei Dir - Wobei auch die restliche Konfig sehr fragwürdig aufgesetzt ist, aber das gehört aktuell nicht hier her.Der SBS muss weg, vielleicht der optimale Moment hierfür?
Bin ich ebenfalls bei Dir. Der neue Server ist bereits in der Bestellung und die Migration geplant. Allerdings möchte ich, selbst wenn es nur noch 2 Wochen wären, das so nicht stehen lassen mit dem Murksworkaround.Mit anderen Worten: ich wäre hier eher an einer Lösung interessiert.
Edit: Ram am A...?
Guter Ansatz - werde ich gegenprüfen!Besten Dank soweit und viele Grüße
Edita: warum die mail.que so massiv anwächst während ich wirklich keine Mails in der Queue sehe (und das sogar mit 2x2 Augen 8-) ) ist auch Dir ein Rätsel oder?
Edita²: Woher komm die riesen Anzahl an Logfiles? Warum steigt die mail.que so arg an? Kann man das nicht auf eine Art troubleshooten im Sinne von Logs (sind alle kryptisch) auslesen mit irgendeinem Tool oder ähnliches?
Hi,
lies Dir mal folgenden TechNet-Thread durch: https://social.technet.microsoft.com/Forums/exchange/en-US/5eb7e0a7-f691 ...
Insbesondere im unteren Teil wird die Reparatur der mail.queue beschrieben (von User Alan.Gim), vorher mal den exBPA gegen den Server laufen lassen. Bei Dir liegt wohl auch ein unclean shutdown der edb Datenbank(en) vor. Er scheint bei Dir allerdings eine automatische Reparatur zu versuchen. Vielleicht hilft aber die manuelle Reparatur mit ausgeschaltetem/deaktiviertem Transportdienst.
Gruß
cykes
P.S. Vielleicht hilft auch das: http://msexchangeguru.com/2011/06/02/mail-que/
lies Dir mal folgenden TechNet-Thread durch: https://social.technet.microsoft.com/Forums/exchange/en-US/5eb7e0a7-f691 ...
Insbesondere im unteren Teil wird die Reparatur der mail.queue beschrieben (von User Alan.Gim), vorher mal den exBPA gegen den Server laufen lassen. Bei Dir liegt wohl auch ein unclean shutdown der edb Datenbank(en) vor. Er scheint bei Dir allerdings eine automatische Reparatur zu versuchen. Vielleicht hilft aber die manuelle Reparatur mit ausgeschaltetem/deaktiviertem Transportdienst.
Gruß
cykes
P.S. Vielleicht hilft auch das: http://msexchangeguru.com/2011/06/02/mail-que/
1
Hallo,
@cykes:
erstmal vielen Dank für dein Feedback.
In der Tat hatte ich es nicht auf dem Schirm, dass die mail.cue auch eine Datenbank darstellt, die man mit eseutil bearbeiten kann.
Folgender Gedankengang stellte sich mir allerdings:
Selbst wenn ich die mail.cue bzw. den ganzen Queue Ordner gelöscht hatte, wurde diese ja ohnehin neu angelegt - wieso sollte die irgendwann defekt werden beim allerersten Aufbau, sprich: es muss ja irgendwo eine Quelle sein, die den "neuaufbau" der QueueDB stört.
Kurzum:
die Reparatur hat nichts gebracht. Die Reparatur verlief zwar erfolgreich aber das Spiel ging dann einfach weiter: - die mail.cue wuchs noch einige MB an und starb wieder im dirty shutdown state.
Nach einigem weiterem rumgemurkse ging dann auch die edgetransport.exe nicht mehr, also im Grunde ist mir das ganze Kalkül unter den Händen zusammen gefallen.
Heute Morgen entschloss ich dann:
Seither sieht der Queueordner wieder gut aus (löscht wieder Logs und ist nicht mehr ganz so groß; erstellt keine queue.old) und die Mails kommen sowohl intern wie extern wieder Blitzschnell an.
Ich bedanke mich für euer mitdenken und hineinversetzen, eure Dienstleistungsangebote und vor allem für das Dazugelernte!
viele Grüße
@cykes:
erstmal vielen Dank für dein Feedback.
In der Tat hatte ich es nicht auf dem Schirm, dass die mail.cue auch eine Datenbank darstellt, die man mit eseutil bearbeiten kann.
Folgender Gedankengang stellte sich mir allerdings:
Selbst wenn ich die mail.cue bzw. den ganzen Queue Ordner gelöscht hatte, wurde diese ja ohnehin neu angelegt - wieso sollte die irgendwann defekt werden beim allerersten Aufbau, sprich: es muss ja irgendwo eine Quelle sein, die den "neuaufbau" der QueueDB stört.
Kurzum:
die Reparatur hat nichts gebracht. Die Reparatur verlief zwar erfolgreich aber das Spiel ging dann einfach weiter: - die mail.cue wuchs noch einige MB an und starb wieder im dirty shutdown state.
Nach einigem weiterem rumgemurkse ging dann auch die edgetransport.exe nicht mehr, also im Grunde ist mir das ganze Kalkül unter den Händen zusammen gefallen.
Heute Morgen entschloss ich dann:
- die Hubtransportrolle zu entfernen
- die default config des edgetransportes (edgetransport.exe.config.template) wieder drüber zu pappen
- die connectoren neu aufzusetzen
- und zu guter letzt noch die queuefiles auf eine andere Partition zu schubsen.
Seither sieht der Queueordner wieder gut aus (löscht wieder Logs und ist nicht mehr ganz so groß; erstellt keine queue.old) und die Mails kommen sowohl intern wie extern wieder Blitzschnell an.
Ich bedanke mich für euer mitdenken und hineinversetzen, eure Dienstleistungsangebote und vor allem für das Dazugelernte!
viele Grüße
