Grundlegendes zum Nachrichtenrouting

 

Gilt für: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Letztes Änderungsdatum des Themas: 2016-11-28

Die Hauptaufgabe von Hub-Transport- und Edge-Transport-Servern in Ihrer Organisation besteht im Routing (d. h. im Weiterleiten) von Nachrichten, die von Benutzern und externen Quellen empfangen werden, an ihre endgültigen Bestimmungsorte. In diesem Thema wird erläutert, wie das Routing von Nachrichten durch Microsoft Exchange Server 2010 in Ihrer Organisation erfolgt.

Möchten Sie wissen, welche Verwaltungsaufgaben es im Zusammenhang mit Transportservern gibt? Weitere Informationen finden Sie hier: Verwalten von Transportservern.

Inhalt

Übersicht über das Nachrichtenrouting in Exchange 2010

Routingkomponenten

Routing mithilfe von Active Directory-Standorten

Exchange 2010-Routingtabellen

Empfangen von Nachrichten für das Routing

Nachrichtenrouting

Erneutes Routing und die Nicht-erreichbar-Warteschlange

Übersicht über das Nachrichtenrouting in Exchange 2010

Routingentscheidungen werden während der Nachrichtenkategorisierung getroffen. Das Kategorisierungsmodul ist eine Komponente des Microsoft Exchange-Transportdiensts, die alle eingehenden Nachrichten verarbeitet und basierend auf Informationen zu den vorgesehenen Empfängern bestimmt, was mit den Nachrichten geschehen soll. Das Kategorisierungsmodul verarbeitet Nachrichten in mehreren voneinander abhängigen Phasen und verwendet auch andere Komponenten des MicrosoftExchange-Transportdiensts während der Nachrichtenverarbeitung. Nachdem eine Nachricht von einem Exchange 2010-Transportserver empfangen wurde und die vorbereitende Verarbeitung bis zum Abschluss des SMTP-Empfangs durchgeführt wurde, wird die Nachricht der Übermittlungswarteschlange zugestellt. Nachrichten durchlaufen das Kategorisierungsmodul aus der Übermittlungswarteschlange in den folgenden Phasen:

1. **Agent-Verarbeitung übermittelter Nachrichten   **Agent-Verarbeitung auf dem Hub-Transport-Server findet statt, wenn die Nachricht für die Kategorisierung empfangen wird. Die Agents, die in dieser Phase angewendet werden, sind z. B. der optionale Antivirus-Agent von Microsoft Forefront Protection für Exchange Server sowie der Journal-Agent.

2. **Empfängerauflösung   **Während dieser Phase wird die E-Mail-Adresse des Empfängers aufgelöst, um zu bestimmen, ob der Empfänger ein Postfach in der Exchange-Organisation oder eine externe E-Mail-Adresse besitzt.

3. **Routing   **Nachdem die Informationen zum Empfänger aufgelöst wurden, ermittelt die Routingkomponente des Kategorisierungsmoduls das Endziel für die Nachricht sowie die Route zu diesem Ziel, wählt das nächste Segment oder den Hop für das Nachrichtenrelay aus und löst die Informationen zum nächsten Hop in eine Liste physischer Server und IP-Adressen auf.

4. Inhaltskonvertierung   Bevor eine Nachricht mittels Relay an den nächsten Hop weitergeleitet wird, findet die Inhaltskonvertierung statt, damit die Nachricht in einem für den Empfänger lesbaren Format gesendet wird. Die Inhaltskonvertierung wandelt aus Gründen der Nachrichtenübermittlung oder der Speicherung E-Mail-Nachrichten aus einem Format in ein anderes Format um, z. B. MAPI in MIME oder die UUENCODE-Codierung in die Base64-Codierung. Die Konvertierung kann auch zum Zweck einer geeigneten, E-Mail-Client-spezifischen Wiedergabe erfolgen, wie z. B. HTML, RTF oder Nur-Text.

5. Agent-Verarbeitung weitergeleiteter Nachrichten   Nachdem die Routingentscheidungen für eine bestimmte Nachricht getroffen wurden, werden der Agent für Transportregeln und der Journal-Agent auf dem Hub-Transport-Server angewendet. Der Journal-Agent wird bei der Übermittlung der Nachricht und beim Routing angewendet, damit alle Änderungen, die vom Agent für Transportregeln an der Nachricht vorgenommen werden (z. B. die Änderung einer Zustelladresse oder die Anwendung einer nachrichtenspezifischen Journalanforderung), dem Journal-Agent nicht entgehen.

6. Nachrichtenverpackung und DSN-Generierung   Die endgültige, kategorisierte Nachricht wird zusammengestellt und in eine Zustellungswarteschlange verschoben. Eine Benachrichtigung über den Zustellungsstatus (DSN) wird während dieser Phase ggf. ebenfalls generiert.

Anschließend werden die Nachrichten von SMTP Send, dem Informationsspeichertreiber, Zustellungs-Agents oder dem Verbindungshandler für das fremde Gateway verarbeitet. Die verwendete Komponente hängt vom Endziel ab. Eine Zustellungswarteschlange wird für jeden Hop dynamisch generiert. Die Nachrichten werden nach der Routingentscheidung in diese Zustellungswarteschlangen eingereiht. Wird eine Route für einen Empfänger nicht gefunden, werden die Nachrichten in die Nicht-erreichbar-Warteschlange verschoben.

Die folgende Abbildung zeigt die Nachrichtenverarbeitung in den verschiedenen Routingphasen sowie das Einreihen der Nachrichten für die Zustellung an das nächste Hopziel.

Routingkontext bei der Nachrichtenübermittlung

Zurück zum Seitenanfang

Routingkomponenten

Für Routingentscheidungen muss Exchange 2010 auf Konfigurationsinformationen zugreifen, die in Active Directory gespeichert sind. Auf einem Edge-Transport-Server werden Konfigurationsinformationen in der AD LDS-Instanz (Active Directory Lightweight Directory Services) auf dem lokalen Server gespeichert und sind von dort aus zugänglich. MicrosoftWindows- und Exchange 2010-Dienste arbeiten bei der Erstellung von Zuordnungen der Konfigurationsdaten zusammen. Diese Zuordnungen werden in Routingtabellen zwischengespeichert. Exchange 2010 verweist auf diese Tabellen beim Treffen von Routingentscheidungen. Der Cache wird aktualisiert, wenn sich die Routingtopologie ändert. Die Exchange-Dienste, die während des Nachrichtentransports verwendet werden, sind für die Hub-Transport- und die Edge-Transport-Serverrolle gleich. Bei der Edge-Transport-Serverrolle erfolgt jedoch keine Zwischenspeicherung der Informationen zur Active Directory-Topologie.

Die folgende Konfiguration und die folgenden Dienstkomponenten sind für das Nachrichtenrouting wichtig:

• Active Directory-Standorte   Ein Active Directory-Standort stellt die Routinggrenze für Hub-Transport-Server dar. Ein Hub-Transport-Server stellt Postfachservern, Servern für die Aufgliederung von Verteilergruppen und Quellservern für Connectors am lokalen Active Directory-Standort sowie Edge-Transport-Servern, die diesen Standort abonniert haben, Nachrichten direkt zu. Ein Hub-Transport-Server muss jedoch Nachrichten mittels Relay an einen anderen Hub-Transport-Server für Empfänger, Server für die Aufgliederung von Verteilergruppen und Connectors weiterleiten, die sich an Active Directory-Remotestandorten befinden. Die Hub-Transport-Serverrolle muss an jedem Active Directory-Standort bereitgestellt werden, der andere Exchange 2010-Serverrollen enthält.

• Active Directory-IP-Standortverknüpfungen   Active Directory Durch IP-Standortverknüpfungen werden logische Pfade zwischen Active Directory-Standorten definiert. Exchange 2010 verweist auf die IP-Standortverknüpfungsobjekte, um den kostengünstigsten Routingpfad von Remote-Active Directory-Standorten zu ermitteln.

• Sendeconnectors   Sendeconnectors werden zum Senden von Nachrichten an andere SMTP-Hosts verwendet. Die Adressraumkonfiguration auf Sendeconnectors wird für Routingentscheidungen verwendet. Wenn eine Nachricht einer externen Domäne zugestellt wird, ist das Routingziel normalerweise ein Sendeconnector. Eine Exchange-Organisation, die Nachrichten für mehrere E-Mail-Domänen akzeptiert, kann Sendeconnectors erstellen, die für die einzelnen Adressräume reserviert sind. Weitere Informationen zur Auswahl von Sendeconnectors für das Weiterleiten von Nachrichten an externe Domänen finden Sie unter Externes Nachrichtenrouting.

• Zustellungs-Agents   Zustellungs-Agents werden zum Weiterleiten von Nachrichten an Fremdsysteme genutzt, in denen für die Nachrichtenübermittlung kein SMTP-Protokoll verwendet wird. Die Adressraum- und Protokollkonfiguration von Zustellungs-Agents wird für Routingentscheidungen verwendet.

• Fremdconnectors   Fremdconnectors verwenden Ablageverzeichnisse zum Senden von Nachrichten an Fremdsysteme, in denen für die Nachrichtenübermittlung kein SMTP-Protokoll verwendet wird. Exchange verwendet die Konfiguration von Fremdconnectors für Routingentscheidungen.

• Routinggruppen   Routinggruppen stellen eine Routinggrenze für Exchange Server 2003 dar. Wenn Exchange 2010 in einer vorhandenen Exchange 2003-Organisation bereitgestellt wird, muss das Routing den Standort von Servern in Routinggruppen berücksichtigen, um eine Nachricht einem Postfach oder einem Connector zuzustellen, das bzw. der Exchange 2003 verwendet. Um Kompatibilität mit Exchange 2003 zu implementieren, gehören alle in der Organisation bereitgestellten Computer, auf denen Exchange 2010 ausgeführt wird, zu einer einzigen, globalen Routinggruppe.

• Routinggruppenconnectors   Routinggruppenconnectors definieren logische Pfade zwischen Exchange-Routinggruppen. Wenn Exchange 2010 in einer vorhandenen Exchange 2003-Organisation bereitgestellt wird, werden Nachrichten zwischen Serverversionen durch Routinggruppenconnectors weitergeleitet. Wenn der erste Hub-Transport-Server bereitgestellt wird, werden Sie vom Installationsprozess aufgefordert, einen Routinggruppenconnector von der globalen Exchange 2010-Routinggruppe zu einer Legacyroutinggruppe zu erstellen. Weitere Informationen zum Nachrichtenrouting in einer Umgebung, in der mehrere Versionen von Exchange bereitgestellt sind, finden Sie unter Internes Nachrichtenrouting.

• Microsoft Exchange-Transportdienst   Der MicrosoftExchange-Transportdienst ist der SMTP-Anbieter für Exchange 2010 und steuert alle Komponenten der Nachrichtenverarbeitung von SMTP IN bis zu SMTP OUT. Eine Reihe konfigurierbarer SMTP-Empfangs-Agents werden von verschiedenen SMTP-Ereignissen ausgelöst. Der MicrosoftExchange-Transportdienst ermöglicht diesen Agents die Verarbeitung der Nachrichten, wenn sie den SMTP-Transport durchlaufen. Dabei werden Antispam-, Antiviren- und weitere Tasks ausgeführt, bevor die Nachrichten an das Kategorisierungsmodul übermittelt werden. Der MicrosoftExchange-Transportdienst verwendet außerdem das Topologieerkennungsmodul für die Exchange-Topologieerkennung.

• Microsoft Exchange Active Directory-Topologiedienst   Der MicrosoftExchangeActive Directory-Topologiedienst ist für das Ermitteln der Domänencontroller und globalen Katalogserver verantwortlich, die Exchange 2010 zum Abrufen von Konfigurations- und Empfängerdaten aus Active Directory verwenden kann. Der MicrosoftExchangeActive Directory-Topologiedienst ist außerdem dafür verantwortlich, die Active Directory-Standortaffinität für einen Servercomputer mit Exchange 2010 aktuell zu halten.

• Routingtabellen   Die Routingtabellen enthalten die Informationen, die die Routingkomponente verwendet, um Routingentscheidungen zu treffen. Die Routingtabelle besteht aus einer Zuordnung der Topologiekomponenten und ihrer Beziehungen zueinander.

• DNS Exchange 2010 verwendet einen erweiterten DNS-Client (Domain Name System), eine Komponente des MicrosoftExchange-Transportdiensts, um die Auswahl der nächsten Hops in eine Liste von Zielservernamen aufzulösen. Der Standard-DNS-Client wird zum Auflösen dieser Liste von Servernamen in IP-Adressen verwendet. Erweitertes DNS stellt außerdem eine Lastenausgleichsfunktion für Exchange 2010-Transportserver über Roundrobin bereit.

• SMTP SMTP wird für die Kommunikation verwendet, wenn Nachrichten mittels Relay zwischen SMTP-Servern weitergeleitet werden. Ein SMTP-Server kann ein Hub-Transport-Server, ein Edge-Transport-Server, ein Servercomputer mit Exchange 2003 oder ein Smarthost sein. Ein Hub-Transport-Server verwendet RPCs (Remote Procedure Calls, Remoteprozeduraufrufe), um Nachrichten an Postfachserver zuzustellen, die die gleiche Active Directory-Standortmitgliedschaft wie der Hub-Transport-Server aufweisen.

Zurück zum Seitenanfang

Routing mithilfe von Active Directory-Standorten

Ein Active Directory-Standort ist eine logische Konfigurationskomponente, die auf den physischen Aspekten des Netzwerks basiert. Der Hauptzweck, dem die Erstellung eines Active Directory-Standorts dient, besteht in der Definition, welche Subnetze im Netzwerk so verbunden sind, dass die Steuerung des Active Directory-Replikationsverkehrs optimiert wird. Der Active Directory-Standort stellt eine Routinggrenze für Exchange 2010 dar. Computer, auf denen die Hub-Transport-Serverrolle installiert ist, treffen Routingentscheidungen basierend auf der Active Directory-Standorttopologie.

Bestimmen der Standortmitgliedschaft

Standardmäßig enthält eine Active Directory-Gesamtstruktur nur einen Active Directory-Standort. Der Standardname für diesen Active Directory-Standort lautet "Default-First-Site-Name". Wenn keine weiteren Active Directory-Standorte erstellt werden, sind alle Domänenmitgliedscomputer in der Gesamtstruktur Mitglieder von "Default-First-Site-Name". Sie müssen keine Zuordnung zwischen Subnetz und Standort konfigurieren. Wenn zusätzliche Active Directory-Standorte erstellt werden, müssen Sie die Subnetze angeben, die dem betreffenden Active Directory-Standort zugeordnet sind.

Jeder Active Directory-Standort ist mindestens einem IP-Subnetz zugeordnet. Ein Administrator weist die Active Directory-Standortmitgliedschaft Computern zu, die als Domänencontroller und globale Katalogserver konfiguriert sind. Anderen Domänenmitgliedscomputern, z. B. Servercomputern mit Exchange, wird die Active Directory-Standortmitgliedschaft automatisch zugewiesen, wenn sie für die Verwendung einer IP-Adresse konfiguriert werden, die sich in einem IP-Subnetz befindet, das einem Active Directory-Standort zugeordnet ist. Bei Computern, die die gleiche Active Directory-Standortmitgliedschaft besitzen, wird davon ausgegangen, dass sie über eine gute Netzwerkverbindung verfügen. Ein Server ist immer Mitglied eines einzelnen Active Directory-Standorts.

Wenn eine Anwendung die Active Directory-Standortmitgliedschaft des Computers, auf dem sie installiert ist, sowie anderer Computer in der Gesamtstruktur bestimmen und diese Informationen zum Steuern des Kommunikationsflusses verwenden kann, handelt es sich um eine standortaktivierte Anwendung. Wenn standortaktivierte Anwendungen die Dienste eines anderen Servers verwenden müssen, z. B. eines Domänencontrollers oder eines globalen Katalogservers, erhalten die Server mit der gleichen Active Directory-Standortmitgliedschaft wie der Computer, der diese Dienste anfordert, Priorität.

Exchange 2010 ist eine standortaktivierte Anwendung und verwendet die Active Directory-Topologie für das Nachrichtenrouting und die Kommunikation mit den Diensten, die auf Computern ausgeführt werden, auf denen andere Exchange 2010-Serverrollen installiert sind. Der Active Directory-Standort stellt nicht nur die Routinggrenze, sondern auch die Diensterkennungsgrenze dar.

Die Bestimmung der Standortmitgliedschaft für einen Domänenmitgliedscomputer hängt von einer Reihe von DNS-Abfragen ab, um die lokale IP-Adresse mit definierten Untermengen zu vergleichen und dann die entsprechende Standortmitgliedschaftszuordnung zu ermitteln. Um den Mehraufwand zu verringern, der mit DNS-Abfragen verbunden ist, enthalten die Exchange 2010Active Directory-Schemaerweiterungen das Attribut msExchServerSite für das Exchange-Serverobjekt. Der Wert dieses Attributs ist der DN (Distinguished Name) des Active Directory-Standorts eines Servercomputers mit Exchange. Dieses Attribut ist eine Eigenschaft jedes Exchange-Serverobjekts. Wenn die Standortmitgliedschaftsaffinität als ein Attribut des Serverobjekts gespeichert wird, kann die aktuelle Topologie direkt aus Active Directory gelesen werden, anstatt DNS-Abfragen verwenden zu müssen, und eine Standortmitgliedschaftszuordnung wird für einen Nicht-Domänencomputer aktiviert, z. B. für einen abonnierten Edge-Transport-Server.

Der Wert für das Attribut msExchServerSite wird vom Microsoft ExchangeActive Directory-Topologiedienst mit Daten aufgefüllt und aktuell gehalten. Wenn ein Windows-basierter Computer gestartet wird, bestimmt der Netzwerkanmeldungsdienst die Standortmitgliedschaft für den Computer. Der Netzwerkanmeldungsdienst verwendet diese Informationen, um Domänencontroller zu ermitteln, die sich am gleichen Active Directory-Standort wie der lokale Computer befinden, und leitet dann Autorisierungs- und Authentifizierungsanforderungen an diese Server um. Der MicrosoftExchangeActive Directory-Topologiedienst verwendet den API-Aufruf "DsGetSiteName" zum Abrufen des Werts der Standortmitgliedschaft aus dem Netzwerkanmeldungsdienst und schreibt den Distinguished Name des Active Directory-Standorts in das Attribut msExchServerSite für das Exchange-Serverobjekt in Active Directory.

Die folgende Tabelle zeigt, wie eine Organisation Active Directory-Standorte definieren kann. In diesem Beispiel werden drei Active Directory-Standorte definiert, und jedem Active Directory-Standort sind mehrere IP-Subnetze zugeordnet.

Beispiel für die Zuordnung eines Active Directory-Standorts zu Subnetzen

Name des Active Directory-Standorts	Zugeordnete IP-Subnetze
Standort A	192.168.1.0/24 192.168.2.0/24
Standort B	192.168.3.0/24 192.168.4.0/24
Standort C	192.168.5.0/24 192.168.6.0/24

Wenn der Server "HubTransportA" die IP-Adresse 192.168.1.1 hat, ist er Mitglied von Standort A. Durch Ändern der IP-Adresse eines Servers wird ggf. auch seine Standortmitgliedschaft geändert. Wenn Sie die IP-Adresse von "HubTransportA" in 192.168.2.1 ändern, ändert dies die Active Directory-Standortmitgliedschaft des Servers nicht, weil dieses Subnetz ebenfalls Standort A zugeordnet ist. Wenn Sie den Server jedoch verschieben, und die IP-Adresse ändert sich in 192.168.3.1, wird der Server als Mitglied von Standort B betrachtet.

Eine Änderung der Standortmitgliedschaft kann auch auftreten, wenn Sie die Zuordnung der Subnetze zu Active Directory-Standorten ändern. Wenn Sie z. B. das Subnetz 192.168.3.0 aus der Zuordnung zu Standort B entfernen und dann Standort A zuordnen, ändert sich auch die Standortmitgliedschaft eines Servers mit der IP-Adresse 192.168.3.1 in Standort A. Bei jeder Änderung einer Standortmitgliedschaft muss Exchange 2010 die Konfigurationsdaten aktualisieren, damit die Änderung berücksichtigt wird, wenn Exchange 2010 Routingentscheidungen trifft. Es entsteht eine Wartezeit zwischen dem Zeitpunkt, zu dem eine Änderung in einer Active Directory-Standortmitgliedschaft stattfindet, und dem Zeitpunkt, zu dem die Topologieänderung vollständig übermittelt ist. Die folgende Kommunikation muss in der angegebenen Reihenfolge stattfinden, um Topologieänderungen zu übermitteln:

1. Die Änderung der Standortmitgliedschaft wird auf einen Domänencontroller geschrieben. Die aktualisierten Informationen werden zwischen den Domänencontrollern an jedem Active Directory-Standort in der Gesamtstruktur repliziert. Die Zeitspanne, die erforderlich ist, bis die Änderung in der Gesamtstruktur vollständig übermittelt wurde, hängt von der durch Standortverknüpfungen definierten Active Directory-Replikationstopologie und dem -zeitplan ab.

2. Der Netzwerkanmeldungsdienst wird auf allen Windows-basierten Computern ausgeführt und fragt regelmäßig Änderungen in der Active Directory-Standortmitgliedschaft ab. Der Netzwerkanmeldungsdienst führt diese Abfrage alle fünf Minuten durch. Aus diesem Grund wird die Änderung vom Netzwerkanmeldungsdienst innerhalb von fünf Minuten erkannt, nachdem der lokale Domänencontroller das Update empfangen hat.

3. Der MicrosoftExchangeActive Directory-Topologiedienst fragt den Netzwerkanmeldungsdienst in Intervallen von 15 Minuten ab, um die Active Directory-Standortmitgliedschaft des lokalen Servercomputers mit Exchange zu bestimmen. Wenn eine Änderung erkannt wird, aktualisiert der MicrosoftExchangeActive Directory-Topologiedienst das Attribut MsExchServerSite.

4. Der geänderte Wert des Standortattributs des Exchange-Serverkonfigurationsobjekts wird dann in die gesamte Organisation repliziert. Die Servercomputer mit Exchange in der Organisation erkennen diese Änderung. Anschließend werden die Routingtabellen mit dem neuen Wert des Attributs für die Active Directory-Standortmitgliedschaft aktualisiert.

Es entstehen Wartezeiten zwischen dem Zeitpunkt, an dem eine Änderung der Active Directory-Standortmitgliedschaft wirksam wird, und dem Zeitpunkt, an dem die aktualisierten Informationen für einen anderen Exchange 2010-Server verfügbar sind. Weitere Informationen dazu, wie Exchange 2010 diese Arten von Konfigurationsänderungen verarbeitet, finden Sie weiter unten in diesem Thema unter "Erneutes Routing und die Nicht-erreichbar-Warteschlange".

IP-Standortverknüpfungen

Standortverknüpfungen sind logische Pfade zwischen Active Directory-Standorten. Ein Standortverknüpfungsobjekt stellt eine Gruppe von Standorten dar, die zu einheitlichen Kosten über einen angegebenen Transportmechanismus zwischen den Standorten kommunizieren können. Standortverknüpfungen entsprechen nicht dem tatsächlichen Pfad, den Netzwerkpakete im physischen Netzwerk durchlaufen. Die der Standortverknüpfung durch den Administrator zugewiesenen Kosten stehen jedoch normalerweise mit der zugrunde liegenden Netzwerkzuverlässigkeit, der Geschwindigkeit und der verfügbaren Bandbreite in Zusammenhang. Der Active Directory-Administrator würde z. B. einer Netzwerkverbindung mit einer Geschwindigkeit von 100 Megabit pro Sekunde (MBit/s) niedrigere Kosten zuweisen als einer Netzwerkverbindung mit 10 MBit/s.

Standardmäßig sind alle Standortverknüpfungen transitiv. Dies bedeutet, dass Standort A transitiv mit Standort C verknüpft ist, wenn Standort A einen Link zu Standort B besitzt, und Standort B einen Link zu Standort C besitzt. Der transitive Link zwischen Standort A und Standort C wird auch als Standortverknüpfungsbrücke bezeichnet.

Eine Active Directory-Standortverknüpfung kann so konfiguriert werden, dass für die Kommunikation entweder IP oder SMTP als Transportprotokoll verwendet wird. Eine SMTP-Standortverknüpfung schränkt die Datentypen ein, die mithilfe des betreffenden Protokolls repliziert werden können, und stellt einen Speicherungs- und Weiterleitungsmechanismus für die Replikation zwischen Active Directory-Standorten bereit, die über keine zuverlässige Netzwerkverbindung verfügen. Eine IP-Standortverknüpfung schränkt die Datentypen nicht ein, die repliziert werden können. Exchange 2010 verwendet ausschließlich IP-Standortverknüpfungen, um die Routingtopologie zu bestimmen. Die Kosten, die der IP-Standortverknüpfung zugewiesen werden, werden von der Routingkomponente von Exchange 2010 beim Berechnen einer Routingtabelle berücksichtigt. Diese Kosten werden zum Berechnen des kostengünstigsten Routingpfads zum Endziel einer Nachricht verwendet.

Jedem Active Directory-Standort muss mindestens eine IP-Standortverknüpfung zugeordnet werden. Es ist eine IP-Standardstandortverknüpfung namens DEFAULTIPSITELINK verfügbar. Wenn Sie einen Active Directory-Standort erstellen, müssen Sie diesen Standort einer IP-Standortverknüpfung zuordnen. Sie können zusätzliche IP-Standortverknüpfungen erstellen, um die gewünschte Topologie zu implementieren, oder Sie können jeden Active Directory-Standort der Standardverknüpfung DEFAULTIPSITELINK zuordnen. Jeder Active Directory-Standort, der Teil einer IP-Standortverknüpfung ist, kann direkt mit jedem anderen Standort in dieser Verknüpfung zu einheitlichen Kosten kommunizieren.

In der folgenden Abbildung sind vier Active Directory-Standorte in der Gesamtstruktur konfiguriert. Jeder Standort wurde der Standardverknüpfung DEFAULTIPSITELINK zugeordnet. Daher kommuniziert jeder Active Directory-Standort direkt mithilfe der gleichen Kostenstruktur mit jedem anderen Standort. Es sind mehrere Kommunikationspfade angegeben, es ist jedoch nur eine IP-Standortverknüpfung definiert.

Vollständig vernetzte Topologie mit einer IP-Standortverknüpfung

In der folgenden Abbildung sind vier Active Directory-Standorte in der Gesamtstruktur konfiguriert. In dieser Topologie hat der Administrator IP-Standortverknüpfungen konfiguriert, um eine Hub-and-Spoke-Topologie der Active Directory-Standorte zu erstellen. Jeder Spokestandort kann direkt mit dem zentralen Standort kommunizieren, und die Spokestandorte können miteinander über transitive IP-Standortverknüpfungen kommunizieren.

Hub-and-Spoke-Topologie der Active Directory-IP-Standortverknüpfungen

Es muss beachtet werden, dass Exchange Standortverknüpfungen nur für die Bestimmung des kostengünstigsten Pfads verwendet, aber immer eine Zustellung von Nachrichten direkt an den Hub-Transport-Zielserver versucht. Wenn beispielsweise ein Benutzer an Standort B in der obigen Abbildung eine Nachricht an einen anderen Benutzer an Standort C sendet, stellt der Hub-Transport-Server an Standort B eine direkte Verbindung zum Hub-Transport-Server an Standort C her. Wenn erzwungen werden soll, dass Nachrichten über Standort A geleitet werden, müssen Sie diesen Standort als Hub-Standort aktivieren. Weitere Informationen zu Hub-Standorten finden Sie weiter unten unter "Implementieren von Hubstandorten".

Ein Active Directory-Administrator implementiert die Topologie, die am besten für die Verbindungs- und Kommunikationsanforderungen der Gesamtstruktur geeignet ist. Da die gleiche Topologie von Exchange 2010 verwendet wird, müssen Sie sicherstellen, das die aktuelle Topologie effiziente Messagingkommunikation unterstützt.

Die Standardkosten für eine Standortverknüpfung haben den Wert 100. Gültige Standortverknüpfungskosten werden durch einen beliebigen Wert zwischen 1 und 99.999 angegeben. Wenn Sie redundante Verknüpfungen angeben, wird die Verknüpfung mit den niedrigsten zugewiesenen Kosten stets bevorzugt. Ein Exchange-Organisationsadministrator kann einer IP-Standortverknüpfung Exchange-spezifische Kosten zuweisen. Wenn einer IP-Standortverknüpfung Exchange-Kosten zugewiesen wurden, werden diese von Exchange 2010 verwendet. Andernfalls werden die Active Directory-Kosten verwendet. Weitere Informationen zum Festlegen von Exchange-Kosten für eine IP-Standortverknüpfung finden Sie weiter unten in diesem Thema unter "Steuern der IP-Standortverknüpfungskosten". Ein Administrator, der Mitglied der Gruppe von Organisationsadministratoren ist, kann zusätzliche IP-Standortverknüpfungen erstellen.

Weitere Informationen zur Active Directory-Standortkonfiguration finden Sie unter Entwerfen der Standorttopologie.

Steuern der IP-Standortverknüpfungskosten

Active Directory-IP-Standortverknüpfungskosten beruhen auf der relativen Netzwerkgeschwindigkeit im Vergleich zu allen Netzwerkverbindungen im WAN und sollen für eine zuverlässige und effiziente Replikationstopologie sorgen. Daher sollten in den meisten Fällen die vorhandenen IP-Standortverknüpfungskosten für Exchange 2010-Nachrichtenrouting gut funktionieren. Wenn Sie nach Abschluss der Dokumentation des vorhandenen Active Directory-Standorts und der IP-Standortverknüpfungstopologie feststellen, dass die Active Directory-IP-Standortverknüpfungskosten und die Datenverkehrsmuster für Exchange 2010 nicht optimal sind, können Sie die von Exchange ermittelten Kosten anpassen. Eine Änderung der einer IP-Standortverknüpfung zugewiesenen Kosten mithilfe von Active Directory-Tools wirkt sich auf die gesamte Umgebung aus. Verwenden Sie stattdessen das Cmdlet Set-AdSiteLink in der Exchange-Verwaltungsshell, um dem IP-Standortlink Exchange-spezifische Kosten zuzuweisen. Um z. B. für die IP-Standortverknüpfung SITELINKAB zu Nachrichtenroutingzwecken andere Kosten festzulegen, führen Sie in der Shell den folgenden Befehl aus:

Set-AdSiteLink -Identity SITELINKAB -ExchangeCost 25

Wenn einer IP-Standortverknüpfung Exchange-Kosten zugewiesen sind, setzen die Exchange-Kosten die Active Directory-Kosten für Nachrichtenroutingzwecke außer Kraft, und das Routing berücksichtigt beim Ermitteln des kostengünstigsten Routingpfads nur die Exchange-Kosten.

Das Anpassen der IP-Standortverknüpfungskosten kann sinnvoll sein, wenn sich die Nachrichtenroutingtopologie von der Active Directory-Replikationstopologie unterscheiden muss. Die Exchange-Kosten können verwendet werden, um zu erzwingen, dass alle Nachrichtenrouten einen Hub-Standort verwenden. Über Exchange-Kosten kann auch gesteuert werden, wo Nachrichten in Warteschlangen gespeichert werden, wenn ein Kommunikationsfehler mit einem Active Directory-Standort auftritt. Die folgende Abbildung zeigt eine Active Directory-Topologie mit vier Standorten:

Topologie mit für IP-Standortverknüpfungen konfigurierten Exchange-Kosten

In der Abbildung oben hat die Netzwerkverbindung zwischen Standort C und Standort D eine geringe Bandbreite und wird nur für die Active Directory-Replikation verwendet. Sie sollte nicht für das Nachrichtenrouting eingesetzt werden. Aufgrund der Active Directory-IP-Standortverknüpfungskosten wird diese Verknüpfung jedoch in den kostengünstigsten Routingpfad von allen anderen Active Directory-Standorten zu Standort D einbezogen. Aus diesem Grund werden die Nachrichten an Standort C in die Warteschlange für den Standort D eingereiht. Der Exchange-Administrator zieht es vor, für den kostengünstigsten Routingpfad stattdessen Standort B zu berücksichtigen, damit die Nachrichten an Standort B in Warteschlangen gespeichert werden, wenn Standort D nicht verfügbar ist. Durch das Konfigurieren hoher Exchange-Kosten für die IP-Standortverknüpfung zwischen Standort C und Standort D wird verhindert, dass die IP-Standortverknüpfung in den kostengünstigsten Routingpfad zu Standort D einbezogen wird.

Exchange 2010 bietet Unterstützung für die Konfiguration einer maximalen Nachrichtengröße für eine Active Directory-IP-Standortverknüpfung. Standardmäßig wendet Exchange 2010 keine maximale Nachrichtengröße für Nachrichten an, die mittels Relay zwischen Hub-Transport-Servern an verschiedenen Active Directory-Standorten weitergeleitet werden. Wenn Sie mit dem Cmdlet Set-AdSiteLink eine maximale Nachrichtengröße für eine Active Directory-IP-Standortverknüpfung konfigurieren, wird beim Routing ein Unzustellbarkeitsbericht (NDR, Non-Delivery Report) für alle Nachrichten generiert, deren Größe die für die Active Directory-Standortverknüpfung auf dem kostengünstigsten Routingpfad konfigurierte, maximal zulässige Nachrichtengröße überschreitet. Diese Konfiguration ist nützlich, um die Größe von Nachrichten zu beschränken, die über Verbindungen mit niedriger Bandbreite an Active Directory-Remotestandorte gesendet werden. Weitere Informationen finden Sie unter Grundlegendes zu Größenbeschränkungen für Nachrichten.

Implementieren von Hubstandorten

In der Exchange-Organisation müssen Sie ggf. erzwingen, dass die gesamte Nachrichtenzustellung mittels Relay über einen speziellen Active Directory-Standort erfolgt. In diesem Szenario verhindert die Konnektivität ggf. das direkte SMTP-Relay zwischen Standorten. Daher müssen Nachrichten mittels Relay über einen Zwischenstandort geleitet werden, bevor sie an ihr Ziel gesendet werden. Aufgrund der internen Richtlinien einer Exchange-Organisation möchte der Administrator ggf. auch alle Nachrichten über einen bestimmten Standort weiterleiten. Mit den Cmdlets in der Shell können Sie einen Active Directory-Standort als Hub-Standort definieren. Indem Sie einen Active Directory-Standort als Hub-Standort festlegen, kann zusätzlicher Gesamtmehraufwand verursacht werden, weil eine größere Anzahl von Servern an der Nachrichtenzustellung beteiligt ist. Angenommen, eine Nachricht wird von Standort A an Standort E gesendet. Wenn der kostengünstigste Routingpfad "Standort A - Standort B - Standort C - Standort D - Standort E" lautet und Sie Standort C als Hub-Standort festlegen, wird die Nachricht mittels Relay von Standort A an Standort C geleitet und dann von Standort C an Standort E.

Mit dem Cmdlet Set-AdSite wird ein Active Directory-Standort als Hub-Standort definiert. Wenn entlang des kostengünstigsten Routingpfads für die Nachrichtenzustellung ein Hub-Standort vorhanden ist, werden die Nachrichten in einer Warteschlange gespeichert und dann von den Hub-Transport-Servern am Hub-Standort verarbeitet, bevor sie mittels Relay an ihr Endziel weitergeleitet werden.

Nachdem der kostengünstigste Routingpfad ausgewählt wurde, bestimmt das Routing, ob in diesem Routingpfad ein Hub-Standort vorhanden ist. Wenn ein Hub-Standort konfiguriert ist, werden die Nachrichten auf einem Hub-Transport-Server am Hub-Standort angehalten, bevor sie mittels Relay an das Ziel weitergeleitet werden. Wenn im kostengünstigsten Routingpfad mehrere Hub-Standorte vorhanden sind, werden die Nachrichten an jedem Hub-Standort im Routingpfad angehalten.

Diese Variante des direkten Relayroutings tritt nur in Kraft, wenn sich der Hub-Standort im kostengünstigsten Routingpfad befindet. Die folgende Abbildung zeigt die richtige Verwendung eines Hub-Standorts. In dieser Abbildung ist Standort B als Hub-Standort konfiguriert. Nachrichten, die von Standort A an Standort D weitergeleitet werden, werden mittels Relay an Standort B geleitet, bevor sie an Standort D zugestellt werden.

Nachrichtenzustellung mit Hub-Standort

Die folgende Abbildung zeigt, wie sich die Kosten für die IP-Standortverknüpfung auf das Routing an einen Hub-Standort auswirken. In diesem Szenario wurde Standort B als Hub-Standort festgelegt. Da er jedoch nicht entlang des kostengünstigsten Routingpfads zwischen anderen Standorten liegt, werden die Nachrichten nicht an Standort B in der Warteschlange eingereiht, bevor die Zustellung am Ziel erfolgt. Ein Active Directory-Standort wird nie als Hub-Standort verwendet, wenn er sich nicht im kostengünstigsten Routingpfad zwischen zwei anderen Standorten befindet.

Falsch konfigurierter Hub-Standort

Sie können jeden beliebigen Active Directory-Standort als Hub-Standort konfigurieren. Damit diese Konfiguration ordnungsgemäß funktioniert, muss jedoch bereits mindestens ein Hub-Transport-Server am Hub-Standort bereitgestellt worden sein.

Topologieerkennung

Die Exchange 2010-Topologie ist von der Active Directory-Standorttopologie abhängig und besitzt keine eigene Konfiguration. Die Active Directory-Topologie wird für Exchange 2010 durch die folgenden erforderlichen Elemente bereitgestellt:

• Den Microsoft ExchangeActive Directory-Topologiedienst

• Das Topologieerkennungsmodul im Microsoft Exchange-Transportdienst

Der Microsoft ExchangeActive Directory-Topologdienst wird auf allen Exchange 2010-Serverrollen ausgeführt, nur nicht auf der Edge-Transport-Serverrolle. Diese Exchange 2010-Server verwenden den Microsoft ExchangeActive Directory-Topologiedienst zum Ermittlen der Domänencontroller und globalen Katalogserver, die von den Exchange-Servern zum Lesen und Schreiben von Active Directory-Daten verwendet werden können. Exchange 2010 stellt eine Bindung mit den erkannten Verzeichnisservern her, wenn Exchange Daten aus Active Directory lesen oder in Active Directory schreiben muss.

Das Topologieerkennungsmodul ist Teil des Microsoft Exchange-Transportdiensts und stellt Informationen zur Active Directory-Topologie für Servercomputer mit Exchange bereit. Diese API erkennt die Servercomputer mit Exchange sowie die Serverrollen in der Organisation und ermittelt ihre Beziehung zu den Active Directory-Konfigurationsobjekten. Die Konfigurationsdaten werden aus Active Directory abgerufen und dann zwischengespeichert, damit die auf dem Computer ausgeführten Exchange-Dienste darauf zugreifen können.

Das Topologieerkennungsmodul führt die folgenden Schritte aus, eine Exchange-Routingtopologie zu generieren:

1. Daten werden aus Active Directory gelesen. Die folgenden Objekte werden abgerufen:

   • Active Directory-Standorte.

   • IP-Standortverknüpfungen.

   • Alle Servercomputer mit Exchange. Dies beinhaltet Informationen zu den Exchange 2010-Serverrollen, die auf diesen Servern bereitgestellt werden.

2. Die in Schritt 1 abgerufenen Daten werden zum Erstellen der anfänglichen Topologie und zum Verknüpfen und Zuordnen der zugehörigen Konfigurationsobjekte verwendet.

3. Exchange-Server werden Active Directory-Standorten durch Abrufen des Werts des Standortattributs aus dem Exchange-Serverobjekt zugeordnet, das in Active Directory gespeichert ist.

4. Routingtabellen werden mit der abgerufenen Informationssammlung aktualisiert.

Durch diesen Vorgang wird jeder Exchange 2010-Server für die anderen Exchange-Server in der Organisation aktiviert und über die Entfernung der Exchange-Server voneinander informiert.

Zurück zum Seitenanfang

Exchange 2010-Routingtabellen

Wenn der MicrosoftExchange-Transportdienst gestartet wird, berechnet er eine Sammlung von Routingtabellen, die auf der Momentaufnahme der Informationen basieren, die aus Active Directory (oder auf einem Edge-Transport-Server aus AD LDS) abgerufen werden. Die in AD LDS gespeicherten Konfigurationsinformationen beinhalten die verfügbaren Connectors und akzeptierten Domänen, nicht jedoch die Topologiedaten.

Die Routingkomponente ermittelt anhand der Routingtabellen, wie Nachrichten an Empfänger weitergeleitet werden. Wenn Konfigurationsänderungen vorgenommen werden, werden die Routingtabellen erneut erstellt. Die neuen Routingtabellen werden zum Weiterleiten neuer eingehender Nachrichten verwendet. Nachrichten in Remotezustellungswarteschlangen werden ebenfalls erneut weitergeleitet, wenn die Routingkomponente feststellt, dass diese von den Konfigurationsänderungen betroffen sind. Weitere Informationen zum erneuten Routing von Nachrichten finden Sie weiter unten in diesem Thema unter "Erneutes Routing und die Nicht-erreichbar-Warteschlange".

Die folgenden Konfigurationsdaten werden aus Active Directory abgerufen und der Routingkomponente von Hub-Transport-Servern zur Verfügung gestellt:

• Active Directory-Standorte

• Active Directory-IP-Standortverknüpfungen

• Servercomputer mit Exchange und ihre Beziehung zu Active Directory-Standorten

• SMTP-Connectors

• Nicht-SMTP-Connectors

  Hinweis

  Zu den Nicht-SMTP-Connectors gehören Exchange 2010-Zustellungs-Agent-Connectors, fremde Connectors und in Koexistenzszenarien alle von Exchange 2003 gehosteten Nicht-SMTP-Connectors.

• Routinggruppen

• Routinggruppenconnectors

• Postfachspeicher (private Nachrichtendatenbanken [MDB-Dateien])

• Informationsspeicher für Öffentliche Ordner (öffentliche MDB-Dateien)

• Öffentliche Ordner-Hierarchien

Basierend auf diesen Informationen füllt die Routingkomponente des MicrosoftExchange-Transportdiensts Routingtabellen mit Daten auf, um die Routingentscheidungen zu optimieren. Die Routingtabelle setzt die Daten miteinander in Beziehung, um eine Topologiezuordnung zu erstellen. Diese Topologiezuordnung enthält die folgenden Elemente:

• Zuordnung verknüpfter Connectors   Diese Zuordnung setzt die Bezeichner von Empfangsconnectors auf dem lokalen Server mit dem verknüpften Sendeconnector in Beziehung.

• Serverzuordnung   Alle Exchange 2010- und Exchange 2007-Hub-Transport-Server, -Edge-Transport-Server, -Postfachserver und Servercomputer mit Exchange 2003 in der Organisation sind in der Serverzuordnung enthalten. Diese Zuordnung setzt den Distinguished Name jedes Servercomputers mit Exchange mit Serverroutingdaten in Beziehung. Dabei werden die Gesamtkosten berücksichtigt, zu denen der betreffende Server erreicht werden kann.

• Legacyserverzuordnung   Alle Exchange Server 2007-Hub-Transport-Server, -Edge-Transport-Server, -Postfachserver und Servercomputer mit Exchange 2003 in der Organisation sind in der Legacyserverzuordnung enthalten. Diese Zuordnung setzt den Legacy-DN (Distinguished Name) jedes Servercomputers mit Exchange mit Serverroutingdaten in Beziehung. Dabei werden die Gesamtkosten berücksichtigt, zu denen der betreffende Server erreicht werden kann. Diese Zuordnung unterstützt Speicherüberschreibfunktionen. Speicherüberschreibfunktionen sind für Öffentliche Ordner spezifisch. Weitere Informationen finden Sie im Abschnitt "Weiterleiten von Nachrichten an Öffentliche Ordner" unter Internes Nachrichtenrouting.

• MDB-Zuordnung   Alle MDB-Dateien in der Organisation sind in der MDB-Zuordnung enthalten. Diese Zuordnung setzt den DN (Distinguished Name) jeder MDB-Datei mit Serverroutingdaten in Beziehung. Dabei werden die Gesamtkosten berücksichtigt, zu denen der betreffende Server erreicht werden kann.

• Active Directory-Standortzuordnung   Diese Zuordnung setzt jeden Active Directory-Standort mit einer Struktur in Beziehung, die den kostengünstigsten Routingpfad vom lokalen Standort zu jedem anderen Standort enthält. Die Zuordnung enthält alle Hubstandorte entlang des kostengünstigsten Routingpfads. Jeder Routingpfadhop identifiziert außerdem alle Hub-Transport-Server an diesem Standort, die von der erweiterten DNS-Komponente verwendet werden.

• Routinggruppenzuordnung   Diese Zuordnung weist jeder Legacyroutinggruppe die Gesamtkosten und den Routinggruppenconnector für den ersten Hop für den kostengünstigsten Routingpfad aus der Exchange 2010-Routinggruppe zu.

• Sendeconnectorzuordnung   Diese Zuordnung identifiziert die in der Organisation konfigurierten Sendeconnectors und die Quellserver für jeden Connector.

Die Routingtabellen werden bei jedem Start eines Transportserver erstellt und erneut berechnet, wenn Konfigurationsänderungen empfangen werden. Konfigurationsänderungen können durch Folgendes erkannt werden:

• Active Directory-Änderungsbenachrichtigungen   Zwischen dem Zeitpunkt, zu dem eine Benachrichtigung empfangen wird, und dem Zeitpunkt, zu dem die Änderung in die Routingtabellen geschrieben wird, liegt eine Verzögerung. Durch diese Verzögerung kann die Routingkomponente die Änderungen zu einem Batch zusammenfassen und mehrere Änderungen in einem einzigen Vorgang verarbeiten. Standardmäßig veranlasst jede Benachrichtigung die Routingkomponente, die Verarbeitung um fünf Sekunden zu verzögern. Wenn z. B. fünf Benachrichtigungen genau eine Sekunde nach der vorherigen Benachrichtigung empfangen werden, verzögert das Routing die Verarbeitung der Änderung um insgesamt neun Sekunden.

• Durch Dienststeuerungsbefehle bewirktes erneutes Laden der Konfiguration Die Routingkomponente lädt die Konfigurationsdaten, wenn der Microsoft Exchange-Transportdienst neu gestartet wird.

• Regelmäßiges erneutes Laden, um Änderungen zu verfolgen, die nicht durch Active Directory-Benachrichtigungen unterstützt werden   Standardmäßig lädt das Routing die Konfigurationsdaten regelmäßig erneut, damit sichergestellt ist, dass alle Änderungen verfolgt werden. Das erneute Laden der Konfigurationsdaten findet in Intervallen von sechs Stunden statt.

Die Informationen in den Routingtabellen werden in Routingprotokollen protokolliert. Diese Protokolle befinden sich standardmäßig im Verzeichnis C:\Programme\Microsoft\Exchange Server\V14\TransportRoles\Logs\Routing. Bei jeder Berechnung der Routingtabellen wird ein neues Protokoll generiert. Wenn der Hub-Transport-Server aus irgendeinem Grund keine Verbindung mit Active Directory herstellen kann, fällt das Routing Routingentscheidungen basierend auf den aktuell zwischengespeicherten Daten, auch wenn diese ggf. nicht mehr aktuell sind. Weitere Informationen finden Sie unter Grundlegendes zur Routingtabellenprotokollierung.

Zurück zum Seitenanfang

Empfangen von Nachrichten für das Routing

Eine Nachricht kann wie folgt auf einem Hub-Transport-Server eingehen:

• Die E-Mail wird von einem internetseitigen SMTP-Server (Simple Mail Transfer Protocol) für die Zustellung an einen Empfänger in der Exchange-Organisation oder einen Empfänger in einer akzeptierten internen Relaydomäne empfangen.

• Die E-Mail wird von einem anderen Hub-Transport-Server in der Exchange-Organisation für die Zustellung an ein Empfängerpostfach empfangen, das sich auf einem Postfachserver an diesem Active Directory-Standort befindet.

• Die E-Mail wird von SMTP-Clients empfangen. In der Regel handelt es sich um POP3- oder IMAP4-Benutzer, die wahrscheinlich in Ihrer Umgebung vorhanden sind.

• Die E-Mail wird von den PICKUP- und Wiedergabeverzeichnissen auf einem Hub-Transport-Server empfangen. Diese Verzeichnisse werden üblicherweise von fremden Connectors für die Übertragung von Nachrichten an Ihre Exchange-Infrastruktur verwendet.

• Die E-Mail wird vom Hub-Transport-Server von einem Exchange 2010-Postfachserver abgerufen.

• Die E-Mail wird von einem Exchange 2007- oder Exchange 2003-Server für die Zustellung an ein Empfängerpostfach empfangen, das sich auf einem Exchange 2010-Postfachserver befindet.

Die Verarbeitung aller E-Mails, die von einem Hub-Transport-Server zur Kategorisierung empfangen werden, beginnt in der Übermittlungswarteschlange.

Empfangen von Nachrichten von Edge-Transport-Servern, weiteren Exchange-Hub-Transport-Servern und SMTP-Clients

In diesem Szenario werden Nachrichten von Edge-Transport-Servern, Hub-Transport-Servern oder SMTP-Hosts von Drittanbietern mithilfe von SMTP-Standardverbindungen empfangen. Der Remotehost stellt eine SMTP-Verbindung her und überträgt die Nachrichten an den Hub-Transport-Server. Hub-Transport-Server verwenden Empfangsconnectors zum Annehmen eingehender SMTP-Verbindungen. Jeder Hub-Transport-Server verfügt über zwei Empfangsconnectors, die während der Installation erstellt werden. Einer dieser Connectors wird für den Empfang authentifizierter SMTP-Verbindungen von anderen Servercomputern mit Exchange verwendet. Der andere Connector wird zum Empfangen von SMTP-Verbindungen von SMTP-Clients genutzt, die von POP3- oder IMAP4-Benutzern in Ihrer Organisation verwendet werden. Für diese beiden Empfangsconnectors werden unterschiedliche Berechtigungen konfiguriert, die der beabsichtigten Nutzung entsprechen. Weitere Informationen zu Empfangsconnectors finden Sie unter Grundlegendes zu Empfangsconnectors.

In der Standardeinstellung akzeptieren Hub-Transport-Server keine nicht authentifizierten, anonymen Verbindungen. Wenn Sie diese Funktion aktivieren müssen, ist es empfehlenswert, einen separaten Empfangsconnector zu erstellen, der die anonymen Verbindungen verarbeitet. Weitere Informationen finden Sie unter Zulassen von anonymem Relay für einen Empfangsconnector.

Abrufen von Nachrichten aus den PICKUP- und Wiedergabeverzeichnissen

Messagingsysteme, die nicht SMTP als Übertragungsprotokoll nutzen, können über fremde Connectors mit Ihrer Exchange-Organisation verbunden werden. Wenn eine Nachricht von einem Remotesystem an einen Exchange-Benutzer gesendet wird, schreibt der fremde Connector diese Nachricht in ein spezielles Verzeichnis auf dem Hub-Transport-Server, das als PICKUP-Verzeichnis bezeichnet wird. Der Hub-Transport-Server überprüft in regelmäßigen Abständen das PICKUP-Verzeichnis auf neue Nachrichten. Wenn eine neue Nachricht ermittelt wird, konvertiert der Hub-Transport-Server die Nachricht in eine Exchange-E-Mail-Nachricht und leitet sie als normale Nachricht weiter. Weitere Informationen zur Verwendung der PICKUP- und Wiedergabeverzeichnisse finden Sie unter Grundlegendes zu den PICKUP- und Wiedergabeverzeichnissen.

Abrufen von Nachrichten von einem Postfachserver

In diesem Szenario benachrichtigt der MicrosoftExchange-Mailübergabedienst, der auf Postfachservern ausgeführt wird, einen Hub-Transport-Server am gleichen Active Directory-Standort darüber, dass Nachrichten zum Abruf aus dem Postausgang eines Absenders bereitstehen. Jeder Postfachserver verwaltet eine Liste mit Hub-Transport-Servern, die sich am gleichen Active Directory-Standort befinden. Diese Liste wird als "Übermittlungsserverliste" bezeichnet. Die Suche nach Servern wird alle 10 Minuten wiederholt, um die Liste stets auf dem aktuellen Stand zu halten.

Wenn sich mehrere Hub-Transport-Server am gleichen Active Directory-Standort wie der Postfachserver befinden, der die Benachrichtigung übermittelt, dass E-Mails zum Abrufen bereitstehen, findet der folgende Prozess zur Auswahl des Servers statt:

• Wenn auf dem lokalen Postfachserver auch die Hub-Transport-Serverrolle ausgeführt wird und er nicht zu einer Database Availability Group (DAG) gehört, wird der lokale Server benachrichtigt. Wenn der lokale MicrosoftExchange-Transportdienst nicht ausgeführt wird oder der lokale Hub-Transport-Server aufgrund von Rückstau keine neuen Nachrichtenübermittlungen verarbeiten kann, wird ein anderer verfügbarer Hub-Transport-Server benachrichtigt. Weitere Informationen zur Rückstaufunktion finden Sie unter Grundlegendes zur Rückstaufunktion.

• Wenn auf dem lokalen Postfachserver auch die Hub-Transport-Serverrolle ausgeführt wird und er nicht zu einer DAG gehört, versucht er zuerst, einen Hub-Transport-Server am Standort zu benachrichtigen, bevor der lokale Hub-Transport-Server benachrichtigt wird. Auf diese Weise werden redundante Kopien von Nachrichten auf derselben Serverhardware vermieden. Weitere Informationen zur Koexistenz von Postfach- und Hub-Transport-Serverrollen bei der Verwendung von DAGs finden Sie unter Koexistenz von Hub-Transport- und Postfachserverrollen bei Verwendung von Datenbankverfügbarkeitsgruppen.

• Wenn auf dem lokalen Postfachserver die Hub-Transport-Serverrolle nicht ausgeführt wird, werden Benachrichtigungen mithilfe von Roundrobin über einen Lastenausgleich auf mehrere Hub-Transport-Server verteilt.

• Wenn mit dem ausgewählten Hub-Transport-Server keine Verbindung hergestellt werden kann, führt der MicrosoftExchange-Mailübergabedienst einen Failover auf einen anderen Hub-Transport-Server am gleichen Active Directory-Standort aus. Der ausgefallene Server wird als inaktiv gekennzeichnet, und der nächste Hub-Transport-Server in der Übermittlungsserverliste wird ausgewählt. Wenn am lokalen Active Directory-Standort keine Hub-Transport-Server verfügbar sind, ist die Übermittlungsserverliste leer. In diesem Fall wird ein Ereignis protokolliert, und die Mailübermittlungsbenachrichtigungen werden vorübergehend ausgesetzt. Bei als inaktiv gekennzeichneten Hub-Transport-Servern wird der Verbindungsvorgang nach fünf Minuten wiederholt.

Standardmäßig nimmt der MicrosoftExchange-Mailübergabedienst einen Lastenausgleich von Benachrichtigungsereignissen auf den Hub-Transport-Servern an einem Standort aus, sodass an jeden Hub-Transport-Server die gleiche Anzahl von Benachrichtigungsereignissen zur Verarbeitung verteilt wird. Unter bestimmten Umständen ist eine gleichmäßige Verteilung nicht die optimale Lösung. Nicht alle Hub-Transport-Server weisen die gleiche Kapazität auf, und manche Nachrichten erfordern einer weitere Verarbeitung. So dauert z. B. die Verarbeitung einer Nachricht mit einer großen Anlage oder vielen Empfängern auf einem Hub-Transport-Server länger als die einer kleinen Nachricht, die nur an einen Empfänger adressiert ist. Wenn Sie eine statische Liste mit Hub-Transport-Servern erstellen möchten, die von einem Postfachserver benachrichtigt werden sollen, können Sie dazu das Cmdlet Set-MailboxServer in der Shell verwenden. Mithilfe des Parameters SubmissionServerOverrideList können Sie eine Liste von Hub-Transport-Servern angeben, die vom lokalen Postfachserver benachrichtigt werden, wenn Nachrichten zum Abrufen bereitstehen. Weitere Informationen zum Konfigurieren dieser Einstellung finden Sie unter Set-MailboxServer.

Wenn ein Hub-Transport-Server von einem Postfachserver eine Mailübermittlungsbenachrichtigung empfängt, wird die Nachricht mithilfe des Speichertreibers aus der Postfachdatenbank abgerufen und in der Übermittlungswarteschlange auf dem Hub-Transport-Server gespeichert. Die Übertragung der Nachricht vom Postfachserver an den Hub-Transport-Server erfolgt mithilfe eines Exchange-Remoteprozeduraufrufs.

Empfangen von Nachrichten von Exchange-Legacyservern

Aufgrund der Änderungen am XSO-Modell (Exchange Server Object, Exchange-Serverobjekt) in Exchange 2010 können Exchange 2010-Hub-Transport-Server keine Nachrichten von Exchange 2007-Postfachservern abrufen oder an diese Server zustellen. Ebenso können Exchange 2007-Hub-Transport-Server nicht mit Exchange 2010-Postfachservern kommunizieren. Alle Nachrichten, die von Exchange 2007-Empfängern gesendet werden, werden zuerst durch Exchange 2007-Hub-Transport-Server von den Postfachservern abgerufen und dann mittels Relay an Exchange 2010-Hub-Transport-Server weitergeleitet. Weitere Informationen zum Nachrichtenrouting bei einer Koexistenz mit Exchange 2007 finden Sie unter Upgrade des Exchange 2007-Transports.

Im Gegensatz zu Active Directory-Standorten verwendet Exchange 2003 Routinggruppen zum Weiterleiten von Nachrichten. Routinggruppen werden über Routinggruppenconnectors miteinander verbunden. Zur Unterstützung der Koexistenz zwischen diesen beiden Routingtopologien werden alle Exchange 2010-Server automatisch einer einzelnen Routinggruppe hinzugefügt, wenn Exchange 2010 in einer Exchange 2003-Organisation installiert wird. Alle Nachrichten, die aus einem Exchange 2003-Postfach stammen, werden über die Routinggruppenconnectors zwischen der Exchange 2010-Routinggruppe und den Exchange 2003-Routinggruppen an die Exchange 2010-Umgebung zugestellt. Weitere Informationen zum Nachrichtenrouting bei einer Koexistenz mit Exchange 2003 finden Sie unter Upgrade des Exchange 2003-Transports.

Zurück zum Seitenanfang

Nachrichtenrouting

Nachdem ein Hub-Transport-Server oder ein Edge-Transport-Server eine Nachricht empfangen hat, bestimmt er das Endziel und verwendet die Exchange-Topologie sowie Connectorkonfigurationen, um den kostengünstigsten Routingpfad zu ermitteln. Nachdem der Routingpfad ermittelt wurde, wird die Nachricht dem nächsten Hop im Routingpfad zugestellt.

Dieses Thema enthält eine allgemeine Erläuterung zu Routingentscheidungen in Exchange. Die folgenden beiden Themen bieten darüber hinaus zusätzliche Informationen zu bestimmten Routingszenarien. Im Thema zum internen Nachrichtenrouting wird die Nachrichtenzustellung an Postfachserver, Öffentliche Ordner und Legacyserver behandelt. Im Thema zum externen Nachrichtenrouting wird das Routing von Nachrichten an Empfänger außerhalb der Exchange-Organisation erläutert. Behandelt werden außerdem die Rollen von Sendeconnectors, Zustellungs-Agent-Connectors und Fremdconnectors.

• Internes Nachrichtenrouting

• Externes Nachrichtenrouting

Bestimmen des Endziels

Im vorherigen Abschnitt wurden die verschiedenen Quellen beschrieben, aus denen ein Hub-Transport-Server Nachrichten empfangen kann. Wenn eine Nachricht von einem Hub-Transport-Server empfangen wird, muss die Nachricht kategorisiert werden. Die erste Phase der Nachrichtenkategorisierung ist die Empfängerauflösung. Nachdem der Empfänger aufgelöst wurde, kann das Endziel bestimmt werden. In der nächsten Phase – dem Routing – wird bestimmt, wie dieses Ziel am besten erreicht werden kann. Eine einzelne, deterministische Route wird ausgewählt. Diese Route wird nur dann erneut berechnet, wenn sich die Routingkonfiguration ändert.

Aus der Perspektive des sendenden Servers stellt jede Zustellungswarteschlange das Ziel für eine bestimmte Nachricht dar. Wenn der Hub-Transport-Server oder der Edge-Transport-Server das Ziel für eine Nachricht auswählt, wird das Ziel als Attribut NextHopSolutionKey auf den Empfänger gestempelt. Wenn eine einzelne Nachricht an mehrere Empfänger gesendet wird, verfügt jeder dieser Empfänger über das Attribut NextHopSolutionKey. Der empfangende Server führt ebenfalls Nachrichtenkategorisierung durch und reiht die Nachricht für die Zustellung in eine Warteschlange ein. Nachdem eine Nachricht in einer Warteschlange gespeichert wurde, können Sie den Zustellungstyp für eine bestimmte Warteschlange untersuchen, damit Sie bestimmen können, ob eine Nachricht nochmals mittels Relay weitergeleitet wird, wenn sie das nächste Hopziel erreicht.

Das Ziel für eine Nachricht kann als einer der folgenden Zustellungstypen klassifiziert werden:

• DNS-Connectorzustellung   Die Nachrichten werden für die Zustellung an einen externen Empfänger mithilfe eines SMTP-Sendeconnectors, für den der lokale Server ein Quellserver ist, in einer Warteschlange gespeichert. Der Connector ist für die Verwendung von DNS zum Auflösen der Empfängeradressen konfiguriert.

• Smarthost-Connectorzustellung   Die Nachrichten werden für die Zustellung an einen externen Empfänger mithilfe eines SMTP-Sendeconnectors, für den der lokale Server ein Quellserver ist, in einer Warteschlange gespeichert. Der Connector ist für die Verwendung eines Smarthosts für die Zustellung konfiguriert.

• SMTP-Relay in einem Active Directory-Standort an einen Edge-Transport-Server   Die Nachrichten werden für die Zustellung an einen externen Empfänger in einer Warteschlange gespeichert. Dazu wird ein SMTP-Sendeconnector verwendet, dessen Quellserver ein Edge-Transport-Server ist, der den lokalen Active Directory-Standort abonniert hat.

• SMTP-Relay in einem Active Directory-Standort an einen Hub-Transport-Server   Die Nachrichten werden für die Zustellung an einen Hub-Transport-Server, der sich am gleichen Active Directory-Standort wie der lokale Server befindet, in einer Warteschlange gespeichert. Der Zielserver kann ein Exchange 2007-Hub-Transport-Server, der Quellserver für einen Sendeconnector, ein Zustellungs-Agent-Connector oder ein fremder Connector, der Quellserver eines Routinggruppenconnectors oder ein Server für die Aufgliederung der Verteilerlisten sein.

• SMTP-Relay an einen Active Directory-Remotestandort   Die Nachrichten werden für die Zustellung an einen Hub-Transport-Server, der sich an einem Active Directory-Remotestandort befindet, in einer Warteschlange gespeichert. Der endgültige Zielserver am Active Directory-Remotestandort kann einer der folgenden Servertypen sein:

  • Der Quellserver für einen Connector, der für den Transport von Nachrichten für externe Empfänger konfiguriert ist

  • Der Quellserver für einen Routinggruppenconnector.

  • Ein Server für die Aufgliederung der Verteilergruppe.

  • Ein Postfachserver, der sich am Active Directory-Remotestandort befindet

  Die Nachrichten werden an einen der Hub-Transport-Server am Zielstandort übermittelt. Der empfangende Server leitet bei Bedarf die Nachrichten mittels Relay innerhalb des Active Directory-Standorts weiter.

• SMTP-Relay an eine Legacyroutinggruppe   Die Nachrichten werden für die Zustellung an den Routinggruppenconnector für den ersten Hop, der für das Erreichen einer Exchange 2003-Routinggruppe verwendet wird, in einer Warteschlange gespeichert. Der endgültige Zielserver kann einer der folgenden Servertypen sein:

  • Der Quellserver für einen Connector.

  • Ein Aufgliederungsserver.

  • Ein Exchange 2003-Bridgeheadserver, der Nachrichten zustellt, die an Postfachempfänger adressiert sind, die sich in der Routinggruppe befinden.

• MAPI-Zustellung Die Nachrichten werden für die Zustellung an das Postfach eines Empfängers, an einen Öffentlichen Ordner oder einen Informationsspeicher für Öffentliche Ordner, der sich auf einem Postfachserver am lokalen Active Directory-Standort befindet, in einer Warteschlange gespeichert.

• Nicht-SMTP-Gatewayzustellung   Die Nachrichten werden mithilfe eines Zustellungs-Agent-Connectors oder Fremdconnectors, für den der lokale Server ein Quellserver ist, für die Zustellung an einen externen Empfänger in einer Warteschlange gespeichert. Dieser Zustellungstyp wird nur verwendet, wenn die Nachrichten an Zustellungs-Agent-Connectors oder an das Ablageverzeichnis des Fremdconnectors auf dem lokalen Server zugestellt werden.

• Nicht erreichbar   Eine Route zum Empfänger konnte nicht bestimmt werden, und die Nachrichten befinden sich in der Nicht-erreichbar-Warteschlange.

Bestimmen des kostengünstigsten Routingpfads

Der kostengünstigste Routingpfad zum Active Directory-Remotestandort wird durch Berechnung aller Kosten ermittelt, die den Active Directory-IP-Standortverknüpfungen zugeordnet sind, die zwischen den beiden Standorten bestehen. Die Verknüpfungen werden überbrückt, sodass eine Direktverbindung entsteht. Exchange 2010-Hub-Transport-Server wählen stets einen einzelnen, deterministischen kostengünstigsten Routingpfad aus. Die Verfügbarkeit der zugrunde liegenden Verbindung oder des Zielservers wird bei der Auswahl des Routingpfads nicht berücksichtigt; auch alternative Routingpfade werden nicht berücksichtigt. 

Die Berechnung des kostengünstigsten Routingpfads wird zum Bestimmen eines Backoffpfads verwendet, wenn bei der Nachrichtenzustellung an den nächsten Hop ein Fehler auftritt. Backoff ist in Exchange 2010 ein Mechanismus, der zum Zustellen von Nachrichten an einen Zwischenhop im kostengünstigsten Routingpfad verwendet wird, wenn aus einem bestimmten Grund ein Fehler beim direkten Relay auftritt, z. B. aufgrund von Netzwerkproblemen oder weil Server offline geschaltet werden. Die Routingkomponente versucht, die Nachrichten mithilfe des Backoff-Mechanismus Hop für Hop entlang dem günstigsten Routingpfads so nah wie möglich an das Ziel zu übermitteln, bis eine Verbindung hergestellt werden kann. Zuerst wird ein Verbindungsversuch mit jedem Hub-Transport-Server am Active Directory-Zielstandort unternommen. Wenn keiner der Hub-Transport-Server am Active Directory-Standort antwortet, wird der kostengünstigste Routingpfad überprüft, um zu bestimmen, wie das Backoff vom Zustellungsstandort begonnen werden kann. Das Ziel besteht darin, die Nachricht so nah wie möglich an den Zielstandort zu übermitteln und auf einem Hub-Transport-Server an diesem Active Directory-Standort in einer Warteschlange zu speichern.

Abhängig vom individuellen Nachrichtenroutingszenario beeinflussen die folgenden Faktoren ggf. die Auswahl des kostengünstigsten Routingpfads:

• Verknüpfte Connectors   Wenn der Empfangsconnector, auf dem die Nachricht empfangen wird, mit einem Sendeconnector verknüpft ist, werden Nachrichten unabhängig von den Kosten an diesen Sendeconnector weitergeleitet. Diese Konfiguration besitzt immer Vorrang.

• Die den IP-Standortverknüpfungen und Routinggruppenconnectors, die zum Erreichen des Ziels durchlaufen werden müssen, zugewiesenen Kosten Wenn mehrere Routingpfade zwischen einem Quellserver und einem Zielserver vorhanden sind, wird der Routingpfad mit den geringsten Gesamtkosten ausgewählt.

• Der einem Sendeconnector zugewiesene Adressraum   Der Sendeconnector mit der genauesten Adressraumentsprechung zum Ziel wird ausgewählt.

• Die dem auf einem Sendeconnector konfigurierten Adressraum zugewiesenen Kosten Wenn mehreren Sendeconnectors der gleiche Adressraum zugewiesen wurde, vergleicht die Routingkomponente die dem Adressraum zugewiesenen Kosten. Der Sendeconnector mit den geringsten Kosten wird ausgewählt.

• Connectorbereich   Ein Connector kann auf die Verwendung durch Servercomputer mit Exchange 2010 beschränkt sein, die sich am gleichen Active Directory-Standort wie die Quelltransportserver für den Connector befinden. In früheren Versionen von Exchange konnte der Connectorbereich auf Server beschränkt sein, die Mitglied der gleichen Routinggruppe sind.

• Beschränkungen der Nachrichtengröße   Der Wert der für einen Connector festgelegten Beschränkung der Nachrichtengröße muss größer als die Größe der weitergeleiteten Nachricht sein. Connectors mit einer Beschränkung der Nachrichtengröße, die kleiner als die Größe der Nachricht ist, werden bei der Routingauswahl nicht berücksichtigt.

• Die Nähe des Ziels zum sendenden Server   Das Routing bevorzugt den nächstgelegenen Server in der folgenden Reihenfolge: lokaler Server, Server am gleichen Active Directory-Standort, Server an einem Active Directory-Remotestandort oder in einer -Routinggruppe.

• Der einem Active Directory-Standort zugewiesene Name Wenn mehrere Routingpfade die gleichen Gesamtkosten aufweisen, führt die Routingkomponente einen alphanumerischen Vergleich des Namens der Active Directory-Standorte durch, die dem Zielstandort auf jedem Routingpfad vorausgehen. Es wird dann der Routingpfad verwendet, bei dem der Active Directory-Standort, der dem Ziel am nächsten ist, in der alphanumerischen Reihenfolge am niedrigsten ist.

• Der einem Routinggruppenconnector zugewiesene Name Wenn mehrere Routingpfade die gleichen Gesamtkosten aufweisen, führt die Routingkomponente einen alphanumerischen Vergleich des Namens der Routinggruppenconnectors durch, die vor dem Ziel auf jedem Routingpfad liegen. Es wird dann der Routingpfad verwendet, bei dem der Routinggruppenconnector, der dem Ziel am nächsten ist, in der alphanumerischen Reihenfolge am niedrigsten ist.

• Der Connectorstatus   Die Routingkomponente von Exchange 2010 berücksichtigt beim Berechnen des Routingpfads nur aktivierte Connectors. Frühere Versionen von Exchange berücksichtigen den Connectorstatus jedoch nicht.

Die folgende Logik wird zum Auswählen des Routingpfads verwendet:

1. Zuerst wird der kostengünstigste Routingpfad berechnet, indem die Kosten der IP-Standortverknüpfungen und ggf. der Routinggruppenconnectors addiert werden, die zum Erreichen des Ziels durchlaufen werden müssen. Wenn das Ziel ein Connector ist, werden die dem Adressraum zugewiesenen Kosten zu den Kosten addiert, die zum Erreichen des ausgewählten Connectors erforderlich sind. Wenn mehrere Routingpfade möglich sind, wird nur der Routingpfad mit den geringsten Gesamtkosten verwendet.

2. Wenn mehrere Routingpfade die gleichen Gesamtkosten aufweisen, wird die Anzahl der Hops in jedem Pfad ausgewertet, und der Routingpfad mit der geringsten Anzahl von Hops wird verwendet.

3. Wenn dann immer noch mehrere Routingpfade zur Verfügung stehen, wird entweder der Name berücksichtigt, der den Active Directory-Standorten zugeordnet ist, oder es werden die Routinggruppenconnectors vor dem Ziel herangezogen. Es wird dann der Routingpfad verwendet, bei dem der Active Directory-Standort, der dem Ziel am nächsten ist, in der alphanumerischen Reihenfolge am niedrigsten ist. Wenn der Standort in größter Nähe zum Ziel für alle ausgewerteten Routingpfade identisch ist, wird ein früherer Standortname berücksichtigt.

Die folgende Abbildung zeigt die Routingtopologie für eine Exchange-Organisation. Diese Topologie wird in den folgenden Beispielen verwendet, um die Logik zu zeigen, die vom Routingalgorithmus zum Auswählen des kostengünstigsten Routingpfads verwendet wird.

Exchange 2010-Routingtopologie

Beispiel 1   Eine Nachricht, die von Standort A an Standort D weitergeleitet wird, kann zwei möglichen Routingpfaden folgen: "Standort A - Standort B - Standort D" und "Standort A - Standort C - Standort D". Die den IP-Standortverknüpfungen in jedem Routingpfad zugewiesenen Kosten werden addiert, um die Gesamtkosten für das Routing der Nachricht zu ermitteln. In diesem Beispiel besitzt der Routingpfad "Standort A - Standort B - Standort D" die Gesamtkosten von 20. Der Routingpfad "Standort A - Standort C - Standort D" weist Gesamtkosten von 10 auf. Das Routing wählt den Pfad "Standort A - Standort C - Standort D" aus.

Beispiel 2   Eine Nachricht wird mittels Relay von Standort B an Standort D weitergeleitet. Es gibt drei mögliche Routingpfade: "Standort B - Standort D" mit Kosten von 15, "Standort B - Standort E - Standort C - Standort D" mit Kosten von 15 und "Standort B - Standort A - Standort C - Standort D" mit Kosten von 15. Da mehrere Routingpfade die gleichen Kosten ergeben, wählt das Routing den Routingpfad "Standort B - Standort D" aus. Dieser weist die niedrigste Anzahl von Hops auf.

Beispiel 3   Eine Nachricht wird mittels Relay von Standort A an Standort E weitergeleitet. Es gibt zwei mögliche Routingpfade: "Standort A - Standort B - Standort E" mit Kosten von 10 und "Standort A - Standort C - Standort E" mit Kosten von 10. Kosten und Anzahl Hops sind bei beiden Routingpfaden identisch. Die alphanumerische Reihenfolge der Active Directory-Standorte unmittelbar vor Standort E wird verglichen. Standort B weist einen niedrigeren alphanumerischen Wert als Standort C auf. Daher wählt das Routing den Routingpfad "Standort A - Standort B - Standort E" aus.

Nachdem der kostengünstigste Routingpfad bestimmt wurde, berücksichtigt die Exchange 2010-Routingkomponente keine alternativen Routingpfade.

Auswahl des nächsten Hops

Exchange 2010-Hub-Transport-Server führen kein Relay an jeden Active Directory-Standort entlang des kostengünstigsten Routingpfads aus. Nachdem der Routingpfad bestimmt wurde, wird die Nachricht mittels Relay direkt vom Quellserver an den nächsten Hop weitergeleitet. Die Auswahl des nächsten Hops versucht, die Nachrichten so nah wie möglich an das Endziel zuzustellen. Zusätzliches Relay innerhalb des Standorts ist ggf. erforderlich, um den Endzielort zu erreichen. Findet Routing an Legacyroutinggruppen statt, wird direktes Relay an den Active Directory-Standort, an dem sich der Quellserver für den Routinggruppenconnector für den ersten Hop befindet, durchgeführt. Nachdem eine Nachricht mittels Relay an die Legacyumgebung weitergeleitet wurde, findet das Legacystandardrouting statt.

Die folgende Abbildung zeigt eine einfache Exchange-Topologie und enthält viele Exchange-Routingkomponenten.

Exchange-Topologie und Routingkomponenten

Gemäß der Abbildung oben wird eine Nachricht, die aus Postfach1 an Standort A an den externen Empfänger joe@contoso.com gesendet wird, folgendermaßen verarbeitet:

1. Der Postfachübermittlungsdienst von MicrosoftExchange, der für Postfach1 ausgeführt wird, benachrichtigt einen Exchange 2010-Hub-Transport-Server, der sich am gleichen Active Directory-Standort befindet, über das neue E-Mail-Element für den Transport.

2. Mithilfe von RPC ruft die Informationsspeichertreiber-Komponente auf einem Exchange 2010-Hub-Transport-Server am gleichen Active Directory-Standort die Nachricht ab und speichert sie in der Übermittlungswarteschlange auf dem lokalen Server.

3. Aus der Übermittlungswarteschlange durchläuft die Nachricht die Kategorisierung. Das Kategorisierungsmodul führt zuerst die Empfängerauflösung durch und bestimmt, dass "joe@contoso.com" ein externer Empfänger ist.

4. Die Routingkomponente wählt den besten Connector aus, über den die Nachricht weitergeleitet wird, und berechnet den kostengünstigsten Routingpfad zu diesem Connector. In diesem Beispiel besitzt ein Sendeconnector den Adressraum "*.contoso.com" und ist der Connector, der von der Routingkomponente ausgewählt wurde. Alle Quellserver für diesen Sendeconnector befinden sich an Standort B.

5. Die Routingkomponente bestimmt den nächsten Hop, der zum Erreichen eines Quellservers für den Sendeconnector erforderlich ist. Der Hub-Transport-Server an Standort A speichert die Nachricht für die SMTP-Zustellung an Standort B in einer Warteschlange.

6. Wenn der empfangende Server an Standort B ein Quellserver für den Sendeconnector ist, speichert er die Nachricht für die Zustellung an diesen Sendeconnector in einer Warteschlange. Wenn der empfangende Server kein Quellserver für den Sendeconnector "*.contoso.com" ist, wird die Nachricht mithilfe von SMTP an einen Hub-Transport-Server an Standort B weitergeleitet, der der Quellserver für den Connector ist.

Die folgende Tabelle enthält weitere Beispiele für die Auswahl des nächsten Hops für mehrere Empfänger basierend auf der in Abbildung 5 gezeigten Topologie. Es handelt sich dabei nicht um eine vollständige Liste aller Routingmöglichkeiten. Sie enthält lediglich Beispiele, die in einer Topologie, wie sie in der obigen Abbildung dargestellt ist, häufig zum Einsatz kommen.

Beispiele für die Auswahl des nächsten Hops in der Abbildung oben

Empfangender Server	Endziel	Nächster Hop	Warteschlangenzustellungstyp
Hub1	Postfach1	Postfach1	MAPI-Zustellung
Hub1	Postfach2	Hub3	SMTP-Relay an einen Active Directory-Standort
Hub1	Postfach3	Standort B	SMTP-Relay an einen Active Directory-Remotestandort
Hub1	Postfach4	Routinggruppenconnector	SMTP-Relay an eine Legacyroutinggruppe
Hub1	Empfänger@fourthcoffee.com	Edge1	SMTP-Relay an den Edge-Transport-Server
Hub3	Postfach1	Hub1 oder Hub2	SMTP-Relay an einen Active Directory-Standort
Hub4	Postfach1	Standort A	SMTP-Relay an einen Active Directory-Remotestandort
Hub4	Postfach4	Standort A	SMTP-Relay an einen Active Directory-Remotestandort
Hub4	Empfänger@contoso.com	Contoso SMTP-Host	Smarthost-Zustellung
Hub4	Empfänger@fourthcoffee.com	Standort A	SMTP-Relay an einen Active Directory-Remotestandort
Edge1	Empfänger@fourthcoffee.com	Fourth Coffee SMTP-Host	DNS-Zustellung

Nachdem der kostengünstigste Routingpfad berechnet und das Ziel des nächsten Hops ausgewählt wurde, versucht das Exchange 2010-Routing ein Relay der Nachricht direkt zum Ziel, sofern entlang des kostengünstigsten Routingpfads kein Hubstandort konfiguriert ist.

Warteschlange am Fehlerpunkt

Anhand der Berechnung des kostengünstigsten Pfads wird ein Backoff-Pfad bestimmt, falls bei der Zustellung der Nachricht an den nächsten Hop ein Fehler auftritt. Exchange 2010 versucht, die Nachrichten mithilfe des Backoff-Mechanismus Hop für Hop entlang des kostengünstigsten Routingpfads so nah wie möglich an das Ziel zuzustellen, bis eine Verbindung hergestellt werden kann. Dieses Verhalten wird auch als Warteschlange am Fehlerpunkt bezeichnet. Wenn die Nachricht an dem Punkt im Zustellungspfad in einer Warteschlange gespeichert wird, an dem der Kommunikationsfehler aufgetreten ist, wird nach der Problemlösung nicht nur die Zustellung beschleunigt, sondern Sie können auch feststellen, warum der Fehler bei der Nachrichtenzustellung aufgetreten ist.

Wenn in der nachstehend abgebildeten Topologie eine Nachricht von Standort A an Standort D zugestellt wird, ist der kostengünstigste Routingpfad möglicherweise "Standort A - Standort B - Standort C - Standort D". Zuerst wird die direkte Zustellung von Standort A an Standort D versucht. Wenn kein Hub-Transport-Server an Standort D antwortet, wird die Zustellung an die Hub-Transport-Server an Standort C versucht. Dieser Vorgang wird fortgesetzt, bis ein Hub-Transport-Server die Nachricht akzeptiert. Wenn kein Zwischenstandort verfügbar ist, wird die Nachricht am Quellstandort in einer Warteschlange gespeichert. Wenn die Nachricht an Standort C in einer Warteschlange gespeichert wird, können Sie mit der Fehlersuche bei den Hub-Transport-Servern an Standort D oder der Netzwerkkonnektivität zwischen Standort C und Standort D beginnen.

Warteschlange am Fehlerpunkt

Wird die Nachricht am Fehlerpunkt in einer Warteschlange gespeichert, wird die Warteschlange in den Wiederholungszustand versetzt. Die Zustellversuche werden auf Grundlage der für die Nachricht festgelegten Wiederholungsintervalle fortgesetzt, bis die Zustellung erfolgreich oder die Nachricht abgelaufen ist. Die Warteschlange wird nach einem Standardintervall von 12 Stunden automatisch erneut zur Kategorisierung übermittelt. Warteschlangen, die einen Connector als nächstes Hopziel aufweisen, werden nur dann automatisch erneut übermittelt, wenn eine Konfigurationsänderung eintritt, die eine erneute Übermittlung verursacht. Weitere Informationen finden Sie unter Erneutes Routing von Nachrichten und die Nicht erreichbar-Warteschlange.

Sie können die Nachrichtenübermittlungs-Problembehandlung zur Unterstützung bei der Diagnose von Nachrichtenübermittlungsproblemen verwenden. Dieses Tool ist eine Komponente des MicrosoftExchange-Problembehandlungs-Assistenten und kann aus der Toolbox der Exchange-Verwaltungskonsole ausgeführt werden.

In komplexeren Topologien kann der kostengünstigste Routingpfad zwischen zwei Active Directory-Standorten zahlreiche Active Directory-Zwischenstandorte enthalten. Wenn ein Netzwerkproblem an einem frühen Punkt im Routingpfad auftritt, kann es zu ineffizient sein, das Backoff standortweise vom Ende her durchzuführen und die Zustellung an jeden der Zwischenstandorte durchzuführen. Wenn der Routingpfad länger als vier Hops ist, wird binäres Backoff implementiert, bis vier oder weniger Standorte verbleiben. Binäres Backoff bedeutet, dass der nächste Verbindungsversuch in der Mitte des Routingpfads durchgeführt wird. Wenn der kostengünstigste Routingpfad von Active Directory-Standort A zu Standort G beispielsweise "A - B - C - D - E - F - G" ist und der Netzwerkfehler an der Verknüpfung zwischen Standort B und Standort C auftritt, wird der erste Verbindungsversuch mit allen Hub-Transport-Servern an Standort G unternommen. Wenn ein Fehler bei diesem Verbindungsversuch auftritt, findet der nächste Versuch mit allen Hub-Transport-Servern an Standort D statt. Dies ist der halbe Weg bis zu Standort G. Wenn ein Fehler bei diesem Verbindungsversuch auftritt, finden Verbindungsversuche mit Standort C und Standort B statt, weil diese näher als vier Verknüpfungen am Quellstandort liegen. Die Nachricht wird letztlich auf einem Hub-Transport-Server an Standort B in einer Warteschlange gespeichert, bis die Konnektivität der Verknüpfung von B und C wiederhergestellt wurde.

Verzögerte Auffächerung

Eine einzelne E-Mail-Nachricht kann an mehrere Empfänger adressiert sein. Diese Empfänger verfügen ggf. über interne Postfächer, oder sie sind externe Empfänger. Um eine einzelne Nachricht an mehrere Empfänger weiterzuleiten, werden die folgenden Schritte ausgeführt:

1. Empfängerauflösung   Jeder Empfänger der Nachricht wird in ein Zustellungsziel aufgelöst.

2. Routing   Der kostengünstigste Routingpfad für jeden Empfänger wird bestimmt. Dabei wird auch ermittelt, ob ein Hub-Standort konfiguriert ist.

3. Nachrichtenverteilung   Um Nachrichten an Empfänger weiterzuleiten, die verschiedene Zustellungsorte aufweisen, muss die Nachricht in mehrere Kopien aufgeteilt werden.

Nachdem jeder der Empfänger aufgelöst und ein Routingpfad zu jedem Zustellungsziel bestimmt wurde, vergleicht Exchange 2010 den Routingpfad für jeden Empfänger. Um Bandbreite zu sparen, findet die Verzweigung oder Aufteilung der Nachrichten in mehrere Kopien erst bei einer Gabelung im Routingpfad statt.

Wenn z. B. mehrere Empfänger einer einzelnen Nachricht den kostengünstigsten Routingpfad teilweise oder vollständig gemeinsam verwenden, wird eine einzelne Kopie der Nachricht gesendet, bis die Nachricht den Punkt erreicht, an dem sich der Routingpfad gabelt. Sobald die Abweichung der Routingpfade erreicht wird, wird die Nachricht aufgeteilt, um eine separate Kopie für jeden Empfänger zu erstellen.

In der folgenden Abbildung wird eine einzelne Nachricht von Standort A an Empfänger an Standort C, Standort D und Standort E gesendet. Der kostengünstigste Routingpfad wird gemeinsam verwendet, bis die Nachricht Standort B erreicht. In diesem Szenario wird eine einzelne Kopie der Nachricht, die alle Empfänger enthält, mittels Relay an Standort B weitergeleitet. Dies ist die erste Gabelung im Routingpfad. Von Standort B wird eine einzelne Nachrichtenkopie an den Empfänger an Standort D weitergeleitet, und eine Kopie wird mittels Relay an Standort C weitergeleitet. An Standort C wird die Nachricht erneut aufgeteilt. Eine Kopie der Nachricht wird dem Empfänger an Standort C zugestellt. Eine weitere Kopie der Nachricht wird mittels Relay an Standort E weitergeleitet, um dem Empfänger an diesem Standort zugestellt zu werden.

Verzögerte Nachrichtenauffächerung

Zurück zum Seitenanfang

Erneutes Routing und die Nicht-erreichbar-Warteschlange

Wenn das Routing aus bestimmten Gründen keine Route für einen gültigen Empfänger bestimmen kann, werden die Nachrichten in der Nicht-erreichbar-Warteschlange gespeichert. Nachrichten in dieser Warteschlange werden erneut weitergeleitet, wenn die Konfigurationsänderungen verarbeitet und die Routingtabellen neu berechnet werden. In den folgenden Szenarien erfolgt kein erneutes Routing von Nachrichten. Stattdessen werden Unzustellbarkeitsberichte an den Absender zurückgegeben. In den folgenden Szenarien wird die Nachricht letztlich in einer Nicht-erreichbar-Warteschlange gespeichert:

• Der Empfänger ist eine Nicht-SMTP-Adresse, und ein entsprechender Connector für den Adressraum konnte nicht gefunden werden.

• Die Nachricht entspricht nicht den Beschränkungen der Nachrichtengröße aller passenden Connectors.

Nicht alle Konfigurationsänderungen erfordern das erneute Routing der Nachrichten in der Warteschlange. Aufgrund einer Änderung der Liste der Smarthosts für einen Connector erfolgt beispielsweise kein erneutes Routing der Nachrichten. Weitere Informationen zum erneuten Routing von Nachrichten finden Sie unter Erneutes Routing von Nachrichten und die Nicht erreichbar-Warteschlange.

Zurück zum Seitenanfang

 © 2010 Microsoft Corporation. Alle Rechte vorbehalten.