15
Exchange 2013 Transportdienst beendet sich
Hallo Zusammen
wir haben aktuell, seit heute morgen, das Problem, dass sich der Transportdienst in einem Rhythmus von 10-20 Minuten immer automatisch beendet.
Im Eventlog tauchen die EventID 15004 (zu hohe Last) und daraus resultierend EventID 17017 (Kontingent überschritten) auf, ok sagt eigentlich alles aus aber:
Ich persönlich habe die Vermutung, dass ein Client hier irgend etwas looped oder versucht was sehr großes zu senden - da man sich aber den Inhalt der Transport-Logs nicht ansehen kann habe ich aktuell keine Idee mehr wie ich ermitteln kann welcher Client mir das den Transportdienst lahmlegt
Randdetails:
Vielleicht kennt ja jemand das Problem oder kann mir ein Tool nennen mit denen man die TransportLogs vom Exchange durchsehen kann (via Notepad++ bekommt man nur wirre Zeichen wie bei einem Binärfile).
Grüße
@clSchak
wir haben aktuell, seit heute morgen, das Problem, dass sich der Transportdienst in einem Rhythmus von 10-20 Minuten immer automatisch beendet.
Im Eventlog tauchen die EventID 15004 (zu hohe Last) und daraus resultierend EventID 17017 (Kontingent überschritten) auf, ok sagt eigentlich alles aus aber:
- Mail Que ist leer (via Konsole & via Powershell geprüft)
- Ordner wurde bereits gelöscht und der Transportdienst (ebenso der gesamte Server) neugestartet
- Die Datei wächst schnell an (ca. 3GB/h bei eine Mailverkehr von ca. 1GB/h)
- Die Werte die bei der EventID 15004 angemerkt werden (Version-Buckets) haben wir mal Testweise um den Faktor 50 nach oben gesetzt - kein Erfolg, in der EventID Meldung sind die gesetzten Werte auch ersichtlich der Schwellenwert wird trotz alledem überschritten, selbst die Zeit bis das Event eintritt ist nicht wesentlich höher
- TransportLog Viewer wie bei einem Exchange 2007 & 2010 verfügbar gibt es scheinbar für Exchange 2013 nicht
Ich persönlich habe die Vermutung, dass ein Client hier irgend etwas looped oder versucht was sehr großes zu senden - da man sich aber den Inhalt der Transport-Logs nicht ansehen kann habe ich aktuell keine Idee mehr wie ich ermitteln kann welcher Client mir das den Transportdienst lahmlegt
Randdetails:
- Server 2012R2 2 x 6C Xeon 2.6Ghz mit 64GB RAM
- Exchange DB: 4,5 TB
- User/Mailboxen: 600
- Exchange: 2013 CU7 (ja ist nicht aktuell ich weis)
- Angebunden via 2 x 10Gb iSCSI an eine EQL PS6100XS (keine hohe IO Last [ca. 1.200 IOPs ab 9.000 fängt es an langsam zu werden], Netzwerklinks liegen bei 0,5-2% Last lt. Windows Anzeige
- VMWare Host hat nur diese eine VM am laufen und ist mit 128GB RAM ausgestattet
- bis gestern lief alles anstandslos, es wurden keinerlei Update oder ähnliches eingespielt
- Angriff von "außen" kann ausgeschlossen werden, ich habe die Verbindung nach draußen für knapp 2h deaktivert um ein solches Problem auszuschließen
- Die Ergebnisse die mir Google lieferte (Frankys Web, msexchangeguru..com usw.) habe ich bereits durchgearbeitet
Vielleicht kennt ja jemand das Problem oder kann mir ein Tool nennen mit denen man die TransportLogs vom Exchange durchsehen kann (via Notepad++ bekommt man nur wirre Zeichen wie bei einem Binärfile).
Grüße
@clSchak
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 315734
Url: https://administrator.de/contentid/315734
Ausgedruckt am: 23.11.2024 um 11:11 Uhr
15 Kommentare
Neuester Kommentar
Hallo,
bei Franky gibt es doch ein Tool für die Nachrichtenverfolgung.
Und ein Powershellbefehl zum anzeigen der Logs ist bei Franky auch dabei.
Wenn Du ein Client für das Problem vermutest, dann trenne den Server mal von den Clients ab z.B. Firewall nur noch Verbindungen von Dir und den DCs erlaubt.
Gibt es alle Verteiler an die jemand X MB große Dateien versendet?
Datenbanklimit?
Öffentliche Ordner Limit?
Welche Datei wächst schnell an?
Wie isnd die Limits für Mailanhänge für intern und extern gesetzt?
Schon mit Wireshark geschaut was für Verbindungen auf den Server einprasseln?
Gruß
Chonta
bei Franky gibt es doch ein Tool für die Nachrichtenverfolgung.
Und ein Powershellbefehl zum anzeigen der Logs ist bei Franky auch dabei.
Wenn Du ein Client für das Problem vermutest, dann trenne den Server mal von den Clients ab z.B. Firewall nur noch Verbindungen von Dir und den DCs erlaubt.
Gibt es alle Verteiler an die jemand X MB große Dateien versendet?
Datenbanklimit?
Öffentliche Ordner Limit?
Welche Datei wächst schnell an?
Wie isnd die Limits für Mailanhänge für intern und extern gesetzt?
Schon mit Wireshark geschaut was für Verbindungen auf den Server einprasseln?
Gruß
Chonta
Hi @Chonta
danke für deine Antwort, wir haben aktuell ein Limit von 50MB auf den Mails, das mit den Blocken der Clients teste ich gleich.
Was mich nur wundert ist, dass die Que komplett leer ist und trotzdem die Transport-Queu vollläuft und die Logfiles im 10sec von 5mb erstellt werden. Auf Frankys Web habe ich lediglich Tools zum Messagetracking gefunden aber nicht womit man sich die Logs vom Transport-Dienst anschauen kann.
danke für deine Antwort, wir haben aktuell ein Limit von 50MB auf den Mails, das mit den Blocken der Clients teste ich gleich.
Was mich nur wundert ist, dass die Que komplett leer ist und trotzdem die Transport-Queu vollläuft und die Logfiles im 10sec von 5mb erstellt werden. Auf Frankys Web habe ich lediglich Tools zum Messagetracking gefunden aber nicht womit man sich die Logs vom Transport-Dienst anschauen kann.
Update
ich habe jetzt alle Verbindung an der Windows FW, bis auf die RDP, geblockt, den Server neugestartet und das Problem bleibt bestehen ... :| via netstat -a sind keine externen Verbindungen vorhanden, demnach "looped" der scheinbar irgend etwas, die Mail-Que habe ich wieder gelöscht und PS gibt auch nur eine leere an, trotzdem wächst das Log pro Minute um 70MB :|
Ich kann mir da keinen Reim mehr drauf machen und wüsste auch nicht wo er noch Daten für die Verarbeitung herbekommen könnte :/
ich habe jetzt alle Verbindung an der Windows FW, bis auf die RDP, geblockt, den Server neugestartet und das Problem bleibt bestehen ... :| via netstat -a sind keine externen Verbindungen vorhanden, demnach "looped" der scheinbar irgend etwas, die Mail-Que habe ich wieder gelöscht und PS gibt auch nur eine leere an, trotzdem wächst das Log pro Minute um 70MB :|
Ich kann mir da keinen Reim mehr drauf machen und wüsste auch nicht wo er noch Daten für die Verarbeitung herbekommen könnte :/
$start = "19.11.2014 20:40" | get-date
$end = "19.11.2014 20:45" | get-date
Get-MessageTrackingLog -Start $start -End $end -ResultSize unlimited | where {$_.sender -notmatch "health"} | select timestamp,sender,recipients,totalbytes,eventid Und hier der Link für die Nachrichtenverfolgung.
http://www.frankysweb.de/exchange-2013-gui-fr-die-nachrichtenverfolgung ...
Wenn da eine Mail schon im system drin ist und da rumspringt, hilft auch das blocken der Clients nix, denn die Mail ist ja schon im System.
Was Du brauchst ist rauszubekommen wer hat alles Mails mit Anhang an z.B. an alle@firma.de geschickt (intern oder extern)
z.B. jemand der seine bany oder Urlaubsfotos mit allen teilen musste.
Gruß
Chonta
Das habe ich auch schon ausprobiert, ebenso "get-queue | suspend-queu" um alle Wartenschlangen anzuhalten und zu schauen ob dort etwas auffälliges reinkommt, das Verhältnis um was die Logs rasant ansteigen entspricht nicht dem Datenvolumen des Mailverkehrs.
Und schon Mails mit Anhang ausfindig gemacht, die kurz vor auftretendes Problems in Umlauf gegangen sind?
Wenn die Logs wachsen, dann steht in den Logs auch weas drin, was steht in den Logs denn drinnen?
Wenn eine Mail mit 50 MB an alle internen Empfänger geshcickt wurdem dann war das einmalig eine eingehende Mail von 50MB auf Netzwerkebene, der Zauber passiert danach und taucht auch in den Warteschlangen nicht auf.
Das Limit kannst Du ja mal auf 10MB runter stellen, für Intern und extern. evtl wird die Mail dann nicht weiterverarbeitet, weil die Empfänger sagen ist nicht.
Es kann auch ein Virus sein, hab ihr einen Exchangetauglichen Scanner?
Evtl. ein Systemhaus ins Bot holen, der Server scheint ja nun schon mehrere Tage off zu sein.
Wenn nix anderes Hilf ein Backup vor dem Problem einspielen und mit dem Datenverlust leben.
Gruß
Chonta
Wenn die Logs wachsen, dann steht in den Logs auch weas drin, was steht in den Logs denn drinnen?
Wenn eine Mail mit 50 MB an alle internen Empfänger geshcickt wurdem dann war das einmalig eine eingehende Mail von 50MB auf Netzwerkebene, der Zauber passiert danach und taucht auch in den Warteschlangen nicht auf.
Das Limit kannst Du ja mal auf 10MB runter stellen, für Intern und extern. evtl wird die Mail dann nicht weiterverarbeitet, weil die Empfänger sagen ist nicht.
Es kann auch ein Virus sein, hab ihr einen Exchangetauglichen Scanner?
Evtl. ein Systemhaus ins Bot holen, der Server scheint ja nun schon mehrere Tage off zu sein.
Wenn nix anderes Hilf ein Backup vor dem Problem einspielen und mit dem Datenverlust leben.
Gruß
Chonta
Offline ist der Server ja eben nicht, der Transport Dienst wird vom Exchange Server automatisch neugestartet weil die Ressourcenauslastung zu hoch ist. Die Mails werden alle zugestellt sobald der Transportdienst einmal neugestartet wurde (also so ca. alle 20 Minuten), danach ist Queu leer, auch via PS wird nicht angezeigt, wenn man diese pausiert trudeln zwar einige Mails ein (50-100 St) aber keine die besonders groß ist oder andere Auffälligkeiten die man sehen könnte.
In den Logs, wenn man sich diese mit deinem o.g. PS Befehl anschaut steht nicht besonderes. Ein Systemhaus ist bereits eingeschaltet, wir geben das morgen früh weiter an MS.
In den Logs, wenn man sich diese mit deinem o.g. PS Befehl anschaut steht nicht besonderes. Ein Systemhaus ist bereits eingeschaltet, wir geben das morgen früh weiter an MS.
Evtl einen Versuch "wert"
http://support.risualblogs.com/blog/2009/10/16/hub-transport-service-ke ...
Auf jedenfall deine Limits für das versenden von Mails anschauen und anpassen, intern wie extern, senden und empfangen.
Das Limit der Datenbanken ist auch wirklich nicht erreicht?
Benutzt Du von Franky den exchangereporter?
http://www.networksteve.com/exchange/topic.php/Exchange_2013_back_press ...
"get-messagetrackinglog
and filtering for objects over 30MB between the hours 00:27:00 and 00:30:00"
Gruß
Chonta
http://support.risualblogs.com/blog/2009/10/16/hub-transport-service-ke ...
Auf jedenfall deine Limits für das versenden von Mails anschauen und anpassen, intern wie extern, senden und empfangen.
Das Limit der Datenbanken ist auch wirklich nicht erreicht?
Benutzt Du von Franky den exchangereporter?
http://www.networksteve.com/exchange/topic.php/Exchange_2013_back_press ...
"get-messagetrackinglog
and filtering for objects over 30MB between the hours 00:27:00 and 00:30:00"
Gruß
Chonta
ja, die Sachen habe ich bereits alle geprüft, wie es scheint "hängt" irgendwo eine Mail im Backend fest die der Transportdienst nicht annehmen kann, haben jetzt einen Call bei MS aufgemacht.
Aber über den Befehl sollst man doch genau so eine Mail ausfindig machen und wenn man die ausfindiggemacht hat, kann man diese Maisl auch aus dem System wieder entfernen.
Gruß
Chonta
Gruß
Chonta
das ist ja eines der Probleme, in den Warteschlange ist rein gar nichts auffälliges, dort ist weder eine hohe Anzahl noch Mails mit einem großen Anhang zu sehen.
Die Logs weisen keinerlei Besonderheiten auf :|
Die Logs weisen keinerlei Besonderheiten auf :|
Was mir noch einfallen würde - eventuell hängt einer der Transport-Agents (Virenscanner/Spamfilter) und verursacht die Probleme...
Das Problem wurde durch MS soweit behoben, Virenscanner usw. war da nicht schuld. Der "Schuldige" war ein Benutzer der es irgendwie geschafft hat eine 4GB E-Mail in sein Postausgang rein zubekommen - trotz der Limitierung auf 25MB je Mail. Da die Mail in der Warteschlange zum/vor Transportdienst damit liegt (denn genau das macht wohl der Ordner "Outbox" das ist die "Warteschlange" für interne Mails an den Transportdienst), hat man in den Logs nichts finden können.
Wenn die Mail im Postausgang liegt ist Sie auch in der Mail DB und wird dann zum Transportdienst bewegt, dieser quittiert dann das er die Mail nicht annehmen kann, das passiert im Regelfall bevor die Mail bereits im Postausgang gelangt, was aber bei dem betreffenden Client wohl nicht der Fall war.
Da die Mail dann im Postausgang festhängt, wurde diese immer wieder an den Transportdienst weitergegeben. Wenn jemand mal ein ähnliches Problem haben sollte, mit folgenden Powershell Befehl lässt sich die Outbox-Größe alle Accounts feststellen:
Unser aktueller Verdacht ist, dass das Outlook im Offlinemodus war wo die Mail erstellt wurde und der das dann "mal eben" im online Modus zum Server synchronisiert hat.
Die Mail habe ich dann via Outlook (Postfachfreigabe angepasst und den Account in meinen Outlook eingebunden) gefunden und gelöscht, OWA reicht in diesem Fall nicht aus, da hier der Ordner "Postausgang" nicht angezeigt wird.
Gruß
@clSchak
Wenn die Mail im Postausgang liegt ist Sie auch in der Mail DB und wird dann zum Transportdienst bewegt, dieser quittiert dann das er die Mail nicht annehmen kann, das passiert im Regelfall bevor die Mail bereits im Postausgang gelangt, was aber bei dem betreffenden Client wohl nicht der Fall war.
Da die Mail dann im Postausgang festhängt, wurde diese immer wieder an den Transportdienst weitergegeben. Wenn jemand mal ein ähnliches Problem haben sollte, mit folgenden Powershell Befehl lässt sich die Outbox-Größe alle Accounts feststellen:
Get-mailbox -Resultsize Unlimited | get-mailboxfolderstatistics -folderscope outbox | format-table -autosize FolderSize,Identity > C:\output.csvUnser aktueller Verdacht ist, dass das Outlook im Offlinemodus war wo die Mail erstellt wurde und der das dann "mal eben" im online Modus zum Server synchronisiert hat.
Die Mail habe ich dann via Outlook (Postfachfreigabe angepasst und den Account in meinen Outlook eingebunden) gefunden und gelöscht, OWA reicht in diesem Fall nicht aus, da hier der Ordner "Postausgang" nicht angezeigt wird.
Gruß
@clSchak
Vielen Dank für die Info 
So blöd kann man garnicht denken was einige versuchen.
Aber dann hätte ja in der Zeit wo die clients vom Exchange ausgesperrt waren am Exchange alles laufen müssen, oder?
Komisch das Outlook im Offlinemodus die Richtwerte für den Mailversand ignoriert.
Oder war es ein BOD Gerät bei dem ein nicht Firmen Outlook vom Mitarbeiter im Einsatz war und der nur so sein Firmenkonto da eingebunden hat.
Gruß
Chonta
So blöd kann man garnicht denken was einige versuchen.Aber dann hätte ja in der Zeit wo die clients vom Exchange ausgesperrt waren am Exchange alles laufen müssen, oder?
Komisch das Outlook im Offlinemodus die Richtwerte für den Mailversand ignoriert.
Oder war es ein BOD Gerät bei dem ein nicht Firmen Outlook vom Mitarbeiter im Einsatz war und der nur so sein Firmenkonto da eingebunden hat.
Gruß
Chonta
genau da ist ja Problem: die große Mail wurde ja bereits vom Client zum Exchange in dem Postaugang gesynct (darum konnte ich die auch in dem eingebundenen Postfach sehen), damit ist der Client raus, die Mail hat den Exchange bereits erreicht und wartet auf den Transportdienst abgeholt zu werden.
Der MS Techniker hat es dann so erklärt das der Postausgangsordner am Exchange ähnlich funktioniert wie damals (TM) der PickUp Folder, wo temporär die ausgehenden Mails liegen bis der Transportdienst diese einsammelt und weiterverarbeitet.
Der 1. MS Techniker hat dann die "glorreiche" Empfehlung ausgesprochen den Exchange neu zu installieren, hätten wir auch fast gemacht, einfach die Datenbanken abhängen und dann am neuen Exchange einhängen, dass Problem wäre damit aber nach wie vor vorhanden gewesen, da die Mail ja bereits in der Datenbank ist.
Der MS Techniker hat es dann so erklärt das der Postausgangsordner am Exchange ähnlich funktioniert wie damals (TM) der PickUp Folder, wo temporär die ausgehenden Mails liegen bis der Transportdienst diese einsammelt und weiterverarbeitet.
Der 1. MS Techniker hat dann die "glorreiche" Empfehlung ausgesprochen den Exchange neu zu installieren, hätten wir auch fast gemacht, einfach die Datenbanken abhängen und dann am neuen Exchange einhängen, dass Problem wäre damit aber nach wie vor vorhanden gewesen, da die Mail ja bereits in der Datenbank ist.
