Heute habe ich den ganzen Tag mit einem besonders seltsamen Problem zu kämpfen gehabt. Ausgangssituation ist eine Mailmigration, bei der für eine Übergangszeit das alte Mailsystem (Lotus Notes) und das neue Mailsystem (Exchange 2010) parallel betrieben werden. Die Umgebung lief jetzt schon eine gewisse Zeit lang ohne Probleme.
Das Besondere an solchen Umgebungen ist die Tatsache, dass ein SMTP-Adressraum sich über zwei unabhängige Systeme erstreckt. Die Systeme müssen also wissen, dass sie Mails für Benutzer, deren Maildomäne ihnen zugeordnet ist, weiterleiten müssen, falls der Benutzer in dem System keine Mailbox hat. Exchange 2010 teile ich über „Akzeptierte Domänen“ mit, für welche Maildomänen es zuständig ist. Setze ich dabei die Option „internes Relay“, weiss Exchange dass es noch weitere Server ausserhalb der Exchange-Organisation gibt, die ebenfalls Mailempfänger aus dieser Domäne haben. Was dann noch fehlt ist ein SMTP-Konnektor, über den die Mails an das andere Mailsystem gehen.
Diese Konfiguration hat jetzt über einen längeren Zeitraum sehr gut funktioniert. Seit zwei Tagen aber konnten keine Mails mehr von Exchange aus an den Notes Server versendet werden. Die Mails landeten alle in der „Unzustellbar“-Warteschlange. Schaute man sich nun eine einzelne Mail dort an, wurde als fehlermeldung angegeben, dass der Empfänger kein Postfach haben würde. Exchange schien also zu glauben, dass der Empfänger zu der Exchange-Organisation gehören würde. Ich habe diese Konfiguration über Jahre (und Exchange-Versionen) hinweg bei Migrationen immer wieder gehabt; aber dieser Fehler war mir neu.
Zuerst habe ich das Übliche versucht: Diagnoseprotokollierung eingeschaltet, Event-Log überprüft. Kein Ergebnis. Der Neustart von Diensten brachte auch keinen Erfolg. Danach habe ich mich durch diverse Artikel in Foren und bei Microsoft gewühlt. Hierbei bin ich auf einen PowerShell-Befehl zum erneuten Versenden von Mails in einer Warteschlange gestossen: Retry-Queue. Hierbei ist zu beachten, dass dieser Befehl den Parameter Resubmit kennt. Wird der Parameter nicht angegeben, versucht das System eine sofortige Zustellung. Setzt man den Parameter aber auf „wahr“ ($true), dann wird die Mail erneut an den Categorizer übergeben. Da ich im Laufe des Tages einige kleinere Änderungen am Konnektor durchgeführt hatte, wollte ich sichergehen dass eventuelle Auswirkungen auf das Routing auch bemerkt würden und habe den Parameter mit angegeben.
Interessanterweise gab es zwei Maildomänen, die auf beiden Systemen existierten. Der Fehler trat nur bei einer Domäne auf; die andere funktionierte tadellos. Ich habe dann eine Mail an einen fiktiven Empfänger aus der nicht funktionierenden Domäne gesendet. Und siehe da: diese Mail ging durch. Nun konnte der Fehler eigentlich nur durch die einzige Änderung am System verursacht worden sein. Über ein Skript war bei allen AD-Benutzern das Attribut „mail“ auf die E-Mailadresse gesetzt worden (die nicht funktionierende). Nun war mir aber nicht klar, warum sich Exchange um dieses Attribut scheren sollte.
Ein Telefongespräch brachte dann die Lösung. Da das Mailrouting demnächst hauptsächlich über Exchange laufen sollte, benötigte der dort installierte SPAM-Filter eine Möglichkeit, aus dem Active Directory sämtliche E-Mail-Adressen für einen Benutzer auszulesen. So sollte sichergestellt werden, dass nur Mails für existierende Empfänger angenommen werden würden. Leider verfiel man, da in das Attribut „mail“ ja nur ein Eintrag passt, auf die Idee hierfür das Attribut proxyAddresses zu nehmen. Bei Benutzern mit Exchange-Postfach bzw. bei Kontakten stehen hier die Mailadressen des Benutzers. Da die Einträge aber über einen unüblichen Weg gemacht wurden, schien Exchange es jetzt so zu interpretieren dass der Benutzer ein Exchange-Empfänger wäre (also die Mail lokal zugestelltw erden könnte). Da die Abfrage nach dem Mailboxserver für den Benutzer (homeMDB-Attribut) aber mangels Postfach fehlschlug, landete die Mail mit der aus Sicht von Exchange korrekten Fehlermeldung in der Unzustellbarkeits-Queue.
Wir haben dann in einem weiteren Telefonat beschlossen die Proxy-Adressen wieder zu entfernen. Exchange bietet mittlerweile bei der Anlage von Kontakten zwei Möglichkeiten: E-Mail Kontakt und E-Mail Benutzer. Der E-Mail Kontakt ist der altbekannte Eintrag im globalen Adressbuch, der nur dazu dient dass man externe Empfänger zentral aus dem Adressbuch auswählen kann. Der E-Mail Benutzer ist nun aber ein Active Directory Objekt mit einer externen Mailadresse (also ohne Postfach). Man kann auch vorhandene Active Directory Benutzer nachträglich zu E-Mail Benutzern machen, so dass ihnen dann über einen korrekten Weg die externen Mailadressen zugewiesen werden kann.
Was lernen wir daraus? Es gibt bei Exchange noch Vieles zu entdecken.
PS:Was ich aber nicht verstehe: warum testet man eigentlich nicht, nachdem man so eine Änderung durchgeführt hat?
]]>