Erneutes Routing von Nachrichten und die Nicht erreichbar-Warteschlange
Gilt für: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Letztes Änderungsdatum des Themas: 2007-08-14
In diesem Thema werden Microsoft Exchange Server 2007-Szenarien zum Routing von Nachrichten beschrieben, in denen eine nicht zugestellte Nachricht aus einem der folgenden Gründe in die Nicht erreichbar-Warteschlange gestellt wird:
Ein Routingpfad konnte nicht ermittelt werden.
Für die Nachricht erfolgt ein erneutes Routing.
Wenn Sie den Nachrichtenfluss nachverfolgen oder Warteschlangen für Transportnachrichten mithilfe der Warteschlangenanzeige überwachen, ist es hilfreich zu verstehen, unter welchen Bedingungen Nachrichten in die Nicht erreichbar-Warteschlange gestellt oder erneut geroutet werden. Wenn eine Nachricht erneut umgeleitet wird, erfolgt eine erneute Übermittlung in die Übermittlungswarteschlange, um den aktuellen Routingpfad mit den geringsten Kosten zu ermitteln. Das Kategorisierungsmodul ermittelt den Routingpfad.
Hinweis
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 in die Nicht erreichbar-Warteschlange gesendet.
Die Entscheidung zum erneuten Routing einer Nachricht erfolgt während der Nachrichtenübermittlungsphase im SMTP-Sendeconnector. Wenn Konfigurationsänderungen auftreten, die eine erneute Übermittlung der Nachricht in der Warteschlange erfordern, dann wird die Nachricht für die erneute Kategorisierung in der Nachrichtenübermittlungsphase erneut übermittelt und mit den neuen Konfigurationsdaten erneut umgeleitet. In Abhängigkeit von der Art der Konfigurationsänderung werden einige oder alle erneut übermittelten Nachrichten möglicherweise in die Nicht erreichbar-Warteschlange oder in eine andere Zustellungswarteschlange gesendet.
Weitere Informationen zum Berechnen des kostengünstigsten Routingpfads finden Sie unter Informationen zum auf Active Directory-Standorten basierenden Routing. Weitere Informationen zur Funktionsweise des Kategorisierungsmoduls finden Sie unter Transportarchitektur.
Exchange 2007-Transportserver erkennen Konfigurationsänderungen, die möglicherweise die Art des Routing von Nachrichten verändern. Weitere Informationen zum Routing von Nachrichten in einer Exchange 2007-Organisation mithilfe des Active Directory-basierten Standortrouting finden Sie unter Informationen zum auf Active Directory-Standorten basierenden Routing. Weitere Informationen zur Problembehandlung bei Nachrichtenübermittlungsproblemen mithilfe der Warteschlangenanzeige und anderer Tools finden Sie unter den folgenden Themen:
Problembehandlung bei Nachrichtenzustellungsfehlern in Exchange 2007
The Exchange 2007 Wiki: Troubleshooting Exchange 2007 Transport Queuing Problems
Hinweis
Die Inhalte von Wiki-Einträgen und Blogs und ihre zugehörigen URLs können ohne vorherige Ankündigung geändert werden.
Szenarien mit erneutem Routing
Remotezustellungswarteschlangen stellen den Schwerpunkt beim erneuten Routing von Nachrichten dar. Lokale Übermittlung bezieht sich auf Nachrichten, die an einen Empfänger mit einem Postfach am gleichen Active Directory-Verzeichnisdienststandort wie der Hub-Transport-Server gesendet werden, auf dem die Kategorisierung erfolgt ist. Remoteübermittlung bezieht sich auf die Übermittlung von Nachrichten an Empfänger in einer Exchange-Organisation sowie an externe Empfänger. Die Remoteübermittlung umfasst das Routing an Active Directory-Remotestandorte, an Legacyroutinggruppen und an Remotedomänen. Die Remoteübermittlung 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. Das erweiterte DNS ist eine Komponente des Microsoft Exchange-Transportdiensts. Während der erweiterten DNS-Auflösung wird die Auswahl des nächsten Hops in eine Liste von Zielservernamen aufgelöst. Der nächste Hop ist eine während der Kategorisierung als NextHopSolutionKey-Attribut in der Nachricht gekennzeichnete Eigenschaft. Die Routingkomponente des Nachrichtenkategorisierungsmoduls versucht Konfigurationsänderungen zu erkennen, die eine erneute Übermittlung von Nachrichten in der Warteschlangen erfordern.
Der Informationsspeichertreiber ist eine Komponente des Hub-Transport-Servers, die eingehende Nachrichten an die Exchange-Datenbanken übermittelt. Der Informationsspeichertreiber übermittelt die Nachricht für ein erneutes Routing erneut, wenn eine der folgenden Bedingungen erfüllt ist:
Es befindet sich eine Nachricht in der MAPI-Zustellungswarteschlange und der nächste Hop wurde ausgewählt. Die Nachricht wurde aber noch nicht übermittelt.
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, d. h. in einer Warteschlange, die an einen fremden Connector geroutet wird, dann 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, die die Zustellung von Nachrichten in DROP-Verzeichnisse verwaltet, die für die Verwendung durch fremde Connectors konfiguriert sind. Das Löschen oder Deaktivieren eines fremden Connectors erfordert z. B. das erneute Routing von Nachrichten an einen anderen Connector.
Verschiedene Arten von Konfigurationsänderungen wirken sich auf das Routing von Nachrichten aus. Weiter unten in diesem Abschnitt erfolgt eine Erläuterung zur Behandlung dieser Änderungen durch den Microsoft Exchange-Transportdienst sowie zu den Auswirkungen dieser Änderungen auf die Nachrichtenübermittlung. In der folgenden Liste sind die Arten der Konfigurationsänderungen zusammengefasst:
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 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, werden bereits geroutete Nachrichten übermittelt, 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ühren dazu, dass der nächste Hop für die Verbindung nicht verfügbar ist. Der nächste Hop ändert sich jedoch nicht. Ein Beispiel hierfür ist, wenn die Hub-Transport-Server an einem Active Directory-Standort offline sind.
Sonderfälle In einigen Fällen können Konfigurationsänderungen auftreten, wenn die DNS MX-Auflösung für einen DNS-Connector oder Smarthostconnector nicht erfolgreich durchgeführt werden konnte.
Eine vollständige Liste spezifischer Konfigurationsänderungen, die sich auf das Routing von Nachrichten auswirken, finden Sie später in diesem Thema in der Tabelle Konfigurationsänderungen, die zum erneuten Routing von Nachrichten und zu Verzögerungen führen.
Ungültige nächste Hops
In diesem Abschnitt werden die Konfigurationsänderungen beschrieben, die dazu führen können, 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.
Übermittlung 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 Übermittlung 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 Übermittlungsphase der Nachricht. Dies führt dazu, dass alle Nachrichten in der Warteschlange erneut kategorisiert werden müssen.
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 Übermittlungsphase der Nachricht 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, erfolgt für die über diesen Sendeconnector gerouteten Nachrichten ein erneutes Routing.
SMTP-Relay an einen Active Directory-Standort
Das SMTP-Nachrichtenrelay erfolgt in den folgenden Szenarien an einem Active Directory-Standort:
Der Empfänger besitzt eine externe Adresse und mindestens einer der Quellserver für den Sendeconnector ist ein Exchange 2007-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 2007-Edge-Transport-Server, der für den lokalen Active Directory-Standort abonniert ist.
Das Postfach des Empfängers befindet sich auf einem Server, der Microsoft Exchange Server 2003 ausführt und mindestens einer der Quellserver für den ausgewählten Routingruppenconnector ist ein Exchange 2007-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 2007-Hub-Transport-Server am lokalen Active Directory-Standort.
In den ersten drei Szenarien wird die Konfigurationsänderung während der Nachrichtenübermittlungsphase erkannt und die Warteschlange neu übermittelt, wenn der Sendeconnector gelöscht oder deaktiviert wurde.
Im vierten Szenario werden die Nachrichten für die Übermittlung 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 Nachrichtenübermittlungsphase erkannt und die Warteschlange neu übermittelt, wenn die Serverfunktion Hub-Transport 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 den Hub-Transport-Server dar, der die Nachricht verarbeitet. Diese Art der Übermittlung 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 2007-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 2007-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 2007-Server an einem Active Directory-Remotestandort.
Der Empfänger ist eine Verteilergruppe und der Server für die Aufgliederung der Verteilerlisten ist ein Exchange 2007-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 Nachrichtenübermittlungsphase erkannt und die Warteschlange 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 2007-Hub-Transport-Server die Nachricht über einen Routinggruppenconnector an einen Exchange 2003-Server weiter. Diese Übermittlungsart tritt in den folgenden Szenarien auf:
Der Empfänger ist ein aufgelöster Benutzer, eine Postfachdatenbank oder ein Öffentlicher Ordner, der/die sich auf einem Exchange 2003-Server befindet.
Der Empfänger ist eine externe Adresse. Außerdem sind die Quellserver für den SMTP-Connector, die für diese Adresse ausgewählt wurden, Exchange 2003-Server.
Der Empfänger ist eine externe Adresse. Außerdem sind die Quellserver für den ausgewählten fremden Connector für diese Adresse Exchange 2003-Server.
Der Empfänger ist eine Verteilergruppe. Außerdem ist der ausgewiesene Server für die Aufgliederung der Verteilerlisten ein Exchange 2003-Server.
In diesen Szenarien wird die Konfigurationsänderung während der Nachrichtenübermittlungsphase erkannt und die Warteschlange neu übermittelt, wenn der Routinggruppenconnector gelöscht wird.
Änderungen am nächsten Hop
In einige 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 zum Ziel des nächsten Hops auswirkt. Derartige Konfigurationsänderungen werden automatisch während der Nachrichtenübermittlungsphase aufgenommen und die Nachrichten an die neuen Ziele übermittelt.
Folgende Änderungsarten führen zu einer Aktualisierung 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
Änderungen an der Liste der Smarthosts auf einem Smarthostconnector
Die Einführung von Hubstandorten entlang eines zuvor berechneten Routingpfads. Wenn diese Änderung während der Nachrichtenübermittlungsphase erkannt wird, 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 wird oder der Routingpfad aus der Überlegung ausgeschlossen wird, dann ist der Routingpfad dennoch weiterhin erreichbar und die Nachrichten werden entlang des zuvor berechneten Routingpfads übermittelt. 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 der Connector, dessen Geltungsbereich beispielsweise von "global" zu "mit Gültigkeitsbereich" wechselt, im 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 Nachrichtenübermittlungsphase 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 Nachrichten entlang des bereits berechneten Routingpfads übermittelt. 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 ungültig wird, zu dem Nachrichten geroutet werden. Die Konfigurationsänderung oder Netzwerkverbindungsänderung führt jedoch dazu, dass der nächste Hop nicht verfügbar ist. Das bedeutet, dass eine SMTP-Verbindung zum nächsten Hopziel aus bestimmten Gründen nicht eingerichtet werden kann. Mögliche Gründe:
Es wurde versucht, eine SMTP-Verbindung zu einem momentan offline 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 offline gestellte Exchange 2003- oder Microsoft Exchange 2000 Server-Bridgeheadserver.
Remotedomänen sind aufgrund von Netzwerkverbindungsproblemen nicht verfügbar.
Die von Netzwerkverbindungsproblemen hervorgerufenen Nachrichtenübermittlungsfehler werden von der Routingkomponente des Kategorisierungsmoduls nicht erkannt. Wenn eine SMTP-Verbindung zum nächsten Hopziel nicht eingerichtet werden kann, versucht der SMTP-Sendeconnector die Warteschlange erneut zu verarbeiten. Der Parameter MaxIdleTimeBeforeResubmit, der sich in der Datei EdgeTransport.exe.config befindet, besitzt die Standardeinstellung von 12 Stunden. Nachdem das konfigurierbare Wiederholungsintervall (MaxIdleTimeBeforeResubmit) abgelaufen ist, ohne die Verbindung erfolgreich einzurichten, werden alle Nachrichten aus der Zustellungswarteschlange erneut in 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 in 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 Nachrichtenübermittlungsphase 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, da der autorisierende Host für den MX-Datensatz nicht gefunden wurde, 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 durchgeführt werden, wenn bestimmte Konfigurationsänderungen während der Nachrichtenübermittlungsphase erkannt und Nachrichten erneut geroutet werden oder die Übermittlung verzögert wird.
Konfigurationsänderungen, die zum erneuten Routing von Nachrichten und zu Verzögerungen führen
| Routingszenario | Konfigurationsänderung und Routingaktion | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Die Nachricht wird an einen auf dem lokalen Server konfigurierten DNS-Connector geroutet. |
|
||||||||||||||||
Die Nachricht wird an einen auf dem lokalen Server konfigurierten Smarthostconnector geroutet. |
|
||||||||||||||||
Die Nachricht wird an einen Connector mit einem Hub-Transport- oder Edge-Transport-Quellserver am lokalen Active Directory-Standort geroutet. |
|
||||||||||||||||
Die Nachricht wird an einen Server für die Aufgliederung der Verteilerlisten für eine Verteilergruppe am lokalen Active Directory-Standort geroutet. |
|
||||||||||||||||
Die Nachricht wird an einen Transportserver am lokalen Active Directory-Standort geroutet. |
|
||||||||||||||||
Die Nachricht wird an einen Active Directory-Remotestandort geroutet. |
|
||||||||||||||||
Die Nachricht wird an einen Exchange 2003-Server in einer Remoteroutinggruppe geroutet. |
|
||||||||||||||||
Die Nachricht wird an ein Ziel geroutet und es sind Konfigurationsänderungen vorhanden, aber das Ziel ist weiterhin erreichbar. |
|
||||||||||||||||
Die Nachricht wird mithilfe der MAPI-Zustellung an einen Postfachserver geroutet. |
|
||||||||||||||||
Die Nachricht wird mithilfe eines Nicht-SMTP-Gateways an einen Nicht-SMTP-Connector geroutet, der auf dem lokalen Server konfiguriert ist. |
|
Nicht erreichbar-Warteschlange
Jeder Transportserver darf nur eine Nicht erreichbar-Warteschlange haben. In dieser Warteschlange befinden sich Nachrichten, die nicht an ihre Ziele weitergeleitet werden können. Ein nicht erreichbares Ziel wird in der Regel durch Konfigurationsänderungen verursacht, durch die sich der Routingpfad für die Zustellung verändert hat. Unabhängig vom Ziel werden alle Nachrichten mit nicht erreichbaren Empfängern in dieser Warteschlange abgelegt. Weitere Informationen zu Warteschlangen finden Sie unter Verwalten von Warteschlangen.
Wie bereits in diesem Thema erläutert, wird die Entscheidung, eine Nachricht in die Nicht erreichbar-Warteschlange zu stellen, 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 in 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 2007-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 ein entsprechender Connector für den Adressraum konnte nicht gefunden werden. Ein übereinstimmender Connector kann auch von der Routingkomponente des Kategorisierungsmoduls ignoriert werden, da dieser deaktiviert oder falsch konfiguriert ist.
Der Empfänger ist eine Verteilergruppe. Außerdem ist der Server für die Aufgliederung der Verteilerlisten für die Verteilergruppe ungültig oder auf diesem ist die Serverfunktion Hub-Transport 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, da er auf gewisse Weise deaktiviert oder falsch konfiguriert ist.
In den folgenden Szenarien werden Nachrichten nicht in die Nicht erreichbar-Warteschlange gestellt. 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, da der Sendeconnector deaktiviert oder falsch konfiguriert ist.
Die Entscheidung zum erneuten Routing einer Nachricht erfolgt nach der Kategorisierung und während der Nachrichtenübermittlungsphase. Die Entscheidung, eine Nachricht in die Nicht erreichbar-Warteschlange zu stellen, wird in der Routingphase der Kategorisierung getroffen. Eine erneut geroutete Nachricht kann in die Nicht erreichbar-Warteschlange gestellt werden, wenn die Konfigurationsänderungen dazu führen, dass der ermittelte Routingpfad ungültig wird. Nicht erreichbar-Warteschlangen werden in der Warteschlangenanzeige angezeigt und sind mit dem Zustellungstyp "Nicht erreichbar" gekennzeichnet. Weitere Informationen zur Behandlung von Problemen mit der Nicht erreichbar-Warteschlange und anderen Nachrichtenflussproblemen finden Sie auch unter den folgenden Themen:
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 2007-Organisation und einer Exchange 2003-Organisation ist kein Routinggruppenconnector vorhanden.
Zwischen der Exchange 2007-Routinggruppe und den Exchange 2003-Routinggruppen wurde kein Routinggruppenconnector konfiguriert oder der letzte Routinggruppenconnector zwischen der Exchange 2007-Routinggruppe und den Exchange 2003-Routinggruppen wurde entfernt. Es ist keine Routinggruppe vorhanden, die einen Routingpfad zu den Exchange 2003-Empfängern bereitstellt. Damit dieses Problem behoben wird, überprüfen Sie, dass kein Routinggruppenconnector vorhanden ist, bevor Sie mithilfe des Cmdlets New-RoutingGroupConnector einen neuen Routinggruppenconnector definieren. Weitere Informationen finden Sie unter Erstellen von Routinggruppenconnectors von Exchange 2007 zu Exchange Server 2003 und New-RoutingGroupConnector. Wenn ein Routinggruppenconnector vorhanden ist, befindet sich die Nachricht aus einem anderen Grund in der Nicht erreichbar-Warteschlange. Weitere Informationen zur Koexistenz von Routinggruppenconnectors finden Sie unter "Erstellen zusätzlicher Routinggruppenconnectors" in Nachrichtenrouting in einer Koexistenzumgebung.
- 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 in 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 Serverfunktion "Hub-Transport": Übersicht.
- 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 2007-Server. Erstellen Sie einen neuen 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. Die letzte Fehlermeldung und diese Ereignisse helfen dem Administrator den Konfigurationsfehler zu ermitteln und Korrekturen vorzunehmen, damit die Nachrichten in der Nicht erreichbar-Warteschlange erfolgreich geroutet werden können.Ein Administrator kann auch manuell veranlassen, dass Nachrichten in der Warteschlange erneut übermittelt werden. Verwenden Sie das Cmdlet Retry-Queue zusammen mit dem Parameter Resubmit, damit die Nachrichten in der Warteschlange manuell erneut an das Kategorisierungsmodul übermittelt werden. Weitere Informationen finden Sie unter Erneutes Übermitteln von Nachrichten in Warteschlangen.
Weitere Informationen
Weitere Informationen hierzu finden Sie unter den folgenden Themen: