Nachrichtenrouting unter Exchange Server 2003

Letztes Änderungsdatum des Themas: 2007-03-06

Wenn Nachrichten nicht an lokale Empfänger gerichtet sind, müssen für das erweiterte Warteschlangenmodul vom Routingmodul Informationen zum Host für den nächsten Hop auf dem Übertragungspfad des Ziels sowie zum Typ des nächsten Hops bereitgestellt werden (siehe vorheriges Thema). Der Host für den nächsten Hop stellt die tatsächliche Routingadresse dar. Durch den Typ des nächsten Hops wird bestimmt, wie die Nachricht durch das erweiterte Warteschlangenmodul verarbeitet wird. Damit diese wichtigen Informationen bereitgestellt werden können, muss das Routingmodul die vollständige Ansicht der gesamten Routingtopologie kennen. Dies schließt alle Routinggruppen und ihre Server, Routinggruppenconnectors sowie Connectors zu externen Messagingsystemen ein. Unter Exchange Server 2003 stehen diese Informationen im Active Directory-Verzeichnisdienst zur Verfügung.

Nachrichtenrouten und die Verbindungsstatustabelle

Jeder Exchange 2003-Server verwaltet im Speicher dynamisch eine eigene, als Verbindungsstatustabelle bezeichnete Routingtabelle, die wie im Folgenden erläutert auf Active Directory und Verbindungsstatusinformationen beruht:

• Routing-bezogene Active Directory-Informationen   Diese Informationen werden in Attributen des Organisationsobjekts, von Routinggruppenobjekten, Connectorobjekten und Serverobjekten gespeichert. Diese Objekte befinden sich in der Konfigurationsverzeichnispartition und definieren die Routingtopologie der gesamten Exchange-Organisation.

  Anmerkung:
  Administrative Gruppen sind nicht Teil der Routingtopologie in einer Exchange-Organisation.

• Verbindungsstatusinformationen   Durch diese Informationen wird angegeben, ob ein Connector in der Routingtopologie verfügbar (in Betrieb) oder nicht verfügbar (außer Betrieb) ist. Verbindungsstatusinformationen sind dynamisch und können sich unter Umständen ändern, wenn an einem Connector Übertragungsprobleme auftreten oder Übertragungsprobleme behoben werden. Weitere Informationen zu Verbindungsstatusänderungen sowie zum Verteilen von Verbindungsstatusinformationen in einer Exchange-Organisation finden Sie unter Verbindungsstatusweitergabe.

Initialisieren der Verbindungsstatustabelle

Nach dem Starten initialisiert jeder Exchange-Server seine Verbindungsstatustabelle anhand der folgenden Informationen aus Active Directory:

• Organisationsobjekt   Die Grenze der Routingtopologie ist die Exchange-Organisation. Die Verbindungsstatustabelle enthält somit keine Informationen über externe Bridgeheadserver oder Messagingconnectors in einem externen Messagingsystem. Aus Sicht des Routingmoduls endet die Routingtopologie am Connector zum externen Messagingsystem. Dementsprechend liest das Routingmodul die im Attribut objectGUID des Exchange-Organisationsobjekts in Active Directory registrierte GUID und kennzeichnet die Verbindungsstatustabelle mit dieser GUID, um die Organisation zu bestimmen, zu der diese Routinginformationen gehören.
• Routinggruppenobjekte   Das Routingmodul listet alle in administrativen Gruppen enthaltenen Routinggruppen auf und fragt die einzelnen Routinggruppen nach allen Objektattributen ab, u. a. auch das Attribut msExchRoutingGroupMembersBL, das eine Liste aller Routinggruppen-Mitgliedsserver enthält. Das Routingmodul speichert diese Informationen in der Verbindungsstatustabelle. Durch das Routingmodul werden außerdem die Server und die zugehörigen Routinggruppen-GUIDs des jeweiligen Servers in einem Servercache im Speicher gespeichert. Jeder Eintrag im Servercache besteht aus jeweils einem Server-FQDN, dem die Routinggruppen-GUID des Servers hinzugefügt wurde.
  Ein weiteres wichtiges Routinggruppenattribut ist das Attribut msExchRoutingMasterDN, das auf den DN des Routinggruppenmasters in der ausgewählten Routinggruppe verweist. Weitere Informationen zu den Aufgaben und Funktionen des Routinggruppenmasters finden Sie in den folgenden Ausführungen dieses Abschnitts.
• Messagingconnectorobjekte   Das Routingmodul listet alle untergeordneten Objekte mit dem Objekttyp msExchconnector auf, die im Verbindungscontainer jeder Routinggruppe enthalten sind. Bei den Objekten vom Typ msExchconnector im Verbindungscontainer handelt es sich um die Routinggruppenconnectors und Connectors zu externen Messagingsystemen, die in der Routinggruppe konfiguriert sind. Das Routingmodul liest alle Attribute von diesen Connectorobjekten, um Adressbereiche, Kostenwerte, Beschränkungen und andere Parameter zu ermitteln. Das Routingmodul speichert diese Informationen für jeden Connector in der Verbindungsstatustabelle. Dadurch können Nachrichten an Ziele außerhalb der lokalen Gruppe weitergeleitet werden.

Dieser Vorgang wird fortgesetzt, bis das Routingmodul alle direkt und indirekt verbundenen Routinggruppen identifiziert und die Konfigurationsdetails ihrer Messagingconnectors abgefragt hat. Nach Abschluss dieses Vorgangs verfügt das Routingmodul über eine vollständige Ansicht aller verfügbaren Übertragungspfade in der gesamten Exchange-Organisation. Es wird davon ausgegangen, dass alle Verbindungen betriebsbereit und zur Nachrichtenübertragung verfügbar sind. Nach der Initialisierung der Verbindungsstatustabelle kommuniziert das Routingmodul mit dem Dienst Microsoft Exchange-Routingmodul auf dem lokalen Server, um dynamische Verbindungsstatusinformationen zu erhalten, die den aktuellen Zustand jedes Connectors angeben. Der Dienst Exchange-Routingmodul stellt über den TCP-Anschluss 691 eine Verbindung mit dem Routinggruppenmaster in der lokalen Routinggruppe her, um diese Informationen abzurufen. Weitere Informationen zu Verbindungsstatusinformationen finden Sie im Abschnitt „Überprüfen der Verbindungsstatustabelle“ weiter unten in diesem Abschnitt.

Routingmodul und der Dienst Exchange-Routingmodul

Das Routingmodul im Transportsubsystem und der Dienst Exchange-Routingmodul führen jeweils unterschiedliche Funktionen aus. Der Dienst Exchange-Routingmodul führt kein Nachrichtenrouting durch. Stattdessen kommuniziert der Dienst Exchange-Routingmodul Verbindungsstatusinformationen zwischen Servern in der lokalen Routinggruppe, auf denen Exchange 2000 Server und Exchange Server 2003 ausgeführt wird. Der Dienst Exchange-Routingmodul wird in der Datei resvc.dll implementiert, die sich im Verzeichnis \Programme\Exchsrvr\bin\ befindet. Der Dienstname lautet RESvc. Weitere Informationen zu den Microsoft Windows-Diensten von Exchange Server 2003 finden Sie unter Dienstabhängigkeiten in Exchange Server 2003.

Beim Dienst Exchange-Routingmodul handelt es sich im Grunde nicht um ein Routingmodul, sondern um einen Dienst zur Verbindungsstatuskommunikation innerhalb einer Routinggruppe. Das eigentliche Routingmodul, das vom erweiterten SMTP-Warteschlangenmodul und Exchange-MTA zum Nachrichtenrouting verwendet wird, wird in der Datei reapi.dll implementiert. Zusätzlicher Programmcode für den Exchange-MTA ist in mtaroute.dll enthalten. Wenn daher der Dienst Exchange-Routingmodul beendet wird, können Nachrichten vom erweiterten Warteschlangenmodul und Exchange-MTA trotzdem noch mit dem Programmcode der Datei reapi.dll geroutet werden. Es werden lediglich keine dynamischen Aktualisierungen der Verbindungsstatustabelle mehr empfangen.

Anmerkung:

Obwohl dies im Allgemeinen nicht empfohlen wird, können Sie den Dienst Exchange-Routingmodul auf allen Servern deaktivieren, auf denen Exchange Server 2003 in einer Organisation ausgeführt wird. Mit dem Code in reapi.dll kann die Verbindungsstatustabelle dennoch auf jedem Server mit Informationen aus Active Directory initialisiert werden, es erfolgen jedoch keine dynamischen Aktualisierungen der Verbindungsstatustabelle mehr. In diesem Fall wird von Exchange Server 2003 ein statisches Nachrichtenrouting ausgeführt.

Überprüfen der Verbindungsstatustabelle

Bei der Verbindungsstatustabelle handelt es sich um eine kleine, im Arbeitsspeicher abgelegte Datenbank, die nicht auf der Festplatte gespeichert wird. Zum Überprüfen der Einträge, auf deren Grundlage das Routingmodul entsprechende Routingentscheidungen trifft, können Sie das Tool Exchange Server 2003 WinRoute (Winroute.exe) verwenden, das auf der Website Downloads for Exchange Server 2003 heruntergeladen werden kann.

Anmerkung:
Das Tool WinRoute ist zwar ebenfalls im Lieferumfang von Exchange 2000 Server enthalten, es wird jedoch empfohlen, die Exchange Server 2003-Version dieses Tools herunterzuladen und für alle Exchange 2000- und Exchange Server 2003-Server in der Organisation zu verwenden.

Das Tool WinRoute stellt eine Verbindung mit dem Verbindungsstatusanschluss (TCP-Anschluss 691) auf dem ausgewählten Exchange-Server her und extrahiert die Verbindungsstatustabelle. Die Informationen in dieser Tabelle bestehen aus GUIDs und ASCII-Text zur Bezeichnung von Routinggruppen, Routinggruppenmitgliedern und Connectors in den Routinggruppen. Die Verbindungsstatustabelle enthält auch Informationen über die Konfiguration jedes einzelnen Connectors. Die Informationsfelder in der Verbindungsstatustabelle sind wie folgt durch Klammern voneinander getrennt:

'General Info' ('Routing Group' 'Routing Group Master' 'Version Info' 'Routing Group Addresses' (Routing Group Members) (Connectors in Routing Group (Connector configuration))).

Im folgenden Beispiel wird eine gekürzte Version einer Verbindungsstatustabelle dargestellt (außer für eine Routinggruppe wurden alle Felder entfernt):

d38082e7c9ecd74dbff32bada8932642 d037d6eaf2fa7cd10934aca433390623 (489416bfa3a4ff459b8f4403f20cad0d 1650c1fe32aef740be236e1089e0da6a 8 0 2 c2da71f9b39ec748aaf44119a2bdcb36 {26}*.489416BF-A3A4-FF45-9B8F-4403F20CAD0D {4c}c=DE;a= ;p=TailspinToys;o=Exchange;cn=489416BF-A3A4-FF45-9B8F-4403F20CAD0D;* {55}/o=TailspinToys/ou=First administrative Group/*/489416BF-A3A4-FF45-9B8F-4403F20CAD0D ( 1650c1fe32aef740be236e1089e0da6a YES 1 1b20 {10}0701000000000101 ) ( aa582d35e9621c4ca8ae57aa33d953a1 ( CONFIG {4}SMTP {} {23}_aa582d35e9621c4ca8ae57aa33d953a1_D {63}/o=TailspinToys/ou=First administrative Group/cn=Configuration/cn=Connections/cn=RGC RG A <-> RG B 0 0 0 0 ffffffff ffffffff 0 1 0 () 0 () 0 () 0 () ARROWS ( {2}RG {20}83bd0e29fad06d4eb8b00faab3265cd5 1 {4}X400 {23}c=DE;a= ;p=TailspinToys;o=Exchange; 1 ) BH () TARGBH ( 766a192b43bfc3459ee85608d65a98a9 CONN_AVAIL {19}server01.TailspinToys.com ) STATE UP)))

(... next routing group... (... next routing members...) (... connectors in routing group (... connector configuration..)))

In der folgenden Tabelle werden diese Informationen den verschiedenen Informationsfeldern in der Verbindungsstatustabelle zugeordnet.

Informationen in der Verbindungsstatustabelle

Feld	Wert	Beschreibung
Organisations-objectGUID	d38082e7c9ecd74dbff32bada8932642	Die GUID, die im objectGUID-Attribut des Exchange-Organisationsobjekts in Active Directory registriert ist.
MD5-Hashwert	d037d6eaf2fa7cd10934aca433390623	Ein MD5-Hashwert (Message Digest 5). Hierbei handelt es sich um eine verschlüsselte Signatur, die die Versionsnummer der Verbindungsstatustabelle angibt. Anhand dieser Informationen können Routingmodule feststellen, ob sie über dieselben Verbindungsstatusinformationen verfügen. Bei unterschiedlichen Informationen tauschen die Routingmodule OrgInfo-Pakete aus, um zu ermitteln, welcher Server über die neuesten Informationen verfügt. Das OrgInfo-Paket enthält die Verbindungsstatustabelle mit allen Details und den Zuständen der Routingtopologie. Die Weitergabe der Verbindungsstatusinformationen wird weiter unten in diesem Abschnitt behandelt.
Routinggruppen-objectGUID	489416bfa3a4ff459b8f4403f20cad0d	Die GUID, die im objectGUID-Attribut des Routinggruppenobjekts registriert ist, zu dem die Routinginformationen gehören. Diese GUID ist in der Verbindungsstatustabelle als nächstes Element aufgeführt.
Routinggruppenmaster-objectGUID	1650c1fe32aef740be236e1089e0da6a	Die GUID, die im objectGUID-Attribut des Servers registriert ist, der als Routinggruppenmaster in dieser Routinggruppe registriert ist. Der Routinggruppenmaster in jeder Routinggruppe ist für die Verwaltung und Kommunikation der Verbindungsstatusinformationen an alle Routinggruppenmitglieder verantwortlich. Es ist jeweils nur ein Routinggruppenmaster je Routinggruppe vorhanden. Weitere Informationen über die Funktion des Routinggruppenmasters finden Sie in weiter unten in diesem Abschnitt.
Versionsinformationen	8 0 2 c2da71f9b39ec748aaf44119a2bdcb36	Die Werte 8 0 2 stellen die Haupt-, Neben- und Benutzerversionsnummern der Verbindungsstatusinformationen dar. Das Routingmodul verwendet diese Versionsinformationen, um Aktualisierungen der Verbindungsstatusinformationen wie folgt zu klassifizieren: Große Aktualisierungen   Änderungen der Routingtopologie, beispielsweise Änderungen der Connectorkonfiguration (d. h. Hinzufügen oder Löschen eines Connectors, Hinzufügen oder Löschen eines Adressraums auf einem Connector oder Festlegen eines neuen Servers als Routinggruppenmaster). Kleine Aktualisierungen   Änderungen der Verfügbarkeit eines virtuellen Servers oder eines Connectors. Beispielsweise kann sich der Status eines Connectors von verfügbar zu nicht verfügbar ändern, wenn der Quellbridgeheadserver des Connectors nicht verfügbar ist. Benutzeraktualisierungen   Änderungen, die beim Starten oder Beenden von Diensten auf einem Exchange-Server oder bei Verlust der Verbindung eines Servers mit dem Routinggruppenmaster auftreten. Das Hinzufügen eines neuen Servers zu einer Routinggruppe stellt ebenfalls eine Benutzeraktualisierung dar. Die übrigen Daten stellen die GUID dieser Versionsinformationen dar.
Routinggruppenadressen	{26}*.489416BF-A3A4-FF45-9B8F-4403F20CAD0D {4c}c=DE;a= ;p=TailspinToys;o=Exchange;cn=489416BF-A3A4-FF45-9B8F-4403F20CAD0D;* {55}/o=TailspinToys/ou=First administrative Group/*/489416BF-A3A4-FF45-9B8F-4403F20CAD0D	In diesem Feld werden SMTP-, X.400-, X.500-Informationen und Adressinformationen einzelnen Routinggruppen-GUIDs zugeordnet. Das Routingmodul erstellt anhand dieser Informationen einen internen Servercache, der zur Bestimmung der Routinggruppe jedes Servers in der Routingtopologie verwendet wird. Der Servercache ist eine interne Tabelle des Routingmoduls. Beispiel: SERVER01 verfügt in einer Routinggruppe mit der Bezeichnung Erste Routinggruppe über den FQDN SERVER01.TailspinToys.com. Entsprechend der Routinggruppen-Adressdefinition erstellt das Routingmodul für SERVER01 folgenden Eintrag im Servercache: SERVER01.TailspinToys.com.489416BF-A3A4-FF45-9B8F-4403F20CAD0D. Wenn bei einem Routingereignis das erweiterte Warteschlangenmodul den FQDN an das Routingmodul übergibt, sucht das Routingmodul im Servercache den Eintrag für SERVER01.TailspinToys.com und bestimmt in kürzester Zeit die Zielroutinggruppe. Dasselbe Prinzip gilt auch für X.400- und X.500-Adressen. Die Adressinformationen sind in diesen Fällen jedoch komplexer.
Routinggruppenmitglieder	( 1650c1fe32aef740be236e1089e0da6a YES 1 1b20 {10}0701000000000101 )	Enthält eine Liste aller Server, die zur Routinggruppe gehören, und kennzeichnet deren Status. Beachten Sie jedoch, dass das Routingmodul diese Informationen nicht zum Nachrichtenrouting verwendet. Wie bereits an anderer Stelle in diesem Abschnitt erläutert, verwendet das Routingmodul den Servercache. Die Mitglieder der Routinggruppe sind in dieser Liste zum Zweck der Systemüberwachung aufgeführt. Sie können diese Informationen im Exchange-System-Manager anzeigen, indem Sie den Knoten Tools öffnen und anschließend auf Überwachung und Status sowie Status klicken. Die Serverstatuseinträge in der Liste der Routinggruppenmitglieder enthalten die folgenden Informationen: Server-objectGUID: 1650c1fe32aef740be236e1089e0da6a Angabe, ob das Mitglied mit dem Routinggruppenmaster verbunden ist. Mit YES wird angezeigt, dass der Server verbunden ist. Serverversionsnummer: 1 Build-Version: 1b20 hex = 6944 Benutzerdaten: {10}0701000000000101 Durch die Benutzerdaten wird der Status des Servers angegeben. Wenn der Wert mit 0701 beginnt, ist der Server verfügbar und funktionsbereit. Wenn der Wert mit 0702 beginnt, befindet sich der Server in einem Warnzustand. Wenn der Wert mit 0703 beginnt, befindet sich der Server in einem kritischen Zustand. Sie können einen Server in den Wartungsmodus schalten, um die Serverüberwachung vorübergehend zu deaktivieren. In diesem Fall beginnt der Wert mit 0781.
Connectors in Routinggruppe	( aa582d35e9621c4ca8ae57aa33d953a1 ( CONFIG ))	Beginnend mit der nächsten geöffneten Klammer wird jeder zur Routinggruppe gehörende Connector in einem separaten Eintrag aufgeführt, der die objectGUID des Connectors und die Konfigurationsinformationen enthält, anhand derer das Routingmodul die erforderlichen Entscheidungen bezüglich des Nachrichtenrouting trifft. Anmerkung: Zu den Connectorkonfigurationsinformationen in der Verbindungsstatustabelle gehören die Felder, die in den folgenden Tabelleneinträgen beschrieben werden:
Connector-objectGUID	aa582d35e9621c4ca8ae57aa33d953a1	Die GUID, durch die der Connector in der Exchange-Organisation eindeutig identifiziert wird.
Connectortyp	{4}SMTP	Nach dem Schlüsselwort CONFIG wird durch dieses Feld der Connectortyp identifiziert. Folgende Typen sind möglich: SMTP, X.400, Notes oder Exchange Development Kit (EDK). Die Typen Notes und EDK beziehen sich auf Instanzen eines MAPI-basierten Messagingconnectors, der mit einem anderen Messagingsystem als Exchange verbunden ist. Weitere Informationen über MAPI-basierte Connectors finden Sie unter Architektur von Gateway-Messaging-Connectors. Tipp Die Zahl in geschweiften Klammern ist kein Bezeichner. Durch diese Zahl wird die Länge der Zeichenfolge des Feldwerts im Hexadezimalformat angegeben. Anmerkung: Es gibt keinen speziellen Typ für Routinggruppenconnectors. Routinggruppenconnectors verwenden zum Übertragen von Nachrichten SMTP.
Adresse des Quellbridgeheadservers	{}	Dieses Feld kann drei verschiedene Werte enthalten: Kein Wert   Wenn kein Quellbridgeheadserver angegeben ist, kann jeder Server in der lokalen Routinggruppe diesen Connector zum Übertragen von Nachrichten verwenden. Dies gilt für Routinggruppenconnectors, wenn die Option Jeder lokale Server kann E-Mail über diesen Connector senden aktiviert ist. Eine Connector-GUID   Für SMTP-Connectors und Routinggruppenconnectors können Sie bestimmte lokale Bridgeheadserver angeben. In diesem Fall wird im Feld für die Adresse des Quellbridgeheadservers die Connector-GUID gefolgt von _S zur Kennzeichnung eines Quellbridgeheadservers aufgeführt. Beispiel: {23}_76290a25817c0643a1a6999e669b1d5f_S Die lokalen Bridgeheadserver werden dann im Bereich der Connectorinformationen im Feld BH aufgeführt. Eine Bridgeheadadresse   X.400-Connectors und MAPI-basierte Connectors können jeweils nur über einen lokalen Bridgeheadserver verfügen. Für diese Connectors wird der lokale Bridgeheadserver im Feld für die Adresse des Quellbridgeheadservers wie folgt angegeben: {8}SERVER01. Zum Bereitstellen von Verfügbarkeitsinformationen kann der lokale Bridgeheadserver auch im Feld BH in den Connectorinformationen enthalten sein.
Adresse des Zielbridgeheadservers	{23}_aa582d35e9621c4ca8ae57aa33d953a1_D	Dieses Feld kann wie das Feld für die Adresse des Quellbridgeheadservers drei verschiedene Werte enthalten: Kein Wert   X.400-Connectors und MAPI-basierten Connectors ist in der Verbindungsstatustabelle kein Zielbridgeheadserver zugeordnet. Diese Connectors verwenden zur Bestimmung des Zielsystems connectorspezifische Informationen, z. B. den Remotehostnamen in der Stackskonfiguration eines X.400-Connectors. Eine Connector-GUID   Für Routinggruppenconnectors wird im Feld für die Adresse des Zielbridgeheadservers die Connector-GUID aufgeführt, an die zum Kennzeichnen eines Zielbridgeheadservers die Zeichenfolge _D angehängt wird. In diesem Fall sind die Zielbridgeheadserver dann im Feld TARGBH der Connectorinformationen aufgeführt. Eine Bridgeheadadresse   SMTP-Connectors können nur einen Zielhost haben, wenn sie Routinggruppen miteinander verbinden. Für diese Connectorkonfiguration müssen Sie einen Smarthost in der Remoteroutinggruppe angeben, der dann als Zielbridgeheadserver angegeben wird. Beispiel: {8}SERVER02.
Legacy-DN	{63}/o=TailspinToys/ou=First administrative Group/cn=Configuration/cn=Connections/cn=RGC RG A <-> RG B	Dies ist der DN des Connectors im Exchange 5.5-kompatiblen Verzeichnisformat. Der Wert entspricht dem legacyExchangeDN-Attribut des Connectorobjekts in Active Directory.
Zeitplan-ID	0	Dieses Feld wird nicht verwendet und ist stets auf den Wert 0 festgelegt. Das erweiterte Warteschlangenmodul und der Exchange-MTA senden eine Abfrage an Active Directory, um den Aktivierungszeitplan eines Connectors zu ermitteln.
Einschränkungen	0 0 0 ffffffff ffffffff 0 1 0 () 0 () 0 () 0 ()	Durch dieses Feld werden der Bereich des Connectors, die Beschränkungen der Nachrichtengröße und andere Einschränkungen wie folgt angegeben: Der Bereich des Connectors wird durch die erste Ziffer angegeben. Der Wert 0 legt die Organisation als Bereich fest. Durch den Wert 1 wird die Routinggruppe als Bereich angegeben. Anmerkung: Routinggruppenconnectors wird stets die Organisation als Bereich zugeordnet. Connectors zu externen Messagingsystemen können auf die lokalen Routinggruppen beschränkt werden. Durch die nächste Ziffer wird angegeben, ob die ausgelöste Übermittlung konfiguriert ist. Der Wert 0 bedeutet, dass keine ausgelöste Übermittlung konfiguriert wurde. Der Wert 1 bedeutet, dass der Remotehost die Nachrichtenübertragung auslösen muss (z. B. TURN/ETRN). Durch die dritte Ziffer wird der Nachrichtentyp identifiziert (hoch, normal, niedrig, System und systemfremd), der über diesen Connector weitergeleitet werden darf. Durch die nächsten acht Bytes werden gegebenenfalls geltende Beschränkungen der Nachrichtengröße angegeben. Wenn für diesen Connector keine Beschränkungen der Nachrichtengröße gelten, lautet der Wert ffffffff. Durch den zweiten 8-Byte-Block wird angegeben, ob ein Schwellenwert für große Nachrichten festgelegt ist. Durch den Wert ffffffff wird angezeigt, dass kein Schwellenwert für Nachrichten angegeben wurde. Durch andere Werte wird der entsprechende Schwellenwert in KB angegeben. Durch die folgende Ziffer wird angegeben, ob Verweise auf Öffentliche Ordner zulässig sind (0 = zugelassen, 1 = nicht zugelassen). Die nächste Ziffer gibt an, ob Nachrichten von allen Absendern standardmäßig angenommen werden. Der Wert 1 bedeutet, dass standardmäßig alle Nachrichten angenommen werden. Der Wert 0 bedeutet, dass standardmäßig alle Nachrichten abgelehnt werden. Die nächsten vier Felder (0 () 0 () 0 () 0 ()) stellen Listen von Absendern und Verteilerlisten dar, denen das Senden von Nachrichten über diesen Connector gestattet oder verweigert wird. Die erste Liste enthält die DNs der zugelassenen Absender, die zweite Liste enthält die DNs der verweigerten Absender, und die letzten beiden Listen enthalten die zugelassenen bzw. abgelehnten Verteilergruppen. Die Zahlen vor den Klammern stehen für die Anzahl der Einträge in jeder Liste. Im folgenden Beispiel wird eine Liste mit zwei Absendern (das Format ist für alle Annahme- und Verweigerungslisten gleich) dargestellt: 2 ( {2d}CN=Ted Bremer,CN=Users,DC=TailspinToys,DC=com {30}CN=Administrator,CN=Users,DC=TailspinToys,DC=com ).
Adressräume	ARROWS ( {2}RG {20}83bd0e29fad06d4eb8b00faab3265cd5 1 {4}X400 {23}c=DE;a= ;p=TailspinToys;o=Exchange; 1 )	Jedem Connector ist mindestens ein Adressraum zugeordnet. Das Routingmodul ermittelt anhand dieser Informationen mögliche Connectors für eine bestimmte Nachricht, indem es die Empfängeradressen mit den verfügbaren Informationen über Adressräume vergleicht. In der Verbindungsstatustabelle enthält die Liste ARROWS () die einzelnen Adressräume, die zu dem Connector gehören. Jeder Adressraumeintrag enthält die folgenden drei Datenelemente: Adressraumtyp   Der Adressraumtyp bestimmt das Format der Adressrauminformationen, die in der nächsten Position folgen. Beispielsweise erfordert ein X.400-Adressraum Adressrauminformationen in einem gültigen X.400-Format. Ein SMTP-Adressraum enthält hingegen Teile eines SMTP-Domänennamens. Für Routinggruppenconnectors gilt der Adressraumtyp RG, der für die objectGUID einer Routinggruppe steht. Adressraum   Durch den Adressraum wird das Adressmuster angegeben, das vom Routingmodul zur Identifikation des Ziels der Nachricht mit den Empfängeradressen verglichen wird. Adressräume für externe und interne Empfänger werden vom Routingmodul jeweils unterschiedlich verwendet. Für externe Empfänger ist das Ziel ein Messagingconnector zum externen Messagingsystem. Das erweiterte Warteschlangenmodul übergibt die externen Adressinformationen an das Routingmodul, und das Routingmodul wählt den Connector aus, der die größtmögliche Übereinstimmung mit dem Ziel aufweist. Wenn ein SMTP-Connector z. B. über den Adressraum SMTP: *.net und ein anderer SMTP-Connector über den Adressraum SMTP: * verfügt, wählt das Routingmodul den ersten SMTP-Connector für alle Empfänger in .NET-Domänen und den zweiten SMTP-Connector für alle verbleibenden Internetempfänger aus. Für Empfänger in der lokalen Organisation sind in den Empfängerrichtlinien Adressräume definiert (Adressraumeinstellung Diese Exchange-Organisation ist für die gesamte E-Mail-Übermittlung an diese Adresse verantwortlich). Wenn die Adresse eines Empfängers mit einem Adressraum für die lokale Organisation übereinstimmt, ermittelt das Kategorisierungsmodul den Stammserver des Empfängers anhand des msExchHomeServerName-Attributs des Empfängers. Das Kategorisierungsmodul kennzeichnet den Empfänger mit dem FQDN des Stammservers. Das erweiterte Warteschlangenmodul übergibt diesen FQDN dann an das Routingmodul zur Weiterleitung der Nachricht an das Ziel in der lokalen Organisation. Das Routingmodul sucht anhand des FQDN nach dem entsprechenden Servercache. Der vom Routingmodul gefundene Eintrag für den Stammserver enthält die GUID des Stammservers des Empfängers. Das Routingmodul bestimmt anhand der GUID des Stammservers des Empfängers, wie die Nachricht übertragen werden muss: Wenn die Routinggruppen-GUID des Stammservers mit der GUID der lokalen Routinggruppe übereinstimmt, befindet sich der Empfänger in der lokalen Routinggruppe, und die Nachricht muss direkt mit dem standardmäßigen virtuellen SMTP-Server des Exchange-Servers an den Stammserver des Empfängers übertragen werden. Das Routingmodul gibt den FQDN des Stammservers des Empfängers an das erweiterte Warteschlangenmodul zurück, um den Host für den nächsten Hop anzugeben. Anmerkung: Server, auf denen Exchange Server 5.5 ausgeführt wird, stellen eine Ausnahme dar. Diese Server kommunizieren mit Exchange 2003 in der lokalen Routinggruppe über Remoteprozeduraufrufe und den MTA-Dienst, wie in bereits an anderer Stellte in diesem Abschnitt erläutert. Wenn die Routinggruppe des Stammservers nicht die lokale Routinggruppe ist, muss die Nachricht mit einem Routinggruppenconnector an das Ziel übertragen werden. Connectors, die Nachrichten an eine Routinggruppe übertragen können, müssen über einen Routinggruppen-Adressraum verfügen, der die GUID der Zielgruppe beinhaltet. Daher kann das Routingmodul eine Topologieansicht erstellen, die alle möglichen Übertragungspfade enthält, beginnend mit der Quelle bis hin zu sämtlichen möglichen Zielen in der Exchange-Organisation. Anhand der GUID der Routinggruppe des Empfängers kann das Routingmodul das endgültige Ziel der Nachricht in der Exchange-Organisation finden und dann den nächsten Hop auf dem kürzesten Weg zu diesem Ziel an das erweiterte Warteschlangenmodul zurückgeben. Dieser Vorgang wird weiter unten in diesem Abschnitt ausführlich beschrieben. Kosten   Kostenwerte sind Adressräumen zugeordnet. Anhand dieser Werte wird ermittelt, welcher Connector für die Nachrichtenübertragung zu bevorzugen ist. Der Wert kann im Bereich von 1 bis 100 liegen. Wenn für ein Ziel mehrere Connectors vorhanden sind, wird der Connector mit dem niedrigsten Kostenwert bevorzugt. Wenn mehreren Connectors der gleiche Kostenwert zugeordnet ist, wählt das Routingmodul einen zufälligen Connector aus und bietet so eine einfache Form von Lastenausgleich.
Quellbridgeheadserver	BH ()	Im Feld BH werden die lokalen Bridgeheadserver für den Connector sowie deren Statusinformationen aufgeführt. Bridgeheadserver werden anhand der folgenden drei Angaben identifiziert: Bridgeheadserver-objectGUID   Die GUID eines virtuellen SMTP-Servers, der in der Connectorkonfiguration als lokaler Bridgeheadserver angegeben ist. Bridgeheadserverstatus    Informationen zur Angabe der Verfügbarkeit des Bridgeheadservers: CONN_AVAIL   Der Bridgeheadserver ist verfügbar. VS_NOT_STARTED   Ein virtueller SMTP-Server wurde beendet oder nicht gestartet. CONN_NOT_AVAIL   Die Verbindung steht auf dem Bridgeheadserver nicht zur Verfügung. Beispielsweise kann der Quellbridgeheadserver keine Verbindung zu einem Zielbridgeheadserver herstellen. FQDN des virtuellen Servers   Der FQDN des virtuellen Servers, der diesem Connector als Bridgeheadserver dient.
Zielbridgeheadserver	TARGBH ( 766a192b43bfc3459ee85608d65a98a9 CONN_AVAIL {19}server01.TailspinToys.com )	Die Liste TARGBH () enthält analog zur Liste BH () die Zielbridgeheadserver für einen Connector. Diese Liste ist insbesondere für Routinggruppenconnectors wichtig, denen mehrere Remotebridgeheadserver zugeordnet sein können. Im nachstehenden Beispiel wird der Remotebridgeheadserver durch folgende Informationen identifiziert: Bridgeheadserver-objectGUID   766a192b43bfc3459ee85608d65a98a9 Bridgeheadserverstatus    CONN_AVAIL FQDN des virtuellen Servers   {19}server01.TailspinToys.com
Status	STATE UP	Der Connectorstatus. Dieses Feld kann zwei verschiedene Werte enthalten: STATE UP   Gibt an, dass der Connector verfügbar ist. STATE DOWN   Gibt an, dass der Connector nicht verfügbar ist. Der Connectorstatus wird vom Status der Quellbridgeheadserver des Connectors abgeleitet. Ein Connector befindet sich nur dann im Zustand STATE UP, wenn mindestens ein Quellbridgeheadserver verfügbar ist (CONN_AVAIL). Wenn kein virtueller Quellbridgeheadserver des Connectors gestartet wurde (VS_NOT_STARTED) oder die Quellbridgeheadserver keine Verbindung herstellen können (CONN_NOT_AVAIL), gilt der Connectorstatus STATE DOWN. Anmerkung: Ein Connector wird nur dann als inaktiv (STATE DOWN) gekennzeichnet, wenn kein lokaler Bridgeheadserver für diesen Connector verfügbar ist. Routinggruppenconnectors, die zur Verwendung der Option Jeder lokale Server kann E-Mail über diesen Connector senden konfiguriert wurden, sowie SMTP-Connectors mit DNS-Routing und MAPI-basierte Connectors werden niemals als inaktiv gekennzeichnet. Routinggruppenconnectors, bei denen ein Bridgeheadserver ein Exchange 5.5-Server ist, werden niemals als inaktiv gekennzeichnet.

Anmerkung:

Das Tool WinRoute bietet eine intuitive Ansicht der Routingtopologie und der Verbindungsstatustabelle. Dabei werden die GUIDs in der Verbindungsstatustabelle zu Namen in einem lesbaren Format aufgelöst, wenn das Tool Zugriff auf Active Directory hat. Im oberen Bereich des Programmfensters von WinRoute werden die umgewandelten Daten und im mittleren Bereich alle vorhandenen Adressräume angezeigt. Der untere Bereich enthält die unverarbeiteten Informationen aus der Verbindungsstatustabelle. Weitere Informationen über das Tool WinRoute finden Sie im Downloadbereich für Tools unter den Tools für Exchange Server 2003.

Exchange-Routingpfadauswahl

In einer Organisation mit mehreren Routinggruppen können unter Umständen verschiedene Pfade zum gleichen Ziel führen. In der Regel wird die effizienteste (d. h. die kürzeste oder kostengünstigste) Route für die Nachrichtenübertragung verwendet. Sollte die beste Route vorübergehend nicht zur Verfügung stehen, können zusätzliche, als Reserve bereitstehende Routen verwendet werden. Beispielsweise sind in der in der folgenden Abbildung dargestellten Topologie zwischen allen Routinggruppen mehrere Übertragungsrouten vorhanden.

Anmerkung:

Das Nachrichtenrouting sollte sich nach der physischen Netzwerktopologie richten. Wenn die zugrunde liegende Netzwerktopologie als eine echte Hub-and-Spoke-Anordnung (mit Routinggruppe A als Hub) konzipiert wurde, ist es kaum sinnvoll, die Routinggruppenconnectors wie in oben stehender Abbildung zu definieren. Stattdessen sollten die Routinggruppen B, C, D und E direkt mit der Routinggruppe A verbunden und die gesamte Nachrichtenübertragung zwischen verschiedenen Routinggruppen über die Routinggruppe A geleitet werden. In einer echten Hub-and-Spoke-Anordnung gibt es keine alternativen Nachrichtenpfade, und die Auswahl des Routingpfads erfolgt auf direktem Weg. Bei den Ausführungen in diesem Abschnitt wird jedoch davon ausgegangen, dass es sich bei der physischen Netzwerktopologie um ein Netz handelt, das der dargestellten Anordnung der Routinggruppenconnectors entspricht.

Das Routingmodul verwendet zur Bestimmung der besten Route die folgenden Informationen:

• Adressraum   Bei der Konfiguration von Routinggruppenconnectors werden auf der Registerkarte Verbundene Routinggruppen in den Connectoreigenschaften mögliche Ziele mit Messagingconnectors verknüpft. Der Routinggruppenconnector stellt jedoch diese Registerkarte nicht zur Verfügung. Da dieser Connector nur zur Verbindung mit Routinggruppen verwendet wird, kann das Routingmodul die Routinggruppen-Adressräume aus der Connectorkonfiguration ermitteln.
  
  Adressräume können einem Connector über die Registerkarte Adressraum hinzugefügt werden. Wie in der Tabelle „Informationen in der Verbindungsstatustabelle“ angegeben, bestehen Adressräume aus einem Adresstyp (z. B. RG, SMTP, X400, MSMAIL oder CCMAIL), einer Adresse und einem Kostenwert. Der Kostenwert, den Sie einem Adressraum zuweisen, stellt ein wichtiges Routingkriterium dar. Das Routingmodul trifft Routingentscheidungen mithilfe des Dijkstra-Algorithmus des kürzesten Weges. Dieser Algorithmus basiert auf Kostenwerten.

• Connectorbereich   Connectors zu externen Messagingsystemen können auf die Routinggruppe eines Connectors beschränkt werden, sodass die Verwendung des Connectors nur Benutzern in der lokalen Routinggruppe des Connectors gestattet wird. Standardmäßig ist für alle Connectors der Bereich Gesamte Organisation festgelegt.

  Anmerkung:
  Routinggruppenconnectors sind stets in der gesamten Organisation verfügbar.

• Einschränkungen   Das Routingmodul bestimmt die Nachrichtengröße, die Priorität und den Nachrichtentyp (d. h. Systemnachricht oder nicht vom System stammende Nachricht). Das Routingmodul vergleicht diese Eigenschaften mit den verfügbaren Informationen über Connectoreinschränkungen. Anschließend werden die Connectors, die diese Nachricht aufgrund wirksamer Connectoreinschränkungen nicht übertragen können, aus der Liste der potenziellen Connectors ausgeschlossen.

• Status   Nur verfügbare Connectors werden in den Prozess zur Routenauswahl aufgenommen. Im Statusfeld jedes Connectors ist angegeben, ob der Connector verfügbar (STATE UP) oder nicht verfügbar (STATE DOWN) ist.

Auswahl des Routingpfads

Zur Auswahl der besten Route zum Ziel berechnet das Routingmodul unter Verwendung des Dijkstra-Algorithmus des kürzesten Weges den kürzesten Übertragungsweg durch die Exchange-Organisation von der Quellroutinggruppe zur Zielroutinggruppe. Das Routingmodul bestimmt anschließend den nächsten Hop auf der kürzesten Route, die vom erweiterten Warteschlangenmodul für die Nachrichtenübertragung verwendet werden soll.

Die Auswahl des Routingpfads ist ein zweistufiger Vorgang:

1. Das erweiterte Warteschlangenmodul ruft in der IMessageRouter-Schnittstelle des Routingmoduls die GetMessageType-Methode auf. In der GetMessageType-Methode übergibt das erweiterte Warteschlangenmodul die Nachricht in Form eines MailMsg-Objekts an das Routingmodul.
   Für diesen Schritt führt das Routingmodul die folgenden Vorgänge aus:

   1. Das Routingmodul überprüft Nachrichtenverfolgungsinformationen, um Schleifen zu erkennen. Falls eine Nachrichtenschleife erkannt wird, löscht das Routingmodul diese Nachricht und sendet einen Unzustellbarkeitsbericht an den Absender.

   2. Die aktuelle Organisationstopologie wird gelesen oder bei Bedarf neu berechnet (d. h. die Liste der kürzesten Routen zu allen Zielen in der Routingtopologie, beginnend bei der lokalen Routinggruppe, wird ermittelt).

   3. Die Informationen über Einschränkungen bezüglich der Connectors in der Verbindungsstatustabelle werden überprüft und bei Bedarf aktualisiert.

   4. Das Routingmodul bestimmt alle Connectors zum Nachrichtenziel in der Organisationstopologie und analysiert dann die Nachrichtenmerkmale und Connectoreinschränkungen, um alle Connectors auszuschließen, die nicht zur Übertragung der Nachricht verwendet werden dürfen.

   5. Für die Nachricht wird ein Filterwert berechnet, der den Nachrichtentyp eindeutig definiert. Der Nachrichtentyp identifiziert den tatsächlichen Pfad, den Nachrichten mit ähnlichen Merkmalen verwenden können. Der Nachrichtentyp wird zwischengespeichert. Daher muss der Filterwert für darauf folgende Nachrichten mit ähnlichen Merkmalen nicht erneut durch das Routingmodul berechnet werden.

      Anmerkung:
      Das erweiterte Warteschlangenmodul verwaltet für jeden Nachrichtentyp jeweils eine gesonderte Nachrichtenwarteschlange.

   6. Anschließend werden zugeordnete Nachrichtentypen erstellt. Ein zugeordneter Nachrichtentyp ähnelt dem tatsächlichen Nachrichtentyp, wird jedoch mit geringeren Einschränkungen berechnet. Zugeordnete Nachrichtentypen ermöglichen dem SMTP-Transportsubsystem die Rückgabe erweiterter Fehlercodes, wenn ein Übertragungspfad für den tatsächlichen Nachrichtentyp aufgrund von Connectoreinschränkungen nicht verfügbar sein sollte.

   7. Der Index des zwischengespeicherten Nachrichtentyps wird an das erweiterte Warteschlangenmodul zurückgegeben.

2. Das Routingmodul ermittelt den nächsten Hop auf der kürzesten Route. Zum Abschließen dieses Schritts ruft das erweiterte Warteschlangenmodul in der IMessageRouter-Schnittstelle die GetMessageType-Methode auf. Die wichtigsten Informationen, die das erweiterte Warteschlangenmodul zu diesem Zeitpunkt an das Routingmodul übergibt, sind die Zieladresse und die Nachrichtentyp-ID. Die Zieladresse für Empfänger in der Exchange-Organisation ist der FQDN des Stammservers des Empfängers. Das Routingmodul ermittelt die Zielroutinggruppe aus dem Servercache, überprüft die verfügbare Route für den Nachrichtentyp und gibt den nächsten Hop in der Route zur Zielroutinggruppe an das erweiterte Warteschlangenmodul zurück. Das erweiterte Warteschlangenmodul kann die Nachricht dann an den nächsten Hop auf dem Weg zum Ziel übertragen.

Dijkstra-Algorithmus des kürzesten Weges

Damit das Routingmodul richtige Routingentscheidungen treffen kann, muss es die kürzeste Route zu allen möglichen Zielen in der Routingtopologie kennen. Das Routingmodul muss die kürzesten Routen aus allen verfügbaren Übertragungsrouten zu allen Zielen in einer komplexen Routingtopologie suchen. Dieses Problem wird auch als „Problem der kürzesten Weges von einem Ausgangspunkt“ bezeichnet.

In der folgenden Abbildung wird veranschaulicht, dass sogar in einer relativ einfachen Routingtopologie zahlreiche Routen von einer Routinggruppe zu jeder anderen Routinggruppe führen können. In der Abbildung werden die Routinggruppenconnectors aus Abbildung 5.4 in vereinfachter Form mit dem standardmäßigen Kostenwert 1 dargestellt.

Im Jahr 1959 wurde das Problem des kürzesten Weges von einem Ausgangspunkt durch Professor Edsger Dijkstra gelöst. Professor Dijkstra entwickelte einen Algorithmus, mit dem die kürzesten Wege von einem gegebenen Ausgangspunkt zu allen Punkten in einer Topologie mittels einer einzigen Berechnung ermittelt werden können.

Das Routingmodul verwendet den Dijkstra-Algorithmus wie folgt:

1. Es wird davon ausgegangen, dass die Routingtopologie alle Pfade von einer Routinggruppe zu allen anderen Routinggruppen in einer umfassenden Struktur abbildet. Daraus ergibt sich, dass die Topologie alle Routinggruppen und Routinggruppenconnectors enthalten muss und dass zwischen Routinggruppen keine Schleifen bestehen dürfen. Daher sind Pfade in der Routingtopologie, auf denen eine Nachricht zur Quellroutinggruppe zurückkehren kann, unzulässige Übertragungspfade und werden nicht in die Berechnung einbezogen.
2. Auf Grundlage des Algorithmus von Dijkstra verwaltet das Routingmodul zwei Sätze von Routinggruppen. Der erste Satz enthält alle Gruppen, für die der kürzeste Pfad von der Quellroutinggruppe aus bereits bestimmt wurde. Der zweite Satz umfasst alle übrigen Routinggruppen. Zunächst ist der Satz der Routinggruppen, für die die kürzesten Pfade von der Quellroutinggruppe aus bereits bestimmt wurde, noch leer. Solange noch Routinggruppen vorhanden sind, die noch nicht verarbeitet wurden, führt das Routingmodul die Schritte 3 bis 6 wie folgt aus.
3. Das Routingmodul sortiert die verbleibenden Routinggruppen nach der aktuellen besten Schätzung der Entfernung (d. h. die Summe der Kostenwerte) zur Quellroutinggruppe.
4. Anschließend wird die am nächsten liegende Routinggruppe zum Satz der Routinggruppen hinzugefügt, deren kürzeste Pfade bereits bestimmt wurden.
5. Das Routingmodul aktualisiert dann die Kosten aller mit dieser Routinggruppe verbundenen Routinggruppen (falls sich dadurch die beste Schätzung des kürzesten Pfads für jede der restlichen Routinggruppen verbessert), indem der Kostenwert des Connectors zwischen diesen Routinggruppen in den Entfernungswert einbezogen wird.
6. Für alle aktualisierten Routinggruppen wird dann auch der Vorgänger aktualisiert. Durch die Liste der Vorgänger wird schließlich der kürzeste Pfad von jeder Routinggruppe zur Zielroutinggruppe definiert.

Im folgenden Schritt wird veranschaulicht, wie das Routingmodul den kürzesten Pfad von der Routinggruppe A zu allen anderen Routinggruppen in der Routingtopologie ermittelt:

1. Die Quelle ist Routinggruppe A. Aus diesem Grund beginnt die Berechnung bei Routinggruppe A. Der Entfernungswert der Routinggruppe A zu sich selbst ist gleich null. Der Entfernungswert aller anderen Routinggruppen wurde noch nicht ermittelt.
2. Routinggruppe A wird zum Satz der Routinggruppen hinzugefügt, deren kürzeste Pfade von der Quellroutinggruppe aus bereits bestimmt wurden. Anschließend wird der Entfernungswert aller Routinggruppe A benachbarten Routinggruppen mit den Kostenwerten der entsprechenden Connectors aktualisiert. Der Vorgänger (Ausgangspunkt der schwarzen Pfeile) dieser Routinggruppen wird dann aktualisiert. Der Vorgänger ist Routinggruppe A.
3. Das Routingmodul sortiert die restlichen Routinggruppen nach der aktuellen besten Schätzung der jeweiligen Entfernung zur Quellroutinggruppe. Die am nächsten liegende Routinggruppe wird zum Satz der Routinggruppen hinzugefügt, deren kürzeste Pfade bereits bestimmt wurden. Da der Entfernungswert für die Routinggruppen B und C jeweils gleich ist, wählt das Routingmodul eine Routinggruppe nach dem Zufallsprinzip aus. In diesem Beispiel wird angenommen, dass Routinggruppe B ausgewählt wird.
4. Das Routingmodul berechnet den Entfernungswert aller übrigen Routinggruppe B benachbarten Routinggruppen, indem der Kostenwert des Connectors zwischen Routinggruppe B und der benachbarten Routinggruppe mit dem Entfernungswert von Routinggruppe B kombiniert wird. Der Entfernungswert einer benachbarten Routinggruppe wird nur dann aktualisiert, wenn der berechnete Entfernungswert kleiner als der Wert ist, der dieser Routinggruppe bereits zugeordnet ist. Nur in diesem Fall wird auch der Vorgänger aktualisiert (durch schwarze Pfeile gekennzeichnet).
   Die Nachbarn von Routinggruppe B sind die Routinggruppen C, D und E. Der aktuelle Entfernungswert der Routinggruppen C und D ist nicht definiert. Daher wird der Entfernungswert dieser Routinggruppen durch die Kostenwerte der entsprechenden Connectors aktualisiert, zuzüglich des Entfernungswerts der Routinggruppe B (1+1). Dann wird der Vorgänger (Ausgangspunkt der schwarzen Pfeile) dieser Routinggruppen aktualisiert. Der Vorgänger ist Routinggruppe B.
   Routinggruppe C wird nicht aktualisiert, da die Summe aus dem Entfernungswert von Routinggruppe C und dem Connectorkostenwert (1+1) größer ist als der aktuelle Entfernungswert von Routinggruppe C.
5. Das Routingmodul sortiert die restlichen Routinggruppen nach der aktuellen besten Schätzung der Entfernung zur Quellroutinggruppe und fügt die am nächsten liegende Routinggruppe zum Satz der Routinggruppen hinzu, deren kürzeste Pfade bereits ermittelt wurden. Der Algorithmus wählt nun Routinggruppe C aus, da dieser Routinggruppe der kleinste Entfernungswert zugeordnet ist.
6. Das Routingmodul berechnet den Entfernungswert aller übrigen Routinggruppe C benachbarten Routinggruppen, indem der Kostenwert des Connectors zwischen Routinggruppe C und den benachbarten Routinggruppen mit dem Entfernungswert von Routinggruppe C kombiniert wird. Der Entfernungswert einer benachbarten Routinggruppe wird nur dann aktualisiert, wenn der berechnete Entfernungswert kleiner als der Wert ist, der dieser Routinggruppe bereits zugeordnet ist. Nur in diesem Fall wird auch der Vorgänger aktualisiert (durch schwarze Pfeile gekennzeichnet).
   Die übrigen als Nachbarn von Routinggruppe C geltenden Routinggruppen sind die Routinggruppen D und E (die Routinggruppen A und B wurden bereits verarbeitet).
   Der aktuelle Entfernungswert der Routinggruppen D und E beträgt 2. Dieser Wert ist kleiner als die Summe der Connectorkosten und des Entfernungswerts der Routinggruppe C (1+2). Aus diesem Grund werden der Entfernungswert und die Vorgängerliste der Routinggruppen D und E nicht aktualisiert.
7. Das Routingmodul sortiert die restlichen Routinggruppen (Routinggruppe D und E) nach der aktuellen besten Schätzung ihrer Entfernung zur Quellroutinggruppe und fügt die am nächsten liegende Routinggruppe zum Satz der Routinggruppen hinzu, deren kürzeste Pfade bereits ermittelt wurden.
   Da der Entfernungswert für die Routinggruppen D und E jeweils gleich ist, wählt das Routingmodul eine Routinggruppe nach dem Zufallsprinzip aus. In diesem Beispiel wird angenommen, dass Routinggruppe D ausgewählt wird.
   Der einzige verbleibende Nachbar ist Routinggruppe E, deren aktueller Entfernungswert 2 beträgt. Dieser Wert ist kleiner als die Summe der Connectorkosten und des Entfernungswerts von Routinggruppe D (1+2). Aus diesem Grund werden der Entfernungswert und die Vorgängerliste von Routinggruppe E nicht aktualisiert.
   Routinggruppe E ist die letzte Routinggruppe, die noch nicht zur Liste der Routinggruppen hinzugefügt wurde, deren kürzeste Pfade ermittelt wurden. Es sind keine benachbarten Routinggruppen mehr vorhanden. Die Berechnung des kürzesten Pfads ist somit abgeschlossen. Die kürzesten Pfade von Routinggruppe A zu jeder anderen Routinggruppe in der Topologie wurden ermittelt.

Lastenausgleich bei der Nachrichtenübertragung

Wenn mehrere Pfade mit jeweils gleichen Kostenwerten vorhanden sind, wählt das Routingmodul – wie im vorhergehenden Schritt erläutert – einen Übertragungspfad nach dem Zufallsprinzip aus. Das Routingmodul führt jedoch keinen Lastenausgleich durch. Wie bereits an früherer Stelle erläutert, speichert das Routingmodul die Informationen zum Nachrichtentyp, die auf den kürzesten Pfad verweisen, auf dem eine Nachricht zum Ziel gelangen kann. Daher werden alle Nachrichten eines bestimmten Typs auf demselben Pfad übertragen, selbst wenn ein anderer Pfad mit dem gleichen Kostenwert vorhanden ist (z. B. „Routinggruppe A > Routinggruppe B > Routinggruppe E“ und „Routinggruppe A > Routinggruppe C > Routinggruppe E“).

Lastenausgleich zwischen Routinggruppen

Echter Lastenausgleich zwischen Routinggruppen kann nur mithilfe eines Routinggruppenconnectors mit mehreren Bridgeheadservern erzielt werden.

In der folgenden Tabelle werden die Lastenausgleichskonfigurationen aufgeführt, die zwischen Routinggruppen verwendet werden können.

Mögliche Konfigurationen zwischen Routinggruppen

Mögliche Konfiguration	Beschreibung
Ein einzelner Routinggruppenconnector mit mehreren Quell- und/oder Zielbridgeheadservern.	Bei diesen Connectortypen gibt das Routingmodul in den Informationen zum nächsten Hop die Connector-GUID für das erweiterte Warteschlangenmodul zurück. Das erweiterte Warteschlangenmodul wählt dann nach dem Zufallsprinzip den zu verwendenden Bridgeheadserver aus und führt so einen Lastenausgleich für die Nachrichtenübertragung über alle Bridgeheadserver aus. Bei Eingang einer Nachricht auf einem Quellbridgeheadserver eines Routinggruppenconnectors mit mehreren Quellbridgeheadservern wird diese Nachricht nicht an einen anderen Quellbridgeheadserver umgeleitet. Nach Eingang der Nachricht beim Routinggruppenconnector erfolgt eine direkte Nachrichtenübertragung an die Zielroutinggruppe. Daher verwenden Benutzer, die Postfächer auf dem Bridgeheadserver besitzen, stets den lokalen Server für die Nachrichtenübertragung an die Zielroutinggruppe. Anmerkung: Es wird empfohlen, mehrere Quell- und Zielbridgeheadserver für einen einzelnen Routinggruppenconnector zwischen zwei Routinggruppen anzugeben. Auf diese Weise wird der Lastenausgleich und die Redundanz verbessert.
Mehrere Connectors mit demselben Adressraum (oder derselben verbundenen Routinggruppe) und derselben Gewichtung (Kosten), wobei für jeden Connector ein Quell- und ein Zielbridgeheadserver vorhanden ist	Bei diesem Konfigurationstyp wird kein echter Lastenausgleich erreicht. Der Lastenausgleich beschränkt sich auf die anfängliche Auswahl eines Connectors für einen angegebenen Nachrichtentyp. Durch das Routingmodul wird der Nachrichtentyp einmalig bestimmt und zwischengespeichert. Anschließend werden alle Nachrichten desselben Typs über diesen Connector geleitet. Der zweite Connector wird nur bei Ausfall des ersten Connectors verwendet. Ein zweiter Server kann jedoch unter Umständen den zweiten Connector auswählen und auf diese Weise einen gewissen Lastenausgleich erzielen. Anmerkung: Ein Lastenausgleich mit mehreren Connectorinstanzen zwischen den Routinggruppen ist nicht sinnvoll, da auf diese Weise kein echter Lastenausgleich erzielt werden kann.
Mehrere Connectors mit demselben Adressraum (oder derselben verbundenen Routinggruppe) und unterschiedlicher Gewichtung (Kosten), wobei für jeden Connector ein Quell- und ein Zielbridgeheadserver vorhanden ist	Wenn Connectors für einen automatischen Failover konfiguriert werden sollen, können Sie auf verschiedenen Bridgeheadservern zwei getrennte Connectors mit unterschiedlichen Kosten erstellen. Der Verbindungsstatus eines Connectors wird durch den zugehörigen lokalen Bridgeheadserver festgelegt. Wenn der Bridgeheadserver des bevorzugten Connectors mit den niedrigsten Kosten nicht verfügbar ist, wird dieser Connector beim Routing als nicht verfügbar betrachtet und der zweite Connector gewählt. Ist der Bridgeheadserver des Connectors mit den niedrigsten Kosten wieder verfügbar, wird dieser von den Servercomputern mit Exchange erneut verwendet.

Lastenausgleich zwischen Connectors und externen Systemen

Abhängig vom jeweiligen Szenario kann der Lastenausgleich über mehrere SMTP-Connectors hinweg auf verschiedene Weise erzielt werden.

• Wenn Sie Lastenausgleich für ausgehende Anforderungen in der sendenden Organisation über mehrere Server hinweg durchführen möchten, konfigurieren Sie mehrere Quellbridgeheadserver.
• Wenn Sie den Lastenausgleich des Datenverkehrs über mehrere Zielserver hinweg durchführen möchten, muss der Zieladministrator DNS (mithilfe einer geeigneten Konfiguration von MX- und A-Datensätzen) ordnungsgemäß konfigurieren, oder Sie geben mehrere Smarthostadressen für den Connector an.

Wenn Sie Failoverflexibilität sicherstellen möchten, können Sie auch mehrere SMTP-Connectors erstellen, die für den gleichen Adressraum gültig sind, jedoch unterschiedliche Kostenwerte und Bridgeheadserver besitzen. Wenn der Bridgeheadserver des bevorzugten Connectors mit den niedrigsten Kosten nicht verfügbar ist, wird der Connector beim Routing als nicht verfügbar bewertet und der zweite Connector gewählt. Wenn Sie zwei Connectors mit den gleichen Kostenwerten verwenden, wählen die Servercomputer mit Exchange nach dem Zufallsprinzip aus, welcher Bridgeheadserver und Connector verwendet wird. Wenn dann dieser Bridgeheadserver nicht mehr verfügbar ist, wird ein Failover auf den zweiten Connector durchgeführt. Wird jedoch der erste Bridgeheadserver erneut verfügbar, erfolgt kein Failover auf diesen Server, da diese Route dieselben Kosten aufweist wie die bereits verwendete.

Bei der Connectorkonfiguration in der folgenden Abbildung handelt es sich beispielsweise nicht um eine Lastenausgleichskonfiguration für Failover, da die Adressräume nicht übereinstimmen. An externe Benutzer in einer .NET-Domäne gesendete Nachrichten durchlaufen immer den SMTP-Connector mit dem .NET-Adressraum. Der Grund hierfür ist, dass das Routingmodul vor einer Bewertung der Kosten den detailliertesten, d. h. die am genauesten bestimmte Adresse auswählt.

Anmerkung:

Wenn für den Connector mit dem .NET-Adressraum Einschränkungen festgelegt wurden und diese Einschränkungen verhindern, dass bestimmte Nachrichten diesen Connector durchlaufen (z. B. weil dem Absender die Nachrichtenübertragung über diesen Connector verweigert wird), gibt das Routingmodul die Nachricht mit einem Unzustellbarkeitsbericht an den Absender zurück. Das Routingmodul wechselt nicht zum zweiten Connector, um diese Nachrichten zu senden. Durch den detailliertesten Adressraum wird festgelegt, welche Connectors zur Übertragung einer Nachricht verwendet werden können. Connectors mit einem Adressraum, der weniger genau bestimmt ist, werden aus der Routenberechnung ausgeschlossen.

Erneutes Routing von Nachrichten anhand von Verbindungsstatusinformationen

Wenn Nachrichten von einem Connector nicht übertragen werden können, informiert das erweiterte Warteschlangenmodul das Routingmodul über einen Verbindungsfehler. Dies kann unter Umständen dazu führen, dass das Routingmodul den Connector als nicht verfügbar kennzeichnet und alle in der Warteschlange befindlichen Nachrichten umgeleitet werden.

Ein Connector wird vom Routingmodul als nicht verfügbar eingestuft, wenn eine der folgenden Bedingungen zutrifft:

• Das Routingmodul kann mit mindestens einem Quellbridgeheadserver des Connectors keine Verbindung herstellen, und es besteht keine TCP/IP-Verbindung mit Anschluss 691 zwischen dem Routinggruppenmaster und den Quellbridgeheadservern. Nicht verfügbare Quellbridgeheadserver werden in der Verbindungsstatustabelle durch den Eintrag VS_NOT_STARTED gekennzeichnet.
• Kein Quellbridgeheadserver kann die Nachricht erfolgreich an einen Zielbridgeheadserver übertragen. Quellbridgeheadserver, die keine Nachrichten an das Ziel übertragen können, werden mit CONN_NOT_AVAIL gekennzeichnet.

Anmerkung:
Wenn Sie X.400-Connectors verwenden und der Connector keine Nachrichten übertragen kann, informiert der Exchange-MTA das Routingmodul darüber, dass ein Verbindungsfehler aufgetreten ist. In diesem Fall erhält der Quellbridgeheadserver den Status CONN_NOT_AVAIL. X.400-Connectors können nur mit jeweils einem Quellbridgeheadserver verbunden sein.

Erneutes Routing von Nachrichten

Zur Gewährleistung einer effizienten Nachrichtenübertragung informiert das Routingmodul das erweiterte Warteschlangenmodul und den Exchange-MTA sofort über alle Verbindungsstatusänderungen. Damit Nachrichten nicht über unterbrochene Übertragungspfade gesendet werden, müssen alle in der Warteschlange befindlichen Nachrichten umgeleitet werden. Dieser Vorgang wird als erneutes Routing bezeichnet. Beim erneuten Routing löscht das erweiterte Warteschlangenmodul alle zwischengespeicherten Informationen über den nächsten Hop, da diese nicht mehr gültig sind. Alle Nachrichten, die gegenwärtig zur Übertragung anstehen, werden erneut an das Routingmodul übergeben, das den nächsten Hop erneut berechnet. Dies kann eine ressourcenintensive Aufgabe sein.

In der folgenden Abbildung wird als Beispiel ein erneuter Routingvorgang veranschaulicht, bei dem der Bridgeheadserver in Routinggruppe E nicht verfügbar ist. Es können derzeit keine Nachrichten an diese Routinggruppe übertragen werden. Bei der Neuberechnung der kürzesten Pfade zu den Empfängern in Routinggruppe E erkennt das Routingmodul, dass kein Pfad verfügbar ist. Connectors, die als nicht verfügbar gekennzeichnet sind, werden vom Routingvorgang ausgeschlossen. Aus diesem Grund ist die Routinggruppe E derzeit isoliert.

Da keine gültigen Pfade vorhanden sind, kann das Routingmodul keinen gültigen nächsten Hop für Nachrichten ermitteln, die zur Übertragung an die Routinggruppe E anstehen. Das Routingmodul informiert das erweiterte Warteschlangenmodul in den Informationen über den nächsten Hop darüber, dass der nächste Hop nicht erreichbar ist. Das erweiterte Warteschlangenmodul muss die Nachricht solange speichern, bis mindestens wieder ein Übertragungspfad verfügbar ist oder bis die Nachricht abläuft und mit einem Unzustellbarkeitsbericht an den Absender zurückgesendet wird.

Anmerkung:
Wenn nur ein Connector zu einer Routinggruppe vorhanden ist und keine alternativen Pfade vorhanden sind, wird der Verbindungsstatus immer als verfügbar gekennzeichnet, um die Anzahl der Verbindungsstatusänderungen in der Routingtopologie zu verringern. Die Nachrichten werden von Exchange Server 2003 in eine Warteschlange gestellt und gesendet, sobald die Route wieder zur Verfügung steht.

Erneutes Routing und Adressräume

In Exchange Server 2003 kann (analog zum Lastenausgleich) ein erneutes Routing von Nachrichten nur über Connectors ausgeführt werden, die denselben Adressraum besitzen. Beispielsweise können Sie zwei separate Connectors auf verschiedenen Bridgeheadservern einrichten, wobei beiden Connectors jeweils derselbe Adressraum, jedoch unterschiedliche Kostenwerte zugeordnet sind. Wenn der bevorzugte Connector ausfällt, wählt das Routingmodul automatisch den zweiten Connector aus, bis der primäre Connector wieder zur Verfügung steht.

Anmerkung:
Das Routingmodul leitet Nachrichten von einem Connector mit einem genau bestimmten Adressraum nicht an einen Connector mit einem weniger genau bestimmten Adressraum um, da das Routingmodul diesen als ein anderes Ziel betrachtet. Die Nachrichten verbleiben daher auf dem Quellbridgeheadserver, bis der Connector mit dem genau bestimmten Adressraum wieder verfügbar ist.

Wenn für den Connector mit dem .NET-Adressraum Einschränkungen festgelegt wurden und diese Einschränkungen verhindern, dass bestimmte Nachrichten diesen Connector durchlaufen – z. B. weil dem Absender die Nachrichtenübertragung über diesen Connector verweigert wird –, gibt das Routingmodul die Nachricht mit einem Unzustellbarkeitsbericht an den Absender zurück. Das Routingmodul wechselt nicht zum zweiten Connector, um diese Nachrichten zu senden. Durch den detailliertesten Adressraum wird festgelegt, welche Connectors für die Übertragung einer Nachricht verwendet werden können. Connectors mit einem Adressraum, der weniger genau bestimmt ist, werden aus der Routenberechnung ausgeschlossen.

Connectorwiederherstellung

Das Routingmodul ermittelt nach einer der folgenden Methoden, ob ein Connector wieder zur Verfügung steht:

• VS_NOT_STARTED   Der Routinggruppenmaster stellt eine Verbindung mit TCP-Anschluss 691 auf dem Quellbridgeheadserver her. Der Quellbridgeheadserver wird mit dem Status CONN_AVAIL gekennzeichnet. Da mindestens ein Quellbridgeheadserver für den Connector verfügbar ist, wechselt der Connectorstatus zu STATE UP.
• CONN_NOT_AVAIL   Bei nicht verfügbaren Connectors erfolgt durch die Quellbridgeheadserver alle 60 Sekunden ein erneuter Versuch zum Herstellen einer Verbindung, selbst wenn keine Nachrichten zur Übertragung anstehen. Nachdem eine Verbindung hergestellt wurde, meldet das erweiterte Warteschlangenmodul oder der Exchange-MTA eine erfolgreich hergestellte ausgehende Verbindung vom Quellbridgeheadserver an das Routingmodul. Das Routingmodul ändert daraufhin den Status des Quellbridgeheadservers in CONN_AVAIL und den Connectorstatus in STATE UP.

Erneutes Routing und Aktivierungszeitpläne

Bei allen Connectortypen können Sie einen Zeitplan für den Connector konfigurieren, mit dem sich E-Mail-Nachrichten jeweils zu bestimmten Zeiten übertragen lassen. Connectors können wahlweise so konfiguriert werden, dass sie stets aktiv sind, nur zu bestimmten Zeitpunkten aktiviert werden oder niemals aktiv sind. Im letzten Fall werden keine Nachrichten über den Connector übertragen, bis der Connectorzeitplan erneut geändert wird. Sie können einen Connector auch mit Remote eingeleitet konfigurieren, sodass der Connector selbst keine Verbindung initiiert. Stattdessen wartet der Connector, bis ein Remoteserver die Verbindung herstellt und die Nachrichtenübertragung startet.

Der Connectorzeitplan betrifft lediglich die Nachrichtenübertragung. Er hat keinen Einfluss auf das Routing der Nachrichten. Connectors mit einem beliebigen Zeitplantyp werden vom Routingmodul als verfügbar betrachtet, wenn für diese Connectors der Status STATE UP angegeben wird. Daher können Nachrichten unter Umständen auch an Connectors geleitet werden, deren Aktivierungszeitplan auf Nie festgelegt wurde. Für diese Connectors werden jedoch keine Verbindungsstatusänderungen und kein erneutes Routing ausgeführt. Die Nachrichten verbleiben dann in der Warteschlange des Connectors, bis der Aktivierungszeitplan geändert wird. Dies gilt auch für remote eingeleitete Connectors. Nachrichten werden nicht erneut geroutet, während sie auf das Abrufen warten.