Erneutes Routing von Nachrichten und die Nicht erreichbar-Warteschlange

Artikel
05/13/2016

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

Letztes Änderungsdatum des Themas: 2015-03-09

In Microsoft Exchange Server 2010 sind Nachrichtenroutingszenarien möglich, in denen eine nicht zugestellte Nachricht in die Nicht-erreichbar-Warteschlange gestellt oder erneut geroutet wird.

Die Entscheidung zum erneuten Routing einer Nachricht erfolgt während der Nachrichtenzustellungsphase im SMTP-Sendeconnector. Wenn Konfigurationsänderungen auftreten, die eine erneute Übermittlung der Nachricht in der Warteschlange erfordern, wird die Nachricht für die Kategorisierung in der Nachrichtenzustellungsphase erneut übermittelt und mit den neuen Konfigurationsdaten erneut geroutet. In Abhängigkeit von der Art der Konfigurationsänderung werden einige oder alle erneut übermittelten Nachrichten möglicherweise an die Nicht-erreichbar-Warteschlange oder an eine andere Zustellungswarteschlange gesendet.

Weitere Informationen zum Berechnen des kostengünstigsten Routingpfads finden Sie unter Grundlegendes zum Nachrichtenrouting. Weitere Informationen zur Funktionsweise des Kategorisierungsmoduls finden Sie unter Grundlegendes zur Transportpipeline.

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

Erneutes Routing von Nachrichten

Es gibt zwei Arten der Nachrichtenzustellung in Exchange:

Lokale Zustellung bezieht sich auf Nachrichten, die an einen Empfänger mit einem Postfach am gleichen Active Directory-Standort wie der Hub-Transport-Server gesendet werden, auf dem die Kategorisierung erfolgt ist.
Remotezustellung bezieht sich auf die Zustellung von Nachrichten an Empfänger an anderen Active Directory-Standorten der Exchange-Organisation sowie an externe Empfänger. Remotezustellungswarteschlangen stellen den Schwerpunkt beim erneuten Routing von Nachrichten dar. Die Remotezustellung kann auf verschiedene Weisen durch Konfigurationsänderungen beeinflusst werden.

Die Routingkomponente des Kategorisierungsmoduls versucht zu erkennen, ob Nachrichten in einer Warteschlange während der erweiterten DNS-Auflösung (Domain Name System) erneut geroutet werden müssen. Während der erweiterten DNS-Auflösung versucht das Routing zu erkennen, ob eine Warteschlange erneut weitergeleitet werden muss. In dieser Phase wird das Attribut NextHopSolutionKey in eine Liste von Zielen aufgelöst. Auf diese Weise kann das Routing automatisch Konfigurationsänderungen erkennen, die das Attribut NextHopSolutionKey ungültig machen oder ändern. Wenn beim Routing erkannt wird, dass durch Konfigurationsänderungen ein erneutes Routing von Nachrichten in einer Warteschlange erforderlich ist, werden die Nachrichten in der betroffenen Warteschlange erneut an das Kategorisierungsmodul übermittelt. Außerdem wird der kostengünstigste Pfad unter Berücksichtigung der neuen Konfigurationsänderungen neu berechnet.

Der Informationsspeichertreiber, der eingehende Nachrichten an die Exchange-Datenbanken übermittelt, kann auch Nachrichten erneut routen. Eine Nachricht wird für ein erneutes Routing erneut übermittelt, wenn eine der folgenden Bedingungen zutrifft:

Die Nachricht befindet sich in einer MAPI-Zustellungswarteschlange, und der nächste Hop wurde ausgewählt, die Nachricht wurde aber noch nicht zugestellt.
Das Zielpostfach wurde auf einen anderen Postfachserver verschoben.

Wenn ein Postfachserver nicht verfügbar ist, wenn der Informationsspeichertreiber versucht, die Nachrichten an den Postfachserver zu übermitteln, dann versetzt der Informationsspeichertreiber die Nachrichtenwarteschlange in den Zustand Wiederholen. Wenn das Wiederholungsintervall nach wiederholten erfolglosen Versuchen den Postfachserver zu erreichen, abgelaufen ist, werden alle Nachrichten in der Warteschlange erneut an das Kategorisierungsmodul übermittelt.

Wenn sich eine Nachricht in einer Nicht-SMTP-Gatewayzustellungswarteschlange befindet (eine Warteschlange, die an einen Zustellungs-Agent-Connector oder an einen fremden Connector geroutet wird), ermittelt der Verbindungshandler des fremden Gateways, ob die Konfigurationsänderung ein erneutes Routing erfordert. Der Verbindungshandler des fremden Gateways ist eine Komponente des Microsoft Exchange-Transportdiensts, mit der die Zustellung von Nachrichten an Warteschlangen von Zustellungs-Agent-Connectors und an Ablageverzeichnisse von fremden Connectors verwaltet wird. Das Löschen oder Deaktivieren eines fremden Connectors erfordert z. B. das erneute Routing von Nachrichten an einen anderen Connector.

In der folgenden Liste sind die Konfigurationsänderungstypen zusammengefasst, die sich auf das Routing von Nachrichten auswirken. Jede Konfigurationsänderung wird weiter unten in diesem Thema ausführlich erläutert:

Ungültiger nächster Hop Der nächste Hop für die Nachricht wurde gelöscht oder geändert und daher ist der zuvor berechnete Routingpfad ungültig. Der nächste Hop für eine Nachricht kann ein Active Directory-Standort, ein Connector oder ein Transportserver (ein Hub-Transport-Server oder ein Edge-Transport-Server) sein.
Änderungen am nächsten Hop Die Konfiguration des nächsten Hops wurde in einer Weise geändert, die sich auf die Verbindung auswirkt. Änderungen an der Liste der Hub-Transport-Server am Active Directory-Remotestandort führen z. B. dazu, dass die Verbindung zum nächsten Hop geändert wird.
Weniger bevorzugte Routingpfade Wenn an einem zuvor berechneten Routingpfad Konfigurationsänderungen vorgenommen werden, erfolgt die Zustellung bereits gerouteter Nachrichten, wenn der Routingpfad erreichbar ist. Neue Nachrichten werden aber mit den aktualisierten Konfigurationsänderungen erneut geroutet.
Nicht verfügbarer nächster Hop Die Verfügbarkeit der Netzwerkverbindung oder des Zielservers führt dazu, dass der nächste Hop für die Verbindung nicht verfügbar ist. Der nächste Hop wird jedoch nicht geändert. Ein Beispiel hierfür ist, wenn die Hub-Transport-Server an einem Active Directory-Standort offline sind.
Weitere Szenarien mit erneutem Routing In einigen Fällen können Konfigurationsänderungen auftreten, wenn die Auflösung des DNS MX-Ressourcendatensatzes für einen DNS-Connector oder Smarthostconnector nicht erfolgreich durchgeführt werden konnte.
Konfigurationsänderungen, die zum erneuten Routing von Nachrichten oder zu Verzögerungen führen Wenn bestimmte Konfigurationsänderungen während der Nachrichtenzustellungsphase erkannt werden, finden Routingaktionen statt, und die Nachrichten werden erneut geroutet, oder die Zustellung wird verzögert.

Ungültiger nächster Hop

Konfigurationsänderungen können dazu führen, dass ein zuvor berechneter nächster Hop ungültig wird. Unter diesen Umständen kann die Routingkomponente des Kategorisierungsmoduls die Konfigurationsänderung erkennen und ein erneutes Routing durchführen, um diese Änderung auszugleichen.

Zustellung an einen SMTP-Connector auf dem lokalen Computer

Wenn eine Nachricht an einen SMTP-Connector auf dem lokalen Computer übermittelt wird, ist der Server, der die Nachricht zur Weiterleitung an dessen Ziel empfangen hat, ebenfalls der Quellserver für den Sendeconnector, über den die Nachricht geroutet wird. Diese Art der Zustellung tritt auf, wenn die beiden folgenden Bedingungen wahr sind:

Die Nachricht wurde auf einem verknüpften Empfangsconnector empfangen.
Der Empfänger besitzt eine externe Adresse und der lokale Computer ist ein Quellserver für den ausgewählten Connector.

Wenn der von der Routingkomponente des Kategorisierungsmoduls ausgewählte Sendeconnector gelöscht oder deaktiviert wird, erfolgt die Erkennung der Konfigurationsänderung während der Nachrichtenzustellungsphase. Dies führt dazu, dass alle Nachrichten in der Warteschlange erneut kategorisiert werden.

Wenn die Konfiguration des Sendeconnectors geändert wird, um den lokalen Server als Quellserver des Connectors zu entfernen, wird die Konfigurationsänderung während der Nachrichtenzustellungsphase erkannt, und alle Nachrichten in der Warteschlange werden erneut kategorisiert.

Eine Änderungen der Methode zur Adressauflösung für den Sendeconnector führt zum erneuten Routing für die Warteschlange. Ein Sendeconnector kann für die Verwendung von DNS zum Auflösen von MX-Datensätzen konfiguriert werden und Nachrichten automatisch weiterleiten oder er wird zum Routing aller Nachrichten über mindestens einen Smarthost konfiguriert. Wenn Sie die Adressauflösung für einen Sendeconnector ändern, werden die über diesen Sendeconnector gerouteten Nachrichten erneut geroutet.

SMTP-Relay an einen Active Directory-Standort

In den folgenden Szenarien erfolgt ein SMTP-Nachrichtenrelay an einem Active Directory-Standort:

Der Empfänger besitzt eine externe Adresse und mindestens einer der Quellserver für den Sendeconnector ist ein Exchange 2010-Hub-Transport-Server, der sich am lokalen Active Directory-Standort befindet.
Der Empfänger besitzt eine externe Adresse und mindestens einer der Quellserver für den Sendeconnector ist ein Exchange 2010-Edge-Transport-Server, der für den lokalen Active Directory-Standort abonniert ist.
Das Postfach des Empfängers befindet sich auf einem Server mit Exchange Server 2007 am lokalen Active Directory-Standort.
Das Postfach des Empfängers befindet sich auf einem Server, auf dem Exchange Server 2003 ausgeführt wird, und mindestens einer der Quellserver für den ausgewählten Routinggruppenconnector ist ein Exchange 2010-Hub-Transport-Server am lokalen Active Directory-Standort.
Der Empfänger ist eine Verteilergruppe, und der Server für die Aufgliederung der Verteilerlisten der Gruppe ist ein Exchange 2010-Hub-Transport-Server am lokalen Active Directory-Standort.

In den ersten vier Szenarien wird die Konfigurationsänderung während der Nachrichtenzustellungsphase erkannt, und die Warteschlange wird neu übermittelt, wenn der Sendeconnector gelöscht oder deaktiviert wurde.

Im letzten Szenario werden die Nachrichten für die Zustellung auf einem Server für die Aufgliederung der Verteilerlisten in eine Wartliste gestellt, und das Attribut NextHopSolutionKey enthält den vollständig qualifizierten Domänennamen (FQDN) des Servers für die Aufgliederung der Verteilerlisten für die Verteilergruppe. Die Konfigurationsänderung wird während der Nachrichtenzustellungsphase erkannt und die Warteschlange neu übermittelt, wenn die Hub-Transport-Serverrolle vom angegebenen Server für die Aufgliederung der Verteilerlisten deinstalliert wird.

SMTP-Relay an einen Active Directory-Remotestandort

Wenn eine Nachricht an einen Active Directory-Remotestandort übermittelt wird, stellt der nächste Hop einen anderen Active Directory-Standort als der Hub-Transport-Server dar, der die Nachricht verarbeitet. Diese Art der Zustellung tritt in den folgenden Szenarien auf:

Der Empfänger ist ein aufgelöster Benutzer, eine Postfachdatenbank oder ein Öffentlicher Ordner, und der Zielcomputer ist ein Exchange 2010-Server an einem Active Directory-Remotestandort.
Der Empfänger ist eine externe Adresse, und die Quellserver des Sendeconnectors, die für diese Adresse ausgewählt wurden, sind Exchange 2010-Server an einem Active Directory-Remotestandort.
Der Empfänger ist eine externe Adresse, und die Quellserver des fremden Connectors, die von der Routingkomponente des Kategorisierungsmoduls ausgewählt wurden, sind Exchange 2010-Server an einem Active Directory-Remotestandort.
Der Empfänger ist eine Verteilergruppe, und der Server für die Aufgliederung der Verteilerlisten ist ein Exchange 2010-Hub-Transport-Server an einem Active Directory-Remotestandort.
Das Postfach des Empfängers befindet sich auf einem Exchange 2003-Server, und der nächstgelegene Hub-Transport-Server, der als Quellserver für den ausgewählten Routinggruppenconnector aufgeführt ist, befindet sich an einem Active Directory-Remotestandort.

In diesen Szenarien wird die Konfigurationsänderung während der Nachrichtenzustellungsphase erkannt, und die Warteschlange wird neu übermittelt, wenn der Active Directory-Remotestandort gelöscht wird.

SMTP-Relay an einen Exchange 2003-Server

Wenn eine Nachricht an einen Exchange 2003-Server übermittelt wird, leitet der Exchange 2010-Hub-Transport-Server die Nachricht über einen Routinggruppenconnector an einen Exchange 2003-Server weiter. Diese Art der Zustellung tritt in den folgenden Szenarien auf:

Der Empfänger ist ein aufgelöster Benutzer, eine Postfachdatenbank oder ein Öffentlicher Ordner auf einem Exchange 2003-Server.
Der Empfänger ist eine externe Adresse, und die Quellserver für den SMTP-Connector, die für diese Adresse ausgewählt wurden, sind Exchange 2003-Server.
Der Empfänger ist eine externe Adresse, und die Quellserver für den ausgewählten fremden Connector für diese Adresse sind Exchange 2003-Server.
Der Empfänger ist eine Verteilergruppe, und der angegebene Server für die Aufgliederung der Verteilerlisten ist ein Exchange 2003-Server.

In diesen Szenarien wird die Konfigurationsänderung während der Nachrichtenzustellungsphase erkannt, und die Warteschlange wird neu übermittelt, wenn der Routinggruppenconnector gelöscht wird.

Änderungen am nächsten Hop

In einigen Szenarien wird der nächste Hop nicht für ungültig erklärt. Er wird jedoch in einer Weise geändert, die sich auf die Verbindung mit dem nächsten Hopziel auswirkt. Derartige Konfigurationsänderungen werden automatisch während der Nachrichtenzustellungsphase erkannt, und die Nachrichten werden an die neuen Ziele übermittelt.

Folgende Änderungsarten führen zu einer Update der Liste der nächsten Hopziele:

Änderungen an der Zielserverliste eines Routinggruppenconnectors
Änderungen an der Liste der Hub-Transport-Server am Active Directory-Remotestandort
Änderungen an der Liste der Hub-Transport-Server oder Edge-Transport-Server am lokalen Active Directory-Standort
Die Einführung von Hubstandorten entlang eines zuvor berechneten Routingpfads. Bei Erkennung dieser Änderung während der Nachrichtenzustellungsphase wird die an die Auflösungsanforderung zurückgegebene IP-Adressliste angepasst, sodass die Nachricht an den Hubstandort gesendet wird.

Weniger bevorzugte Routingpfade

Wenn eine Konfigurationsänderung dazu führt, dass der zuvor berechnete Routingpfad weniger berücksichtigt oder der Routingpfad aus der Überlegung ausgeschlossen wird, dann ist der Routingpfad dennoch weiterhin erreichbar, und die Nachrichten können weiterhin entlang des zuvor berechneten Routingpfads übermittelt werden. Die folgenden Konfigurationsänderungen fallen in diese Kategorie:

Einschränkungen hinsichtlich der Nachrichtengröße werden entlang des Routingpfads hinzugefügt. Dadurch werden Nachrichten, die die Größenbeschränkung überschreiten, entlang eines anderen Routingpfads geroutet werden.
Es wird ein Routingpfad mit niedrigeren Kosten oder kürzeren Wegen erstellt.
Der Adressraum des Connectors ändert sich.
Andere connectorbezogene Änderungen treten auf, z. B. das Aktivieren eines Connectors oder das Ändern eines Connectorbereichs. Wenn sich beispielsweise ein Connector, dessen Bereich von "global" in "mit Gültigkeitsbereich" geändert wird, am lokalen Active Directory-Standort befindet, hat die Änderung keine Auswirkungen. Wenn sich der Connector an einem Active Directory-Remotestandort befindet, wird die Änderung während der Nachrichtenzustellungsphase nicht erkannt, da die Nachrichten am Active Directory-Remotestandort und nicht auf dem Connector in die Warteschlange gestellt werden.
Während der Routingpfad versucht, ein SMTP-Relay zu einem Postfachserver am Active Directory-Remotestandort durchzuführen, wird der Postfachserver von einem Active Directory-Remotestandort zu einem lokalen Active Directory-Standort verschoben.
Der Routingpfad versucht, den Server für die Aufgliederung der Verteilerlisten für eine Verteilergruppe zu erreichen, während es sich nicht länger um einen Server für die Aufgliederung der Verteilerlisten handelt.

In diesen Szenarien werden die vorhandenen Nachrichten entlang des bereits berechneten Routingpfads zugestellt. Da der Routingpfad vorhanden und erreichbar ist, sind bereits geroutete Nachrichten von diesen Konfigurationsänderungen nicht betroffen. Neu übermittelte Nachrichten werden jedoch mithilfe der aktualisierten Konfiguration geroutet.

Nicht verfügbarer nächster Hop

In diesem Szenario führt eine Konfigurationsänderung oder eine Netzwerkverbindungsänderung nicht dazu, dass der nächste Hop, an den Nachrichten geroutet werden, ungültig wird. Die Konfigurationsänderung oder Netzwerkverbindungsänderung führt jedoch dazu, dass der nächste Hop nicht verfügbar ist. Das bedeutet, dass aus bestimmten Gründen keine SMTP-Verbindung mit dem nächsten Hopziel hergestellt werden kann. Mögliche Gründe:

Es wird versucht, eine SMTP-Verbindung mit einem momentan im Offlinemodus befindlichen Hub-Transport-Server am lokalen Standort herzustellen.
Ein Active Directory-Remotestandort verfügt über nicht verfügbare oder offline gestellte Hub-Transport-Server.
Eine Remoteroutinggruppe verfügt über nicht verfügbare oder im Offlinemodus befindliche Exchange 2003-Bridgeheadserver.
Remotedomänen sind aufgrund von Netzwerkverbindungsproblemen nicht verfügbar.

Die durch Netzwerkverbindungsprobleme verursachten Nachrichtenzustellungsfehler werden von der Routingkomponente des Kategorisierungsmoduls nicht erkannt. Wenn keine SMTP-Verbindung mit dem nächsten Hopziel hergestellt werden kann, versucht der SMTP-Sendeconnector, die Warteschlange erneut zu verarbeiten. Der Parameter MaxIdleTimeBeforeResubmit, der sich in der Datei "EdgeTransport.exe.config" befindet, ist auf den Standardwert "12 Stunden" festgelegt. Nachdem das konfigurierbare Wiederholungsintervall (MaxIdleTimeBeforeResubmit) abgelaufen ist, ohne die Verbindung erfolgreich einzurichten, werden alle Nachrichten aus der Zustellungswarteschlange erneut an die Übermittlungswarteschlange gesendet. Wenn das Verbindungsproblem weiterhin besteht, wird dieser Vorgang wiederholt. Wenn das Verbindungsproblem gelöst ist, werden die Nachrichten übermittelt, sobald die Nachrichtenwiederholung erfolgreich durchgeführt wurde. Auch eine Konfigurationsänderung, die das Ziel des nächsten Hops modifiziert, kann das Problem beheben. Wenn das Problem beispielsweise dadurch hervorgerufen wird, dass alle Hub-Transport-Server am Zielstandort offline sind und Sie die Postfächer auf einen Server an einem anderen Standort verschieben, würde der nächste Hop zum neuen Standort wechseln.

Hinweis

Die automatische erneute Übermittlung aus der Nachrichtenzustellungswarteschlange an die Übermittlungswarteschlange erfolgt nur für Nicht-Connectorwarteschlangen. Connectorwarteschlangen verbleiben im Wiederholungsmodus, bis das Problem behoben wurde oder die Nachrichten abgelaufen sind und ein Unzustellbarkeitsbericht gesendet wurde.

Weitere Szenarien mit erneutem Routing

Zusätzlich zu den bereits in diesem Abschnitt beschriebenen Szenarien führen die folgenden Szenarien dazu, dass für Nachrichten während der Nachrichtenzustellungsphase ein erneutes Routing erfolgt:

Die DNS MX-Auflösung schlägt für einen DNS-Connector fehl. Wenn die DNS MX-Auflösung fehlschlägt, weil der autorisierende Host für den MX-Datensatz nicht gefunden werden konnte, wird sofort ein Unzustellbarkeitsbericht für die Nachrichten in der Warteschlange gesendet. Wenn andere Fehlertypen vorhanden sind, wird die Warteschlange in den Wiederholungsmodus versetzt, bis eine Verbindung eingerichtet wurde oder die Nachrichten zeitlich ablaufen.
Die DNS MX-Auflösung schlägt für einen Smarthostconnector fehl. Die Warteschlange wird bis zum Ablauf der Nachrichten in den Wiederholungsmodus versetzt.

Konfigurationsänderungen, die zum erneuten Routing von Nachrichten oder zu Verzögerungen führen

In der folgenden Tabelle sind die Routingaktionen zusammengefasst, die ausgeführt werden, wenn bestimmte Konfigurationsänderungen während der Nachrichtenzustellungsphase erkannt und Nachrichten erneut geroutet werden oder die Zustellung verzögert wird.

Konfigurationsänderungen, die zum erneuten Routing von Nachrichten und zu Verzögerungen führen

Die Nachricht wird an einen auf dem lokalen Server konfigurierten DNS-Connector geroutet.

Konfigurationsänderung	Routingaktion
Der Connector wird gelöscht.	Die Warteschlange wird erneut übermittelt.
Der Connector wird in einen Smarthostconnector geändert.	Die Warteschlange wird erneut übermittelt.
Der Connector wird geändert, um den lokalen Server aus der Quellserverliste zu entfernen.	Die Warteschlange wird erneut übermittelt.
Es tritt ein schwerwiegender DNS MX-Auflösungsfehler auf.	Es wird ein Unzustellbarkeitsbericht gesendet.
Es tritt ein nicht schwerwiegender DNS MX-Auflösungsfehler auf.	Die Warteschlange wird bis zum Ablauf der Nachrichten wiederholt versucht.
Der Connector wird deaktiviert.	Die Warteschlange wird erneut übermittelt.

Die Nachricht wird an einen auf dem lokalen Server konfigurierten Smarthostconnector geroutet.

Konfigurationsänderung	Routingaktion
Der Connector wird gelöscht.	Die Warteschlange wird erneut übermittelt.
Der Connector wird geändert, um den lokalen Server aus der Quellserverliste zu entfernen.	Die Warteschlange wird erneut übermittelt.
Der Connector wird in einen DNS-Connector geändert.	Die Warteschlange wird erneut übermittelt.
Die Smarthostliste für den Connector wird geändert.	Die aktualisierte Smarthostliste wird automatisch erkannt und während der Nachrichtenzustellungsphase verwendet.
Es tritt ein DNS MX-Auflösungsfehler auf.	Die Warteschlange wird bis zum Ablauf der Nachrichten wiederholt versucht.
Der Connector wird deaktiviert.	Die Warteschlange wird erneut übermittelt.
Der SMTP-Server ist offline, oder das Ziel wird nicht auf einem SMTP-Server ausgeführt.	Die Warteschlange wird bis zum Ablauf der Nachrichten wiederholt versucht.

Die Nachricht wird an einen Connector mit einem Hub-Transport- oder Edge-Transport-Quellserver am lokalen Active Directory-Standort geroutet.

Konfigurationsänderung	Routingaktion
Der Connector wird gelöscht.	Die Warteschlange wird erneut übermittelt.
Die Quellserverliste für den Connector wird geändert, um Hub-Transport-Server oder Edge-Transport-Server am lokalen Active Directory-Standort zu entfernen oder hinzuzufügen.	Änderungen an Quellservern am lokalen Standort werden automatisch erkannt und während der Nachrichtenzustellungsphase verwendet.
Die Quellserverliste für den Connector wird geändert, um alle Hub-Transport-Server oder Edge-Transport-Server am lokalen Active Directory-Standort zu entfernen.	Die Warteschlange wird erneut übermittelt.

Die Nachricht wird an einen Server für die Aufgliederung der Verteilerlisten für eine Verteilergruppe am lokalen Active Directory-Standort geroutet.

Konfigurationsänderung	Routingaktion
Der Server ist nicht mehr für die Hub-Transport-Serverrolle konfiguriert.	Die Warteschlange wird erneut übermittelt.

Die Nachricht wird an einen Transportserver am lokalen Active Directory-Standort geroutet.

Konfigurationsänderung	Routingaktion
Der Server ist offline, oder der Microsoft Exchange-Transportdienst wird nicht ausgeführt.	Die Warteschlange wird nach einem Intervall erneut übermittelt.

Die Nachricht wird an einen Active Directory-Remotestandort geroutet.

Konfigurationsänderung	Routingaktion
Der Active Directory-Remotestandort wird gelöscht.	Die Warteschlange wird erneut übermittelt.
Der Link zum Active Directory-Remotestandort wird gelöscht. Daher ist dieser Standort für den lokalen Standort nicht mehr erreichbar.	Die Warteschlange wird erneut übermittelt.
Die Liste der Hub-Transport-Server am Active Directory-Remotestandort wird geändert.	Änderungen werden automatisch erkannt und während der Nachrichtenzustellungsphase übernommen.
Alle Hub-Transport-Server am Active Directory-Remotestandort werden entfernt.	Die Warteschlange wird erneut übermittelt.
Hubstandorte werden entlang des Routingpfads des Active Directory-Zielstandorts eingeführt.	Änderungen werden automatisch erkannt und während der Nachrichtenzustellungsphase übernommen, sodass die Nachrichten an den Hubstandort weitergeleitet werden.
Alle Hub-Transport-Server am Active Directory-Remotestandort sind offline.	Die Warteschlange wird nach einem Intervall erneut übermittelt.
Der Remotestandort ist der verzögerte Auffächerungspunkt, und alle Hub-Transport-Server am Standort sind offline.	Die Warteschlange wird nach einem Intervall erneut übermittelt.

Die Nachricht wird an einen Exchange 2003-Server in einer Remoteroutinggruppe geroutet.

Konfigurationsänderung	Routingaktion
Der Connector wird gelöscht.	Die Warteschlange wird erneut übermittelt.
Die Liste der Hub-Transport-Server für den Connector ändert sich, um den lokalen Server aus der Liste zu entfernen.	Die Warteschlange wird erneut übermittelt.
Die Liste der Zielbridgeheadserver für den Connector wird durch Entfernen oder Hinzufügen von Bridgeheadservern aus der bzw. zur Remoteroutinggruppe geändert.	Änderungen werden automatisch erkannt und während der Nachrichtenzustellungsphase übernommen.
Alle Exchange 2003-Bridgeheadserver in der Remoteroutinggruppe sind offline.	Die Warteschlange wird bis zum Ablauf der Nachrichten wiederholt versucht.

Die Nachricht wird an ein Ziel geroutet, und es sind Konfigurationsänderungen vorhanden, das Ziel ist jedoch weiterhin erreichbar.

Konfigurationsänderung	Routingaktion
Der Routingpfad wird weniger berücksichtigt, da ein neuer Routingpfad mit niedrigeren Kosten oder kürzeren Wegen bzw. mit beidem vorhanden ist.	Änderungen werden automatisch erkannt und während der Nachrichtenzustellungsphase übernommen.
Der Routingpfad wird für eine Nachricht entfernt, da entlang des Pfads Einschränkungen hinsichtlich der maximalen Nachrichtengröße hinzugefügt werden.	Änderungen werden automatisch erkannt und während der Nachrichtenzustellungsphase übernommen.
Ein zuvor deaktivierter Routingpfad mit verringerten Kosten wird in Erwägung gezogen, da der Connector aktiviert ist, in den Geltungsbereich zurückversetzt wurde oder keine Einschränkungen hinsichtlich der Nachrichtengröße aufweist.	Änderungen werden automatisch erkannt und während der Nachrichtenzustellungsphase übernommen.
Der Connectoradressraum ändert sich.	Änderungen werden automatisch erkannt und während der Nachrichtenzustellungsphase übernommen.
Der Connector wird geändert, um lokale Hub-Transport- oder Edge-Transport-Server zur Quellserverliste hinzuzufügen.	Änderungen werden automatisch erkannt und während der Nachrichtenzustellungsphase übernommen.
Die Nachricht wird an einen Postfachserver am Active Directory-Remotestandort weitergeleitet, während der Postfachserver, der die Zielpostfachdatenbank enthält, an einen anderen Standort verschoben wird.	Änderungen werden automatisch erkannt und während der Nachrichtenzustellungsphase übernommen.
Die Nachricht wird an einen Verteilergruppenserver für die Aufgliederung der Verteilerlisten weitergeleitet, wenn es sich bei diesem nicht länger um einen Server für die Aufgliederung der Verteilerlisten handelt. (Das Attribut HomeMTA der Verteilergruppe wird geändert.)	Änderungen werden automatisch erkannt und während der Nachrichtenzustellungsphase übernommen.

Die Nachricht wird mithilfe der MAPI-Zustellung an einen Postfachserver geroutet.

Konfigurationsänderung	Routingaktion
Das Postfach wird auf einen anderen Postfachserver verschoben.	Der Informationsspeichertreiber erkennt die Änderung und übermittelt die Nachrichten erneut.
Der Postfachserver ist offline.	Die Warteschlange wird wiederholt versucht und nach einem Intervall erneut übermittelt.

Die Nachricht wird mithilfe eines Nicht-SMTP-Gateways an einen Nicht-SMTP-Connector geroutet, der auf dem lokalen Server konfiguriert ist.

Konfigurationsänderung	Routingaktion
Ein fremder Connector wird gelöscht.	Die Warteschlange wird erneut übermittelt.
Ein fremder Connector wird geändert, um den lokalen Server aus der Quellserverliste zu entfernen.	Die Warteschlange wird erneut übermittelt.
Der Connector wird deaktiviert.	Die Warteschlange wird erneut übermittelt.
Das Ablageverzeichnis wurde nicht gefunden.	Die Warteschlange wird bis zum Ablauf der Nachrichten wiederholt versucht.

Nicht-erreichbar-Warteschlange

In der Nicht-erreichbar-Warteschlange befinden sich Nachrichten, die nicht an die jeweiligen Ziele weitergeleitet werden können. Ein nicht erreichbares Ziel wird in der Regel durch falsch geschriebene E-Mail-Adressen oder durch Konfigurationsänderungen verursacht, durch die sich der Routingpfad für die Zustellung geändert hat. Unabhängig vom Ziel werden alle Nachrichten mit nicht erreichbaren Empfängern in dieser Warteschlange abgelegt.

Die Entscheidung, eine Nachricht in die Nicht-erreichbar-Warteschlange zu stellen, wird während der Routingphase der Kategorisierung getroffen. Wenn ein Routingpfad während der Routingphase nicht für eine Nachricht berechnet werden kann, wird die Nachricht an die Nicht-erreichbar-Warteschlange gesendet. Für Nachrichten in der Nicht-erreichbar-Warteschlange erfolgt nach der Verarbeitung von Konfigurationsänderungen ein erneutes Routing. Für jeden Exchange 2010-Transportserver gibt es nur eine Nicht-erreichbar-Warteschlange.

Während der Kategorisierung werden Nachrichten in die Nicht-erreichbar-Warteschlange gestellt, wenn die folgenden Bedingungen wahr sind:

Der Empfänger ist ein gültiges Active Directory-Empfängerobjekt. Für diesen Empfänger kann jedoch kein Routingpfad berechnet werden.
Der Empfänger ist eine externe SMTP-Adresse, und für den Adressraum konnte kein entsprechender Connector gefunden werden. Ein entsprechender Connector kann auch von der Routingkomponente des Kategorisierungsmoduls ignoriert werden, wenn er deaktiviert oder falsch konfiguriert ist.
Der Empfänger ist eine Verteilergruppe. Der Server für die Aufgliederung der Verteilerlisten für die Verteilergruppe ist ungültig, oder die Hub-Transport-Serverrolle ist auf diesem Server nicht installiert.
Der Empfänger ist ein SMTP-Adressempfänger einer Nachricht, die auf einem Empfangsconnector empfangen wurde, der mit einem Sendeconnector verknüpft ist, der von der Routingkomponente des Kategorisierungsmoduls ignoriert wird, weil er deaktiviert oder falsch konfiguriert ist.

In den folgenden Szenarien werden Nachrichten nicht in die Nicht-erreichbar-Warteschlange gestellt, und stattdessen werden Unzustellbarkeitsberichte gesendet:

Der Routingpfad kann für einen Empfänger nicht berechnet werden, da Einschränkungen (z. B. der Nachrichtengröße) die Zustellung der Nachricht mithilfe einer einzelnen, deterministischen Route verhindern, die vom Kategorisierungsmodul berechnet wurde.
Der Empfänger ist eine Nicht-SMTP-Adresse, und ein entsprechender Connector konnte nicht gefunden werden. Oder der entsprechende Connector ist deaktiviert oder falsch konfiguriert.
Der Empfänger ist ein Nicht-SMTP-Adressempfänger einer Nachricht, die auf einem Empfangsconnector empfangen wurde, der mit einem Sendeconnector verknüpft ist, der von der Routingkomponente des Kategorisierungsmoduls ignoriert wird, weil der Sendeconnector deaktiviert oder falsch konfiguriert ist.

Die Nachrichten in der Nicht-erreichbar-Warteschlange werden erneut an das Kategorisierungsmodul gesendet, wenn die Routingtabellen aufgrund von Konfigurationsänderungen neu erstellt werden. Die alten und die neuen Routingtabellen werden verglichen. Die Nicht-erreichbar-Warteschlange wird nur erneut übermittelt, wenn die alten und die neuen Routingtabellen nicht übereinstimmen.

Szenarien, in denen Nachrichten in die Nicht-erreichbar-Warteschlange gestellt werden

In diesem Abschnitt werden einige Szenarien beschrieben, in denen Nachrichten in die Nicht-erreichbar-Warteschlange gestellt werden.

Zwischen einer Exchange 2010-Organisation und einer Exchange 2003-Organisation ist kein Routinggruppenconnector vorhanden.
Zwischen der Exchange 2010-Routinggruppe und den Exchange 2003-Routinggruppen wurde kein Routinggruppenconnector konfiguriert, oder der letzte Routinggruppenconnector zwischen der Exchange 2010-Routinggruppe und den Exchange 2003-Routinggruppen wurde entfernt. Es ist keine Routinggruppe vorhanden, die einen Routingpfad zu den Exchange 2003-Empfängern bereitstellt. Zur Behebung dieses Problems müssen Sie zuerst überprüfen, ob kein Routinggruppenconnector vorhanden ist. Wenn dies der Fall ist, können Sie einen Routinggruppenconnector erstellen. Weitere Informationen finden Sie unter Erstellen von zusätzlichen Routinggruppenconnectors von Exchange 2010 zu Exchange 2003. Wenn ein Routinggruppenconnector vorhanden ist, befindet sich die Nachricht aus einem anderen Grund in der Nicht-erreichbar-Warteschlange. Überprüfen Sie die Konfiguration des Routinggruppenconnectors.

Der Active Directory-Zielstandort verfügt über keine Hub-Transport-Server.
Der Active Directory-Zielstandort verfügt über keine Hub-Transport-Server. In diesem Szenario werden Nachrichten an Empfänger an diesem Standort an die Nicht-erreichbar-Warteschlange gesendet. Stellen Sie einen Hub-Transport-Server am Active Directory-Standort bereit, um dieses Problem zu beheben. Weitere Informationen finden Sie unter Übersicht über die Hub-Transport-Serverrolle.

Zwischen zwei Active Directory-Standorten ist kein Active Directory-Standortlink vorhanden.
Es wurde ein Active Directory-Standortlink entfernt, und daher enthält ein getrennter Active Directory-Standort Exchange 2010-Server. Erstellen Sie einen Active Directory-Standortlink mithilfe der Active Directory-Standorte und -Dienste, um das Problem zu beheben.

Andere Probleme
Wenn eine Nachricht in die Nicht-erreichbar-Warteschlange gestellt wird, gibt die letzte Fehlermeldung an, warum die Nachricht in die Nicht-erreichbar-Warteschlange gestellt wurde. Wenn mehrere Empfänger derselben Nachricht in die Nicht-erreichbar-Warteschlange geroutet werden, dies aber aus unterschiedlichen Gründen geschieht, gibt der letzte verfügbare Fehler der einzelnen Empfänger den jeweiligen Grund an. Wenn während der Berechnung der Routingtabelle Inkonsistenzen auftreten, werden die Ereignisse im Anwendungsprotokoll der Windows-Ereignisanzeige aufgezeichnet. Anhand der letzten Fehlermeldung und mithilfe dieser Ereignisse können Sie den Konfigurationsfehler ermitteln und Korrekturen vornehmen, sodass die Nachrichten in der Nicht-erreichbar-Warteschlange erfolgreich geroutet werden können.

Sie können auch manuell erzwingen, dass Nachrichten in Warteschlangen erneut übermittelt werden. Weitere Informationen finden Sie unter Erneutes Übermitteln von Nachrichten in Warteschlangen.