Verbindungsstatusweitergabe

 

Letztes Änderungsdatum des Themas: 2005-05-23

Zur Gewährleistung eines effizienten und zuverlässigen Nachrichtenroutings muss die Verbindungsstatustabelle eines Exchange-Servers stets aktuelle Informationen enthalten. Diese Informationen müssen der Zustand aller Bridgeheadserver und Messagingconnectors genau wiedergeben. Zur Weitergabe von Verbindungsstatusinformationen an alle Server in einer Exchange-Organisation wird ein Übermittlungsprotokoll verwendet, das als Verbindungsstatusalgorithmus (LSA, Link State Algorithm) bezeichnet wird.

Die Weitergabe von Verbindungsstatusinformationen an alle Server hat folgende Vorteile:

• Jeder Exchange-Server kann die optimale Nachrichtenroute von der Quelle ermitteln, anstatt die Nachrichten auf einer Route zu senden, auf der kein Connector verfügbar ist.
• Nachrichten werden nicht zwischen Servern hin- und hergesendet, da jeder Exchange-Server feststellen kann, ob andere oder redundante Verbindungen verfügbar sind.
• Nachrichtenschleifen treten nicht mehr auf.

Verbindungsstatusalgorithmus

Die Weitergabe von Verbindungsstatusinformationen erfolgt innerhalb von Routinggruppen und zwischen Routinggruppen unterschiedlich. Innerhalb von Routinggruppen wird eine zuverlässige TCP/IP-Verbindung vorausgesetzt. Die Server kommunizieren daher über direkte TCP/IP-Verbindungen miteinander. Zwischen verschiedenen Routinggruppe sind jedoch unter Umständen keine direkten TCP/IP-Verbindungen möglich. Aus diesem Grund werden Verbindungsstatusinformationen von Exchange Server 2003 zwischen Routinggruppen über SMTP oder X.400 weitergegeben.

Exchange Server 2003 übermittelt Verbindungsstatusinformationen folgendermaßen:

• LSA innerhalb einer Routinggruppe   Innerhalb einer Routinggruppe erfasst der Routinggruppenmaster die Verbindungsstatusinformation und übermittelt diese an die übrigen Server in der Routinggruppe. Die übrigen Server werden auch als Mitgliedsknoten oder Routinggruppenmitglieder bezeichnet. Wenn ein Mitgliedsknoten gestartet wurde und seine Routingtabelle mit Informationen aus Active Directory initialisiert hat, wird eine TCP/IP-Verbindung mit Anschluss 691 hergestellt. Anschließend authentifiziert sich der Mitgliedsknoten beim Routinggruppenmaster und bezieht aktuelle Informationen über den Status aller Verbindungen in der Routingtopologie. Alle Verbindungen innerhalb einer Routinggruppe erfordern eine bidirektionale Authentifizierung. Die Verbindung bleibt bestehen, sodass der Master und der untergeordnete Knoten bei jeder neuen Verbindungsstatusänderung miteinander kommunizieren können.
  
  Innerhalb einer Routinggruppe aktualisiert Exchange Server 2003 Verbindungsstatusinformationen wie folgt:

  1. Wenn das erweiterte Warteschlangenmodul oder der Exchange-MTA ein Problem mit einem Bridgeheadserver oder einem Routinggruppenconnector feststellen, wird das lokale Routingmodul informiert, wie in „Erneutes Routing von Nachrichten anhand von Verbindungsstatusinformationen“ unter Nachrichtenrouting unter Exchange Server 2003 erläutert.

  2. Das lokale Routingmodul, das als Cacheproxy zwischen dem Routinggruppenmaster und dem erweiterten Warteschlangenmodul oder dem Exchange-MTA fungiert, leitet diese Verbindungsstatusinformation an den Routinggruppenmaster über eine entsprechende Verbindung an den TCP-Anschluss 691 weiter.

  3. Nachdem der Routinggruppenmaster über eine Aktualisierung informiert wurde, wird die Verbindungsstatustabelle mit den neuen Informationen überschrieben. Auf Grundlage dieser neuen Informationen erstellt der Routinggruppenmaster einen neuen MD5-Hashwert, fügt diesen in die Verbindungsstatustabelle ein und übermittelt diese neuen Informationen an alle Server in der Routinggruppe. Die Kommunikation erfolgt über den TCP-Anschluss 691.

     Anmerkung:

     Ein MD5-Hashwert ist ein verschlüsselter Datenblock, der unter Verwendung eines Hashalgorithmus aus einer Nachricht abgeleitet wurde. Mit diesem Hashalgorithmus wird ein 128-Bit-Hashwert aus einer Liste von Blöcken mit 512 Bit generiert. Für eine Nachricht wird stets derselbe Hashwert erzeugt, wenn sie denselben Hashalgorithmus durchläuft. Für Nachrichten, die sich auch nur durch ein Zeichen unterscheiden, werden völlig verschiedene Hashwerte ausgegeben.

  4. Der Routinggruppenmaster sendet die gesamte Verbindungsstatustabelle (d. h. ein OrgInfo-Paket) an jedes einzelne Routinggruppenmitglied. Jedes Routinggruppenmitglied vergleicht den MD5-Hashwert des neuen OrgInfo-Pakets mit dem MD5-Hashwert in der eigenen Verbindungsstatustabelle und ermittelt, ob der lokale Server über die neuesten Informationen verfügt.

  5. Wenn die MD5-Hashwerte nicht übereinstimmen, wird das OrgInfo-Paket vom Routinggruppenmitglied verarbeitet. Nachdem die Verbindungsstatustabelle im Speicher ersetzt wurde, sendet das Routinggruppenmitglied eine kurze Antwort an den Routinggruppenmaster, in der auf den neuen MD5-Hashwert verwiesen wird.

  6. Der Routinggruppenmaster verarbeitet diese Informationen, stellt fest, dass das Routinggruppenmitglied aktualisiert wurde, und sendet eine kurze Bestätigung an das Routinggruppenmitglied.

  7. Anschließend fordert das Routinggruppenmitglied alle fünf Minuten aktuelle Routinginformationen vom Master an. Master und Mitgliedsknoten vergleichen ihre MD5-Hashwerte, um festzustellen, ob Änderungen aufgetreten sind.

  Anmerkung:
  Alle Server innerhalb einer Routinggruppe müssen über eine zuverlässige TCP/IP-Verbindung mit dem Routinggruppenmaster kommunizieren.

• LSA zwischen verschiedenen Routinggruppen   Verbindungsstatusinformationen werden auf indirekte Weise über Bridgeheadserver und Routinggruppenconnectors zwischen Routinggruppen übertragen. Zum Senden von Verbindungsstatusinformationen an eine andere Routinggruppe überträgt der Routinggruppenmaster die Verbindungsstatusinformationen in Form eines Orginfo-Pakets, das an den Bridgeheadserver einer Routinggruppe über den TCP-Anschluss 691 gesendet wird. Der Bridgeheadserver leitet diese Informationen dann unter Verwendung der verschiedenen verfügbaren Routinggruppenconnectors an alle Bridgeheadserver in anderen Routinggruppen weiter, mit denen der Server verbunden ist.
  Wenn die Kommunikation zwischen Routinggruppen SMTP-basiert ist (d. h. über Routinggruppenconnectors oder SMTP-Connectors erfolgt), werden vor der regulären Nachrichtenübertragung Verbindungsstatusinformationen mit dem erweiterten SMTP-Befehl X-LINK2STATE ausgetauscht, wie im Folgenden erläutert:

  1. Der Quellbridgeheadserver stellt eine TCP/IP-Verbindung mit dem Zielbridgeheadserver über den TCP-Anschluss 25 her.

  2. Die Bridgeheadserver authentifizieren sich gegenseitig mit dem Befehl X-EXPS GSS API.

  3. Nach der Verbindungsherstellung und der Authentifizierung beginnt die Verbindungsstatuskommunikation mit dem Befehl X-LINK2STATE.

  4. Zunächst vergleichen die Bridgeheadserver ihre MD5-Hashwerte, um ggf. Änderungen in den Verbindungsstatusinformationen zu ermitteln. Anschließend fordert der lokale Bridgeheadserver mit dem Verb DIGEST_QUERY den MD5-Hashwert vom Remotebridgeheadserver an. Das Verb DIGEST_QUERY enthält die GUID der Exchange-Organisation und den MD5-Hashwert des lokalen Bridgeheadservers.

  5. Der Remotebridgeheadserver vergleicht dann den eigenen MD5-Hashwert mit dem MD5-Hashwert, der über DIGEST_QUERY empfangen wurde. Wenn die Hashwerte identisch sind, sendet der Remotebridgeheadserver das Verb DONE_RESPONSE, durch das angegeben wird, dass die Verbindungsstatustabelle nicht aktualisiert werden muss. Andernfalls wird vom Remotebridgeheadserver das gesamte OrgInfo-Paket gesendet.

  6. Nach Empfang des OrgInfo-Pakets werden die Funktionen des Remotebridgeheadservers und des lokalen Bridgeheadservers vertauscht, und der lokale Bridgeheadserver sendet sein eigenes OrgInfo-Paket an den Remotebridgeheadserver. Beide Bridgeheadserver übertragen das empfangene OrgInfo-Paket an ihren Routinggruppenmaster. Durch den Routinggruppenmaster wird ermittelt, ob die Verbindungsstatustabelle mit den Informationen aus dem OrgInfo-Paket aktualisiert werden muss. Eine höhere Versionsnummer weist darauf hin, dass es sich um ein aktuelleres OrgInfo-Paket handelt.

     Anmerkung:
     Routinggruppenmaster nehmen niemals Informationen über ihre lokale Routinggruppe von einem Routinggruppenmaster in einer Remoteroutinggruppe an.

  7. Nach dem Austausch von OrgInfo-Paketen startet der Remotebridgeheadserver die Übertragung von E-Mail-Nachrichten oder sendet den Befehl QUIT, um die SMTP-Verbindung zu beenden.
     Einzelheiten zur SMTP-Kommunikation zwischen Servern mit Exchange Server 2003 finden Sie unter SMTP-Transportarchitektur.

Anmerkung:

Wenn Sie Routinggruppen durch einen X.400-Connector verbinden, werden im Rahmen der normalen Nachrichtenübertragung Verbindungsstatusinformationen zwischen den MTAs ausgetauscht. Ein als OrgInfo-Paket bezeichnetes Binärobjekt wird dabei in einer Systemmeldung an den empfangenden MTA gesendet, bevor IPM-Nachrichten übertragen werden. Der empfangende MTA überträgt das Orginfo-Paket dann an das lokale Routingmodul, das die Übertragung dem Routinggruppenmaster mitteilt.

Beispiel für einen LSA

In der folgenden Abbildung wird die Funktionsweise des Verbindungsstatusalgorithmus (LSA, Link State Algorithm) in einer Exchange-Organisation mit mehreren Routinggruppen dargestellt. In der Abbildung wird eine Umgebung mit einem nicht verfügbaren Bridgeheadserver in Routinggruppe E gezeigt. Die Bridgeheadserver der anderen Routinggruppen haben keine Informationen darüber erhalten, dass ein Routingproblem besteht.

Das Routingproblem wird von Exchange Server 2003 auf folgende Weise erkannt:

1. Ein Benutzer in Routinggruppe A sendet einem Empfänger in Routinggruppe E eine Nachricht.
2. Das Routingmodul wählt den in Abbildung 5.9 dargestellten Weg. Die Nachricht wird daher an den Bridgeheadserver in Routinggruppe B übermittelt.
3. Der Bridgeheadserver in Routinggruppe B versucht eine direkte Übertragung an den Bridgeheadserver in Routinggruppe E. Da der Remotebridgehead nicht verfügbar ist, schlägt dieser Versuch fehl. Nach drei aufeinanderfolgenden Verbindungsversuchen wird der lokale Bridgeheadserver des Routinggruppenconnectors als CONN_NOT_AVAIL gekennzeichnet. Da es in der Konfiguration des Connectors keine weiteren Bridgeheads gibt, wird der Connector als STATE DOWN gekennzeichnet.
   
4. Der Bridgeheadserver in Routinggruppe B stellt über den TCP-Anschluss 691 eine Verbindung mit seinem Routinggruppenmaster her und überträgt die neuen Verbindungsstatusinformationen. Die Informationen werden vom Master in die Verbindungsstatustabelle aufgenommen, und alle Server der Routinggruppe werden über die Änderung informiert.
5. Durch die Änderung des Verbindungsstatus erfolgt ein erneutes Routing in Routinggruppe B. Zwei Wege mit den gleichen Kosten sind für Exchange Server 2003 verfügbar. In diesem Beispiel wird die Nachricht an Routinggruppe C gesendet. Der Übertragungsweg wird vom Routingmodul zufällig ausgewählt.
6. Bevor die eigentliche Nachricht gesendet wird, vergleichen die beiden Bridgeheadserver in Routinggruppe B und C ihre MD5-Hashwerte. Da die MD5-Hashwerte nicht übereinstimmen, tauschen die Server Verbindungsstatusinformationen aus. Der Bridgeheadserver in Routinggruppe B informiert die verbleibenden benachbarten Remotebridgeheadserver (in Routinggruppe A, C und D) über die Änderungen des Verbindungsstatus.
7. Der Bridgeheadserver in Routinggruppe C stellt über den TCP-Anschluss 691 eine Verbindung mit seinem Routinggruppenmaster her und überträgt die neuen Verbindungsstatusinformationen. Die Informationen werden vom Routinggruppenmaster in die Verbindungsstatustabelle aufgenommen, und alle Server der Routinggruppe werden über die Änderung informiert. Alle Server in Routinggruppe B und C sind nun darüber informiert, dass der Routinggruppenconnector zwischen Routinggruppe B und Routinggruppe E nicht verfügbar ist.
8. Der Bridgeheadserver in Routinggruppe B versucht eine direkte Übertragung an den Bridgeheadserver in Routinggruppe E. Da der Remotebridgehead nicht verfügbar ist, schlägt dieser Verbindungsversuch fehl. Nach drei Verbindungsversuchen wird der Connector als STATE DOWN gekennzeichnet.
   
9. Der Bridgeheadserver in Routinggruppe C stellt über den TCP-Anschluss 691 eine Verbindung mit seinem Routinggruppenmaster her und überträgt die neuen Verbindungsstatusinformationen. Die Informationen werden vom Routinggruppenmaster in die Verbindungsstatustabelle aufgenommen, und alle anderen Server der Routinggruppe werden über die Änderung informiert.
10. Durch die Änderung des Verbindungsstatus erfolgt ein erneutes Routing in Routinggruppe C. Die Nachricht wird nun an Routinggruppe D gesendet, da das Routingmodul noch eine bestehende Verbindung zwischen den Routinggruppen D und E erkennt. Der Bridgeheadserver in Routinggruppe C informiert die verbleibenden benachbarten Remotebridgeheadserver (in den Routinggruppen A, B und C) über die Änderungen des Verbindungsstatus.
11. Die Nachricht wird an Routinggruppe D übermittelt. Vor der eigentlichen Übertragung vergleichen jedoch die Bridgeheadserver der Routinggruppen B und C ihre MD5-Hashwerte und tauschen Verbindungsstatusinformationen aus.
12. Der Bridgeheadserver in Routinggruppe D stellt über den TCP-Anschluss 691 eine Verbindung mit seinem Routinggruppenmaster her und überträgt die neuen Verbindungsstatusinformationen. Die Informationen werden vom Routinggruppenmaster in die Verbindungsstatustabelle aufgenommen, und alle Server der Routinggruppe werden über die Änderung informiert. Alle Server in Routinggruppe D sind nun darüber informiert, dass die Routinggruppenconnectors zwischen den Routinggruppen B und E sowie C und E nicht verfügbar sind.
13. Der Bridgeheadserver in Routinggruppe D versucht eine direkte Übertragung an den Bridgeheadserver in Routinggruppe E. Da der Remotebridgehead nicht verfügbar ist, schlägt dieser Verbindungsversuch jedoch fehl. Nach drei Verbindungsversuchen wird der Connector als STATE DOWN gekennzeichnet.
    
14. Der Bridgeheadserver in Routinggruppe D stellt über den TCP-Anschluss 691 eine Verbindung mit seinem Routinggruppenmaster her und überträgt die neuen Verbindungsstatusinformationen. Die Informationen werden vom Master in die Verbindungsstatustabelle aufgenommen, und alle Server der Routinggruppe werden über die Änderung informiert.
15. Durch die Änderung des Verbindungsstatus erfolgt ein erneutes Routing in Routinggruppe D. Da für Routinggruppe E keine zusätzlichen Übertragungswege zur Verfügung stehen, bleibt die Nachricht in Routinggruppe D, bis mindestens ein Übertragungsweg verfügbar ist. Sobald der Bridgeheadserver in Routinggruppe E verfügbar ist, wird die Nachricht an Routinggruppe E übermittelt.
16. Der Bridgeheadserver in Routinggruppe D informiert die verbleibenden benachbarten Remotebridgeheadserver (in Routinggruppe B und C) über die Änderungen des Verbindungsstatus. Diese Routinggruppen übermitteln die Verbindungsstatusänderungen anschließend an Routinggruppe A.

Verbindungsstatusänderungen und Verbindungsstatusübermittlung

Die Verbindungsstatustabelle enthält Versionsinformationen für jede Routinggruppe in Form von Haupt-, Neben- und Benutzerversionsnummern. Hauptversionsänderungen haben die höchste Priorität, gefolgt von Nebenversionsänderungen und Änderungen der Benutzerversionsnummern.

Exchange Server 2003 erkennt Verbindungsstatusänderungen auf die im Folgenden beschriebene Weise:

• Hauptversionsnummer   Als Hauptversionsänderungen gelten physikalische Änderungen an der Routingtopologie. Ein Beispiel für eine Hauptversionsänderung wäre das Hinzufügen eines neuen Connectors zu einer Routinggruppe oder die Änderung einer Connectorkonfiguration. Damit der Routinggruppenmaster über Hauptversionsänderungen an der Routingtopologie seiner Routinggruppe informiert wird, registriert er sich mithilfe von DSAccess bei Active Directory für den Empfang von Änderungsmitteilungen. Der Konfigurationsdomänencontroller sendet diese Mitteilungen entsprechend dem LDAP-Standard (Lightweight Directory Access Protocol) über Änderungsbenachrichtigungsvorgänge an den Exchange-Server. Wenn ein Routinggruppenmaster vom Konfigurationsdomänencontroller eine Aktualisierung der Routingtopologie erhält, sendet er die aktualisierten Informationen an alle Mitgliedsserver seiner Routinggruppe. Außerdem benachrichtigt er alle Bridgeheadserver in Remoteroutinggruppen, wie oben im Abschnitt „Verbindungsstatusalgorithmus“ beschrieben. Weitere Informationen zur Funktion von DSAccess und den Konfigurationsdomänencontroller in Exchange 2003 finden Sie in Exchange Server 2003 und Active Directory.

• Nebenversionsnummer   Als Nebenversionsänderungen gelten Änderungen am Verbindungsstatus, z. B. wenn ein Connector vom Status STATE UP in den Status STATE DOWN wechselt. Unzuverlässige Netzwerkverbindungen können allerdings dazu führen, dass Connectors häufig als UP bzw. DOWN gekennzeichnet werden. Dadurch werden zusätzliche Verbindungsstatusaktualisierungen in der gesamten Exchange-Organisation verursacht. Es kann dadurch zu einem deutlichen Anstieg der Verarbeitungslast in Folge von zusätzlichen Zurücksetzungen der Route und erneutem Routing von Nachrichten kommen. In der Standardeinstellung verringert Exchange Server 2003 oszillierende Connectors, indem Verbindungsstatusänderungen um einen Zeitraum von zehn Minuten verzögert werden. In dieser Zeit werden vorkommende Änderungen zusammengeführt und anschließend gebündelt per Stapelverarbeitung in der Organisation repliziert. Dennoch kann eine oszillierende Verbindung Verbindungsstatus-Datenverkehr erzeugen, wenn Änderungen über längere Zeiträume vorkommen.
  Sie können das Aktualisierungszeitfenster mit dem folgenden Registrierungsparameter vergrößern oder verkleinern.

  Speicherort	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RESvc\Parameters\
  Wert	StateChangeDelay
  Typ	REG_DWORD
  Wert	Zeitraum zwischen Verbindungsstatusaktualisierungen in Sekunden. Der Standardwert beträgt zehn Minuten. Der Höchstwert beträgt sieben Tage. Für die Fehlerbehebung bei Verbindungsproblemen kann es hilfreich sein, diesen Parameter auf 0 zu setzen. Fehler spiegeln sich dann sofort im Connectorstatus wider.

  Mit dem folgenden Registrierungsschlüssel können Sie verhindern, dass der Routinggruppenmaster seine Connectors als DOWN kennzeichnet. Dies kann vor allem in Hub-and-Spoke-Routingszenarios hilfreich sein, in denen jeder Zielort nur durch einen einzigen Connector erreichbar ist. Es kann zum erneuten Routing von Nachrichten kommen, wenn keine alternativen Connectors zur Verfügung stehen.

  Speicherort	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RESvc\Parameters\
  Wert	SuppressStateChanges
  Typ	REG_DWORD
  Wert	Über den Wert 0x1 werden Verbindungsstatusänderungen deaktiviert.

• Benutzerversionsnummer   Zu den Benutzeraktualisierungen zählen minimale Änderungen, wie der Wechsel des Routinggruppenmasters, das Starten und Beenden von Diensten auf einem Exchange-Server, das Hinzufügen eines Servers zu der Routinggruppe oder der Ausfall der Verbindung zwischen einem Mitgliedsserver und dem Routinggruppenmaster.

Ändern des Routinggruppenmasters

Der erste installierte Server der Routinggruppe wird automatisch als Routinggruppenmaster festgelegt. Wenn dieser Server ausfällt oder offline geschaltet wird, werden Verbindungsstatusinformationen in der Routinggruppe nicht mehr weitergegeben. Alle Server der Routinggruppe arbeiten weiterhin auf Basis der älteren Informationen. Sobald der Routinggruppenmaster wieder verfügbar ist, rekonstruiert er seine Verbindungsstatusinformationen. Es wird mit den Servern und Connectors begonnen, die als nicht verfügbar gekennzeichnet sind. Der Routinggruppenmaster ermittelt alle nicht verfügbaren Server und aktualisiert die Mitglieder der Routinggruppe.

Wenn Sie einen Routinggruppenmaster für längere Zeit herunterfahren, sollten Sie einen anderen Routinggruppenmaster benennen, um ein ineffizientes Nachrichtenrouting zu vermeiden. Erweitern Sie im Exchange-System-Manager die gewünschte Routinggruppe, und wählen Sie den Container Mitglieder. Klicken Sie im Detailbereich mit der rechten Maustaste auf den Server, den Sie zum Routinggruppenmaster heraufstufen möchten, und wählen Sie die Option Als Master festlegen.

Anmerkung:
Das Wechseln des Routinggruppenmasters stellt eine wesentliche Verbindungsstatusänderung dar. Bei einer Verbindungsstatusänderung werden Verbindungsstatusinformationen in der gesamten Organisation weitergegeben, und alle Exchange-Server müssen ihre Nachrichten neu routen. Der Routinggruppenmaster sollte daher nicht häufig gewechselt werden.

Konflikte zwischen Routinggruppenmastern

In einer Routinggruppe wird nur ein Server als Routinggruppenmaster anerkannt. 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. Wird beispielsweise ein Routinggruppenmaster verschoben oder gelöscht, ohne dass ein anderer gewählt wird, verweist das Attribut msExchRoutingMasterDN, über das in Active Directory der Routinggruppenmaster festlegt wird, unter Umständen auf einen gelöschten Server, da das Attribut nicht verbunden ist.

Ein solcher Fall kann auch eintreten, wenn ein alter Routinggruppenmaster die Trennung als Master ablehnt, oder ein Rogue-Routinggruppenmaster weiterhin die ATTACH-Verbindungsstatusinformation an einen alten Routinggruppenmaster sendet. Wenn msExchRoutingMasterDN in Exchange 2003 auf ein gelöschtes Objekt verweist, gibt der Routinggruppenmaster seine Funktion 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 kein Firewall für 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), der in Microsoft Windows Server 2003 enthalten ist.
• Überprüfen Sie Netzwerkprobleme und Wartezeiten in der Netzwerkkommunikation.
• Überprüfen Sie gelöschte Routinggruppenmaster oder nicht mehr vorhandene Server. In diesen Fällen wird das Transportereignis 958 im Anwendungsprotokoll der Ereignisanzeige protokolliert. Dieses Ereignis gibt an, dass ein Routinggruppenmaster nicht mehr vorhanden ist. Überprüfen Sie diese Informationen mit einem Verzeichniszugriffstool, wie LDP (ldp.exe) oder ADSI-Bearbeitung (adsiEdit.msc). Diese Anwendungen sind Teil der Supporttools von Windows Server 2003.