none
Exchange 2016 - 451 4.7.1 Service unavailable - try again later RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen,

     

    ich benötige einmal euren Rat.

    Wir haben bei unser Exchange 2016 Server mit dem aktuellen CU und aktuell in den Warteschlangen (Connector zum Mailproxy) auf den Servern den Fehler.

     

    451 4.7.1 Service unavailable - try again later

    Dies ist heute mit einmal bei allen Exchange Servern aufgetreten und die Ursache für mich nicht greifbar. Das betrifft somit nur Mails die nach Extern gehen und teilweise werden sie versendet andere wiederum bleiben Ewigkeiten in der Warteschlange. Wir haben auf den Exchange Servern von TrendMicro die Software „Scanmail for Exchange“ welche aber nur eingehende Mails auf deren Gefahr prüft und nicht ausgehende E-Mails.

     

    Hier einmal der Mail Ablauf bei uns.

    Anwender -> Exchange 2016 -> KEMP Loadbalancer (vService SMTP – Port25) -> Mailproxy -> Extern

     

    Wir haben bereits die Mailproxy Systeme neugestartet sowie den KEMP Loadbalancer. Beim Kemp werden die beiden Mailproxy Systeme auch mit ihren Service (SMTP) Grün also funktional angezeigt. Auch den ScanMail Dienst habe ich auf den Servern neugestartet. Leider kein erfolg denn es werden weiterhin die Nachrichten eine Zeitlang mit diesem Fehler angezeigt. Meine Testmails (Mit und ohne Anhang) gehen immer sofort raus und kommen auch an. Ich habe keinen Ansatz was diese Mails von denen der anderen Benutzer unterscheidet.

    Heute Abend plane ich den Neustart von den Exchange Servern aber ich bin eher pessimistisch das dies die Lösung sein wird.

     

    Habt Ihr Tipps wo ich noch schauen kann (Logs) oder was womöglich die Ursache sein könnte dann bitte her damit und DANKE im Vorfeld.

    MfG Paul


    Update: Auch ein Neustart der Server sowie das neueste SecUpdate für Ex2k16 CU18 brachte keine Besserung.

    • Bearbeitet Lexxitus Donnerstag, 12. November 2020 07:25
    Mittwoch, 11. November 2020 17:07
    |

Antworten

  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen,

    wir haben den vermeintlichen Fehler bzw. die Ursache lokalisieren können.

    Es handelt sich wohl bei uns um ein Bug am Mailproxy (Clearswift) der zu Stande kommt, weil wir unsere Mailproxy Systeme per Implace Upgrade von 4.2 auf 5 hochgezogen haben. Das ist wohl nicht ganz sauber oder vollständig vonstattengegangen oder seitens Clearswift etwas unsauber gewesen.

    Wir haben ein System komplett mit der aktuellen Version (5) neu aufgesetzt und die Konfiguration übertragen und auch STARTTLS aktiviert.

    Bisher gab es keine Vorfälle mehr und daher stelle ich das Thema auf Gelöst.

    Vielen Dank an alle Kommentatoren für eure Ansätze/Tipps und wünsche ein erholsames Wochenende.

    MfG Paul

    • Als Antwort markiert Lexxitus Freitag, 27. November 2020 07:45
    Freitag, 27. November 2020 07:45
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Moin,

    in dem Fall würde ich Kemp ins Boot holen, die sehen ggf. mehr

    ;)

    Gruß Norbert

    Donnerstag, 12. November 2020 10:55
    |
    Moderator
  • Question
    Anmelden
    0
    Anmelden

    Hallo Norbert,

    ja ich habe schon TrendMicro (ScanMail for Exchange), Kemp und unseren Netzwerk Dienstleister kontaktiert. Es sind alles VM`s und daher ist auch unser vmware Team bei einer Überprüfung der Ressourcen (ESX & SAN) bei. Das Verhalten tritt gefühlt auch immer gleichzeitig bei allen Exchange Servern auf. Ich hatte mal die Protokollierung am Sendeconnector (Richtung KEMP vService) aktiviert aber entweder durchsuche ich die falschen Logs oder man kann nichts wirklich daraus lesen.

    Der Pfad zu den Logs wäre doch der, oder?

    %ExchangeInstallPath%TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpSend


    MfG Paul

    Donnerstag, 12. November 2020 11:01
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen,

    wir konnten aktuell den KEMP ausschließen da wir die E-Mails testweise über einen neuen Sendeconnector direkt an die Mailproxy Systeme gesendet hatten und der Fehler weiterhin auftritt.

    Gerade eben war es wieder verstärkt so das fast an die 100 Mails in Summe festhingen. Die Mails in den Warteschlangen (es tritt anscheinend immer bei allen Servern gleichzeitig auf) werden nur sehr langsam versendet und zwischendrin kam auch mal folgende Meldung bei der Warteschlange.

    "451 4.4.397 Error communication with target host. -> 421 4.2.1 Unable to connect -> SocketConnectionRefused: Socket error code 10061

    Ich habe bald keinen Ansatz mehr und unser Netzwerkdienstleister auch noch keinen wirklichen Hinweis gefunden aber er schaut weiter.

    Dienstag, 17. November 2020 13:08
    |
  • Question
    Anmelden
    0
    Anmelden

    Den KEMP habe ich jetzt aus der Kette herausgenommen und und lasse die Exchange Server direkt an die Mailproxy Systeme senden.

    Habe jetzt den richtige Log Pfad gefunden denn es werden weiterhin Mails in der Warteschlange gestaut.

    \\ExSvr\c$\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Hub\ProtocolLog\SmtpSend

     

    2020-11-19T12:02:34.707Z,Extern SMTP direkt zu den Mailproxy Systemen,08D8874E6E6ACCA1,2,172.31.xx.xxx:6835,192.168.242.1:25,+,,
    2020-11-19T12:02:34.709Z,Extern SMTP direkt zu den Mailproxy Systemen,08D8874E6E6ACCA1,3,172.31.xx.xxx:6835,192.168.242.1:25,<,220 SMTP ESMTP Relay,
    2020-11-19T12:02:34.709Z,Extern SMTP direkt zu den Mailproxy Systemen,08D8874E6E6ACCA1,4,172.31.xx.xxx:6835,192.168.242.1:25,>,EHLO EX04.firma.local,
    2020-11-19T12:02:34.710Z,Extern SMTP direkt zu den Mailproxy Systemen,08D8874E6E6ACCA1,5,172.31.xx.xxx:6835,192.168.242.1:25,<,250 mail.firma.de PIPELINING SIZE ETRN STARTTLS ENHANCEDSTATUSCODES 8BITMIME DSN CHUNKING,
    2020-11-19T12:02:34.710Z,Extern SMTP direkt zu den Mailproxy Systemen,08D8874E6E6ACCA1,6,172.31.xx.xxx:6835,192.168.242.1:25,>,STARTTLS,
    2020-11-19T12:02:34.710Z,Extern SMTP direkt zu den Mailproxy Systemen,08D8874E6E6ACCA1,7,172.31.xx.xxx:6835,192.168.242.1:25,<,454 4.3.0 Try again later,
    2020-11-19T12:02:34.711Z,Extern SMTP direkt zu den Mailproxy Systemen,08D8874E6E6ACCA1,8,172.31.xx.xxx:6835,192.168.242.1:25,*,,sending message with RecordId 50006304228629 and InternetMessageId <541a2ff27a4e441eab40ed96ee1cdf0e@firma.de>
    2020-11-19T12:02:34.711Z,Extern SMTP direkt zu den Mailproxy Systemen,08D8874E6E6ACCA1,9,172.31.xx.xxx:6835,192.168.242.1:25,>,MAIL FROM:<InternUser@firma.de> SIZE=3203428,
    2020-11-19T12:02:34.711Z,Extern SMTP direkt zu den Mailproxy Systemen,08D8874E6E6ACCA1,10,172.31.xx.xxx:6835,192.168.242.1:25,>,"RCPT TO:<ExternUser@gmail.com> NOTIFY=SUCCESS,FAILURE,DELAY",
    2020-11-19T12:02:34.712Z,Extern SMTP direkt zu den Mailproxy Systemen,08D8874E6E6ACCA1,11,172.31.xx.xxx:6835,192.168.242.1:25,<,451 4.7.1 Service unavailable - try again later,
    2020-11-19T12:02:34.713Z,Extern SMTP direkt zu den Mailproxy Systemen,08D8874E6E6ACCA1,12,172.31.xx.xxx:6835,192.168.242.1:25,<,503 5.5.1 Error: need MAIL command,
    2020-11-19T12:02:34.713Z,Extern SMTP direkt zu den Mailproxy Systemen,08D8874E6E6ACCA1,13,172.31.xx.xxx:6835,192.168.242.1:25,>,QUIT,
    2020-11-19T12:02:34.714Z,Extern SMTP direkt zu den Mailproxy Systemen,08D8874E6E6ACCA1,14,172.31.xx.xxx:6835,192.168.242.1:25,<,221 2.0.0 Bye,
    2020-11-19T12:02:34.715Z,Extern SMTP direkt zu den Mailproxy Systemen,08D8874E6E6ACCA1,15,172.31.xx.xxx:6835,192.168.242.1:25,-,,Local
    2020-11-19T12:02:38.705Z,Extern SMTP direkt zu den Mailproxy Systemen,08D8874E6E6ACCA2,0,,192.168.242.1:25,*,SendRoutingHeaders,Set Session Permissions
    Donnerstag, 19. November 2020 13:49
    |
  • Question
    Anmelden
    0
    Anmelden

    Dann bin ich jetzt leider raus, wenn Evgenij nicht noch eine Idee hat, würde ich einen Call bei MS aufmachen

    ;)

    Gruß Norbert

    Donnerstag, 19. November 2020 14:47
    |
    Moderator
  • Question
    Anmelden
    0
    Anmelden
    OK, also Dein Mailproxy lehnt STARTTLS ab. Was ist es denn für ein System?

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Donnerstag, 19. November 2020 16:07
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen,

    wir haben den vermeintlichen Fehler bzw. die Ursache lokalisieren können.

    Es handelt sich wohl bei uns um ein Bug am Mailproxy (Clearswift) der zu Stande kommt, weil wir unsere Mailproxy Systeme per Implace Upgrade von 4.2 auf 5 hochgezogen haben. Das ist wohl nicht ganz sauber oder vollständig vonstattengegangen oder seitens Clearswift etwas unsauber gewesen.

    Wir haben ein System komplett mit der aktuellen Version (5) neu aufgesetzt und die Konfiguration übertragen und auch STARTTLS aktiviert.

    Bisher gab es keine Vorfälle mehr und daher stelle ich das Thema auf Gelöst.

    Vielen Dank an alle Kommentatoren für eure Ansätze/Tipps und wünsche ein erholsames Wochenende.

    MfG Paul

    • Als Antwort markiert Lexxitus Freitag, 27. November 2020 07:45
    Freitag, 27. November 2020 07:45
    |