magicpeter 11 Geschrieben 13. Mai Melden Teilen Geschrieben 13. Mai (bearbeitet) Moin, wir setzen einen Exchange 2019 CU14 in einer Hyper-V VM unter Windows 2019 Std ein. Alle aktuellen Updates sind installiert. Der Exchange 2019 CU14 versendet auf einmal keine E-Mails mehr nach aussen. Es kommt keine Fehlermeldung beim Versenden der E-Mail. Intern ist alles OK, aber nach aussen geht nix mehr raus. Versendet wird über einen Smarthost. Auf dem Server ist auch der DKimSigner in Version 3.4.0 installiert. Hat bis gestern alles einwandfrei funktioniert. Hat jemand eine Idee wo es hängen könnte? Wo schaue ich am besten nach? Habe mich schon durch die Logdateien gekämpft. Standardmäßig befinden sich die Protokolldateien an folgenden Speicherorten: Front-End-Transportdienst auf Postfachservern: Empfangsconnectors: %ExchangeInstallPath%TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive Sendeconnectors: %ExchangeInstallPath%TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpSend Transportdienst auf Postfachservern: Empfangsconnectors: %ExchangeInstallPath%TransportRoles\Logs\Hub\ProtocolLog\SmtpReceive Sendeconnectors: %ExchangeInstallPath%TransportRoles\Logs\Hub\ProtocolLog\SmtpSend Postfachtransportübermittlungsdienst auf Postfachservern (Empfangsconnectors): %ExchangeInstallPath%TransportRoles\Logs\Mailbox\ProtocolLog\SmtpReceive\Delivery Postfachtransportübermittlungsdienst auf Postfachservern (Sendeconnectors): %ExchangeInstallPath%TransportRoles\Logs\Mailbox\ProtocolLog\SmtpSend\Submission Hinweis: Die Protokollprotokollierung für Nebeneffektnachrichten, die gesendet werden, nachdem Nachrichten an Postfächer übermittelt wurden, erfolgt in %ExchangeInstallPath%TransportRoles\Logs\Mailbox\ProtocolLog\SmtpSend\Delivery. So löst beispielsweise eine an ein Postfach gesendete Nachricht eine Posteingangsregel aus, die die Nachricht an einen anderen Empfänger weiterleitet. Transportdienst auf Edge-Transport-Servern: Empfangsconnectors: %ExchangeInstallPath%TransportRoles\Logs\Edge\ProtocolLog\SmtpReceive Sendeconnectors: %ExchangeInstallPath%TransportRoles\Logs\Edge\ProtocolLog\SmtpSend Leider konnte ich da nichts ungewöhnliches finden. So jetzt bin ich schon einen Schritt weiter. Schaue mir gerade mit dem Queue Viewer die Warteschlangen an. Und siehe da alle E-Mail von heute (83 Stück) liegen in der Queue sslout.de. Das brachte mich auf die Idee mit der Firewall. Konnte das Problem schon lösen. Es hatte einer an der Hardware-Firewall und dem Regelwerk rumgefummelt. So jetzt läuft wieder alles. bearbeitet 13. Mai von magicpeter 1 1 Zitieren Link zu diesem Kommentar
v-rtc 88 Geschrieben 13. Mai Melden Teilen Geschrieben 13. Mai Vielen Dank fürs Bescheid geben 👍 Zitieren Link zu diesem Kommentar
massaraksch 41 Geschrieben 18. Mai Melden Teilen Geschrieben 18. Mai Hi, Queue Viewer? Ist doch für "Warmduscher" Der erste Weg ist immer: get-queue oder (bei mehreren Servern) get-transportservice | get-queue Bevor man mühsam in den Logs rumpult... Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.