Exchange Troubleshooting – Fall 3: Mail kann nicht versendet werden
Lesen Sie einen weiteren Exchange Troubleshooting-Fall in der Blog-Serie unseres Experten Markus Hengstler. Thema: Mail kann nicht versendet werden.
Vor einiger Zeit habe ich eine Serie von Artikeln über Troubleshooting-Fälle begonnen und Probleme im Zusammenhang mit Netzwerk und Storage beschrieben. Hier möchte ich ein weiteres interessantes Ticket bei einem Kunden ausführen und an die Serie anschliessen.
Die Umgebung des Kunden besteht aus nur einem Exchange 2016 CU4 Server. Normalerweise bin ich kein Befürworter von 1-Server-Lösungen, aber es hat die Fehlersuche doch erleichtert, da nicht die Logs von mehreren Lokationen überprüft werden mussten.
Die fast 300 Mailboxen werden hauptsächlich mit Outlook 2016 über Citrix XenApp verwendet. Alle Namen und IP-Adressen sind geändert oder unkenntlich gemacht.
Mail an externe Adresse kann nicht versendet werden
Im ersten Fall gab der IT-Supporter des Kunden an, dass ein Benutzer an eine externe Adresse keine Mails versenden könne. Soweit wäre das nichts Aussergewöhnliches – verschiedene Komponenten können dazu führen: Outlook, Exchange, Anti-Spam Gateway, Infrastruktur des Empfängers. Was das Ganze mysteriös machte, war die Bemerkung des Supporters, es funktioniere nur über Outlook nicht – in OWA hätte er das Mail versenden können. Ausserdem schickte er noch die Fehlermeldung mit, die der Benutzer beim erfolglosen Versand erhalten hatte:
Diagnostic information for administrators:
Generating server: mail.kunde.com
peter.meier@empfaenger.com
xxx.xxx.xxx.xx
Remote Server returned '554 5.0.0 <xxx.xxx.xxx.xx #5.0.0 smtp; 5.1.0
- Unknown address error 550-'5.7.1 < peter.meier@empfaenger.com >...
Relaying denied. Proper authentication required.' (delivery attempts: 0)>'
«mail.kunde.com» ist der FQDN des SMTP-Gateways. Somit hatte das Mail die Exchange-Organisation verlassen. Wieso sollte es dann mit OWA ohne Fehlermeldung ausgeliefert werden?
Ich überprüfte die Message Tracking Logs des Servers mittels Exchange Management Shell und konnte verifizieren, dass beide Mails – erfolgreiche und erfolglose Zustellung – Exchange verlassen hatten.
 |
Microsoft Exchange TrainingsFür mehr Informationen zu Exchange 2013 und 2016 besuchen Sie einen der folgenden Kurse. |
Für mehr Informationen zu Exchange 2013 und 2016 besuchen Sie einen der folgenden Kurse.
Als Nächstes schaute ich mir das originale Mail und die originale Fehlermeldung, die der Benutzer inzwischen gelöscht hatte, mit Hilfe von In-Place eDiscovery an. Auch hier wurde nur der Verdacht erhärtet, dass das Problem bei der Gegenseite liegen musste.
Schliesslich prüfte ich die MX DNS Records des Empfängers mit nslookup:
C:\Users\markus.hengstler>nslookup
Default Server: ADDS01.hengstler-it.com
Address: 10.20.0.200
> set type=mx
> empfaenger.com.
Server: ADDS01.hengstler-it.com
Address: 10.20.0.200
Non-authoritative answer:
empfaenger.com MX preference = 10, mail exchanger = securemailin1.mybiscloud.com
empfaenger.com MX preference = 10, mail exchanger = securemailin2.mybiscloud.com
empfaenger.com MX preference = 10, mail exchanger = securein3.infotec.com
securemailin1.mybiscloud.com internet address = xxx.xxx.xxx.xx
securemailin1.mybiscloud.com internet address = xxx.xxx.xxx.xxx
securein3.infotec.com internet address = xxx.xxx.xxx.xxx
Der 3. MX-Eintrag zeigte auf die IP-Adresse aus der Fehlermeldung. Es machte mich stutzig, dass der FQDN nicht ins Schema passte – aber das konnte natürlich auch Teil eines Desaster-Recovery-Konzepts sein …
Jedenfalls testete ich den Mailversand an den betroffenen Empfänger mit Microsofts Remote Connectivity Analyzer:
Resultat: An zwei der Mail Exchanger konnte das Testmail ausgeliefert werden, an einen nicht. Der Kunde hatte also einfach Pech beim Versand mit Outlook und Glück mit OWA, da die gleiche Präferenz für alle drei MX Records ein Loadbalancing bewirkte.
Ich schrieb dem Postmaster des Empfängers eine Nachricht mit meinen Erkenntnissen und kurze Zeit später war der fehlerverursachende Eintrag entfernt.
Fazit
Fehlersuche im Messaging-Umfeld ist nicht immer gradlinig. Symptome können täuschen und das Verhalten der Systeme aus Benutzersicht auch. Wichtig ist es, alle möglichen Troubleshooting Tools zu kennen, um sich selber ein Bild der Situation machen zu können.