Exchange Server 2007

Aktualisieren Ihrer Infrastruktur auf Exchange 2007

Kate Follis

Kurz zusammengefasst:

• Neue Funktionen in Exchange 2007
• Vorbereitung auf eine Aktualisierung
• Rollenbasierte Bereitstellung
• Nachrichtenroutingtopologie

Einer der von mir unterrichteten Kurse befasste sich mit der Migration von Exchange Server 5.5 zu Exchange 2000. Der Unterricht begann morgens um 8:30 Uhr und dauerte bis abends um 18:00 Uhr. Wenn ich den Schulungsraum abends verließ,

war ich vollkommen gerädert. Es gab extrem viel vorzubereiten, nur um die Verzeichnisressourcen zu verschieben, und außerdem viel Verwirrung um NTDSNoMatch und das wackelige Vertrauen in Windows NT® 4.0, das ein Vertrauen schier unmöglich machte. Aus Zeitgründen hatten wir kaum Gelegenheit, auf die Exchange 2000 Server-Verwaltung einzugehen, aber es gab immer ein paar wissensbegierige Kursteilnehmer, die den Schulungsraum am Freitag Abend verlassen und die Migration über das Wochenende abschließen wollten. Davon habe ich immer abgeraten und mehr Planungszeit empfohlen, aber ich bin sicher, dass sie meine Warnung einfach ignoriert haben.

Der Übergang von Exchange 2000 Server oder Exchange Server 2003 zu Exchange Server 2007 erfordert ebenso Vorsicht und Vorausplanung. Der eigentliche Übergangsprozess ist je nach Organisation und der Komplexität der aktuellen Bereitstellung unterschiedlich, der Übergangsprozess erfordert jedoch nach wie vor ein Durchlaufen mehrerer Phasen. Eine kleine Organisation kann diese Phasen möglicherweise in einem einzelnen Projekt durchlaufen, während eine große Organisation möglicherweise entscheidet, Serverrollen schrittweise einzuführen und Exchange in einem Koexistenzmodus für einen bestimmten Zeitraum zu unterstützen. Der End-to-End-Prozess ist so entworfen, dass Messagingfunktionalität und -stabilität für den gesamten Übergangszeitraum aufrechterhalten werden. In diesem Artikel werden die wichtigsten Schritte beschrieben, die für eine Beibehaltung des Nachrichtenflusses innerhalb Ihrer Organisation erforderlich sind, während Sie auf Exchange Server 2007 aktualisieren.

Besonderheiten

Die erste Anforderung, auf die geachtet werden muss, ist, dass Exchange Server 2007 auf 64-Bit-Hardware bereitgestellt werden muss und keine direkte Aktualisierung von einer früheren Version von Exchange unterstützt. Sie müssen die Swingaktualisierungsmethode verwenden, um Ihre vorhandenen Messagingdienste zu Exchange 2007 zu verschieben. Die Exchange-Organisation muss sich außerdem im einheitlichen Modus befinden, um die zusätzlichen Exchange 2007-Server zu unterstützen. Wenn Ihre Organisation derzeit Exchange 5.5 verwendet, müssen Sie eine Zwischenaktualisierung zu Exchange Server 2003 durchführen, bevor Sie mit Exchange 2007 fortfahren.

Es gibt einige wichtige Änderungen in Exchange 2007, die Sie bei der Planung Ihres Übergangs bedenken müssen. Beispielsweise führt Exchange 2007 rollenbasierte Bereitstellung ein, mit der Sie die bereitzustellenden Messagingdienste auswählen und die für diese Dienste spezifischen Serverrollen bereitstellen können. Sie können die Serverrollen einzeln auf dedizierter Hardware bereitstellen oder mehrere Rollen auf demselben physischen Server installieren, die als separate Entitäten verwaltet werden. Eine Erklärung jeder Rolle finden Sie in der Randleiste „Exchange 2007-Serverrollen“.

Exchange Server 2007-Serverrollen

Postfachserver Die Postfachserverrolle bietet einen Nachrichtenspeicher für eine Organisation. Exchange 2007 kann bis zu 50 Speicher pro Server unterstützen. Diese Speicher können als 50 einzelne Speichergruppen bereitgestellt werden, oder Sie können bis zu 50 Speicher in einer einzelnen Speichergruppe erstellen. Die Postfachserverrolle ist die einzige Rolle, die als Cluster bereitgestellt werden kann. Wenn Sie also Clustering verwenden, müssen Sie den Postfachserver auf dedizierter Hardware installieren.

Clientzugriffsserver Die Clientzugriffs-Serverrolle ersetzt die Funktionalität, die von einem Front-End-Server bereitgestellt wird. Sie bietet Postfachzugriff auf Clients, die auf Exchange mithilfe von POP3, IMAP4, Outlook® Web Access (OWA), RPC-über-HTTPS (jetzt bekannt als Outlook Anywhere) und Exchange ActiveSync® zugreifen.

Hubtransportserver Diese Rolle stellt SMTP- und MAPI-Nachrichtentransportdienste für die Exchange-Organisation zur Verfügung. Jede Nachricht, die von den Benutzern in Ihrer Organisation gesendet oder empfangen wird, wird von einem Hubtransportserver verarbeitet. Dies ist sehr nützlich, da dadurch sichergestellt wird, dass keine Nachricht die serverbasierten Regeln oder Journalrichtlinien umgehen kann, die von Agents bereitgestellt werden, die an verschiedenen Stellen in der Transportpipeline aktiv sind.

Unified Messaging-Server Diese Rolle stellt Sprachzugriff auf Ihr Postfach bereit. Sie ist in Ihr IP/VoIP-Gateway oder IP-PBX integriert, um Telefonzugriff auf Nachrichten und Kalenderelemente bereitzustellen und Ihnen die Möglichkeit zu geben, eine Antwort zu transkribieren. Diese Rolle ist neu in Exchange und kann nicht mit einer der früheren Versionen von Exchange verwendet werden.

Edgetransportserver Der Edgetransportserver wird normalerweise in Ihrem Umkreisnetzwerk bereitgestellt. Er stellt SMTP-Nachrichtentransport zwischen der Exchange-Organisation und dem Internet bereit und bietet Antispam- und Antivirusverarbeitung mithilfe von Transportagents. Sie können jetzt eine einzelne Technologie als Standard sowohl für Organisations- als auch Umkreisnetzwerkserver einrichten. Dieses nahtlose Interaktionsmodell vereinfacht die Verwaltung und ermöglicht eine einfache Integration von Umkreisservern.

Untersuchen Sie Ihre Topologie

Womit fangen Sie an? Nun, es ist schwierig, Ihr Ziel zu bestimmen, wenn Sie Ihre momentane Situation nicht genau kennen. Nehmen Sie sich Zeit, Ihre aktuelle Umgebung einzuschätzen und die Topologie zu dokumentieren – nicht nur Exchange, sondern auch die Active Directory®-Umgebung. Es wird Sie wahrscheinlich freuen zu erfahren, dass Exchange 2007 jetzt kein Verbindungsstatusrouting und keine Topologie basierend auf Routinggruppen und Connectors mehr beinhaltet. Stattdessen nutzt Exchange 2007 den Vorteil der Investition aus, die Ihre Organisation bereits in das Entwerfen der Active Directory-Topologie gesteckt hat. Daraus resultierend werden alle Exchange-Empfänger und Konfigurationsdaten in Active Directory gespeichert, die Routingtopologie wird aus der Active Directory-Standortkonfiguration abgeleitet, und alle Serverrollen verwenden Standortinformationen, um die Dienste, die auf den Serverrollen ausgeführt werden, zu erkennen.

Stellen Sie sicher, dass die aktuelle Active Directory-Standorttopologie das zugrunde liegende physische Netzwerk wirklich nutzt und dass alle Active Directory-Standorte über verknüpfte Subnetze verfügen, und dokumentieren Sie daraufhin die vorhandenen Active Directory-Standorte und IP-Standortverknüpfungen. Dokumentieren Sie außerdem, wo sich Ihre Exchange 2003-Server physisch befinden, sowie die Routinggruppe und Routinggruppenconnector-Struktur.

Dies ist der schwierigste Teil des Übergangsprozesses: das Verschieben aus einer Exchange-Routinginfrastruktur basierend auf Routinggruppen in eine Routinginfrastruktur basierend auf Active Directory-Standorten. Für eine kleine Organisation ist dies normalerweise ein einfacher Prozess. Eine große Organisation mit zahlreichen Routinggruppen muss eine Übergangsphase jedoch vorsichtig planen, wenn Exchange 2003 und Exchange 2007 koexistieren. Vermeiden Sie das Senden einer Nachricht an Ihr Exchange 2003-Postfach vom Exchange 2007-Benutzer von gegenüber, die durch eine Remoteroutinggruppe über eine Verbindung mit niedriger Bandbreite geroutet wird.

Gehen Sie von folgenden Annahmen für Ihre aktuelle Topologie aus:

• Die Exchange 2003-Organisation wird im einheitlichen Modus ausgeführt.
• Sie verfügen über mehr als eine Routinggruppe.
• Sie verfügen über mehr als einen Active Directory-Standort.

Abbildung 1 zeigt eine Exchange- und Active Directory-Topologie. Denken Sie daran, je mehr Details Sie in Ihren vorläufigen Plänen berücksichtigen, desto besser wird Ihr Design.

Abbildung 1** Eine Exchange- und Active Directory-Topologie **(Klicken Sie zum Vergrößern auf das Bild)

So verwendet Exchange 2007 Active Directory

Wenn ein Exchange 2007-Server startet, wird er mit einem Standortattribut gekennzeichnet, das anderen Exchange 2007-Servern beim Finden der von diesem Server zur Verfügung gestellten Dienste hilft. Nur der Hubtransportserver kann SMTP für den Transport einer Nachricht innerhalb der Organisation verwenden. Jeder Active Directory-Standort, der einen Postfachserver enthält, muss auch einen Hubtransportserver enthalten, und wenn die Postfachbenutzer auf ihr Postfach mithilfe einer Nicht-MAPI-Methode zugreifen, muss jeder Standort außerdem einen Clientzugriffsserver enthalten. Jedes Mal, wenn eine Nachricht für die Zustellung verarbeitet werden muss, läuft sie durch einen Hubtransportserver, der eine Entscheidung trifft, wie die Nachricht geroutet werden soll. Wenn die Nachricht für einen Postfachserver bestimmt ist, der sich am selben Active Directory-Standort wie der Hubtransportserver befindet, sendet der Hubtransportserver die Nachricht an das Postfach. Wenn die Nachricht für einen Postfachserver bestimmt ist, der sich an einem anderen Standort befindet, leitet der Hubtransportserver die Nachricht direkt an einen Hubtransportserver an einem Remotestandort weiter.

Der Hubtransportserver verwendet die Kosteninformationen der Active Directory-IP-Standortverknüpfung zur Berechnung der kostengünstigsten Route zum Active Directory-Standort, an dem sich das Postfach des Empfängers befindet. Der Routenauswahlalgorithmus ist dem von Exchange 2003 sehr ähnlich, aber er basiert auf Standortverknüpfungskosten anstelle von Routinggruppenconnector-Kosten. Außerdem wird die Nachricht nicht an jedem Hubtransportserver angehalten. Sie gelangt direkt von der Quelle zum Ziel. Weshalb macht er sich also die Mühe, die kostengünstigste Route zu berechnen, wenn er sich auf das IP-Netzwerk für das Senden der Nachricht verlässt? Dafür gibt es einige Gründe. Einer ist die Verzögerung von Nachrichtengabelung. Eine Nachricht, die an mehr als einen Empfänger gesendet wird, muss möglicherweise an Postfachserver an mehr als einem Active Directory-Standort gesendet werden. Anstatt die Nachricht am ersten Hubtransportserver zu gabeln oder zu teilen, teilt Exchange 2007 die Nachricht nicht, bis sie eine Gabelung im Routingpfad erreicht. Dies hat zur Folge, dass die Nachricht direkt an einen Hubtransportserver am Active Directory-Standort weitergeleitet wird, der den Gabelungspunkt darstellt. Dieses Verhalten wird auch als verzögerter Ausgangsfächer beschrieben.

Die kostengünstigste Route wird außerdem verwendet, um zu bestimmen, wo die Nachricht in die Warteschlange gestellt werden soll, für den Fall, dass das Ziel nicht erreicht werden kann. Wenn ein Hubtransportserver am Active Directory-Zielstandort nicht erreicht werden kann, versucht der sendende Hubtransportserver daraufhin, die Sendung an einen Hubtransportserver am nächstgelegenen Active Directory-Standort gemäß dem Routingpfad zu übermitteln. Die Nachrichtenübermittlung geschieht weiterhin entlang der kostengünstigsten Route, bis sie einen Active Directory-Standort erreicht, an dem ein Hubtransportserver verfügbar ist. Wenn schließlich keine Hubtransportserver entlang der Route zum empfangenden Active Directory-Standort verfügbar sind, wird die Nachricht lokal in die Warteschlange gestellt. Mit dieser Methode wird die Nachricht so nahe wie möglich am Lieferpunkt in die Warteschlange gestellt, was die Diagnose von Netzwerkfehlern deterministischer macht. Dieses Verhalten wird „Queue-at-point-of-failure“ (Warteschlange an Fehlerpunkt) genannt.

Exchange 2003 funktioniert auf eine komplett andere Weise. Es berechnet die kostengünstigste Route von einer Routinggruppe zu einer anderen basierend auf den Kosten, die den Routinggruppenconnectors zugewiesen sind. Ein Bridgeheadserver in jeder Routinggruppe entlang des Routingpfads empfängt die Nachricht und leitet sie weiter. Wenn der nächste Connector im Pfad nicht verfügbar ist, wird ein Versuch unternommen, eine alternative Route zu berechnen. Verbindungsstatus-Aktualisierungsnachrichten werden auch über die Exchange-Organisation übermittelt, um die anderen Exchange-Server darüber zu unterrichten, dass die Verbindung unterbrochen ist. Die Bridgeheadserver versuchen, um den nicht funktionierenden Connector herum zu routen, bis eine Verbindungsstatusbenachrichtigung empfangen wurde, die angibt, dass die Verbindung wieder funktioniert.

Die Herausforderung beim Übergangsprozess in einer großen Organisation besteht darin, den E-Mail-Verkehr während des Koexistenzzeitraums zu verwalten. Um diese Kontinuität zu erreichen, wenn Exchange 2007 in die Umgebung eingeführt wird, werden alle Exchange 2007-Server zu Mitgliedern einer einzelnen Routinggruppe. Das bedeutet, dass unabhängig davon, an welchem Active Directory-Standort sich der Exchange 2007-Server befindet, Exchange 2003 ihn als zu dieser einzelnen Routinggruppe gehörig betrachtet. Dies ermöglicht Ihnen, einen Routinggruppenconnector zwischen dieser Routinggruppe und den Exchange 2003-Routinggruppen einzurichten, sodass Exchange 2003 entscheiden kann, wie Nachrichten an Exchange 2007 geroutet werden. Exchange 2007 verwendet den Routinggruppenconnector außerdem zur Bestimmung, wie Nachrichten an Exchange 2003 gesendet werden. Exchange 2007 wird es jedoch immer vorziehen, eine Nachricht über einen anderen Exchange 2007-Server zu routen, und wird nie über eine Exchange 2003-Routinggruppe zu einem anderen Exchange 2007-Server weiterleiten.

Einführung des ersten Exchange 2007-Servers

Wenn Sie den ersten Exchange 2007-Server in der Exchange 2003-Organisation installieren, müssen Sie einen Exchange 2003-Bridgeheadserver auswählen, mit dem der erste Routinggruppenconnector eingerichtet wird.

Abbildung 2 zeigt, wie die Einführung des ersten Exchange 2007-Servers sich auf die Organisationstopologie auswirkt.

Abbildung 2** Installation des ersten Exchange 2007-Servers **(Klicken Sie zum Vergrößern auf das Bild)

So weit so gut. Beachten Sie, dass die Standardkosten des von Exchange 2007 erstellten Routinggruppenconnectors nur 1 betragen. E-Mails werden wie üblich durch die Exchange 2003-Server geleitet, und wenn eine Nachricht an einen Benutzer auf dem Exchange 2007-Server von einem beliebigen Exchange 2003-Server gesendet wird, wird sie durch die Acapulco-Routinggruppe geleitet. Als der Routinggruppenconnector erstellt wurde, wurde der von Ihnen ausgewählte Exchange 2003-Bridgeheadserver automatisch zu einem Mitglied der ExchangeLegacyInterop-Universalsicherheitsgruppe und erhielt die korrekten Berechtigungen zum Senden und Empfangen von E-Mail-Nachrichten an und von Exchange 2007. Verwenden Sie immer den New-RoutingGroupConnector in der Exchange-Verwaltungsshell zur Erstellung eines Routinggruppenconnectors, wenn ein Exchange 2007-Server als Quellen- oder Zielserver für den Connector angegeben wird. Sie können auch das Cmdlet „Set-RoutingGroupConnector“ verwenden, um die Konfiguration eines Routinggruppenconnectors zu ändern. Sie möchten z. B. Quellen- und Zielserver zum ursprünglichen Routinggruppenconnector hinzufügen, um Redundanz bereitzustellen. (Weitere Informationen finden Sie im Artikel von David Strome über die Exchange-Verwaltungsshell in dieser Ausgabe des TechNet Magazins.)

Vorbereitung zum Verschieben einiger Postfächer

Der nächste Schritt besteht im Verschieben einiger Postfächer von den Exchange 2003-Servern zu den Exchange 2007-Servern. Verwenden Sie das cmdlet „Move-Mailbox (Postfach verschieben)“, um dies durchzuführen. Bevor Sie die Exchange 2003-Server jedoch außer Betrieb nehmen können, erstellen Sie Connectors zum Senden und Empfangen auf dem Exchange 2007-Server, um alle SMTP-Connectors zu ersetzen, die auf dem Exchange 2003-Server zur Verarbeitung des Routing an externe SMTP-Adressräume definiert waren.

Im nächsten Diagramm wurden die Ressourcen der Acapulco-Routinggruppe zu Exchange 2007 verschoben. Die Acapulco-Routinggruppe kann außer Betrieb genommen werden. Dies bedeutet jedoch, dass Sie nun einen Routinggruppenconnector zu einer anderen Routinggruppe einrichten müssen. In Abbildung 3 wurde der Routinggruppenconnector für einen Bridgeheadserver in der Miami Norden-Routinggruppe konfiguriert.

Abbildung 3** Konfigurieren des Routinggruppenconnectors **(Klicken Sie zum Vergrößern auf das Bild)

Fahren Sie fort mit der Übertragung der LA Osten-Routinggruppe zu Exchange 2007. Dies ist eine Situation, in der die Verwaltung des Routing etwas komplizierter wird. In Abbildung 4 wurde Exchange 2007 am Standort Los Angeles installiert, und eine zweite Routinggruppe wurde außer Betrieb genommen. Es wurden jedoch keine zusätzlichen Routinggruppenconnectors erstellt.

Abbildung 4** Installiertes Exchange 2007 am Standort Los Angeles **(Klicken Sie zum Vergrößern auf das Bild)

Wenn jetzt eine Nachricht vom Exchange 2007-Server am Standort Lost Angeles an den Exchange 2003-Server in der LA Westen-Routinggruppe gesendet wird, wird sie zunächst nach Acapulco weitergeleitet, dann nach Miami Norden, Miami Süden und schließlich nach LA Westen. Wenn eine Nachricht vom Exchange 2003-Server in der LA Westen-Routinggruppe an den Exchange 2007Server am Standort Los Angeles gesendet wird, wird sie zunächst nach Miami Süden, dann nach Miami Norden, Acapulco und schließlich zurück nach Los Angeles weitergeleitet. Autsch.

Um dies zu vermeiden, müssen Sie einen zweiten Routinggruppenconnector hinzufügen. Abbildung 5 zeigt das Hinzufügen eines Routinggruppenconnectors von LA Westen zum Exchange 2007-Server am Standort Los Angeles. Hinweis: Wenn Sie eine Unmenge an Routinggruppenconnectors vermeiden möchten, stellen Sie sicher, dass Ihr erster Routinggruppenconnector in einem gut verbundenen Active Directory-Hubstandort konfiguriert ist.

Abbildung 5** Effizienteres Routing **(Klicken Sie zum Vergrößern auf das Bild)

Dies führt zu einem Problem, das möglicherweise nicht sofort erkennbar ist. Es gibt jetzt mehr als einen Eingang und einen Ausgang für die Exchange 2007-Routinggruppe. Da die Exchange 2007-Routinggruppe keinen Verbindungsstatus verwendet, ist nun eine potenzielle Routingschleife vorhanden. Der Exchange 2003-Server kann eine alternative Route um einen nicht funktionierenden Connector herum auswählen, während Exchange 2007 immer die kostengünstigste Route auswählt. Eine Umgehung dieses Problems liegt in der Unterdrückung geringer Verbindungsstatus-Aktualisierungsnachrichten, die Verbindungsstatusnachrichten verhindern, die einen nicht funktionierenden Connectorstatus melden, verhindern jedoch nicht Verbindungsstatusnachrichten, die Konfigurationsänderungen mitteilen. Dies ist wichtig, da die Exchange 2003-Server über die neuen Routinggruppenconnectors informiert sein sollen, jedoch nicht versuchen sollen, eine alternative Route zu berechnen. Das Endergebnis ist, dass die Exchange 2003-Server das gleiche „Queue-at-point-of-failure“ wie die Exchange 2007-Server zeigen werden.

In Abbildung 6 wurden weitere Exchange 2003-Ressourcen in Exchange 2007 überführt. Verbindungsstatusaktualisierungen wurden unterdrückt, und es wurde darauf geachtet, Routinggruppenconnectors einzurichten, die einen logischen Routingpfad beibehalten.

Abbildung 6** Mehr Exchange 2003-Ressourcen wechseln zu Exchange 2007 **(Klicken Sie zum Vergrößern auf das Bild)

Es besteht allerdings ein anderes Problem. Es wurden Verbindungsstatusinseln in Redmond und Vancouver erstellt. Die E-Mail wird problemlos weitergeleitet, wenn auch über Miami. Es besteht jedoch keine Möglichkeit für Redmond und Miami, Verbindungsstatus-Konfigurationsänderungen mitzuteilen. Um eine aktuelle Routingtabelle beizubehalten, müssen Sie einen anderen Routinggruppenconnector zwischen Redmond und Vancouver konfigurieren. Sie können die Kosten dieses Routinggruppenconnectors anpassen, sodass diese hoch genug sind, um Exchange 2003 an einem Routing über diese Verbindung zu hindern, während Verbindungsstatus-Konfigurationsänderungen weiterhin gemeldet werden können.

Mit vorsichtiger Planung können Sie die Probleme umgehen, die durch die Beibehaltung zweier separater Exchange-Routingtopologien entstehen können. Die besten Ergebnisse erzielen Sie, wenn Sie den Übergang für jede Routinggruppe einzeln vornehmen und jeweils dann mit der nächsten fortfahren, bis Sie ausschließlich Exchange 2007-Server ausführen.

Bis jetzt wurde auf die Routingänderungen in Exchange 2007 eingegangen, und darauf, wie sich diese auf Ihren Übergang auswirken. Es gibt noch ein paar weitere Überlegungen zu berücksichtigen, wenn Sie einen Wechsel zu Exchange 2007 planen.

Exchange 2003-Front-End-Server können nicht auf Exchange 2007-Postfächer zugreifen. Ein Exchange 2007-Clientzugriffsserver hat jedoch kein Problem, Sie mit Ihrem Exchange 2003-Postfach zu verbinden. Wenn Sie den Exchange 2007-Clientzugriffsserver verwenden, sehen Sie die gleiche OWA-Version wie der Postfachserver, auf dem Ihr Postfach gespeichert ist. Wenn Sie Exchange 2007 auf separater Hardware bereitstellen, sollte der Clientzugriffsserver die erste Rolle sein, die Sie an einem Active Directory-Standort einführen. Alle Exchange 2003-Front-End-Server, die öffentlichen Internetzugriff auf Postfächer bereitstellen, sollten durch Exchange 2007-Clientzugriffsserver ersetzt werden, bevor Postfächer zu Exchange 2007 verschoben werden.

Es wurde zuvor erwähnt, dass jeder Standort, der die Postfachserverrolle enthält, auch die Clientzugriffs-Serverrolle (wenn Sie über Nicht-MAPI-Clients verfügen – und wer kommt heutzutage schon ohne OWA aus?) und einen Hubtransportserver benötigt. Wenn Ihre Serverrollen also Hardware gemeinsam nutzen, achten Sie darauf, den Clientzugriffsserver in die Rollenauswahl einzuschließen. Zu einer typischen Installation gehören die Hubtransport-Serverrolle, die Clientzugriffs-Serverrolle und die Postfach-Serverrolle. Dies reicht für eine vollständig funktionierende Exchange-Umgebung aus.

Eine andere Überlegung für den Übergangsprozess ist der Zeitpunkt der Aktualisierung Ihrer Clientanwendung (Outlook). Es wird Ihnen nicht möglich sein, die Vorteile aller Exchange 2007-Serverfeatures vollständig zu nutzen, bis Ihre Clients auf Outlook 2007 aktualisiert wurden. Dazu gehören verbesserte Abwesenheitsnachrichten-Einstellungen und verwaltete Postfachordner-Features.

Sie werden auch entscheiden müssen, wann die Edgetransport-Serverrolle bereitgestellt werden soll. Genau genommen können Sie Ihr aktuelles Umkreisnetzwerk-SMTP-Relay und Ihren Smarthost mit dem Edgetransportserver ersetzen, bevor oder nachdem Sie beliebige sonstige Exchange 2007-Serverrollen eingeführt haben. Wenn Sie zunächst allerdings den Edgetransportserver bereitstellen, ist die Gesamtfunktionalität eingeschränkt, da Exchange 2003 keine Möglichkeit hat, die Empfänger- und Konfigurationsdaten zu replizieren, die der Edgetransportserver von Active Directory zum Active Directory-Anwendungsmodus (ADAM) benötigt.

Nachdem Sie mindestens einen Hubtransportserver installiert haben, können Sie den Edgetransportserver im Umkreisnetzwerk bereitstellen und den Edgetransportserver daraufhin dem Active Directory-Standort zuordnen, an dem sich der Hubtransportserver befindet. Der EdgeSync-Dienst auf dem Hubtransportserver repliziert eine Teilmenge der Empfängerdaten in Active Directory zu ADAM.

Mit diesen Daten kann der Edgetransportserver eine Empfängersuche und eine Sicherheitslistenzusammenfassung durchführen, sodass Sie die Vorteile der auf dem Edgetransportserver ausgeführten Spamschutzagents vollständig nutzen können. Zusätzlich dazu erstellt EdgeSync die Sendeconnectors, die für einen End-to-End-E-Mail-Verkehr an und von der Exchange-Organisation und dem Internet benötigt werden. Dies kann den Vorgang des Ersetzens der Exchange 2003-SMTP-Connectors vereinfachen, die Routing an externe Adressräume bereitstellen.

Nehmen Sie sich deshalb etwas Zeit, Ihren Übergang zu Exchange 2007 zu planen, und der Prozess wird einfach und frei von Problemen sein.

Kate Follis ist Senior Content Publisher des Exchange 2007-Teams technischer Redakteure. Ihre Gruppe ist spezialisiert auf Edgetransport- und Hubtransport-Serverrollen. Bevor sie zu Microsoft kam, war Kate Follis mehrere Jahre lang Microsoft-zertifizierte Trainerin für Exchange und Active Directory.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.