Freigeben über


Upgrade des Exchange 2003-Transports

 

Gilt für: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Letztes Änderungsdatum des Themas: 2016-11-28

Beim Aktualisieren von Microsoft Exchange Server 2003 auf Exchange Server 2010 gibt es eine Phase, in der beide Versionen gleichzeitig in der Produktionsumgebung vorhanden sind. Anhand der Informationen in der folgenden Tabelle können Sie sicherstellen, dass der Meldungsfluss in dieser Zeit der Koexistenz nicht negativ beeinflusst wird. 

Wichtig

Wenn Exchange 2010 als neue Organisation bereitgestellt wird, kann Exchange 2003 nicht später in der Exchange 2010-Organisation installiert werden. Dieses Szenario wird nicht unterstützt. Wenn Sie erwarten, dass in Zukunft Exchange 2003-Funktionen in der Organisation erforderlich sind, müssen Sie zuerst eine Exchange 2003-Organisation installieren und mindestens einen Exchange 2003-Server beibehalten.

Zusammenfassung nach Funktion der erforderlichen und optionalen Aktionen für das Upgrade von Exchange 2003 Transport auf Exchange 2010

Funktion Erforderliche Aktionen für Koexistenz Optionale Aktionen und bewährte Methoden

Unterschiede in der Routingtopologie   Wenn Sie eine Koexistenz von Exchange 2010 und Exchange 2003 planen, müssen Sie die Unterschiede in der Ermittlung der Routingtopologie in den beiden Versionen verstehen. Dieser Abschnitt gibt Ihnen einen Überblick über die Unterschiede zwischen den Topologien und enthält Erläuterungen zu den folgenden Themen:

  • Routinggruppenconnectors

  • Verbindungsstatusupdates in einer Koexistenzumgebung

  • Geben Sie einen Exchange 2003-Bridgeheadserver für den ersten Routinggruppenconnector an, der während des Setups von Exchange 2010 erstellt wird.

  • Jede Exchange 2003-Routinggruppe muss über mindestens einen Connector zu einer anderen Routinggruppe verfügen, bevor der erste Exchange 2010-Server eingeführt wird.

  • Unterdrücken Sie kleine Verbindungsstatusupdates auf allen Servern in der Exchange 2003-Organisation.

  • Stellen Sie sicher, dass die Exchange 2010-Routinggruppe nicht der einzige Kommunikationspfad zwischen Exchange 2003-Routinggruppen ist, damit große Verbindungsstatusupdates weiterhin ausgeführt werden können.

  • Geben Sie mindestens zwei Quellserver und mindestens zwei Zielserver für die Routinggruppenconnectors zwischen der Exchange 2010-Routinggruppe und Exchange 2003-Routinggruppen an, um Redundanz und Serververfügbarkeit bereitzustellen.

  • Erstellen Sie bei Bedarf zusätzliche Routinggruppenconnectors zwischen Exchange 2003 und Exchange 2010, um die Nachrichtenübermittlung zu optimieren.

Sende- und Empfangsconnectors   Exchange 2003 verwendet zum Senden und Empfangen von Nachrichten zwischen Exchange-Servern virtuelle SMTP-Serverschnittstellen für jedes Protokoll. Die Exchange 2010-Hub-Transport-Server verwenden einen impliziten organisationsinternen Sendeconnector zum Routen von Nachrichten zwischen Standorten.

  • Keine. Die Standardkonfiguration von Sende- und Empfangsconnectors unter Exchange 2010 unterstützt die Koexistenz mit Exchange 2003.

  • Erstellen Sie explizite Sende- und Empfangsconnectors, wenn ein Connector erstellt werden soll, der Nachrichten an einen bestimmten Adressraum sendet oder von einem bestimmten Adressraum empfängt.

X-EXCH50-Daten   Exchange 2003 verwendet das proprietäre Verb X-EXCH50, um Informationen zu Nachrichten und Empfängern zu übermitteln, die nicht in die E-Mail-Nachricht aufgenommen werden können. Exchange 2010 unterstützt eine Zuordnung zwischen MAPI und MIME, und es ist nicht erforderlich, dass Exch50-Daten Nachrichteneigenschaften zuverlässig übertragen.

  • Keine. Die Routinggruppenconnectors unterstützen die Weitergabe von EXCH50-Daten.

  • Wenn Sie von Exchange 2010 aus eine Verbindung mit einem Exchange 2003-Server in einem gesamtstrukturübergreifenden Szenario herstellen, müssen Sie sicherstellen, dass die Connectorberechtigungen die Weiterleitung von EXCH50-Daten zulassen.

Nachrichtenverfolgung   Ein wichtiger Unterschied zwischen den Versionen besteht darin, dass Ereignisse, die vom Exchange 2010-Protokoll der Nachrichtenverfolgung erfasst werden, nicht direkt den Nachrichtenverfolgungsereignissen entsprechen, die von Exchange 2003 protokolliert werden.

  • Keine.

  • Verwenden Sie das Exchange 2003-Tool für die Nachrichtenverfolgung, um nach Nachrichten zu suchen, die in die Exchange 2003-Organisation übertragen bzw. von dieser empfangen werden.

Koexistenz von Edge-Transport-Servern   Wenn ein Edge-Transport-Server bereitgestellt wird, um eine Exchange-Organisation zu unterstützen, die in Exchange 2010 noch nicht bereitgestellt ist, ist nur ein eingeschränkter Funktionsumfang verfügbar.

  • Erstellen Sie spezielle Sende- und Empfangsconnectors auf dem Edge-Transport-Server, und aktualisieren Sie die Konfiguration der Exchange 2003-Bridgeheadserver, wenn Sie einen Edge-Transport-Server bereitstellen, bevor Exchange 2010 in die Exchange 2003-Organisation eingeführt wird.

  • Stellen Sie Exchange 2010-Hub-Transport-Server in der Exchange 2003-Organisation bereit, und verwenden Sie dann EdgeSync.

Unterschiede in der Routingtopologie

Exchange 2003 verwendet Routinggruppen, um eine Exchange-spezifische Routingtopologie zu definieren. Normalerweise werden Routinggruppen verwendet, um eine Gruppe von Exchange-Servern anzugeben, die über stabile Verbindungen verfügen. Server in derselben Routinggruppe können ohne Verwendung von Connectors miteinander kommunizieren. Idealerweise basieren die Routinggruppen, die in der vorhandenen Umgebung definiert sind, auf IP-Subnetzen und bilden möglichst exakt die Active Directory-Standortkonfiguration nach.

Wenn mehr als eine Routinggruppe in einer Exchange 2003-Organisation definiert ist, müssen Sie manuell Routinggruppenconnectors erstellen, um die Nachrichtenübermittlung zwischen Exchange 2003-Servern, die sich in verschiedenen Routinggruppen befinden, zu ermöglichen. Der Routinggruppenconnector muss einen Quellserver und einen Zielserver als Connectorendpunkte angeben. Ein Routinggruppenconnector definiert eine unidirektionale Verbindung, weshalb ein bidirektionaler Connector erstellt werden muss, damit die Nachrichtenübermittlung in beide Richtungen ermöglicht wird. Die Quell- und Zielserver sind die Bridgeheadserver für die Routinggruppe. Die Bridgeheadserver leiten E-Mail im Auftrag anderer Server in ihrer Routinggruppe per Relay an andere Routinggruppen weiter und empfangen E-Mail von anderen Routinggruppen, um sie an andere Server in ihrer Routinggruppe zuzustellen.

In Exchange 2010 muss keine Exchange-spezifische Routingkonfiguration definiert werden. Exchange 2010 verwendet die vorhandene Active Directory-Standorttopologie, um die Routingtopologie zu definieren. Sie können jedoch immer noch Exchange-spezifische Konfigurationsänderungen an Active Directory-Standorten und IP-Standortlinkkosten vornehmen, um die Nachrichtenübermittlung zu steuern. E-Mail, die an Exchange-Server weitergeleitet wird, die sich an verschiedenen Standorten befinden, müssen von Hub-Transport-Servern per Relay weitergeleitet werden. Hub-Transport-Server verwenden den organisationsinternen Sendeconnector, um E-Mail an Hub-Transport-Server an Remotestandorten zu senden. Der organisationsinterne Sendeconnector ist ein impliziter Connector, der unter Verwendung von Active Directory-Standort- und IP-Standortlinkinformationen berechnet wird. Weitere Informationen darüber, wie Exchange 2010 mithilfe von Active Directory-Standorten Nachrichten weiterleitet, finden Sie unter Planen der Verwendung von Active Directory-Standorten für das E-Mail-Routing.

Routinggruppenconnectors

Zur Unterstützung der Koexistenz zwischen diesen beiden Routingtopologien werden alle Exchange 2010-Server automatisch einer einzelnen Routinggruppe hinzugefügt, wenn Exchange 2010 installiert wird. Die Exchange 2010-Routinggruppe wird im Exchange-System-Manager in Exchange 2003 als Exchange-Routinggruppe (DWBGZMFD01QNBJR) innerhalb der administrativen Exchange-Gruppe (FYDIBOHF23SPDLT) erkannt.

Während der Installation des ersten Exchange 2010-Hub-Transport-Servers in einer vorhandenen Exchange-Organisation müssen Sie einen Exchange 2003-Bridgeheadserver angeben, für den der erste Routinggruppenconnector eingerichtet werden soll. Es wird empfohlen, einen Bridgeheadserver auszuwählen, der sich in einer Hubroutinggruppe oder in einer Routinggruppe mit zahlreichen Postfächern befindet. Der Routinggruppenconnector verknüpft die Routinggruppe, die sich am Standort des Exchange 2003-Servers befindet, mit der Exchange 2010-Routinggruppe. Die Exchange 2010-Routinggruppe umfasst alle Exchange 2010-Server, unabhängig vom Active Directory-Standort, an dem sie sich befinden.

VorsichtAchtung:
Verschieben Sie keine Exchange 2010-Server aus der Exchange-Routinggruppe (DWBGZMFD01QNBJR), und benennen Sie die Exchange-Routinggruppe (DWBGZMFD01QNBJR) nicht mithilfe eines Low-Level-Verzeichnis-Editors um. Keine der beiden Aktionen wird unterstützt. Exchange 2010 muss diese Routinggruppe für die Kommunikation mit Exchange 2003 verwenden.

Der Hub-Transport-Server, den Sie installieren, sowie der Exchange 2003-Bridgeheadserver, den Sie auswählen, sind für zwei bidirektionale Routinggruppenconnectors als Quell- und Zielserver konfiguriert. Der ausgewählte Bridgeheadserver wird automatisch der universellen Sicherheitsgruppe "ExchangeLegacy Interop" als Mitglied hinzugefügt und erhält die Berechtigungen, die zum Senden und Empfangen von E-Mail an bzw. von Exchange 2010 erforderlich sind. Dieser Routinggruppenconnector bildet einen einzigen Verbindungspunkt zwischen Exchange 2003 und Exchange 2010.

Die Liste der Quell- und Zielserver kann mithilfe des Cmdlets Set-RoutingGroupConnector in der Exchange-Verwaltungsshell geändert werden. Es ist eine bewährte Methode, mehr als einen Quell- und Zielserver anzugeben, um Redundanz und Serververfügbarkeit bereitzustellen.

Wichtig

Das Platzieren von Exchange 2010- und Exchange 2003-Servern in derselben Routinggruppe wird nicht unterstützt.

Jede Exchange 2003-Routinggruppe muss über mindestens einen Connector zu einer anderen Routinggruppe verfügen, bevor der erste Exchange 2010-Server eingeführt wird. Für jede Microsoft Exchange-Nachrichtendatenbank (Message Database, MDB), die sich in einer Routinggruppe befindet, die über keinen Routinggruppenconnector-Pfad von der Exchange 2010-Routinggruppe verfügt, wird die Ereignis-ID 5006 protokolliert. Weitere Informationen über die Exchange 2003-Routingtopologie finden Sie im Transport- und Routing-Handbuch für Exchange-Server.

Wenn die vorhandene Exchange-Umgebung mehr als eine Routinggruppe enthält, möchten Sie möglicherweise zusätzliche Verbindungspunkte zwischen Exchange 2003 und Exchange 2010 erstellen, um die Nachrichtenübermittlung zu optimieren. Zum Erstellen zusätzlicher Verbindungspunkte führen Sie die folgenden Schritte aus:

  1. Legen Sie fest, wie die Organisation auf Exchange 2010 aktualisiert werden soll. Die Reihenfolge, in der die Routinggruppen außer Betrieb gesetzt werden, legt fest, welche Exchange 2003-Routinggruppen direkt mit Exchange 2010 eine Verbindung herstellen sollen.

  2. Ändern Sie die Registrierung, um kleine Verbindungsstatusupdates auf allen Exchange 2003-Servern zu unterdrücken. Diese Konfigurationsänderung verhindert, dass Connectorstatusnachrichten per Relay unter Verwendung von Verbindungsstatusupdates durch die Organisation geleitet werden. Sie verhindert jedoch nicht die Weiterleitung von Konfigurationsänderungsnachrichten per Relay. Weitere Informationen finden Sie unter Unterdrücken von Verbindungsstatusaktualisierungen.

  3. Verwenden Sie das Cmdlet New-RoutingGroupConnector in der Shell, um alle Routinggruppenconnectors zu erstellen, die Exchange 2010-Hub-Transport-Server als Quell- oder Zielserver angeben. Konfigurieren Sie einen Routinggruppenconnector von der Exchange-Routinggruppe (DWBGZMFD01QNBJR) zu jeder Exchange 2003-Routinggruppe, mit der Exchange 2010 direkt kommunizieren soll, und konfigurieren Sie die entsprechenden bidirektionalen Routinggruppenconnectors. Sie können den Parameter Bidirectional mit dem Cmdlet New-RoutingGroupConnector verwenden, um beide Connectors in einem einzigen Vorgang zu erstellen. Diese Connectors ermöglichen die Nachrichtenübermittlung zwischen Exchange 2003 und Exchange 2010. 

    Wichtig

    Wenn Sie das Cmdlet New-RoutingGroupConnector verwenden, werden die angegebenen Legacy-Exchange-Server automatisch der universellen Sicherheitsgruppe "ExchangeLegacyInterop" als Mitglieder hinzugefügt. Zudem erhalten sie automatisch die für einen Legacy-Exchange-Server erforderlichen Berechtigungen, um E-Mail an einen Exchange 2010-Hub-Transport-Server zu senden bzw. von diesem zu empfangen. Wenn Sie mithilfe des Exchange-System-Managers einen Routinggruppenconnector zwischen der Exchange 2010-Routinggruppe und einer beliebigen Exchange 2003-Routinggruppe erstellen, wird diese Gruppenmitgliedschaft nicht aktualisiert, weshalb der Connector nicht einwandfrei funktionieren wird. Verwenden Sie daher stets die Shell, um Routinggruppenconnectors zwischen Exchange 2010 und Exchange 2003 zu erstellen.

Weitere Informationen finden Sie unter Erstellen von zusätzlichen Routinggruppenconnectors von Exchange 2010 zu Exchange 2003.

Verbindungsstatusupdates in einer Koexistenzumgebung

Wenn Sie eine Verbindung zwischen der Exchange 2010-Routinggruppe und der Exchange 2003-Organisation herstellen, müssen Sie das Verhalten des Verbindungsstatusroutings berücksichtigen. Exchange 2003-Server pflegen eine Verbindungsstatus-Routingtabelle, die per Kommunikation mit dem Routinggruppenmaster aktualisiert wird. Jeder Connector, der zwischen Exchange 2003-Routinggruppen erstellt wurde, wird als Verbindung betrachtet. Unter Verwendung der Kosten, die diesen Verbindungen zugeordnet sind, ermitteln Exchange 2003-Server, wie eine Nachricht innerhalb der Organisation weitergeleitet werden soll. Wenn auf eine bestimmte Routinggruppe unter Verwendung der Route mit den geringsten Kosten nicht zugegriffen werden kann, wird die Verbindungsstatustabelle vom Routinggruppenmaster dahingehend aktualisiert, dass der Status dieser Verbindung als "nicht verfügbar" gekennzeichnet wird. Diese Daten werden an jede Routinggruppe in der Exchange-Organisation übermittelt. Sobald die Daten empfangen werden, wird die Verbindungsstatustabelle aktualisiert, und eine andere Route wird berechnet.

Verbindungsstatusrouting wird nicht von Exchange 2010-Hub-Transport-Server verwendet. Exchange 2010 kann Verbindungsstatusupdates nicht weitergeben, und Routen werden nicht erneut berechnet. Hub-Transport-Server versuchen immer, direkt mit anderen Hub-Transport-Servern zu kommunizieren. Wenn eine Verbindung mit einem Standort nicht verfügbar ist, werden von Exchange 2010 die IP-Standortlinkkosten verwendet, die Active Directory-Standorten zugeordnet sind, um den nächst liegenden Standort zu ermitteln, an dem die Nachricht in die Warteschlange gestellt werden soll. Dieses Verhalten wird auch als Warteschlangenbildung am Fehlerpunkt bezeichnet. Die am Fehlerpunkt generierte Nachrichtenwarteschlange wird in den Zustand "Wiederholen" versetzt.

Wenn mehrere Pfade zwischen der Exchange 2010-Routinggruppe und einer beliebigen Exchange 2003-Routinggruppe vorhanden sind, müssen kleine Verbindungsstatusupdates unterdrückt werden, damit sichergestellt ist, dass es bei der Neuberechnung einer Route zu keinen Nachrichtenschleifen kommt. Es wird empfohlen, kleine Verbindungsstatusupdates für jeden Server in der Exchange 2003-Organisation zu unterdrücken. Wenn Verbindungsstatusupdates unterdrückt werden, werden auch von Exchange 2003-Servern Warteschlangen am Fehlerpunkt gebildet, statt dass die Route erneut berechnet wird.

Konfigurationsänderungen, z. B. das Hinzufügen von Connectors, werden weiterhin zwischen Exchange 2003-Servern mithilfe des Verbindungsstatus übermittelt. Stellen Sie jedoch sicher, dass die Exchange 2010-Routinggruppe nicht der einzige Kommunikationspfad zwischen Exchange 2003-Routinggruppen ist, damit große Verbindungsstatusupdates weiterhin ausgeführt werden können. Weitere Informationen zum Unterdrücken von Verbindungsstatusupdates finden Sie unter Unterdrücken von Verbindungsstatusaktualisierungen.

Zurück zum Seitenanfang

Sende- und Empfangsconnectors

Exchange 2003 verwendet zum Senden und Empfangen von Nachrichten zwischen Exchange-Servern virtuelle SMTP-Serverschnittstellen für jedes Protokoll. Eine Konfiguration ist nur dann erforderlich, wenn die Standardwerte geändert oder für eine andere Organisation spezifische Connectors erstellt werden.

Die Exchange 2010-Hub-Transport-Server verwenden einen impliziten Connector zum Routen von Nachrichten zwischen Standorten. Dieser Connector wird als "organisationsinterner Sendeconnector" bezeichnet. Während der Installation werden auf jedem Hub-Transport-Server explizite Empfangsconnectors automatisch erstellt. Ein Empfangsconnector ist für den Empfang von SMTP-Datenverkehr aus allen Quellen konfiguriert. Er überwacht Port 25. Ein zweiter Empfangsconnector ist für den Empfang von SMTP-Datenverkehr von Nicht-MAPI-Clients konfiguriert. Dieser überwacht Port 587. Explizite Sende- und Empfangsconnectors werden auf Hub-Transport-Servern nur dann erstellt, wenn ein Connector erstellt werden soll, der Nachrichten an einen bestimmten Adressraum sendet oder von einem bestimmten Adressraum empfängt. Weitere Informationen zu Connectors in Exchange 2010 finden Sie unter Grundlegendes zu Sendeconnectors und Grundlegendes zu Empfangsconnectors.

Zurück zum Seitenanfang

X-EXCH50-Daten

Exchange 2003 verwendet das proprietäre Verb X-EXCH50, um Informationen über Nachrichten und Empfänger zu übermitteln, die nicht in die E-Mail-Nachricht aufgenommen werden können. Diese Informationen werden als Exch50-BLOB (Binary Large Object) übertragen. Exch50 enthält Daten wie die SCL-Bewertung (Spam Confidence Level), Adressumschreibungsinformationen und weitere MAPI-Eigenschaften, die über keine MIME-Entsprechung verfügen. Da es sich bei X-EXCH50 um ein proprietäres ESMTP-Verb (Extended Simple Mail Transfer Protocol) handelt, können Exch50-Daten von Servern, auf denen kein Exchange ausgeführt wird, nicht weitergegeben werden.

Exchange 2010 unterstützt eine Zuordnung zwischen MAPI und MIME, und es ist nicht erforderlich, dass Exch50-Daten Nachrichteneigenschaften zuverlässig übertragen. Damit eine ordnungsgemäße Koexistenz mit Exchange 2003 möglich ist, können Exchange 2010-Server die Exch50-Daten an Exchange 2003-Server weitergeben. Bei eingehenden SMTP-Verbindungen werden Exch50-bezogene Eigenschaften, die von Exchange 2010 verwendet werden, zu entsprechenden Exchange 2010-Eigenschaften heraufgestuft. Eigenschaften, die zwar nicht von Exchange 2010, jedoch von Exchange 2003 verwendet werden, bleiben erhalten. Bei ausgehenden SMTP-Verbindungen kann der Exchange 2010-Server die Exch50-Daten durch Heraufstufen der Exchange 2010-Eigenschaften und Anfügen an die erhaltenen Exchange 2003-Daten bilden.

Routinggruppenconnectors zwischen Exchange 2010 und Exchange 2003 werden automatisch für die Unterstützung des Sendens und Empfangens von Exch50-Daten konfiguriert. Wenn Sie von Exchange 2010 aus eine Verbindung mit einem Exchange 2003-Server in einem gesamtstrukturübergreifenden Szenario herstellen, müssen Sie sicherstellen, dass die Connectorberechtigungen die Weiterleitung von Exch50-Daten zulassen. Weitere Informationen finden Sie unter Konfigurieren gesamtstrukturübergreifender Connectors.

Zurück zum Seitenanfang

Nachrichtenverfolgung

Das Nachrichtenverfolgungsschema in Exchange 2010 unterscheidet sich wesentlich von dem Nachrichtenverfolgungsschema in Exchange 2003. Ereignisse, die vom Exchange 2010-Protokoll der Nachrichtenverfolgung erasst werden, entsprechen nicht direkt den Nachrichtenverfolgungsereignissen, die von Exchange 2003 protokolliert werden. Nachrichten, die von Exchange 2010 gesendet und empfangen werden, können nur von Exchange 2010-Servern verfolgt werden. In Exchange 2010 wird keine Microsoft Windows-Verwaltungsinstrumentation (Windows Management Instrumentation, WMI) unterstützt. Deshalb kann ein Exchange 2003-Server keine Nachrichtenverfolgungsprotokolle von einem Exchange 2010-Server abfragen. Wenn eine Nachrichtenverfolgungsabfrage in Exchange 2010 anzeigt, dass die Nachricht an einen Exchange 2003-Server übertragen wurde, müssen Sie das Exchange 2003-Tool für die Nachrichtenverfolgung verwenden, um die Suche nach der Nachricht fortzusetzen.

Zurück zum Seitenanfang

Koexistenz von Edge-Transport-Servern

Die Edge-Transport-Serverrolle ist darauf ausgelegt, verbesserten Antivirus- und Antispamschutz für die Exchange-Organisation bereitzustellen. Der Edge-Transport-Server wendet außerdem Richtlinien auf Nachrichten an, die sich im Transport zwischen Organisationen befinden. Diese Serverrolle wird im Umkreisnetzwerk und außerhalb der Active Directory-Gesamtstruktur bereitgestellt. Der Edge-Transport-Server kann als Smarthost- und SMTP-Relayserver für eine vorhandene Exchange 2003-Organisation bereitgestellt werden.

Sie können einer vorhandenen Exchange-Organisation einen Edge-Transport-Server hinzufügen, ohne die internen Exchange-Server zu aktualisieren oder Änderungen an der Organisation vorzunehmen. Da die Bereitstellung außerhalb von Active Directory erfolgt, müssen Sie keine Active Directory-Vorbereitungsschritte ausführen, wenn der Edge-Transport-Server installiert wird. Wenn Sie den intelligenten Nachrichtenfilter von Exchange (Intelligent Message Filter) für die Ausführung von Antispamaufgaben in Exchange 2003 verwenden, können Sie mithilfe des Edge-Transport-Servers eine zusätzliche Antispamschutzebene hinzufügen.

Wenn ein Edge-Transport-Server bereitgestellt wird, um eine Exchange-Organisation zu unterstützen, die in Exchange 2010 noch nicht bereitgestellt ist, ist nur ein eingeschränkter Funktionsumfang verfügbar. In diesem Szenario kann kein Edge-Abonnement erstellt werden. Deshalb können Sie die Funktionen für die Empfängersuche und Aggregation von Listen sicherer Adressen nicht verwenden. Weitere Informationen zum Verwenden der Edge-Transport-Serverrolle mit einer Exchange 2003-Organisation finden Sie unter Bereitstellen der Edge-Transport-Serverrolle in einer bestehenden Exchange Server 2003-Organisation vor dem Upgrade auf Exchange 2010.

Zurück zum Seitenanfang

 © 2010 Microsoft Corporation. Alle Rechte vorbehalten.