Problembehandlung beim Routing

Letztes Änderungsdatum des Themas: 2006-03-15

In diesem Thema werden allgemeine Situationen erläutert, in denen das Routing in der Microsoft® Exchange-Organisation unterbrochen wird. Folgende Themen werden behandelt:

• Verwenden von WinRoute
  In diesem Abschnitt werden die Vorteile des WinRoute-Tools bei der Behebung von Routingproblemen erläutert.
• Allgemeine Verbindungsstatusprobleme
  In diesem Abschnitt werden die Probleme auf Grund von getrennten Verbindungen zwischen Routinggruppen, Konflikten von Routinggruppenmastern, gelöschten Routinggruppen, nicht als verfügbar markierten Connectors und oszillierenden Verbindungen erläutert und ihre Behebung erläutert.
• Unterbrochene Verbindungsstatusübermittlung
  In diesem Abschnitt werden die Probleme beim Ändern eines Routinggruppen-Bridgeheadservers von Exchange Server, Version 5.5, in einen Server mit Exchange 2000 oder einen Bridgeheadserver mit Exchange Server 2003 und anschließendem erneuten Ändern in einen Server mit Exchange 5.5 erläutert.

Verwenden von WinRoute

WinRoute ist ein Exchange 2003-Tool, mit dem Sie die Routingtopologie und die Verbindungsstatus-Routinginformationen ermitteln, die dem Routingmaster bekannt sind. Verwenden Sie dieses Tool als ersten Schritt bei der Behandlung von Routingproblemen in einer Exchange 2000- und Exchange 2003-Messagingumgebung. Das Tool stellt die Verbindung zum Verbindungsstatusanschluss (TCP-Anschluss 691) auf Exchange 2000- oder Exchange 2003-Servern her und extrahiert die Verbindungsstatusinformationen einer Organisation. Die Informationen liegen als eine Reihe von GUIDs vor, die WinRoute auf Übereinstimmung mit Objekten im Microsoft Verzeichnisdienst Active Directory®, auf Connectors und auf Bridgeheadservern prüft. Das Ergebnis wird in einem lesbaren Format dargestellt.

Anmerkung:
Das WinRoute-Tool und die Benutzerdokumentation stehen auf der Website Downloads for Exchange Server 2003 zum Download bereit. Laden Sie dieses Tool herunter, und installieren Sie es auf allen Exchange 2000- und Exchange 2003-Servern in Ihrer Organisation. Verwenden Sie nicht das mit Exchange 2000 ausgelieferte WinRoute-Tool.

Allgemeine Verbindungsstatusprobleme

Innerhalb einer Routinggruppe verwendet Exchange den TCP-Anschluss 691 zum Austausch von aktualisierten Verbindungsstatus- und Routinginformationen zwischen dem Routinggruppenmaster und seinen Routinggruppenmitgliedern. Zwischen zwei Routinggruppen tauschen zwei Routinggruppen-Bridgeheadserver mithilfe des Verbs X-LINK2STATE Verbindungsstatusinformationen aus. Dabei wird die Digest verglichen, eine verschlüsselte Digitalsignatur im Orginfo-Paket, die Verbindungsstatusinformationen zu den zwei Routinggruppen-Bridgeheadservern enthält. Stimmen diese Digests nicht überein, werden die Verbindungsstatusinformationen zwischen den beiden Servern über den SMTP-Anschluss 25 ausgetauscht.

Der Routinggruppenmaster koordiniert Änderungen des durch die Server gemeldeten Verbindungsstatus in seiner Routinggruppe und ruft Aktualisierungen aus Active Directory ab. Wenn der Routinggruppenmaster nicht zur Verfügung steht, werden alle Server in der Routinggruppe weiterhin auf Grundlage der Informationen ausgeführt, die zu dem Zeitpunkt vorlagen, als die Verbindung zum Routinggruppenmaster getrennt wurde.

Sobald der Routinggruppenmaster wieder verfügbar ist, rekonstruiert er seine Verbindungsstatusinformationen und beginnt dabei mit allen Servern und Connectors, die als „Nicht verfügbar“ markiert sind. Werden nicht verfügbare Server entdeckt, aktualisiert der Routinggruppenmaster die Mitglieder in der Routinggruppe.

In diesem Abschnitt werden folgende Verbindungsstatusprobleme und die jeweils empfohlene Problembehebung erläutert:

• Trennen der Verbindung zwischen Routinggruppenmitgliedern und Routinggruppenmaster
• Konflikte zwischen Routinggruppenmastern
• Probleme durch gelöschte Routinggruppen
• Nicht als „Inaktiv“ markierte Connectors
• Oszillierende Verbindungen

Trennen der Verbindung zwischen Routinggruppenmitgliedern und Routinggruppenmaster

Wenn ein Routinggruppenmitglied keine Verbindung zum Routinggruppenmaster herstellen kann, zeigt das WinRoute-Tool in diesem Fall ein rotes X neben dem betreffenden Routinggruppenmitglied an.

So beheben Sie das Problem:

• Stellen Sie sicher, dass der Microsoft Exchange-Routingdienst (RESvc) in einem kontrollierten Zustand auf allen betroffenen Servern in der Routinggruppe gestartet wird. Ist der Routingdienst in einem instabilen Zustand, können Routinggruppenmitglieder u. U. keine Verbindung zum Routinggruppenmaster herstellen. Ermitteln Sie zunächst die eigentliche Ursache für die Instabilität der Dienste.

• Stellen Sie sicher, dass Port 691 nicht durch eine Firewall eingeschränkt wird, indem Sie eine Telnet-Sitzung auf Port 691 der betroffenen Servern und des Masterknotens initiieren. Im aktiven Status wird das Microsoft Routingmodul-Banner angezeigt.

• Geben Sie an der Eingabeaufforderung Folgendes ein:

  netstat -a -n 
  

  Das Ergebnis sollte ähnlich der nachfolgenden Anzeige alle Routinggruppenmitglieder und den Master anzeigen, die an Port 691 auf dem Masterknoten angeschlossen sind:

  TCP    127.0.0.1:691          127.0.0.1:691         ESTABLISHED
  

• Überprüfen Sie die Anwendungsprotokolle der Ereignisanzeige auf alle Ereignisse, die einen Fehler bei der Authentifizierung mit dem Computerkonto anzeigen (Domäne\Servername). Überwachen Sie die folgenden Transportereignisse:

  • Ereignis ID 961 wird protokolliert, wenn ein Mitgliedsserver nicht durch seinen Routinggruppenmaster authentifiziert werden kann.
  • Ereignis ID 962 wird protokolliert, wenn ein Clientknoten nicht durch den Routingdienst (RESvc) authentifiziert werden konnte.
  • Ereignis ID 996 wird bei erfolgreicher Authentifizierung eines Clientroutingknotens durch den Routingdienst protokolliert.
  • Ereignis ID 995 wird bei erfolgreicher Authentifizierung eines Routinggruppenmitglieds durch seinen Routinggruppenmaster protokolliert.

• Überprüfen Sie, ob die betroffenen Server einen ServicePrincipalName (SPN) generieren können, der beim Authentifizierungsvorgang zum überprüfen des Werts „ncacn_ip_tcp“ im Netzwerkadressattribut der betroffenen Server verwendet wird. Dies geschieht mit einem Verzeichniszugriffstool wie LDP (ldp.exe) oder ADSI-Bearbeitung (adsiEdit.msc).
  Mitglieder einer Routinggruppe müssen zur Verbindungsherstellung gegenseitig durch den Routinggruppenmaster authentifiziert werden. Dazu generieren sie den SPN für den Masterknoten durch Aufrufen von DsClientMakeSpnForTargetServer mit dem Wert ncacn_ip_tcp im Netzwerkadressattribut des Exchange-Servers. Anschließend können die Routinggruppenmitglieder mit Kerberos authentifiziert werden. Stellen Sie sicher, dass es sich bei diesem Wert um einen Fully Qualified Domain Name (FQDN – vollqualifizierten Domänennamen) und nicht um einen NetBIOS-Namen oder um eine Internetprotokolladresse handelt. Starten Sie den Exchange-Routingdienst neu.

• Überprüfen Sie, ob das Domänenkennwort für das Computerkonto noch gültig ist*.*

• Wenn die Mitgliedschaft der Routinggruppe mehrere Domänen umfasst, darf die Ursache des Problems keine untergeordnete Domäne oder ein Stammdomänenproblem auf Grund einer DNS-Fehlkonfiguration sein.

• Überprüfen Sie alle Microsoft-fremden Anwendungen oder Gruppenrichtlinienobjekte, die Berechtigungen oder die Sicherheit einschränken.

• Konfigurieren Sie einen anderen Server in der Routinggruppe als Routinggruppenmaster. Dieses Vorgehen stellt eine Übergangslösung dar. Eine Neuzuweisung der Rolle des Routinggruppenmasters kann Abhilfe schaffen, bis das Problem behoben ist.

• Wenn der Routinggruppenmaster oder Routinggruppenmitglieder keine SendAs-Berechtigung besitzen, zeigt WinRoute den Server als Besteht eine Verbindung mit dem Master?: Nein an. Überprüfen Sie, ob diesem Server oder der Gruppe, der er angehört, auf dem Gruppenmaster nicht explizit die SendAs-Berechtigung verweigert wurde.

Konflikte zwischen Routinggruppenmastern

Der erste Server, der in der Routinggruppe installiert wird, wird automatisch als Masterknoten oder Routinggruppenmaster festgelegt. Werden weitere Server installiert, können Sie einen dieser Server als Routinggruppenmaster festlegen.

Es darf jeweils nur ein Server von sich und den anderen Servern als Master erkannt werden. Diese Konfiguration wird durch einen Algorithmus erzwungen, bei dem (N/2) +1 Server in der Routinggruppe den Master akzeptieren und erkennen müssen. N steht dabei für die Anzahl der Server in der Routinggruppe. Die Mitgliederknoten senden daher ATTACH-Verbindungsstatusdaten an den Master.

Gelegentlich verwenden zwei oder mehr Server den falschen Server als Routinggruppenmaster. Wenn Sie z. B. einen Routinggruppenmaster verschieben oder löschen, ohne einen anderen Masterknoten auszuwählen, verweist das Attribut msExchRoutingMasterDN in Active Directory unter Umständen auf einen gelöschten Server, da das Attribut nicht verbunden ist.

Ein weiteres Beispiel ist, wenn ein alter Routinggruppenmaster die Trennung als Master ablehnt, oder wenn ein Rogue-Knoten weiterhin ATTACH-Verbindungsstatusinformationen an einen alten Routinggruppenmaster sendet. Wenn msExchRoutingMasterDN in Exchange 2003 auf ein gelöschtes Objekt verweist, gibt der Masterknoten seine Rolle als Master auf und initiiert die Beendigung der Masterrolle.

So beheben Sie das Problem:

• Überprüfen Sie die ordnungsgemäße Verbindungsstatusübermittlung in der Routinggruppe an Anschluss 691. Stellen Sie sicher, dass keine Firewall und kein SMTP-Filter die Kommunikation blockiert.
• Stellen Sie sicher, dass kein Exchange-Dienst gestoppt wurde.
• Überprüfen Sie die Active Directory-Replikationswartezeiten mithilfe des Replikationsmonitors von Active Directory (Replmon.exe), den Sie im Windows Resource Kit finden.
• Überprüfen Sie Netzwerkprobleme und Latenzen.
• Überprüfen Sie gelöschte Routinggruppenmaster oder nicht mehr vorhandene Server. Ist dies der Fall, wird das Transportereignis 958 im Anwendungsprotokoll der Ereignisanzeige protokolliert. Es besagt, dass ein Routinggruppenmaster nicht mehr vorhanden ist. Überprüfen Sie diese Informationen mit einem Verzeichniszugriffstool wie LDP (ldp.exe) oder ADSI-Bearbeitung (adsiEdit.msc).

Probleme durch gelöschte Routinggruppen

Wenn Routinggruppen gelöscht werden, z. B. nachdem Server aus den Gruppen verschoben wurden, zeigt WinRoute den Text „object_not_found_in_DS“ (Objekt in DS nicht gefunden) für die Objekte an.

Exchange-Server bewahren die Verbindungsstatustabelle, die weiterhin auf die Objekte verweist. Allerdings fehlen diese Objekte in Active Directory, wenn der Routingdienst gestartet wird und Active Directory auf die betreffenden Objekte untersucht.

Exchange-Routing kann gelöschte Routinggruppen und ihre Mitglieder (Server und Connectors) nicht automatisch aus der Verbindungsstatustabelle entfernen, sondern behandelt die gelöschten Routinggruppen wie bestehende, funktionsfähige Routinggruppen. In seltenen Fällen verursachen gelöschte Routinggruppen Fehlfunktionen beim Routing oder Mailschleifen. Gelöschte Routinggruppen können Topologien, in denen ein Standort mit Exchange 5.5 einer Organisation mit Exchange 2003 beitritt, schwer beeinträchtigen.

Zudem können sich die gelöschten Routinggruppen wesentlich auf die Größe der Verbindungsstatustabelle auswirken und den Netzwerkverkehr beim Austausch von Verbindungsstatusinformationen erhöhen.

Wenn das Persönliche Adressbuch (PAB) oder das Offlineadressbuch (OAB) einen Legacy-Exchange-Domänennamen hat, der einer gelöschten Routinggruppe entspricht, bewirken die gelöschten Routinggruppenobjekte, dass E-Mail-Nachrichten an nicht vorhandene Benutzer aus den PABs und OABs in der Warteschlange für Nachrichten mit nicht erreichbarem Ziel platziert werden. Nach einer Standardwartezeit von zwei Tagen wird die E-Mail mit einem Non-Delivery Report (NDR – Unzustellbarkeitsbericht) an den Absender zurückgesendet. Ohne das gelöschte Routinggruppenobjekt werden E-Mail-Nachricht an nicht vorhandene Benutzer sofort mit einem NDR an den Absender zurückgesendet und nicht in eine Warteschlange gestellt.

Stellen Sie zur Behebung dieses Problems zunächst sicher, dass das Konto, mit dem Sie die Routinginformationen anzeigen, über die entsprechenden Berechtigungen verfügt. Melden Sie sich, wenn möglich, mit dem Systemkonto und dem interaktiven AT-Befehl bei WinRoute an. Wenn keine entsprechenden Leseberechtigungen erteilt wurden, wird in WinRoute die Fehlermeldung „object_not_found_in_DS“ (Objekt in DS nicht gefunden) angezeigt.

Sie können gelöschte Routinggruppen mit einer der folgenden Methoden aus den Verbindungsstatusinformationen entfernen:

• Fahren Sie alle Server in der Organisation gleichzeitig herunter, um zwischengespeicherte Routingdaten zu aktualisieren, und entfernen Sie gelöschte Routinggruppen und Connectors.
• Fahren Sie auf allen Exchange-Servern in der Organisation sämtliche Dienste von Exchange und Windows Management Instrumentation (WMI) gleichzeitig herunter.

Sie können dieses Problem auch beheben, indem Sie mit Remonitor.exe den Speicherbedarf für die gelöschte Routinggruppe reduzieren und die Routinggruppe als gelöscht markieren.

Remonitor.exe ist ein Tool, mit dem ein benutzerdefiniertes Routingpaket in eine Exchange-Organisation eingeführt werden kann. Das benutzerdefinierte Paket ist eine modifizierte Version des Pakets für die gelöschte Routinggruppe. Diese modifizierte Version weist keine Server- oder Connector-Einträge auf. Dadurch wird der Umfang des Routinggruppenobjekts erheblich verkleinert. Diese Version schließt auch ein mögliches Versagen oder eine Verzögerung beim Routing durch einen Connector-Eintrag mit gelöschter Routinggruppe aus. Da dieses Tool ein modifiziertes Paket ohne Connector-Einträge einführt, kann es keinen Connector-Eintrag mit gelöschter Routinggruppe geben. Schließlich aktualisiert Remonitor.exe die Versionsnummer der modifizierten Routinggruppe, sodass dieser gelöschten Routinggruppe keine Server- oder Connector-Einträge hinzugefügt werden können.

Ausführliche Anweisungen finden Sie unter Ausführen von „Remonitor.exe“ als lokales Systemkonto im Modus zum Einfügen.

Nach dem Ausführen von Remonitor.exe enthält das Routingpaket keine Servermitglieder oder Connectors. Den Adressen der Routinggruppe ist nun das Schlüsselwort deleted vorangestellt. Außerdem wurde die Versionsnummer des Routinggruppenobjekts erhöht.

Connectors sind nicht als „Nicht verfügbar“ markiert

In einigen Fällen wird der Verbindungsstatus eines Connectors als „Verfügbar“ markiert, obwohl er eigentlich gar nicht zur Verfügung steht. Routing markiert den Verbindungsstatus folgender Connectors nicht als „Nicht verfügbar“:

• Connectors, die für das Routing zu einer Domäne im Adressraum DNS verwenden (z. B. SMTP-Connectors mit DNS).
• Connectors in Exchange 5.5 bzw. benutzerdefinierte EDK-Connectors (Exchange Development Kit), da sie kein Verbindungsstatusrouting verwenden.
• Routinggruppenconnectors mit lokalen Bridgeheadservern eines beliebigen Bridgeheads. Sie legen einen lokalen Bridgeheadserver als lokalen Bridgehead fest, indem Sie beim Erstellen einer Routinggruppe auf Jeder lokale Server kann E-Mail über diesen Connector senden klicken.
• Routinggruppenconnectors mit einem Exchange 5.5-Server als Bridgeheadserver

Weitere, eher unübliche Beispiele sind:

• Situationen, in denen in einer Routinggruppe die Weiterleitung von E-Mail-Nachrichten per Relay zur Vermeidung von MTA-Schleifen (Message Transfer Agent) in einer Routinggruppe fehlschlägt
• Connectors, die mit einem Smart Host konfiguriert sind, der erst vor kurzem geändert wurde.

Damit beim Routing ein Connector als „Nicht verfügbar“ markiert wird, müssen alle Bridgehead-Quellserver nicht verfügbar sein und den Status „VS_CONN_NOT_AVAILABLE oder VS_CONN_NOT_STARTED“ aufweisen. Sie können den Status mithilfe von WinRoute überprüfen.

Oszillierende Verbindungen

Connectors in einem unzuverlässigen Netzwerk, die erst als „Verfügbar“ und anschließend als „Nicht verfügbar“ markiert werden, führen wiederholt zu übermäßigen Aktualisierungen des Verbindungsstatus zwischen Servern. Diese Änderungen verursachen teure und häufige Neuberechnungen von Routen in Exchange. In der Ereignisanzeige wird die Ereignis-ID 4005 häufig protokolliert und mit dem Text „Reset routes“ (Routen zurücksetzen) angezeigt. Exchange 2003 reduziert diese Änderungen, wenn ein sich häufig ändernder Connectorstatus festgestellt wird, indem der Status für die Zeit, in der ein Server die Änderung überwacht, in einem einzelnen Abruffenster als „Verfügbar“ markiert bleibt. Treten diese Änderungen jedoch in unterschiedlichen Abrufzeiten auf, kann eine oszillierende Verbindung weiterhin den Verbindungsstatusverkehr generieren. Das Standwert für das Statusänderungsintervall für Exchange 2003-Server beträgt 10 Minuten.

Exchange-Routing wählt den optimalen Pfad und ermittelt den nächsten Server, zu dessen nächstem Abschnitt eine Nachricht geht. Dabei wird der Name dieses Servers in der Warteschlange platziert. Der optimale Pfad wird unter Berücksichtigung von Variablen wie beispielsweise Kosten, Nachrichtentyp und Einschränkungen ausgewählt. Folglich muss Exchange wegen des oszillierenden Status eines Connectors den optimalen Pfad wiederholt neu berechnen, was Abfragen von Active Directory sowie Leistungseinbußen mit sich zieht.

Wenn die Exchange-Warteschlange einen Verbindungsfehler zum Bridgeheadserver auf einem Connector feststellt, werden diese Information an den Routinggruppenmaster weitergeleitet. Dieser unterdrückt die Information für die Dauer von bis zu 10 Minuten, um Fluktuationen des Connectorstatus zu vermeiden. Wenn Routing den Connector als „Nicht verfügbar“ markiert, wird diese Änderung an alle Exchange-Server in der Organisation übermittelt (einschließlich des Servers, auf dem der Fehler aufgetreten ist). Diese Benachrichtigung, auch „Rücksetzungsroute“ genannt, ist hinsichtlich der CPU-Auslastung ein aufwändiger Vorgang. E-Mails werden nicht mehr auf dem Connector in die Warteschlange gestellt, und das Routing muss neue Übermittlungspfade generieren. Der gleiche Vorgang gilt beim Markieren eines Connectors als „Verfügbar“.

Eine oszillierende Verbindung tritt in folgenden Situationen auf:

• Netzwerkprobleme, die in einer Netzwerkverfolgung angezeigt werden
• Reaktionen auf Verbindungsstatus-Benachrichtigungsrückrufe von zu Grunde liegenden Protokolldiensten (SMTP und MTA) auf Grund einer Interferenz auf den X.400- oder SMTP-Protokollebenen durch Microsoft-fremde Anwendungen In diesem Szenario können die Probleme nur durch eine Erfassung der Netzwerküberwachung ermittelt werden. Zusätzlich können Sie das Tool remonitor.exe des Microsoft-Produktsupport verwenden.

Mit dem Netzwerkmonitor (Netmon.exe) oder dem Tool remonitor.exe können Sie die eigentliche Ursache für oszillierende Verbindungen ermitteln. Wenn die oszillierenden Verbindungen bei der Weitergabe erheblichen Netzverkehr erzeugen, können Sie zusätzlich die Weitergabe von Änderungen des Verbindungsstatus bis zur Lösung des Problems unterbinden.

Ausführliche Anweisungen finden Sie unter Unterdrücken der Verbindungsstatusinformationen auf einem Server.

Weitere Informationen über das Unterbinden des Verbindungsstatus-Datenverkehr finden Sie unter „Unterbinden des Verbindungsstatus-Datenverkehrs für Connectors“ unter Erweiterte Routingkonfiguration.

Unterbrochene Verbindungsstatusübermittlung

Exchange 5.5-Server verwenden keine Verbindungsstatusinformationen, sondern die Gateway-Addressroutingtabelle (GWART) für das Nachrichtenrouting. In einer Organisation im gemischten Modus erkennen Exchange 2000 und höhere Versionen diese Einschränkung und lesen die Konfiguration von Exchange 5.5-Servern direkt aus Active Directory. Daher erwarten Exchange 2000- und Exchange 2003-Server keinen Austausch von Verbindungsstatusinformationen mit Exchange 5.5-Servern.

Wenn ein Exchange 5.5-Bridgeheadserver in einer Exchange-Routinggruppe auf einen Exchange 2000- oder Exchange 2003-Server aktualisiert und als Bridgeheadserver festgelegt wird, nimmt er am Austausch von Verbindungsstatusinformationen teil und besitzt nicht länger die Hauptversionsnummer Null. Exchange 2000- und Exchange 2003-Server vergleichen Verbindungsstatustabellen mithilfe der Versionsnummern und stellen sicher, dass Server über die aktuellsten Informationen zum Verbindungsstatus verfügen. Die Hauptversionsnummer Null weist auf einen Server hin, der nicht am Austausch von Verbindungsstatusinformationen teilnimmt bzw. nie teilgenommen hat. Ein reiner Exchange 5.5-Standort besitzt die Versionsnummer Null, da er keine Verbindungsstatusinformationen austauscht. Wenn der Server auf einen Exchange 2000- oder Exchange 2003-Server aktualisiert wird, nimmt er am Austausch von Verbindungsstatusinformationen teil und erhöht seine Hauptversionsnummer. Bridgeheadserver in anderen Routinggruppen erwarten also, dass sie vom neu aktualisierten Server über Verbindungsstatusänderungen in der Routinggruppe informiert werden.

Es kommt zu Problemen, wenn Sie nun einen Exchange 5.5-Server als Bridgeheadserver für diese Routinggruppe festlegen. Andere Server gehen weiterhin davon aus, dass der Exchange 5.5-Bridgeheadserver (d. h. der frühere Exchange 2000- oder Exchange 2003-Bridgeheadserver) an der Übermittlung von Verbindungsstatusinformationen teilnimmt und warten auf aktualisierte Informationen von diesem Server. Da dieser Server jedoch wieder in einen Exchange 5.5-Server geändert wurde, besitzt er keine Verbindungsstatustabelle mehr. Daher wird diese Routinggruppe nun isoliert und nimmt nicht an den dynamischen Verbindungsstatusaktualisierungen in der Organisation teil.

Die isolierte Routinggruppe verursacht in einer in Abbildung 11.4 dargestellten Situation Probleme. Insbesondere weil der Exchange 5.5-Bridgeheadserver früher ein Exchange 2000- oder Exchange 2003-Bridgeheadserver war, erwarten andere Server, dass er an der Weitergabe des Verbindungsstatus teilnimmt. Der Internet Mail-Connector in Exchange 5.5 und der SMTP-Connector in Exchange 2003 in der folgenden Abbildung leiten E-Mails über einen einzelnen Smart Host an das Internet weiter. Da der Smart Host unverfügbar wird, markiert der Exchange 2003-Bridgeheadserver die Route über seinen SMTP-Connector als „Nicht verfügbar“. Da jedoch der Bridgeheadserver vom Exchange 5.5-Server Verbindungsstatusinformationen zu seinen Routinggruppen und Connectors erwartet, nimmt er an, dass die Route über den Internet Mail Connector zur verfügbar ist und versucht, die Nachrichten über diese Route zu senden. Nach einem Fehlversuch erkennt der Exchange 2003-Server eine mögliche Schleife und verwendet diese Route nicht mehr.

Die Weitergabe des Verbindungsstatus kann auch durch eine Firewall im System unterbrochen werden, die diese Weitergabe blockiert. Die Anschlüsse 25 und 691 sind innerhalb einer Routinggruppe und der Anschluss 25 ist zwischen Routinggruppen erforderlich. Auch darf der ESMTP-Befehl X-LINK2STATE (Extended Simple Mail Transfer Protocol) nicht durch eine Firewall blockiert werden.

Zur Problembehebung stehen zwei Lösungen zur Verfügung:

• Aktualisieren Sie den Exchange 5.5-Bridgeheadserver auf einen Exchange 2000- oder Exchange 2003-Server, oder senden Sie die Verbindungsstatusinformationen zu dieser Routinggruppe über einen anderen Exchange 2000- oder Exchange 2003-Server. Mit diesen beiden Möglichkeiten können Sie das Problem am einfachsten beheben.
• Wenn Sie die nicht verbundenen Routinggruppen auf einen Verbindungsstatus mit Hauptversionsnummer Null zurücksetzen möchten, fahren Sie alle Exchange-Server in der Organisation gleichzeitig herunter, und starten Sie sie anschließend neu.
• Konfigurieren Sie die Firewall so, dass die Weitergabe des Verbindungsstatus nicht verhindert wird.

Weitere Informationen über isolierte oder nicht zusammenhängende Routinggruppen und die Hauptversionsnummern finden Sie im Microsoft Knowledge Base-Artikel 842026 "Routing status information is not propagated correctly to all servers in Exchange 2000 Server or in Exchange Server 2003".