Andy's Web Blog

Hallo lieber Leser.

Im Rahmen einer Migration kann ein Exchange 2007 Edge Transport Server mit einem Exchange 2010 Hub Transport Server betrieben werden. Der im Folgenden beschriebene Fehler wird mit hoher Wahrscheinlichkeit auch mit einem Exchange 2010 Edge Transport auftreten, da die Ursache in der Hub Transport Rolle liegt.

Zum Fehler: Nach dem ändern der Edge Synchronisation auf den Exchange 2010 Hub Transport Server konnten keine Nachrichten mehr gesendet werden. Der Empfang funktioniert jedoch einwandfrei. Auf dem Exchange 2010 Hub Transport Server füllt sich die Warteschlange des Send Connectors in Richtung Edge Server (SMTP Relay in Active Directory Site to Edge Transport Server) mit der Fehlermeldung „451 4.4.0 DNS query failed“:

Die Anwender erhielten  zudem Benachrichtigungen „Delivery is delayed to these recipients or groups” für die entsprechenden Mails.

Beschreibung der Installation:

·         Exchange 2010 UR2 Standard English, Single Server (MB, HUB, CAS)

o   Auf Windows Server 2008 SP2 Standard English (aktueller Patch Stand)

·         Exchange 2007 SP2 UR 2 Standard English Edge Transport Server

o   Auf Windows Server 2003 R2 SP2 Standard English (aktueller Patch Stand)

Eine Analyse der Transport Logs ergab dass bisher kein Versuch gestartet wurde diese Mails per SMTP zu versenden. Damit konnte der Exchange 2007 Edge Transport als Fehlerquelle nahezu ausgeschlossen werden. Ein Blick in die Connectivity Logs des Hub Transport Servers bestätigte die Fehlermeldung der Warteschlangen:

2010-03-12T13:02:25.714Z,08CC8FFAF64ED566,SMTP,edgesync - duesseldorf to internet,+,SmtpRelayWithinAdSiteToEdge 347ebd04-3856-4d7b-8570-3a5c734c1e46

2010-03-12T13:02:25.714Z,08CC8FFAF64ED566,SMTP,edgesync - duesseldorf to internet,>,Non-existent domain reported by 172.16.2.251

2010-03-12T13:02:25.714Z,08CC8FFAF64ED566,SMTP,edgesync - duesseldorf to internet,-,Messages: 0 Bytes: 0 (The DNS query for ‘SmtpRelayWithinAdSiteToEdge’:'edgesync - duesseldorf to internet’:'347ebd04-3856-4d7b-8570-3a5c734c1e46′ failed with error: InfoDomainNonexistent)

Zugleich fand sich auf hier die Ursache des Problems. Der DNS Server 172.16.2.251 war der Sekundäre DNS Server der IP Konfiguration. Er sollte also gar nicht für die DNS Auflösung herangezogen werden, sofern der Primäre DNS Server antwortet. In diesem Fall konnte der Sekundäre DNS Server die internen Namen auch nicht auflösen. Es war ein nicht bereinigter Eintrag. Allerdings war auch dies ein DNS Server, der grundsätzlich auf die Anfragen geantwortet hat.

Da der Primäre DNS Server aber korrekt auflöst konnte das Problem durch nslookup nicht nachgestellt werden. Der Primäre DNS Server kann alle Server, inklusive Edge Transport, mit FQDN und Shortname auflösen.

Nach dem Entfernen des falschen Eintrags leerte sich dich Warteschlange augenblicklich. Der Fehler konnte durch das erneute Eintragen des falschen DNS Server reproduziert werden. Augenscheinlich verwendet der Transport Service in diesem speziellen Fall die DNS Server nicht in der richtigen Reihenfolge.

Andy

Post a Comment