none
Exchange 2013: Halbstuendlich 99% CPU durch MSExchangeFrontendTransport, EdgeTransport, MSExchangeSubmission RRS feed

  • Frage

  • Hallo zusammen,

    wir haben auf unserem Exchange 2013 regelmäßig wiederkehrend (etwa alle halbe Stunde) eine seltsam hohe CPU-Last auf folgenden Prozessen:

    - MSExchangeFrontendTransport

    - EdgeTransport

    - MSExchangeSubmission

    Der Server ist dann jeweils für 1-2 Minuten voll ausgelastet und auf den Outlook-Clients tritt beim Wechsel der Ansichten die Meldung auf "Outlook versucht Daten von <exchangeserver.local.domain> abzurufen". Nachdem die CPU-Last der o.g. Prozesse wieder normal ist, funktioniert wieder alles einwandfrei.

    Der Server ist unter ESXi 5.5 virtualisiert und auch ausreichend dimensioniert: 4x2,19GHz, 16GB RAM.

    Solange der Fehler nicht auftritt, liegt die CPU-Last bei angenehmen 6-18%.

    Es sind im Schnitt 15-20 User online, teilweise mit gegenseitigen Postfachzugriffen. Es existiert ein zentrales Postfach, das mit über 50GB sehr groß ist und von allen im Online-Modus verwendet wird. Bisher hat das aber keine Probleme verursacht. Exchange-Cache-Modus ist auf allen Clients aktiviert (ohne Herunterladen freigegebener Ordner).

    Gibt es hier jemanden, der eine Idee hat,  woran es liegen könnte, dass die o.g. Prozesse in dieser Regelmäßigkeit die volle CPU für sich beanspruchen?

    Vielen Dank schon mal und Grüße

    Patrick



    • Bearbeitet FoergP Mittwoch, 30. März 2016 12:12 Ueberschrift korrigiert
    Mittwoch, 30. März 2016 11:53

Antworten

  • Hallo zusammen,

    Problem gelöst!!! Zunächst hatte das Update auf CU12 keinen Erfolg gebracht - außer dass der Exchange nun CU12 ist, was nebenher auch sehr freut ;-)

    Nach weitergehender Recherche in den Event Logs bin ich dann auf einen Zusammenhang aufmerksam geworden, den ich bei meinen bisherigen Analysen nicht erkannt hatte: Ich verteile über eine GPO eine gehärtete hosts-Datei, die neben Servereinträgen für den Fall eines Fehlers im DNS auch zahlreiche Seiten blockiert (Umleitung auf 127.0.0.1), die Schadcode ausliefern. Da der WMI-Filter nicht korrekt eingestellt war, wurde diese hosts-Datei auch halbstündlich auf den Exchange repliziert. Der verschluckt sich dann an der aktualisierten hosts-Datei und macht regelmäßig die oben erläuterten Faxen - immer wenige Sekunden nach dem turnusmäßigen GPO-Update. - GPO temporär deaktiviert und der Fehler trat nicht mehr auf!

    Euch allen vielen herzlichen Dank für die schnellen Antworten und viele Grüße aus Berlin

    Patrick

    • Als Antwort markiert FoergP Donnerstag, 31. März 2016 10:39
    Donnerstag, 31. März 2016 10:39

Alle Antworten

  • Am 30.03.2016 schrieb FoergP:
    Hi,

    wir haben auf unserem Exchange 2013 regelmäßig wiederkehrend (etwa alle halbe Stunde) eine seltsam hohe CPU-Last auf folgenden Prozessen:

    - MSExchangeFrontendTransport

    - EdgeTransport

    - MSExchangeSubmission

    Welches CU hat der 2013? Warum kann man sowas denn nicht als erstes mit reinschreiben? ;)
    Seit wann tritt das Problem auf?
     Bye
    Norbert

    Mittwoch, 30. März 2016 13:14
  • Und ein Blick ins Eventlog und in die Warteschlange wäre auch sinnvoll. Klingt wie fehlerhafte Mails.

    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Mittwoch, 30. März 2016 13:41
  • Version ist 2013 SP1 (Build 847.32)
    Mittwoch, 30. März 2016 13:45
  • Version ist 2013 SP1 (Build 847.32)

    Uii.... Na dann weißt Du ja, was Du als erstes zu tun hast.

    Zwischen CU 4 (= SP 1) und CU 12 (= aktuell) liegen Welten!


    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Mittwoch, 30. März 2016 13:47
  • Die Warteschlange ist leer, während das auftritt, das hatte ich auch schon mal nachgesehen.
    Mittwoch, 30. März 2016 13:54
  • Moin,

    Ich glaube nicht das die angegebene Version stimmt, guck bitte mal nach:
    http://blog-schulenburg.de/index.php/kategorie-als-blog/87-exchange-build-nummern

    Offiziell nach den neuen Richtlinien seitens MS ist die älteste supportete Version aktuell -2, heißt Stand heute CU13 - 2 = CU11!!

    ;)


    Gruß Norbert


    Mittwoch, 30. März 2016 14:26
    Moderator
  • Moin,

    Ich glaube nicht das die angegebene Version stimmt, guck bitte mal nach:
    http://blog-schulenburg.de/index.php/kategorie-als-blog/87-exchange-build-nummern

    Offiziell nach den neuen Richtlinien seitens MS ist die älteste supportete Version aktuell -2, heißt Stand heute CU13 - 2 = CU11!!

    ;)


    Gruß Norbert


    Wie so nicht? Build 847.32 ist CU 4 = SP 1.

    Und aktuell ist CU 12. ;)


    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Mittwoch, 30. März 2016 14:38
  • Ja, ist richtig, was Robert sagt.

    Ausgabe von Get-ExchangeServer | Format-List Name, Edition, AdminDisplayVersion sagt:

    Name                : xxxx
    Edition             : Standard
    AdminDisplayVersion : Version 15.0 (Build 847.32)

    CU12 ist ja auch offiziell freigegeben.

    Kann ich erst abends updaten

    Danke allen schon mal bis hierhin und ich gebe Rückmeldung!

    Patrick
    Mittwoch, 30. März 2016 15:04
  • Am 30.03.2016 schrieb Robert Wille [MVP]:

    Version ist 2013 SP1 (Build 847.32)

    Uii.... Na dann weißt Du ja, was Du als erstes zu tun hast.

    Zwischen CU 4 (= SP 1) und CU 12 (= aktuell) liegen Welten!

    Und der Grund meiner Frage war, dass zumindest im CU 12 tatsächlich der Edgetransport gefixt wurde. Könnte ja evtl. ein Zusammenhang bestehen. ;)

    Bye
    Norbert

    Mittwoch, 30. März 2016 15:12
  • Hopefully, danke!
    Mittwoch, 30. März 2016 15:35
  • Hallo zusammen,

    Problem gelöst!!! Zunächst hatte das Update auf CU12 keinen Erfolg gebracht - außer dass der Exchange nun CU12 ist, was nebenher auch sehr freut ;-)

    Nach weitergehender Recherche in den Event Logs bin ich dann auf einen Zusammenhang aufmerksam geworden, den ich bei meinen bisherigen Analysen nicht erkannt hatte: Ich verteile über eine GPO eine gehärtete hosts-Datei, die neben Servereinträgen für den Fall eines Fehlers im DNS auch zahlreiche Seiten blockiert (Umleitung auf 127.0.0.1), die Schadcode ausliefern. Da der WMI-Filter nicht korrekt eingestellt war, wurde diese hosts-Datei auch halbstündlich auf den Exchange repliziert. Der verschluckt sich dann an der aktualisierten hosts-Datei und macht regelmäßig die oben erläuterten Faxen - immer wenige Sekunden nach dem turnusmäßigen GPO-Update. - GPO temporär deaktiviert und der Fehler trat nicht mehr auf!

    Euch allen vielen herzlichen Dank für die schnellen Antworten und viele Grüße aus Berlin

    Patrick

    • Als Antwort markiert FoergP Donnerstag, 31. März 2016 10:39
    Donnerstag, 31. März 2016 10:39
  • Am 31.03.2016 schrieb FoergP:
    Hi,

    Nach weitergehender Recherche in den Event Logs bin ich dann auf einen Zusammenhang aufmerksam geworden, den ich bei meinen bisherigen Analysen nicht erkannt hatte: Ich verteile über eine GPO eine gehärtete hosts-Datei, die neben Servereinträgen für den Fall eines Fehlers im DNS auch zahlreiche Seiten blockiert (Umleitung auf 127.0.0.1), die Schadcode ausliefern. Da der WMI-Filter nicht korrekt eingestellt war, wurde diese hosts-Datei auch halbstündlich auf den Exchange repliziert. Der verschluckt sich dann an der aktualisierten hosts-Datei und macht regelmäßig die oben erläuterten Faxen - immer wenige Sekunden nach dem turnusmäßigen GPO-Update. - GPO temporär deaktiviert und der Fehler trat nicht mehr auf!

    Wer sollte auch mit einer Hosts Datei auf einem Exchange rechnen? danke für die Rückmeldung. Gibts echt Leute die eine Hosts Datei für sowas "pflegen"? Ich finde das irgendwie grenzwertig. :)

    Bye
    Norbert

    PS: Mir fällt dabei folgender Spruch ein ;)


    Donnerstag, 31. März 2016 11:41