Exchange 2000/2003 MTA und Routing
Das Nachrichten Routing bei Exchange 5.5 war X.400 basiert und nutzte den MTA-Dienst. Dieser hat die Nachrichten aus den Warteschlangen geholt und weiter verteilt. Der SMTP-Connector war nur ein "Anhängsel" des MTA, d.h. ohne den MTA lief nichts innerhalb von Exchange 5.5. Der MTA hat seine Wegewahl anhand der Routing Tabelle getroffen, welche über den normalen Verzeichnisabgleich in der Organisation aktualisiert wurde.
Exchange 2000 hat einen gänzlich anderen Mechanismus zum übermitteln von Nachrichten und Leitwegeinformationen. Aufgrund der Verbreitung des Internet und der erwiesen robusten Funktion von SMTP und DNS und dem immensen Aufkommen von "MIME-codierten" Nachrichten ist Exchange 2000 nun ebenfalls ein SMTP-basiertes Übermittlungssystem. Natürlich kann Exchange auch weiterhin mit X.400 Systemen und alten Exchange 5.5. Servern per MTA kommunizieren, aber zwischen Exchange 2000 Servern und Routinggruppen wird in der Regel "SMTP" gesprochen.
Die Rolle des MTA
Der Microsoft Exchange MTA ist in einer reinen Exchange 2000x Umgebung nicht mehr unbedingt nötig, da der Exchange 2000/2003 Routing Service in Verbindung mit dem virtuellen SMTP-Server hier die meiste Arbeit übernimmt. Der MTA ist eigentlich nur noch für folgende Tätigkeiten erforderlich.
- X.400-Connector
Verbindungen über den X.400 Connector werden weiterhin über den MTA abgewickelt. - Exchange 5.5
Die Verbindung mit Exchange 5.5 Servern in der gleichen administrativen Gruppe (= Exchange 5.5. Site) erfolgt per RPC und ist damit ein Fall für den MTA - EDK Gateways
Oft nutzen "alte" Gateways zu Fax, SMS etc. noch die EDK-Schnittstelle, welche noch aus Exchange 5.x Zeiten stammt und auch hier ist der MTA für die Übertragung der Nachrichten zuständig. Neuere Gateways nutzen SMTP zur Anbindung.
Entsprechend können Sie natürlich den MTA deaktivieren, wenn Sie seine Funktion wirklich nicht mehr benötigen.
- 261103 A comparison of the Exchange Server 5.5 message transfer agent and the Exchange 2000 Server message transfer agent
- 263248 X.400 message flow in Exchange 2000
- 264075 Description of MTA tuning when Exchange 5.5 coexists with Exchange 2000 Server or with Exchange Server 2003
- 810489 MTA Stacks service must remain enabled in Exchange 2000 and 2003
- 899302 How to increase the number of databases that are supported by the MTA service when Exchange Server 5.5 coexists with a server cluster that is running Exchange Server 2003
- http://msexchangeteam.com//archive/2005/09/09/410522.aspx
Routing Extrem
Um etwas Licht in das Exchange Routing zu bringen, habe ich eine kleine Testreihe aufgebaut.
- Exchange 2003 SP1 auf Windows 2003
Servername: SRV01 - Outlook 2003 Client
Verbindung mit MAPI over RPC - Empfängerrichtlinien
firma.tld (einmal autoritativ und einmal nicht autoritativ) - Internet Connector
Adressraum: SMTP:* Kosten 1
keine Beschränkungen
Nun wurden von intern mit Outlook Nachrichten an folgende Empfänger gesendet:
- Unknown@firma.tld
Dies soll eine nicht bekannte Mailadresse mit der gleichen SMTP-Domäne darstellen. Das kann z.B.: erforderlich sein, wenn ein Adressraum gemeinsam genutzt wird. Das kann aber auch durch einen Tippfehler eines Anwenders passieren - User@host.firma.tld
In größeren Firmen werden oft auch andere Systeme eingebunden und müssen erreicht werden. Leider ist der Name der AD-Domäne oft identisch mit der SMTP-Maildomäne, so dass hier ein Anwender auf solche einem System vielleicht mit User@host.firma.tld adressiert wird. Lässt Exchange Mails dorthin zu, auch wenn Exchange autoritativ für die übergeordnete Domänbe ist ?
Um das genaue Verhalten von Exchange zu ermitteln, wurde folgende Testreihe durchgeführt.
Richtlinie | Connector Test Adressraum |
Empfänger | Ergebnis |
---|---|---|---|
firma.tld |
Nicht installiert |
Unknown@firma.tld |
NDR vom Postfachserver |
User@host.firma.tld |
Queue Internet Connector |
||
Smtp:firma.tld |
Unknown@firma.tld |
NDR vom Postfachserver |
|
User@host.firma.tld |
Queue Internet Connector |
||
Smtp:*.firma.tld |
Unknown@firma.tld |
NDR vom Postfachserver |
|
User@host.firma.tld |
Queue TEST Connector |
||
firma.tld |
Nicht installiert |
Unknown@firma.tld |
Queue Internet Connector |
User@host.firma.tld |
Queue Internet Connector |
||
Smtp:firma.tld |
Unknown@firma.tld |
Queue TEST Connector |
|
User@host.firma.tld |
Queue Internet Connector |
||
Smtp:*.firma.tld |
Unknown@firma.tld |
Queue Internet Connector |
|
User@host.firma.tld |
Queue TEST Connector |
Aus der Tabelle ist gut zu erkennen, dass Exchange Mails von intern auf die Hostadresse User@host.firma.tld immer zustellt, auch wenn Exchange Autoritativ für firma.tld ist. Die Zustellung kann aber mit einem Connector mit dem passenden Adressraum gesteuert werden. Nur genau entsprechende Adressen werden von Exchange mit einem NDR beantwortet, wenn der Empfänger nicht in der Organisation zu finden ist.
Ist Exchange jedoch nicht autoritativ, dann werden die Mails von unbekannten Empfängern prinzipiell über Connectoren weiter versendet.
Sonderfall Alternate-Recipient / Target Address
Normalerweise löst Exchange jede SMTP-Mail gegen das Active Directory auf und sucht das entsprechende Zielpostfach. Wird die SMTP-Adresse im AD gefunden, dann stellt Exchange die Mail in das dazugehörige Postfach zu. Das kann durchaus über mehrere Server und Connectoren laufen.
Allerdings gibt es einen Fall, in dem Exchange sich nicht um die Empfängerrichtlinien und das interne Routing kümmert, sondern die Mail als "geht ins Internet" betrachtet und entsprechend den Adressräumen der SMTP-Connectoren aus der Exchange Organisation hinaus sendet. Dies ist z.B.: bei Kontakten der Fall.
Exchange unterscheidet, ob die SMTP-Adresse "nur" eine Adresse von vielen in den "ProxyAddresses" ist (Siehe auch AD LDAPFelder), sondern ob die Adresse als "TargetAddress" ausgeführt wird. Wenn Sie z.B.: als Domäne "firma.de" in ihren Empfängerrichtlinien definiert haben, dann haben meist alle Postfächer auch diese Adressen. Nun können Sie aber einen Kontakt anlegen, der ebenfalls "Username@firma.de" als Zieladresse hat.
Wenn Sie nun annehmen, dass Exchange die Mail versucht, intern aufzulösen, dann haben Sie sich geirrt. Auch wenn diese Zieldomäne eigentlich "intern" ist und selbst wenn es intern sogar ein Postfach mit dieser Adresse geben würde, so wird Exchange 200x die Mail auf dem kürzesten und günstigsten Weg aus der Organisation hinaus in das Internet sendet. Das passiert sogar, wenn es sich dabei um ein Postfach handelt, bei dem Sie manuell (LDAP, ADSIEDIT o.ä.) das Attribut gesetzt haben.
Nun mag man sich fragen, was das eigentlich soll zumal viele nun sagen werden, dass Exchange dank MX-Record die Mail ja wieder direkt zu sich selbst zurück sendet und damit eine Schleife baut. Diese Funktion ist aus meiner Sicht z.B. für folgende Fälle interessant.
- Migration
Stellen Sie sich vor, Sie migrieren Postfächer von einer Exchange Organisation zu einer anderen Organisation. Warum auch immer können sie in der Quelle das Postfach nicht löschen und durch einen Kontakt ersetzen, sondern es muss vorhanden bleiben. Dann können Sie mit dem Trick erreichen, dass alle Mails an das Postfach zur anderen Organisation weitergeleitet werden, ohne erst einen zweiten Kontakt anzulegen und diesen als alternativen Empfänger beim Postfach einzutragen. - Koexistenz
Das gleiche gilt natürlich auch für die Koexistenz von Organisationen, bei denen ein Benutzer in beiden Organisationen ein Postfach haben muss aber nur in einem Postfach die Mails auflaufen sollen. - partielles externes Hosting
Es gibt Firmen, die z.B.: intern ein Postfach für einen Mitarbeiter haben, der aber bei einem externen Dienstleister ein weiteres Postfach betreibt. So könnte das externe Postfach z.B.: für die Arbeit in einer anderen Firma sein oder z.B. das Konto, welches mobil (Blackberry, ActiveSync o.ä.) abgefragt wird.
Damit diese Lösungen aber funktionieren, müssen Sie natürlich sicherstellen, dass die Mails tatsächlich an diese externen Mailserver gehen. Dazu richten Sie am besten einen Internet Mail Connector ein, welcher nur ihren eigenen Adressraum bedient und direkt an die gewünschten Server zustellt. Eine Zustellung über eine DNS-Auflösung wird die Mail sonst vermutlich direkt zu ihnen zurück senden.
Routing, DNS und DNS-Hostname
Eine weitere Tücke im Detail verbirgt der DNS-Hostname, welchen Sie im virtuellen SMTP-Server pflegen können. Viele Administratoren verändern diesen Namen, weil Sie z.B.: möchten, dass sich Exchange bei der Kommunikation mit dem Internet per SMTP nicht mit ihrem "echten" Namen melden. Allerdings hat diese Einstellung noch weitere Auswirkungen.
Das Problem tritt nicht bei Umgebungen mit nur genau einem Server aus, sondern nur wenn mehrere Server miteinander kommunizieren und der geänderte Name intern nicht eindeutig auf den gleichen Server verweist
Ein falscher Name kann nämlich das interne Exchange Routing komplett stören. Microsoft hat nicht umsonst den Button "DNS überprüfen" an diese Stelle hinzugefügt.
Leider wird dabei gerne übersehen, dass diese Änderung nicht nur in der METABASE des SMTP-Servers hinterlegt wird, sondern auch in der Exchange Konfiguration, wie man mit ADSIEDIT leicht auslesen kann.
Das entsprechende Feld lautet "msExchSmtpFullyQualifiedDomainName". Und auch in WinRoute wird der FQDN mit aufgeführt.
Damit sollten Sie erkennen, dass dieser Hostname für das Exchange Routing essentiell wichtig ist. Die Informationen in der Exchange Konfiguration werden von der Exchange Routingengine ausgewertet und auch auch für die interne Mailzustellung verwendet.
Sie können sich nun natürlich denken, was bei einer Änderung dieses Namens so alles passieren kann.
- Nur Extern auflösbar
Wird hier nun ein Name verwendet, der von extern aber nicht von intern auflösbar ist, so kann dieser Server keine Mails mehr erhalten, da alle anderen Server in der gleichen Routinggruppe den falschen Server erreichen. - Namen verweist auf externes System
Schlimmer kann es noch sein, wenn der Name zwar intern auflösbar ist, aber zu einem anderen System (z.B.: einem Relay) weist oder durch eine Firewall woanders hin geroutet wird. - Namen und NLB
Wenn Sie mehrere Connectorserver betreiben und diese z.B.: auch Frontend Server für OWA sind, dann ist die Wahrscheinlichkeit hoch, das diese Server über ein NLB-Cluster zusammen geschaltet sind. Das kann es im schlimmsten Fall dazu führen, dass beide in der Exchange Konfiguration den gleichen Hostnamen haben, die internen Server eine Weg "nach draußen" an diesen Hostnamen senden und der Server letztlich die "falsche" Gegenstelle erreicht. Der falsche Connectorserver wird dann jedoch davon ausgehen, dass sie eine Schleife konfiguriert haben und die Mail löschen und einen NDR erstellen.
Leider ist diesem Verhalten auch nicht so einfach durch einen zweiten virtuellen SMTP-Server beizukommen, der z.B. auf einer eigenen IP-Adresse lauscht und für den ausgehenden SMTP-Connector konfiguriert wird. Denn intern sind dann beide Server Bestandteil der Routinggruppe.
Unterm Strich bedeutet dies: "Finger weg" von diesem Namen. Sorgen Sie dafür, dass der Name wirklich dem Hostnamen entspricht und eindeutig ist. Wenn Sie aber nach extern von von extern ihre Nachrichten senden und empfangen und dabei z.B. eine abweichende SMTP-Meldung haben wollen, dann fahren Sie am besten mit einem Relay zwischen Exchange und Internet.
Wenn Sie den Eintrag im virtuellen SMTP-Server ändern, dann kann es sein, dass Exchange diese Änderung nicht im Routing übernimmt (Kontrolle mit Winroute). Meist hilft es dann, z.B.: im SMTP-Connector einfach einen Wert zu ändern und wieder zurück zu ändern, so dass man einmal "übernehmen" sagen kann. Soe ein Änderung triggert die Routingengine an, die Daten neu einzulesen. (Kontrolle mit Winroute)
Rerouting
Keine Konfiguration ist für immer statisch und so stehen Sie als Administrator irgendwann einmal vor der Aufgabe, das Mailrouting zu ändern. Sie müssen als Connectoren addieren und entfernen, Dienste durchstarten etc. Da fragt man sich dann doch mal, was Exchange hier im Detail macht, wenn Sie z.B. einen Routinggroup Connector löschen, in dessen Warteschlange noch Nachrichten stehen. Werden diese Mails gelöscht, als unzustellbar zurückgewiesen oder gar neu einsortiert ?.
Hierzu müssen sie nur ganz wenige Fakten wissen:
- Änderungen "on the fly"
Alle Änderungen am Exchange 2000/2003 Routing erfolgen zeitnah aber nicht immer "sofort". Ein Neustart von Diensten ist meist nicht erforderlich allerdings nutzen einige Komponenten einen "Cache", so dass einige Änderungen auch mal ein paar Minuten oder wenige Stunden dauern können. Bedenken Sie aber, dass Einstellungen in der Konfigurationspartition des Active Directory abgelegt werden und diese auf alle Domaincontroller im gesamten Forest zu replizieren sind. Das kann bei größeren Umgebungen und besonders bei Sitelinks mit Zeitplänen etwas dauern. Erst dann kann der lokale Exchange die Daten auslesen und übernehmen. - Löschen = Rerouting
Wenn Sie einen Connector löschen, dann werden die Mails, die noch in dessen Warteschlange liegen, nicht verworfen, sondern wieder in die Warteschlange "Warten auf Routing" zurückgestellt und anhand der aktuellen Konfiguration weiter geroutet.
Tipp:
Richten Sie erst die neuen Connectoren ein und erhöhen Sie dann die Kosten
der Connectoren, die sie demnächst entfernen wollen oder halten Sie diese
Warteschlange an. (Fixieren). Wenn ihr Routing korrekt ist, dann sollte in
der alten Wartenschlange keine Mail "stecken" bleiben
Unterstützung durch
Net at
Work:
Gerade in größeren Umgebungen kann eine Umstellung etwas Zeit bedeuten und nicht jeder kann auf allen Servern alle Warteschlangen überwachen. Wenn
Sie keine Hilfsmittel wie
MOM2005 o.ä.
einsetzen, dann könnten wir Sie mit
QStatus
während der Umstellung unterstützen.
- Alte Konnectoren verschwinden im AD aber nicht in WinRoute
Wenn Sie einen Connector in der Konfiguration löschen, dann wird dieser nach einiger Zeit in der gesamten Organisation nicht mehr genutzt. Allerdings "vergisst" Exchange den alten Connector nicht mehr. Die Routingengine pflegt eine eigene Liste, die nur im Hauptspeicher gehalten wird, aus dem Active Directory befüllt wird und sich mit anderen Server abgleicht ( Siehe auch Link State unter Routing2000). Dieses kollektive Wissen aller Exchange Server können Sie nur durch einen zeitgleichen Neustart aller Exchange Routingdienste leeren. Es handelt sich aber nur um einen kosmetischen Effekt. Die Idee dahinter ist, dass Exchange über LinkState von anderen Exchange Servern schnelle die Leitwege lernen kann, als diese über eine Replikation der Konfiguration stattfindet.
Insofern ist es also kein Problem, das Routing im laufen Betrieb zu ändern. Allerdings bietet es sich an, zuerst die neuen Wege zu konfigurieren und deren Nutzung zu prüfen und dann die alten Wege zu entfernen. Auch eine Überwachung der Warteschlangen ist angeraten.
Der Weg durchs System
Zuletzt möchte ich noch ein paar Details zur internen Verarbeitung beim Routing aufführen, die für das Verständnis sehr hilfreich sein können.
Ausgehende Nachrichten
Wird eine Mail von einem Exchange Postfach zu einem anderen Exchange Postfach, einem externen Mailsystem (z.B. Internet) oder einem Connector (z.B. Notes) versendet, dann passiert folgendes:
- Store bekommt Mail mit Empfängerliste
Outlook legt also die Mail in den Postausgang ihrer Mailbox ab. Das Mailobjekt enthält eine Liste aller Zielempfänger - Store Driver -> Advanced Queuing component
Die Mail wird dann vom Store zum Queueing des virtuellen SMTP-Servers übergeben und dort in die Warteschlange "pre-categorization queue" eingestellt - Kategorisierung
Der "Categorizer" ist nun bemüht, die Empfänger als auch den Absender im Active Directory aufzulösen und Verteiler in einzelne Empfänger zu zerlegen. - Routing
Abhängig vom Ziel wird die Mail nun je Empfänger weiter verteilt:
Lokale Empfänger: Mail geht zum Informationsstore, welcher diese lokal zustellt. Der Prozess ist beendet
Entfernte Empfänger: Ablage in der Warteschlange "post-categorization queue" - Routing Engine
Alle Mails, die den Server verlassen müssen, werden von der Routing Engine nun abgeholt und anhand der Zieladresse weiter geleitet:
Andere Exchange Server in der Organisation: Weitergabe per SMTP
Fremde Connectoren: Mail wird an den den Server für dieses Gateway übertragen und dort dann an den MTA übermittelt. Dieses Gateway muss die Mail aus dem ordner "MTS-OUT" abholen, übersetzen und zustellen. Wenn das Gateway nicht läuft, dann wird der MTA weiterhin Mails in diese Warteschlange senden. Überwachen Sie daher diese Mailbox, damit Sie Störungen schnell erkennen.
Ein Versucht, die auch visuell darzustellen, ist folgendes Bild:
Winroute
Winroute ist ein Tool auf der Exchange 2000 bzw. Service Pack CD im jeweiligen Support unterverzeichnis -siehe WINROUTE
Weitere Links
-
Internet Mail Connector
200x
Wann erkennt SMTP, dass ein Connector "Down" ist ? - WINROUTE
- RG-Connector
- Routing2000
- Routing2007
- Routinggruppen
- Exchange 2000 ResKit - Enterprise Deployment Guide - Chapter 16 Routing
- Q233208 XCON: Port used by Routing Service (RESVC)
- Q238614 XCON: How to Set up Regtrace für Exchange 2000
- Q253193 XCON: Exchange 2000 Transport Core Top Support Issues
- Q257265 XCON: General Troubleshooting für Exchange 2000 Transport Issues
- Q257638 XCON: Locally Scoped Connectors Not Allowed in Mixed Environment
- Q260995 XCON: Definitions of Key Transport Components in Exchange 2000 Server
- Q261103 XCON: Exchange Server 5.5 & Exchange 2000 Server MTA Comparison
- Q263249 XCON: Link State Routing in Exchange 2000 Server
- Q264054 XCON: understanding Queue States in Exchange 2000 Server
- Q264270 XCON: Exchange 2000 Server Queues Display and Troubleshooting
- Q264273 XCON: Managing Connections in Exch 2K & Link States Definitions
- Q267992 XADM: How to Configure a Routing Group Connector
- Q271930 Message Delivery to Global Groups Does Not Work
- Q275596 XADM: MAPI Messages Stack up in Send Queue to the Host Specified in Forward unresolved Recipients
- Q278838 XCON: Cannot Send Mail to SMTP Domain That Is the Same as the Local Exchange Organization Domain
- Q280794 XIMS: Message Cannot Be Sent to Domains with MX Record Pointing
- Q281382 XCON: How to use the WinRoute Tool
- Q281761 XCON: Attributes Required to Route Messages Through the Categorizer
- Q281800 XCON: Troubleshooting Message Failures in Exchange 2000
- Q284204 XCON: Delivery Status Notifications in Exchange 2000 Server
- Q285130 XCON: Link State Database Information
- Q300129 XADM: How to Establish Mail Flow and Directory Replication Between Exchange Server 5.5 and Exchange 2000
- ms-help://MS.TechNet.2006JUN.1033/exchange/tnoffline/prodtechnol/exchange/exchange2003/proddocs/library/trguide/e2k3rt05.htm