Informationen zur Interoperabilität zwischen Exchange Server 2003 und Exchange-fremden Messagingsystemen

Letztes Änderungsdatum des Themas: 2006-07-27

Microsoft bietet mehrere Komponenten zur Integration von Exchange 2003 in eine Exchange-fremde Messaginginfrastruktur sowie zur Migration von Benutzern zu Exchange 2003:

• SMTP-Connector und X.400-Connector   Für eine nahtlose Interoperabilität ist die Bereitstellung eines verlässlichen Nachrichtenübertragungspfades in beide Richtungen erforderlich. Alle modernen Messagingsysteme bieten Unterstützung für SMTP, so dass Sie einen SMTP-Connector zur Verbindung der Systeme einsetzen können. Wenn das alte Messagingsystem auf einem X.400-Connector basiert, kann dieser ebenfalls verwendet werden. Diese Messagingverbindungen können temporär sein (die Systeme müssen beispielsweise nur nebeneinander bestehen, wenn Benutzer vom alten System zu Exchange Server 2003 migriert werden). In anderen Fällen kann eine längerfristige Koexistenz erforderlich sein (für das Messagingsystem einer Abteilung, das nicht auf Exchange Server 2003 umgestellt wird, könnte beispielsweise eine permanente Verbindung erforderlich sein).
• Active Directory-Tools und APIs (Application Programming Interfaces)   Synchronisieren Sie den Active Directory®-Verzeichnisdienst und das Verzeichnis des alten Messagingsystems, um eine konsistente globale Adressliste für beide Messagingsysteme zu erstellen. Die automatische Verzeichnissynchronisierung wird jedoch weder von einem SMTP-Connector noch von einem X.400-Connector unterstützt. Wie unter Informationen zur Interoperabilität und Migration in Exchange Server 2003 erwähnt, können Sie die Active Directory-Tools, wie zum Beispiel Ldifde.exe und Csvde.exe verwenden, um eine manuelle Verzeichnissynchronisierung oder Massenexport- und Massenimportoperationen durchzuführen. Mit grundlegenden Microsoft Visual Basic® Scripting Edition (VBScript)-Programmierkenntnissen können Sie ebenfalls eine modernere, halbautomatische Verzeichnissynchronisierung basierend auf Active Directory Service Interfaces (ADSI) und Collaboration Data Objects for Exchange Management (CDOEXM) implementieren. Weitere Informationen zu ADSI und CDOEXM finden Sie im Exchange Software Development Kit (SDK) (https://go.microsoft.com/fwlink/?LinkId=25925).
• Exchange Server-Programmierschnittstellen für den Zugriff auf Frei/Gebucht-Informationen   Der plattformübergreifende Zugriff auf Frei/Gebucht-Informationen stellt eine hilfreiche Methode für das Planen von Besprechungen und Konferenzen über mehrere Messagingsysteme hinweg dar. Außer für Lotus Notes und Novell GroupWise ist ein Kalenderconnector für andere Exchange-fremde Messagingsysteme nicht verfügbar, Lotus Notes oder Novell GroupWise müssen über den jeweiligen Connector mit der Exchange 2003-Organisation verbunden sein. Obwohl Frei/Gebucht-Informationen zwischen Systemen nicht synchronisiert werden können, die über einen SMTP-Connector oder einen X.400-Connector miteinander verbunden sind, können Sie Outlook zur Veröffentlichung von Frei/Gebucht-Informationen an einem freigegebenen Speicherort veröffentlichen oder Collaboration Data Objects für Exchange (CDOEX) verwenden, um eine benutzerdefinierte Lösung zur Anzeige des Frei/Gebucht-Informationsstatus von Exchange 2003-Benutzern auf einer ASP.NET-Seite zu implementieren. Weitere Informationen zu CDOEX finden Sie im Exchange SDK (https://go.microsoft.com/fwlink/?LinkId=25925).
• Assistent für die Migration zu Exchange   Bei dem Assistenten für die Migration zu Exchange handelt es sich um ein Tool zur Migration von Benutzern von einem unterstützten Messagingsystem wie Microsoft Mail für PC-Netzwerke, Microsoft Mail für AppleTalk-Netzwerke oder Lotus cc:Mail zu Exchange 2003. Der Assistent für die Migration zu Exchange bietet ebenfalls Unterstützung für LDAP und IMAP4. Dieses Feature ist sehr hilfreich, wenn Sie eine Migration von HP OpenMail, Sun ONE (früher unter Netscape iPlanet bekannt), Openwave Email Mx, Alt-n MDaemon oder einem beliebigen E-Mail-System mit Unterstützung für LDAP und IMAP4 aus durchführen. Wie unter Informationen zur Interoperabilität und Migration in Exchange Server 2003 erläutert, unterstützt der Assistent für die Migration zu Exchange die Migration, indem vorhandene Verzeichnisinformationen, Postfächern und Nachrichten kopiert und in Exchange Server 2003 importiert werden.
• Eigenständige Quellenextraktionsprogramme   Der Assistent für die Migration zu Exchange bietet keine direkte Unterstützung für alte Messagingsysteme wie Dec All-in-One, Verimation MEMO oder IBM Professional Office System (PROFS) und OfficeVision/VM. Über Microsoft und andere Anbieter verfügbare eigenständige Quellenextraktionsprogramme können jedoch verwendet werden, um vorhandene Daten aus Postfächern im alten Messagingsystem in Migrationsdateien zu extrahieren und anschließend mit dem Assistenten zur Migration von Exchange in Exchange Server 2000 zu importieren. Wenden Sie sich an Ihren Microsoft Software Service, um ein eigenständiges Quellenextraktionsprogramm für Ihr altes Messagingsystem zu beziehen. Informationen zum Software Service sowie Kontaktinformationen finden Sie unter https://support.microsoft.com.

Übertragung und Konvertierung von Nachrichten

Exchange Server 2003 unterstützt zwei allgemeine Messagingstandards zum Herstellen einer Verbindung zu einem beliebigen Messagingsystem: SMTP und X.400. SMTP ist ein Standardprotokoll zur Nachrichtenübertragung von Exchange 2003. Die Verwendung von SMTP hat daher Vorrang vor X.400 Im Gegensatz zu einem X.400-Connector kann ein SMTP-Connector darüber hinaus leichter konfiguriert werden. Wenn in der alten Infrastruktur nicht zusätzliche Komponenten bereitgestellt werden, ist die Verwendung eines X.400-Connectors dennoch empfehlenswert, wenn Sie in einer Umgebung mit einem X.400-Backbone arbeiten oder SMTP nicht unterstützt wird.

SMTP-basierte Nachrichtenübertragung

Exchange Server 2003 ist vom Windows 2003 SMTP-Dienst abhängig, der mit Exchange-spezifischen Übertragungskomponenten und -modulen zur Kommunikation mit SMTP-Remotehosts erweitert wurde. Der SMTP-Dienst wird in Exchange 2003 durch virtuelle Server repräsentiert. Zur ordnungsgemäßen Nachrichtenübertragung müssen virtuelle SMTP-Server in der Lage sein, SMTP-Domänennamen in IP-Adressen aufzulösen. Dieses Verfahren wird normalerweise über DNS (Domain Name System)-Abfragen durchgeführt. Die SMTP-Hosts müssen in MX (Mail Exchanger)-Datensätzen registriert werden. Alle ausgehenden SMTP-Nachrichten können auch an einen einzelnen SMTP-Host zur weiteren Übermittlung übertragen werden. Dieser SMTP-Host wird als Smarthost bezeichnet. ISPs (Internet Service Providers, Internetdienstanbieter) stellen ihren Kunden häufig einen zentralen Smarthost für die Nachrichtenübertragung über das Internet bereit.

Die SMTP-Nachrichtenübertragung zu internen SMTP-Hosts ist über dedizierte SMTP-Connectors empfehlenswert, da die Konfiguration mit SMTP-Connectors im Vergleich zu virtuellen SMTP-Servern besser gesteuert werden kann. Connectoreinstellungen haben gegenüber Einstellungen für virtuelle Server eine höhere Priorität für Nachrichtenübermittlung. Sie können zum Beispiel einen SMTP-Connector zur Implementierung eines zentralen Messaging-Bridgeheadservers verwenden, der für die gesamte Nachrichtenübertragung zwischen dem alten Messagingsystem und der Exchange 2003-Organisation verantwortlich ist. In Abbildung 1 wird eine Umgebung mit einem einzelnen Bridgeheadserver dargestellt. Zur Fehlertoleranz und zum Lastenausgleich können Sie mehrere Bridgeheadserver in der SMTP-Connectorkonfiguration festlegen.

Bei der Konfiguration eines SMTP-Connectors können Sie angeben, ob Sie DNS- und MX-Datensätze für die Nachrichtenübermittlung verwenden oder alle Nachrichten an den Smarthost weiterleiten möchten. Der Einsatz eines Smarthosts ist bei der Übertragung von Nachrichten an einen anderen SMTP-Host im internen Netzwerk normalerweise die bessere Option, da interne Ziele häufig nicht als MX-Datensätze in DNS registriert sind. Zur Weiterleitung von Nachrichten für eine bestimmte SMTP-Domäne über einen SMTP-Connector müssen Sie den verantwortlichen Connector für die Domäne angeben. Legen Sie hierfür einen SMTP-Adressbereich in der Connectorkonfiguration fest, der dem SMTP-Domänennamen des Zielsystems entspricht. Adressbereich in Abbildung 1: SMTP: legacy.contoso.com. Da das Zielsystem durch einen SMTP-Domänennamen ermittelt wurde, können das alte Messagingsystem und die Exchange 2003-Organisation nicht denselben SMTP-Domänennamen verwenden. Weitere Informationen zum Umgang mit SMTP-Domänennamen in Migrationsszenarien finden Sie unter Informationen zur Interoperabilität und Migration in Exchange Server 2003.

Anmerkung:
Wenn eine Empfängeradresse keinem Connectoradressbereich entspricht, werden die Einstellungen des lokalen virtuellen SMTP-Servers für die Nachrichtenübermittlung verwendet. Wenn die Optionen für die Nachrichtenübermittlung des virtuellen SMTP-Hosts nicht geändert werden, sucht Exchange 2003 den SMTP-Remotehost standardmäßig unter Verwendung von DNS.

Nachrichtenübertragung von Exchange nach SMTP

In Abbildung 2 wird dargestellt, wie Nachrichten von Exchange 2003 an ein Exchange-fremdes Messagingsystem über einen SMTP-Connector gesendet werden.

Die Übertragung von Nachrichten von Exchange 2003 an ein Exchange-fremdes Messagingsystem über SMTP wird wie folgt ausgeführt:

1. Alle an lokale Benutzer oder Remotebenutzer gesendeten Nachrichten werden über das Exchange 2003-Transportmodul weitergeleitet. Die Warteschlange vor der Übermittlung ist der Eintrittspunkt in das erweiterte Warteschlangenmodul.

2. Das erweiterte Warteschlangenmodul überträgt die Nachricht aus der Warteschlange vor der Übermittlung in die Warteschlange vor der Kategorisierung, so dass das Kategorisierungsmodul die Nachricht verarbeiten kann. Das Kategorisierungsmodul überprüft die Einschränkungen, weist Sender- und Empfängerbeschränkungen zu und löst die Empfängerinformationen in Active Directory auf, um zu ermitteln, ob die Nachricht an einen lokalen Empfänger oder einen Remoteempfänger weitergeleitet werden soll. Das Kategorisierungsmodul platziert die Nachricht in einer Warteschlange nach der Kategorisierung, um sie an das erweiterte Warteschlangenmodul zurückzugeben.

   Anmerkung:
   Das Kategorisierungsmodul erweitert Verteilerlisten, löst Empfänger- und Sendernamen auf, gibt Homeserver an, legt fest, in welches Format Nachrichten konvertiert werden müssen, und verzweigt Nachrichten. Bei der Verzweigung werden mehrere Kopien einer Nachricht erstellt. Dies ist beispielsweise dann erforderlich, wenn Empfänger verschiedene Nachrichtenformate benötigen.

3. Das erweiterte Warteschlangenmodul überträgt Nachrichten für nicht lokale Empfänger aus der Warteschlange nach der Kategorisierung in die Warteschlange vor dem Routing und ruft das Routingmodul auf. Das Routingmodul speichert die Informationen zum nächsten Hop in der Verbindungsstatustabelle. Basierend auf der Zieladresse des Benutzers erkennt das Routingmodul, dass es sich beim Empfänger um einen Benutzer auf einem Exchange-fremden Messagingsystem handelt und verschiebt die Nachricht in die Verbindungswarteschlangen für den SMTP-Connector. Der Warteschlangen-Manager verwaltet die Verbindungswarteschlangen. Der Name der Warteschlange stimmt mit dem Remoteübermittlungsziel überein.

4. Der SMTP-Protokolldienst nimmt die Nachricht auf, ermittelt den Zielhost anhand der SMTP-Connectorkonfiguration oder über eine DNS-Abfrage basierend auf der SMTP-Domäne des Empfängers, stellt eine TCP/IP-Verbindung zum Zielhost an TCP-Anschluss 25 her und überträgt die Nachricht.

5. Der Zielhost liefert die Nachricht an das endgültige Ziel.

Nachrichtenübertragung von SMTP nach Exchange

Ein SMTP-Connector wird nur für ausgehende Exchange 2003-Nachrichten verwendet. SMTP-Connectors sind Konfigurationsobjekte mit Parametern, unter Verwendung derer festgelegt wird, wie der SMTP-Service Verbindungen herstellt und Nachrichten übermittelt. Von Exchange-fremden Messagingsystemen werden diese Objekte und Parameter nicht erkannt. SMTP-Remotehosts stellen lediglich eine TCP/IP-Verbindung zum SMTP-Dienst auf dem Exchange 2003-Server über TCP-Anschluss 25 her und übertragen ihre Nachrichten.

In Abbildung 3 wird das Empfangen von Nachrichten von einem SMTP-Host dargestellt.

Die Übertragung von Nachrichten von einem SMTP-Remotehost nach Exchange 2003 kann in vier Schritte unterteilt werden:

1. Der SMTP-Remotehost stellt eine TCP/IP-Verbindung zum Exchange 2003-Server an TCP-Anschluss 25 her und überträgt die Nachricht. Der lokale SMTP-Protokolldienst platziert die Nachricht in einer Warteschlange vor der Übermittlung des erweiterten Warteschlangenmoduls.
2. Das erweiterte Warteschlangenmodul überträgt die Nachricht aus der Warteschlange vor der Übermittlung in die Warteschlange vor der Kategorisierung, so dass das Kategorisierungsmodul die Nachricht verarbeiten kann. Das Kategorisierungsmodul überprüft die Einschränkungen, weist Sender- und Empfängerbeschränkungen zu und löst die Empfängerinformationen in Active Directory auf, um zu ermitteln, ob die Nachricht an einen lokalen Empfänger oder einen Remoteempfänger weitergeleitet werden soll. Das Kategorisierungsmodul platziert die Nachricht in einer Warteschlange nach der Kategorisierung, um sie an das erweiterte Warteschlangenmodul zurückzugeben.
3. Das erweiterte Warteschlangenmodul überträgt die Nachrichten für lokale Empfänger aus der Warteschlange nach der Kategorisierung in die lokale Warteschlangenübermittlung.
4. Der Exchange-Informationsspeichertreiber nimmt die Nachricht auf und platziert sie im Posteingang des lokalen Empfängers.

Exchange/SMTP-Nachrichtenkonvertierung

SMTP, wie der Name Simple Mail Transfer Protokoll bereits impliziert, legt keine komplexen Nachrichtentypen fest, wie zum Beispiel Anforderungen von Übermittlungs- oder Lesebestätigungen, Besprechungsanforderungen oder Aufgabenanforderungen. SMTP verarbeitet lediglich einen Nachrichtentyp: eine einfache Textnachricht. Eine SMTP-Nachricht besteht aus einer Abfolge von 7-Bit-ASCII-Zeichen. Der Nachrichtenheader, der unter anderem Sender-, Empfänger- und Betreffinformationen sowie Daten enthält, wird vom Nachrichtentext durch eine Nullzeile getrennt, eine Zeile, in der dem Wagenrücklauf und dem Zeilenvorschub keine Zeichen vorausgehen. Wie in Abbildung 4 dargestellt, ist das in RFC 822 definierte SMTP-Nachrichtenformat ist in der Tat sehr einfach.

Das SMTP-Standardnachrichtenformat kann nur für textbasierte E-Mail-Nachrichten verwendet werden. Zur Unterstützung von Anlagen müssen die ursprünglichen Dateien unter Verwendung von UUENCODE oder MIME (Multipurpose Internet Mail Extensions) verschlüsselt werden. Die Verwendung von UUENCODE oder MIME zum Verschlüsseln von Nachrichten richtet sich nach den Features, die vom empfangenden Messaginghost unterstützt werden.

UUENCODE ist ein Verschlüsselungsmechanismus zur Konvertierung von binären Daten in druckbare ASCII-Zeichen, so dass der Nachrichtenkörper Daten enthalten kann, ohne die SMTP-Konventionen zu verletzen. Die in Abbildung 4 enthaltene Nachricht beinhaltet die 7-Bit-Zeichenfolge einer angehängten, nicht verschlüsselten Datei.

MIME bietet eine weitere Möglichkeit zur Verschlüsselung von textfremden Informationen als Text. Bei dem in RFC 1341 und folgenden definierten MIME-Format handelt es sich um ein sehr flexibles Format. Es beschreibt eine Möglichkeit, mehrere Teile unterschiedlicher Inhaltstypen in einer E-Mail-Nachricht zu integrieren, Textnachrichten und textfremde Nachrichten. Teile einer Nachricht können aus Text, Bildern, Audio- oder Videodaten bzw. aus anderen anwendungsspezifischen Daten bestehen.

Anmerkung:
MIME verwendet den Base64-Verschlüsselungs-/Entschlüsselungsalgorithmus. Er ist flexibel und verlässlich, bläht die Datenmenge aber um durchschnittlich 33 Prozent auf. Dies bedeutet, dass ein SMTP-Connector 33 Prozent mehr Daten pro Nachricht übertragen muss.

Wenn Sie eine Exchange 2003-Organisation mit einem Exchange-fremden Messagingsystem über einen SMTP-Connector verbinden, muss der gesamte Nachrichteninhalt unter Verwendung von UUENCODE oder MIME verkapselt werden, um den Formatierungsverlust im RTF (Richt Text Format)-Format sowie den Verlust von erweiterten Zeichen zu vermeiden. Die verkapselte Nachricht kann als druckbare Zeichen in die Nachricht eingefügt werden.

Standardmäßig werden Nachrichten unter Verwendung von MIME verkapselt. Sie können jedoch das Nachrichtenformat für jede SMTP-Domäne im Exchange-System-Manager-Tool separat angeben. Zeigen Sie unter Globale Einstellungen die Eigenschaften für das Objekt Internet-Nachrichtenformate an, und wechseln Sie zur Registerkarte Nachrichtenformat. Neben anderen Aktivitäten können Sie den Nachrichtentext als HTML bereitstellen. Dies ist empfehlenswert, wenn der E-Mail-Client des Empfängers Nachrichten im HTML-Format unterstützt. Durch die Formatierung von Nachrichten in HTML werden die meisten Richt-Text-Features beibehalten, die beim Senden des Nachrichtentextes als unformatierten Text verloren gehen würden.

Anmerkung:

Einige Messagingadministratoren blockieren HTML-formatierte Nachrichten, da HTML-E-Mail Skripts mit infiziertem Code, wie zum Beispiel Wurmviren, enthalten kann. Fragen Sie den Remoteadministrator, ob Sie Nachrichten im HTML-Format übertragen können. Die Alternative zu HTML stellt die Nur Text- bzw. Nachrichtenverschlüsselung unter Verwendung von TNEF (Transport Neutral Encapsulation Format) dar. Beide Methoden werden weiter unten in diesem Abschnitt näher erläutert.

In Tabelle 1 wird dargestellt, welche Exchange-Richt-Text-Feature ordnungsgemäß in HTML konvertiert werden.

Tabelle 1   Konvertierung von E-Mail-Nachrichten zwischen RTF und HTML

Um den Verlust von Formatierungsinformationen bei der Konvertierung von RTF zu HTML zu vermeiden, können Outlook-Benutzer ihre Clients so konfigurieren, dass Nachrichten standardmäßig im HTML-Format verfasst werden. Wenn Benutzer Microsoft Word als E-Mail-Editor einsetzen, können sie das in Word verfügbare komplette HTML-Bearbeitungsset beim Verfassen von E-Mail-Nachrichten verwenden. So kann beispielsweise eine Nachricht im HTML-Format verfasst und eine Tabelle darin eingefügt werden. Die Tabelle wird bei der Nachrichtenübermittlung beibehalten, da es sich um eine ursprüngliche HTML-Struktur handelt. Eine Tabelle, die hingegen in eine Rich-Text-Nachricht eingefügt wird, geht bei der Konvertierung von RTF zu HTML verloren. Hierbei geht es nicht darum, ob eine in HTML formatiert Nachricht eine Tabelle enthalten kann (oder ein anderes spezifisches Rich-Text-Feature), sondern darum, ob die Konvertierung von RTF zu HTML dieses Rich-Text-Element unterstützt.

Eine weitere Option besteht darin, im TNEF-Format verkapselte RTF-Informationen zu Remoteempfängern zu senden. Dies ist empfehlenswert, wenn bekannt ist, dass der Empfänger mit einem Client mit Unterstützung von MAPI arbeitet, wie zum Beispiel Outlook mit dem IMAP4-Transporttreiber. Beim Senden von Nachrichten im RTF-Format kann eine maximale Interoperabilität zwischen Outlook-Benutzern in verschiedenen Messagingsystemen gewährleistet werden, da alle Nachrichteneigenschaften beibehalten werden. Für Kalenderinformationen ist die Rich-Text-Formatierung beispielsweise erforderlich. Benutzer können sich gegenseitig spezielle Nachrichtentypen in RTF senden, wie zum Beispiel Besprechungsanfragen oder Aufgabenanforderungen. Benutzer können individuell entscheiden, ob sie Nachrichten im RTF-Format senden möchten. Sie können dieses Feature jedoch ebenfalls im Exchange-System-Manager für jede einzelne SMTP-Domäne aktivieren. Wechseln Sie in den Eigenschaften für das Internetnachrichtenformat-Objekt zur Registerkarte Erweitert, und wählen Sie unter Exchange-Rich-Text-Format die Option Immer verwenden aus.

Anmerkung:

Beim Senden einer TNEF-verkapselten Nachricht werden alle MAPI-Attribute beibehalten, vorausgesetzt, der Empfänger arbeitet mit einem MAPI-fähigen Messagingclient. Nicht MAPI-fähige Clients zeigen eine Nur-Text-Nachricht bzw. eine HTML-formatierte Nachricht mit der zusätzlichen Anlage winmail.dat an, die der Empfänger nicht verwenden kann. Dies könnte den Empfänger irritieren. Sie sollten daher nur Rich-Text-Informationen an SMTP-Domänen senden, wenn Sie sich sicher sind, dass die Empfänger mit einem MAPI-fähigen Client arbeitet.

X.400-basierte Nachrichtenübertragung

Bevor sich SMTP selbst als einer der führenden Standards für die Nachrichtenübertragung etabliert hat, setzten kommerzielle E-Mail-Dienstanbieter und große Unternehmen X.400-Backbones ein, um unterschiedliche Messagingsysteme zu verbinden. Heute ist SMTP bekannter als X.400, da es einfach und im Internet etabliert ist. X.400 ist jedoch nach wie vor ein gängiger Messagingstandard in Kanzleien und Rechtsabteilungen, Finanzinstituten, Versicherungsunternehmen und anderen Organisationen, für die eine sichere und nachvollziehbare Nachrichtenübertragung erforderlich ist. In einem SMTP-basierten Backbone ist es schwer, fehlgeleitete Nachrichten zu suchen oder die Quelle einer E-Mail-Nachricht mit unerwünschtem Text zu ermitteln. In einem X.400-Backbone erfordert jede Verbindung eine Authentifizierung. Alle MTAs (Message Transfer Agents) müssen sich selbst als autorisierte MTAs identifizieren, bevor sie Nachrichten übertragen können. Da das Internet mit Spam und E-Mail-Viren überflutet wird, nimmt die Popularität von X.400 wieder zu.

Exchange Server 2003 unterstützt X.400 über den MTA (Microsoft Exchange Message Transfer Agent)-Stacks-Dienst. Der Exchange MTA unterstützt X.400 gemäß dem Konformitätsjahr 1988 und kann mit X.400-Remotesystemen aus den Jahren 1984 und 1988 über TCP/IP oder X.25 kommunizieren. X.400-Systeme aus späteren Konformitätsjahren (wie zum Beispiel 1992) müssen bei der Kommunikation mit Exchange 2003 den Umfang ihrer Features auf den Standard von 1988 reduzieren. Der X.400-Standard setzt voraus, dass X.400-Systeme ihre Funktionen an diejenigen ihrer Kommunikationspartner anpassen.+

Anmerkung:
Der X.400-Connector ist nur in der Enterprise Edition von Exchange Server 2003 verfügbar.

Nachrichtenübertragung von Exchange nach X.400

In Abbildung 5 wird das Senden von Nachrichten von Exchange 2003 an ein X.400-Remotesystem dargestellt.

Die Übertragung von Nachrichten von Exchange 2003 an ein Exchange-fremdes Messagingsystem über X.400 wird wie folgt ausgeführt:

1. Der Benutzer senden eine neue Nachricht, die der Exchange-Informationsspeichertreiber in der Warteschlange vor der Übermittlung positioniert, um sie an das Exchange 2003-Transportmodul weiterzugeben. In Exchange müssen alle Nachrichten für lokale oder Remoteempfänger das Transportmodul durchlaufen.
2. Das erweiterte Warteschlangenmodul überträgt die Nachricht aus der Warteschlange vor der Übermittlung in die Warteschlange vor der Kategorisierung, so dass das Kategorisierungsmodul die Nachricht verarbeiten kann. Das Kategorisierungsmodul überprüft die Einschränkungen, weist Sender- und Empfängerbeschränkungen zu und löst die Empfängerinformationen in Active Directory auf, um zu ermitteln, ob die Nachricht an einen lokalen Empfänger oder einen Remoteempfänger weitergeleitet werden soll. Das Kategorisierungsmodul platziert die Nachricht in einer Warteschlange nach der Kategorisierung, um sie an das erweiterte Warteschlangenmodul zurückzugeben.
3. Das erweiterte Warteschlangenmodul überträgt Nachrichten für nicht lokale Empfänger aus der Warteschlange nach der Kategorisierung in die Warteschlange vor dem Routing und ruft das Routingmodul auf. Das Routingmodul erkennt, dass der Empfänger ein Benutzer auf einem X.400-Messagingsystem ist (basierend auf der Zieladresse des Benutzers und dem mit dem X.400-Connector verknüpften Adressbereich). Der Warteschlangen-Manager verwaltet die Verbindungswarteschlangen.
4. Der Exchange-Informationsspeichertreiber informiert den Exchange MTA, dass die Übertragung einer neuen Nachricht erwartet wird. Der MTA erhält die Nachricht von der Verbindungswarteschlange, konvertiert Empfängerinformationen und Nachrichtentextkörper vom MDBEF (Message Database Encoding Format)-Format in das gewünschte X.400-Format gemäß dem in den X.400-Connectoreigenschaften angegebenem Konformitätsjahr und dem Zeichensatz des Remote-MTA, und platziert die Nachricht in einer internen MTA-Warteschlange im Dateisystem.
5. Der Exchange MTA stellt eine Verbindung zum Remote-MTA her, identifiziert sich selbst, und überträgt die Nachricht, sobald die Verbindung akzeptiert wird. Der Remote-MTA leitet die Nachricht anschließend an das endgültige Ziel weiter.

Nachrichtenübertragung von X.400 nach Exchange

In Abbildung 6 wird das Empfangen von Nachrichten von einem X.400-Remote-MTA dargestellt.

Die Übertragung von Nachrichten von einem X.400-Remot-MTA an Exchange 2003 kann in mehrere Schritte unterteilt werden:

1. Der X.400-Remote-MTA stellt eine Verbindung zum lokalen Exchange MTA her, identifiziert sich selbst als autorisierter MTA und überträgt die Nachricht, nachdem der Exchange MTA die Verbindung akzeptiert hat und diese erfolgreich hergestellt wurde. Der Exchange MTA speichert die eingehenden Nachrichten in einer Nachrichtendatenbank im Dateisystem.
2. Der Exchange MTA konvertiert die Empfängerinformationen und den Nachrichtentextkörper in ein Exchange-Format und platziert die Nachricht im SMTP-Postfachspeicher, um sie zur Übermittlung an das SMTP-Transportmodul weiterzugeben. In Exchange 2003 müssen alle Nachrichten durch das SMTP-Transportmodul übermittelt werden.
3. Der Exchange-Informationsspeichertreiber platziert die Nachricht in der Warteschlange vor der Übermittlung des erweiterten Warteschlangenmoduls.
4. Das erweiterte Warteschlangenmodul überträgt die Nachricht aus der Warteschlange vor der Übermittlung in die Warteschlange vor der Kategorisierung, so dass das Kategorisierungsmodul die Nachricht verarbeiten kann. Das Kategorisierungsmodul überprüft die Einschränkungen, weist Sender- und Empfängerbeschränkungen zu und löst die Empfängerinformationen in Active Directory auf, um zu ermitteln, ob die Nachricht an einen lokalen Empfänger oder einen Remoteempfänger weitergeleitet werden soll. Das Kategorisierungsmodul platziert die Nachricht in einer Warteschlange nach der Kategorisierung, um sie an das erweiterte Warteschlangenmodul zurückzugeben.
5. Das erweiterte Warteschlangenmodul überträgt die Nachrichten für lokale Empfänger aus der Warteschlange nach der Kategorisierung in die lokale Warteschlangenübermittlung.
6. Der Exchange-Informationsspeichertreiber nimmt die Nachricht auf und platziert sie im Posteingang des lokalen Empfängers.

Nachrichtenkonvertierung von Exchange nach X.400

X.400-Connectors bieten Unterstützung für eine Reihe von Inhaltstypen und Zeichensätzen. X.400-Inhaltstypen beinhalten P2 (Konformitätsjahr 1984), P22 (Konformitätsjahr 1988) sowie die Nachrichtentextteile 14 und 15 für binäre Daten. Wenn der Exchange MTA mit einem X.400-84-MTA kommuniziert, wird der Nachrichtenkörper unter Verwendung des P2-Inhaltstyps gesendet und die Anlagen unter Verwendung von Nachrichtentextteil 14. Bei der Kommunikation gemäß dem Konformitätsjahr 1988 wird Text unter Verwendung des P22-Inhaltstyps gesendet, und Sie können den Server zum Senden von Anlagen mit dem als FTPB (File Transfer Body Part) formatierten Nachrichtentextteils 14 oder 15 konfigurieren.

Der Exchange MTA bietet Unterstützung für die folgenden X.400-Nachrichtentextteile für Nachrichtentext:

• IA5 (Internationales Alphabet Nummer 5)   Ein Zeichensatz, der US-ASCII ähnelt und westeuropäische Zeichen beinhaltet.
• ISO (International Organization for Standardization) 6937   Ein Zeichensatz mit 333 Zeichen, die aus lateinischen Zeichen und vorschubfreien diakritischen Zeichen bestehen. Zur Unterstützung von anderen Sprachen ist der in ISO 2022 festgelegte Zeichensatzwechsel erforderlich. ISO 6937 stellt eine Erweiterung der Teletex-Zeichensatzdefinition dar.
• ISO 8859   Eine Familie von einzeln kodierten Acht-Bit-Zeichensätzen. Die meisten Sprachen, die auf Single-Byte-Zeichen basieren, können in einem der ISO 8859-Alphabete unterstützt werden.
• Teletex 61 (T.61)   Eine Teilmenge von ASCII mit internationalen Acht-Bit-Zeichen.

Keiner der Zeichensätze in den P2- oder P22-Inhaltstypen kann RTF-Informationen oder OLE-Objekte darstellen. Unterstützung für RTF ist nur verfügbar, wenn die Empfängerseite MAPI-Nachrichtenformate interpretieren kann. Viele X.400-basierte Messagingsysteme wie HP OpenMail unterstützen Outlook und daher auch MAPI.

Der Exchange MTA kann die komplette Nachricht in TNEF verkapseln und als zusätzliche Dateianlage senden. Dieses Prinzip entspricht demjenigen, das dem SMTP-Connector zugrunde liegt. Wenn das Empfängersystem die TNEF-Anlage verarbeiten kann (wenn der Empfänger beispielsweise Microsoft Outlook verwendet), wird die Nachricht mit allen RTF-Informationen angezeigt. Wenn das Empfängersystem TNEF jedoch nicht verarbeiten kann, sind der Nachrichtentext sowie die Anlagen möglicherweise nicht lesbar. Stellen Sie sicher, dass die X.400-Connectorkonfiguration den Funktionen des Exchange-fremden Messagingsystems entspricht.

Verzeichnissynchronisierung

Bei der Verzeichnissynchronisierung werden Verzeichnisinformationen über Exchange 2003-Benutzer von Active Directory in das Verzeichnis eines Exchange-fremden Messagingsystems übertragen. Gleichzeitig werden Informationen über Benutzer vom Exchange-fremden Messagingsystem in Active Directory zur Verwendung in Exchange 2003 übertragen. Nach Abschluss der Verzeichnissynchronisierung verfügt jedes System über eine vollständige Kopie der Verzeichnisdaten (Benutzer, Gruppen usw.) für die kombinierte Messagingorganisation.

Die Verzeichnissynchronisierung besteht aus zwei aufeinander folgenden Vorgängen:

• Synchronisieren der Empfänger zwischen Active Directory und einem Exchange-fremden Messagingsystem
• Synchronisieren der Empfänger zwischen einem Exchange-fremden Messagingsystem und Active Directory

Leider können Sie einen SMTP-Connector oder einen X.400-Connector nicht zur Aktivierung der automatischen, geplanten Verzeichnissynchronisierung zwischen Exchange 2003 und einem Exchange-fremden Messagingsystem verwenden. Die Implementierung einer manuellen bzw. halbautomatischen Lösung ist daher erforderlich. Achten Sie bei der Implementierung einer benutzerdefinierten Lösung zur Verzeichnissynchronisierung darauf, dass Sie einen bidirektionalen Prozess implementieren müssen, da die Empfängerattribute in beiden Verzeichnissen aktualisiert werden müssen. Weitere Informationen zur Verarbeitung von Verzeichnisinformationen mit Programmcode in einem Exchange-fremden Messagingsystem erhalten Sie vom Anbieter des jeweiligen Messagingsystems. In diesem Abschnitt wird die Verwendung von Active Directory mit Active Directory-Standardtools erläutert.

Synchronisieren von Verzeichniseinträgen zwischen einem Exchange-fremden Messagingsystem und Active Directory

Die Verzeichnissynchronisierung zwischen einem Exchange-fremden Messagingsystem und Active Directory beinhaltet die folgenden Prozesse:

1. Extrahieren von Verzeichnisinformationen aus dem Exchange-fremden Messagingsystem   Sie können eine Vielzahl an Tools zum Abrufen der Quellverzeichnisinformationen verwenden. Dazu zählen APIs (Application Programming Interfaces) oder LDAP. Wenn das Exchange-fremde Messagingsystem LDAP unterstützt, können Sie den Assistenten für die Migration zu Exchange verwenden, um Verzeichnisinformationen aus dem Exchange-fremden Messagingsystem zu extrahieren. Stellen Sie bei LDAP-Verzeichnissen sicher, dass Sie die Option Migration von Internetverzeichnis (LDAP via ADSI) und auf der nächsten Seite des Assistenten die Option Nur Migrationsdateien extrahieren auswählen. Der Assistent für die Migration zu Exchange platziert die extrahierten Verzeichnisinformationen in die primäre Migrationsdatei directory.pri, eine durch Komma getrennte (.csv) Textdatei, die Sie als Grundlage für weitere Prozesse verwenden können, wie zum Beispiel für einen Verzeichnisimport. Weitere Informationen zu Migrationsdateien und zum Assistenten für die Migration zu Exchange finden Sie unter Informationen zur Interoperabilität und Migration in Exchange Server 2003.

   Anmerkung:

   LDAP-konforme Verzeichnisse enthalten normalerweise SMTP-Adressinformationen. Sie sollten daher einen SMTP-Connector verwenden, wenn Sie LDAP-konforme Verzeichnisse für Verbindungen zu Messagingsystemen verwenden. Wenn Sie stattdessen einen X.400-Connector verwenden, stellen Sie sicher, dass Sie die Adressinformationen im X.400-Format abrufen. Die meisten Messagingsysteme bieten proprietäre Verzeichnisexportfeatures, die Sie verwenden können. Fragen Sie Ihren Administrator nach der für das alte Messagingsystem verantwortlichen Person, um exportierte Verzeichnisinformationen in dem Format zu erhalten, das dem Connector entspricht, den Sie zwischen Exchange 2003 und dem Exchange-fremden Messagingsystem bereitstellen.

2. Vorbereiten der Verzeichnisinformationen für einen Import in Active Directory   Das Tool, das Sie für den Import von Verzeichnisinformationen in Active Directory verwenden, legt fest, wie Sie die Daten für einen erfolgreichen Importvorgang strukturieren müssen. Wenn Sie beispielsweise Ldifde.exe verwenden, müssen Sie die Quelldaten im LADP LDIF (Data Interchange Format)-Format bereitstellen. LDIF ist in RFC 2849 definiert. Wenn Sie jedoch über Programmierkenntnisse in ADSI oder CDOEXM verfügen, können Sie eine benutzerdefinierte Lösung zum Importieren von Daten entwickeln. Das Format der Quelldaten richtet sich nach den in Ihrer benutzerdefinierten Lösung implementierten Analyseroutinen. Idealerweise verwenden Sie ein Tool, das die Eingabedatei ohne vorherige Formatkonvertierungen analysiert. Sie möchten beispielsweise die CSV-basierte Struktur einer directory.pri-Datei direkt in dem Format analysieren, in dem es aus einem LDAP-Verzeichnis exportiert wurde, um Empfängerinformationen in Active Directory zu importieren. Weitere Informationen zur Programmierung mit ADSI oder CDOEXM finden Sie im Exchange SDK (https://go.microsoft.com/fwlink/?LinkId=25925).

3. Importieren der Verzeichnisinformationen in Active Directory   Sie können den Assistenten für die Migration zu Exchange nicht zur Verzeichnissynchronisierung verwenden, da er zum Erstellen von Postfächern in Exchange 2003 entwickelt wurde. Die Verzeichnissynchronisierung basiert auf der Annahme, dass sich die Empfänger nach wie vor im alten System befinden. Zur Ausführung einer ordnungsgemäßen Verzeichnissynchronisierung muss Ihre Lösung E-Mail-aktivierte Benutzerkonten oder E-Mail-aktivierte Kontakte anstelle von Postfach-aktivierten Benutzerkonten erstellen. Es ist daher empfehlenswert, dass Sie eine ausgewiesene Organisationseinheit für alle Exchange-fremden Benutzer in Active Directory erstellen, die während des Migrationsprozesses verwendet werden.
   Für Exchange-fremde Benutzer können Sie die folgenden Benutzerkontentypen in Active Directory erstellen:

   • Deaktivierte Windows-Benutzerkonten   Erstellen Sie deaktivierte Windows-Benutzerkonten, wenn sich Ihre Exchange-fremden Benutzer noch nicht in Ihrer Active Directory-Umgebung befinden, dies aber nach der Migration zu Exchange 2003 sein werden.
   • Neue Windows-Benutzerkonten   Erstellen Sie aktivierte Windows-Konten für Exchange-fremde Benutzer, die sich vor der Migration bereits in Ihrer Active Directory-Umgebung befinden.
   • Windows-Kontakte   Erstellen Sie Windows-Kontakte für Exchange-fremde Benutzer, die sich nicht in Ihrer Active Directory-Umgebung befinden. Der Assistent für die Migration zu Exchange kann diese Kontaktobjekte während der Migration in Benutzerkonten konvertieren.
     Eine interessante Frage stellt sich im Hinblick auf die Verteilerlisten im alten Messagingsystem. Sie können Verteilerlisten als Kontaktobjekte synchronisieren, was den Vorteil hat, dass Sie die Mitgliedschaftsinformationen der Verteilerlisten in Active Directory nicht beibehalten müssen. Wenn Sie jedoch Verteilerlisten als Kontaktobjekte synchronisieren, müssen an eine Verteilerliste gesendete Nachrichten zunächst an das alte Messagingsystem zur Aufgliederung der Verteilerliste gesendet werden, bevor die Nachricht an die einzelnen Empfänger übermittelt werden kann. Wenn die Verteilerliste Empfänger enthält, die sich auf Benutzer in der Exchange 2003-Organisation beziehen, müssen Nachrichten an die Exchange 2003-Organisation zurückgegeben werden, nachdem die Verteilerliste aufgeteilt wurde. Um diese unnötige Nachrichtenübertragung zu vermeiden, können Sie E-Mail-aktivierte Gruppen in Active Directory erstellen und die einzelnen Mitglieder direkt angeben. Wenn Sie so vorgehen, kann Exchange 2003 die Verteilerliste sofort und ohne zusätzliche Nachrichtenübertragung an das alte Messagingsystem aufteilen.
     Gruppen in Active Directory können beliebige Arten von Empfängerobjekten enthalten, z. B. Benutzerkonten, Kontakte oder andere Gruppen. Nachdem Sie E-Mail-aktivierte Benutzerkonten oder E-Mail-aktivierte Kontakte in Active Directory erstellt haben, die den Empfängern im alten Messagingsystem entsprechen, können Sie die Verteilerlisten aus dem alten System spiegeln und die erforderlichen Empfängerobjekte als Elemente hinzufügen. Wenn Sie Benutzer zu einem späteren Zeitpunkt mit dem Assistenten für die Migration zu Exchange migrieren, findet der Assistent vorhandene E-Mail-aktivierte Objekte, indem er die E-Mail-Adresse des zu migrierenden Kontos mit der E-Mail-Adresse des Zielobjekts in Active Directory vergleicht. Während des Migrationsprozesses konvertiert der Assistent für die Migration zu Exchange diese Empfängerobjekte in Postfach-aktivierte Benutzerkonten und behält die Mitgliedschaftsinformationen der Verteilergruppen bei. Wenn Sie den Assistenten für die Migration zu Exchange jedoch nicht verwenden, müssen Sie zusätzliche Schritte ausführen, um die Postfach-aktivierten Benutzerkonten nach der Migration an die jeweiligen Verteilergruppen zurückzugeben. Diese Schritte können programmiert werden.

   Anmerkung:
   Der Assistent für die Migration zu Exchange exportiert keine Verzeichnisinformationen zu Verteilerlisten aus dem alten Messagingsystem. Sie müssen eine andere Verzeichnisexportmethode auswählen oder die Verteilerlisten in Active Directory manuell erstellen.

4. Aktualisieren der Verzeichnisinformationen in Active Directory   Nach dem Import der Verzeichnisinformationen in Active Directory müssen Sie sicherstellen, dass die Verzeichnisinformationen in beiden Verzeichnissen einen aktuellen Stand aufweisen. Wenn Sie z. B. einen Benutzer im alten Messagingsystem ändern oder löschen, muss auch das entsprechende Empfängerobjekt in Active Directory aktualisiert bzw. gelöscht werden. Das Ändern bzw. Löschen eines vorhandenen Empfängerobjekts setzt voraus, dass Sie das vorhandene Objekt in Active Directory finden, um eine Aktualisierung durchzuführen.
   So suchen Sie Empfängerobjekte in Active Directory, die folgenden Objekten entsprechen:

   • Geänderte Empfängerobjekte im Exchange-fremden Messagingsystem   Sie können die E-Mail-Adresse des Empfängerobjekts für die Suche nach dem Gegenstück in Active Directory verwenden, da die primäre E-Mail-Adresse des Active Directory-Objekts die SMTP- oder X.400-Adresse des Empfängers im alten Messagingsystem ist. Beachten Sie jedoch Situationen, in denen die E-Mail-Adressen nicht übereinstimmen. Ein Benutzer verfügt möglicherweise über ein Benutzerkonto in Active Directory, das nicht E-Mail-aktiviert wurde, oder die ursprüngliche E-Mail-Adresse des Benutzers hat sich geändert (zum Beispiel hat der Benutzer im alten Messagingsystem eine neue SMTP-Adresse erhalten). In diesen Fällen funktioniert die Suche nach übereinstimmenden E-Mail-Adressen nicht. Sie müssen zusätzliche Attribute verwenden, um das übereinstimmende Empfängerobjekt zu finden. Sie können den Anzeigenamen oder den Alias des Benutzers im alten System oder ein beliebiges Attribut verwenden, mit dem Sie eine verlässliche Verknüpfung zwischen den Quell- und Zielempfängerobjekten herstellen können.
   • Gelöschte Empfängerobjekte im Exchange-fremden Messagingsystem   Die Suche nach einem Zielobjekt in Active Directory ist sehr kompliziert, wenn das Quellobjekt aus dem alten Exchange-fremden Messagingsystem gelöscht wurde. Das gelöschte Quellobjekt ist nicht mehr vorhanden, kann also nicht als Verweis für die Suche nach einem entsprechenden Empfängerobjekt in Active Directory verwendet werden. In diesem Fall können Sie entweder das entsprechende Empfängerobjekt manuell aus Active Directory löschen oder die komplette Adressliste aus dem Exchange-fremden Messagingsystem mit der kompletten Liste der entsprechenden Empfängerobjekte in Active Directory vergleichen, um herauszufinden, welche Objekte lediglich in Active Directory vorhanden sind. E-Mail-aktivierte Active Directory-Konten ohne ein Gegenstück im ursprünglichen Messagingsystem geben an, dass die Quellobjekte gelöscht wurden.
     Wenn Sie Adresslisten vergleichen möchten, müssen Sie die in Active Directory erstellten Empfängerobjekte mit ihren Gegenstücken im Exchange-fremden Messagingsystem verknüpfen. Sie können den SMTP-Domänennamen des alten Messagingsystems möglicherweise verwenden, um diese Verknüpfung zu erstellen. Eine weitere Option ist die Verwendung einer Organisationseinheit ausschließlich für Empfängerobjekte, die zu einem bestimmten alten Messagingsystem gehören. Sie können dann die Objekte in der Organisationseinheit mit der Liste der Empfänger im alten System vergleichen. Eine dritte, und möglicherweise eine der verlässlichsten Methoden zum Vergleichen von Adresslisten besteht darin, bestimmte Informationen zum Messagingsystem, in dem sich die Empfänger befinden, in ein Attribut der Empfängerobjekte in Active Directory zu schreiben. Dieses Attribut kann anschließend als Grundlage für eine LDAP-Abfrage verwendet werden. Sie können entweder ein Erweiterungsattribut oder ein Attribut mit der Bezeichnung importedFrom verwenden, um Ihre spezifischen Synchronisierungsinformationen zu registrieren.

In Abbildung 7 wird das allgemeine Verfahren für die Übertragung von Verzeichnisinformationen aus einem Exchange-fremden Messagingsystem nach Active Directory basierend auf LDAP, der Assistent für die Migration zu Exchange sowie ein benutzerdefiniertes Skript zur Verarbeitung der Datei directory.pri dargestellt. Wenn Sie eine Lösung ohne ein benutzerdefiniertes Skript bevorzugen, können Sie dieses durch Ldifde.exe ersetzen. Beachten Sie hierbei, dass Sie das Format der Datei directory.pri zur Unterstützung von Ldifde.exe in ein LDF-Format konvertieren müssen.

Synchronisierung von Verzeichniseinträgen zwischen Active Directory und einem Exchange-fremden Messagingsystem

Die Verzeichnissynchronisierung zwischen Active Directory und einem Exchange-fremden Messagingsystem basiert auf denselben Prinzipien wie die Verzeichnissynchronisierung zwischen einem Exchange-fremden Messagingsystem und Active Directory. Extrahieren Sie Informationen zu Postfach-aktivierten Benutzerkonten von Active Directory, verarbeiten Sie diese Informationen, und importieren, aktualisieren oder löschen Sie sie im alten Verzeichnis. Zum Extrahieren von Active Directory-Daten können Sie Tools wie Ldifde.exe, Csvde.exe oder ADSI verwenden. Sie können ebenfalls den Assistenten für die Migration zu Exchange verwenden, da es sich bei Active Directory um ein unterstütztes LDAP-konformes Verzeichnis handelt. Der Vorteil bei der Verwendung des Assistenten für die Migration zu Exchange zum Extrahieren von Active Directory-Daten liegt darin, dass die extrahierten Verzeichnisinformationen in der Datei directory.pri genau wie Verzeichnisinformationen aus einem beliebigen LDAP-Verzeichnis platziert werden. Sie können daher die Routinen für die Dateianalyse, die Sie für die Synchronisierung zwischen dem Exchange-fremden Messagingsystem und Active Directory verwendet haben, erneut einsetzen. Lediglich die für den Import der Verzeichnisinformationen in das alte Verzeichnis verwendeten APIs oder Tools unterscheiden sich. Ausführliche Informationen zum Importieren von Verzeichnisinformationen in ein altes Messagingsystem erhalten Sie vom jeweiligen Anbieter Ihres Messagingsystems.

Anmerkung:

Damit die Verzeichnissynchronisierung aus Active Directory in das Exchange-fremde Verzeichnis funktioniert, muss das andere Messagingsystem Verzeichnisinformationen für Benutzer enthalten, die nicht zum lokalen Messagingsystem gehören. Die meisten Systeme erlauben Verknüpfungen zu SMTP- oder X.400-Empfängerobjekten mit Connectors oder Remotedomänen in ihrem Verzeichnis. Beim Herstellen einer Verbindung zu den Messagingsystemen über SMTP müssen Sie Exchange-Benutzer als Internetempfänger synchronisieren. Beim Herstellen einer Verbindung zu den Messagingsystemen unter Verwendung eines X.400-Connectors müssen Sie Exchange-Benutzer als X.400-Empfänger synchronisieren. Alle Exchange-Benutzer verfügen mindestens über eine SMTP-Adresse und eine X.400-Adresse.

In Abbildung 8 wird das allgemeine Verfahren für die Übertragung von Verzeichnisinformationen aus Active Directory in ein Exchange-fremdes Messagingsystem unter Verwendung des Assistenten für die Migration zu Exchange sowie ein benutzerdefiniertes Skript dargestellt, dass Microsoft-fremde APIs verwendet oder Tools importiert, um die Empfängerobjekte im alten Verzeichnis zu platzieren.

Ein Nachteil bei der Verwendung des Assistenten für die Migration zu Exchange zum Extrahieren von Verzeichnisinformationen aus Active Directory besteht darin, dass Informationen für E-Mail-aktivierte Benutzerknoten, Kontakte oder Verteilergruppen aus Active Directory nicht extrahiert werden können. Wenn Ihre Exchange 2003-Organisation mit mehreren Exchange-fremden Messagingsystemen verbunden ist oder E-Mail-aktivierte Objekte für Empfänger im Internet erstellt wurden, möchten Sie diese E-Mail-aktivierten Objekte möglicherweise in Ihrem benutzerdefinierten Verzeichnissynchronisierungsprozess integrieren, damit Benutzer in den Exchange-fremden Messagingsystemen mit allen Benutzern in Ihrer Messagingumgebung unter Verwendung der Exchange 2003-Organisation als Backbone problemlos kommunizieren können. Zum Extrahieren von E-Mail-aktivierten Objekten aus Active Directory können Sie Tools wie Ldifde.exe, Csvde.exe oder ADSI verwenden. Die Synchronisierung von E-Mail-aktivierten Verteilergruppen als Kontaktobjekte ist empfehlenswert, da Sie somit die Synchronisierung der Gruppenmitgliedschaft umgehen können. Wie unter Informationen zur Interoperabilität und Migration in Exchange Server 2003 erläutert, können Probleme mit Verteilergruppen auf verschiedene Weise behoben werden.

Anmerkung:
Wenn Sie E-Mail-aktivierte Clients synchronisieren möchten, müssen Sie Ihre Verzeichnissynchronisierungsprozesse sorgfältig überprüfen, um doppelte Adressinformationen zu vermeiden, die entstehen können, wenn Sie E-Mail-aktivierte Objekte synchronisieren, die auf aktuelle Empfänger im alten Messagingsystem verweisen.

Alternativen zur Verzeichnissynchronisierung

Die Implementierung einer benutzerdefinierten Lösung für die Verzeichnissynchronisierung ist eine gute Wahl für Systemadministratoren, die das Arbeiten mit Befehlszeilentools und APIs bevorzugen. Wenn Sie jedoch eine schneller verfügbarere Lösung bevorzugen, stehen die folgenden Optionen ebenfalls zur Auswahl:

• In Exchange Server 5.5 oder Exchange 2000 Server verfügbare Messagingconnectors   Wenn Sie eine gemischte Exchange-Organisation ausführen, können Sie die in Exchange 5.5 oder Exchange 2000, jedoch nicht in Exchange 2003 enthaltenen Messagingconnectors für die Nachrichtenübertragung und Verzeichnissynchronisierung verwenden. Sie können zum Beispiel Exchange 2000 für nahtlose Verbindungen zu Microsoft Mail für PC-Netzwerke oder Lotus cc:Mail sowie Exchange 5.5 für Verbindungen zu Microsoft Mail für PC-Netzwerke, Lotus cc:Mail, IBM PROFS und IBM Systems Network Architecture Distribution Services (SNADS) mit einem direkten Gatewayconnector verwenden.
• Microsoft Metadirectory Services (MMS)   Verwenden Sie MMS zur gegenseitigen Integration von mehreren Verzeichnissen. MMS unterstützt eine Reihe von Verzeichnisdiensten, darunter Active Directory, das Exchange 5.5-Verzeichnis Microsoft Windows NT®-Domänen, Lotus Notes/Domino, Lotus cc:Mail, Novell NetWare Directory (NDS) oder Novell NetWare Bindery, Novell GroupWise, Banyan Systems BeyondMail und Intelligent Messaging, Structured Query Language (SQL)/Open DataBase Connectivity (ODBC) sowie LDAP-basierte Verzeichnisserver wie Netscape, Sun ONE (früher Netscape iPlanet) und X.500-basierte Verzeichnisse. MSS stellt eine geeignete Wahl dar, wenn Ihre Exchange 2003-Organisation permanent neben einem Exchange-fremden Messagingsystem besteht. Wenn Sie jedoch die alte Infrastruktur durch die Migration zu Active Directory und Exchange 2003 in naher Zukunft ersetzen möchten, sollten Sie die Investition in MMS überdenken.
• Connector für Lotus Notes   Wenn Sie Exchange 2003 mit Lotus Notes/Domino verbinden, E-Mail-Nachrichten jedoch über SMTP und nicht über Connector für Lotus Notes senden möchten, können Sie die Synchronisierung der Verzeichnisse unter Verwendung des von Connector für Lotus Notes bereitgestellten Features zur Verzeichnissynchronisierung beibehalten. Ändern Sie lediglich die Zuordnungstabellen für die Verzeichnisattribute, damit Exchange-Empfänger als SMTP-Empfänger in Lotus Notes und Lotus Notes-Empfänger als SMTP-Kontakte in Active Directory angezeigt werden. Ausführliche Informationen zum Bearbeiten von Zuordnungstabellen finden Sie im Microsoft Knowledge Base-Artikel 303724, "Verzeichnis-Synchronisierung zwischen Notizen und Exchange mit SMTP-Adressen" (https://go.microsoft.com/fwlink/?linkid=3052&kbid=303724).

Kalenderintegration

Exchange 2003 verwaltet Frei/Gebucht-Informationen in einem versteckten Systemordner mit der Bezeichnung Schedule+ Frei/Gebucht und benötigt eine Kalenderconnectorinstanz, um Frei/Gebucht-Informationen für Exchange-fremde Benutzer in diesen Systemordner zu platzieren. Wenn Sie eine Verbindung von Exchange 2003 nach einem Exchange-fremden Messagingsystem über einen SMTP- oder einen X.400-Connector herstellen, ist der Kalenderconnector leider nicht verfügbar.

Dieses Problem können Sie umgehen, indem Sie das IFB (Internet Free/Busy)-Veröffentlichungsfeature von Outlook verwenden. Outlook-Benutzer können dieses Feature verwenden, um Frei/Gebucht-Informationen an einem freigegebenen Speicherort zu veröffentlichen, so dass andere Benutzer, die ansonsten keinen Zugriff auf diese Informationen hätten, diese abrufen können. Outlook-Benutzer können ihre Frei/Gebucht-Zeiten mit dem Frei/Gebucht-Internetdienst von Microsoft Office oder an einem Speicherort im internen Netzwerk veröffentlichen. Bei der Verwendung des Frei/Gebucht-Dienstes können Sie den Zugriff auf die veröffentlichten Informationen beschränken, so dass lediglich speziell autorisierte Mitglieder des Dienstes diese Informationen anzeigen können. Standardmäßig werden die Frei/Gebucht-Informationen im Frei/Gebucht-Dienst alle 15 Minuten in Outlook aktualisiert, so dass der aktuelle Terminplan wiedergegeben wird. Wenn andere Benutzer eine Besprechung mit Ihnen planen, werden die von Ihnen im Frei/Gebucht-Dienst veröffentlichten Frei/Gebucht-Zeiten auf der Registerkarte Terminplanung in den Besprechungsanfragen der Benutzer automatisch als schattierte Leisten angezeigt, so dass diese sich über Ihre Verfügbarkeit informieren können. Weitere Informationen zum Frei/Gebucht-Dienst finden Sie unter https://go.microsoft.com/fwlink/?LinkId=25927.

Alternativ können Frei/Gebucht-Informationen auch auf einen internen Server veröffentlicht werden. Der Vorteil dieser Option ist derjenige, dass keine Mitgliedschaften für den Dienst erforderlich sind. Sie können einen Webserver im Intranet, einen internen FTP-Server oder einen Dateiserver verwenden, um das gemeinsam genutzte Repository bereitzustellen. Der einzige Unterschied bei diesen Optionen ist die URL (Uniform Resource Locator), die Sie in Ihrer Outlook-Konfiguration für den Speicherort angeben müssen, an dem die Frei/Gebucht-Informationen veröffentlicht werden sollen. Sie können ein gültiges URL-Format verwenden, wie zum Beispiel: http://, Datei://\ oder ftp://.

In Abbildung 9 wird eine Möglichkeit für die Implementierung der Frei/Gebucht-Informationsfreigabe in einer Umgebung mit einem Exchange-fremden Messagingsystem dargestellt.

Die Veröffentlichung von Frei/Gebucht-Informationen über das Internet oder das Intranet funktioniert reibungslos, wenn alle Benutzer Outlook installiert haben. IFB-Veröffentlichung wird jedoch nur unterstützt, wenn Outlook für den Internetmodus konfiguriert wurde. Weitere Informationen zur Konfiguration von Outlook für den Internetmodus finden Sie in Ihrer Outlook-Produktdokumentation.

Andere Messagingclients können die Veröffentlichung von Frei/Gebucht-Informationen über das Internet oder Intranet ebenfalls unterstützen, da IFP-Veröffentlichung auf dem IETF (Internet Engineering Task Force)-Standard iCal basiert. IFB-Veröffentlichung basiert auf dem vCalendar-Standard, der Teil von iCal ist und sich mehr und mehr als Standard zum Formatieren und Speichern von Frei/Gebucht-Informationen durchsetzt.

Wenn Sie IFB-Veröffentlichung in einer Exchange-Organisation aktivieren, in der Benutzer normalerweise über den MAPI-Transportdienst für Exchange auf ihre Postfächer zugreifen, verwendet Outlook weiterhin den Systemordner Schedule+ Frei/Gebucht für alle Exchange-Empfänger, die sich in den serverbasierten Adresslisten befinden. Diese serverbasierten Konten werden nicht zusätzlich im Frei/Gebucht-Dienst oder in einem gemeinsam genutzten Repository überprüft. Die serverbasierten Konten beinhalten alle Exchange-Benutzer sowie alle mit Active Directory synchronisierten Exchange-fremden Empfänger.

IFB-Veröffentlichung funktioniert daher nur so lange, bis Sie eine Verzeichnissynchronisierung durchführen. Dies liegt daran, das E-Mail-aktivierte Benutzerkonten (nur Outlook betreffend) und E-Mail-aktivierte Kontakte in Active Directory beides Empfänger in der Exchange 2003-Organisation sind, in der Outlook keine an einem freigegebenen Speicherort im Unternehmensnetzwerk veröffentlichten Frei/Gebucht-Informationen erwartet. IFB-Veröffentlichung funktioniert nicht, da Outlook nur den Systemordner Schedule+ Frei/Gebucht nach Exchange-fremde Benutzern mit synchronisierten Empfängerobjekten durchsucht, die Frei/Gebucht-Informationen befinden sich jedoch nicht an diesem Speicherort.

Um die Tatsache zu umgehen, dass IFB-Veröffentlichung mit Outlook nur im Internetmodus funktioniert, stehen Ihnen zwei Möglichkeiten zur Verfügung:

• Führen Sie keine Verzeichnissynchronisierung durch    Wenn die Freigabe von Kalenderinformationen wichtiger ist als die Bereitstellung von konsistenten Adresslisten in allen Messagingsystemen, können Sie sich gegen die Verzeichnissynchronisierung entscheiden. Für eine nahtlose Interoperabilität ist die Verzeichnissynchronisierung normalerweise jedoch erforderlich und hat eine höhere Priorität als die IFB-Veröffentlichung. Wenn Sie konsistente serverbasierte Adresslisten bereitstellen möchten, müssen Sie sich nach einer anderen Lösung umschauen, um plattformübergreifenden Zugriff auf Frei/Gebucht-Informationen zu gewährleisten.

• Speichern von Kalenderinformationen als Webseite   Wenn Sie das IFB-Veröffentlichungsfeature verwenden möchten, können Sie einmal im Monat einen Snapshot von Ihrem Kalender mit allen Terminen und Besprechungen veröffentlichen. Achten Sie jedoch darauf, dass bei dieser Methode die Details zu Ihren Terminen und Besprechungen nicht berücksichtigt werden. In diesem Szenario veröffentlichen Sie mehr als Frei/Gebucht-Zeiten. Weiterhin wird die Webseite nicht automatisch aktualisiert, wenn Sie Termine in Ihrem Kalenderordner aktualisieren, hinzufügen, löschen oder ändern. Sie müssen Ihren Kalender jedes Mal speichern, wenn Sie die Webversion aktualisieren möchten.

• Gewährleisten von Zugriff auf Kalenderinformationen über eine ASP.NET-Seite   Anstelle des Speicherns von Kalendersnapshots als Webseiten können Sie benutzerdefinierte Frei/Gebucht-Suchen unter Verwendung von Exchange-Programmier-APIs, wie zum Beispiel CDOEX, implementieren. CDOEX bietet eine GetFreeBusy-Methode über die IAddressee-Schnittstelle, die Sie mit Hilfe von Programmcode in eine ASP.NET-Seite oder ein Visual Basic-Programm abrufen können. Sie können ebenfalls andere Programmiersprachen verwenden, zum Beispiel C++ oder Microsoft C#. Wie der Name bereits impliziert, ruft die GetFreeBusy-Methode die Frei/Gebucht-Informationen eines gültigen Exchange 2003-Benutzers ab.

  Anmerkung:
  CDOEX kann nur direkt auf einem Server unter Exchange 2000 oder Exchange 2003 verwendet werden. Es ist daher empfehlenswert, die GetFreeBusy-Methode auf einer ASP.NET-Seite zu verwenden, die über Microsoft Internet Information Services (IIS) auf einem Exchange 2003-Server veröffentlicht wurde.

  Das folgende Visual Basic .NET-Codebeispiel aus dem Exchange SDK zeigt, wie Frei/Gebucht-Informationen für einen bestimmten Benutzer abgerufen werden. Sie können diesen Code verwenden, um Exchange-fremde Benutzern eine webbasierte Lösung für den Zugriff auf Frei/Gebucht-Informationen über Exchange-Benutzer bereitzustellen. Weitere Informationen zur GetFreeBusy-Methode finden Sie unter "Checking Free/Busy Status" (https://go.microsoft.com/fwlink/?LinkId=25928).

  ' Reference to Microsoft ActiveX Data Objects 2.5 Library
  ' Reference to Microsoft CDO for Exchange 2000 Library
  ' Reference to Active DS Type Library
  Function GetFreeBusyString(ByVal strUserUPN As String, _
                             ByVal dtStartDate As Date, _
                             ByVal dtEndDate As Date, _
                             ByVal Interval As Integer) As String
  
     Try
        ' Variables.
        Dim iAddr As New CDO.Addressee()
        Dim freebusy As String
        Dim Info As New ActiveDs.ADSystemInfo()
  
        iAddr.EmailAddress = strUserUPN
        If Not iAddr.CheckName("LDAP://" & Info.DomainDNSName) Then
           Throw New System.Exception("Error occurred!")
        End If
  
       ' Get the free/busy status in Interval minute intervals
       ' from dtStartDate to dtEndDate.
       freebusy = iAddr.GetFreeBusy(dtStartDate, dtEndDate, Interval)
       GetFreeBusyString = freebusy
  
     Catch err As Exception
        Console.WriteLine(err.ToString())
        GetFreeBusyString = ""
     End Try
  End Function
  

  Die GetFreeBusy-Methode kann nur zum Abrufen von Frei/Gebucht-Informationen in Exchange verwendet werden. Viele Messagingsysteme bieten jedoch Webschnittstellen für den Zugriff auf Daten in Postfächern und öffentlichen Repositorys. Fragen Sie den Hersteller Ihres alten Systems nach der Verfügbarkeit einer ähnlichen API, um Exchange-Benutzern Zugriff auf Kalenderinformationen ebenfalls über eine benutzerdefinierte webbasierte Lösung zu ermöglichen.

• Konfigurieren von Outlook zur Verwendung von IFB-Veröffentlichung bei gleichzeitigem Einsatz einer anderen Lösung für den Zugriff auf veröffentlichte Frei/Gebucht-Informationen   Eine weitere, und möglicherweise geeignetere Lösung für den gegenseitigen Zugriff von Exchange-fremden und Exchange-Benutzern auf Frei/Gebucht-Informationen in einer ASP.NET-Lösung stellt das Auslesen von vCalendar-Dateien dar, die Outlook-Clients bei Aktivierung der IFB-Veröffentlichung in ein freigegebenes Verzeichnis schreiben können. Frei/Gebucht-Informationen können immer veröffentlicht werden. Lediglich die Suche nach Frei/Gebucht-Informationen von synchronisierten Empfängerobjekten stellt ein Problem für Exchange-Benutzer dar. Eine ASP.NET-Lösung kann dieses Problem beheben. Exchange- und Exchange-fremde Benutzer können ihre Outlook-Clients zur Veröffentlichung von Frei/Gebucht-Informationen auf einem Webserver konfigurieren und dann die ASP.NET-Lösung als Tool verwenden, um Besprechungen und Konferenzen zu buchen. Die Implementierung einer ASP.NET-Lösung zur Analyse von vCalender-Dateien übersteigt den Rahmen dieser Dokumentation. Weitere Informationen hierzu finden Sie im Exchange SDK (https://go.microsoft.com/fwlink/?LinkId=25925).

• Ignorieren des Problems   Eine weitere Option stellt die grundsätzliche Vermeidung der Frei/Gebucht-Integration dar. Wenn die Migration von Teams und Abteilungen als eine Einheit möglich ist, ist der plattformübergreifende Zugriff auf Frei/Gebucht-Informationen nicht notwendig. Wenn Sie alle möglichen Besprechungsteilnehmer gleichzeitig zu Exchange 2003 migrieren, können Sie das Outlook-Standardfeature für Frei/Gebucht-Suchen beim Planen von Besprechungen verwenden.