Microsoftdownload.microsoft.com/download/9/5/0/95048233-01b7 … · Web viewFolgende Themen...
840
c5541abf-15ce-464f-b5d2-758395fcdf3e Technisches Referenzhandbuch für Microsoft Exchange Server 2003 Microsoft Corporation Veröffentlicht: 12.12.06 Autor: Exchange Server-Dokumentationsteam Kurzdarstellung Das Handbuch wurde für Exchange-Experten konzipiert, die umfassende Informationen über die Architektur und Interaktion zwischen den Hauptkomponenten von Microsoft Exchange Server 2003 benötigen. Kommentare? Senden Sie Ihr Feedback an folgende Adresse: [email protected] .
Transcript of Microsoftdownload.microsoft.com/download/9/5/0/95048233-01b7 … · Web viewFolgende Themen...
c5541abf-15ce-464f-b5d2-758395fcdf3e
Technisches Referenzhandbuch für Microsoft Exchange Server 2003
Microsoft Corporation
Veröffentlicht: 12.12.06
Autor: Exchange Server-Dokumentationsteam
KurzdarstellungDas Handbuch wurde für Exchange-Experten konzipiert, die umfassende Informationen über die Architektur und Interaktion zwischen den Hauptkomponenten von Microsoft Exchange Server 2003 benötigen.
Kommentare? Senden Sie Ihr Feedback an folgende Adresse: [email protected].
Contents
Technisches Referenzhandbuch für Exchange Server 2003..................................................17
Einführung in das technische Referenzhandbuch für Exchange Server 2003........................17Welche Informationen bietet dieses Handbuch?.................................................................17Für wen ist dieses Handbuch gedacht?..............................................................................19Einführende Dokumentationen............................................................................................20
Technische Übersicht über Exchange Server 2003................................................................20
Exchange Server 2003 als Nachrichtenverarbeitungssystem................................................21Allgemeine Komponenten eines Nachrichtenverarbeitungssystems...................................22Das Nachrichtenverarbeitungssystem in der Netzwerkinfrastruktur....................................23
Verzeichnisintegration............................................................................................................25Empfängerobjekte im Verzeichnis.......................................................................................25Konfigurationsinformationen im Verzeichnis.......................................................................27Exchange-Klassen und -Attribute in Active Directory..........................................................28Verzeichniszugriffsarchitektur..............................................................................................28
Nachrichtentransport..............................................................................................................29Nachrichtenroutingarchitektur.............................................................................................29Nachrichtenrouting mit Routinggruppen..............................................................................30
Exchange-Nachrichtenspeicher..............................................................................................33Exchange Server 2003-Datenbanktechnologie...................................................................33Informationsspeicher und Speichergruppen........................................................................34
Benutzeragents in einer Exchange Server 2003-Organisation...............................................35
Dienstabhängigkeiten in Exchange Server 2003....................................................................37
Grundlagen zur Architektur der Windows-Dienste..................................................................38Funktionen des Dienststeuerungs-Managers......................................................................39Exchange-Dienste und das Konto „LocalSystem“...............................................................45Überprüfen der Dienstedatenbank......................................................................................47
Betriebssystemdienste...........................................................................................................53
Internetinformationsdienste (IIS)............................................................................................58
Hauptdienste von Exchange Server 2003..............................................................................64
Zusätzliche Dienste von Exchange Server 2003....................................................................76
Beenden aller Exchange Server 2003-Dienste auf einem Server..........................................80Bevor Sie beginnen.............................................................................................................81Verfahren............................................................................................................................ 81
Exchange Server 2003 und Active Directory..........................................................................81
Verzeichnisintegration und Exchange Server 2003................................................................83Exchange-Klassen und -Attribute in Active Directory..........................................................83Verzeichnisdienstzugriff......................................................................................................86Lastenausgleich und Failover durch LDAP-Verbindungen..................................................89DSAccess-Topologieerkennung..........................................................................................90Erste Suche und laufende neue Suche...............................................................................92Hartcodierung von DSAccess-Servern................................................................................95DSAccess-Profile................................................................................................................96Angeben des Konfigurationsdomänencontrollers................................................................98Zuweisen von Serverfunktionen durch DSAccess..............................................................99Verzeichniszugriffscache...................................................................................................103Laden von DSAccess........................................................................................................105
Verzeichnisdienstproxy.........................................................................................................108DSProxy-Operationen.......................................................................................................109Verhalten von Exchange Server 2003 vor Service Pack 2 bei Verweisen.........................109Verhalten von Exchange Server 2003 Service Pack 2 bei Verweisen...............................112
SMTP-Kategorisierungsmodul..............................................................................................117Nachrichtenkategorisierung und Active Directory..............................................................118
Empfängeraktualisierungsdienst und Exchange Server 2003..............................................120Aktualisieren von Empfängerobjekten...............................................................................121
Metabase-Aktualisierungsdienst...........................................................................................123DS2MB-Vorgänge.............................................................................................................124
Architektur des Exchange-System-Managers......................................................................124
Integration in MMC...............................................................................................................125Exchange Server 2003-Snap-Ins und Snap-In-Erweiterungen.........................................132Erstellen benutzerdefinierter Exchange-Verwaltungskonsolen.........................................149
Verwalten von Konfigurationsinformationen in Active Directory............................................151Herstellen von Bindungen an einen Domänencontroller...................................................151Die Exchange-Organisation in der Konfigurationsverzeichnispartition..............................153Exchange-System-Manager und Berechtigungseinstellungen..........................................156Aktivieren der Registerkarte „Sicherheit“ für Objekte im Exchange-System-Manager......157Vererbung von Berechtigungen und Exchange-System-Manager....................................159
Verwalten von Exchange-Informationsspeicherressourcen..................................................164
MAPI-basierte Kommunikation..........................................................................................164Über die IExchangeManageStore-Schnittstelle abgerufene Informationen.......................165Exchange-System-Manager und MAPI-basierte Clients...................................................167DAV-basierte Kommunikation............................................................................................167DAV-basierte Kommunikation und virtuelle HTTP-Verzeichnisse......................................168Exchange-System-Manager und das virtuelle Verzeichnis „Exadmin“..............................169Verbinden mit einem bestimmten Exchange-Server.........................................................171Exchange-System-Manager und die Standardwebsite.....................................................172Virtuelles Verzeichnis „Exadmin“ und SSL-Verschlüsselung.............................................173
Anzeigen aller für einen Postfachspeicher oder einen Informationsspeicher für Öffentliche Ordner verfügbaren Informationen....................................................................................175Verfahren.......................................................................................................................... 175
Verbinden mit einem bestimmten Exchange-Server im Exchange-System-Manager...........176Verfahren.......................................................................................................................... 176
Integration in die Windows-Verwaltungsinstrumentation......................................................176
Dienstkonfiguration im Exchange-System-Manager.............................................................180
Nachrichtenroutingarchitektur...............................................................................................182
Nachrichtenroutingtopologie in Exchange Server 2003........................................................184
Nachrichtenverarbeitung in Exchange Server 2003.............................................................187
Nachrichtenrouting unter Exchange Server 2003.................................................................197Nachrichtenrouten und die Verbindungsstatustabelle.......................................................197Initialisieren der Verbindungsstatustabelle........................................................................198Routingmodul und der Dienst Exchange-Routingmodul....................................................199Überprüfen der Verbindungsstatustabelle.........................................................................200Exchange-Routingpfadauswahl........................................................................................217Auswahl des Routingpfads................................................................................................220Dijkstra-Algorithmus des kürzesten Weges.......................................................................221Lastenausgleich bei der Nachrichtenübertragung.............................................................225Lastenausgleich zwischen Routinggruppen......................................................................225Lastenausgleich zwischen Connectors und externen Systemen......................................228Erneutes Routing von Nachrichten anhand von Verbindungsstatusinformationen............229Erneutes Routing von Nachrichten....................................................................................230Erneutes Routing und Adressräume.................................................................................231Connectorwiederherstellung.............................................................................................232Erneutes Routing und Aktivierungszeitpläne.....................................................................233
Verbindungsstatusweitergabe..............................................................................................233Verbindungsstatusalgorithmus..........................................................................................234
Beispiel für einen LSA.......................................................................................................237Verbindungsstatusänderungen und Verbindungsstatusübermittlung................................242Ändern des Routinggruppenmasters.................................................................................244Konflikte zwischen Routinggruppenmastern.....................................................................244
Abwärtskompatibilität mit Exchange Server 5.5...................................................................245Erzeugen der GWART......................................................................................................245Routingprobleme im gemischten Modus...........................................................................246Topologieaktualisierungen.................................................................................................246Unterbrochene Verbindungsstatusübermittlung................................................................247
SMTP-Transportarchitektur..................................................................................................249
Entwurf des SMTP-Diensts..................................................................................................250IIS-Integration (Internetinformationsdienste).....................................................................251Asynchrone Ausführung von Threads...............................................................................252Verarbeiten eingehender SMTP-Verbindungen.................................................................252Beschränken der Anzahl der SMTP-Threads....................................................................254COM-basierte SMTP-Erweiterungen.................................................................................256Ereignisse im SMTP-Transportsubsystem........................................................................256Ereignisverteiler und Ereignisbenachrichtigungen............................................................258Verwaltungsschnittstellen..................................................................................................260Konfigurationseinstellungen und Ereignisbindungen.........................................................260Konfigurationsinformationen in Active Directory................................................................261SMTP-Konfigurationseinstellungen in der Metabasis........................................................266SMTP-Konfigurationsschlüssel.........................................................................................267Direktes Bearbeiten der Metabasis...................................................................................270Registrierung lokaler Domänen.........................................................................................270Registrierung von Ereignissenken....................................................................................271Servererweiterungsobjekte...............................................................................................274
Aktivieren der Option „Direktes Bearbeiten der Metabasis ermöglichen“ im IIS-Manager....275Bevor Sie beginnen...........................................................................................................275Verfahren.......................................................................................................................... 276
Erweitertes Warteschlangenmodul.......................................................................................277Durch das erweiterte Warteschlangenmodul ausgelöste Ereignisse.................................278Nachrichtenwarteschlangen im erweiterten Warteschlangenmodul..................................282Begrenzen der Anzahl von Nachrichten in Warteschlangen..............................................288
SMTP-Transportkomponenten.............................................................................................289Exchange-Kategorisierungsmodul....................................................................................290Verzweigung von Nachrichten...........................................................................................306Inhaltskonvertierung..........................................................................................................307IMAIL................................................................................................................................. 308
TNEF................................................................................................................................. 309Nachrichtenverarbeitung für Öffentliche Ordner................................................................311Optimieren der Leistung des Kategorisierungsmoduls......................................................313Lastenausgleich für globale Kataloge...............................................................................316LDAP-Suchstapel..............................................................................................................318Erneute Kategorisierung von Nachrichten.........................................................................319Alternative Datenströme im Warteschlangenverzeichnis..................................................320Erzwingen der erneuten Kategorisierung..........................................................................322
Informationsspeichertreiber des SMTP-Diensts...................................................................323NTFS-Informationsspeichertreiber....................................................................................325Verschieben des Mailrootverzeichnisses..........................................................................327Exchange-Informationsspeichertreiber..............................................................................328Architektur des Exchange-Informationsspeichertreibers...................................................329Installierbares Dateisystem von Exchange.......................................................................331Übertragung ausgehender Nachrichten............................................................................333Übertragung eingehender Nachrichten.............................................................................338Wiederholte Übertragungsversuche..................................................................................340
SMTP-Protokollerweiterungen..............................................................................................340Protokollereigniskategorien...............................................................................................346Exchange-spezifische SMTP-Protokollerweiterungen.......................................................347Weitere Informationen.......................................................................................................355
Protokollaufzeichnungen, Ereignisprotokollierung und Nachrichtenverfolgung....................355Protokollaufzeichnungen...................................................................................................355Ereignisprotokollierung......................................................................................................356Produktsupport-Protokollierung.........................................................................................357Nachrichtenverfolgung......................................................................................................357
Aktivieren der Diagnoseprotokollierung für den SMTP-Dienst im Exchange-System-Manager.......................................................................................................................................... 358Bevor Sie beginnen...........................................................................................................358Verfahren.......................................................................................................................... 359
Festlegen des Diagnoseprotokolliergrads für MSExchangeTransport-Kategorien auf Produktsupport..................................................................................................................359Bevor Sie beginnen...........................................................................................................359Verfahren.......................................................................................................................... 360Weitere Informationen.......................................................................................................360
Aktivieren der Nachrichtenverfolgung im Exchange-System-Manager.................................360Bevor Sie beginnen...........................................................................................................361Verfahren.......................................................................................................................... 361Referenz........................................................................................................................... 361
X.400-Transportarchitektur...................................................................................................362
Exchange-MTA in der Exchange Server 2003-Architektur....................................................363Exchange-MTA-Kommunikationspartner...........................................................................364Exchange-MTA-Konfigurationseinstellungen in Active Directory.......................................367Interne Exchange-MTA-Architektur...................................................................................372Exchange-MTA-Datenbank...............................................................................................376Ändern des Speicherorts für das MTA-Datenbankverzeichnis..........................................380Gesicherte und ungesicherte Nachrichtenkopien..............................................................381MTA-Datenbank in einem Servercluster............................................................................382Beschädigte Nachrichten in Gatewaywarteschlangen......................................................383Reparieren beschädigter MTA-Datenbanken....................................................................384Leeren der MTA-Datenbank..............................................................................................385Wiedergeben von DAT-Dateien.........................................................................................385Überprüfen der Exchange-MTA-Verarbeitung...................................................................386Überprüfen des Exchange-MTA mithilfe des Systemmonitors..........................................386Exchange-MTA-Ereignisprotokollierung............................................................................391Ereignisprotokollierung im Textformat...............................................................................396Ablaufverfolgungsstufen-Protokollierung...........................................................................396MTACheck-Protokollierung...............................................................................................397Objekt-IDs und Nachrichten-IDs.......................................................................................398
Leeren der MTA-Datenbank.................................................................................................399Bevor Sie beginnen...........................................................................................................399Verfahren.......................................................................................................................... 399Weitere Informationen.......................................................................................................400
Wiedergeben von DAT-Dateien nach einer MTA-Datenbankleerung....................................400Bevor Sie beginnen...........................................................................................................400Verfahren.......................................................................................................................... 400Referenz........................................................................................................................... 401
Wiedergeben von DAT-Dateien nach einer MTA-Datenbankleerung über eine vollständige Wiedergabe.......................................................................................................................401Bevor Sie beginnen...........................................................................................................401Verfahren.......................................................................................................................... 402Weitere Informationen.......................................................................................................403
Wiedergeben von DAT-Dateien nach einer MTA-Datenbankleerung mittels einer Remotewiedergabe...........................................................................................................403Bevor Sie beginnen...........................................................................................................403Verfahren.......................................................................................................................... 404Weitere Informationen.......................................................................................................405
Wiedergeben von DAT-Dateien nach einer MTA-Datenbankleerung mittels inkrementeller Wiedergabe.......................................................................................................................405Bevor Sie beginnen...........................................................................................................406Verfahren.......................................................................................................................... 406Weitere Informationen.......................................................................................................407
MTA-Transportstacks und X.400-Connectors.......................................................................408Nachrichtenübertragungsdienst........................................................................................409RTS (Reliable Transfer Service)........................................................................................416ACSE – Association Control Service Element...................................................................419Darstellungs- und Sitzungsdienste....................................................................................420MTA-Transportstapel.........................................................................................................422Beispiel für die MTA-Kommunikation................................................................................426X.400-Connectors.............................................................................................................427Konfigurieren eines X.400-Connectors.............................................................................427Verbindungsanforderungsinformationen...........................................................................429OSI-Adressinformationen für ausgehende und eingehende Übertragungen.....................430X.400-Adressen................................................................................................................430X.400-Adressräume..........................................................................................................432Konformitätsjahr und Nachrichtenteile..............................................................................434Nachrichtenschleifenerkennung........................................................................................436X.400-Connectorobjecte in Active Directory......................................................................439Ausführen mehrerer X.400-Connectors............................................................................444
Verbinden von Routinggruppen mithilfe von X.400-Connectors...........................................447Lastenausgleich zwischen Routinggruppen......................................................................447Nachrichtenrouting über Exchange-MTAs.........................................................................448SMTP-XAPI-Gateway.......................................................................................................449Exchange-MTA-Nachrichtenübertragung..........................................................................450Verbindungsstatusinformationen und erneutes Routing von Nachrichten.........................452Austauschen von Verbindungsstatusinformationen zwischen Routinggruppen................453
Exchange-MTA in einer Organisation im gemischten Modus...............................................455RPC-basierte MTA-Kommunikation..................................................................................455Auswirkungen auf die RPC-Leistung.................................................................................457RPC-Bindback-Fehler.......................................................................................................458Gateway-Adressroutingtabelle..........................................................................................459Nachrichtenschleifen zwischen Exchange Server 5.5- und Exchange Server 2003-Servern
....................................................................................................................................... 460
Architektur von Gateway-Messaging-Connectors................................................................460
EDK-Connectorarchitektur....................................................................................................462Connectorkomponenten....................................................................................................464Nachrichtenübertragung zu und von Exchange Server 2003............................................472
Übertragung ausgehender Nachrichten............................................................................473Übertragung eingehender Nachrichten.............................................................................474MAPI-Profile für MAPI-Connectors....................................................................................475Nachrichtenkonvertierung.................................................................................................476Adressübersetzung...........................................................................................................477Proxyadressen und Einmaladressen.................................................................................480Probleme bei der Adresszuordnung..................................................................................480Nachrichtenkonvertierung.................................................................................................481Verzeichnissynchronisierung.............................................................................................484Verzeichnissynchronisierung aus einem anderen Messagingsystem in eine Exchange-
Organisation.................................................................................................................. 484Verzeichnissynchronisierung aus einer Exchange-Organisation in ein anderes
Messagingsystem..........................................................................................................486
Öffnen eines Connector-Postfachs mit „Mdbvu32.exe“........................................................488Bevor Sie beginnen...........................................................................................................488Verfahren.......................................................................................................................... 488
Architektur von Connector für Lotus Notes...........................................................................489Nachrichtenübertragung....................................................................................................496Nachrichtenkonvertierung.................................................................................................498Konvertierung des E-Mail-Nachrichtentyps.......................................................................500Zuordnen von E-Mail-Nachrichteneigenschaften..............................................................501Verzeichnissynchronisierung.............................................................................................502
Architektur von Connector für Novell GroupWise.................................................................504Nachrichtenübertragung....................................................................................................512Nachrichtenkonvertierung.................................................................................................515Konvertierung des E-Mail-Nachrichtentyps.......................................................................517Konvertierung von E-Mail-Nachrichteneigenschaften.......................................................518Verzeichnissynchronisierung.............................................................................................520
Architektur des Kalender-Connectors...................................................................................522Frei-/Gebucht-Informationen.............................................................................................522Veröffentlichen von Frei-/Gebucht-Daten..........................................................................523Frei-/Gebucht-Nachrichten................................................................................................523Generieren von Frei-/Gebucht-Daten................................................................................524Veröffentlichen von Frei-/Gebucht-Informationen in Outlook.............................................525Veröffentlichen von Frei-/Gebucht-Informationen in Outlook Web Access und Outlook
Mobile Access................................................................................................................527Suchen von Frei-/Gebucht-Daten.....................................................................................527Veröffentlichungs-Agent für Frei-/Gebucht-Informationen (MadFB)..................................528Bereinigen von Frei-/Gebucht-Daten.................................................................................529Outlook-Startschalter........................................................................................................529Bereinigen mit Outlook Web Access.................................................................................530
Komponenten des Kalender-Connectors..........................................................................531Frei-/Gebucht-Suchen mit Lotus Notes.............................................................................536Frei-/Gebucht-Suchen aus Exchange 2003......................................................................538Frei-/Gebucht-Suchen aus Lotus Notes............................................................................539Frei-/Gebucht-Suchen mit Novell GroupWise...................................................................540Frei-/Gebucht-Suchen aus Novell GroupWise..................................................................544
Prüfen des Vorhandenseins eines Replikats des Frei-/Gebucht-Systemordners für die administrative Gruppe auf einem Server mit Exchange Server.........................................545Bevor Sie beginnen...........................................................................................................545Verfahren.......................................................................................................................... 545
Virtuelle Protokollserver in Exchange Server 2003..............................................................546
IIS-Integration....................................................................................................................... 547Untersuchen der prozessübergreifenden Kommunikation zwischen IIS und dem Microsoft
Exchange-Informationsspeicherdienst...........................................................................548Installierbares Dateisystem von Exchange.......................................................................549Eingehende Nachrichten...................................................................................................550Ausgehende Nachrichten..................................................................................................551Dateisystemsemantik........................................................................................................551ExIPC-Bindungsfunktion...................................................................................................551ExIPC-Protokollstubs........................................................................................................552
MAPI und RPC über HTTP...................................................................................................552RPC über HTTP................................................................................................................553Virtuelles RPC-Verzeichnis...............................................................................................554RPC über HTTP und der Microsoft Exchange-Informationsspeicherdienst.......................555
Einzelheiten zu den Internetprotokollen...............................................................................555HTTP................................................................................................................................. 555WebDAV und XML............................................................................................................557POP3................................................................................................................................ 558IMAP4............................................................................................................................... 561NNTP................................................................................................................................ 565Konfigurationseinstellungen in Active Directory................................................................566Konfigurationseinstellungen in der Metabase...................................................................566Aktualisieren der IIS-Metabase mit DS2MB......................................................................567Hochwassermarken..........................................................................................................567Front-End-Serverarchitektur..............................................................................................568Überlegungen zur Verwendung von Front-End-Servern...................................................569
Exchange ActiveSync und Exchange 2003..........................................................................570Exchange ActiveSync-Protokollarchitektur........................................................................570Versionen des Sync-Protokolls und Geräteunterstützung.................................................572
Befehle des Sync-Protokolls.............................................................................................573Format des Sync-Befehls..................................................................................................574URI.................................................................................................................................... 574HTTP-Header.................................................................................................................... 574HTTP-Nachrichtentext.......................................................................................................575Protokollunabhängige Multicastdaten auf dem Mobilgerät................................................575Exchange ActiveSync-Profil..............................................................................................576Aktuelle Benachrichtigungen.............................................................................................576Aggregatoren....................................................................................................................576
Outlook Mobile Access und Exchange 2003........................................................................577Abhängigkeiten von Outlook Mobile Access.....................................................................578Outlook Mobile Access und .NET......................................................................................578.NET Framework...............................................................................................................578ASP.NET........................................................................................................................... 579Sitzungsverwaltung...........................................................................................................580Geänderte URL-Sitzungs-ID.............................................................................................580ASP.NET-Geräteaktualisierungen.....................................................................................580Architektur von Outlook Mobile Access.............................................................................581Outlook Mobile Access und Microsoft Outlook Web Access-Vorlagen..............................581Outlook Mobile Access-Datenquellen................................................................................582Verzeichniseinstellungen für Outlook Mobile Access........................................................583Outlook Mobile Access und DS2MB..................................................................................585Outlook Mobile Access und die Windows-Registrierung...................................................585Outlook Mobile Access und Web.Config...........................................................................587Outlook Mobile Access-Clientanforderungen....................................................................590Outlook Mobile Access-Sicherheitsarchitektur..................................................................590
Architektur des Exchange-Informationsspeicherdiensts.......................................................591
Exchange-Speicherarchitektur.............................................................................................592Speichergruppen...............................................................................................................594Speichergruppenarchitektur..............................................................................................594Speichergruppenattribute in Active Directory....................................................................597Speicherplatzmindestanforderungen für Speichergruppen...............................................600Datenbanken im Exchange-Informationsspeicher.............................................................600MAPI-Datenbankdatei.......................................................................................................601Streamingdatenbankdatei.................................................................................................601Weitergabe von Eigenschaften.........................................................................................602
Konfiguration und Verwaltung der Größenbeschränkung von Datenbanken........................603Registrierungseinstellungen..............................................................................................604Datenbankgrößenbeschränkung in GB.............................................................................605Warnung für Puffer der Datenbankgröße in Prozent.........................................................605Startzeit für Überprüfung der Datenbankgröße in Stunden nach Mitternacht....................606
Verhalten bei Erreichen der konfigurierten oder lizenzierten Datenbankgrößenbeschränkung....................................................................................606
Lizenzierte Datenbankgrößenbeschränkung.....................................................................607Überlegungen zur Planung für die Wiederherstellung nach Datenverlust.........................608
Architektur von Extensible Storage Engine..........................................................................608Transaktionen...................................................................................................................609ACID-Transaktionen..........................................................................................................609Der Versionsspeicher........................................................................................................610Snapshot-Isolation.............................................................................................................611ESE-Datenbankstruktur.....................................................................................................611Datenbankseiten...............................................................................................................611ECC-Prüfsumme...............................................................................................................612Datenbankkonsistenz und -1018-Fehler...........................................................................613Datenbankstrukturausgleich..............................................................................................615Teilung............................................................................................................................... 616Zusammenführung............................................................................................................616Auffächerung.....................................................................................................................616Indizes............................................................................................................................... 617Langwerte.........................................................................................................................617Datensatzformat................................................................................................................618Spaltendatentypen............................................................................................................618Feste und variable Spalten...............................................................................................619Markierte Spalten..............................................................................................................619
Funktionen des Informationsspeichers.................................................................................620Interaktivität mit anderen Exchange-Diensten...................................................................620Speicherplatzverwaltung...................................................................................................621Datenbankdefragmentierung.............................................................................................622Pufferverwaltung...............................................................................................................623Dynamic Buffer Allocation (DBA).......................................................................................623Der LRU-K-Ersetzungsalgorithmus...................................................................................624
Replikation von Öffentlichen Ordnern...................................................................................625Datenbankstrukturen für Öffentliche Ordner.....................................................................625Replikationsüberblick........................................................................................................626Packen und Entpacken.....................................................................................................627Änderungsnummern..........................................................................................................627Replikationsnachrichtentypen...........................................................................................628Replikationsvorgang..........................................................................................................633Hierarchiereplikation.........................................................................................................633Inhaltsreplikation...............................................................................................................634Abgleichvorgang...............................................................................................................635Abgleicharray.................................................................................................................... 635
Replikationsstatus.............................................................................................................636Replikationsstatusthread...................................................................................................636Replikationsstatusanforderungen......................................................................................637Ändern der Replikatliste....................................................................................................638Hinzufügen eines Replikats...............................................................................................638Löschen eines Replikats...................................................................................................638Replikationsstatustabellen................................................................................................639Standardzeitplan für Replikationsereignisse.....................................................................640Standardreplikationswerte.................................................................................................642
Exchange Server 2003-Clusterarchitektur............................................................................643
Architektur von Windows-Clustern.......................................................................................644Servercluster.....................................................................................................................645Serverclusterarchitektur....................................................................................................646Komponenten des Clusterdiensts.....................................................................................647Cluster-Failover.................................................................................................................653Cluster-Failback................................................................................................................654Clusterquorum..................................................................................................................654Standardquorum...............................................................................................................655Hauptknotensatzquorum...................................................................................................656Clusterressourcen.............................................................................................................657Clusterverwaltung.............................................................................................................657Struktur und Ausführung eines Clusters............................................................................658Erstellen eines Clusters....................................................................................................658Bilden eines Clusters........................................................................................................658Beitreten zu einem Cluster................................................................................................659Verlassen eines Clusters...................................................................................................660Ausfallerkennung..............................................................................................................660
Virtuelle Exchange-Server....................................................................................................662Exchange-Komponenten in einem Cluster........................................................................663Aktiv/Aktiv-Cluster.............................................................................................................665Aktiv/Passiv-Cluster..........................................................................................................666Ressourcenabhängigkeiten...............................................................................................667Microsoft Exchange-Systemaufsichtsdienst......................................................................667Microsoft Exchange-Informationsspeicherdienst...............................................................668Message Transfer Agent...................................................................................................668Protokolle.......................................................................................................................... 668Microsoft Search...............................................................................................................669
Interaktion von Exchange-Clustern......................................................................................669Die Funktionen ExchangeOpen/ExchangeClose..............................................................670Die Funktionen ExchangeOnline und ExchangeOffline.....................................................671ExchangeIsAlive und ExchangeLooksAlive......................................................................672
ExchangeTerminate..........................................................................................................672Erstellen von Ressourcen.................................................................................................672
Clusterspezifische Konfigurationen......................................................................................673Exchange-MTA.................................................................................................................. 673IIS-SMTP-Protokollierung.................................................................................................673AntiAffinityClassNames.....................................................................................................674Öffentliche MAPI-Informationsspeicher.............................................................................675Eseutil............................................................................................................................... 675Installieren von Aktualisierungen.......................................................................................676
How to Disable MTA Monitoring on an Exchange Virtual Server..........................................676Bevor Sie beginnen...........................................................................................................676Verfahren.......................................................................................................................... 677
How to Enable SMTP Logging and Log the Files to a Shared Disk......................................677Bevor Sie beginnen...........................................................................................................677Verfahren.......................................................................................................................... 678
How to Create an HTTP Virtual Server in Exchange System Manager................................678Bevor Sie beginnen...........................................................................................................678Verfahren.......................................................................................................................... 679
How to Create Virtual Directories for an Exchange Virtual Server in a Windows Server Cluster.......................................................................................................................................... 680Bevor Sie beginnen...........................................................................................................681Verfahren.......................................................................................................................... 681Weitere Informationen.......................................................................................................682
How to Create an HTTP Virtual Server Resource for an Exchange Virtual Server in a Windows Server Cluster....................................................................................................682Bevor Sie beginnen...........................................................................................................683Verfahren.......................................................................................................................... 683
Copyright.............................................................................................................................. 683
Technisches Referenzhandbuch für Exchange Server 2003In diesem technischen Referenzhandbuch wird die Systemarchitektur von Microsoft® Exchange Server 2003 vorgestellt. Es enthält eine Übersicht über den Entwurf des Exchange Server 2003-Messagingsystems und zusätzliche spezifischere Angaben, z. B. zu den Dienstabhängigkeiten, zur Integration des Active Directory®-Verzeichnisdiensts, zur Architektur des Exchange-System-Managers, zur Routingarchitektur, zur SMTP-Transportarchitektur, zur X.400-Architektur, zur Architektur des Exchange-Informationsspeichers und zur Clusterarchitektur. Anhand dieser Angaben können Sie eine Exchange-Organisation entwerfen, verwalten und aufgetretene Probleme beheben sowie benutzerdefinierte Lösungen für Administratoren entwickeln.
Dieses ausführliche Referenzhandbuch wurde nicht für Administratoren mit Grundkenntnissen konzipiert und enthält keine Erläuterungen zur Implementierung oder Verwaltung von Exchange Server 2003. Es richtet sich in erster Linie an Microsoft Certified Systems Engineers (MSCEs) und Exchange Server-Fachleute, die ihre Kenntnisse über Exchange Server 2003 umfassend erweitern möchten.
Hinweis: Laden Sie das Technische Referenzhandbuch für Microsoft Exchange Server 2003 herunter, um dieses Dokument zu drucken oder offline zu lesen.
Einführung in das technische Referenzhandbuch für Exchange Server 2003Das technische Referenzhandbuch für Microsoft Exchange Server 2003 wurde für Exchange-Fachleute konzipiert, die umfassende Informationen über die Architektur und Interaktion zwischen den Hauptkomponenten von Microsoft Exchange Server 2003 benötigen.
Welche Informationen bietet dieses Handbuch?In diesem technischen Referenzhandbuch wird die Systemarchitektur von Exchange Server 2003 vorgestellt. Es enthält eine allgemeine Übersicht über den Entwurf des Exchange Server 2003-Messagingsystems und zusätzliche spezifischere Angaben, z. B. zu den Dienstabhängigkeiten, zur Integration des Active Directory-Verzeichnisdiensts, zur
17
Architektur des Exchange-System-Managers, zur Routingarchitektur, zur SMTP-Transportarchitektur, zur X.400-Architektur, zur Architektur des Exchange-Informationsspeichers und zur Clusterarchitektur. Anhand dieser Angaben können Sie eine Exchange-Organisation entwerfen, verwalten und aufgetretene Probleme beheben sowie benutzerdefinierte Lösungen für Administratoren entwickeln.
Dieses ausführliche Referenzhandbuch wurde nicht für Administratoren mit Grundkenntnissen konzipiert und enthält keine Erläuterungen zur Implementierung oder Verwaltung von Exchange Server 2003. Es richtet sich in erster Linie an Microsoft Certified System Engineers (MSCEs) und Exchange-Fachleute, die ihre Kenntnisse über Exchange Server 2003 umfassend erweitern möchten. Im Abschnitt „Einführende Dokumentationen“ weiter unten in dieser Einführung finden Sie eine Liste von Büchern, die Sie vor der Lektüre dieses technischen Referenzhandbuchs konsultieren können.
Der Aufbau des technischen Referenzhandbuchs orientiert sich an den Hauptkomponenten von Exchange Server 2003, und Sie können so gezielt die Kapitel auswählen, die Sie besonders interessieren. Hinweise zur Problembehandlung von Active Directory-Verbindungsfehlern finden Sie unter Exchange Server 2003 und Active Directory , Informationen zu Problemen mit dem SMTP-Dienst unter SMTP-Transportarchitektur. Dieses Handbuch enthält Antworten auf die folgenden Fragen:
Welche Unterschiede weist die Architektur von Exchange Server 2003 im Vergleich zur allgemeinen Architektur eines Client/Server-Messagingsystems auf?
Wie werden die verschiedenen Komponenten von Exchange Server 2003 in das Betriebssystem integriert?
Welche Dienstabhängigkeiten weisen die einzelnen Exchange Server 2003-Komponenten auf?
Welche Komponenten von Exchange Server 2003 kommunizieren in welchen Fällen mit Active Directory?
Mit welchen Arten von Domänencontrollern kommuniziert Exchange Server 2003 zu welchem Zweck?
Über welche Komponenten und Kommunikationsabhängigkeiten verfügt der Exchange-System-Manager?
Wie wird die Nachrichtenübertragung und das Nachrichtenrouting in Exchange Server 2003 verarbeitet?
Welche internen Komponenten des SMTP-Diensts (Simple Mail Transfer Protocol) werden durch Exchange Server 2003 zur Implementierung von Exchange-spezifischen Funktionen ersetzt oder erweitert?
Wie kommuniziert der SMTP-Dienst mit dem Exchange-Informationsspeicher für die Übertragung von eingehenden und ausgehenden Nachrichten genau?
18
Welche Rolle spielt Exchange Message Transfer Agent (MTA) in der Nachrichtenübertragungsarchitektur?
Welche technischen Auswirkungen hat die Bereitstellung eines X.400-Messagingbackbone in einer Exchange Server 2003-Organisation?
Wie werden in Exchange Server 2003 Verbindungen mit Messagingsystemen hergestellt, die nicht auf Exchange basieren, z. B. Lotus Notes oder Novell GroupWise?
Wie sieht die allgemeine Architektur von EDK-Connectors (Exchange Development Kit) aus?
Wie werden Internetmessagingclients durch Exchange Server 2003 unterstützt?
Wie sieht die Architektur von ESE (Extensible Storage Engine) aus, die in Exchange Server 2003 zur Verwaltung des Exchange-Informationsspeichers verwendet wird?
Worin liegen die Hauptaufgaben des Exchange-Informationsspeichers?
Wie werden in Exchange Server 2003 Öffentliche Ordner zwischen Servern in der gleichen Exchange-Organisation repliziert?
Über welche Komponenten kann Exchange Server 2003 in einem Servercluster bereitgestellt werden, und wie wird Exchange Server 2003 in die Architektur des Microsoft Windows-Clusterdiensts integriert?
Für wen ist dieses Handbuch gedacht?Dieses Handbuch enthält wichtige Informationen für Benutzer, die ihre Kenntnisse über Exchange Server 2003 erweitern möchten. Wie weiter oben erwähnt, wurde dieses Handbuch für Messagingconsultants, Systemarchitekten, Administratoren und Spezialisten für Problembehandlung konzipiert, die bereits über fundierte Fachkenntnisse zu Exchange verfügen. Mithilfe der in diesem Handbuch vermittelten technischen Informationen können diese Exchange-Fachleute Lösungen implementieren, die über die Standardmöglichkeiten des Produkts hinausgehen, sowie technische Engpässe und andere Probleme beseitigen.
Dieses Handbuch richtet sich an folgende Exchange-Fachgruppen:
IT-Architekten, die Exchange Server 2003 planen und bereitstellen.
IT-Consultants, die Kunden bei der Bereitstellung und Verwaltung von Exchange Server 2003-Organisationen unterstützen.
Messagingadministratoren, die eine Exchange Server 2003-Organisation betreiben.
Systemadministratoren, die für die Problembehandlung in Messagingsystemen verantwortlich sind.
Systementwickler, die über die Standardmöglichkeiten von Exchange Server 2003 hinausgehende Messaginglösungen erstellen.
19
Einführende DokumentationenLeser, die Exchange Server 2003 noch nicht kennen, sollten zusätzlich zu den Exchange-Onlinebüchern vor der Lektüre dieses Handbuchs die Produktdokumentationen für Windows, Microsoft Office Outlook und Exchange lesen. Die Exchange-Dokumentation ist unter (Exchange Server TechCenter) verfügbar.
Bei diesem technischen Referenzhandbuch für Exchange Server 2003 wird davon ausgegangen, dass Sie folgende Bücher gelesen haben:
Planning an Exchange Server 2003 Messaging System In diesem Buch werden Exchange Server 2003 und die Technologien für Messagingsysteme, einschließlich der Features und Beschränkungen, vorgestellt. Zum Verständnis ist fundiertes Wissen erforderlich.
Exchange Server 2003 Deployment Guide Dieses Buch enthält Installations- und Bereitstellungsinformationen für Administratoren mit guten bis sehr guten Kenntnissen, die eine Bereitstellung von Exchange Server 2003 planen.
Exchange Server 2003 Administration Guide In diesem Buch werden die grundlegenden Konzepte der Exchange Server 2003-Verwaltung erläutert.
Exchange Server 2003 Interoperability and Migration Guide In diesem Buch finden Sie Anweisungen zur Festlegung einer effizienten Strategie für die Umstellung von Exchange-fremden Messagingplattformen, z. B. Lotus Notes und Domino, Novell GroupWise sowie andere Messagingsysteme, auf Exchange Server 2003.
Technische Übersicht über Exchange Server 2003Als Messagingserverplattform verfügt Microsoft Exchange Server 2003 über die gleichen allgemeinen Funktionen wie andere E-Mail-Systeme:
E-Mail-Nachrichten werden auf verlässliche Weise an die gewünschten Empfänger übertragen, unabhängig davon, ob sich die Empfänger auf dem lokalen Server, einem anderen Server in der gleichen Exchange Server 2003-Organisation oder einem anderen Server in einer mit der Organisation verbundenen externen Messagingumgebung befinden.
E-Mail-Nachrichten werden in einem Informationsspeicher auf dem Server gespeichert.
Verschiedene E-Mail-Clients werden für den Zugriff auf Nachrichten oder deren Download unterstützt.
Der Benutzer erhält Informationen über Empfänger in der Organisation über ein Adressbuch oder eine globale Adressliste.
20
Exchange Server 2003 enthält diese und viele andere Funktionen. Diese Funktionen werden jedoch nicht von Exchange Server 2003 bereitgestellt. Exchange Server 2003 ist fest in die durch Microsoft Windows Server 2003 und den Active Directory-Verzeichnisdienst bereitgestellte TCP/IP-Infrastruktur eingebunden. Zum besseren Verständnis der Exchange Server 2003-Architektur sollten Sie sich zuerst mit den TCP/IP-Technologien sowie mit Microsoft Windows Server 2003 und Active Directory vertraut machen.
Zusätzlich sollten Sie über Kenntnisse der folgenden allgemeinen Messagingkonzepte verfügen:
Merkmale des Messagingsystems Hierzu gehören Kenntnisse der typischen Komponenten eines Messagingsystems sowie des allgemeinen Nachrichtenflusses zwischen Servern.
Integration von Active Directory in Exchange Server 2003 Dies beinhaltet Kenntnisse darüber, wie Active Directory in Exchange Server 2003 zur Implementierung der erforderlichen Verzeichnisinfrastruktur verwendet wird.
Messagingverbindungen Hierzu zählen Kenntnisse darüber, wie Exchange Server 2003 Nachrichten von Sendern an Empfänger überträgt.
Nachrichtenspeicher Dies beinhaltet Kenntnisse über Funktion und Aufgabe des Nachrichtenspeichers in einem Messagingsystem.
Unterstützte E-Mail-Clients Hierzu gehören Kenntnisse der verschiedenen Clients und Nachrichtenzugriffsprotokolle, die in einer Exchange Server 2003-Organisation verwendet werden können.
Dieser Abschnitt bildet die Grundlage für die anderen Themen in dieser technischen Referenz. Damit Sie den größmöglichen aus diesem Handbuch ziehen können, sollten Sie mit Windows Server 2003-Technologien vertraut sein.
Weitere Informationen über Windows Server 2003 finden Sie unter Windows Server 2003 Technology Centers.
Exchange Server 2003 als NachrichtenverarbeitungssystemAlle Messagingumgebungen weisen mehrere typische gemeinsame Anforderungen auf. Für alle Messagingsysteme in einer Messagingumgebung ist Folgendes erforderlich:
Ein Nachrichtentransportverfahren
Eine Liste aller Benutzer im Messagingsystem
Ein Speicherort für Nachrichten bis zum Abruf durch den Client
21
Eine Schnittstelle für E-Mail-Clients zur Kommunikation mit einem Server in der Messagingumgebung
Allgemeine Komponenten eines NachrichtenverarbeitungssystemsIn der folgenden Abbildung sind die Komponenten eines Nachrichtenverarbeitungssystems dargestellt.
Komponenten eines Nachrichtenverarbeitungssystems
Exchange Server 2003 implementiert die folgenden Messagingkomponenten:
Verzeichnis Das Verzeichnis enthält Informationen zu den Benutzern des Systems. Diese Informationen werden zum Übertragen von Nachrichten an die gewünschten Benutzer verwendet. Im Verzeichnis wird darüber hinaus der größte Teil der Konfigurationsinformationen über das Nachrichtenverarbeitungssystem gespeichert. Es enthält Informationen zur Konfiguration des Systems und zur Weiterleitung von Nachrichten von einem Messagingserver zu einem anderen Messagingserver. In Exchange Server 2003 stellt Active Directory das Verzeichnis zur Verfügung. Bei vielen Komponenten in Exchange Server 2003 wird ein Verzeichniszugriffsmodul, DSAccess, zur Kommunikation mit Active Directory verwendet. Weitere Informationen zur Exchange Server 2003-Verzeichnisarchitektur finden Sie unter Exchange Server 2003 und Active Directory .
Subsystem für Nachrichtenübertragung Mit dieser Komponente wird ein Routing- und Übertragungsverfahren für E-Mail-Nachrichten implementiert. Nachrichten werden möglicherweise an Empfänger auf demselben Server bzw. auf einem anderen Server in der gleichen Organisation oder an Empfänger im Internet oder in anderen Messagingsystemen gesendet. Das zentrale Transportmodul in Exchange Server 2003 ist das SMTP-Transportmodul (Simple Mail Transfer Protocol), das im SMTP-Dienst
22
implementiert ist, der im Lieferumfang von Windows Server 2003 enthalten ist. Exchange Server 2003 erweitert den SMTP-Dienst für die Implementierung der für Exchange Server 2003 erforderlichen Nachrichtenverarbeitungsfunktionen. Beachten Sie, dass die Nachrichtenübertragung in Exchange Server 2003 vollständig auf dem SMTP-Transportmodul beruht, auch wenn sich Sender und Empfänger auf demselben Server befinden. Weitere Informationen zum SMTP-Transportmodul finden Sie unter SMTP-Transportarchitektur.
Nachrichtenspeicher In Exchange Server 2003 werden im Nachrichtenspeicher, d. h. im Exchange-Informationsspeicher, E-Mail-Nachrichten und andere Objekte in Postfächern und Öffentlichen Ordnern gespeichert. Darüber hinaus enthält er Nachrichtentabellen, die beim Weiterleiten von Nachrichten von Server zu Server vom Transportsubsystem zum temporären Speichern von Nachrichten verwendet werden. Der Exchange-Informationsspeicher ist zur Implementierung der Messagingdatenbanken von der ESE-Technologie (Extensible Storage Engine) abhängig. Weitere Informationen zur Exchange-Informationsspeicherarchitektur finden Sie unter Architektur des Exchange-Informationsspeicherdiensts.
Benutzer-Agent Über den Benutzer-Agent kann auf das Messagingsystem zugegriffen werden. Dies bedeutet, dass es sich beim Benutzer-Agent um den Messagingclient handelt. Exchange Server 2003 unterstützt eine Vielzahl von Messagingclients, einschließlich MAPI-Clients, HTTP-Clients sowie Clients, die POP3, IMAP4 und NNTP (Network News Transfer Protocol) verwenden. Die LDAP-Unterstützung (Lightweight Directory Access Protocol) für die Verzeichnissuche wird dagegen von Active Directory bereitgestellt.
Das Nachrichtenverarbeitungssystem in der NetzwerkinfrastrukturFür die Übertragung einer Nachricht von einem Server auf einen anderen Server in einer Exchange Server 2003-Organisation muss TCP/IP im Netzwerk unterstützt werden. Active Directory und der SMTP-Dienst erfordern TCP/IP. In der folgenden Abbildung sind die für die Systemkommunikation und die Nachrichtenübertragung erforderlichen Komponenten dargestellt. Beachten Sie dabei, dass für bestimmte Komponenten, z. B. Connector für Novell GroupWise, möglicherweise zusätzliche Komponenten benötigt werden, die in dieser Abbildung nicht aufgeführt sind.
23
Netzwerkkomponenten für Exchange Server 2003
Für Exchange Server 2003 sind die folgenden Netzwerkkomponenten erforderlich:
IP und TCP In Exchange Server 2003 wird TCP/IP zur Kommunikation mit anderen Computern im Netzwerk benötigt. In Exchange Server 2003 werden keine anderen Netzwerkprotokolle unterstützt.
DNS In Exchange Server 2003 werden über DNS die IP-Adressen für andere Hosts in einem TCP/IP-Netzwerk aufgelöst, die Domänencontroller und globalen Katalogserver in einer Active Directory-Domäne sowie die E-Mail-Server in anderen Messagingorganisationen gesucht.
DHCP und WINS Für die ordnungsgemäße Funktion von Exchange Server 2003 ist DHCP (Dynamic Host Configuration Protocol) nicht erforderlich. Einige der Netzwerkclients im TCP/IP-Netzwerk benötigen diesen Dienst jedoch möglicherweise. DHCP wird für die automatische Zuweisung einer IP-Adresse zu Computern in einem Netzwerk verwendet. WINS (Windows Internet Name Service) wird dagegen von Microsoft Windows-Clients für die Auflösung von NetBIOS-Namen verwendet. In Netzwerkumgebungen mit Routern, die Broadcasts nicht über Netzwerksegmente weiterleiten, wird WINS zur Auflösung der IP-Adressen für andere Computer im Netzwerk benötigt. Für Exchange Server 2003 ist WINS erforderlich.
Windows Sockets In Exchange Server 2003 werden Windows Sockets für die Bereitstellung von Verbindungspunkten für Netzwerkclients verwendet, über die eine Verbindung mit Diensten auf einem Server hergestellt wird. Bei einem Windows Socket
24
handelt es sich um die mit einer Anschlussnummer kombinierte IP-Adresse eines Hosts zur Identifizierung eines Serverdiensts.
Active Directory Active Directory stellt den Verzeichnisdienst für Exchange Server 2003 bereit.
Internetinformationsdienste (IIS) Exchange Server 2003 stellt über IIS die Internetprotokollunterstützung bereit. Alle Internetprotokolldienste, z. B. HTTP, SMTP oder IMAP4, werden in der Arbeitsumgebung von IIS auf dem Exchange-Server ausgeführt. Weitere Informationen zu IIS finden Sie unter Internetinformationsdienste (IIS).
Sicherheitsteilsystem Exchange Server 2003 verwendet ein Sicherheitsteilsystem von Windows Server 2003 zur Authentifizierung von Benutzern in der Exchange-Organisation. Mit dem Sicherheitsteilsystem wird sichergestellt, dass ausschließlich autorisierte Benutzer auf Postfächer zugreifen oder E-Mail-Nachrichten an angegebene Empfänger senden können.
Windows E/A-Manager Der E/A-Manager des Servers, auf dem Exchange Server ausgeführt wird, verwaltet die Übertragung von Daten zwischen den Festplatten des Servers. Exchange Server 2003 greift über den E/A-Manager auf die Transaktionsprotokolle und Datenbanken zu, die auf der Festplatte des Servers gespeichert sind. Mit dem E/A-Manager werden darüber hinaus die Netzwerkdateisysteme gesteuert, z. B. Server und Client für Microsoft-Netzwerke. In Exchange Server 2003 sind mehrere Dateisystemordner für den Netzwerkzugriff freigegeben. Auf diese Ordner wird über das Microsoft-Netzwerkdateisystem zugegriffen.
VerzeichnisintegrationDie Exchange Server 2003-Informationen in Active Directory umfassen Informationen über Empfänger im Messagingsystem sowie Konfigurationsinformationen über die Messagingorganisation. Active Directory stellt zudem das Sicherheitsteilsystem für Exchange Server 2003 bereit. Durch die Sicherheitsfunktionen von Active Directory wird gewährleistet, dass nur autorisierte Benutzer auf Postfächer zugreifen können und dass ausschließlich autorisierte Administratoren die Exchange-Konfiguration in der Organisation ändern können.
Empfängerobjekte im VerzeichnisEmpfänger in einer Exchange Server 2003-Organisation werden in Active Directory durch Empfängerobjekte dargestellt. Eine Exchange Server 2003-Organisation enthält die folgenden fünf Typen von Empfängerobjekten:
Postfachaktivierte Benutzerkonten Postfachaktivierte Benutzer sind die am häufigsten vertretenen Empfängerobjekte in einer Exchange Server 2003-Organisation.
25
Bei einem postfachaktivierten Benutzer handelt es sich um einen Windows-Benutzer mit einem Postfach auf einem Server, auf dem Exchange Server ausgeführt wird. Ein postfachaktiviertes Benutzerkonto ist ein Active Directory-Objekt, dem eine eindeutige Sicherheits-ID (SID) zugewiesen ist. Über die Sicherheits-ID kann der Benutzer auf Ressourcen in der Active Directory-Domäne zugreifen. Wenn ein Benutzerkonto postfachaktiviert ist, verfügt es über ein Postfach auf einem Server, auf dem Exchange Server ausgeführt wird. Über das Postfach kann der Benutzer unter Verwendung eines unterstützten Clients, z. B. Microsoft Office Outlook, E-Mail-Nachrichten senden und empfangen.
E-Mail-aktivierte Benutzerkonten Ein E-Mail-aktivierter Benutzer verfügt über eine E-Mail-Adresse, jedoch nicht über ein Postfach auf einem Server, auf dem Exchange Server ausgeführt wird. Ein E-Mail-aktiviertes Benutzerkonto verfügt über eine SID und kann auf Ressourcen in der Active Directory-Domäne zugreifen, die zur E-Mail-Aktivierung des Benutzerkontos verwendete E-Mail-Adresse verweist jedoch auf ein Postfach in einem Exchange-fremden oder externen Messagingsystem. E-Mail-aktivierte Benutzerkonten sind in der globalen Adressliste aufgeführt.
E-Mail-aktivierte Kontakte Ein E-Mail-aktivierter Kontakt verfügt über keine SID und daher über kein Exchange-Postfach in der Exchange-Organisation. Dies bedeutet, dass ein E-Mail-aktivierter Kontakt nicht auf Ressourcen in der Domäne zugreifen kann, das Empfängerobjekt jedoch in der globalen Adressliste angezeigt wird. Die an einen Kontakt gesendeten E-Mail-Nachrichten werden an die dem Kontaktobjekt zugeordnete E-Mail-Adresse weitergeleitet.
E-Mail-aktivierte Gruppen Bei einer E-Mail-aktivierten Gruppe handelt es sich um eine Gruppierung von Benutzern, Gruppen und Kontakten, die mit E-Mail-Adressen konfiguriert sind. Sowohl universelle als auch Sicherheitsgruppen können E-Mail-aktiviert werden, die E-Mail-Aktivierung von universellen Gruppen empfiehlt sich jedoch für E-Mail-Zwecke. Eine E-Mail-aktivierte Gruppe wird häufig als Verteilerliste bezeichnet, da ihr eine E-Mail-Adresse zugewiesen ist. Wenn eine Nachricht an die Gruppe gesendet wird, erweitert Exchange Server 2003 die Gruppenmitgliedschaft und leitet die Nachricht an die einzelnen Empfänger weiter. Exchange Server 2003 unterstützt die Verwendung von abfragebasierten Verteilergruppen. Hierbei handelt es sich um Verteilerlisten, deren Mitgliedschaft durch eine LDAP-Abfrage (Lightweight Directory Access Protocol) bestimmt wird.
E-Mail-aktivierte Öffentliche Ordner Bei einem E-Mail-aktivierten Öffentlichen Ordner handelt es sich um einen Öffentlichen Ordner, an den E-Mail-Nachrichten gesendet werden können. Ein E-Mail-aktivierter Öffentlicher Ordner verfügt über eine eindeutige E-Mail-Adresse und kann in der globalen Adressliste angezeigt werden.
Hinweis: Exchange-Empfängerobjekte werden in der Domänenpartition in Active Directory gespeichert. (Active Directory-Partitionen werden auch als Verzeichnispartitionen bezeichnet). Die Domänenpartition enthält alle Objekte in einer bestimmten Domäne
26
und wird auf jeden Domänencontroller in der Domäne, jedoch nicht außerhalb der Domäne repliziert. Die Domänenpartition ist in Abbildung 1.3 dargestellt. Weitere Informationen zur Replikation von Domäneninformationen finden Sie in der Produktdokumentation unter Windows Server 2003 Technology Centers .
Konfigurationsinformationen im VerzeichnisExchange Server 2003 speichert die meisten Konfigurationsinformationen für die Exchange-Organisation in Active Directory. Active Directory enthält ausführliche Informationen über Serverobjekte, Container für administrative und Routinggruppen und alle Exchange-Connectors. Mit diesen Informationen wird die Konfiguration aller Server mit Exchange Server, die Anzahl der Speichergruppen und Informationsspeicher auf jedem Server sowie die Serverkonfiguration der Internetinformationsdienste (IIS) angegeben.
Die Exchange-Konfigurationsinformationen werden in der Konfigurationsverzeichnispartition in Active Directory gespeichert. Einige der in der Konfigurationspartition gespeicherten Informationen sind in der folgenden Abbildung dargestellt. Da Active Directory die Konfigurationspartition zwischen allen Domänen in der Gesamtstruktur repliziert, wird auch die Exchange-Organisation in der Gesamtstruktur repliziert. Die Konfigurationspartition kann jedoch nicht außerhalb der Gesamtstruktur repliziert werden. Dies bedeutet, dass sich eine Exchange-Organisation nicht über mehrere Gesamtstrukturen erstrecken kann. Es ist jedoch möglich, Topologien mit mehreren Gesamtstrukturen in einer Exchange-Organisation zu implementieren. Weitere Informationen zum Wiederherstellen von Exchange-Topologien mit mehreren Gesamtstrukturen finden Sie unter Exchange Server 2003 Deployment Guide .
Anzeigen von Exchange-Informationen in Active Directory über „ADSIEDIT.MSC“
27
Exchange-Klassen und -Attribute in Active DirectoryZusätzlich zu den in der Domänen- und Konfigurationspartition gespeicherten Informationen werden in Exchange Server 2003 Informationen auch in der Schemapartition gespeichert. Mit dem Active Directory-Schema werden alle Objektklassen definiert, die im Verzeichnis erstellt werden können, sowie alle Attribute, die jedem Klassenobjekt zugewiesen werden können. Vor der Installation eines Exchange Server 2003-Servers in einer Gesamtstruktur muss das Active Directory-Schema um die Exchange-spezifischen Objekte und Attribute erweitert werden. Die Active Directory-Schemapartition und einige Exchange-spezifische Objekte sind in Abbildung weiter oben dargestellt.
VerzeichniszugriffsarchitekturDie Verbindung zwischen Exchange Server 2003 und Active Directory ist von höchster Bedeutung für einen zuverlässigen Serverbetrieb. In Exchange Server 2003 werden die folgenden beiden primären Komponenten verwendet, um nach Active Directory-Domänencontrollern zu suchen und mit diesen zu kommunizieren:
DSAccess Mit dieser Komponente wird der Zugriff anderer Exchange-Komponenten auf Active Directory gesteuert. DSAccess liest die Active Directory-Topologie, ermittelt Domänencontroller und globale Katalogserver und verwaltet eine Liste gültiger Verzeichnisserver, die für die Verwendung durch Exchange-Komponenten geeignet sind. Zusätzlich enthält DSAccess einen Cache im Arbeitsspeicher, der Active Directory durch Verringerung der benötigten LDAP-Anforderungen einzelner Komponenten an Active Directory-Server entlastet. Für die Weiterleitung von Nachrichten wird beim Transport beispielsweise DSAccess zum Abrufen von Informationen über die Connectoranordnung verwendet. Im SMTP-Transportmodul wird DSAccess darüber hinaus zum Auflösen von Empfängerinformationen verwendet. Dadurch können Nachrichten an die Server weitergeleitet werden, auf denen sich die Postfächer befinden.
DSProxy Diese Komponente stellt einen Adressbuchdienst für MAPI-Clients bereit, auf denen Outlook 2002 Service Release 1 (SR-1) und ältere Versionen ausgeführt werden. In Exchange 5.5 und älteren Versionen wurde ein Verzeichnisdienst implementiert, sodass Clients die globale Adressliste durch Abfragen des Servers mit Exchange Server anzeigen konnten. In Exchange 2000 Server und Exchange Server 2003 wird dieser Adressbuchdienst von DSProxy emuliert.
Hinweis: DSProxy (Directory Service Proxy) verweist Microsoft Outlook 2003 direkt an einen globalen Katalogserver. Im Gegensatz zu älteren Versionen von Outlook muss bei Outlook 2003 auf dem Server, auf dem Exchange Server ausgeführt wird, keine Verzeichnisproxykomponente vorhanden sein.
28
Ausführliche Informationen zu DSAccess und DSProxy finden Sie unter Exchange Server 2003 und Active Directory .
NachrichtentransportDie Hauptfunktion eines Nachrichtenverarbeitungssystems besteht in der Übertragung von Nachrichten von einem Messagingserver auf einen anderen Messagingserver. Die Nachrichtenübertragung kann dabei auf dem gleichen Server, zwischen Exchange Server 2003-Servern in der gleichen Organisation, zwischen Servern mit Exchange Server und Internethosts oder zwischen Servern mit Exchange Server und externen Messagingsystemen erfolgen. In allen Fällen werden die E-Mail-Nachrichten mit dem Exchange Server 2003-Nachrichtentransportmodul weitergeleitet und übertragen.
NachrichtenroutingarchitekturIn einer Exchange Server 2003-Organisation werden alle Nachrichten mithilfe von SMTP weitergeleitet. SMTP wird zudem von allen Internetmessagingservern unterstützt. Wenn über einen Server mit Exchange Server eine Nachricht an einen anderen Messagingserver gesendet wird, der nur das X.400-Messagingprotokoll unterstützt, wird die Nachricht über die SMTP-Komponente in Exchange Server 2003 weitergeleitet. Hierzu enthält die SMTP-Komponente mehrere Unterkomponenten.
Bei jeder Nachrichtenübertragung auf einem Server, auf dem Exchange Server 2003 ausgeführt wird, werden die folgenden Komponenten verwendet:
SMTP-Dienst Der SMTP-Dienst ist für die SMTP-Kommunikation zwischen SMTP-Remotehosts und SMTP-Remoteclients zuständig. Mit dem Dienst werden die in Exchange Server 2003 unterstützten SMTP-Befehle implementiert.
Informationsspeichertreiber Der Informationsspeichertreiber ermöglicht die Kommunikation zwischen dem SMTP-Dienst und dem Exchange-Informationsspeicher, um die über den SMTP-Dienst übertragenen Nachrichten zu speichern. Über den Informationsspeichertreiber werden außerdem die Nachrichten für lokale Empfänger übermittelt.
Erweitertes Warteschlangenmodul Mit dem erweiterten Warteschlangenmodul werden die Warteschlangenverwaltung und -logik für die Übermittlung, Weiterleitung und Weitergabe von Nachrichten bereitgestellt.
Kategorisierungsmodul Das Kategorisierungsmodul stellt Kategorisierungsdienste für eingehende und ausgehende Nachrichten zur Verfügung. Darüber hinaus wird mit dieser Komponente die Verteilerliste mithilfe von LDAP und Active Directory aufgegliedert.
29
Routingmodul Mit dem Routingmodul wird die erforderliche Routinglogik für die Übertragung ausgehender Nachrichten auf den korrekten Messagingconnector oder virtuellen SMTP-Server bereitgestellt.
Warteschlangen-Manager Der Warteschlangen-Manager steuert Verbindungswarteschlangen. In Verbindungswarteschlangen werden Nachrichten gespeichert, die zu einem späteren Zeitpunkt an das nächste Remoteziel übertragen werden.
Ausführliche Informationen zur Nachrichtenroutingarchitektur und zu den Beziehungen zwischen den einzelnen Komponenten finden Sie unter Nachrichtenroutingarchitektur.
Nachrichtenrouting mit RoutinggruppenExchange Server 2003 verwaltet über Routinggruppen die Nachrichtenübermittlung in einer Exchange-Organisation. Bei einer Routinggruppe handelt es sich um eine Gruppierung von Servern, auf denen Exchange Server ausgeführt wird und die über permanente Netzwerkverbindungen verbunden sind.
Die Nachrichtenübermittlung in einer einzelnen Routinggruppe weist die folgenden Merkmale auf:
Punkt-zu-Punkt-Übermittlung aller Nachrichten In einer einzelnen Routinggruppe werden Nachrichten immer direkt zwischen zwei Servern übermittelt, auf denen Exchange Server ausgeführt wird. Dabei befindet sich der Sender auf dem einen Server, der Empfänger auf dem anderen Server. Nachrichten werden nie über mehrere Server weitergeleitet.
Übermittlung aller Nachrichten zwischen Exchange Server 2003-Servern mithilfe von SMTP Exchange Server 2003-Server übermitteln Nachrichten an andere Exchange Server 2003-Server in der gleichen Routinggruppe immer mithilfe von SMTP.
Übermittlung von Nachrichten unmittelbar nach dem Empfang der Nachrichten Die Nachrichtenübermittlung in einer Routinggruppe kann zeitlich nicht geplant werden. Wenn einer der Server mit Exchange Server in einer Routinggruppe offline ist, werden alle an diesen Offlineserver zu sendenden Nachrichten auf den anderen Servern in der Routinggruppe in einer Warteschlange gespeichert.
Automatische Konfiguration der Nachrichtenübermittlung zwischen Exchange Server 2003-Servern in der gleichen Routinggruppe Administratoren können den Nachrichtenfluss in einer Routinggruppe nicht ändern.
Die Nachrichtenübermittlung in einer Routinggruppe ist in der folgenden Abbildung dargestellt.
30
Nachrichtenrouting in einer einzelnen Routinggruppe
Exchange Server 2003 unterstützt die Verwendung von mehreren Routinggruppen. Die Nachrichtenübermittlung zwischen Routinggruppen weist die folgenden Merkmale auf:
Zwischen den Routinggruppen müssen Routinggruppenconnectors konfiguriert werden.
Alle zwischen den Routinggruppen gesendeten Nachrichten werden über Bridgeheadserver in jede Routinggruppe geleitet.
Die Nachrichtenübermittlung zwischen Routinggruppen kann konfiguriert werden. Die Konfigurationsoptionen umfassen die Planung der Nachrichtenübermittlung, die Begrenzung der Nachrichtengröße sowie die Einschränkung von Benutzern oder Gruppen hinsichtlich des Sendens von Nachrichten über den Connector.
In der folgenden Abbildung ist das Nachrichtenrouting zwischen mehreren Routinggruppen dargestellt.
31
Nachrichtenrouting zwischen mehreren Routinggruppen
Exchange Server 2003 unterstützt die folgenden drei Routinggruppenconnectors:
Routinggruppenconnector Der Routinggruppenconnector empfiehlt sich als Connector für die Verbindung von Routinggruppen in der gleichen Exchange-Organisation. Mit diesem Connector werden Nachrichten mit SMTP auf andere Server übertragen, auf denen Exchange Server 2003 ausgeführt wird. Der Routinggruppenconnector kann ausschließlich zur Verbindung von Routinggruppen verwendet werden.
SMTP-Connector Der SMTP-Connector erstellt eine Messagingroute zwischen zwei Routinggruppen oder zwischen einer Routinggruppe und einem Exchange-fremden SMTP-Host. Obwohl der Routinggruppenconnector und der SMTP-Connector SMTP als Transportprotokoll verwenden, verfügt der SMTP-Connector über zusätzliche Funktionen, da er für die Verbindung einer Exchange-Organisation mit einem beliebigen SMTP-Server eingesetzt werden kann.
X.400-Connector Der X.400-Connector erstellt eine X.400-Messagingroute zwischen zwei Routinggruppen oder zwischen einer Routinggruppe und einem X.400-System. Wie der Routinggruppenconnector und der SMTP-Connector kann auch ein X.400-Connector zur Verbindung von Exchange-Routinggruppen verwendet werden. In der Regel werden X.400-Connectors nur zur Anbindung anderer X.400-Messagingsysteme verwendet.
Exchange Server 2003 unterstützt die folgenden optionalen Connectors für die Verbindung der Organisation mit Exchange-fremden Messagingsystemen:
32
Exchange Connector für Lotus Notes Exchange Connector für Lotus Notes wird für das Nachrichtenrouting und die Verzeichnissynchronisierung zwischen einer Exchange-Organisation und einem Lotus Notes-Messagingsystem verwendet.
Exchange Connector für Novell GroupWise Exchange Connector für Novell GroupWise wird für das Nachrichtenrouting und die Verzeichnissynchronisierung zwischen einer Exchange-Organisation und einem Novell GroupWise-Messagingsystem verwendet.
Exchange Kalender-Connector Exchange Kalender-Connector wird für den Austausch von Frei-/Gebucht-Informationen zwischen einer Exchange-Organisation und einem Lotus Notes- oder Novell GroupWise-Messagingsystem verwendet.
Exchange-NachrichtenspeicherExchange Server 2003 unterstützt die Verwendung von zwei Informationsspeichertypen: Postfachspeicher und Informationsspeicher für Öffentliche Ordner. Bei jedem Informationsspeicher handelt es sich um eine logische Datenbank, die zwei Datenbankdateien enthält. Die erste Datei ist die Streamingdatenbank-Datei (STM-Datei), in der Nachrichten mit Internetformatierung gespeichert werden, z. B. mit Inhalten im MIME-Format (Multipurpose Internet Mail Extensions). Alle Nachrichten mit Internetformatierung, die über einen beliebigen Client, mit Ausnahme von MAPI-Clients, an den Informationsspeicher gesendet werden, sind in dieser Datei gespeichert. Die zweite Datei ist die MAPI-Datenbankdatei (EDB-Datei), die alle über MAPI an den Informationsspeicher übermittelten Nachrichten sowie die Datenbanktabellen enthält, über die Postfächer, Nachrichten, Ordner und Anlagen definiert werden. Die Eigenschaften von Nachrichten mit Internetformatierung werden an die MAPI-Datenbank weitergeleitet, sodass die Nachrichten im Posteingang der MAPI-Clients aufgeführt werden. Mit anderen Worten, die STM-Datei enthält den Inhalt der E-Mail-Nachrichten mit Internetformatierung, z. B. UUENCODE oder MIME, auf den durch die entsprechende EDB-Datei verwiesen wird. Dies bedeutet, dass die Streamingdatenbank-Datei und die MAPI-Datenbankdatei, aus denen sich eine bestimmte Datenbank zusammensetzt, nicht getrennt werden können.
Exchange Server 2003-DatenbanktechnologieIn Exchange werden transaktionsbasierte Datenbanken über ESE (Extensible Storage Engine) verwaltet. Durch die Verwendung von Write-Ahead-Transaktionsprotokolldateien wird sichergestellt, dass Exchange-Daten effizient verarbeitet werden. Durch den transaktionsorientierten Exchange-Informationsspeicher wird eine maximale Wiederherstellbarkeit gewährleistet. Eine Transaktion kann mehrere Aktionen enthalten, die Transaktion wird jedoch erst übermittelt, wenn alle Aktionen erfolgreich abgeschlossen wurden. Wenn ein Teil einer Transaktion nicht vollständig abgeschlossen werden kann, wird
33
die gesamte Transaktion zurückgesetzt und nicht an die Datenbank übermittelt. Weitere Informationen zur Transaktionsverarbeitung in Exchange Server 2003 finden Sie unter Architektur des Exchange-Informationsspeicherdiensts.
Informationsspeicher und SpeichergruppenDer Exchange-Informationsspeicher kann in mehrere Speichergruppen und Informationsspeicher aufgeteilt werden. Eine Speichergruppe ist eine Gruppe von Datenbanken, die über ein gemeinsames Transaktionsprotokoll verfügen. Ein Informationsspeicher ist eine Datenbank mit dem Inhalt eines Postfachs oder eines Öffentlichen Ordners. In Exchange Server 2003 können Sie auf jedem Server, auf dem Exchange Server ausgeführt wird, bis zu vier Speichergruppen konfigurieren. Jede Speichergruppe kann bis zu fünf Informationsspeicher enthalten. Exchange Server 2003 enthält darüber hinaus eine zusätzliche dedizierte Speichergruppe für die Wiederherstellung. Die Speichergruppe für die Wiederherstellung kann zur Wiederherstellung von Postfächern oder Informationsspeichern verwendet werden. Die anderen Informationsspeicher bleiben dabei online. Weitere Informationen zu Speichergruppen und zur Speichergruppe für die Wiederherstellung finden Sie unter Architektur des Exchange-Informationsspeicherdiensts.
In der folgenden Abbildung ist eine mögliche Konfiguration für Speichergruppen und Informationsspeicher auf einem Server dargestellt, auf dem Exchange Server ausgeführt wird.
Informationsspeicher und Speichergruppen auf einem Server, auf dem Exchange Server ausgeführt wird
34
Der Hauptgrund für die Bereitstellung von mehreren Speichergruppen und Informationsspeichern besteht in der Verringerung der Größe jeder einzelnen Datenbank, während dennoch auf einem Server viele Benutzer arbeiten können. Durch die Bereitstellung mehrerer kleinerer Informationsspeicher wird die Sicherung und Wiederherstellung von Exchange Server optimiert. Da alle Informationsspeicher in einer Speichergruppe auf ein gemeinsames Transaktionsprotokoll zugreifen, sollte jede Speichergruppe in ihrer Gesamtheit gesichert werden. Wenn in der Sicherungsinfrastruktur mehrere Sicherungsdatenströme unterstützt werden, können mehrere Speichergruppen gleichzeitig gesichert werden. Wenn Daten auf dem Server, auf dem Exchange Server ausgeführt wird, wiederhergestellt werden müssen, wird jeder Informationsspeicher einzeln wiederhergestellt. Bei der Wiederherstellung der einzelnen Informationsspeicher können Sie den entsprechenden Informationsspeicher bereitstellen und für Benutzer verfügbar machen.
Hinweis: Exchange Server 2003 unterstützt eine dedizierte Speichergruppe für die Wiederherstellung. Dadurch können Datenbanken wiederhergestellt werden, während Benutzer gleichzeitig mit den ursprünglichen Datenbanken verbunden sind. Über die Speichergruppe für die Wiederherstellung können Sie einzelne Postfächer wiederherstellen, ohne dass nicht betroffene Benutzer vom Server abgemeldet werden müssen.
Benutzeragents in einer Exchange Server 2003-OrganisationBenutzer-Agents sind Messagingclients, über die Empfänger auf ihre Postfächer auf dem Server mit Exchange Server zugreifen. Exchange Server 2003 unterstützt mehrere unterschiedliche Clientzugriffsprotokolle. In der folgenden Tabelle sind die unterstützten Messagingprotokolle aufgeführt:
35
Unterstützte Messagingprotokolle in einer Exchange Server 2003-Organisation
Protokoll Beschreibung
MAPI MAPI-Clients stellen die meisten Funktionen zur Verfügung. Mit einem MAPI-Client wie Outlook können Sie auf den Inhalt aller Ordner in einem Postfach und im Standardinformationsspeicher für Öffentliche Ordner zugreifen. MAPI-Clients stellen über RPC eine Verbindung mit dem Server her, auf dem Exchange Server ausgeführt wird. Exchange Server 2003 unterstützt darüber hinaus RPC über HTTP unter Windows Server 2003. Windows Server 2003 stellt die Infrastruktur für RPC über HTTP bereit. Die Protokollkapselung erfolgt unabhängig von Client und Server. Weitere Informationen zu RPC über HTTP finden Sie im Microsoft Knowledge Base-Artikel 833401 „How to configure RPC over HTTP on a single server in Exchange Server 2003 “.
HTTP Exchange stellt über HTTP den Zugriff auf den Nachrichtenspeicher über Outlook Web Access, Exchange ActiveSync und Outlook Mobile Access bereit.
POP3 POP3 ist ein Standardprotokoll zum Abrufen von E-Mails, über das auf Exchange zugegriffen werden kann. Benutzer können über POP3 auf Nachrichten im Ordner Posteingang in ihren Postfächern zugreifen.
IMAP4 IMAP4 ist ein flexibles Protokoll zum Abrufen von E-Mails. Über einen IMAP4-Client können Sie Nachrichten auf dem Server verwalten. Sie können Nachrichten zwischen Ordnern verschieben und den Inhalt von Nachrichten in einer Vorschau anzeigen, bevor Sie eine Nachricht vollständig oder einen ausgewählten Teil einer Nachricht, z. B. eine Anlage, downloaden.
36
Protokoll Beschreibung
NNTP NNTP wird für den Zugriff auf Newsgroups verwendet. Exchange kann so konfiguriert werden, dass Bereiche der Hierarchie von Öffentlichen Ordnern veröffentlicht und für NNTP-Clients verfügbar werden.
Dienstabhängigkeiten in Exchange Server 2003Microsoft Exchange Server 2003 ist ein Client/Server-Messagingsystem, bei dem Prozesse aktiver Server mit Clientprozessen interagieren. Die Serverprozesse können in der Programmgruppe Verwaltung im Tool Dienste angezeigt werden. In der Microsoft Windows-Terminologie werden Serverprozesse als Dienste bezeichnet. Der Name der meisten Exchange Server-Dienste beginnt mit „Microsoft Exchange“. Ein gutes Beispiel dafür ist der Microsoft Exchange-Informationsspeicherdienst.
In einem Client/Server-System findet der größte Teil der Verarbeitung direkt auf dem Server statt. Serverdienste nehmen Anforderungen und Daten von Clients an, verarbeiten die Anforderungen, speichern die Daten und senden die Verarbeitungsergebnisse zurück an die Clients. Bei Microsoft Office Outlook handelt es sich um einen Client, genauer gesagt um einen Messagingclient. Mit einem Messagingclient wird im Wesentlichen eine Benutzeroberfläche bereitgestellt, über die Benutzer das Messagingsystem auf intuitive Weise verwenden können. Der Exchange-System-Manager ist auch ein Client. Über die Oberfläche dieses Clients können Administratoren eine Exchange Server 2003-Organisation verwalten. Darüber hinaus sind Serverdienste wiederum Clients für andere Serverdienste. So muss beispielsweise der SMTP-Dienst (Simple Mail Transfer Protocol) mit dem Exchange-Informationsspeicherdienst kommunizieren, um auf E-Mail-Nachrichten auf einem Server zuzugreifen, auf dem Exchange Server ausgeführt wird. Jeder Dienst in Exchange Server 2003 hat eine bestimmte Funktion. Durch die Interaktion aller Dienste miteinander und mit den Diensten des Betriebssystems entsteht eine funktionstüchtige Messagingplattform.
Zum besseren Verständnis der Funktion von Exchange Server 2003 als Client/Server-System sind gründliche Kenntnisse der folgenden Komponenten sowie ihrer Abhängigkeiten und Interaktionen untereinander erforderlich:
Dienststeuerungs-Manager und Architektur der Windows-Dienste Service Control Manager (SCM – Dienststeuerungs-Manager) ist die Hauptkomponente in der Architektur der Windows-Dienste, da über diese zentrale Komponente alle unter Windows ausgeführten Dienste und Gerätetreiber verwaltet werden. Über den SCM können Dienste, jedoch keine Gerätetreiber gesteuert werden. Mit dem Dienststeuerungs-
37
Manager werden beispielsweise Gerätetreiber je nach Abhängigkeitsstrukturen in einer festgelegten Reihenfolge gestartet, können jedoch nicht beendet werden. Windows-Dienste können dagegen in der Programmgruppe Verwaltung im Tool Dienste gestartet und beendet werden. Wenn Sie das Tool Dienste verwenden, interagieren Sie mit dem SCM-Prozess.
Betriebssystemdienste Im Betriebssystem werden zahlreiche erforderliche Dienste bereitgestellt, z. B. der RPC-Dienst (Remote Procedure Call) und der Security Support Provider NTLM.
Internetinformationsdienste Internetinformationsdienste (IIS) ist ein wichtiger Prozess, der auf jedem Server ausgeführt werden muss, auf dem Exchange 2003 ausgeführt wird. In Exchange Server 2003 werden POP3- und IMAP4-Dienste zu IIS hinzugefügt und der SMTP-Dienst, der NNTP-Dienst sowie der WWW-Dienst erweitert.
Exchange-Hauptdienste Für die Ausführung als Messagingsystem enthält Exchange Server 2003 mehrere Dienste, die nicht Bestandteil des Betriebssystems oder von IIS sind. Die Hauptdienste von Exchange Server 2003 müssen auf jedem Exchange-Server ausgeführt werden. In diesem Abschnitt werden alle Hauptdienste ausführlich vorgestellt.
Zusätzliche Exchange-Dienste Exchange Server 2003 kann für spezifische Aufgaben konfiguriert werden. Exchange Server 2003 kann beispielsweise für die Implementierung eines dedizierten Postfachservers oder eines dedizierten Bridgeheadservers verwendet werden. Je nach Funktion des Servers werden möglicherweise zusätzliche Exchange-Dienste benötigt, z. B. Messagingconnectors. Die Exchange-Dienste, die nur in bestimmten Fällen erforderlich sind, gelten als zusätzliche Dienste.
Dieser Abschnitt enthält eine Übersicht über Betriebssystemdienste und Exchange-spezifische Dienste, die ausgeführt werden müssen, damit ein vollfunktionsfähiger Exchange Server 2003-Server betrieben werden kann. Es wird davon ausgegangen, dass Sie mit der Microsoft Windows Server 2003-Plattform, Netzwerkdiensten und Active Directory sowie den Exchange Server 2003-Verwaltungskonzepten vertraut sind. Zusätzliche Informationen zu Windows Server 2003 finden Sie unter Windows Server 2003 Technology Centers ). Weitere Informationen zum Verwalten von Exchange Server 2003 finden Sie unter Exchange Server 2003 Administration Guide .
Grundlagen zur Architektur der Windows-DiensteWindows-Dienste, auch als Dienstanwendungen bezeichnet, sind Anwendungen, die auf Windows-Computern ausgeführt werden, unabhängig davon, ob Benutzer angemeldet sind. Ein Windows-Dienst beinhaltet eine ausführbare Datei, ein Verzeichnis zum Speichern von Anwendungskomponenten sowie Registrierungseinstellungen zur Definition der
38
Dienstparameter. Mit dem Windows-Dienst wird eine programmatische Schnittstelle implementiert, über die der SCM den Dienst steuern kann. Ein Windows-Dienst kann beim Starten des Systems automatisch oder über ein Dienststeuerungsprogramm manuell gestartet werden. Ein Dienststeuerungsprogramm ist eine Anwendung, die einen Dienst mithilfe von SCM-Funktionen steuert. Das Tool Dienste und die Befehlszeilenprogramme net.exe und SC.exe sind beispielsweise Dienststeuerungsprogramme.
In der folgenden Abbildung ist die Architektur der Windows-Dienste dargestellt.
Beziehungen zwischen dem Dienststeuerungsprogramm, dem Dienststeuerungs-Manager und den Windows-Diensten
Hinweis: Der SCM-Prozess ist ein RPC-Serverdienst. Dienststeuerungsprogramme können lokal oder über das Netzwerk mithilfe von RPCs mit dem SCM-Prozess kommunizieren, um Dienste auf Remotecomputern zu steuern.
Funktionen des Dienststeuerungs-ManagersSCM, auch als Dienstcontroller bezeichnet, ist ein generischer Windows-Prozess, mit dem zahlreiche dienstbezogene Aufgaben ausgeführt werden. Diese Aufgaben werden in den folgenden Abschnitten ausführlich behandelt.
Verwalten einer Datenbank mit installierten DienstenDer Dienststeuerungs-Manager verwaltet eine Datenbank mit allen installierten Diensten, einschließlich einer Liste aller Dienste und Gerätetreiber, die für den erfolgreichen Start von
39
Windows geladen werden müssen. Bei der Installation zusätzlicher Dienste, z. B. von Exchange Server 2003-Diensten, auf dem Server werden in der Dienstedatenbank neue Einträge eingefügt. SCM verwaltet diese Datenbank unter folgendem Registrierungspfad:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
Die Dienstedatenbank enthält einen Schlüssel für jeden installierten Dienst und Treiber. Der Name des Schlüssels entspricht dem Namen des Diensts, der bei der Installation des Diensts mit einem Dienstkonfigurationsprogramm angegeben wurde. MSExchangeIS ist beispielsweise der Name des Microsoft Exchange-Informationsspeicherdiensts, und MSExchangeSA bezeichnet den Microsoft Exchange-Systemaufsichtsdienst. Die maximale Länge eines Dienstnamens beträgt 256 Zeichen.
In der folgenden Abbildung sind mehrere Exchange-spezifische Diensteinträge in der Registrierung dargestellt.
Exchange-spezifische Diensteinträge in der Registrierung
Hinweis: Die Namen, die bei Verwendung des Tools Dienste angezeigt werden, sind die Anzeigenamen der Windows-Dienste. MSExchangeSA wird beispielsweise als Microsoft Exchange-Systemaufsicht angezeigt. Der Anzeigename ist im REG_SZ-Wert DisplayName definiert und befindet sich unter: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<service name>.
40
Sperren und Freigeben der DienstedatenbankDie Dienstedatenbank muss bei der SCM-Initialisierung vom SCM gesperrt werden, damit der Zugriff auf die Konfigurationsinformationen serialisiert werden kann. Der SCM sperrt die Dienstedatenbank beispielsweise vor dem Starten eines Diensts, sodass die Dienstkonfiguration während des Starts des Diensts nicht geändert werden kann. Nach dem Starten des Diensts wird die Sperre vom SCM wieder aufgehoben. Dienstkonfigurationsprogramme müssen ebenfalls mit dem SCM kommunizieren, um vor der Neukonfiguration eines Diensts eine Sperre und anschließend die Aufhebung der Sperre anzufordern. Mit dem Befehlszeilenprogramm SC.exe können Sie über den Befehl sc QueryLock in Erfahrung bringen, ob die Dienstedatenbank gesperrt ist.
Hinweis: Beachten Sie beim Verwalten von Diensten mit einer sehr langen Startzeit, dass der Starttyp oder andere Konfigurationseinstellungen während des Dienststarts nicht neu konfiguriert werden können, da die Dienstedatenbank vom SCM gesperrt wird. Konfigurationsänderungen können nur vor oder nach dem Starten eines Diensts vorgenommen werden.
Aufführen der installierten DiensteDer SCM-Prozess liest jeden Registrierungsschlüssel in der Dienstedatenbank, um für jeden Dienst einen Dienstdatensatz zu erstellen. Der Dienstdatensatz enthält den Dienstnamen, den Starttyp, den Dienststatus (z. B. den aktuellen Status des Diensts und zulässige Steuerungscodes) sowie einen Zeiger auf die Liste der Abhängigkeiten. Mithilfe der Dienstdatensätze ermittelt der SCM anhand des aktuellen Status und der Abhängigkeiten der Dienste die jeweils gültigen Vorgänge für die Dienste. Der Systemaufsichtsdienst kann beispielsweise nicht mit dem Tool Dienste beendet werden, wenn ein anderer von der Systemaufsicht abhängiger Dienst ausgeführt wird, z. B. der Microsoft Exchange-Informationsspeicherdienst.
Starten, Beenden, Anhalten oder Fortsetzen von DienstenFür die Ausführung von allgemeinen Aufgaben, z. B. Starten oder Beenden eines Diensts, kommuniziert der SCM mit den von ihm gesteuerten Diensten. Windows-Dienste können vom SCM automatisch beim Systemstart oder manuell bei Anforderung durch ein Dienststeuerungsprogramm gestartet werden. Wenn ein automatisch zu startender Dienst jedoch von einem manuell zu startenden Dienst abhängt, wird auch der manuell zu startende Dienst automatisch gestartet. Mit dem Starttyp kann auch festgelegt werden, dass ein Dienst deaktiviert ist. In diesem Fall kann er nicht gestartet werden. Sie können einen automatisch oder manuell zu startenden Dienst nicht starten, wenn der entsprechende Dienst von einem deaktivierten Dienst abhängt. Diese Abhängigkeit darf nicht außer Acht gelassen werden, insbesondere nicht, wenn Sie Dienste deaktivieren möchten (z. B. auf einem Front-End-Server, auf dem Exchange Server ausgeführt wird). Wesentliche Dienste dürfen nicht
41
deaktiviert werden. Andernfalls wird das Betriebssystem möglicherweise nicht gestartet, da durch deaktivierte Dienste der Start aller anderen von diesen abhängigen Dienste verhindert wird. Melden Sie sich nicht unter Windows an, wenn nach dem Deaktivieren eines Diensts Fehler beim Start auftreten. Starten Sie stattdessen das System mit der letzten als funktionierend bekannten Konfiguration neu, damit die letzten Änderungen an der Dienstekonfiguration verworfen werden. Die letzte als funktionierend bekannte Konfiguration wird unter Windows im Registrierungsschlüssel HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001 gespeichert. Dieser Schlüssel wird bei jeder erfolgreichen Anmeldung am Betriebssystem aktualisiert. Wenn Sie sich unter Windows mit einer falschen Konfiguration anmelden, werden die falschen Einstellungen in der letzten als funktionierend bekannten Konfiguration gespeichert.
Mit dem Programm SC.exe über den Befehl sc <Dienstname> qc können Sie die Abhängigkeiten und den Starttyp von Exchange-Diensten auf schnelle Weise überprüfen. Mit der folgenden Ausgabe wird beispielsweise die Standardkonfiguration der Systemaufsicht angegeben (Befehlszeile: sc qc MSExchangeSA):
SERVICE_NAME: MSExchangeSA
TYPE : 10 WIN32_OWN_PROCESS
ERROR_CONTROL : 1 NORMAL
BINARY_PATH_NAME : "C:\Program Files\Exchsrvr\bin\mad.exe"
LOAD_ORDER_GROUP :
TAG : 0
DISPLAY_NAME : Microsoft Exchange System Attendant
SERVICE_START_NAME : LocalSystem
Klicken Sie zum Festlegen des Starttyps im Tool Dienste auf die Registerkarte Allgemein und anschließend auf Starttyp. Über das Tool Dienste können Sie auch die Systemaufsicht starten, oder verwenden Sie SC.exe mit der Befehlszeile sc start MSExchangeSA. Darüber hinaus können Sie Dienste mit dem Befehl net start starten, z. B. net start MSExchangeSA. Die meisten Administratoren ziehen die Verwendung des Tools Dienste vor.
Ob Sie nun das Tool Dienste, SC.exe, den Befehl net start oder ein anderes Dienststeuerungsprogramm verwenden, der SCM führt die unten stehenden aufeinander folgenden Schritte zum Starten eines Diensts aus:
1. Abrufen der in der Dienstedatenbank gespeicherten Kontoinformationen
Der Benutzername und das Kennwort für das Dienstkonto werden bei der Installation des Diensts angegeben. Der SCM speichert den Benutzernamen in einem REG_SZ-Registrierungswert mit dem Namen ObjectName im Registrierungsschlüssel des
42
einzelnen Diensts (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<Dienstname>). Das Kennwort befindet sich in einem sicheren Bereich von Local Security Authority (LSA – lokale Sicherheitsautorität). Im Tool Dienste auf der Registerkarte Anmelden können Sie Änderungen am Dienstkonto vornehmen.
Hinweis: Exchange Server 2003-Dienste verwenden in der Standardeinstellung das Konto LocalSystem. Das Konto LocalSystem ist ein vordefiniertes lokales Konto mit umfassenden Berechtigungen für den lokalen Computer. Dieses Konto ist nur für Systemprozesse verfügbar und verfügt über kein Kennwort.
2. Anmelden am Dienstkonto
Alle aktiven Prozesse, auch Dienstanwendungen, müssen über eine Identität unter Windows verfügen. Beim Starten eines Diensts verwendet der SCM die aus der Dienstedatenbank abgerufenen Kontoinformationen und meldet sich unter Windows an. Auf dem lokalen Computer muss das vom SCM zum Anmelden verwendete Konto über das besondere Benutzerrecht Als Dienst anmelden verfügen.
Hinweis: Das Konto LocalSystem verfügt implizit über das Benutzerrecht Als Dienst anmelden, da dieses Konto auf alle lokalen Ressourcen zugreifen kann.
3. Erstellen des Diensts mit dem Status „gesperrt“
Der SCM startet neue Dienste mit dem Status „gesperrt“, da ein Dienst erst verwendet werden kann, nachdem die erforderlichen Sicherheitsinformationen vom SCM dem neuen Prozess hinzugefügt wurden.
4. Zuweisen des Zugriffstokens zum Prozess
Für jeden unter Windows ausgeführten Prozess ist ein Zugriffstoken, auch als Anmeldetoken bezeichnet, erforderlich. Das Zugriffstoken ist ein Objekt, mit dem der Sicherheitskontext des Diensts beschrieben wird. Zu den Informationen im Token zählen die Identität und die Berechtigungen des Dienstkontos, über das der Dienst mit dem Betriebssystem interagiert.
5. Ermöglichen der Ausführung des Prozesses
Nach dem Abschluss der Anmeldung und der Zuweisung des Zugriffstokens lässt der SCM die Ausführung des Diensts und seiner Funktionen zu.
Folgende Schritte werden vom SCM beim Beenden eines Diensts ausgeführt:
1. Empfang einer Anforderung zum Beenden eines Diensts durch den SCM
Ein Dienststeuerungsprogramm kann einen Dienst beenden, indem es mit einer Dienststeuerungsfunktion eine SERVICE_CONTROL_STOP-Anforderung über den SCM an den Dienst sendet.
43
2. Überprüfen der Dienstabhängigkeiten durch den SCM
Wenn der SCM feststellt, dass andere Dienste ausgeführt werden, die von dem in der Anforderung zum Beenden angegebenen Dienst abhängen, wird vom SCM ein Fehlercode an das Dienststeuerungsprogramm zurückgegeben. Vor dem Auslösen des Beendigungsvorgangs muss das Dienststeuerungsprogramm alle vom angegebenen Dienst abhängigen Dienste aufführen und beenden. Im Tool Dienste wird beispielsweise das Dialogfeld Andere Dienste beenden angezeigt, in dem Sie gefragt werden, ob alle abhängigen Dienste ebenfalls beendet werden sollen. In SC.exe wird dagegen ein Fehlercode und eine Meldung angezeigt, dass der Dienst nicht beendet werden kann, da andere aktive Dienste von ihm abhängen.
3. Weiterleiten der Beendigungsanforderung an den Dienst durch den SCM
Wenn keine abhängigen aktiven Dienste vorliegen, wird die Anforderung zum Beenden des Diensts vom SCM an den entsprechenden Dienst weitergeleitet. Die dem Dienst zugewiesenen Ressourcen werden freigegeben, und der Dienst wird beendet.
Verwalten der Statusinformationen für Dienste, die ausgeführt werdenWährend der Ausführung eines Diensts werden Statusbenachrichtigungen an den SCM-Prozess gesendet. Die Statusinformationen werden vom SCM für jeden Dienst im entsprechenden Dienstdatensatz verwaltet. Der SCM überprüft kontinuierlich diese Informationen, sodass nicht fälschlicherweise Steuerungsanforderungen gesendet werden, die nicht mit dem aktuellen Status des Empfängerdiensts übereinstimmen.
Die Statusinformationen des Diensts enthalten die folgenden Angaben:
Diensttyp Ein Dienst kann ein Dateisystemtreiber, ein Gerätetreiber oder ein Windows-Dienst sein und über einen eigenständigen Prozess oder über einen mit anderen Diensten gemeinsam verwendeten Prozess ausgeführt werden. Der Systemaufsichtsdienst ist beispielsweise ein Dienst, der über einen eigenständigen Prozess ausgeführt wird. Beim SMTP-Dienst handelt es sich dagegen um einen Dienst, der in einem Prozess gemeinsam mit anderen Diensten ausgeführt wird, die in den Internetinformationsdiensten (IIS) integriert sind.
Aktueller Status Ein Dienst kann sich in einem der folgenden Status befinden: „Wird gestartet“, „Wird ausgeführt“, „Angehalten“, „Wird beendet“ oder „Wird nicht ausgeführt“.
Zulässige Steuerungscodes Hierbei handelt es sich um die Steuerungscodes, die für den Dienst zulässig sind und je nach aktuellem Status im zugehörigen Handler verarbeitet werden können.
Windows-Beendigungscode Der Dienst zeigt mit diesem Code Fehler an, die beim Starten oder Beenden des Diensts auftreten. Für die Rückgabe eines dienstspezifischen Fehlercodes muss der Wert im Dienst auf ERROR_SERVICE_SPECIFIC_ERROR festgelegt werden. So wird angegeben, dass im Beendigungscode des Diensts weitere
44
Informationen angezeigt werden. Der Wert ist auf NO_ERROR gesetzt, wenn der Dienst ordnungsgemäß ausgeführt oder beendet wird.
Dienstbeendigungscode Der Dienst zeigt mit diesem Code Fehler an, die beim Starten oder Beenden des Diensts auftreten. Der Wert wird nur angezeigt, wenn der Windows-Beendigungscode auf ERROR_SERVICE_SPECIFIC_ERROR festgelegt ist.
Wait Hint Dieser Code wird zum Protokollieren der für einen ausstehenden Vorgang zum Starten, Beenden, Anhalten oder Fortsetzen des Diensts geschätzten Zeit in Millisekunden verwendet.
Prüfpunkt Mit diesem Wert wird der Fortschritt eines Diensts bei längeren Vorgängen zum Starten, Beenden, Anhalten oder Fortsetzen des Diensts in regelmäßigen Abständen angezeigt. Dieser Wert wird im Tool Dienste beispielsweise verwendet, um den Fortschritt von Start- oder Beendigungsvorgängen für einen Dienst zu verfolgen.
Tipp: Mit dem Befehl sc query state= all type= service können Sie den aktuellen Status aller Windows-Dienste anzeigen.
Exchange-Dienste und das Konto „LocalSystem“Exchange Server 2003-Dienste werden über das Konto LocalSystem ausgeführt. Dies bringt die folgenden Sicherheitsauswirkungen mit sich:
Keine erforderlichen zusätzlichen Konto- oder Kennwortänderungen Das Konto LocalSystem (NT AUTHORITY\LocalSystem) ist immer vorhanden und verfügt über eine hexadezimale Zufallszahl als Kennwort. Das Kennwort wird alle sieben Tage automatisch geändert. Dadurch müssen Sie vor der Installation von Exchange Server 2003 in Active Directory kein Dienstekonto erstellen und das Dienstekennwort nicht in regelmäßigen Abständen ändern.
Vollzugriff auf alle lokalen Ressourcen Da Exchange Server 2003-Dienste über einen Vollzugriff auf alle lokalen Ressourcen verfügen, haben diese Dienste in der Regel einen uneingeschränkten Zugriff auf die Registrierungsdatenbank, die IIS-Metabase und das Dateisystem. Dies trifft jedoch nicht zu, wenn der Zugriff für das spezielle Windows-Konto SYSTEM oder das Konto Everyone ausdrücklich gesperrt ist. Dies ist nicht zu empfehlen. Wenn Exchange 2003 auf einem Domänencontroller installiert ist, verfügen Exchange Server 2003-Dienste daher über einen Vollzugriff auf Active Directory, da der Domänencontroller über ein Verzeichnisreplikat und das Konto LocalSystem über Vollzugriff auf die lokalen Ressourcen verfügt.
45
Hinweis: In den meisten sicherheitsorientierten Organisationen wird Exchange Server 2003 nicht auf einem Domänencontroller installiert, da Exchange Server 2003 und Active Directory bei dieser Installation nicht einzeln verwaltet werden können.
Zugriff über „LocalSystem“ nur auf lokale Ressourcen Wenn ein Dienst über das Konto LocalSystem ausgeführt wird, kann dieser nur auf lokale Ressourcen zugreifen, wenn für den Netzwerkzugriff kein anderes Konto verwendet wird. Aus diesem Grund wird bei Diensten, die über LocalSystem ausgeführt werden, das Konto NetworkService für den Netzwerkzugriff verwendet. Der Name des Kontos lautet NT AUTHORITY\NetworkService. Dieses Konto verfügt über kein Kennwort.
Das Konto NetworkService entspricht dem Computerkonto des lokalen Computers in der Domäne. Bei einem Exchange-Dienst, der im Sicherheitskontext des Kontos LocalSystem ausgeführt wird, werden beim Zugriff auf Domänenressourcen im Netzwerk, z. B. auf Active Directory, die Anmeldeinformationen für das lokale Computerkonto verwendet. Folglich verfügt Exchange Server 2003 auf einem Mitgliedsserver über wesentlich weniger Berechtigungen als auf einem Domänencontroller, da Computerkonten in der Standardeinstellung sehr wenige Berechtigungen aufweisen und keiner Gruppe angehören. In der Standardkonfiguration für Computerkonten ist nur ein minimaler Zugriff auf Active Directory zulässig.
Zur Behebung des Problems und zur Erteilung der erforderlichen Berechtigungen für das Computerkonto werden mit Exchange Server 2003 die folgenden beiden speziellen Sicherheitsgruppen in Active Directory erstellt:
Exchange Domain Servers Die Gruppe Exchange Domain Servers ist eine globale Sicherheitsgruppe mit den Computerkonten aller Server in einer Domäne, auf denen Exchange Server ausgeführt wird.
Exchange Enterprise Servers Die Gruppe Exchange Enterprise Servers ist eine lokale Sicherheitsgruppe mit allen globalen Exchange Domain Servers-Gruppen in der Gesamtstruktur. Über diese Sicherheitsgruppe wird allen Exchange-Computerkonten der Zugriff auf die erforderlichen Ressourcen in der lokalen Domäne gewährt.
Hinweis: Benennen Sie die Exchange Domain Server- oder Exchange Enterprise Server-Sicherheitsgruppen nicht um, und verschieben Sie sie nicht. Entfernen Sie aus diesen Gruppen auch keine Computerkonten von vorhandenen Exchange-Servern.
46
Überprüfen der DienstedatenbankBeim Öffnen von HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services im Registrierungs-Editor (Regedit.exe) und Überprüfen der einzelnen Schlüssel für Exchange-Dienste können Sie feststellen, dass viele Dienste, deren Namen mit MSExchange beginnen, ähnliche Werte in den entsprechenden Dienstschlüsseln enthalten. Diese Werte sind in der folgenden Tabelle aufgeführt.
Allgemeine Registrierungswerte für Windows-Dienste
Wert Typ BeschreibungDependOnGroup REG_MULTI_SZ Listet Ladegruppen auf, von
denen Windows-Dienste abhängen. Die von einer Gruppe abhängigen Dienste können ausgeführt werden, wenn nach dem Versuch, alle Mitglieder einer Gruppe zu installieren, mindestens ein Gruppenmitglied ausgeführt wird.
DependOnService REG_MULTI_SZ Listet die Namen der Windows-Dienste auf, von denen der Dienst abhängt. Die Dienste müssen vor dem Start dieses Diensts vom SCM gestartet werden. Dieser Wert kann eine leere Zeichenfolge sein, wenn der Dienst über keine Abhängigkeiten verfügt.
Description REG_SZ Beschreibt den Dienst. Dabei handelt es sich lediglich um einen Kommentar zur Erläuterung der Funktion des Diensts.
47
Wert Typ BeschreibungDiagnosticsMessageFile REG_SZ Enthält den Namen der
Ressourcen-DLL mit den Ereignisbeschreibungszeichenfolgen für die Ereignisse, die mit dem Dienst in das Anwendungsereignisprotokoll geschrieben werden. Ressourcen-DLLs befinden sich im Verzeichnis \Programme\Exchsrvr\Res.
DisplayName REG_SZ Enthält den Anzeigenamen zur Identifikation des Diensts. Diese Zeichenfolge hat eine maximale Länge von 256 Zeichen. Die Groß- und Kleinschreibung des Namens wird im SCM beibehalten. Für den Vergleich von Anzeigenamen wird die Groß- und Kleinschreibung jedoch nicht beachtet.
48
Wert Typ BeschreibungErrorControl REG_DWORD Gibt den Schweregrad von
Fehlern und die Art der Fehlerbehebung an, wenn der Start des Diensts fehlschlägt. Dieser Parameter legt eins der folgenden Verfahren fest:
Der Fehler wird vom Startprogramm protokolliert, der Startvorgang wird jedoch fortgesetzt.
Der Fehler wird vom Startprogramm protokolliert, und eine Meldung wird angezeigt, der Startvorgang wird jedoch fortgesetzt.
Der Fehler wird vom Startprogramm protokolliert. Wird die letzte als funktionierend bekannte Konfiguration gestartet, wird der Startvorgang fortgesetzt. Andernfalls wird das System mit der letzten als funktionierend bekannten Konfiguration neu gestartet.
Der Fehler wird nach Möglichkeit vom Startprogramm protokolliert. Wird die letzte als funktionierend bekannte Konfiguration gestartet, wird der Systemstart abgebrochen. Andernfalls wird das System mit der letzten
49
Wert Typ BeschreibungFailureActions REG_BINARY Gibt den Vorgang an, der
vom SCM beim Fehlschlagen eines Diensts durchgeführt werden soll. Ein Dienst gilt als fehlgeschlagen, wenn er beendet wird, ohne dass der entsprechende Status an den Dienstcontroller gesendet wird (wenn z. B. Fehler bei einem Dienst auftreten).
Group REG_SZ Gibt die Ladegruppe an, der der Dienst angehört. Beachten Sie, dass durch Festlegen dieses Werts möglicherweise die Einstellung des Werts DependOnService überschrieben wird.
ImagePath REG_EXPAND_SZ Enthält den vollqualifizierten Pfad für die Binärdatei des Diensts. Wenn der Pfad ein Leerzeichen enthält, muss er für die korrekte Interpretation in Anführungszeichen gesetzt werden. Beispiel: "d:\\Programme\\Exchsvr\\Bin\\mad.exe".
Der Pfad kann darüber hinaus Programmargumente enthalten.
50
Wert Typ BeschreibungObjectName REG_SZ Gibt den Namen des Kontos
an, unter dem der Dienst ausgeführt werden soll. Wenn der Dienst das Konto LocalService verwendet, wird dieser Parameter auf NT AUTHORITY\LocalService eingestellt. Zudem kann ein Kontoname im Format „Domänenname\Benutzername“ angegeben werden.
Start REG_DWORD Gibt an, wann der Dienst gestartet werden soll. Der SCM kann einen Dienst automatisch beim Systemstart oder auf Anforderung eines Prozesses starten. Mit diesem Wert kann auch angegeben werden, dass ein Dienst nicht gestartet werden kann und dass beim Versuch, den Dienst zu starten, der Fehlercode ERROR_SERVICE_DISABLED ausgegeben wird.
Tag REG_DWORD Legt die Reihenfolge des Dienststarts in einer Ladegruppe fest. Tags werden nur bei Treiberdiensten überprüft.
51
Wert Typ BeschreibungType REG_DWORD Gibt den Diensttyp an:
Dateisystemtreiber, Gerätetreiber, Dienst mit eigenständigem Prozess oder Dienst, der einen Prozess gemeinsam mit mindestens einem anderen Dienst nutzt. MSExchangeSA ist beispielsweise ein Dienst, der über einen eigenständigen Prozess ausgeführt wird. EXIFS ist ein Beispiel für einen Exchange-spezifischen Dateisystemtreiber.
Darüber hinaus liegen möglicherweise die folgenden Unterschlüssel für Exchange-Dienste vor:
Diagnostics Dieser Schlüssel enthält REG_DWORD-Parameter für mögliche Ereignisprotokollkategorien, die vom Dienst bereitgestellt werden. Der Name der Parameter unter diesem Schlüssel setzt sich aus der Ressourcen-ID und einer Zeichenfolge zusammen, z. B. 9 Clean Mailbox. Der jedem Parameter zugeordnete Wert entspricht dem Diagnoseprotokolliergrad für die betreffende Kategorie. In der Regel werden diese Werte über die Servereigenschaften im Exchange-System-Manager konfiguriert. Auf der Registerkarte Diagnoseprotokoll werden die verschiedenen Kategorien aufgeführt und die ausgewählten Werte den entsprechenden Parametern zugewiesen.
Enum Dieser Schlüssel enthält Parameter, die der SCM zum Aufführen der Dienste in der Dienstedatenbank verwendet werden. Beispielsweise enthält der REG_SZ-Parameter 0 einen Wert, der auf die Unterschlüssel unter dem Registrierungsschlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root verweist. Dadurch können die Dienste im Windows-Konfigurations-Manager beim Systemstart als logische Geräte aufgeführt werden.
Parameters Dieser Schlüssel enthält Registrierungsparameter für dienstspezifische Konfigurationsinformationen. Der Schlüssel Parameters kann weitere Unterschlüssel enthalten.
Performance Dieser Schlüssel enthält Indikatoren für die Leistungsüberwachung. Mit dem REG_SZ-Parameter Library wird die DLL-Datei mit den Leistungsindikatoren
52
angegeben. Für die Leistungsindikatoren sind weitere Schlüssel vorhanden. Der REG_SZ-Parameter PerfIniFile verweist beispielsweise auf die INI-Datei, in der die einzelnen Leistungsindikatoren definiert werden.
Security Dieser Schlüssel enthält einen REG_BINARY-Parameter mit dem Namen Security mit einer Sicherheitsbeschreibung für den Dienst, die angibt, mit welchen Konten der Dienst gesteuert wird. Ein Administrator verfügt möglicherweise über Berechtigungen zum Starten und Beenden eines Diensts, über die ein Benutzer beispielsweise nicht verfügt.
Vorsicht: Die fehlerhafte Bearbeitung der Registrierung kann zu ernsthaften Problemen führen, die möglicherweise eine Neuinstallation des Betriebssystems erforderlich machen. Dadurch entstandene Probleme können unter Umständen nicht mehr behoben werden. Sichern Sie vor dem Ändern der Registrierung alle wichtigen Daten.
BetriebssystemdiensteExchange Server 2003 ist u. a. bei der Netzwerkkommunikation, der Sicherheit und den Verzeichnisdiensten in hohem Maße vom Betriebssystem abhängig. Exchange Server 2003 erfordert beispielsweise TCP/IP und ist abhängig vom TCP/IP-Stack und den zugehörigen Komponenten. Diese Komponenten sind in den im Windows-E/A-Subsystem integrierten Kernel-Treibern implementiert. Exchange Server 2003 verwendet Standardprogrammierschnittstellen von Microsoft Win32 für die Interaktionen mit dem Kernel.
Zusätzlich zum Windows-Kernel weist Exchange Server 2003 die folgenden Abhängigkeiten zu Windows-Diensten auf:
Ereignisprotokoll Über diesen Dienst können die von Exchange-Diensten und anderen Windows-Programmen und -Komponenten gesendeten Ereignisprotokollnachrichten in der Ereignisanzeige angezeigt werden. Der Dienst kann nicht beendet werden.
NTLM-Security Support Provider Dieser Dienst ist für die Sicherheit von Programmen zuständig, die RPCs und andere Transportmechanismen als Named Pipes für die Netzwerkanmeldung verwenden und dabei vom NTLM-Authentifizierungsprotokoll Gebrauch machen.
Remoteprozeduraufruf (RPC) Mit diesem Dienst werden über die RPC-Endpunktzuordnung RPC-Verbindungen mit dem Server unterstützt. Der Dienst dient auch als COM (Component Object Model).
RPCs und LRPCs (Lightweight Remote Procedure Calls) sind wichtige Verfahren für die Kommunikation zwischen den Prozessen. LRPCs sind lokale Versionen von RPCs. LRPCs werden zur Kommunikation zwischen dem Exchange-Informationsspeicher und Serverkomponenten verwendet, die abhängig sind von MAPI und verwandten APIs, z. B.
53
Messagingconnectors für Messagingsysteme, die nicht auf Exchange basieren. Normale RPCs werden dagegen verwendet, wenn Clients mit Serverdiensten im Netzwerk kommunizieren müssen. Typische RPC-Clients sind MAPI-Clients, z. B. Microsoft Outlook und Exchange-System-Manager, interne Komponenten der Systemaufsicht, beispielsweise DSProxy, sind jedoch auch RPC-Clients. Zur Annahme von Verzeichnisanforderungen von MAPI-Clients und zur Weitergabe der Anforderungen an Adressbuchdienstanbieter muss DSProxy RPCs zur Kommunikation mit Active Directory über die Namensdienstanbieter-Schnittstelle (NSPI – Name Service Provider Interface) verwenden. Weitere Informationen zu DSProxy finden Sie unter Exchange Server 2003 und Active Directory .
Dabei ist wichtig, dass es sich bei RPCs um ein Kommunikationsverfahren auf Anwendungsebene handelt, d. h., dass RPCs für die Herstellung der Verbindung andere Netzwerkkommunikationsverfahren verwenden, z. B. NetBIOS, Named Pipes oder Windows Sockets. Die Verbindung muss über die RPC-Endpunktzuordnung hergestellt werden, da der Client zuerst den zu verwendenden Endpunkt festlegen muss. In der Standardeinstellung werden bei RPC-Serverdiensten dynamische Verbindungsendpunkte verwendet. In einem TCP/IP-Netzwerk stellt der Client über TCP-Anschluss 135 eine Verbindung mit der RPC-Endpunktzuordnung her, fragt den aktuellen TCP-Anschluss des gewünschten Diensts ab (z. B. den NSPI-Anschluss von Active Directory), empfängt den entsprechenden TCP-Anschluss von der Endpunktzuordnung und stellt schließlich über diesen TCP-Anschluss eine RPC-Verbindung mit dem RPC-Server her. In der folgenden Abbildung ist die Funktion der RPC-Endpunktzuordnung dargestellt.
Herstellen einer RPC-Verbindung mit Active Directory
Hinweis: In der Standardeinstellung verwenden Exchange-Dienste dynamische TCP-Anschlüsse zwischen 1024 und 5000 für die RPC-Verbindung. Bei verschiedenen Diensten, z. B. bei der Systemaufsicht und dem Exchange-Informationsspeicherdienst, können statische Anschlüsse mithilfe von
54
Registrierungsschlüsseln angegeben werden. Der Client muss jedoch bei dynamischen und statischen Anschlusszuweisungen eine Verbindung mit der RPC-Endpunktzuordnung herstellen.
Server Über diesen Dienst wird die Datei- und Druckerfreigabe sowie der Named Pipe-Zugriff auf den Server mit dem SMB-Protokoll (Server Message Block) ermöglicht. Wenn Sie z. B. auf Nachrichtenverfolgungs-Protokolldateien über den Nachrichtenstatus im Exchange-System-Manager zugreifen, kommunizieren Sie mit dem Serverdienst, da Nachrichtenverfolgungsprotokolle über \\<Servername>\<Servername>.Log, beispielsweise \\Server01\Server01.log, für den Netzwerkzugriff freigegeben sind. Das SMB-Protokoll wird darüber hinaus für die Windows-Remoteverwaltung benötigt.
Der SCM-Schlüssel für den Serverdienst lautet lanmanserver. Unter diesem Registrierungsschlüssel finden Sie den wichtigen Unterschlüssel Shares. Dieser Schlüssel enthält Parameter für alle Freigaben auf dem Server. Eine besonders wichtige Freigabe für den Systemaufsichtsdienst ist die Freigabe Address, über die auf die DLLs zur Erstellung der Proxyadressen zugegriffen werden kann. Mit dem Empfängeraktualisierungsdienst werden je nach den Einstellungen in den Empfängerrichtlinien über diese DLLs postfachaktivierte und E-Mail-aktivierte Empfängerobjekte sowie X.400-, SMTP-, Lotus Notes-, Microsoft Mail-, Novell GroupWise- und Lotus cc:Mail-Adressen zugewiesen. Auf die DLLs zur Erstellung von Adressen wird über das Netzwerk zugegriffen, da Gatewayconnectors (und die zugeordneten DLLs zur Erstellung von Adressen) nicht zwangsläufig auf dem lokalen Server vorhanden sind, auf dem Exchange Server ausgeführt wird. Der Empfängeraktualisierungsdienst ist ein Teil der Systemaufsicht, sodass der Serverdienst vor dem Start der Systemaufsicht gestartet werden muss.
Arbeitsstation Dieser Dienst ist das Gegenstück zum Serverdienst. Über diesen Dienst kann der Computer mit dem SMB-Protokoll eine Verbindung mit anderen Computern im Netzwerk herstellen. Dieser Dienst muss vor dem Start der Systemaufsicht gestartet werden.
Sicherheitskontenverwaltung Mit dem Sicherheitskontenverwaltungsdienst werden Sicherheitsinformationen für lokale Benutzerkonten gespeichert. Der Dienst wird bei der Anmeldung von lokalen Konten am Server benötigt. Da alle Exchange-Dienste über das Konto LocalSystem am lokalen Computer angemeldet werden müssen, kann Exchange Server 2003 nicht ausgeführt werden, wenn diese Komponente nicht verfügbar ist.
Windows-Verwaltungsinstrumentation Mit diesem Dienst wird eine Standardschnittstelle und ein Standardobjektmodell für den Zugriff auf Verwaltungsinformationen über Computerhardware und -software bereitgestellt. Die Systemaufsicht ist die Komponente in Exchange Server 2003, über die die Serverüberwachung und der Serverstatus verwaltet wird. Exchange Server 2003 fügt zusätzliche WMI-Anbieter zum WMI-Dienst hinzu, sodass über die WMI auf Exchange-Statusinformationen zugegriffen werden kann. Der WMI-Dienst ist zum Starten des Microsoft Exchange-Verwaltungsdiensts erforderlich.
55
Es gibt zudem mehrere Windows-Dienste, die von Exchange Server 2003 in bestimmten Fällen benötigt werden:
COM+ Ereignissystem Dieser Dienst unterstützt die Systemereignisbenachrichtigung für COM+-Komponenten, die die automatische Verteilung von Ereignissen an die entsprechenden COM-Komponenten bereitstellen. Deaktivieren Sie diesen Dienst nicht auf Servern, auf denen Exchange Server 2003 ausgeführt wird, da die in eine COM+-Komponentenanwendung integrierten Ereignissenken ohne Prozesse auf dem Server nicht ordnungsgemäß ausgeführt werden.
COM+-Systemanwendung Mit diesem Dienst wird die Konfiguration und Verfolgung der COM+-Komponenten verwaltet. Wenn der Dienst beendet wird, können die meisten COM+-Komponenten in Exchange Server 2003 nicht ordnungsgemäß ausgeführt werden.
Fehlerberichterstattungsdienst Mit diesem optionalen Dienst können Fehler automatisch aufgezeichnet werden. Auf Servern mit Exchange Server kann dieser Dienst zum automatischen Senden von Informationen über schwerwiegende Dienstfehler an Microsoft verwendet werden.
HTTP SSL Mit diesem Dienst wird HTTPS für den HTTP-Dienst mit SSL implementiert. Aktivieren Sie diesen Dienst, wenn Sie HTTPS zum Sichern von Outlook Web Access oder RPC über HTTP-Verbindungen verwenden möchten.
IPSec-Dienste Über diesen Dienst wird IPSec (Internet Protocol Security) aktiviert, sodass Endpunktsicherheit zwischen Clients und Servern in TCP/IP-Netzwerken bereitgestellt wird. Dieser Dienst muss aktiviert sein, wenn IPSec zum Sichern des Netzwerkverkehrs zwischen einem Server, auf dem Exchange Server ausgeführt wird, und anderen Computern im Netzwerk verwendet werden soll, z. B. ein Front-End-Server mit Exchange Server oder ein Domänencontroller.
Microsoft Search Über diesen Dienst wird die Indizierung der auf dem Server gespeicherten Informationen aktiviert. Dieser Dienst ist erforderlich, wenn die Volltextindizierung für einen Postfachspeicher oder einen Informationsspeicher für Öffentliche Ordner auf dem Server aktiviert werden soll, auf dem Exchange Server ausgeführt wird.
MS Software Shadow Copy Provider Über diesen Dienst werden die mit dem Microsoft Volumeschattenkopie-Dienst erstellten Software-basierten Volumeschattenkopien verwaltet. Wenn Sie die Exchange Server 2003-Messagingdatenbanken mit dem Windows-Sicherungsprogramm sichern, können Sie diesen Dienst beenden, da das Windows-Sicherungsprogramm nicht vom Volumeschattenkopie-Dienst abhängig ist. Wenn Sie eine nicht von Microsoft vertriebene Sicherungslösung einsetzen, bei der der Volumeschattenkopie-Dienst verwendet wird, muss dieser Dienst jedoch aktiviert werden. In der Regel sollte dieser Dienst den gleichen Starttyp haben wie der Volumeschattenkopie-Dienst.
56
Anmeldedienst Mit diesem Dienst wird ein sicherer Channel zwischen dem Server, auf dem Exchange Server ausgeführt wird, und einem Domänencontroller bereitgestellt. Dieser Dienst ist für den Benutzerzugriff auf Postfächer auf dem Server mit Exchange Server sowie für jeden Dienst erforderlich, bei dem ein Domänenkonto zum Starten verwendet wird.
Leistungsprotokolle und Warnungen Mit diesem Dienst werden Systemleistungsdaten von lokalen oder Remotecomputern über vorkonfigurierte Zeitplanparameter erfasst. Anschließend werden die Daten in ein Protokoll geschrieben oder eine Warnmeldung ausgelöst. Wenn Sie diesen Dienst beenden, können Sie im Tool Systemleistung über das Snap-In Leistungsprotokolle und Warnungen keine Systemleistungsinformationen abrufen.
Remoteregistrierung Mit diesem Dienst können Benutzer die Registrierungseinstellungen über Remotezugriff ändern. Der Exchange-System-Manager benötigt Zugriff auf die Registrierung, wenn Sie beispielsweise Diagnoseprotokolle für Exchange-Dienste konfigurieren möchten. Dieser Dienst muss verfügbar sein, wenn der Exchange-System-Manager auf einem Verwaltungscomputer ausgeführt wird. Wenn der Dienst beendet wird, kann die Registrierung nur auf dem lokalen Server geändert werden.
Systemereignisbenachrichtigung Mit diesem Dienst werden Systemereignisse überwacht und im COM+-Ereignissystem registrierte Komponenten über diese Ereignisse benachrichtigt. Wenn dieser Dienst beendet wird, erhalten im COM+-Ereignissystem registrierte Komponenten keine Exchange-Systemereignisbenachrichtigungen. In der folgenden Tabelle sind die von Exchange Server 2003 bereitgestellten Systemereignisse aufgeführt.
Systemereignisse in Exchange Server 2003
Ereignis Beschreibung
OnTimer Wird in einem angegebenen Intervall aufgerufen.
OnMDBStartUp Wird beim Starten eines Informationsspeichers aufgerufen.
OnMDBShutDown Wird beim Beenden eines Informationsspeichers aufgerufen.
Volumeschattenkopie Über diesen Dienst werden die für die Sicherung und andere Zwecke verwendeten Volumeschattenkopien verwaltet und implementiert. Dieser Dienst muss ausgeführt werden, wenn in der Sicherungslösung ein Requestor für den Exchange Server 2003-Volumeschattenkopie-Dienst zum Erstellen von Schattenkopien der Messagingdatenbanken verwendet wird. Wenn der Dienst deaktiviert ist, können Sicherungsprozesse fehlschlagen.
57
Hinweis: Die oben aufgeführten Dienste sind so konfiguriert, dass sie unter Windows Server 2003 automatisch gestartet werden. Sie werden im Sicherheitskontext des Kontos LocalSystem ausgeführt.
Internetinformationsdienste (IIS)Internetinformationsdienste (IIS) sind ein integraler Bestandteil jedes Servers, auf dem Exchange 2003 Server ausgeführt wird. IIS dient als Host für wesentliche Komponenten, die für die Funktion von Exchange Server 2003 als Messagingsystem benötigt werden. In den ISAPI-Anwendungen (Internet Server Application Programming Interface), die von Exchange Server 2003 zum Webdienst hinzugefügt werden, z. B. Outlook Web Access, Outlook Mobile Access und Exchange ActiveSync, können Benutzer über mehrere HTTP-basierte Protokolle auf Exchange zugreifen. Der Webdienst stellt darüber hinaus die RPC über HTTP-Kommunikation zur Verfügung, wenn Benutzer mit diesem Kommunikationsverfahren über das Internet ohne eine VPN-Verbindung (Virtual Private Network) auf die Postfächer zugreifen. IIS dient als Host für den SMTP-Dienst, der das zentrale Transportmodul von Exchange 2003 implementiert. IIS dient auch als Host für die NNTP-, IMAP4- und POP3-Protokollmodule, über die Internetbenutzer Messagingdaten mit den meisten Internetzugriffsprotokollen abrufen können. Der FTP-Dienst (File Transfer Protocol) ist der einzige IIS-Protokolldienst ohne Bedeutung für Exchange 2003, da es sich bei FTP um kein Messagingprotokoll handelt.
In der folgenden Abbildung ist die Integration von SMTP, NNTP, IMAP4, POP3, Outlook Web Access, Outlook Mobile Access und Exchange ActiveSync in die Architektur von IIS 6.0 dargestellt.
58
Exchange Server 2003-Komponenten in der IIS 6.0-Architektur
Exchange Server 2003 basiert auf den folgenden Hauptkomponenten in IIS 6.0:
Inetinfo.exe Inetinfo.exe ist eine Komponente im Benutzermodus, mit der der IIS-Hauptprozess ausgeführt wird und die als Host für die meisten Protokollmodule von IIS 6.0 dient. Zu diesen Komponenten gehören u. a. FTP, SMTP, NNTP, IMAP4 und POP3. Der Verwaltungsdienst wird ebenfalls im Kontext des Prozesses Inetinfo.exe ausgeführt. Beachten Sie dabei jedoch, dass der WWW-Veröffentlichungsdienst in Inetinfo.exe nicht ausgeführt wird. Die Architektur von IIS 6.0 wurde neu entwickelt, sodass der Webdienst aus Gründen der Fehlertoleranz, Systemleistung und Sicherheit in einem eigenen Verarbeitungskontext ausgeführt wird.
Metabase Die Metabase ist ein Datenspeicher, in dem IIS-Konfigurationsdaten gespeichert werden. Die Metabase ist eine XML-Datei im Nur-Text-Format und kann manuell oder programmgesteuert bearbeitet werden. Die Datei metabase.xml befindet sich im Verzeichnis \Windows\System32\Inetsrv. Weitere Informationen zur Metabase finden Sie unter Virtuelle Protokollserver in Exchange Server 2003 .
IIS-Verwaltungsdienst Mit dem IIS-Verwaltungsdienst wird die IIS-Metabase verwaltet und die Registrierung für den Webdienst, FTP-Dienst, SMTP-Dienst, POP3-Dienst, IMAP4-Dienst und NNTP-Dienst aktualisiert. Über den IIS-Verwaltungsdienst kann darüber hinaus in anderen Anwendungen auf die IIS-Konfigurationsinformationen zugegriffen werden, beispielsweise im Metabase-Aktualisierungsdienst, einer internen Komponente der Systemaufsicht. Weitere Informationen zum Metabase-Aktualisierungsdienst finden Sie unter Exchange Server 2003 und Active Directory .
Der Registrierungsschlüssel für den IIS-Verwaltungsdienst ist HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IISAdmin. Der IIS-Verwaltungsdienst ist abhängig
59
vom RPC-Dienst und vom Sicherheitskontenverwaltungsdienst. Alle anderen IIS-Dienste sind abhängig vom IIS-Verwaltungsdienst. Der IIS-Verwaltungsdienst ist in Iisadmin.dll implementiert. Diese Datei befindet sich in der Standardeinstellung im Verzeichnis \Windows\System32\Inetsrv.
Hinweis: Der IIS-Verwaltungsdienst muss auf jedem Server mit Exchange Server 2003 ausgeführt werden.
SMTP-Dienst Mit dem SMTP-Dienst wird das SMTP-Modul ausgeführt, über das eingehende SMTP-Nachrichten in der Standardeinstellung am TCP-Anschluss 25 angenommen und Nachrichten mit SMTP an andere Hosts gesendet werden. Auf einem Server, auf dem Exchange Server 2003 ausgeführt wird, steuert der SMTP-Dienst darüber hinaus das Haupttransportmodul. Der SMTP-Dienst ist in Windows Server 2003 integriert und wird durch Exchange Server 2003 erweitert. Weitere Informationen zur SMTP-Transportarchitektur finden Sie in SMTP-Transportarchitektur.
Der Registrierungsschlüssel für den SMTP-Dienst ist HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SMTPSvc. Der SMTP-Dienst wird im Kontext des Prozesses Inetinfo.exe ausgeführt und ist abhängig vom Ereignisprotokolldienst und vom IIS-Verwaltungsdienst. Der SMTP-Dienst ist in Smtpsvc.dll implementiert. Diese Datei befindet sich in der Standardeinstellung im Verzeichnis \Windows\System32\Inetsrv.
Hinweis: Obwohl keine anderen Dienste vom SMTP-Dienst abhängen, muss der SMTP-Dienst auf jedem Exchange Server 2003-Server ausgeführt werden, da das gesamte Exchange Server 2003-Messagingsystem auf diesem Dienst beruht.
POP3-Dienst Der POP3-Dienst ist in Exchange Server 2003 integriert und ermöglicht Internetbenutzern den Zugriff auf ihre Postfächer über POP3 (Post Office Protocol, Version 3). Clients, z. B. Outlook Express, können Nachrichten über POP3 downloaden, wenn Benutzer über die erforderlichen Berechtigungen verfügen und der POP3-Dienst auf dem Server mit Exchange Server ausgeführt wird. Über den POP3-Dienst kann nur auf den Posteingangsordner zugegriffen werden. Auf andere Postfachordner oder Öffentliche Ordner kann nicht zugegriffen werden.
Der Registrierungsschlüssel für den POP3-Dienst ist HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\POP3Svc. Der POP3-Dienst wird im Kontext des Prozesses Inetinfo.exe ausgeführt und ist abhängig vom IIS-Verwaltungsdienst, sodass er in IIS gesteuert werden kann. Der POP3-Dienst ist in Pop3svc.dll implementiert. Diese Datei befindet sich in der Standardeinstellung im Verzeichnis \Programme\Exchsrvr\Bin. In der Standardeinstellung ist der POP3-Dienst deaktiviert.
60
Hinweis: Da keine anderen Exchange-Dienste vom POP3-Dienst abhängig sind, muss der POP3-Dienst nicht ausgeführt werden, wenn Benutzer ihre Postfächer nicht über POP3-Clients aufrufen.
NNTP-Dienst Über den NNTP-Dienst kann ein Exchange Server 2003-Server anhand von Öffentlichen Ordnern als Host für NNTP-Newsgroups (z. B. Diskussionsgruppen) verwendet werden. Da sich dieser Dienst vollständig am NNTP-Protokoll orientiert, können sich Benutzer über einen beliebigen Newsreader-Client an Newsgroup-Diskussionen beteiligen. Wenn der NNTP-Dienst auf einem Exchange Server 2003-Server ausgeführt wird, kann er auch zum Replizieren von Newsgroups auf andere NNTP-Hosts über Newsfeeds verwendet werden. Der NNTP-Dienst ist in Windows Server 2003 enthalten und wird von Exchange Server 2003 erweitert.
Der Registrierungsschlüssel für den NNTP-Dienst ist HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NNTPSvc. Der NNTP-Dienst wird im Kontext des Prozesses Inetinfo.exe ausgeführt und ist abhängig vom Ereignisprotokolldienst und vom IIS-Verwaltungsdienst. Der NNTP-Dienst ist in Nntpsvc.dll implementiert. Diese Datei befindet sich in der Standardeinstellung im Verzeichnis \Windows\System32\Inetsrv. In der Standardeinstellung ist der NNTP-Dienst deaktiviert.
Hinweis: Da keine anderen Exchange-Dienste vom NNTP-Dienst abhängig sind, muss der NNTP-Dienst nicht ausgeführt werden, wenn Sie Newsgroups nicht auf andere NNTP-Hosts replizieren und wenn Benutzer für den Zugriff auf Öffentliche Ordner keine Newsreader-Clients verwenden.
IMAP4-Dienst Der IMAP4-Dienst gehört zum Lieferumfang von Exchange Server 2003 und ermöglicht Internetbenutzern den Zugriff auf ihre Postfächer und Öffentlichen Ordner über IMAP4 (Internet Mail Access Protocol, Version 4). Clients, z. B. Outlook Express, können Nachrichten über IMAP4 downloaden, wenn Benutzer über die erforderlichen Berechtigungen verfügen und der IMAP4-Dienst auf dem Server mit Exchange Server ausgeführt wird. IMAP4-Benutzer können die Nachrichten auch direkt auf dem Server bearbeiten.
Der Registrierungsschlüssel für den IMAP4-Dienst ist HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IMAP4Svc. Der IMAP4-Dienst wird im Kontext des Prozesses Inetinfo.exe ausgeführt und ist abhängig vom IIS-Verwaltungsdienst. Der IMAP4-Dienst ist in IMAP4svc.dll implementiert. Diese Datei befindet sich in der Standardeinstellung im Verzeichnis \Programme\Exchsrvr\Bin. In der Standardeinstellung ist der IMAP4-Dienst deaktiviert.
61
Hinweis: Da keine anderen Exchange-Dienste vom IMAP4-Dienst abhängig sind, muss der IMAP4-Dienst nicht ausgeführt werden, wenn Benutzer nicht über IMAP4-Clients auf ihre Postfächer zugreifen.
WWW-Veröffentlichungsdienst Der in Windows Server 2003 integrierte WWW-Veröffentlichungsdienst ist ein Konfigurations- und Verarbeitungsverwaltungsdienst im Benutzermodus, über den die IIS-Komponenten verwaltet werden, die HTTP-Anforderungen verarbeiten und Webanwendungen ausführen, z. B. Outlook Web Access, Outlook Mobile Access und Exchange ActiveSync. Der Webdienst ist darüber hinaus eine Überwachungskomponente, mit der die Webanwendungen in regelmäßigen Abständen daraufhin überprüft werden, ob sie ausgeführt werden oder unerwartet beendet wurden. Der Webdienst ist in Windows Server 2003 integriert. Exchange Server 2003 erweitert diesen Dienst mit ISAPI-Komponenten für Outlook Web Access, Outlook Mobile Access und Exchange ActiveSync.
Der Registrierungsschlüssel für den WWW-Dienst ist HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3Svc. Im Gegensatz zu allen anderen IIS-Diensten wird der Webdienst nicht im Kontext des Prozesses Inetinfo.exe ausgeführt. Im Parameter ImagePath im Registrierungsschlüssel W3Svc können Sie sehen, dass der Webdienst im Kontext des Prozesses Svchost.exe ausgeführt wird. Hierbei handelt es sich um einen generischen Hostprozess für in DLLs implementierten Dienste. Der Webdienst ist in Iisw3adm.dll implementiert.
Er wird in einer Dienstgruppe von Svchost.exe mit dem Namen IISSvcs ausgeführt. Svchost.exe verwendet Dienstgruppen zum Ausführen von einzelnen Diensten in einer einzigen gemeinsamen Instanz von Svchost.exe. Auf einem Server können mehrere Instanzen von Svchost.exe ausgeführt werden. Jede Sitzung von Svchost.exe kann eine gesonderte Gruppe von Diensten enthalten. Svchost-Gruppen werden im folgenden Registrierungsschlüssel aufgeführt:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Svchost.
Jeder Eintrag unter diesem Schlüssel ist ein REG_MULTI_SZ-Parameter, der eine einzelne Svchost-Gruppe repräsentiert. Jeder Wert enthält die Namen der Dienste, die gemeinsam in einer Dienstgruppe ausgeführt werden. Durch Überprüfen des Werts im Eintrag IISSvcs können Sie feststellen, dass der Webdienst der einzige Dienst in der IISSvcs-Gruppe ist.
WWW-Arbeitsprozess Die gesamte Webanwendungsverarbeitung, u. a. das Laden der ISAPI-Filter und -Erweiterungen sowie die Authentifizierung und Autorisierung, wird über einen WWW-Arbeitsprozess ausgeführt. Die ausführbare Datei des Arbeitsprozesses lautet w3wp.exe. Jeder Arbeitsprozess wird vollkommen unabhängig von Systemkomponenten und anderen Webanwendungen ausgeführt und empfängt Anforderungen direkt über den Kernelmodustreiber HTTP.sys.
62
Anwendungspool Ein Anwendungspool ist eine Anforderungswarteschlange in HTTP.sys, die von mindestens einem Arbeitsprozess verwendet wird. Dies bedeutet, dass in einem Anwendungspool Anforderungen für mindestens eine eindeutige Webanwendung verarbeitet werden können. Diese Webanwendungen werden abhängig von ihrer URL dem Anwendungspool zugewiesen. Jeder Anwendungspool ist durch Prozessgrenzen von anderen Anwendungspools getrennt. Eine Anwendung, die einem Anwendungspool zugewiesen ist, wird durch andere Anwendungspools nicht beeinträchtigt und kann nicht an einen anderen Anwendungspool weitergeleitet werden, wenn sie im aktuellen Anwendungspool bearbeitet wird.
Alle erforderlichen Laufzeitdienste für HTTP-Anwendungen, z. B. Unterstützung für die ISAPI-Erweiterung, sind in allen Anwendungspools verfügbar. Mit diesem Design wird verhindert, dass durch eine fehlerhafte Webanwendung oder Website andere Webanwendungen oder Websites beeinträchtigt werden, die auf dem Server von anderen Arbeitsprozessen bearbeitet werden. Nun können aktive Komponenten entfernt werden, ohne dass der Webdienst vollständig beendet werden muss. Der Hostarbeitsprozess kann vorübergehend unterbrochen werden, ohne dass andere mit Webbrowsern oder Webanwendungen kommunizierende Arbeitsprozesse beeinträchtigt werden. In einem Anwendungspool können zudem andere auf Prozessebene verfügbare Betriebssystemdienste verwendet werden (z. B. CPU-Drosselung).
Hinweis: Anwendungen können einem anderen Anwendungspool im Snap-In IIS-Manager zugewiesen werden, während der Server ausgeführt wird. IIS unterstützt bis zu 20.000 Anwendungspools pro Server.
HTTP.sys Dies ist die Kernelmoduskomponente für den Empfang, die Weiterleitung, die Warteschlange und die Zwischenspeicherung mit HTTP. Bei HTTP.sys handelt es sich um einen Kontaktpunkt für alle eingehenden HTTP-Anforderungen. Hierdurch werden Hochleistungsverbindungen für HTTP-Serveranwendungen ermöglicht. Der Treiber ist dem TCP/IP-Stack vorgeschaltet und registriert sich für alle Windows Sockets (IP/Anschluss-Kombinationen), auf denen eingehende Verbindungsanforderungen empfangen werden. Über HTTP.sys wird zudem die gesamte Verbindungsverwaltung, Bandbreiteneinschränkung und Webserverprotokollierung bereitgestellt.
HTTP.sys verfügt über eine Warteschlange für jeden Anwendungspool, sodass die einzelnen HTTP-Anforderungen an die entsprechenden Arbeitsprozesse im Benutzermodus weitergeleitet werden, die einem Anwendungspool zur Verfügung stehen. Wenn ein Arbeitsprozess im Benutzermodus unerwartet beendet wird, werden Anforderungen über HTTP.sys weiterhin angenommen und in Warteschlangen gespeichert, vorausgesetzt, der Webdienst wird noch ausgeführt. HTTP.sys nimmt weiterhin Anforderungen an und leitet sie in die entsprechende Warteschlange weiter, bis keine Warteschlangen mehr verfügbar sind, in den Warteschlangen kein Platz mehr verfügbar ist oder der Webdienst beendet ist. Sobald der Webdienst den fehlerhaften Arbeitsprozess bemerkt, startet er einen neuen Arbeitsprozess, wenn zu verarbeitende
63
Anforderungen für den Anwendungspool des Arbeitsprozesses ausstehen. Obwohl möglicherweise vorübergehend eine Störung bei der Anforderungsverarbeitung auftritt, wird der Fehler von den Benutzern nicht bemerkt, da die Anforderungen weiterhin angenommen und in Warteschlangen eingereiht werden.
Hauptdienste von Exchange Server 2003In der folgenden Abbildung sind die Hauptkomponenten von Exchange Server 2003 sowie die zugehörigen Dienstabhängigkeiten dargestellt. Zu den Hauptkomponenten zählen die Systemaufsicht, der Exchange-Informationsspeicherdienst, der IIS-Verwaltungsdienst, der SMTP-Dienst und das Exchange Installable File System (ExIFS – Installierbares Dateisystem von Exchange). Alle diese Dienste müssen auf jedem Exchange Server 2003-Server ausgeführt werden, um ein vollfunktionsfähiges Messagingsystem zu gewährleisten.
Windows-Hauptdienste und die abhängigen Exchange Server 2003-Hauptdienste
Der IIS-Verwaltungsdienst und der SMTP-Dienst sind in IIS integriert (siehe Erläuterungen im vorherigen Abschnitt). Der SMTP-Dienst muss auf jedem Exchange Server 2003-Server ausgeführt werden, da alle an oder von lokalen Empfängern gesendeten Nachrichten über das SMTP-Transportmodul übermittelt werden müssen. Wenn der SMTP-Dienst beendet wird oder nicht verfügbar ist, kann Exchange Server 2003 keine Nachrichten übermitteln. Weitere Informationen zur Routingarchitektur von Exchange Server 2003 finden Sie unter Nachrichtenroutingarchitektur.
64
Die Hauptkomponenten von Exchange Server 2003 haben folgende Aufgaben.
Microsoft Exchange-Systemaufsichtsdienst Der Systemaufsichtsdienst ist einer der wichtigsten Dienste in Exchange Server 2003. Diese Komponente hat viele Aufgaben, u. a. Verwaltung der Kommunikation mit Active Directory, Erstellen von Offlineadresslisten, Ausführen der Nachrichtenverfolgung. Die ausführbare Datei Mad.exe ist im Verzeichnis \Programme\Exchsrvr\Bin gespeichert. Unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ befinden sich mehrere Registrierungsschlüssel für die verschiedenen internen Komponenten der Systemaufsicht, z. B. MSExchangeSA, MSExchangeDSAccess, MSExchangeAL, MSExchangeFBPublish, MSExchangeMU und MSExchangeADDXA.
In der folgenden Tabelle sind die Funktionen der Systemaufsicht aufgeführt.
65
Interne Komponenten der Systemaufsicht und ihre Funktionen
Komponente Funktion Beschreibung
DSAccess-Komponente Suchen der Domänencontroller im Netzwerk und Bereitstellen von Active Directory-Informationen für andere Exchange-Dienste
Die Systemaufsicht muss Domänencontroller und globale Kataloge im Netzwerk suchen, sodass über die Exchange-Dienste auf Empfänger- und Konfigurationsinformationen zugegriffen werden kann. Die Systemaufsicht sucht Domänencontroller über ADSI (Active Directory Services Interface), um eine Bindung ohne Server zu erstellen.
Für den Proxyverzeichniszugriff über andere Exchange-Komponenten, z. B. den Exchange-Informationsspeicher oder das SMTP-Transportmodul, auf Active Directory beinhaltet die Systemaufsicht die DSAccess-Komponente (DSAccess.dll). Mit DSAccess werden zudem Verzeichnisinformationen zwischengespeichert, sodass die Anzahl der Anfragen an Active Directory reduziert wird. Weitere Informationen zu den Funktionen der Domänencontroller und globalen Kataloge sowie zu DSAccess finden Sie unter Exchange Server 2003 und Active Directory .
66
Komponente Funktion Beschreibung
DSProxy-Komponente Bereitstellung von Proxyfunktionen zwischen Legacy-MAPI-Clients und Active Directory
Mit der DSProxy-Komponente (Dsproxy.dll) der Systemaufsicht werden Outlook 2000 und neuere Versionen an einen globalen Katalogserver verwiesen, sodass der MAPI-Client mit Active Directory kommunizieren und auf die globale Adressliste zugreifen kann. DSProxy überträgt außerdem die Verzeichniskommunikation für ältere MAPI-Clients, die nicht direkt verwiesen werden können. Weitere Informationen zu DSProxy finden Sie unter Exchange Server 2003 und Active Directory .
67
Komponente Funktion Beschreibung
Frei-/Gebucht-Komponente Verwalten der Frei-/Gebucht-Informationen für Outlook Web Access-Benutzer
Die Veröffentlichung von Frei-/Gebucht-Informationen in Outlook Web Access wird über die Systemaufsicht ausgeführt. Wenn ein Benutzer einen Termin erstellt, werden die Frei-/Gebucht-Informationen vom Exchange-Informationsspeicher aus dem Kalender des Benutzers extrahiert und in einer Nachricht an das Postfach der Systemaufsicht gesendet. Mit der Frei-/Gebucht-Komponente (Madfb.dll) werden diese Nachrichten verarbeitet und die Frei-/Gebucht-Informationen im Öffentlichen Systemordner SCHEDULE+ FREE BUSY veröffentlicht. Weitere Informationen zur Veröffentlichung von Frei-/Gebucht-Informationen finden Sie unter Architektur des Exchange-Informationsspeicherdiensts.
Postfach-Manager-Komponente
Verwalten von Postfächern Über die Postfach-Manager-Komponente werden die Richtlinien zum Aufbewahren von Nachrichten sowie Postfachkontingente angewendet, die zum Verwalten der Postfachspeichergröße eingesetzt werden können.
68
Komponente Funktion Beschreibung
Metabase-Aktualisierungsdienst
Replizieren der Einstellungen von Active Directory in der IIS-Metabase
Der Verzeichnisdienst für den Metabase-Aktualisierungsdienst (Ds2mb.dll) ist eine interne Komponente der Systemaufsicht. Mit dem Metabase-Aktualisierungsdienst werden Protokolleinstellungen von Active Directory in die IIS-Metabase repliziert. Dadurch werden die im Exchange-System-Manager konfigurierten Internetprotokolleinstellungen auf die Internetprotokollmodule angewendet, z. B. auf den SMTP-Dienst. Weitere Informationen zum Metabase-Aktualisierungsdienst finden Sie unter Exchange Server 2003 und Active Directory .
69
Komponente Funktion Beschreibung
Offlineadressbuchgenerator Erstellen von Offlineadressbüchern
Mit dem Offlineadressbuchgenerator (Oabgen.dll) werden Adresslisten im Exchange-Informationsspeicher auf einem Server für Offlineadresslisten erstellt. Benutzer können eine Verbindung mit dem Server herstellen und die Offlineadresslisten downloaden. Über Offlineadresslisten kann auf Adressinformationen zugegriffen werden, wenn Benutzer einen Remotecomputer verwenden und keine permanente Verbindung mit dem Server zur Verfügung haben. Da Offlineadresslisten in einem versteckten Öffentlichen Ordner gespeichert sind, können sie auf mehrere Server repliziert werden.
70
Komponente Funktion Beschreibung
Empfängeraktualisierungsdienst
Anwenden von Empfängerrichtlinien und Erstellen von Proxyadressen
Der Empfängeraktualisierungsdienst (Abv_dg.dll) ist eine Komponente der Systemaufsicht, mit der alle E-Mail-aktivierten Benutzerobjekte und Empfängerrichtlinien überwacht sowie Empfängerrichtlinien auf E-Mail-aktivierte Benutzerobjekte angewendet werden. Weitere Informationen zum Empfängeraktualisierungsdienst finden Sie unter Exchange Server 2003 und Active Directory .
71
Komponente Funktion Beschreibung
Servermonitorkomponente Überwachen von Serverressourcen
Mit der Systemaufsicht werden Serverressourcen in regelmäßigen Abständen überwacht und Verbindungsstatusinformationen mit der Windows-Verwaltungsinstrumentation (WMI, Windows Management Instrumentation) aktualisiert. Darüber hinaus aktualisiert die Systemaufsicht die Routingtabelle, sodass im Routingmodul je nach dem aktuellen Status der Server und Connectors die entsprechenden Routingentscheidungen getroffen werden können. Weitere Informationen zu Verbindungsstatusinformationen finden Sie unter Nachrichtenroutingarchitektur.
Über die Systemaufsicht werden zudem die Nachrichtenverfolgungsprotokolle verwaltet, wenn die Nachrichtenverfolgung auf einem Server aktiviert wurde.
72
Komponente Funktion Beschreibung
Systemaufsichtskomponente Überprüfen der Computerkontokonfiguration
Das Computerkonto eines Exchange-Servers muss Mitglied einer globalen Sicherheitsgruppe mit dem Namen Exchange Domain Servers sein, damit Exchange Server 2003 über die erforderlichen Zugriffsberechtigungen für Active Directory verfügt. Über die Systemaufsicht wird im Hintergrund überprüft, ob das Computerkonto dieser Gruppe angehört.
Exchange-Informationsspeicherdienst Der Microsoft Exchange-Informationsspeicherdienst ist eine andere sehr wichtige Komponente in Exchange Server 2003, da er die Messagingdatenbanken verwaltet, die alle serverbasierten Postfächer und Öffentlichen Ordner enthalten. Die ausführbare Datei für den Exchange-Informationsspeicherdienst Store.exe befindet sich im Verzeichnis \Programme\Exchsrvr\Bin. Der entsprechende Registrierungsschlüssel lautet HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS.
Der Exchange-Informationsspeicher verwendet ESE (Extensible Storage Engine) zur Verwaltung der Messagingdatenbanken und unterstützt eine Vielzahl von Clients über die entsprechenden Informationsspeichererweiterungen. In der folgenden Abbildung ist dargestellt, auf welche Weise die verschiedenen Clienttypen auf Messagingdaten zugreifen können.
73
Architektur des Exchange-Informationsspeichers und unterstützte Messagingclients
MAPI-Clients kommunizieren über MAPI-RPCs direkt mit dem Exchange-Informationsspeicherdienst. Internetclients verwenden dagegen die in IIS integrierten Protokollmodule, wie weiter oben in diesem Abschnitt beschrieben. Internetclients und Webanwendungen kommunizieren über IIS-Protokollmodule mit dem Exchange-Informationsspeicher. Diese Kommunikation findet mithilfe des Informationsspeichertreibers Epoxy.dll und Informationsspeichererweiterungen statt, z. B. ExSMTP.dll oder ExIMAP.dll. Die EPOXY-Schicht ist ein schnelles, auf freigegebenem Arbeitsspeicher beruhendes Verfahren zur Interprozesskommunikation (IPC), mit dem die Verarbeitung durch Drviis.dll und Informationsspeichererweiterungen koordiniert wird. Bei der Übermittlung einer eingehenden Nachricht über SMTP verwendet Drviis.dll beispielsweise das installierbare Dateisystem von Exchange zur Erstellung eines Nachrichtenobjekts im Exchange-Informationsspeicher. Anschließend
74
kommuniziert Drviis.dll über EPOXY mit ExSMTP.dll, um den Exchange-Informationsspeicher anzuweisen, die Nachricht weiterzuverarbeiten (d. h., die Nachricht im Postfach des Empfängers abzulegen). Weitere Informationen zur Interaktion zwischen Drviis.dll, Epoxy.dll, Informationsspeichererweiterungen, Store.exe und ExIFS finden Sie unter Architektur des Exchange-Informationsspeicherdiensts.
Installierbares Dateisystem von Exchange Das in ExIfs.sys implementierte installierbare Dateisystem von Exchange ist ein Kernelmodustreiber, über den IIS-Protokollmodule und Webanwendungen Objekte in Messagingdatenbanken schreiben und lesen können. Für den Zugriff auf die Datenbanken muss der ExIFS-Dateisystemtreiber mit dem Exchange-Informationsspeicher kommunizieren. Dies erfolgt über eine Informationsspeichererweiterung (ExWin32.Dll) und einen Benutzermoduswrapper (Ifsproxy.dll). Der Exchange-Informationsspeicher verwendet dagegen ESE für den Zugriff auf STM- und EDB-Dateien. Dabei handelt es sich um Dateien auf einem NTFS-Laufwerk. Die folgende Abbildung zeigt diese Architektur.
ExIFS-Architektur
Wie in Technische Übersicht über Exchange Server 2003 erwähnt, setzt sich ein Postfachspeicher oder ein Informationsspeicher für Öffentliche Ordner aus einer Streamingdatenbank (STM-Datei) und einer MAPI-Datenbank (EDB-Datei) zusammen. Die IIS-Komponenten verwenden ExIFS für Streamingdatenbanken, während MAPI-Clients, z. B. Outlook, die MAPI-basierten Datenbanken (EDB-Dateien) verwenden. Eine Streamingdatenbank enthält Internetnachrichten im ursprünglichen Format, z. B. MIME, während E-Mail-Nachrichten in einer EDB-Datenbank im MAPI-Format gespeichert werden. Im Exchange-Informationsspeicher müssen die Streamingdatenbanken und die entsprechenden MAPI-basierten Datenbanken synchronisiert gespeichert sein. Zu diesem Zweck muss der Exchange-Informationsspeicher, zusätzlich zu ESE, mit ExIFS kommunizieren. Beim Zuweisen von freiem Speicherplatz in einer Datenbank wird
75
beispielsweise über ExIFS Speicherplatz von ESE angefordert. Über ESE wird ermittelt, welche Seiten in der Streamingdatenbank reserviert und zugewiesen sind. Daher ist der Exchange-Informationsspeicherdienst von ExIFS abhängig. Der Registrierungsschlüssel für ExIFS lautet HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EXIFS. Weitere Informationen zu ExIFS und zur Architektur des Exchange-Informationsspeichers finden Sie unter Architektur des Exchange-Informationsspeicherdiensts.
Hinweis: ExIFS ist die einzige Kernelmoduskomponente in Exchange Server 2003.
Zusätzliche Dienste von Exchange Server 2003Zusätzlich zu den IIS-Protokollmodulen und Hauptdiensten von Exchange Server 2003 werden über die folgenden Exchange-Dienste weitere Funktionen bereitgestellt:
Kalender-Connector Über den Kalender-Connectordienst können Frei-/Gebucht-Informationen von Exchange Server 2003-Benutzern und Lotus Notes- oder Novell GroupWise-Benutzern gemeinsam verwendet werden. Dieser Dienst ist abhängig vom Ereignisprotokoll, vom Exchange-Informationsspeicherdienst und vom Microsoft Exchange-Verbindungscontroller. Weitere Informationen zur Architektur des Kalender-Connectors finden Sie unter Architektur von Gateway-Messaging-Connectors.
Die ausführbare Datei Calcon.exe ist im Verzeichnis \Programme\Exchsrvr\Bin gespeichert. Der Registrierungsschlüssel lautet HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeCalCon.
Verbindungscontroller Über den Verbindungscontrollerdienst werden Dienste für Connector für Lotus Notes, Connector für Novell GroupWise und Kalender-Connector unterstützt. Der Dienst ist abhängig vom Ereignisprotokolldienst und der Systemaufsicht. Zusätzliche Informationen zur Architektur des Verbindungscontrollers finden Sie unter Architektur von Gateway-Messaging-Connectors.
Die ausführbare Datei Lscntrl.exe ist im Verzeichnis \Programme\Exchsrvr\Bin gespeichert. Der Registrierungsschlüssel lautet HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeCOCO.
Connector für Lotus Notes Über Connector für Lotus Notes wird die Nachrichtenübertragung und die Verzeichnissynchronisierung zwischen Exchange Server 2003 und Lotus Notes ermöglicht. Der Dienst ist abhängig vom Ereignisprotokolldienst, vom Verbindungscontroller und vom Exchange-Informationsspeicherdienst. Weitere Informationen zur Architektur des Connectors für Lotus Notes finden Sie unter Architektur von Gateway-Messaging-Connectors.
76
Die ausführbare Datei Dispatch.exe wird mit LME-NOTES-Befehlszeilenparametern gestartet. Dadurch werden die Lotus Notes-spezifischen Connectorprozesse gestartet. Dispatch.exe ist im Verzeichnis \Programme\Exchsrvr\Bin gespeichert. Der Registrierungsschlüssel lautet HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LME-NOTES.
Connector für Novell GroupWise Über Connector für Novell GroupWise wird die Nachrichtenübertragung und die Verzeichnissynchronisierung zwischen Exchange Server 2003 und Novell GroupWise ermöglicht. Dieser Dienst ist abhängig vom Ereignisprotokolldienst, vom Verbindungscontroller, vom Router für Novell GroupWise und vom Exchange-Informationsspeicherdienst. Weitere Informationen zur Architektur des Connectors für Novell GroupWise finden Sie unter Architektur von Gateway-Messaging-Connectors.
Die ausführbare Datei Dispatch.exe wird mit LME-GWISE-Befehlszeilenparametern gestartet. Dadurch werden die Novell GroupWise-spezifischen Connectorprozesse gestartet. Dispatch.exe ist im Verzeichnis \Programme\Exchsrvr\Bin gespeichert. Der Registrierungsschlüssel lautet HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LME-GWISE.
Exchange-Ereignisdienst Über den Exchange-Ereignisdienst werden Ordner überwacht und Ereignisse für Serverskripts ausgelöst, die mit Exchange Server 5.5 kompatibel sind. Dieser Dienst ist nur erforderlich, wenn Exchange Server 5.5-kompatible Anwendungen auf einem Exchange Server 2003-Server ausgeführt werden. Der Dienst ist in der Standardeinstellung deaktiviert. Dieser Dienst ist abhängig vom Exchange-Informationsspeicherdienst. Die ausführbare Datei Events.exe ist im Verzeichnis \Programme\Exchsrvr\Bin gespeichert. Der Registrierungsschlüssel lautet HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeES.
Exchange-Verwaltungsdienst Mit diesem Dienst werden über die Windows-Verwaltungsinstrumentation (WMI, Windows Management Instrumentation) Exchange-Verwaltungsinformationen bereitgestellt. Wenn der Dienst beendet wird, werden die in der Microsoft Exchange-Verwaltung implementierten WMI-Anbieter, z. B. die Nachrichtenverfolgung oder der Active Directory-Zugriff, nicht ausgeführt. Aus diesem Grund sollte dieser Dienst auf allen Servern mit Exchange Server ausgeführt werden, sodass die Domänencontroller und globalen Katalogserver für einen Exchange Server 2003-Server angezeigt und festgelegt werden können sowie der Nachrichtenfluss in Exchange über den Nachrichtenstatus überwacht werden kann. Für den Verzeichniszugriff können Sie mit dem Exchange-System-Manager manuell einen Domänencontroller oder einen globalen Katalogserver konfigurieren. Öffnen Sie dazu die Seite Eigenschaften auf dem Server, und verwenden Sie anschließend die Optionen auf der Registerkarte Verzeichniszugriff. Auf den Servern mit Exchange Server wird dann über die angegebenen Server auf das Verzeichnis zugegriffen.
Der Exchange-Verwaltungsdienst ist abhängig vom RPC-Dienst und vom WMI-Dienst. Die ausführbare Datei Exmgmt.exe ist im Verzeichnis \Programme\Exchsrvr\Bin
77
gespeichert. Der Registrierungsschlüssel lautet HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMGMT.
Microsoft Exchange MTA-Stacks-Dienst Mit dem Microsoft Exchange MTA-Stacks-Dienst (MTA) werden Nachrichten über X.400- und Gatewayconnectors an nicht auf Exchange basierte Messagingsysteme weitergeleitet. In einer gemischten Umgebung mit Exchange Server 5.5-Servern in der lokalen Routinggruppe werden Nachrichten mit MTA auch zwischen Exchange Server 2003 und Exchange Server 5.5 übertragen. Die Übertragung erfolgt auf diese Weise, da die einzelnen Exchange Server 5.5-MTAs am lokalen Standort direkt über RPCs miteinander kommunizieren. Exchange Server 2003 verwendet dieses Kommunikationsverfahren aus Gründen der Abwärtskompatibilität.
Die ausführbare Datei des Microsoft Exchange-MTA-Stacks-Diensts EMSMTA.exe ist im Verzeichnis \Programme\Exchsrvr\bin gespeichert. Dieser Dienst ist abhängig von der Systemaufsicht und verwaltet eigene spezielle Nachrichtenwarteschlangen außerhalb des Exchange-Informationsspeichers im Verzeichnis \Programme\Exchsrvr\Mtadata. Der Registrierungsschlüssel lautet HKEY_Local_Machine\System\CurrentControlSet\Services\MSExchangeMTA.
Hinweis: Der Microsoft Exchange-MTA-Stacks-Dienst sollte ausgeführt werden, sodass bei Serverüberwachungen in der Standardkonfiguration kein Server mit Exchange Server als nicht verfügbar angezeigt wird. Weitere Informationen zum Verfolgen des Serverstatus finden Sie unter Architektur des Exchange-System-Managers.
Router für Novell GroupWise Über den Dienst Router für Novell GroupWise in Verbindung mit Connector für Novell GroupWise wird die Nachrichtenübertragung sowie die Verzeichnissynchronisierung zwischen Exchange Server 2003 und Novell GroupWise ausgeführt. Der Dienst Router für Novell GroupWise und das Novell GroupWise-API-Gateway bilden eine Schnittstelle, Connector für Novell GroupWise und Exchange Server 2003 eine andere Schnittstelle. Weitere Informationen zur Architektur des Connectors für Novell GroupWise finden Sie unter Architektur von Gateway-Messaging-Connectors.
Der Dienst Router für Novell GroupWise ist abhängig von der Systemaufsicht. Die ausführbare Datei GWRouter.exe ist im Verzeichnis \Programme\Exchsrvr\Bin gespeichert. Der Registrierungsschlüssel lautet HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeGWRtr.
Routingmodul Über den Routingmoduldienst werden Topologie- und Routinginformationen für Server bereitgestellt, auf denen Exchange Server 2003 ausgeführt wird. Mit dem erweiterten Warteschlangenmodul im SMTP-Transportsubsystem werden beim Weiterleiten von Nachrichten in der Exchange-Organisation über diesen Dienst Informationen über den nächsten Hop zur Verfügung gestellt. Wenn dieser Dienst beendet wird, ist das optimale Routing von Nachrichten nicht
78
verfügbar. Zusätzliche Informationen zum Routingmoduldienst und dessen Rolle bei der Nachrichtenübermittlung finden Sie unter SMTP-Transportarchitektur.
Der Routingmoduldienst ist abhängig vom IIS-Verwaltungsdienst und wird im Prozess Inetinfo.exe ausgeführt. Dieser Dienst ist in der Datei RESvc.dll implementiert und im Verzeichnis \Programme\Exchsrvr\Bin gespeichert. Der Registrierungsschlüssel lautet HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RESvc..
Standortreplikationsdienst Der Standortreplikationsdienst (Site Replication Service, SRS) stellt die Verzeichnisintegration zwischen Exchange Server 5.5 und Exchange Server 2003 bereit. SRS wird unter Exchange Server 2003 ausgeführt und stellt ein geändertes Exchange Server 5.5-Verzeichnis dar. Exchange Server 5.5 reagiert auf SRS als Replikationspartner eines Exchange Server 5.5-Verzeichnisses. SRS wird automatisch auf dem ersten Server aktiviert, der an einen Exchange Server 5.5-Standort angeschlossen wird. Wenn der letzte Server mit Exchange Server 5.5 aus dem Netzwerk entfernt wird, kann SRS deaktiviert werden.
SRS ist von keinem anderen Dienst abhängig. Dieser Dienst ist in der ausführbaren Datei srsmain.exe implementiert und im Verzeichnis \Programme\Exchsrvr\Bin gespeichert. Der Registrierungsschlüssel lautet HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSRS..
In der folgenden Abbildung ist die Integration der zusätzlichen Dienste in die Hauptdienste von Exchange, IIS und des Betriebssystems dargestellt.
79
Hauptdienste und zusätzliche Dienste von Exchange Server 2003
Tipp Wenn Sie alle Exchange Server 2003-Dienste auf einem Server beenden möchten, müssen Sie die Systemaufsicht, den IIS-Verwaltungsdienst, ExIFS, SRS (wenn dieser Dienst ausgeführt wird) sowie alle abhängigen Dienste beenden. Ausführliche Anweisungen zum Beenden aller Exchange Server 2003-Dienste auf einem Server finden Sie unter Beenden aller Exchange Server 2003-Dienste auf einem Server .
Beenden aller Exchange Server 2003-Dienste auf einem ServerIn diesem Thema wird das Beenden aller Exchange Server 2003-Dienste auf einem Server erläutert.
80
Bevor Sie beginnenBevor Sie das Verfahren in diesem Thema durchführen, sollten Sie Folgendes berücksichtigen:
Wenn Sie alle Exchange Server 2003-Dienste auf einem Server beenden möchten, müssen Sie die Systemaufsicht, den IIS-Verwaltungsdienst, ExIFS, SRS (wenn dieser Dienst ausgeführt wird) sowie alle abhängigen Dienste beenden. Die einfachste Möglichkeit, alle Dienste erneut zu starten, besteht im Neustart des Servers.
VerfahrenBeenden aller Exchange Server 2003-Dienste auf einem Server
1. Mit dem Befehl net stop MSExchangeSA /y können Sie die Systemaufsicht und alle abhängigen Dienste beenden.
2. Mit dem Befehl net stop IISAdmin /y beenden Sie alle IIS-Module.
3. Mit dem Befehl net stop ExIFS können Sie den ExIFS-Treiber Exchange Installable File System) beenden.
4. Mit dem Befehl net stop MSExchangeSRS beenden Sie SRS.
Exchange Server 2003 und Active DirectoryDie Verzeichnisoperationen von Microsoft Exchange Server 2003 beruhen vollständig auf dem Microsoft Active Directory-Verzeichnisdienst. Active Directory stellt alle Postfachinformationen, Adresslistendienste und andere Informationen zu Empfängern bereit. Die meisten Konfigurationsinformationen von Exchange 2003 sind ebenfalls in Active Directory gespeichert. Die Systemaufsicht ist die Komponente in Exchange 2003, über die der Verzeichniszugriff verwaltet wird. Die Systemaufsicht enthält mehrere interne Komponenten, z. B. DSAccess und DSProxy, die mit Active Directory kommunizieren und Verzeichnisinformationen zwischenspeichern. Dadurch wird die Geschwindigkeit beim Abruf der Verzeichnisinformationen erhöht sowie die Auslastung von Domänencontrollern und globalen Katalogservern reduziert.
In diesem Abschnitt werden die Verzeichniszugriffskomponenten von Exchange Server 2003, deren Aufgaben und Architektur sowie die Funktionsweise der wichtigsten Technologien erläutert. Anhand dieser Informationen können Sie den Verzeichniszugriff verwalten und Probleme beim Verzeichniszugriff beheben. Folgende Themen werden in diesem Abschnitt behandelt:
81
Erweiterung des Active Directory-Schemas Exchange erweitert das Active Directory-Schema und verwendet Active Directory für Empfänger- und Konfigurationsinformationen.
Unterschiede zwischen Domänencontrollern und globalen Katalogservern Ein globaler Katalogserver ist immer ein Domänencontroller, das Gegenteil trifft jedoch nicht immer zu. Die Unterschiede werden in diesem Abschnitt erörtert, einschließlich der Frage, warum Exchange Server 2003 mit Domänencontrollern und globalen Katalogservern kommunizieren muss.
Verzeichnisdienstzugriffskomponente in Exchange Server 2003 Die DSAccess-Komponente ist eine interne Komponente der Systemaufsicht, die für den Zugriff auf Verzeichnisinformationen und deren Speicherung verwendet wird. DSAccess ermittelt statisch oder dynamisch Verzeichnisdienstserver in der Organisation.
DSProxy-Komponente in Exchange Server 2003 DSProxy ermöglicht die Kommunikation zwischen Active Directory und Exchange 2003-Computern. DSProxy stellt Proxy- und Verweisdienste für MAPI-Clients bereit, z. B. für neuere Versionen von Microsoft Office Outlook.
SMTP-Kategorisierungsmodul im Exchange-Transportmodul Das SMTP-Kategorisierungsmodul muss mit Active Directory kommunizieren, um während der Nachrichtenübertragung Empfängerinformationen aufzulösen und Einschränkungen des Nachrichtenempfangs feststellen zu können. Obwohl sich das Kategorisierungsmodul auf DSAccess stützt, verwendet es zusätzlich ein eigenes Verfahren für die Kommunikation mit Active Directory.
Empfängeraktualisierungsdienst Exchange Server 2003 kommuniziert mit Verzeichnisservern, um Empfängerobjekte (z. B. postfachaktivierte Benutzerkonten oder E-Mail-aktivierte Gruppen) entsprechend den für die Organisation definierten Empfängerrichtlinien mit E-Mail-Adressen zu aktualisieren.
Metabase-Aktualisierungsdienst Der Metabase-Aktualisierungsdienst muss mit Active Directory kommunizieren, um Konfigurationseinstellungen von Komponenten der Internetinformationsdienste (IIS) abzurufen, z. B. vom SMTP-Dienst und dem WWW-Dienst. Diese Einstellungen werden vom Metabase-Aktualisierungsdienst in die IIS-Metabase übertragen.
Weitere Informationen über die Planung, den Entwurf und die Bereitstellung von Exchange 2003 finden Sie in den folgenden Handbüchern:
Planning an Exchange Server 2003 Messaging System
Exchange Server 2003 Deployment Guide
82
Verzeichnisintegration und Exchange Server 2003Die Exchange Server 2003-Informationen in Active Directory umfassen Informationen über Empfänger sowie Konfigurationsinformationen über die Messagingorganisation. Active Directory stellt das Sicherheitssubsystem für Exchange Server 2003 bereit. Mit den Active Directory-Sicherheitsfunktionen wird gewährleistet, dass nur autorisierte Benutzer auf Postfächer zugreifen können und dass ausschließlich autorisierte Administratoren die Exchange-Konfiguration in der Organisation ändern können.
Die folgenden drei Verzeichnispartitionen in Active Directory enthalten Exchange-Daten:
Domänenverzeichnispartition Empfänger- und Systemobjekte von Exchange werden in der Domänenverzeichnispartition von Active Directory gespeichert. Die Domänenverzeichnispartition wird auf jeden Domänencontroller in einer bestehenden Domäne repliziert.
Konfigurationsverzeichnispartition Exchange-Konfigurationsobjekte wie administrative Gruppen, globale Einstellungen, Empfängerrichtlinien, Systemrichtlinien und Adresslisten oder Adressinformationen werden in der Konfigurationsverzeichnispartition gespeichert. Die Konfigurationsverzeichnispartition wird auf alle Domänencontroller in der Gesamtstruktur repliziert.
Schemaverzeichnispartition Änderungen am Exchange-Schema (z. B. Klassen und Attribute) werden in der Schemaverzeichnispartition gespeichert. Die Schemaverzeichnispartition wird auf alle Domänencontroller in der Gesamtstruktur repliziert.
Hinweis: Nicht alle Konfigurationsinformationen werden in Active Directory gespeichert. Exchange verwendet darüber hinaus die lokale Registrierung, die IIS-Metabasis und in besonderen Fällen auch Konfigurationsdateien.
Exchange-Klassen und -Attribute in Active DirectoryIm Active Directory-Schema werden die Objektklassen definiert, die im Verzeichnis erstellt werden können, sowie die Attribute, die jeder Instanz eines Objekts zugewiesen werden können. Bei der Installation des ersten Exchange 2003-Servers in einer Active Directory-Gesamtstruktur muss dieses Schema von Exchange geändert werden, sodass Exchange-spezifische Empfänger- und Konfigurationsinformationen von Active Directory gespeichert werden können. Mit dem Prozess ForestPrep im Exchange-Setup wird das Active Directory-Schema erweitert. Sie können diesen Prozess auch explizit über die Befehlszeile
83
Setup/ForestPrep ausführen, um dem Active Directory-Schema Exchange-spezifische Klassen und Attribute hinzuzufügen, ohne einen Server zu installieren. Dieser zusätzliche Schritt ist notwendig, wenn beim Installieren von Exchange Server 2003 keine Administratorrechte für das Schema vorliegen.
Das Setupprogramm von Exchange Server 2003 erweitert das Active Directory-Schema durch Importieren mehrerer LDF-Dateien in Active Directory. Mit Ausnahme von Exschema.ldf befinden sich alle LDF-Dateien auf der Produkt-CD im Verzeichnis \Setup\i386\Exchange. Exschema.ldf befindet sich im Verzeichnis \Setup\i386\Exchange\Bin.
In der folgenden Tabelle sind die unterschiedlichen LDF-Dateien aufgeführt, mit denen Objekte und Attribute für Exchange Server 2003 definiert werden.
Exchange Server 2003-Installationsdateien mit Active Directory-Schemaerweiterungen
Dateiname Beschreibung
Schema0.ldf Enthält Schemaerweiterungen für Empfängerobjekte, z. B. die Definition der Exchange-Erweiterungsattribute, die zum Zuweisen der nicht über ein Standardattribut definierten Informationen zu Empfängerobjekten verwendet werden können.
Schema1.ldf Enthält Schemaerweiterungen für Active Directory Connector, die für die Integration einer Exchange Server 5.5-Organisation in Active Directory verwendet werden können.
Schema2.ldf Enthält Schemaerweiterungen für Internetzugriffsprotokolle, die Verzeichnissynchronisierung und für Konfigurationsobjekte des Exchange-Informationsspeichers.
Schema3.ldf Enthält Schemaerweiterungen für die Systemüberwachung, für Konfigurationsobjekte von Connector für Lotus Notes, für Einstellungen des Offlineadressbuchs sowie Einstellungen für X.400-Connectors.
84
Dateiname Beschreibung
Schema4.ldf Enthält Schemaerweiterungen für Routinggruppen, Bridgeheadserver, Protokollcontainer, Messagingdatenbanken, Adresslistendienste und Microsoft Exchange MTA-Konfigurationsobjekte.
Schema5.ldf Enthält Schemaerweiterungen für Protokollcontainer, Routinggruppenconnectors und ESE-Parameter (Extensible Storage Engine).
Schema6.ldf Enthält Schemaerweiterungen für virtuelle Protokollserver, administrative Gruppen, Messagingconnectors und den Exchange-Informationsspeicher.
Schema7.ldf Enthält Schemaerweiterungen für Messagingdatenbanken und den Postfach-Manager.
Schema8.ldf Enthält Schemaerweiterungen für den Postfach-Manager, die Systemüberwachung, Öffentliche Ordner und Konfigurationsobjekte des SMTP-Transports.
Schema9.ldf Enthält Schemaerweiterungen für Kalender-Connector, Connector für Novell GroupWise, dynamische Verteilerlisten, Messagingordner und Outlook Mobile Access.
Hinweis: Schema1.ldf bis Schema8.ldf sind für Exchange 2000 Server und Exchange Server 2003 identisch. Schema9.ldf enthält die Schemaerweiterungen, die unter Exchange Server 2003 neu sind.
85
Dateiname Beschreibung
Exschema.ldf Fügt dem Schema Attribute für Objekt-GUID, Replikationssignatur, Unmerged-Attributes und ADC-Global-Names hinzu, sodass ein Schema aus Versionen vor Exchange 2000 Service Pack 1 mit den für Exchange Server 2003 erforderlichen Informationen aktualisiert wird.
Hinweis: Sie können LDF-Dateien in Verbindung mit funktionsorientierten Active Directory-Tools (z. B. Ldifde.exe) zum Reparieren eines beschädigten Active Directory-Schemas verwenden. Die Problembehandlung des Active Directory-Schemas geht jedoch über den Rahmen dieses Handbuchs hinaus. Beachten Sie, dass der globale Katalog aufgrund von Schemaänderungen möglicherweise zurückgesetzt wird. In diesem Fall müssen alle Empfängerobjekte erneut auf den globalen Katalog repliziert werden. Dies führt in größeren Organisationen unter Umständen zu einem erheblich erhöhten Datenverkehr.
VerzeichnisdienstzugriffExchange 2003-Dienste greifen auf die in Active Directory gespeicherten Informationen zu und schreiben Informationen in Active Directory. Wenn zwischen jedem Dienst und Active Directory direkte Kommunikation stattfindet, werden Active Directory-Domänencontroller möglicherweise mit Kommunikationsanforderungen von Exchange 2003 überlastet. Die Kommunikation mit Active Directory muss daher durch eine zentrale Komponente optimal gesteuert werden. Bei dieser Komponente handelt es sich um das DSAccess-Modul.
DSAccess ist eine freigegebene API, über die von mehreren Komponenten in Exchange 2003 Konfigurations- und Empfängerinformationen von Active Directory abgefragt werden. DSAccess wird in DSAccess.dll implementiert. Diese Datei wird in Exchange-Komponenten und in Exchange-fremden Komponenten geladen, u. a. in der Systemaufsicht, in Message Transfer Agent, im Microsoft Exchange-Informationsspeicherdienst, im Exchange-Verwaltungsdienst, in den Internetinformationsdiensten (IIS) und der Windows-Verwaltungsinstrumentation (WMI – Windows Management Instrumentation). DSAccess analysiert die Active Directory-Topologie, ermittelt Domänencontroller und globale Katalogserver und verwaltet eine Liste gültiger für die Verwendung von Exchange-Komponenten geeigneter Verzeichnisserver. DSAccess verfügt darüber hinaus über einen Cache, mit dem die Auslastung von Active Directory durch Reduzieren der LDAP-Abfragen (Lightweight Directory Access Protocol) verringert wird, die einzelne Komponenten an Active Directory-Server senden.
86
Wichtig: DSAccess.dll ist die primäre DLL-Datei für die Implementierung von DSAccess. Damit DSAccess.dll ordnungsgemäß ausgeführt wird, muss die Version von DSAccess.dll mit der Version der DLL-Begleitdateien übereinstimmen. Die DLL-Begleitdateien Dscmgs.dll und Dscperf.dll speichern Ereignisprotokollnachrichten bzw. Leistungsobjektanbieter.
DSAccess unterteilt die verfügbaren Verzeichnisdienstserver in die folgenden drei (sich möglicherweise überschneidenden) Kategorien:
Globale Katalogserver Exchange Server 2003 muss auf globale Katalogserver zugreifen, um vollständige Adressinformationen für alle Empfängerobjekte in der Gesamtstruktur abzurufen. Nur globale Katalogserver enthalten ein vollständiges Replikat aller Objekte in der Domäne und ein Teilreplikat aller Objekte in der Gesamtstruktur. Die von einem Exchange-Server aktuell verwendeten globalen Katalogserver werden als aktive globale Katalogserver bezeichnet.
Fast alle benutzerbezogenen Exchange Server 2003-Verzeichnisdiensttransaktionen richten sich an globale Kataloge. Unabhängig von der Anzahl der globalen Katalogserver am lokalen Active Directory-Standort können maximal zehn globale Katalogserver zur Liste der aktiven globalen Kataloge hinzugefügt werden. Wenn sich am lokalen Standort keine globalen Katalogserver befinden oder keiner der globalen Katalogserver am lokalen Standort die Verwendungstests besteht, verwendet DSAccess maximal 200 globale Katalogserver an Remotestandorten mit den geringsten Kosten. Da der für einen globalen Katalog verwendete Verzeichnisdienstserver auch ein Domänencontroller ist, kann der Server für beide Arten von Verzeichnissen verwendet werden.
Domänencontroller Domänencontroller werden für benutzerbezogene Anforderungen verwendet, wenn dem anfordernden Dienst bei der gesendeten Suche ausreichende Angaben zum Speicherort des angeforderten Benutzerobjekts vorliegen. Diese Domänencontroller werden auch als aktive Domänencontroller bezeichnet. Aktive Domänencontroller sind Domänencontroller in der lokalen Domäne, die Abfragen im Zusammenhang mit Domänennamen annehmen können. Unabhängig von der Anzahl der Domänencontroller am lokalen Active Directory-Standort können maximal zehn Domänencontroller zur Liste der aktiven Domänencontroller hinzugefügt werden. Wenn sich am lokalen Standort keine Domänencontroller befinden oder keiner der Domänencontroller am lokalen Standort die Verwendbarkeitstests besteht, verwendet DSAccess Domänencontroller an Remotestandorten mit den geringsten Kosten.
Für Abfragen an aktive Domänencontroller wird ein Lastenausgleich auf Grundlage des Round-Robin-Verfahrens durchgeführt, damit einzelne Domänencontroller nicht überlastet werden. Wenn die aktiven Domänencontroller in der Registrierung nicht festgelegt sind, wird die Liste der aktiven Domänencontroller mithilfe des Topologieerkennungsprozesses und Verwendbarkeitstests alle 15 Minuten neu überprüft und neu erstellt.
87
Konfigurationsdomänencontroller Exchange Server 2003 kann Daten von mehreren Domänencontrollern lesen. Zur Vermeidung von Konflikten bei Konfigurationsänderungen von Active Directory werden die Konfigurationsinformationen von Exchange Server 2003 auf einem einzigen Domänencontroller gespeichert, dem so genannten Konfigurationsdomänencontroller. Bei der Auswahl eines Konfigurationsdomänencontrollers aus der Liste der aktiven Domänencontroller zieht DSAccess einen Domänencontroller einem globalen Katalogserver vor. Darüber hinaus hat ein Verzeichnisserver am lokalen Standort für DSAccess Vorrang vor einem Verzeichnisserver an einem sekundären Standort.
Wenn der Konfigurationsdomänencontroller in Exchange Server 2003 nicht verfügbar sein sollte, wählt DSAccess einen anderen aktiven Domänencontroller als Konfigurationsdomänencontroller aus. Die Funktion des Konfigurationsdomänencontrollers wird von DSAccess alle acht Stunden mithilfe verschiedener Verwendbarkeitstests neu überprüft. Nach erfolgreicher Durchführung der Tests wird der entsprechende Konfigurationsdomänencontroller weiterhin verwendet. Andernfalls wird ein anderer Domänencontroller aus der Liste der aktiven Domänencontroller als Konfigurationsdomänencontroller ausgewählt.
Für die Hauptkomponenten von Exchange Server 2003 wird über DSAccess eine aktuelle Liste der Active Directory-Server bereitgestellt. Der MTA (Message Transfer Agent) leitet beispielsweise LDAP-Abfragen über die DSAccess-Schicht an Active Directory weiter. Beim Herstellen einer Verbindung mit Datenbanken verwendet der Speicherprozess DSAccess, um Konfigurationsinformationen von Active Directory abzurufen. Bei der Nachrichtenweiterleitung verwendet der Transportprozess DSAccess zum Abrufen von Informationen über die Connectoranordnung.
DSAccess aktualisiert die Liste der verfügbaren globalen Kataloge und Domänencontroller bei Änderungen des Verzeichnisdienststatus. Diese Liste kann auch von anderen Verzeichnisbenutzern verwendet werden, die DSAccess nicht als Gateway für den Zugriff auf den Verzeichnisdienst einsetzen (z. B. DSProxy und andere Komponenten in der Systemaufsicht). Mit dem Dienst, über den die Liste angefordert wird, werden die nachfolgenden Statusänderungen im Verzeichnisdienst ermittelt.
Hinweis: Wenn Domänencontroller und globale Katalogserver in der Registrierung nicht festgelegt sind, wird die Liste der globalen Katalogserver und Domänencontroller alle 15 Minuten mithilfe eines Topologieerkennungsprozesses und Verwendbarkeitstests neu überprüft und neu erstellt.
88
Lastenausgleich und Failover durch LDAP-VerbindungenDSAccess ermittelt in Exchange Server 2003 die Active Directory-Topologie, öffnet die entsprechenden LDAP-Verbindungen und gleicht Serverausfälle aus. Für jeden verfügbaren Verzeichnisdienstserver werden von DSAccess LDAP-Verbindungen geöffnet, die ausschließlich dem jeweiligen Prozess zugewiesen sind, der DSAccess verwendet. DSAccess aktualisiert diese LDAP-Verbindungen mit den ermittelten Statusinformationen des Verzeichnisdiensts (aktiv, langsam oder inaktiv). Anhand dieser Statusinformationen legt DSAccess fest, über welche LDAP-Verbindung Anforderungen an Active Directory weitergeleitet werden. Die LDAP-Verbindungen zu verfügbaren Domänencontrollern und globalen Katalogservern sowie die zugeordneten Statuswerte ergeben das DSAccess-Profil.
DSAccess unterstützt ein Lastenausgleichsverfahren, bei dem benutzerbezogene Verzeichnisdienstanforderungen mit einer Round-Robin-Methode auf die LDAP-Verbindungen im DSAccess-Profil verteilt werden. Durch den Lastenausgleich wird die Zuverlässigkeit und Skalierbarkeit sichergestellt. Sie können alle Profile in der Registrierung statisch konfigurieren, sodass nur ein bestimmter Satz von Verzeichnisdienstservern verwendet wird. Der tatsächliche Status und Lastenausgleich dieser Verbindungen fällt jedoch möglicherweise bei den einzelnen Prozessen (Profilen) unterschiedlich aus. Dies trifft auf konfigurationsbezogene Anforderungen nicht zu.
Hinweis: Da bei allen Exchange Server 2003- und IIS-Diensten der gleiche Sicherheitskontext (das lokale Systemkonto) verwendet wird, können die LDAP-Verbindungen über DSAccess bei verschiedenen Anforderungen erneut verwendet werden. Beim Starten oder bei einer Topologieänderung werden über DSAccess LDAP-Verbindungen zu allen verwendbaren Domänencontrollern und globalen Katalogservern in der Topologie geöffnet.
Wenn die Microsoft Windows-basierte Implementierung von LDAP (WLDAP) einen Fehler bei einer LDAP-Operation zurückgibt, analysiert DSAccess diesen Fehler und ermittelt, ob der Fehler auf Probleme auf dem Verzeichnisserver zurückzuführen ist. Wenn dies der Fall ist, wird der Verzeichnisserver sofort als ungeeignet gekennzeichnet und die Benutzeroperation automatisch auf einem anderen Server erneut ausgeführt. Wenn in der Topologie mindestens ein ordnungsgemäß arbeitender Domänencontroller vorhanden ist, kann der Vorgang mit DSAccess fehlerlos fortgesetzt werden.
Zum Überprüfen der Verwendbarkeit eines Domänencontrollers oder globalen Katalogservers stellt DSAccess fest, ob der Server über Port 389 (Domänencontroller) bzw. Port 3268 (globaler Katalogserver) erreichbar ist und ob er sich in einer mit DomainPrep vorbereiteten Domäne befindet. Durch DomainPrep wird sichergestellt, dass die Zugriffssteuerungsliste (ACL – Access Control List) für das Gruppenrichtliniensystem so konfiguriert ist, dass mit Exchange Server 2003-Diensten auf Active Directory zugegriffen werden kann. Die Verwendbarkeitstests für Server werden weiter unten in diesem Abschnitt behandelt.
89
Tipp: Wenn Berichte über die Verwendbarkeit im Anwendungsereignisprotokoll aufgenommen werden sollen, aktivieren Sie im Exchange-System-Manager das Diagnoseprotokoll für die Topologiekategorie des DSAccess-Diensts.
Die DSAccess-Topologie enthält immer zwei Listen, die Liste „am Standort“ und die Liste „außerhalb des Standorts“. Eine Liste („am Standort“) enthält Server am lokalen Active Directory-Standort des Exchange-Servers und die andere Liste („außerhalb des Standorts“) Server von anderen Active Directory-Standorten. Anfangs werden nur Server vom lokalen Standort verwendet. Wenn jedoch alle lokalen Server einer bestimmten Kategorie (z. B. globale Katalogserver) nicht verwendbar sind, wird unmittelbar die Liste der Server außerhalb des Standorts verwendet. Der lokale Standort wird dann alle fünf Minuten überprüft, und Zugriffe werden so schnell wie möglich wieder auf lokalen Servern durchgeführt. Benutzeranforderungen an Server außerhalb des Standorts werden unmittelbar und für Benutzer unbemerkt wiederholt.
Einige Exchange Server 2003-Komponenten (z. B. der Exchange-Routingmoduldienst) registrieren sich bei Active Directory, um bei jeder Änderung an den Konfigurationsinformationen automatisch informiert zu werden. Durch dieses Benachrichtigungsverfahren werden Abrufvorgänge ausgeschlossen, die Ereignisregistrierung muss jedoch für jeden Zielserver festgelegt werden. Wenn der Zielserver als inaktiv gekennzeichnet ist, wird die Ereignisregistrierung neu gesendet und der Client (z. B. der Routingmoduldienst) über eine Änderung informiert, da die überwachten Werte bei der Auswahl eines neuen Domänencontrollers oder globalen Katalogservers möglicherweise geändert wurden.
DSAccess-TopologieerkennungBeim Starten von DSAccess wird ein Suchprozess zum Identifizieren der Active Directory-Topologie und zum Ermitteln der verfügbaren Domänencontroller und globalen Katalogserver durchgeführt. Nach dem Starten (und anschließend alle 15 Minuten) ermittelt DSAccess die Topologie mit einem fast identischen Prozess erneut. Gleichzeitig werden Änderungen in der Verfügbarkeit der Server überprüft.
Hinweis: Wenn Sie die von DSAccess verwendeten Verzeichnisserver festlegen (siehe unten stehende Erläuterungen), wird die Topologieerkennung umgangen und nur die Verwendbarkeit der Server überprüft.
In der folgenden Aufstellung wird der Suchprozess kurz umrissen. Zudem werden die Unterschiede zwischen der ersten Suche und der Neuerkennung beschrieben:
1. DSAccess.dll wird beim Starten vom Systemaufsichtsprozess (Mad.exe) instantiiert und initialisiert.
90
2. DSAccess stellt eine LDAP-Verbindung mit einem zufällig ausgewählten Domänencontroller in der lokalen Domäne her. Dieser Server wird als Bootstrapserver bezeichnet.
3. DSAccess überprüft in der lokalen Registrierung, ob die Topologie festgelegt ist. Wenn die Topologie festgelegt ist, wird der Suchprozess beendet. Andernfalls wird der Suchprozess fortgesetzt.
4. DSAccess fragt den Bootstrapserver zum Identifizieren der lokalen Domänencontroller und globalen Katalogserver ab. Anschließend ermittelt DSAccess die Serververwendbarkeit und weist den Servern Rollen zu.
5. DSAccess fragt den Bootstrapserver ab, um zu ermitteln, welche sekundären Standorte mit dem lokalen Standort verbunden sind. Wenn sekundäre Standorte vorhanden sind, werden die siteLink-Objekte für jeden Standort ausgehend von den geringsten Kosten aufsteigend sortiert. Die Standorte mit den geringsten Kosten werden in einer Liste für die sekundäre Topologie aufgenommen.
6. An den Bootstrapserver wird eine Abfrage zur Identifizierung der an den Standorten der sekundären Topologie vorhandenen Domänencontroller und globalen Katalogserver gesendet.
7. DSAccess identifiziert die Gesamttopologie und erstellt eine Liste der aktiven Domänencontroller und eine Liste der aktiven globalen Katalogserver.
In der Standardeinstellung muss die DSAccess-Initialisierung beim Starten nach einer Minute abgeschlossen sein, andernfalls wird DSAccess beendet. In der Regel genügt eine Minute für die Initialisierung von DSAccess. Wenn die Initialisierung länger als eine Minute dauert, liegt möglicherweise ein Problem im Netzwerk oder in der Topologiekonfiguration vor. Obwohl der Timeoutparameter durch Festlegen eines Registrierungsschlüssels geändert werden kann, sollte zunächst festgestellt werden, aus welchem Grund die Initialisierung unerwartet lange dauert. Konfigurieren Sie den Timeoutwert mit der folgenden Registrierungseinstellung:
Speicherort HKEY_LOCAL_MACHINE\SYSTEM \
CurrentControlSet\Services\
MSExchangeDSAccess
Wert TopoCreateTimeoutSecs
Typ REG_DWORD
Beschreibung Legt den Timeoutwert für die DSAccess-Initialisierung in Sekunden fest, z. B. 0x200. Die Standardeinstellung ist 0x3C Sekunden (1 Minute).
91
Hinweis: Wenn Sie den Diagnoseprotokollierungsgrad für alle Kategorien des Diensts MSExchangeDSAccess auf Maximum festlegen, ruft der Exchange-System-Manager automatisch umfassende Informationen über die Initialisierung von DSAccess ab und speichert diese Informationen im Anwendungsereignisprotokoll.
Erste Suche und laufende neue SucheNach der Active Directory-Topologieerkennung ermittelt DSAccess, ob die in der ermittelten Liste aufgeführten aktiven Domänencontroller und globalen Katalogserver verwendbar sind. Während der ersten Suche und der laufenden neuen Suche ermittelt DSAccess die Serververwendbarkeit mithilfe mehrerer Verwendbarkeitstests. Verwendbarkeitstests lassen sich in zwei Kategorien unterteilen: „harte“ und „weiche“ Tests. Mit harten Tests wird ermittelt, ob der Domänencontroller oder der globale Katalog zur Verwendung geeignet ist. Wenn die harten Tests für einen Server nicht erfolgreich durchgeführt werden, gilt der Server als nicht verwendbar und wird aus der Liste der ermittelten Server entfernt. Die weichen Tests werden nicht durchgeführt.
DSAccess führt die folgenden harten Verwendbarkeitstests durch:
Funktionalität als globaler Katalog DSAccess überprüft, ob der Verzeichnisserver als globaler Katalogserver gekennzeichnet ist. Zu diesem Zweck wird ermittelt, ob das isGlobalCatalogReady-Attribut im RootDSE-Objekt auf TRUE festgelegt ist. Wenn das Attribut auf TRUE festgelegt ist, gilt der Verzeichnisserver als gültiger und verwendbarer globaler Controller.
Erreichbarkeit Mit DSAccess wird über ICMP (Internet Control Message Protocol) ein Ping-Signal an jeden Server gesendet und überprüft, ob der entsprechende Server verfügbar ist. Darüber hinaus wird überprüft, ob der Verzeichnisserver über Port 389 (Domänencontroller) und Port 3268 (globale Katalogserver) erreichbar ist.
Beim Überprüfen der Verfügbarkeit eines Servers über ICMP treten unter Umständen Probleme auf, wenn ICMP nicht von allen Verbindungen im Netzwerk unterstützt wird. Beispiel: Ein Exchange-Server befindet sich möglicherweise in einem Umkreisnetzwerk, bei dem keine ICMP-Verbindungen zwischen dem Exchange-Server und den Domänencontrollern bestehen. Deaktivieren Sie in diesem Fall die ICMP-Überprüfung, und legen Sie den folgenden Registrierungsparameter auf Null fest:
Speicherort HKEY_LOCAL_MACHINE\SYSTEM \
CurrentControlSet\Services\
MSExchangeDSAccess
Wert LdapKeepAliveSecs
Typ REG_DWORD
92
Wert 0x0
Beschreibung Wenn der Registrierungsschlüssel nicht vorhanden oder nicht auf 0 festgelegt ist, verwendet DSAccess das Ping-Protokoll.
Weitere Informationen zum Registrierungsschlüssel LdapKeepAliveSecs finden Sie im Microsoft Knowledge Base-Artikel 320529, „XADM: Using DSAccess in a Perimeter Network Firewall Scenario Requires a Registry Key Setting“.
Vorsicht: Eine fehlerhafte Bearbeitung der Registrierung kann zu ernsthaften Problemen führen, die möglicherweise eine Neuinstallation des Betriebssystems erforderlich machen. Dadurch entstandene Probleme können unter Umständen nicht mehr behoben werden. Sichern Sie vor dem Ändern der Registrierung alle wichtigen Daten.
SACL-Berechtigung für Gruppenrichtlinien Zusätzlich zu den regulären ACL-Berechtigungen wird im Setupprogramm für alle Server mit Exchange 2003 Server eine SACL-Berechtigung (Security Access Control List) zum Anzeigen der ntSecurityDescriptor-Attribute erteilt. Diese Berechtigung wird über das SeSecurityPrivilege-Recht gewährt. DSAccess liest die Sicherheitsbeschreibung des Objekts für die Konfigurationsverzeichnispartition auf dem Server, um die Lesbarkeit der SACL zu überprüfen. Wenn die SACL nicht gelesen werden kann, gilt der Server als nicht verwendbar.
Wichtige Daten Der Verzeichnisserver muss sich in einer Domäne befinden, in der DomainPrep ausgeführt wurde. Die Domäne muss das Exchange Server 2003-Serverobjekt im Exchange-Konfigurationscontainer enthalten.
Synchronisierung DSAccess ermittelt, ob das isSynchronized-Attribut im rootDSE-Objekt des Servers auf TRUE festgelegt ist. Dadurch wird überprüft, ob der Server synchronisiert ist.
Netlogon DSAccess sendet einen DSGetDcName-Remoteprozeduraufruf an den Verzeichnisserver, um die allgemeine Verwendbarkeit zu testen. Wenn der Verzeichnisserver nicht synchronisiert ist, kein Festplattenspeicher mehr zur Verfügung steht oder andere Probleme auftreten, wird er nicht als Verzeichnisserver identifiziert.
In einem Umkreisnetzwerk, in dem RPC-Datenverkehr nicht zulässig ist, kann die NetLogon-Überprüfung nicht durchgeführt werden. Die NetLogon-Überprüfung sendet jedoch weiterhin Remoteprozeduraufrufe bis sie fehlschlägt. Dies kann längere Zeit in Anspruch nehmen. Da die Systemleistung durch wiederholte NetLogon-Überprüfungen verringert wird, sollten Sie den folgenden Registrierungsschlüssel erstellen. Dadurch sendet DSAccess keine NetLogon-Überprüfungen mehr.
93
Speicherort HKEY_LOCAL_MACHINE\SYSTEM \
CurrentControlSet\Services\
MSExchangeDSAccess
Wert DisableNetLogonCheck
Typ REG_DWORD
Wert 0x0
Beschreibung Wenn der Registrierungsschlüssel nicht vorhanden oder nicht auf 0 festgelegt ist, führt DSAccess die Netlogon-Überprüfung durch.
Weitere Informationen finden Sie im Microsoft Knowledge Base-Artikel 320228, „XGEN: The "DisableNetLogonCheck" Registry Value and How to Use ItXGEN: The "DisableNetLogonCheck" Registry Value and How to Use It“.
Version des Betriebssystems Exchange Server 2003 kann nur Domänencontroller und globale Katalogserver verwenden, auf denen Microsoft Windows Server™ 2003 oder Windows 2000 Server Service Pack 3 oder höher ausgeführt wird. DSAccess ermittelt, ob der Verzeichnisserver diese Anforderungen erfüllt.
Nach Abschluss der harten Tests ermittelt DSAccess mithilfe mehrerer weicher Tests, welche Verzeichnisserver die durch Exchange Server 2003 zusätzlich erzeugte Last aufnehmen können. Dazu werden die folgenden weichen Verwendbarkeitstests durchgeführt:
DNS-Gewichtung DSAccess ermittelt mithilfe des in den Ressourcendatensätzen jedes Servers im DNS angegebenen Gewichtungswerts der Domänencontroller und globalen Katalogserver, welchen Server der Client bevorzugen sollte. Mit einer höheren Gewichtung steigt die Wahrscheinlichkeit, dass DSAccess einen Server auswählt. Wenn die Gewichtung nicht ermittelt werden kann, wird die Standardgewichtung 100 verwendet.
Server mit PDC FSMO-Funktion Wenn die Topologie Server enthält, auf denen Windows NT Server ausgeführt wird, erhöht sich die Last des Verzeichnisservers mit der PDC FSMO-Funktion (Primary Domain Controller, Flexible Single Master Operation) erheblich. Dadurch eignet er sich weniger für die Verwendung mit Exchange Server 2003. Aus diesem Grund führt DSAccess einen weichen Verwendbarkeitstest durch, um den Server mit der PDC FSMO-Funktion zu finden. Dieser wird anschließend aus der Liste der verwendbaren Verzeichnisserver gelöscht.
Antwortzeit DSAccess führt auf dem Verzeichnisserver eine LDAP-Abfrage zur Überprüfung der Antwortzeit aus. Bei einer Antwortzeit von mehr als zwei Sekunden gilt der weiche Verwendbarkeitstest als nicht bestanden.
94
Hinweis: DSAccess unterstützt den Round-Robin-Lastenausgleich und Failover auf einen anderen Verzeichnisserver, wenn ein derzeit verwendeter Server nicht mehr verfügbar ist. Diese Funktionen sind deaktiviert, wenn Exchange Server 2003 auf einem Domänencontroller oder globalen Katalogserver ausgeführt wird.
Hartcodierung von DSAccess-ServernDSAccess ermöglicht Administratoren, bestimmte Domänencontroller und globale Katalogserver für die Verwendung von DSAccess statisch zu konfigurieren und den automatischen Topologieerkennungsprozess zu deaktivieren. Diese hartcodierten Einträge werden über die DSAccess-Benutzeroberfläche im Exchange-System-Manager konfiguriert, wie in der folgenden Abbildung dargestellt.
Registerkarte „Verzeichniszugriff“ im Exchange-System-Manager
Bei der Initialisierung von DSAccess werden die Registrierungsdaten gelesen, um zu ermitteln, ob Domänencontroller oder globale Katalogserver statisch konfiguriert sind. Wenn Domänencontroller oder globale Katalogserver statisch konfiguriert sind, wird die dynamische Topologieerkennung nicht ausgeführt. Wenn keine statischen Verzeichnisserver gefunden werden, werden die Verzeichnisdienstserver in der Topologie dynamisch erkannt.
Wenn DSAccess statisch konfiguriert ist, werden die Features für den Lastenausgleich und den Failover in DSAccess nicht gestartet, und es werden keine anderen Domänenkataloge oder globalen Kataloge verwendet oder ermittelt. Wenn alle statisch konfigurierten Domänenkataloge oder globalen Kataloge offline oder auf andere Weise nicht verfügbar sind, schlagen DSAccess-Operationen daher fehl. Wenn globale Kataloge statisch konfiguriert, in
95
der Registrierung jedoch keine Domänenkataloge angegeben sind, werden alle verfügbaren Domänencontroller dynamisch ermittelt und verwendet. Ebenso werden alle verfügbaren globalen Kataloge dynamisch ermittelt und verwendet, wenn Domänenkataloge statisch konfiguriert, in der Registrierung jedoch keine globalen Kataloge angegeben sind. Wenn der Konfigurationsdomänencontroller nicht statisch konfiguriert ist, wird er aus der Liste der verfügbaren Domänencontroller entfernt (unabhängig davon, ob die Liste nun dynamisch oder statisch konfiguriert ist).
DSAccess-ProfileDie für benutzerbezogene Anforderungen verwendeten Domänencontroller und globalen Kataloge sind profilabhängig. Daher befinden sich die Werte für diese Einstellungen in der Registrierung unter dem Unterschlüssel HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAccess\Profiles\Default. Für die statische Konfiguration der Domänencontroller und globalen Katalogserver zur Verwendung mit DSAccess werden die folgenden Registrierungsschlüssel benötigt:
Speicherort MSExchangeDSAccess\Profiles\Default\<Name
of DC>
Wert IsGC
Typ REG_DWORD
Wert 0x0
Speicherort MSExchangeDSAccess\Profiles\Default\<Name
of DC>
Wert HostName
Typ REG_SZ
Wert <name of DC>
Speicherort MSExchangeDSAccess\Profiles\Default\<Name
of DC>
Wert DSType
Typ REG_SZ
Wert 0
96
Speicherort MSExchangeDSAccess\Profiles\Default\<Name
of DC>
Wert PortNumber
Typ REG_DWORD
Wert 0x00000185 (389)
Speicherort MSExchangeDSAccess\Profiles\Default\<Name
of GC>
Wert IsGC
Typ REG_DWORD
Wert 0x1
Speicherort MSExchangeDSAccess\Profiles\Default\<Name
of GC>
Wert HostName
Typ REG_SZ
Wert <name of GC>
Speicherort MSExchangeDSAccess\Profiles\Default\<Name
of GC>
Wert DSType
Typ REG_SZ
Wert 0
Speicherort MSExchangeDSAccess\Profiles\Default\<Name
of GC>
Wert PortNumber
Typ REG_DWORD
Wert 0x00000cc4 (3268)
97
Angeben des KonfigurationsdomänencontrollersEs gibt folgende drei Möglichkeiten zum Festlegen des von DSAccess zu verwendenden Konfigurationsdomänencontrollers:
Statische Konfiguration in der Registrierung Der Konfigurationsdomänencontroller wird für alle Profile gemeinsam verwendet. Aus diesem Grund werden die Registrierungseinstellungen für den Konfigurationsdomänencontroller unter dem Unterschlüssel \Instance0 wie folgt angegeben:
Speicherort MSExchangeDSAccess\Instance0
Wert ConfigDCHostName
Typ REG_SZ
Wert <Name of config DC>
Speicherort MSExchangeDSAccess\Instance0
Wert ConfigDCPortNumber
Typ REG_DWORD
Wert 0x00000185 (389)
Dynamische Erkennung Wenn der Konfigurationsdomänencontroller nicht statisch konfiguriert wurde, ermittelt DSAccess den Konfigurationsdomänencontroller über die dynamische Topologieerkennung. DSAccess verwendet den ausgewählten Konfigurationsdomänencontroller acht Stunden lang. Anschließend wird nach dem Zufallsprinzip ein neuer Konfigurationsdomänencontroller ausgewählt. Ein neuer Konfigurationsdomänencontroller wird früher ausgewählt, wenn die Systemaufsicht neu gestartet wird oder wenn beim aktuellen Konfigurationsdomänencontroller Fehler auftreten bzw. dieser heruntergefahren wird.
Beim Start über die Systemaufsicht In Exchange Server 2003 wird der Konfigurationsdomänencontroller nur beim ersten Starten des Diensts über die Systemaufsicht ausgewählt. Dies erfolgt beim Setup oder bei einer Aktualisierung. Die Auswahl durch die Systemaufsicht wird in allen Fällen ignoriert, bei denen der Konfigurationsdomänencontroller in der Registrierung statisch konfiguriert wurde. Der Eintrag eines statischen Konfigurationsdomänencontrollers wird in DSAccess als Vorgabe betrachtet. Wenn der Konfigurationsdomänencontroller statisch konfiguriert ist,
98
wird er daher vorzugsweise für konfigurationsbezogene Anforderungen verwendet. Wenn dieser Domänencontroller nicht mehr verfügbar ist, wird ein anderer Domänencontroller aus der Liste der aktiven Domänencontroller ausgewählt. In diesem Fall ersetzt DSAccess den Konfigurationsdomänencontroller durch Auswahl eines verfügbaren Domänencontrollers und ignoriert somit die Registrierungsinformationen für den Konfigurationsdomänencontroller.
Zuweisen von Serverfunktionen durch DSAccessIn den folgenden Beispielen werden unterschiedliche Konfigurationen von Active Directory dargestellt. Zudem wird erläutert, wie die Serverfunktionen jeweils durch DSAccess zugewiesen werden. In den Beispielen wird davon ausgegangen, dass auf allen Domänencontrollern und globalen Katalogen Windows 2000 Server mit Service Pack 3 oder höher ausgeführt wird, dass alle Verwendbarkeitstests durchgeführt und keine statischen Domänencontroller festgelegt wurden (d. h., die dynamische Topologieerkennung wird ausgeführt).
Beispiel 1 – Einfache Topologie mit einer DomäneIn der folgenden Abbildung wird eine Gesamtstruktur mit einer Domäne und zwei Standorten dargestellt. Standort A enthält einen Domänencontroller und einen globalen Katalog, während Standort B drei Domänencontroller und zwei globale Kataloge umfasst.
99
Eine Domäne mit zwei Standorten
Wenn DSAccess auf Exchange Server 2003-Servern an Standort A ausgeführt wird, wird die in der folgenden Tabelle aufgeführte Topologie erkannt:
Topologie für Standort A
Typ des Domänencontrollers Server
Konfigurationsdomänencontroller Domänencontroller 1 oder globaler Katalog 1
Aktive Domänencontroller Domänencontroller 1 und globaler Katalog 1
Aktive globale Kataloge Globaler Katalog 1
Wenn DSAccess auf Exchange Server 2003-Servern an Standort B ausgeführt wird, wird die in der folgenden Tabelle aufgeführte Topologie ermittelt:
Topologie für Standort B
Typ des Domänencontrollers Server
Konfigurationsdomänencontroller Domänencontroller 2, 3 und 4
Globaler Katalog 2 oder 3
100
Typ des Domänencontrollers Server
Aktive Domänencontroller Domänencontroller 2, 3 und 4
Globale Kataloge 2 und 3
Aktive globale Kataloge Globale Kataloge 2 und 3
In allen Fällen ist die Reihenfolge der aufgeführten Server wichtig. Die Server werden in der Reihenfolge aufgeführt und verwendet, in der sie von DSAccess ermittelt und als geeignet festgelegt werden.
Beispiel 2 – Komplexe DomänentopologieIn der folgenden Abbildung wird eine komplexere Topologie mit zwei Domänen und zwei Standorten dargestellt, wobei sich Standort A über beide Domänen erstreckt.
Zwei Domänen mit einem Standort, der beide Domänen umfasst
Wenn DSAccess auf Exchange Server 2003-Servern in Domäne 1 und an Standort A ausgeführt wird, wird die in der folgenden Tabelle aufgeführte Topologie ermittelt:
101
Topologie für Domäne 1 und Standort A
Typ des Domänencontrollers Server
Konfigurationsdomänencontroller Domänencontroller 1, 2, 3 und 4
Globaler Katalog 1, 2 oder 3
Aktive Domänencontroller Domänencontroller 1, 2, 3 und 4
Globale Kataloge 1, 2 und 3
Aktive globale Kataloge Globale Kataloge 1, 3 und 2
Wenn DSAccess auf Exchange Server 2003-Servern in Domäne 2 und an Standort A ausgeführt wird, wird die in der folgenden Tabelle aufgeführte Topologie ermittelt:
Topologie für Domäne 2 und Standort A
Typ des Domänencontrollers Server
Konfigurationsdomänencontroller Domänencontroller 1, 2, 3, 4
Globaler Katalog 1, 2 oder 3
Aktive Domänencontroller Domänencontroller 1, 2, 3 und 4
Globale Kataloge 1, 2 und 3
Aktive globale Kataloge Globale Kataloge 2, 1 und 3
Wenn DSAccess auf Exchange Server 2003-Servern in Domäne 2 und an Standort B ausgeführt wird, wird die in der folgenden Tabelle aufgeführte Topologie ermittelt:
Topologie für Domäne 2 und Standort B
Typ des Domänencontrollers Server
Konfigurationsdomänencontroller Domänencontroller 5
Globaler Katalog 4
Aktiver Domänencontroller Domänencontroller 5
Globaler Katalog 4
Aktive globale Kataloge Globaler Katalog 4
Die Server werden wieder in der Reihenfolge aufgeführt und verwendet, in der sie erkannt und als geeignet festgelegt werden.
102
VerzeichniszugriffscacheBeim DSAccess-Cache handelt es sich um einen Cache im Arbeitsspeicher auf dem Exchange-Server, der die von Active Directory abgerufenen Konfigurations- und Benutzerdatensätze enthält. Auf die Datensätze im Cache wird über den DN (Distinguished Name) des Objekts, den GUID (Globally Unique Identifier) oder einen aus dem Bereich, dem BaseDN sowie dem für die Suche dieses Objekts in Active Directory verwendeten Filter erstellten Schlüssel zugegriffen. Bei späteren Zugriffen mit dem gleichen DN, GUID oder Schlüssel wird der Datensatz im Cache gefunden. Wie bereits erwähnt, handelt es sich bei DSAccess um eine gemeinsame API, die von mehreren Prozessen auf einem Exchange Server 2003-Computer verwendet wird. In der folgenden Tabelle werden die Prozesse aufgeführt, die DSAccess.dll in ihren Heap laden und von den Active Directory-Informationen im Cache profitieren.
Prozesse, die „DSAccess.dll“ laden
Prozess Beschreibung
Mad.exe Microsoft Exchange-Systemaufsichtsdienst
Store.exe Microsoft Exchange-Informationsspeicherdienst
EMSMTA.exe Microsoft Exchange MTA-Stacks-Dienst
ExMgmt.exe Exchange-Verwaltungsdienst
RESvc.exe Exchange-Routingdienst
Inetinfo.exe oder W3WP.exe IIS- und Arbeitsprozesse
Winmgmt.exe Windows-Verwaltungsinstrumentationsdienst
In der folgenden Tabelle werden die verschiedenen Exchange-Komponenten aufgeführt, in denen über DSAccess Benutzer- und Konfigurationsinformationen abgerufen werden.
Verwendung von DSAccess in Exchange-Komponenten
Komponente Verwendungszweck von DSAccess
Metabasis-Aktualisierungsdienst (DS2MB) Verzeichnisänderungen, die anhand der Aktualisierungssequenznummer (USN – Update Sequence Number) verfolgt werden
Exchange-Routingmodul (RESVC) Benutzer- und Konfigurationssuche
SMTP-Kategorisierungsmodul (SMTP CAT) Liste globaler Katalogserver in der Topologie
Verzeichnisdienstproxy (DSProxy) Liste globaler Katalogserver in der Topologie
103
Komponente Verwendungszweck von DSAccess
Exchange-Informationsspeicher Benutzer- und Konfigurationssuche
WebDAV Benutzer- und Konfigurationssuche
Message Transfer Agent (MTA) Benutzer- und Konfigurationssuche
Die mit den Komponenten durchgeführten Verzeichnissuchläufe können für einen bestimmten Zeitraum im DSAccess-Cache zwischengespeichert werden. Wenn ein anderer Prozess im betreffenden Zeitraum die gleichen Informationen anfordert, wird keine wiederholte Abfrage an einen aktiven globalen Katalog gestartet, sondern die Informationen können aus dem DSAccess-Cache abgerufen werden. Jeder Verzeichniszugriff, mit Ausnahme der Adressbuchsuche über MAPI-Clients und von bestimmten Bereichen des eingehenden und ausgehenden SMTP-Routings, wird über den DSAccess-Prozess geleitet und im Cache abgelegt.
In der Standardeinstellung werden Verzeichniseinträge für einen Zeitraum von 15 Minuten zwischengespeichert. Die Standardgröße des Benutzercache beträgt 140 MB und die des Konfigurationscache 50 MB. Die Anzahl der Benutzer, die maximale Anzahl der Einträge, die maximale Cachegröße (Arbeitsspeicher) und die Ablaufzeit des Cache sind Parameter, die sich möglicherweise auf die optimale Größe und Leistung des DSAccess-Cache auswirken.
Mit den folgenden (in der Standardeinstellung nicht festgelegten) Registrierungsschlüsseln kann der DSAccess-Cache für Konfigurationsdaten auf niedriger Ebene gesteuert werden:
Speicherort MSExchangeDSAccess\Instance0
Wert CacheTTLConfig
Typ REG_DWORD
Wert 0x384 (900 seconds)
Beschreibung Wird zur Angabe des TTL-Werts (Time-To-Live) für die Konfigurationsdaten im Cache verwendet.
Speicherort MSExchangeDSAccess\Instance0
Wert MaxEntriesConfig
Typ REG_DWORD
Wert 0 (no limit)
104
Beschreibung Wird zur Angabe der maximalen Anzahl der Einträge für Konfigurationsdaten im Cache verwendet.
Mit den folgenden (in der Standardeinstellung nicht festgelegten) Registrierungsschlüsseln kann der DSAccess-Cache für Benutzerdaten auf niedriger Ebene gesteuert werden:
Speicherort MSExchangeDSAccess\Instance0
Wert CacheTTLUser
Typ REG_DWORD
Wert 0x258 (600 seconds)
Beschreibung Wird zur Angabe des TTL-Werts (Time-To-Live) für die Benutzerdaten im Cache verwendet.
Speicherort MSExchangeDSAccess\Instance0
Wert MaxEntriesUser
Typ REG_DWORD
Wert 0 (no limit)
Beschreibung Wird zur Angabe der maximalen Anzahl der Einträge für Benutzerdaten im Cache verwendet.
Laden von DSAccessDurch Laden von Suchfiltern kann verhindert werden, dass mehrere Suchinstanzen gleichzeitig auf Active Directory zugreifen. Dieses Problem tritt auf, wenn auf dem gleichen Benutzerobjekt mehrere Suchfilter gestartet werden. Die Suchfilter können über die folgenden Registrierungsschlüssel geladen werden. Dadurch werden der Bereich, der BaseDN (Base Distinguished Name) und der Filter für die Suche definiert.
Vorsicht: Eine fehlerhafte Bearbeitung der Registrierung kann zu ernsthaften Problemen führen, die möglicherweise eine Neuinstallation des Betriebssystems erforderlich machen. Dadurch entstandene Probleme können unter Umständen nicht mehr
105
behoben werden. Sichern Sie vor dem Ändern der Registrierung alle wichtigen Daten.
Der DSAccess-Cache kann mit den folgenden Registrierungswerten geladen werden:
Speicherort MSExchangeDSAccess
Wert PreloadBaseDNs
Typ REG_MULTI_SZ
Wert BaseDN value (for example,
DC=contoso,DC=com)
Beschreibung Gibt das Containerobjekt an, das als Stamm für die Abfrage verwendet wird. Dies ist eine Einstellung für mehrteilige Zeichenfolgen. Jeder BaseDN muss mit einem geladenen Filter übereinstimmen. Dies bedeutet, dass BaseDNs und Filterzeichenfolge vollständig übereinstimmen müssen.
Speicherort MSExchangeDSAccess\
Wert PreloadFilters
Typ REG_MULTI_SZ
Wert A filter string, for example,
legacyExchangeDN=%
106
Beschreibung DSAccess liest die Daten in der Registrierung und verarbeitet das Prozentzeichen (%) als offenen Parameter, der noch festgelegt wird. Bei einer Suche wird der vom Verzeichnis zurückgegebene Datensatz analysiert und der Wert des entsprechenden im geladenen Filter angegebenen Attributs in den Sucheintrag eingefügt. Anschließend werden Zeiger auf den entsprechenden Benutzerdatensatz festgelegt. Gehen Sie wie bei allen anderen an der Registrierung vorgenommenen Änderungen beim Aktualisieren der Registrierung mit äußerster Vorsicht vor. Wie auch bei anderen Exchange-Diensten wird die Gültigkeit der in der Registrierung angegebenen Active Directory-Server von DSAccess nicht überprüft. Daher werden falsche Einträge oder andere mögliche Fehler nicht gefunden. Die zum Laden aufgefüllten Werte sind für die am häufigsten durchgeführten Exchange-Suchläufe optimal festgelegt.
Eine Reihe von Exchange-Transaktionen könnten ein Ladeereignis auslösen, dazu müssen jedoch bestimmte Kriterien erfüllt sein. Die Ladeereignisse treten in der folgenden Reihenfolge auf:
1. In Active Directory wird eine Suche durchgeführt. Wenn bei der Suche die folgenden drei Bedingungen erfüllt sind, wird der DSAccess-Cache geladen:
Bei einer Benutzerverzeichnispartitionssuche muss der DN zurückgegeben werden.
Der DN muss den in den geladenen Registrierungseinstellungen angegebenen BaseDN enthalten. Wenn bei einer Suche beispielsweise ein allgemeinerer BaseDN als der geladene BaseDN angegeben ist, wird der Cache nicht geladen.
Der zurückgegebene Datensatz wird analysiert, und die in der geladenen Suchzeichenfolge angegebenen Attribute werden extrahiert. Dabei müssen die zum Erstellen des Suchfilters erforderlichen Attribute vorhanden sein. Im folgenden Beispiel für eine Multiplexsuche muss mindestens eins der Attribute vorhanden sein:
(|(objectGuid=%) (msExchMailboxGuid=%))
Aufgrund der Mehrdeutigkeit des zurückgegebenen Ergebnisses darf das Attribut in der geladenen Zeichenfolge nicht mehrwertig sein. proxyAddresses = % stellt
107
beispielsweise keinen gültigen geladenen Suchfilter dar, da es sich bei proxyAddresses um ein mehrwertiges Attribut handelt und DSAccess nicht entscheiden kann, welcher Wert für den unbesetzten Wert verwendet werden soll.
2. Ein Sucheintrag wird aus Bereich, BaseDN, Attributen und Filterzeichenfolge erstellt und mit diesem DN-Eintrag im Cache verknüpft. Beispiel:
[scope = Whole Subtree] / [baseDN = DC=mydom,DC=com] / [filter =
(objectClass=myclass)]
DSAccess verarbeitet spätere Active Directory-Suchanforderungen auf Grundlage der geladenen Filtern und BaseDNs mithilfe des Caches und nicht über Active Directory.
VerzeichnisdienstproxyVerzeichnisdienstproxy (DSProxy) ist eine Exchange Server 2003-Komponente, mit der ein Adressbuchdienst für Microsoft Office Outlook-Clients bereitgestellt wird. DSProxy ist in DSProxy.dll implementiert und verfügt über zwei Funktionen:
Emulieren eines MAPI-Adressbuchdiensts und Weiterleiten von Anforderungen auf einen Active Directory-Server
Bereitstellen eines Verweisverfahrens für die direkte Verbindung von Outlook-Clients mit Active Directory-Servern
Obwohl durch den Namen impliziert wird, dass über DSProxy ausschließlich Proxydienste zur Verfügung stehen, werden gleichzeitig auch Verweisdienste bereitgestellt.
MAPI-Clients, auf denen ältere Versionen von Outlook als Outlook 2000 ausgeführt werden, greifen über die DSProxy-Komponente auf das Verzeichnis zu. Diese älteren Clients wurden unter der Annahme entwickelt, dass jeder Exchange-Server einen Verzeichnisdienst enthält. Dies trifft auf Exchange 2000 Server und höhere Versionen nicht mehr zu. Aus diesem Grund wird über DSProxy ein Verzeichnisdienst emuliert, sodass auch ältere Clients verwendet werden können, indem der Exchange 2003-Server die Anforderungen an Active Directory weiterleitet.
Neuere Versionen von Outlook, z. B. Outlook 2000 und Outlook 2002, verwenden noch einen Proxy der Namensdienstanbieter-Schnittstelle (NSPI – Name Service Provider Interface) von der ersten Verbindung mit dem Exchange-Server. Nachdem der Client jedoch mit dem Server eine Verbindung hergestellt hat, übergibt der DSProxy einen Verweis zurück an den Client. Von diesem Moment an werden alle künftigen Verzeichnisanforderungen direkt an den Verweisserver gesendet. Der Verweisserver ist in diesem Fall der globale Katalogserver.
Hinweis: In der Originalversion von Outlook 2000 wird ein Verweis nur dann aktualisiert, wenn der globale Katalogserver nicht mehr erreichbar ist. In Outlook 2000
108
Service Release 2 (SR2) wird der Verweis bei jedem Start von Outlook aktualisiert. Durch diese Änderung wird verhindert, dass Outlook 2000 kontinuierlich an einen ungeeigneten globalen Katalogserver gebunden wird. Outlook 2002 und neuere Versionen aktualisieren bei jedem Neustart des Clients oder bei einem Fehler den Verweis auf den globalen Katalog.
DSProxy ruft die Liste der aktiven globalen Katalogserver von DSAccess ab, leitet Abfragen jedoch nicht über DSAccess weiter. Der Grund dafür liegt darin, dass DSProxy die NSPI zum Senden einer Suche in MAPI-Adressbüchern verwendet. Mit DSAccess werden ausschließlich LDAP-Abfragen bearbeitet. DSProxy ist jedoch beim Bereitstellen der Failover-Unterstützung für globale Kataloge vollständig abhängig von DSAccess.
DSProxy-OperationenDSProxy führt die folgenden Vorgänge aus.
Abrufen der Liste der aktiven globalen Kataloge von DSAccess und Ausfiltern der ungeeigneten globalen Kataloge
Weiterleiten der MAPI-Abfragen von Clients mit älteren Outlook-Versionen als Outlook 2000 an die globalen Katalogserver ausgehend von der Anzahl der globalen Kataloge sowie der Client-IP-Adresse
Verweisen von Clients mit Outlook 2000 und neueren Versionen an globale Katalogserver über ein Round-Robin-Verfahren.
DSProxy führt anfangs einen einzelnen Thread aus, über den bis zu 512 Clientverbindungen unterstützt werden. DSProxy erstellt jeweils automatisch einen zusätzlichen Thread für weitere 512 Verbindungen. Im Gegensatz zu DSAccess verfügt DSProxy über kein Cacheverfahren. Dies bedeutet, dass jede über DSProxy verarbeitete MAPI-Abfrage an einen aktiven globalen Katalog gesendet wird.
Verhalten von Exchange Server 2003 vor Service Pack 2 bei VerweisenIn Exchange Server 2003 Service Pack 2 (SP2) erfolgte eine Änderung des Entwurfs, wie der DSProxy-Dienst auf Outlook-Clients in globalen Katalogen verweist. In diesem Thema wird das Verhalten vor und nach dieser Änderung erläutert.
Vor Exchange Server 2003 SP2 erhielten Outlook MAPI-Clients entweder einen Verweis auf einen globalen Katalogserver, oder sie sendeten mithilfe des Exchange-Servers verzeichnisbezogene Anforderungen. Im Szenario mit Outlook 2000 als Client gibt der DSProxy-Dienst, nachdem der Outlook-Client die Verbindung mit dem Exchange-Server hergestellt hat, einen Verweis an den Client zurück. Von da an werden alle künftigen
109
Verzeichnisanforderungen direkt an den globalen Katalogserver gesendet, auf den verwiesen wurde.
In diesem Szenario befindet sich der globale Katalog an einem der folgenden zwei Speicherorte:
Der globale Katalog befindet sich an demselben Active Directory-Standort wie der Exchange-Server (typisches Verhalten).
Der globale Katalog befindet sich an einem Active Directory-Standort, der direkt mit dem Active Directory-Standort des Exchange-Servers verbunden ist (wenn alle am Standort vorhandenen globalen Kataloge nicht verfügbar sind).
Über die Standortzugehörigkeit hinaus bevorzugt DSProxy die Verwendung von globalen Katalogservern, die Mitglieder derselben Domäne wie der Exchange-Server sind. Wenn davon keiner verfügbar ist, verwendet DSProxy die anderen globalen Katalogserver an dem Active Directory-Standort.
Dieses Verhalten bereitet Probleme in Umgebungen mit mehreren Domänen, wo DomainPrep in den Domänen ausgeführt wurde. Insbesondere dann, wenn ein Outlook-Client an einen globalen Katalogserver verwiesen wird, der sich nicht in derselben Domäne wie der postfachaktivierte Benutzer befindet, greift der Benutzer auf Daten im schreibgeschützten Format zu. Das bedeutet, dass Aktualisierungen für bestimmte Objekte fehlschlagen können. Bei den Aktualisierungen könnte es sich um Aktualisierungen für den postfachaktivierten Benutzer handeln, z. B. Zugriffsrechte für Stellvertretung oder Verteilergruppenmitgliedschaft.
Szenario vor SP2Die Gesamtstruktur enthält drei Domänen, wovon jede für Exchange Server vorbereitet ist. Alle Benutzer und Verteilergruppen befinden sich in der Domäne UserDomain. Ein globaler Katalogserver von UserDomain und ThirdDomain sind Mitglieder des Active Directory-Standorts des Exchange-Servers. Die Outlook-Clients befinden sich an einem anderen Active Directory-Standort. Die Domäne des Exchange-Servers ist nicht repräsentiert, und an dem Exchange Server Active Directory-Standort gibt es keine globalen Katalogserver aus dieser Domäne.
110
Wenn ein Outlook 2003-Client eine Verbindung mit dem Exchange-Server herstellt, könnte DSProxy den Client potenziell an jeden der drei globalen Katalogserver am Active Directory-Standort des Exchange-Servers in der Annahme verweisen, dass mindestens einer von diesen globalen Katalogservern online und erreichbar ist. Da keiner der globalen Katalogserver Mitglied der Domäne des Exchange-Servers ist, wird bei dem Verhalten vor SP2 kein globaler Katalogserver den anderen gegenüber bevorzugt. DSProxy führt bezüglich der Verweisanforderungen einen Lastenausgleich unter den verfügbaren globalen Katalogservern aus, um die Clients gleichmäßig zu verteilen.
In Anbetracht des oben dargelegten Entwurfs besteht eine 66-prozentige Chance, dass DSProxy den Outlook-Client an einen globalen Katalogserver verweist, der sich nicht in der Stammdomäne des Client befindet. Nehmen wir im Rahmen dieser Betrachtung an, dass DSProxy den Client an einen globalen Katalogserver der ThirdDomain verweist. In diesem Szenario können die Outlook-Clients den globalen Katalogserver erfolgreich für alle Verzeichnisanforderungen bis auf die nachstehend aufgeführten verwenden:
Aktualisieren der Mitgliedschaft der Verteilergruppen, die sich in der UserDomain befinden
Zuweisen von Berechtigungen der Stellvertretung anhand der Postfächer dieser Verteilergruppen, die sich in der UserDomain befinden
Veröffentlichen von Zertifikaten in der globalen Adressliste (GAL) mithilfe der Outlook-Option In GAL veröffentlichen.
Wenn DSProxy den Outlook-Client an die UserDomain GC1 verweisen würde, könnte der Outlook-Client die oben aufgeführten Anforderungen ausführen.
Weitere Informationen zum Verhalten vor SP2 und seinen potenziellen Problemen finden Sie in den folgenden Microsoft Knowledge Base-Artikeln.
256976, "XCLN: How MAPI Clients Access Active Directory“
111
872897, "How to control the DSProxy process for RPC over HTTP connections in Exchange Server 2003 sp1"
318074, "Die Fehlermeldung „Sie verfügen nicht über die erforderlichen Rechte" wird angezeigt, wenn Sie das Outlook-Adressbuch verwenden, um die Mitgliedschaft in Verteilerlisten zu verwalten“
329622, "Das Recht zum „Senden im Auftrag von" wird einem Benutzer nicht erteilt, nachdem Sie den Zugriff in Outlook delegiert haben“
Verhalten von Exchange Server 2003 Service Pack 2 bei VerweisenIn Exchange Server 2003 SP2 wird jetzt bei dem Verweisvorgang mithilfe eines neuen Algorithmus versucht, dem Outlook-Client einen globalen Katalog zur Verfügung zu stellen, der zu derselben Domäne wie der postfachaktivierte Benutzer gehört. Der neue Algorithmus löst das Delegierungsproblem, sofern ein globaler Katalogserver der Stammdomäne vorhanden ist und vom Exchange-Server für den Nachrichtenempfänger erreichbar ist. Das Verteilergruppenproblem kann behoben werden, wenn sich die Verteilergruppe in derselben Domäne wie das Postfach befindet. Wenn sich die Verteilergruppe nicht in derselben Domäne befindet, wird das Problem nicht behoben, weil der globale Katalog eine schreibgeschützte Kopie der Verteilergruppe enthält.
Funktionsweise des neuen AlgorithmusDer DSProxy-Dienst von Exchange Server 2003 SP2 versucht, den Outlook-Client an einen verfügbaren globalen Katalogserver zu verweisen, unterstützt das vom Client verwendete Protokoll und befindet sich in der Active Directory-Stammdomäne des Postfachbesitzers. Damit DSProxy einen globalen Katalogserver findet, der diesen Anforderungen genügt, stuft DSProxy aufgrund der folgenden Beschränkungen die Erwünschtheit eines bestimmten globalen Katalogservers ein:
Einschränkung 1 Ein verfügbarer globaler Katalog (RPC-Ping) - 16 Punkte
Einschränkung 2 Ein globaler Katalog, der das Protokoll des Client unterstützt - 8 Punkte
Einschränkung 3 Ein globaler Katalog, der zur Domäne des Benutzers gehört - 4 Punkte
Einschränkung 4 Ein globaler Katalog, der sich an demselben Active Directory-Standort wie der Exchange-Server befindet - 2 Punkte
Einschränkung 5 Ein globaler Katalog, der zu den aktuell vom Exchange-Server verwendeten globalen Katalogen gehört - 1 Punkt
112
DSProxy verteilt zuerst die globalen Katalogserver mit der höchsten Punktzahl und weist sequenziell Ressourcen zu, wenn eine Verbindung besteht.
Einschränkung 1 wird alle fünf Minuten berechnet und und kann durch Ändern des Registrierungsschlüssels LdapKeepAliveSecs konfiguriert werden. Die Einschränkungen 2 und 3 sind insofern „dynamisch“, weil sie bei jeder Verweisanforderung durch einen Client berechnet werden müssen. Die Einschränkungen 4 und 5 sind insofern „statisch“, weil sie für jeden globalen Katalog einmal berechnet und dann gespeichert werden müssen.
Einschränkung 5 ist auch als Inkarnationsliste bekannt. Bei der Initialisierung von DSAccess wird eine „Inkarnationsliste“ der 10 dem Standort angehörenden globalen Katalogserver erstellt, die verwendet werden können. Wenn kein dem Standort angehörender globaler Katalogserver verfügbar ist, erstellt DSAccess eine „Inkarnationsliste“ von 10 globalen Katalogservern (außerhalb des Standorts) an den direkt verbundenen Standorten, beginnend mit dem Standort, der die geringsten Standortverbindungskosten aufweist. Aufgrund der Reihenfolge der Einschränkungen bevorzugt DSProxy Server in der Inkarnationsliste von DSAccess, sodass in der Standardeinstellung die 10 Server mit den geringsten Standortverbindungskosten bevorzugt werden. DSProxy verfügt jedoch über eine Liste aller globalen Katalogserver an allen direkt verbundenen Standorten und verwendet die Mitgliedschaft in der Inkarnationsliste nur dazu, um den Servern Punkte zuzuweisen.
Die folgende Abbildung zeigt das Szenario mit den beiden Domänen Exchange Domain und UserDomain.
113
In diesem Szenario werden den globalen Katalogservern vom DSProxy-Dienst Punkte entsprechend der folgenden Tabelle zugewiesen. Beachten Sie, dass hierbei davon ausgegangen wird, dass alle globalen Katalogserver betriebsbereit sind und am Exchange Active Directory-Standort auf Anforderungen reagieren.
Server Active Directory-Standort
Wird von DSAccess verwendet?
Gesamtanzahl von Punkten als Wert für die Einschränkungen
UserDomain GC1 Active Directory-Standort des Client
Nein 16+8+4=28
(1, 2, 3)
114
Server Active Directory-Standort
Wird von DSAccess verwendet?
Gesamtanzahl von Punkten als Wert für die Einschränkungen
UserDomain GC2 Active Directory-Standort des Client
Nein 16+8+4=28
(1, 2, 3)
UserDomain GC3 Active Directory-Standort B
Nein 16+8+4=28
(1, 2, 3)
UserDomain GC4 Active Directory-Standort B
Nein 16+8+4=28
(1, 2, 3)
Exchange Domain GC1
Exchange Active Directory-Standort
Ja 16+8+2+1=27
(1, 2, 4, 5)
Exchange Domain GC2
Exchange Active Directory-Standort
Ja 16+8+2+1=27
(1, 2, 4, 5)
Exchange Domain GC3
Active Directory-Standort A
Nein 16+8=24
(1, 2)
Exchange Domain GC4
Active Directory-Standort A
Nein 16+8=24
(1, 2)
Exchange Domain GC5
Active Directory-Standort B
Nein 16+8=24
(1, 2)
Exchange Domain GC6
Active Directory-Standort B
Nein 16+8=24
(1, 2)
Hinweis: Wie Sie aus der Tabelle ersehen können, sind Exchange Domain GC7 und UserDomain GC5 nicht enthalten, weil sie nicht direkt mit dem Active Directory-Standort des Exchange-Servers verbunden sind. Mit anderen Worten: der Exchange-Server verwendet diese globalen Katalogserver nie für DSAccess- oder DSProxy-Funktionen.
An diesem Beispiel können Sie erkennen, dass der Algorithmus möglicherweise einen globalen Katalogserver außerhalb des Standorts gegenüber einem am eigenen Standort befindlichen globalen Katalogserver bevorzugt. Das macht den Unterschied zum typischen DSProxy-Verhalten vor SP2 aus.
115
In diesem Beispiel stellt Exchange Server den Outlook-Clients die globalen Katalogserver der UserDomain (sequenziell zum Lastenausgleich von Anforderungen) zur Verfügung, weil diese globalen Katalogserver eine höhere berechnete Punktzahl als die globalen Katalogserver der Exchange Domain aufweisen. Das bedeutet, dass Exchange jetzt Clients auf globale Katalogserver außerhalb des Standorts verweisen kann (aber nur auf diejenigen, die mit dem Exchange Active Directory-Standort direkt verbunden sind), wenn am Active Directory-Standort des Exchange-Servers keine globalen Katalogserver der Postfach-Stammdomäne verfügbar sind. In diesem speziellen Beispiel könnte der Outlook-Client einen Verweis auf einen globalen Katalogserver der UserDomain erhalten, der sich am Active Directory-Standort B oder am Active Directory-Standort des Client befindet.
Außerdem würde DSProxy in dem Fall, dass alle globalen Katalogserver der UserDomain unerreichbar wären (falls diese Server Einschränkung 1 nicht erfüllen), die Outlook-Clients an die globalen Katalogserver verweisen, die sich am Exchange Active Directory-Standort befinden, weil sie die nächsthöhere Punktzahl aufweisen.
Weitere Informationen zum DSProxy-Verweisvorgang vor SP2 finden Sie im Exchange Server-Teamblogartikel Aktualisierung Exchange 2003-DSProxy-Verweisvorgang vor SP2 .
Hinweis: Die Inhalte der einzelnen Blogartikel und ihre URLs können ohne vorherige Ankündigung geändert werden.
Ungelöste Probleme mit DSProxy unter Exchange Server 2003 SP2Die Änderung am DSProxy-Verweisverfahren hilft dem Endbenutzer nur dann, wenn DSProxy einen globalen Katalogserver in der Stammdomäne finden kann. Wenn am Active Directory-Standort des Exchange-Servers oder an allen direkt verbundenen Active Directory-Stammorten des Exchange-Servers keine globalen Katalogserver in der Stammdomäne vorhanden sind, erhält der Outlook-Client einen Verweis auf einen globalen Katalogserver, der eine schreibgeschützte Kopie des postfachaktivierten Benutzers enthält. Dieser schreibgeschützte Zugriff bedeutet, dass es für das betreffende Postfach nicht möglich ist, Änderungen durch Stellvertretung vorzunehmen oder Zertifikate in der (GAL) zu veröffentlichen.
Obwohl durch das neue Verhalten die Probleme der Stellvertretungsberechtigungen und der Veröffentlichung von Zertifikaten gelöst werden können, bleibt außerdem u. U. die Frage ungelöst, ob der Empfänger von Nachrichten die Mitgliedschaft der Verteilergruppe aktualisieren kann. Die Verteilergruppe muss zu derselben Domäne wie der Empfänger von Nachrichten gehören, damit der Empfänger von Nachrichten die Mitgliedschaft aktualisieren kann. Wenn die Verteilergruppe nicht zu derselben Domäne wie der Empfänger von Nachrichten gehört, kann die Mitgliedschaft nicht aktualisiert werden. Deshalb müssen Sie möglicherweise trotzdem nach einer anderen Lösung suchen, um allen Benutzern die Möglichkeit einzuräumen, die Gruppenmitgliedschaft zu aktualisieren.
116
Auswirkungen des DSProxy-Verhaltens bei VerweisenIn der Infrastruktur müssen folgende Punkte überprüft werden:
Falls nicht im Voraus hinsichtlich des Netzentwurfs Überlegungen angestellt wurden, kann diese Änderung bewirken, dass Clients aus der Sicht des Netzwerks nicht auf die richtigen globalen Katalogserver verwiesen werden (Latenz, Bandbreite, Verwendung, Anzahl der Hops). Es wird empfohlen, die Auswirkungen auf das Netzwerk vor der Implementierung zu bedenken.
Um sicherzustellen, dass Exchange Server weiterhin Verweise auf globale Katalogserver am eigenen Standort liefert, müssen Sie u. U. dem Exchange Active Directory-Standort globale Katalogserver für diejenigen Domänen hinzufügen, die Postfächer enthalten, die sich auf den Exchange-Servern an diesem Active Directory Standort befinden.
SMTP-KategorisierungsmodulDas SMTP-Kategorisierungsmodul (auch verkürzt als Kategorisierungsmodul bezeichnet) ist eine Komponente des Exchange Server 2003-Transportmoduls. Bei Übermittlung einer Nachricht an den Transportprozess verwendet das Kategorisierungsmodul die Headerinformationen in der Nachricht, um von Active Directory Informationen über die Übertragungsmethode und den Empfänger der Nachricht abzufragen. Beispielsweise identifiziert das Kategorisierungsmodul anhand der SMTP-Adresse [email protected] den Exchange Server 2003-Server, der das Postfach des Benutzers enthält, und ermittelt, auf welchem Weg die Nachricht an diesen Server weitergeleitet wird. Das Kategorisierungsmodul erweitert auch Verteilerlisten und wendet auf Benutzerebene geltende Beschränkungen auf Nachrichten an. Weitere Informationen zur Architektur des SMTP-Transportmoduls finden Sie unter SMTP-Transportarchitektur.
Das Kategorisierungsmodul benötigt DSAccess, um die Liste der für Lookups verwendeten Active Directory-Server abzurufen. Wie auch DSProxy verwendet das Kategorisierungsmodul den eigenen Mechanismus zum Lesen der Informationen von Active Directory erst, nachdem die Serverliste abgerufen wurde.
Es gibt zwei Arten von Kategorisierungsmodulen: Das mit dem IIS SMTP-Transportstack installierte Basiskategorisierungsmodul und das Exchange-Kategorisierungsmodul, das mit Exchange installiert wird. Das Basiskategorisierungsmodul ist in Aqueue.dll implementiert. Das Basiskategorisierungsmodul führt einige grundlegende Funktionen aus, z. B. die Verwendung von LDAP-Abfragen zum Auflösen von Empfängerinformationen in Active Directory. Außerdem wird durch das Modul eine effiziente Batchverarbeitung ausgeführt, wobei eine Reihe von Abfragen in Form einer einzigen Abfrage gesendet wird. Das Basiskategorisierungsmodul kann ebenfalls die Aufgliederung von Verteilerlisten durchführen. Das Modul verfügt über SMTP-Weiterleitungsfunktionen und löst Kategorisierungsmodul-Serverereignisse aus. Exchange Server 2003 erweitert das
117
Basiskategorisierungsmodul durch die Installation einer DLL mit dem Dateinamen PhatCat.dll. Durch die Datei PhatCat.dll wird die Funktionalität des Basiskategorisierungsmoduls ergänzt. Die Standardfunktionalität des Basiskategorisierungsmoduls wird jedoch nicht ersetzt, sondern lediglich für einen speziellen Verwendungszweck erweitert.
Die Architektur des Exchange-Kategorisierungsmoduls ist in der folgenden Abbildung dargestellt.
Die Architektur des Exchange-Kategorisierungsmoduls
Nachrichtenkategorisierung und Active DirectoryBei Aufnahme einer Nachricht in die Warteschlange vor der Kategorisierung wählt das Kategorisierungsmodul die Nachricht zur Verarbeitung aus. Das Kategorisierungsmodul löst den Absender der Nachricht auf, indem das Modul in Active Directory im Attribut proxyAddresses nach der Adresse sucht. Die Empfänger der Nachricht werden ebenfalls aufgelöst, indem das Kategorisierungsmodul in Active Directory im Attribut proxyAddresses nach den entsprechenden Adressen sucht. Falls die Empfängerliste eine Verteilergruppe enthält, werden diese Mitglieder in die Gruppe aufgenommen, sofern eine Aufgliederung von Verteilergruppen auf dem Server zulässig ist. Andernfalls überträgt Exchange die Nachricht an den Server für die Aufgliederung der Verteilerlisten, der in der Verteilergruppe für die Gruppenaufgliederung angegeben ist.
118
Das Kategorisierungsmodul überprüft ebenfalls, ob das Attribut mail in Active Directory vorhanden ist, und kennzeichnet dieses Attribut als die SMTP-Adresse. Das Kategorisierungsmodul hat zudem die Aufgabe, Beschränkungen auf Absender- und Empfängerebene anzuwenden und dann die Empfänger entsprechend zu markieren. Das Kategorisierungsmodul wendet dann für jede Domäne die Formateinstellungen für aus- und eingehende Internetnachrichten auf Absender und Empfänger an und legt anschließend die entsprechenden Kennzeichnungen für die IMAIL-Konvertierungseigenschaften fest. Sie können Nachrichtenformateinstellungen im Exchange-System-Manager konfigurieren, wenn Sie den Container Globale Einstellungen auswählen.
Für die lokale Übermittlung kennzeichnet das Kategorisierungsmodul den Empfänger als lokal, indem eine empfängerspezifische Eigenschaft der Nachricht gesetzt wird, durch die für jeden einzelnen Empfänger der Zielserver angegeben wird. Das normale Format dieser Eigenschaft ist der vollqualifizierte Domänenname (FQDN) des Servers des Empfängers. Durch das Attribut homeMDB des Empfängers wird angegeben, auf welchem Server sich das Postfach des Empfängers befindet.
Die Prozesse des Kategorisierungsmoduls werden als eine Reihe von Übertragungsereignissenken in dem Bereich für Kategorisierungsmodulereignisse des erweiterten Warteschlangenmoduls ausgeführt. Das Basiskategorisierungsmodul enthält zehn Ereignissenken. Die nachstehenden sieben Ereignissenken werden zum Abfragen von Active Directory verwendet:
Register Diese Ereignissenke wird zur Initialisierung bei Beginn der Nachrichtenkategorisierung aufgerufen.
BeginMessageCategorization Diese Ereignissenke wird jeweils einmal für jede Nachricht aufgerufen, die an das Kategorisierungsmodul übermittelt wird.
EndMessageCategorization Diese Ereignissenke wird aufgerufen, um das Ende der Nachrichtenkategorisierung zu signalisieren.
BuildQuery Diese Ereignissenke wird jeweils einmal für jeden Benutzer aufgerufen, der im Verzeichnis überprüft werden muss.
BuildQueries Diese Ereignissenke wird für jeden Batchsuchlauf einmal aufgerufen. In jedem dieser Szenarien erstellt das Kategorisierungsmodul einen LDAP-konformen Filter für den Benutzer.
SendQuery Diese Ereignissenke sendet den Batchsuchlauf. Die Ereignissenke führt die Verzeichnisserverprozesse unter den Request-Attributen aus. Über die Ereignissenke wird ein asynchroner LDAP-Suchlauf auf einem Verzeichnisserver ausgeführt
SortQueryResult Diese Ereignissenke ordnet die aus Active Directory zurückgegebenen Ergebnisse den einzelnen Benutzern zu.
Die folgenden drei Ereignissenken werden auf Einzelbenutzerbasis und im Anschluss an spätere Verzeichnisdienst-Suchlaufereignisse verwendet:
119
ProcessItem Durch diese Ereignissenke werden Adressen aufgelöst. Wenn beispielsweise ein lokaler MAPI-Client eine Nachricht übermittelt, löst der MAPI-Client alle anderen Adressen wie X.400-, X.500 DN-, Legacy-Exchange-DN- und SMTP-Adressen auf und gibt diese in der E-Mail-Nachricht aus.
ExpandItem Durch diese Ereignissenke werden weitere Empfänger zu der Nachricht hinzugefügt, z. B. bei Nachrichtenjournalen, der Aufgliederung von Verteilergruppen und Inhaltskonvertierungen. Durch dieses Serverereignis werden Mitglieder hinzugefügt, zum Beispiel durch Erweiterung bei der SMTP-Weiterleitung.
CompleteItem Diese Ereignissenke wird ausgeführt, nachdem die Verarbeitungsvorgänge aller anderen Kategorisierungsmodul-Ereignissenken abgeschlossen sind. Sie erfasst die von den vorherigen Ereignissenken zurückgegebenen Statuscodes und ordnet diese Codes den Empfängern der E-Mail-Nachricht zu. Anhand der Fehlercodes erstellt das erweiterte Warteschlangenmodul anschließend Unzustellbarkeitsberichte für die betroffenen Empfänger.
Die Komponenten des Exchange-Kategorisierungsmoduls in PhatCat.dll erweitern das IIS-Kategorisierungsmodul durch Hinzufügen der folgenden drei Ereignissenken:
Register Diese Ereignissenke initialisiert die Komponenten des Exchange-Kategorisierungsmoduls, jedoch ebenfalls DSAccess, das Routingmodul sowie den Speichertreibercode. Falls bei einem dieser Initialisierungsvorgänge ein Fehler auftritt, kann auch PhatCat.dll nicht initialisiert werden.
BuildQuery Durch diese Ereignissenke wird überprüft, ob der Benutzer im DSAccess-Cache gespeichert ist. Bei einem positiven Ergebnis dieser Überprüfung wird ein Objekt ICategorizerItemAttributes zurückgegeben. Dadurch wird der Verzeichnisdienst-Suchlaufcode für das IIS-Kategorisierungsmodul umgangen. Die Verarbeitung wird mit dem Ereignis ProcessItem fortgesetzt.
ProcessItem Die Exchange-Datei PhatCat.dll enthält speziellen Programmcode zur Verarbeitung von Kontakten und einmaligen Empfängern auf Sonderfallbasis. In diesem Szenario wird lediglich die Zieladresse des Kontexts zur E-Mail-Nachricht hinzugefügt.
Empfängeraktualisierungsdienst und Exchange Server 2003Exchange Server 2003 kommuniziert mit Verzeichnisservern, um Empfängerobjekte (z. B. postfachaktivierte Benutzerkonten und E-Mail-aktivierte Gruppen) mit E-Mail-Adressen entsprechend den für die Organisation definierten Empfängerrichtlinien zu aktualisieren. Dazu verwendet Exchange Server 2003 den Empfängeraktualisierungsdienst, eine Komponente der Systemaufsicht. Der Empfängeraktualisierungsdienst erstellt und verwaltet Exchange Server 2003-spezifische Attributwerte in Active Directory. Wenn Sie ein Postfach
120
für einen Benutzer erstellen, generiert der Empfängeraktualisierungsdienst automatisch die SMTP-Adresse des Benutzers sowie alle anderen Proxyadressen, die Sie für die Empfänger definiert haben.
Exchange Server 2003 installiert zwei Instanzen des Empfängeraktualisierungsdiensts:
Unternehmenskonfigurations-Empfängeraktualisierungsdienst Es gibt nur eine Instanz dieses Empfängeraktualisierungsdiensts in der Organisation, da mit dem Unternehmensempfänger-Aktualisierungsdienst die Konfigurationsverzeichnispartition aktualisiert wird und die gesamte Struktur nur eine einzige Konfigurationsverzeichnispartition gemeinsam verwendet.
Domänenempfänger-Aktualisierungsdienst Für jede Domäne, die postfachaktivierte Benutzer enthält, muss ein Empfängeraktualisierungsdienst vorhanden sein.
Für jede einzelne Domäne in einer Gesamtstruktur ordnet der Empfängeraktualisierungsdienst einen Exchange Server 2003-Computer (auf dem der Empfängeraktualisierungsdienst ausgeführt wird) einem Domänencontroller zu (auf dem die Verzeichnisobjekte aktualisiert werden). Einem Verzeichnisserver darf jeweils immer nur ein Empfängeraktualisierungsdienst zugeordnet sein.
Aktualisieren von EmpfängerobjektenDie verwendete Suchmethode des Empfängeraktualisierungsdiensts wird durch die Aktionen bestimmt, die der Exchange-Administrator im Exchange-System-Manager ausführt. Beispielsweise können Sie im Exchange-System-Manager mit der rechten Maustaste auf ein Konfigurationsobjekt des Empfängeraktualisierungsdiensts klicken und dann den Befehl Neu erstellen auswählen, um die Mitgliedschaft in Adresslisten und Einstellungen für Empfängerrichtlinien aller Empfänger in einer Domäne zum nächsten geplanten Intervall neu zu berechnen. Sie können ebenfalls den Befehl Jetzt aktualisieren auswählen, um diesen Verarbeitungsvorgang sofort auszuführen.
Der Empfängeraktualisierungsdienst durchsucht das Verzeichnis nach zu aktualisierenden Objekten und verwendet hierzu die folgenden drei Verfahren:
Nur Aktualisierung von neuen und geänderten Objekten Dies ist das Standardverhalten des Empfängeraktualisierungsdiensts bei der Suche nach zu aktualisierenden Objekten. Es handelt sich ebenfalls um das standardmäßige Verhalten des Empfängeraktualisierungsdiensts bei Verwendung des Befehls Jetzt aktualisieren, sofern nicht die Option Neu erstellen ausgewählt wird und keine Richtlinie geändert oder angewendet wurde.
Der Empfängeraktualisierungsdienst verfolgt die letzte Änderung im Domänencontroller, für den der Empfängeraktualisierungsdienst konfiguriert wurde. Auf Grundlage des Zeitplans, der für das Objekt des Empfängeraktualisierungsdiensts festgelegt ist, sucht der Empfängeraktualisierungsdienst in regelmäßigen Abständen nach Objekten, die seit der letzten Überprüfung erstellt oder aktualisiert wurden.
121
Die Funktion Jetzt aktualisieren im Exchange-System-Manager setzt das Attribut msExchReplicateNow auf TRUE und bewirkt, dass der Empfängeraktualisierungsdienst den Zeitplan vorübergehend ignoriert und neue Änderungen sofort abfragt sowie entsprechende Maßnahmen für diese Objekte ergreift. Nach Abschluss des Vorgangs Jetzt aktualisieren wird das Attribut msExchReplicateNow auf FALSE zurückgesetzt.
Aktualisierung aller Objekte Durch Auswahl der Option Neu erstellen im Exchange-System-Manager wird das Attribut msExchDoFullReplication im Empfängeraktualisierungsdienst auf den Wert TRUE festgelegt. Nachdem für das Attribut msExchDoFullReplication der Wert TRUE festgelegt wurde, fragt der Empfängeraktualisierungsdienst beim nächsten Start nicht nur neue Objekte ab, sondern überprüft jedes Objekt. Nach Abschluss des Vorgangs Neu erstellen wird msExchDoFullReplication wieder auf FALSE zurückgesetzt.
Aktualisierung von Objekten, die einer bestimmten Empfängerrichtlinie entsprechen Sie können den Filter für eine Richtlinie ändern (das Attribut purportedSearch), um zu erreichen, dass der Empfängeraktualisierungsdienst auch nicht zum Standardverhalten gehörende Vorgänge ausführt. Wenn Sie den Filter für eine Richtlinie ändern, kann die Geltung der Richtlinie für eine Benutzergruppe geändert werden, sodass diese Richtlinie nicht mehr auf die bisherige, sondern auf eine andere Benutzergruppe angewendet werden kann. Aus diesem Grund fragt der Empfängeraktualisierungsdienst bei einer Änderung des Filters einer Richtlinie jeden Benutzer ab, der sowohl dem neuen als auch dem früheren Filter entspricht. Dieser Vorgang wird beim nächsten Start des Empfängeraktualisierungsdiensts oder bei Auswahl des Befehls Jetzt aktualisieren ausgeführt. Der Empfängeraktualisierungsdienst wird für alle Benutzer ausgeführt, die die Kriterien beider Filter erfüllen. Das Attribut msExchPoliciesIncluded dieser Benutzer wird vom Empfängeraktualisierungsdienst entsprechend dem gegenwärtig angewendeten Filter aktualisiert.
Die E-Mail-Adressen von Benutzern, die einer anderen Richtlinie unterliegen, werden jedoch nicht automatisch neu erstellt. Wenn Sie auch die Adressen solcher Benutzer aktualisieren und an die neue Richtlinie anpassen möchten, müssen Sie den Befehl Übernehmen auswählen, um die aktuelle Richtlinie anzuwenden.
Falls Sie nur die E-Mail-Adressen für eine Richtlinie ändern, wird das Standardverhalten des Empfängeraktualisierungsdiensts nicht geändert. Lediglich neue und geänderte Objekte werden aktualisiert. Sie müssen den Filter für die Richtlinie ändern, damit der Empfängeraktualisierungsdienst automatisch alle dieser Richtlinie entsprechenden Benutzer abfragt und diese Benutzer aktualisiert. Selbst wenn Sie jedoch den Filter für die Richtlinie ändern und der Empfängeraktualisierungsdienst alle Benutzer abfragt, werden die vorhandenen E-Mail-Adressen der Benutzer durch den Empfängeraktualisierungsdienst nicht entsprechend den Einstellungen der neuen Empfängerrichtlinie neu erstellt. Stattdessen werden neue E-Mail-Adressen hinzugefügt.
122
Wenn Sie eine Richtlinie anwenden, füllt der Exchange-System-Manager das Attribut gatewayProxy in den Objekten des Empfängeraktualisierungsdiensts mit der jeweiligen Adresse aus der angewendeten Richtlinie aus. Das Attribut gatewayProxy fungiert als Aktionsliste. Beispielsweise kann das Attribut gatewayProxy für die Objekte des Empfängeraktualisierungsdiensts mit einer Liste von Werten wie den folgenden gefüllt werden:
{667A1454-FCD1-434F-B3C6-D9B6D2B4A336}X400:c=us;a= ;p=Organization;o=Exchange;
{667A1454-FCD1-434F-B3C6-D9B6D2B4A336}SMTP:@contoso.com
{667A1454-FCD1-434F-B3C6-D9B6D2B4A336}smtp:@fabrikam.com
Diese Werte enthalten das Attribut objectGUID der Richtlinie und die Adressen für die Richtlinie. Beachten Sie, dass zwei Adresstypen in Großbuchstaben aufgeführt sind. Durch diese Schreibweise wird angegeben, dass es sich um die primären Proxyadressen handelt. Der andere SMTP-Adresstyp in Kleinbuchstaben kennzeichnet eine sekundäre Proxyadresse.
Der Empfängeraktualisierungsdienst aktualisiert anhand der Aktionsliste die Proxyadressen für alle Benutzer, die die Kriterien des entsprechenden Richtlinienfilters erfüllen. Um die Richtlinie auf alle Benutzer anzuwenden, müssen Sie ebenfalls den Filter für die Richtlinie ändern (das Attribut purportedSearch), indem Sie ein Leerzeichen hinzufügen oder löschen. Diese Änderung führt dazu, dass beim nächsten Start des Empfängeraktualisierungsdiensts alle dieser Richtlinie entsprechenden Objekte und nicht nur die neuen Änderungen abgefragt werden. Nachdem der Empfängeraktualisierungsdienst die Empfängeraktualisierung abgeschlossen hat, werden die Adressen, die dieser speziellen Richtlinie entsprechen, aus der Aktionsliste gatewayProxy entfernt.
Hinweis: Durch den Empfängeraktualisierungsdienst werden bestehende Adressen für einen Empfänger nur dann neu erstellt oder entfernt, wenn in der Aktionsliste die entsprechenden Adresstypen eingetragen sind.
Metabase-AktualisierungsdienstDer Metabase-Aktualisierungsdienst, der auch als Verzeichnisdienst/Metabase-Synchronisierungsprozess oder DS2MB bezeichnet wird (da dieser Prozess in DS2MB.dll implementiert ist), ist eine Komponente von Exchange Server 2003, mit der mehrere Exchange-Konfigurationseinstellungen in Active Directory mit den entsprechenden Einstellungen in der IIS-Metabase synchronisiert werden können. DS2MB hat die Aufgabe, die Konfigurationsinformationen aus Active Directory in der lokalen IIS-Metabase zu replizieren.
123
Durch den DS2MB-Prozess werden vollständige Unterstrukturen aus Active Directory kopiert, ohne dass dabei die Form der Unterstrukturen geändert wird. Dabei handelt es sich um einen Schreibvorgang in einer Richtung von Active Directory zur Metabase. Die Metabase schreibt niemals ins Active Directory. Beim Kopieren werden durch den DS2MB-Prozess keine Attribute hinzugefügt oder berechnet. Die Pfade in der Metabase werden als Schlüssel bezeichnet. Für jeden Schlüssel können Eigenschaften festgelegt werden. Jede Eigenschaft kann über Attribute zur Anpassung der betreffenden Eigenschaft verfügen. Alle Bezeichner, die im Verzeichnisdienstabbild der Unterstruktur enthalten sind (z. B. KeyType) werden auch in der Metabase benötigt. Außerdem wird der RDN (Relative Distinguished Name) des Objekts im Verzeichnis direkt dem Schlüsselnamen in der Metabase zugeordnet.
DS2MB-VorgängeDie Metabase-Aktualisierung ist ein Unterprozess, der beim Start der Systemaufsicht gestartet wird. Die Funktion von SMTP, POP3, IMAP4, Outlook Web Access und Outlook Mobile Access ist von der Replikation durch DS2MB abhängig. Nach dem Start registriert sich DS2MB beim Konfigurationsdomänencontroller, sodass dieser Konfigurationsdomänencontroller DS2MB benachrichtigen kann, wenn Änderungen an der Exchange-Konfiguration vorgenommen werden. Diese Benachrichtigungen erfolgen innerhalb von 15 Sekunden nach einer Änderung. Sobald die Änderung auf den Konfigurationsdomänencontroller repliziert wurde, sollte sie auch von DS2MB in der Metabase repliziert werden. DS2MB verfolgt Änderungen an Verzeichnisobjekten anhand von USNs (Update Sequence Numbers, Aktualisierungssequenznummern).
Architektur des Exchange-System-ManagersDer Exchange-System-Manager ist ein MMC-basiertes Tool (Microsoft Management Console), das Administratoren eine grafische Benutzeroberfläche zur Verfügung stellt, mit dem die Konfiguration von Exchange 2000 Server- oder Exchange Server 2003-Organisationen verwaltet werden kann. Der Exchange-System-Manager ist jedoch mehr als nur ein einzelnes Snap-In, sondern stellt ein System eigenständiger Snap-Ins und Erweiterungs-Snap-Ins dar, die im MMC-Prozess (MMC.exe) ausgeführt werden. Diese Snap-Ins sind in einer vorkonfigurierten MMC-Datei mit der Bezeichnung Exchange System Manager.msc gespeichert, die sich im Verzeichnis \Programme\Exchsrvr\Bin befindet. Der Exchange-System-Manager kann über das Startmenü gestartet werden. Klicken Sie dazu in der Programmgruppe Microsoft Exchange auf die Verknüpfung System-Manager. Sie können das Exchange-System-Snap-In auch zu den benutzerdefinierten MMC-basierten Tools hinzufügen. Das Exchange-System-Snap-In bildet die Hauptkomponente des Exchange-System-Managers.
124
Folgende Themen werden in diesem Abschnitt behandelt:
MMC-Integration Da alle Exchange-System-Manager-Snap-Ins auf MMC basieren, müssen Sie Kenntnisse über die Integration dieser Snap-Ins in MMC besitzen.
Kommunikation mit dem Microsoft Active Directory-Verzeichnisdienst Die meisten Exchange Server 2003-Konfigurationsobjekte befinden sich in Active Directory. Daher müssen Sie wissen, was diese Objekte bedeuten und wie der Exchange-System-Manager mit Active Directory kommuniziert, um auf diese Objekte zuzugreifen.
Kommunikation mit dem Exchange-Informationsspeicher Speichergruppen, Nachrichtendatenbanken und einzelne Postfächer sowie Öffentliche Ordner sind Exchange-Speicherkomponenten. Wenn Sie diese Komponenten konfigurieren, kommuniziert der Exchange-System-Manager mit dem Exchange-Informationsspeicher über die Protokolle MAPI oder DAV (Distributed Authoring and Versioning). Sie müssen mit diesen Kommunikationsmechanismen vertraut sein, um zu erkennen, welche Server in einem Computernetzwerk über eine einzelne Konsole verwaltet werden können.
Integration in Windows-Verwaltungsinstrumentation (WMI) Der Exchange-System-Manager kommuniziert mit WMI-Anbietern, um dynamische Informationen anzuzeigen, beispielsweise eine Liste der zu übermittelnden Nachrichten, die sich gegenwärtig noch in einer Nachrichtenwarteschlange befinden. Zum Verständnis der Funktionsweise von Überwachungstools, z. B. der Warteschlangenanzeige oder des Nachrichtenstatus, müssen Sie wissen, wann und wie der Exchange-System-Manager mit WMI-Anbietern und den zugehörigen Diensten kommuniziert.
Konfiguration von Exchange Server 2003-Diensten Der Exchange-System-Manager ist ebenfalls ein Dienstkonfigurationsprogramm, mit dem Sie dienstspezifische Parameter in der Registrierung eines Exchange-Servers festlegen können. Beim Festlegen von Diagnoseprotokolliergraden muss der Exchange-System-Manager beispielsweise auf die Registrierungsdatenbank eines Exchange-Servers zugreifen.
In diesem Abschnitt wird davon ausgegangen, dass Sie mit Active Directory und den grundlegenden Konzepten der Verwaltung einer Exchange Server 2003-Organisation vertraut sind. Weiterhin wird vorausgesetzt, dass Sie die Vorgehensweise zum Installieren des Exchange-System-Managers auf einer dedizierten Arbeitsstation kennen.
Weitere Informationen über die Installation des Exchange-System-Managers und die Verfahrensweise zur effizienten Verwaltung einer Exchange Server 2003-Organisation finden Sie im Exchange Server 2003-Administratorhandbuch .
Integration in MMCBei der Installation des Exchange-System-Managers auf einem Server mit Exchange Server 2003 oder auf einem Verwaltungscomputer werden die Exchange-MMC-Snap-Ins vom Setupprogramm in der lokalen Registrierung registriert, damit diese Snap-Ins
125
im MMC-Tool zur Verfügung stehen. Die Snap-Ins sind in COM-In-Process-Server-DLL-Dateien (Component Object Model Dynamic Link Libraries) implementiert. Im Unterschied zu einer eigenständigen Anwendung, die als separater Prozess ausgeführt wird, stellt eine In-Process-Server-DLL ein oder mehrere COM-Objekte bereit und wird innerhalb des Prozesses der Clientanwendung ausgeführt, die diese Objekte verwendet. Beispielsweise werden MMC-Snap-Ins mit MMC.exe ausgeführt. Die Snap-Ins müssen in der Registrierung unter folgenden Schlüsseln registriert sein:
HKEY_CLASSES_ROOT\CLSID Jedem Snap-In wird eine GUID zugewiesen, die das Snap-In als eindeutiges Objekt der COM-Klasse in einer In-Process-Server-DLL identifiziert. Diese Bezeichner, die auch als Klassenkennung (CLSIDs) bezeichnet werden, müssen für jedes einzelne Objekt im Registrierungsschlüssel CLSID registriert sein. Beispielsweise ist {1B600AEA-10BA-11d2-9F28-00C04FA37610} die CLSID der SystemMgr Class. Die SystemMgr Class ist in einer In-Process-Server-DLL mit der Bezeichnung Exadmin.dll zu finden, die sich im Verzeichnis \Program Files\Exchsrvr\Bin befindet. (Die meisten Exchange-Snap-Ins befinden sich in dieser DLL.) Durch die Einträge unter dem Registrierungsschlüssel CLSID werden das Threadingmodell für die COM-Klassen, die ProgID, die Versionsnummer der COM-Klassen und andere Parameter definiert.
HKEY_LOCAL_MACHINE\Software\Microsoft\MMC\SnapIns Zur Definition von COM-Komponenten als MMC-Snap-Ins müssen CLSIDs unter dem Schlüssel SnapIns registriert sein. Wenn Sie zum Beispiel nach dem CLSID-Schlüssel {1B600AEA-10BA-11d2-9F28-00C04FA37610} unter dem Schlüssel SnapIns suchen (d. h. nach der CLSID von SystemMgr Class), stellen Sie fest, dass dieser Eintrag zum Exchange-System-Snap-In gehört, der das grundlegende Snap-In des Exchange-System-Managers ist. In der folgenden Tabelle sind die Einträge für Snap-Ins unter dem Schlüssel SnapIns aufgeführt.
126
Registrierungsparameter für MMC-Snap-Ins
Übergeordneter Schlüssel
Parameter Typ Beschreibung
{CLSID} NameString REG_SZ Durch den Wert NameString wird der Anzeigename des Snap-Ins angegeben, der in der MMC-Benutzeroberfläche angezeigt wird, wenn einer Konsole ein Snap-In hinzugefügt wird. Beispielsweise wird durch Namestring=Exchange-System der Anzeigename für das Exchange-System-Snap-In definiert.
127
Übergeordneter Schlüssel
Parameter Typ Beschreibung
{CLSID} About REG_SZ Der Wert About enthält die CLSID des Objekts, durch das ein Symbol, eine Beschreibung und das Dialogfeld Info für das Snap-In bereitgestellt werden. Beispielsweise verweist der Eintrag About= {1B600AEB-10BA-11d2-9F28-00C04FA37610} auf eine bestimmte CLSID. Wenn Sie diese CLSID unter HKEY_CLASSES_ROOT\
CLSID suchen, können Sie erkennen, dass es sich um die CLSID für die Klasse AboutSystemMgr handelt, die ebenfalls in Exadmin.dll implementiert ist.
128
Übergeordneter Schlüssel
Parameter Typ Beschreibung
{CLSID} NameStringIndirect REG_SZ Der Wert für NameStringIndirect definiert einen Ressourcen-DLL-Namen sowie eine Zeichenfolgenkennung und bietet somit eine indirekte Möglichkeit, den Namen des Snap-Ins abzurufen. Beispielsweise wird durch
NameStringIndirect=@C:\\Programme\\Exchsrvr\\bin\\exadmin.dll,-12577 der in der Datei Exadmin.dll enthaltene Name des Exchange-System-Snap-Ins angegeben. Falls NameStringIndirect nicht existiert oder mit dem entsprechenden Wert keine Zeichenfolge erfolgreich geladen werden kann, verwendet MMC als Namenszeichenfolge den Wert von NameString.
{CLSID}\ StandAlone N/A N/A Durch einen vorhandenen Schlüssel StandAlone wird angegeben,
129
Übergeordneter Schlüssel
Parameter Typ Beschreibung
dass es sich um ein eigenständiges Snap-In handelt. Eigenständige Snap-Ins können im Dialogfeld Snap-In hinzufügen/entfernen zu einer MMC-Konsole hinzugefügt werden. Sie können eigenständige Snap-Ins zu Unterknoten anderer Snap-Ins hinzufügen, indem Sie das eigenständige Snap-In wie ein Erweiterungs-Snap-In behandeln.
Erweiterungs-Snap-Ins verfügen nicht über den Schlüssel StandAlone. Daher lässt sich ein solches Snap-In nur einer MMC-Konsole hinzufügen, wenn zunächst ein eigenständiges Snap-In hinzugefügt wird, das die Knoten bereitstellt, die dann durch das Erweiterungs-Snap-In erweitert werden können. Beispielsweise wird durch das Exchange-Informationsspeicher-Erweiterungs-Snap-
130
Übergeordneter Schlüssel
Parameter Typ Beschreibung
In das System-Manager-Snap-In erweitert. Dieses Erweiterungs-Snap-In kann somit nur hinzugefügt werden, nachdem Sie das System-Manager-Snap-In zur MMC-Konsole hinzugefügt haben. Erweiterungs-Snap-Ins werden als verfügbare Erweiterungen für eigenständige Snap-Ins im Dialogfeld Snap-In hinzufügen/entfernen auf der Registerkarte Erweiterungen aufgeführt.
131
Übergeordneter Schlüssel
Parameter Typ Beschreibung
{CLSID}\ NodeTypes {CLSID} N/A Knoten beziehen sich auf die Konfigurationsobjekte in der MMC-Konsolenstruktur. Im Exchange-System-Manager haben zum Beispiel die einzelnen Serverobjekte im Container Server unter einer administrativen Gruppe einen bestimmten Knotentyp. Knotentypen sind im Schlüssel NodeTypes registriert.
Der Schlüssel NodeTypes enthält Unterschlüssel, die jeweils die GUIDs der Knotentypen sind. MMC verwendet diese GUIDs zur Auflistung der Knotentypen des Snap-Ins. Mithilfe dieser Auflistung können dann die Erweiterungs-Snap-Ins für diese Knotentypen abgerufen werden. Die Erweiterungs-Snap-Ins werden dann als verfügbare Erweiterungen für das Snap-In im Dialogfeld Snap-In
132
KEY_LOCAL_MACHINE\Software\Microsoft\MMC\NodeTypes Für alle erweiterbaren Knotentypen ist jeweils ein eigener Unterschlüssel (d. h. die GUID des Knotentyps) unter dem Schlüssel MMC\NodeTypes registriert. Jeder GUID-Schlüssel enthält einen Unterschlüssel Extensions. Der Schlüssel Extensions enthält wiederum weitere Unterschlüssel, die jeweils die möglichen Typen der Erweiterungen definieren, die dieser Knotentyp aufweisen kann. Jeder Unterschlüssel für Erweiterungstypen enthält Werte für die CLSIDs der Snap-Ins, durch die dieser Knotentyp erweitert wird. Beispielsweise ist das Exchange-Containerobjekt POP3 (GUID {F54E0C6b-11FF-11d2-9F28-00C04FA37610}) ein erweiterbarer Knotentyp des Exchange-Protokolle-Snap-Ins.
Ebenso verfügt der Schlüssel \NodeTypes\{F54E0C6b-11FF-11d2-9F28-00C04FA37610} über einen Unterschlüssel Extensions, durch den die CLSID des Exchange-POP3-Erweiterungs-Snap-Ins in den Unterschlüsseln ContextMenu und NameSpace aufgelistet werden. Dadurch wird angegeben, dass durch das Exchange-POP3-Erweiterungs-Snap-In der Namespace und das Kontextmenü im Exchange-System-Manager für das Exchange-POP3-Containerobjekt erweitert werden. Der Namespace ist die Hierarchie aller Objekte, die über eine MMC-Konsole verwaltet werden können.
Exchange Server 2003-Snap-Ins und Snap-In-ErweiterungenWie im vorherigen Abschnitt erläutert, wird durch eigenständige Snap-Ins und Erweiterungs-Snap-Ins die Benutzeroberfläche des Exchange-System-Managers erstellt. Mit Erweiterungs-Snap-Ins lassen sich die Funktionen von eigenständigen Snap-Ins oder anderen Erweiterungs-Snap-Ins erweitern. Diese modulare Architektur ermöglicht es Entwicklern, spezielle Verwaltungsfunktionen zu implementieren. Administratoren können mithilfe dieser Erweiterungen zudem benutzerdefinierte Verwaltungskonsolen erstellen. Beispielsweise können Sie das Exchange-Snap-In Nachrichtenstatus in eine benutzerdefinierte MMC-Konsole einfügen und dieses Snap-In einem Messagingadministrator zur Verfügung stellen, der allein für die Nachrichtenverfolgung zuständig ist.
In der folgenden Tabelle sind die verfügbaren Exchange Server 2003-Snap-Ins und die möglichen Snap-In-Erweiterungen aufgeführt.
Exchange Server 2003-Snap-Ins und Snap-In-Erweiterungen
Snap-In Snap-In-Erweiterung In-Process-Server-DLL
Beschreibung
Exchange-Nachrichtenstatus
Nicht zutreffend Exadmin.dll Bietet Zugriff auf den Nachrichtenstatus. Dies ist ein eigenständiges Snap-In.
133
Snap-In Snap-In-Erweiterung In-Process-Server-DLL
Beschreibung
Exchange-SMTP Exps.dll Ermöglicht die Verwaltung von SMTP (Simple Mail Transfer Protocol) und virtueller SMTP-Server.
Exchange-X.400 Exadmin.dll Ermöglicht die Verwaltung des lokalen MTA (Message Transfer Agent) und der X.400-Protokolleinstellungen.
Exchange-Server Nicht zutreffend Exadmin.dll Ermöglicht die Verwaltung von speicherspezifischen Einstellungen eines Exchange-Servers.
Das Snap-In Exchange-Server ist ein Erweiterungs-Snap-In des eigenständigen Snap-Ins Exchange-System.
134
Snap-In Snap-In-Erweiterung In-Process-Server-DLL
Beschreibung
Exchange-DXA Exadmin.dll Ermöglicht die Überprüfung von Einstellungen für die Verzeichnissynchronisierung, wenn Sie Microsoft Exchange Connector für Microsoft Mail auf einem Server mit einer älteren Version von Exchange ausführen.
Hinweis: Die Konfiguration von Exchange 2000 Server-Ressourcen mit dem System-Manager von Exchange Server 2003 wird nicht unterstützt. Stellen Sie sicher, dass Sie zum Konfigurieren der Verzeichnissynchronisierung mit Microsoft Mail den System-Manager von Exchange 2000
135
Snap-In Snap-In-Erweiterung In-Process-Server-DLL
Beschreibung
Exchange-Informationsspeicher
Exadmin.dll Ermöglicht die Verwaltung von Speichergruppen, Postfachspeichern und Informationsspeichern für Öffentliche Ordner.
Exchange-Überwachung
Exadmin.dll Ermöglicht die Überprüfung des Zustands von Exchange-Servern und Messagingconnectors zwischen Routinggruppen.
136
Snap-In Snap-In-Erweiterung In-Process-Server-DLL
Beschreibung
Exchange-Protokolle Exadmin.dll Wie bereits in einem vorhergehenden Eintrag dieser Tabelle erläutert, implementiert dieses Snap-In den Container Protokolle und erstellt leere Knoten auf Unterebenen, die von den Erweiterungs-Snap-Ins Exchange-HTTP, Exchange-IMAP4, Exchange-NNTP, Exchange-POP3, Exchange-SMTP und Exchange-X.400 zur Optimierung der Benutzeroberfläche im Exchange-System-Manager verwendet werden können.
Exchange-Warteschlangenanzeige
Exadmin.dll Bietet Zugriff auf die Warteschlangenanzeige im Exchange-System-Manager, der Verwaltungsschnittstellen für SMTP, MTA, X.400 und andere Connectorwarteschlangen bereitstellt.
137
Snap-In Snap-In-Erweiterung In-Process-Server-DLL
Beschreibung
Exchange-System Nicht zutreffend Exadmin.dll Das grundlegende MMC-Snap-In des Exchange-System-Managers. Durch dieses eigenständige Snap-In wird die Benutzeroberfläche implementiert, über die ein Administrator globale Einstellungen und Servereigenschaften verwalten kann. Das Snap-In stellt auch zusätzliche Knoten bereit, die von den übrigen Snap-Ins zur Erweiterung der Benutzeroberfläche verwendet werden können.
Exchange-Adresslisten
Exadmin.dll Ermöglicht die Verwaltung von Adresslisten, einschließlich globaler Adresslisten und Offlineadressbücher.
Exchange-Adressvorlagen
Exadmin.dll Ermöglicht die Verwaltung von Adressvorlagen.
138
Snap-In Snap-In-Erweiterung In-Process-Server-DLL
Beschreibung
Exchange-Kalenderconnector
Exadmin.dll Ermöglicht die Verwaltung von Kalenderconnector-Instanzen. Mit dem Kalenderconnector können Frei-/Gebucht-Informationen zwischen Exchange-Benutzern und Benutzern von Lotus Notes oder Novell GroupWise synchronisiert werden.
139
Snap-In Snap-In-Erweiterung In-Process-Server-DLL
Beschreibung
Exchange cc:Mail Exadmin.dll Ermöglicht die Überprüfung der Konfiguration von Connector für Lotus cc:Mail, das auf Exchange 2000 Server-Systemen ausgeführt wird.
Hinweis: Die Konfiguration von Exchange 2000 Server-Ressourcen mit dem System-Manager von Exchange Server 2003 wird nicht unterstützt. Stellen Sie sicher, dass Sie zum Konfigurieren von Connector für Lotus cc:Mail den System-Manager von Exchange 2000 verwenden.
140
Snap-In Snap-In-Erweiterung In-Process-Server-DLL
Beschreibung
Exchange-DXA Exadmin.dll Ermöglicht die Überprüfung von Einstellungen für die Verzeichnissynchronisierung, wenn Connector für Microsoft Mail auf einem Server mit einer älteren Version von Exchange ausgeführt wird.
Hinweis: Die Konfiguration von Exchange 2000 Server-Ressourcen mit dem System-Manager von Exchange Server 2003 wird nicht unterstützt. Stellen Sie sicher, dass Sie zum Konfigurieren der Verzeichnissynchronisierung mit Microsoft Mail den System-Manager von Exchange 2000 verwenden.
141
Snap-In Snap-In-Erweiterung In-Process-Server-DLL
Beschreibung
Exchange-Ordner Exadmin.dll Ermöglicht die Verwaltung von Öffentlichen Ordnern und Öffentlichen Ordnerstrukturen.
Exchange GroupWise Connector
Exadmin.dll Ermöglicht die Verwaltung von Connector für Novell GroupWise.
Exchange-Informationsspeicher
Exadmin.dll Ermöglicht die Verwaltung von Speichergruppen, Postfachspeichern und Informationsspeichern für Öffentliche Ordner.
Wiederherstellung von Exchange-Postfächern
Exadmin.dll Bietet Zugriff auf das Tool zur Wiederherstellung von Postfächern, mit dem Sie einzelne Postfächer aus einer Sicherung wiederherstellen können.
Exchange-Nachrichtenstatus
Exadmin.dll Ermöglicht den Zugriff auf den Nachrichtenstatus und dessen Verwendung.
Exchange-Überwachung
Exadmin.dll Bietet Zugriff auf die Überwachungs- und Statusfunktionen zum Verwalten der Verbindungen zwischen Routinggruppen.
142
Snap-In Snap-In-Erweiterung In-Process-Server-DLL
Beschreibung
Exchange MSMail Exadmin.dll Ermöglicht die Überprüfung der Konfigurationseinstellungen von Connector für Microsoft Mail auf Exchange 2000-Servern.
Hinweis: Die Konfiguration von Exchange 2000 Server-Ressourcen mit dem System-Manager von Exchange Server 2003 wird nicht unterstützt. Stellen Sie sicher, dass Sie zum Konfigurieren von Connector für Microsoft Mail den System-Manager von Exchange 2000 verwenden.
143
Snap-In Snap-In-Erweiterung In-Process-Server-DLL
Beschreibung
Exchange Notes Connector
Exadmin.dll Bietet Zugriff auf die Konfigurationseinstellungen von Connector für Lotus Notes.
Exchange-Protokolle Exadmin.dll Wie bereits in einem vorhergehenden Eintrag dieser Tabelle erläutert, implementiert dieses Snap-In den Container Protokolle und erstellt leere Knoten auf Unterebenen, die von den Erweiterungs-Snap-Ins Exchange-HTTP, Exchange-IMAP4, Exchange-NNTP, Exchange-POP3, Exchange-SMTP und Exchange-X.400 zur Optimierung der Benutzeroberfläche im Exchange-System-Manager verwendet werden können.
144
Snap-In Snap-In-Erweiterung In-Process-Server-DLL
Beschreibung
Exchange-Warteschlangenanzeige
Exadmin.dll Bietet Zugriff auf die Warteschlangenanzeige im Exchange-System-Manager, der Verwaltungsschnittstellen für SMTP, MTA, X.400 und andere Connectorwarteschlangen bereitstellt.
Exchange-Empfängerrichtlinien
Exadmin.dll Ermöglicht die Verwaltung von Empfängerrichtlinien, mithilfe derer der Empfängeraktualisierungsdienst Empfängerinformationen (z. B. E-Mail-Adressen) den entsprechenden Benutzerkonten zuordnet.
145
Snap-In Snap-In-Erweiterung In-Process-Server-DLL
Beschreibung
Exchange Schedule+ Frei-/Gebucht-Connector
Exadmin.dll Ermöglicht die Überprüfung der Konfigurationseinstellungen des Schedule+ Frei-/Gebucht-Connectors auf Servern, auf denen Exchange 2000 Server ausgeführt wird.
Hinweis: Die Konfiguration von Exchange 2000 Server-Ressourcen mit dem System-Manager von Exchange Server 2003 wird nicht unterstützt. Stellen Sie sicher, dass Sie zum Konfigurieren des Schedule+ Frei-/Gebucht-Connectors den System-Manager von Exchange 2000 verwenden.
146
Snap-In Snap-In-Erweiterung In-Process-Server-DLL
Beschreibung
Exchange-Server Exadmin.dll Ermöglicht die Verwaltung von speicherspezifischen Einstellungen eines Exchange-Servers.
Erstellen benutzerdefinierter Exchange-VerwaltungskonsolenZum Erstellen benutzerdefinierter Verwaltungskonsolen auf Grundlage von Exchange-Snap-Ins können Sie die eigenständigen Snap-Ins Exchange-System oder Exchange-Nachrichtenstatus in der MMC-Konsole verwenden. Sie können jedoch nicht allein mit dem Erweiterungs-Snap-In Exchange-Ordner eine MMC-Konsole für die Verwaltung Öffentlicher Ordner erstellen, sondern müssen zunächst das eigenständige Snap-In Exchange-System zur Konsole hinzufügen. Allerdings erhält der Administrator beim Hinzufügen des Snap-Ins Exchange-System auch Zugriff auf globale Einstellungen und Servereigenschaften. Dies ist jedoch unter Umständen nicht erwünscht. Glücklicherweise gibt es eine Lösung für dieses Problem.
Anstatt separate Snap-Ins zur Konsole hinzuzufügen, können Sie das gesamte Snap-In Exchange-System hinzufügen und dann im MMC-Namespace das Objekt suchen, das bereitgestellt werden soll, z. B. den Knoten Öffentliche Ordner. Wenn Sie dann mit der rechten Maustaste auf diesen Knoten klicken, können Sie aus dem Kontextmenü den Befehl Neues Fenster auswählen. Dadurch wird ein Unterfenster geöffnet, in dem der ausgewählte Knoten als Stammebene der Hierarchie dargestellt ist. Anschließend können Sie das Unterfenster, in dem alle Knoten angezeigt werden, schließen und die Konsole in ihrem aktuellen Zustand als MSC-Datei speichern.
MMC-Konsolen können jeweils in einem der beiden folgenden Modi ausgeführt werden: im Autorenmodus oder im Benutzermodus. Im Autorenmodus können neue Konsolen erstellt oder vorhandene Konsolen geändert werden. Der Benutzermodus dient zur Arbeit mit vorhandenen Konsolen für die Systemverwaltung. Es gibt drei verschiedene Stufen des Benutzermodus:
Benutzermodus – Vollzugriff Wenn eine Konsole in diesem Modus ausgeführt wird, kann der Benutzer zwar sämtliche verfügbaren Funktionen des Snap-Ins verwenden, jedoch keine Snap-Ins hinzufügen oder entfernen und keine Änderungen an der Konsole speichern.
Benutzermodus – beschränkter Zugriff, mehrere Fenster Wenn eine Konsole in diesem Modus ausgeführt wird, kann der Benutzer keine Snap-Ins hinzufügen oder
147
entfernen und keine Änderungen an der Konsole speichern. Der Benutzer kann ebenfalls keine Fenster schließen, die bei der letzten Speicherung der Konsole durch den Konsolenautor geöffnet waren.
Benutzermodus – beschränkter Zugriff, Einzelfenster Wenn eine Konsole in diesem Modus ausgeführt wird, kann der Benutzer keine Snap-Ins hinzufügen oder entfernen und keine Änderungen an der Konsole speichern. Außerdem können keine weiteren Unterfenster geöffnet werden.
In der folgenden Abbildung ist eine benutzerdefinierte Konsole zur Verwaltung Öffentlicher Ordner dargestellt.
Konsole zur Verwaltung Öffentlicher Ordner im Benutzermodus
Mit der MMC-Befehlszeilenoption /a können Sie eine gespeicherte Konsole im Autorenmodus öffnen und Änderungen an einer solchen gespeicherten Konsole vornehmen. Wenn eine gespeicherte Konsole mit der Option /a geöffnet wird, befindet sich die Konsole unabhängig von ihrem Standardmodus stets im Autorenmodus. Der Standardmodus wird dadurch jedoch nicht dauerhaft geändert. Beim Öffnen ohne Angabe der Befehlszeilenoption /a werden Konsolendateien im jeweils festgelegten Standardmodus geöffnet.
Hinweis: Der Schlüssel StandAlone darf nicht zu den Registrierungseinstellungen eines Erweiterungs-Snap-Ins hinzugefügt werden, um dieses Snap-In in ein eigenständiges Snap-In umzuwandeln. Erweiterungs-Snap-Ins sind von den von übergeordneten
148
Snap-Ins bereitgestellten Knoten und Funktionen abhängig und funktionieren daher als eigenständige Snap-Ins nicht ordnungsgemäß.
Verwalten von Konfigurationsinformationen in Active DirectoryWenn Sie das Snap-In Exchange-System zu einer benutzerdefinierten Konsole hinzufügen, wird das Dialogfeld Domänencontroller ändern angezeigt. In diesem Dialogfeld können Sie einen Domänencontroller aus einer Domäne in der Struktur der Exchange Server 2003-Organisation auswählen oder die Standardkonfiguration übernehmen, um eine Verbindung mit einem beliebigen Domänencontroller mit Schreibzugriff herzustellen. Der Zugriff auf Active Directory wird benötigt, um die Konfigurationsinformationen einer Exchange Server 2003-Organisation abrufen zu können, die in der Konfigurationsverzeichnispartition gespeichert sind. Eine entsprechende Erläuterung finden Sie unter Exchange Server 2003 und Active Directory .
Hinweis: Sie können eine Exchange Server 2003-Organisation nur von einem Computer aus verwalten, der Mitglied einer Domäne ist, die von den Domänencontrollern der Struktur, in der die Server mit Exchange Server 2003 enthalten sind, als vertrauenswürdig eingestuft wird.
Herstellen von Bindungen an einen DomänencontrollerDer Exchange-System-Manager kommuniziert per ADSI (Active Directory Service Interfaces) mit Active Directory. ADSI benötigt das LDAP-Protokoll (Lightweight Directory Access Protocol). Wenn Sie im Dialogfeld Domänencontroller ändern einen bestimmten Domänencontroller angeben, wird beim Öffnen des Exchange-System-Managers eine direkte LDAP-Verbindung mit diesem Domänencontroller hergestellt. Falls Sie stattdessen die Standardkonfiguration übernehmen (d. h. keinen Domänencontroller angeben), stellt ADSI eine serverlose Bindung an einen Domänencontroller her.
Bei einer serverlosen Bindung sucht ADSI über den Locatordienst von Netlogon nach dem am besten geeigneten Domänencontroller. Dieser Domänencontroller befindet sich stets in der Domäne, die dem aktuellen Sicherheitskontext des Benutzers zugeordnet ist, der eine Verbindung mit Active Directory herstellt. Jeder Domänencontroller registriert seinen Hostnamen in DNS (Domain Name System) und seinen NetBIOS-Namen über einen transportabhängigen Mechanismus, z. B. WINS (Windows Internet Name Service). Der
149
Locatordienst sucht den Namen und sendet dann ein Datagramm an den Domänencontroller, durch den der Name registriert wurde. Für NetBIOS-Domänennamen ist dieses Datagramm eine Mailslot-Nachricht. Ein Mailslot ist ein Mechanismus, der vom Betriebssystem für 1:1- oder 1:n-IPC (Interprocess Communications) bereitgestellt wird. Für DNS-Domänennamen ist das Datagramm eine LDAP-UDP-Suche (User Datagram Protocol). Wenn ein Domänencontroller antwortet, bedeutet dies, dass er betriebsbereit ist.
Hinweis: NetBIOS ist für Exchange Server 2003 noch erforderlich. Daher müssen im Netzwerk installierte WINS-Server weiterhin in Betrieb bleiben. Beispielsweise könnte der Exchange-System-Manager unter Umständen NetBIOS für die RPC-basierte Kommunikation (Remote Procedure Call) mit einem Exchange-Server auswählen, sofern dies in der RPC-Protokollbindungsreihenfolge definiert ist. Die RPC-Protokollbindungsreihenfolge wird in dem REG_STRING-Registrierungsparameter Rpc_Binding_Order definiert, der sich unter folgendem Schlüssel befindet: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\Exchange Provider. In der Standardeinstellung ist NetBIOS enthalten: ncalrpc,ncacn_ip_tcp,ncacn_spx,ncacn_np,netbios,ncacn_vns_spp. Die Kommunikation mit Domänencontrollern basiert jedoch auf LDAP und erfordert kein NetBIOS oder WINS.
Gemäß der Darstellung in der folgenden Abbildung bevorzugt der Locatordienst Domänencontroller am lokalen Active Directory-Standort und stellt eine Verbindung mit dem ersten reagierenden Domänencontroller her. Wenn der Locatordienst ein Datagramm an den Domänencontroller sendet, sucht der Domänencontroller die IP-Adresse des Clients im Konfigurations-/Standort-/Subnetzcontainer in Active Directory, um ein Subnetzobjekt zu finden, das dem IP-Adressbereich des Clients entspricht. Durch die Eigenschaft siteObject des Subnetzobjekts wird der DN (Distinguished Name) des Standorts offen gelegt, der den Client enthält, z. B.: CN=Standardmäßiger-Erster-Standortname,CN=Standorte,CN=Konfiguration,DC=fabrikam,DC=com. Der Domänencontroller antwortet auf das Datagramm durch Senden des DN des Standorts, in dem sich der Client befindet, und gibt ebenfalls an, ob der Domänencontroller für diesen Standort zuständig ist. Wenn der Domänencontroller nicht für diesen Standort zuständig ist und der Locatordienst noch nicht versucht hat, einen Domänencontroller am Standort des Clients zu finden, sucht der Locatordienst erneut einen Domänencontroller am lokalen Standort. Nachdem ein Domänencontroller gefunden wurde, wird eine LDAP-Verbindung mit Active Directory hergestellt, und die Verbindungsinformationen werden zwischengespeichert, sodass für nachfolgende Verbindungen für dieselbe Anwendung der Algorithmus zur serverlosen Bindung nicht wiederholt werden muss. Im Bindungscache werden die Verbindungshandles zu den entsprechenden Servern sowie Verbindungseigenschaften wie Verschlüsselungs- und Authentifizierungsinformationen gespeichert.
150
Serverlose Bindung an einen Domänencontroller
Hinweis: Eine serverlose Bindung wird als Verbindungsmethode bevorzugt, da bei dieser Verbindung Anforderungen von mehreren Clients zwischen mehreren Domänencontrollern ausgeglichen werden können und automatisch zu einem anderen Domänencontroller gewechselt werden kann, wenn ein bestimmter Domänencontroller nicht mehr verfügbar ist.
Die Exchange-Organisation in der KonfigurationsverzeichnispartitionDie meisten Konfigurationseinstellungen, die Sie mit dem Exchange-System-Manager verwalten, sind in Verzeichnisobjekten in der Konfigurationsverzeichnispartition in Active Directory gespeichert. Die Hierarchie der Konfigurationsobjekte, die in der Konsolenstruktur des Exchange-System-Managers angezeigt werden, stimmt in hohem Maße mit der Hierarchie der Verzeichnisobjekte in der Konfigurationsverzeichnispartition überein. Es sind nur geringe Unterschiede vorhanden. Beispielsweise können Sie in einer Organisation mit nur einer administrativen Gruppe und einer Routinggruppe die Konfigurationsobjekte in einer Hierarchie mit oder ohne administrative Gruppe und Routinggruppe anzeigen. Aktivieren oder deaktivieren Sie dazu in den Eigenschaften des Exchange-Organisationsobjekts (Stammobjekt in der Konsolenstruktur des Exchange-System-Managers) auf der Registerkarte Allgemein die Kontrollkästchen Routinggruppen anzeigen und Administrative Gruppen anzeigen. Container für eine administrative Gruppe und Routinggruppe sind in der Konfigurationsverzeichnispartition immer vorhanden.
151
In der folgenden Abbildung ist die Hierarchie von Verzeichnisobjekten aus der Konfigurationsverzeichnispartition (in Active Directory-Standorte und -Dienste) dargestellt und wird mit der Hierarchie der Konfigurationsobjekte im Exchange-System-Manager verglichen (administrative Gruppen und Routinggruppen sind aktiviert).
Hierarchien von Verzeichnis- und Konfigurationsobjekten
Der Exchange-System-Manager ordnet die Konfigurationsobjekte aus der Konfigurationsverzeichnispartition in der Konsolenstruktur nach folgenden allgemeinen Kategorien an:
Globale Exchange-Objekte Globale Exchange-Objekte sind Objekte, durch die Internet-Nachrichtenformate und andere Einstellungen definiert werden, die Einfluss auf die gesamte Exchange-Organisation haben. Beispielsweise werden durch das Objekt Mobile Dienste Einstellungen für Exchange ActiveSync und Microsoft Office Outlook Mobile Access definiert, die für alle Empfänger in der Exchange-Organisation gelten. Die Verzeichnisobjekte, die diesen Konfigurationsobjekten entsprechen, befinden sich im Container Globale Einstellungen unter dem Container der Exchange-Organisation in der Konfigurationsverzeichnispartition.
Empfängerobjekte Empfängerobjekte definieren Regeln, durch die die E-Mail-Adressen bestimmt werden, die der Empfängeraktualisierungsdienst den postfachaktivierten und E-Mail-aktivierten Empfängerobjekten zuweist. Durch Empfängerobjekte wird auch bestimmt, auf welche Weise serverbasierte Adresslisten erstellt werden. Mit den Konfigurationsobjekten im Container Empfänger im Exchange-
152
System-Manager können Sie Details und Adressvorlagen anpassen, um die Benutzeroberfläche des Adressbuchs in Outlook zu ändern.
Im Container Empfänger des Exchange-System-Managers werden Verzeichnisobjekte aus einer Reihe von Containern in der Konfigurationsverzeichnispartition zusammengefasst. Adresslisten-Definitionsobjekte und Objekte des Empfängeraktualisierungsdiensts befinden sich im Container Adresslisten. Objekte für Details und Adressvorlagen sind im Container Adressierung enthalten. Objekte für Richtlinien, die E-Mail-Adressen für postfachaktivierte und E-Mail-aktivierte Empfänger definieren, sind im Container Empfängerrichtlinien unter dem Exchange-Organisationsobjekt in Active Directory gespeichert.
Objekte der administrativen Gruppe und der Routinggruppe Objekte der administrativen Gruppe und der Routinggruppe bieten keinen Zugriff auf Konfigurationsparameter im Exchange-System-Manager. Stattdessen werden diese Objekte zur Definition der administrativen Topologie und der Nachrichtenroutingtopologie einer Exchange-Organisation verwendet. Beispielsweise kann mit administrativen Gruppen die Verwaltung von Exchange-Servern und -Ressourcen aufgeteilt werden. Mit Routinggruppen lässt sich die Nachrichtenübertragung zwischen verschiedenen Standorten optimieren. Weitere Informationen zur administrativen und Routinggruppenplanung finden Sie unter Planning an Exchange Server 2003 Messaging System.
Serverobjekte Serverobjekte enthalten die für einzelne Exchange-Server in der Messagingorganisation geltenden Einstellungen. Serverobjekte enthalten auch zusätzliche Konfigurationsobjekte für Speichergruppen und Messagingprotokolle. Beim Anzeigen der Eigenschaften eines Serverobjekts werden vom Exchange-System-Manager Informationen aus verschiedensten Informationsquellen auf mehreren Eigenschaftenregisterkarten zusammengefasst. Serverkonfigurationsobjekte entsprechen den Serververzeichnisobjekten in der Konfigurationsverzeichnispartition, die sich im Container Server unter einer administrativen Gruppe befindet.
Systemrichtlinienobjekte Mithilfe von Systemrichtlinienobjekten lässt sich die Systemverwaltung vereinfachen, indem Parameter für mehrere Exchange-Server über ein einzelnes Konfigurationsobjekt konfiguriert werden, beispielsweise ein Postfachspeicher, ein Informationsspeicher für Öffentliche Ordner oder Servereinstellungen. Systemrichtlinienobjekte sind jedoch standardmäßig nicht vorhanden. Bevor Sie eine Systemrichtlinie erstellen können, müssen Sie zunächst den Container Systemrichtlinien zur administrativen Gruppe hinzufügen. Klicken Sie dazu mit der rechten Maustaste auf die administrative Gruppe, zeigen Sie auf Neu, und wählen Sie dann die Option Systemrichtliniencontainer aus. Klicken Sie anschließend zum Erstellen einer Richtlinie für Postfachspeicher, einer Richtlinie für Öffentliche Informationsspeicher oder einer Serverrichtlinie mit der rechten Maustaste auf den Container Systemrichtlinien, und konfigurieren Sie die gewünschte Richtlinie. Weitere Informationen zur Konfiguration des Postfachspeichers, des Informationsspeichers für
153
Öffentliche Ordner oder der Servereigenschaften finden Sie im Exchange Server 2003 Administration Guide.
Ordnerhierarchien Ordnerhierarchieobjekte befinden sich im Container Ordner unter einer administrativen Gruppe. Jedes Hierarchieobjekt in diesem Container bezieht sich auf eine bestimmte Öffentliche Ordner-Struktur im Exchange-Informationsspeicher. Eine Öffentliche Ordner-Struktur kann in Öffentlichen Informationsspeichern auf mehreren Exchange-Servern repliziert werden. Die Hierarchieobjekte befinden sich jedoch im Container für die Ordnerhierarchien unter einer administrativen Gruppe in der Konfigurationsverzeichnispartition.
Hinweis: Der Knoten Tools im Exchange-System-Manager entspricht keinem Verzeichnisobjekt in der Konfigurationsverzeichnispartition. Der Knoten Tools bietet lediglich Zugriff auf Erweiterungs-Snap-Ins, z. B. den Nachrichtenstatus, die jedoch unter Umständen auf Objekte in Active Directory zugreifen können, um Konfigurationsinformationen zu übernehmen.
Exchange-System-Manager und BerechtigungseinstellungenDas Berechtigungsmodell von Exchange Server 2003 basiert vollständig auf dem Microsoft Windows-Sicherheitsmodell. Das Berechtigungsmodell orientiert sich am Exchange-Organisationsobjekt und den administrativen Gruppen in der Konfigurationsverzeichnispartition. Wenn Sie mit der rechten Maustaste auf das Organisationsobjekt oder die administrative Gruppe in der Konsolenstruktur des Exchange-System-Managers klicken, können Sie den Befehl Objektverwaltung zuweisen auswählen, um den Assistenten für die Zuweisung von Verwaltungsberechtigungen zu starten. Mit dem Assistenten für die Zuweisung von Verwaltungsberechtigungen können Sie einem Exchange-Administrator eine der drei folgenden Funktionen zuweisen:
Exchange-Administrator – Vollständig Mit dieser Funktion erhält der Administrator vollständigen Zugriff auf die Exchange-Organisation. Die Berechtigungen Empfangen als und Senden als werden jedoch verweigert. Ein Exchange-Administrator mit vollständigen Rechten kann daher in der Exchange-Organisation nicht die Identität eines anderen Benutzers annehmen. Beispielsweise kann ein Administrator ohne die Berechtigung Senden als keine E-Mail-Nachrichten im Auftrag eines anderen Benutzers senden.
Exchange-Administrator Mit dieser Funktion verfügt der Administrator über ähnliche Berechtigungen wie ein Exchange-Administrator mit vollständigen Rechten, mit Ausnahme der Berechtigungen Besitzer ändern und Berechtigungen ändern, die in dieser Funktion verweigert werden. Ein Exchange-Administrator kann daher alle
154
Einstellungen einer Exchange-Organisation verwalten, jedoch keine Sicherheitseinstellungen ändern.
Exchange-Administrator – Nur Ansicht Diese Funktion gewährt dem Administrator die Berechtigungen Alle Eigenschaften lesen, Inhalte auflisten, Leseberechtigungen und Status des Informationsspeichers anzeigen. Berechtigungen der Funktion Exchange-Administrator – Nur Ansicht werden beispielsweise von Postfachadministratoren benötigt, die Benutzerkonten für Postfächer oder E-Mail aktivieren müssen, jedoch nicht für die Exchange-Serververwaltung verantwortlich sind.
In der folgenden Tabelle sind die wichtigsten Unterschiede zwischen den verschiedenen Exchange-Administratorfunktionen aufgeführt.
Wichtige Unterschiede zwischen Exchange-Administratorfunktionen
Administratorfunktion Sicherheitseinstellungen ändern
Exchange-Konfigurationseinstellungen verwalten
Exchange-Konfigurationseinstellungen anzeigen
Exchange–Administrator – Vollständig
Ja Ja Ja
Exchange–Administrator
Nein Ja Ja
Exchange–Administrator – Nur Ansicht
Nein Nein Ja
Aktivieren der Registerkarte „Sicherheit“ für Objekte im Exchange-System-ManagerMit dem Assistenten für die Zuweisung von Verwaltungsberechtigungen können Exchange-Administratoren oder Gruppen auf Organisationsebene oder auf Ebene einer administrativen Gruppe bestimmte Funktionen zugewiesen werden. Allerdings werden durch den Assistenten für die Zuweisung von Verwaltungsberechtigungen nicht alle Sicherheitseinstellungen angezeigt. Unter Umständen kann es sogar vorkommen, dass der Assistent eine unvollständige Administratorliste anzeigt. Dies ist darin begründet, dass der Assistent für die Zuweisung von Verwaltungsberechtigungen die Administratoren, denen Exchange-Administratorfunktionen zugewiesen werden, anhand eines Attributs des Exchange-Organisationsobjekts in Active Directory erfasst. Dieses Attribut hat die Bezeichnung msExchAdmins. Durch den Assistenten für die Zuweisung von Verwaltungsberechtigungen werden jedoch keine Administratoren mit Berechtigungen erfasst, die von Containern einer höheren Ebene in der Konfigurationsverzeichnispartition ererbt, d. h. übernommen wurden.
155
Beispielsweise verfügen Organisationsadministratoren standardmäßig über vollständige Berechtigungen auf der gesamten Konfigurationsverzeichnispartition. Der Grund hierfür ist, dass die Einstellung für vollständige Berechtigungen vom Stammcontainer Konfiguration übernommen und auf alle untergeordneten Container vererbt wird. Der Assistent für die Zuweisung von Verwaltungsberechtigungen zeigt diese Administratoren jedoch nicht als Exchange-Administratoren – Vollständig an, da sie im Attribut msExchAdmins nicht aufgeführt sind. Die Vererbung von Berechtigungen wird in diesem Thema unter „Vererbung von Berechtigungen und Exchange-System-Manager“ erläutert.
Wenn Sie einer Sicherheitsgruppe die Funktion Exchange-Administrator – Vollständig auf Ebene der Organisation zuweisen, können Sie Mitglieder dieser Gruppe zu einem späteren Zeitpunkt nicht mehr mit dem Assistenten für die Zuweisung von Verwaltungsberechtigungen auf die Funktion Exchange-Administrator – Nur Ansicht für eine bestimmte administrative Gruppe herabstufen. Der Grund hierfür ist, dass der Assistent für die Zuweisung von Verwaltungsberechtigungen keine Berechtigungen verweigern kann, die durch von übergeordneten Containern ererbte Sicherheitseinstellungen gewährt wurden. Falls Sie mit dem Assistenten für die Zuweisung von Verwaltungsberechtigungen einzelnen Mitgliedern die Funktion Exchange-Administrator – Nur Ansicht für eine administrative Gruppe zuweisen, zeigt der Assistent diese Konten als Exchange-Administrator – Nur Ansicht an. Allerdings gilt für die Konten weiterhin die Funktion Exchange-Administrator – Vollständig, die über die Gruppenmitgliedschaft von der Organisationsebene geerbt wurde Zur Überprüfung der tatsächlichen Sicherheitseinstellungen müssen Sie im Exchange-System-Manager die Registerkarte Sicherheit für die Organisation und für Objekte der administrativen Gruppe aktivieren. Legen Sie dazu den Registrierungsparameter ShowSecurityPage entsprechend der Beschreibung in der folgenden Tabelle fest.
Registrierungsparameter „ShowSecurityPage“
HKEY_CURRENT_USER\Software\Microsoft\Exchange\ExAdmin
Wertname ShowSecurityPage
Datentyp REG_DWORD
Wert 1
156
HKEY_CURRENT_USER\Software\Microsoft\Exchange\ExAdmin
Beschreibung Diese Einstellung betrifft nur den derzeit angemeldeten Benutzer. Wenn der Wert ShowSecurityPage nicht vorhanden oder auf 0 gesetzt ist, wird die Registerkarte Sicherheit nur für folgende Objekte angezeigt:
Adresslisten
Globale Adresslisten
Postfachspeicher
Informationsspeicher für Öffentliche Ordner
Öffentliche Ordner-Hierarchien auf oberster Ebene
Wenn der Wert ShowSecurityPage auf 1 gesetzt ist, wird die Registerkarte Sicherheit für alle Objekte im Exchange-System-Manager angezeigt. Änderungen werden sofort wirksam. Der Exchange-System-Manager muss nicht neu gestartet werden.
Vorsicht: Die falsche Verwendung des Registrierungs-Editors kann zu ernsthaften Problemen führen, die möglicherweise eine Neuinstallation des Betriebssystems erforderlich machen. Dadurch entstandene Probleme können unter Umständen nicht mehr behoben werden. Sichern Sie vor dem Ändern der Registrierung alle wichtigen Daten.
Vererbung von Berechtigungen und Exchange-System-ManagerWenn Sie im Exchange-System-Manager auf der Registerkarte Sicherheit die Sicherheitseinstellungen für eine Exchange-Organisation überprüfen, stellen Sie fest, dass die Sicherheitseinstellungen mehreren Systemkonten und Gruppen zugewiesen sind und nicht nur den Konten, denen Sie speziell eine Exchange-Administratorfunktion zugeordnet haben. In der folgenden Tabelle sind diese Standardkonten und deren Berechtigungen aufgeführt.
157
Standardkonten mit Berechtigungen in einer Exchange-Organisation
Konto Zugelassen Verweigert
ANONYMOUS-ANMELDUNG
Benannte Eigenschaften im Informationsspeicher erstellen
Öffentlichen Ordner erstellen
Ausführen
Inhalt auflisten
Objekt auflisten
Lesen
Berechtigungen lesen
Eigenschaften lesen
Keine
Authentifizierte Benutzer Eigenschaften lesen
Objekt auflisten
Keine
Domänen-Admins (Stammdomäne)
Lesen
Schreiben
Ausführen
Löschen
Berechtigungen lesen
Berechtigungen ändern
In Besitz nehmen
Untergeordnete Objekte erstellen
Inhalt auflisten
Selbst hinzufügen/entfernen
Eigenschaften lesen
Eigenschaften schreiben
Objekt auflisten
Öffentlichen Ordner erstellen
Empfangen als
Senden als
158
Konto Zugelassen Verweigert
Öffentliche Ordner der obersten Ebene erstellen
Verwaltungs-ACL für Öffentlichen Ordner ändern
Replikatlisten für Öffentliche Ordner ändern
Warteschlange für E-Mail-Versand öffnen
Metabase-Eigenschaften lesen
Informationsspeicher verwalten
Benannte Eigenschaften im Informationsspeicher erstellen
Status des Informationsspeichers anzeigen
Empfangen als
Senden als
Organisations-Admins Vollzugriff Empfangen als
Senden als
159
Konto Zugelassen Verweigert
Jeder Benannte Eigenschaften im Informationsspeicher erstellen
Öffentlichen Ordner erstellen
Ausführen
Inhalt auflisten
Objekt auflisten
Lesen
Berechtigungen lesen
Eigenschaften lesen
Keine
Exchange Domain Servers Vollzugriff Keine
Die meisten Berechtigungseinstellungen werden durch das Exchange-Organisationsobjekt ererbt, d. h. von übergeordneten Containern in der Hierarchie der Konfigurationsverzeichnispartition übernommen. Beispielsweise erhalten Organisationsadministratoren die Berechtigungen für Vollzugriff im Stammcontainer der Konfigurationsverzeichnispartition. Da Berechtigungen standardmäßig an alle untergeordneten Objekte in der Konfigurationsverzeichnispartition vererbt werden (einschließlich des Exchange-Organisationscontainers), verfügen Organisationsadministratoren auch über die Berechtigung Exchange-Administrator – Vollständig.
Sie können mit dem Exchange-System-Manager keine Sicherheitseinstellungen für übergeordnete Container in der Konfigurationsverzeichnispartition überprüfen. Die tatsächlichen Einstellungen lassen sich jedoch mit dem Tool ADSI-Bearbeitung anzeigen. In Abbildung 4.4 sind die Sicherheitseinstellungen für die Gruppe der Organisationsadministratoren dargestellt, die auf den Konfigurationscontainer angewendet werden. In der folgenden Abbildung wird zudem verdeutlicht, dass diese Einstellungen für den Konfigurationscontainer und alle untergeordneten Objekte, einschließlich der Exchange-Organisation, übernommen werden.
160
Sicherheitseinstellungen für Organisationsadministratoren in ADSI-Bearbeitung
Die Vererbung von Berechtigungen ist eine Funktion, mit der die Zuweisung von Berechtigungen in der Konfigurationsverzeichnispartition von Active Directory erleichtert wird. Beispielsweise verwendet der Assistent für die Zuweisung von Verwaltungsberechtigungen im Exchange-System-Manager die Funktionalität der Vererbung von Berechtigungen, um Konten und Gruppen auf Organisationsebene und auf Ebene der administrativen Gruppe bestimmte Exchange-Administratorfunktionen zuzuweisen. Wenn der Assistent für die Zuweisung von Verwaltungsberechtigungen einem Administratorkonto auf der Organisationsebene die Funktion Exchange-Administrator – Vollständig zuweist, wird dem Konto am übergeordneten Container Microsoft Exchange (Abbildung 4.4) die Berechtigung Vollzugriff gewährt. Daher wird die Vollzugriffsberechtigung auch auf den untergeordneten Container Active Directory-Verbindungen und auf die Exchange-Organisation angewendet. Konten, denen administrative Berechtigungen auf Ebene der administrativen Gruppe zugewiesen wurden, werden jedoch auf Organisationsebene ebenfalls Leseberechtigungen gewährt, sodass diese Administratoren die Konfigurationsinformationen im Exchange-System-Manager anzeigen können. Weitere Informationen zum Assistenten für die Zuweisung von Verwaltungsberechtigungen und zu Berechtigungszuweisungen in einer Exchange-Organisation finden Sie unter Exchange Server 2003 Security Hardening Guide .
161
Verwalten von Exchange-InformationsspeicherressourcenActive Directory ist nicht der einzige Kommunikationspartner des Exchange-System-Managers. Verschiedene Exchange-System-Manager-Snap-Ins kommunizieren auch mit dem Exchange-Informationsspeicher. Mithilfe dieser Snap-Ins können Sie Echtzeitinformationen über Exchange-Informationsspeicherressourcen anzeigen und Öffentliche Ordner verwalten. Der Exchange-System-Manager verwendet MAPI zum Anzeigen von Postfachstatistiken und Clientanmeldungen. Außerdem wird zum Anzeigen und Verwalten von Ressourcen für Öffentliche Ordner das DAV-Protokoll (Distributed Authoring and Versioning) verwendet.
MAPI-basierte KommunikationIn der folgenden Abbildung ist der Unterschied zwischen Objekten eines Postfachspeichers und des Informationsspeichers für Öffentliche Ordner in Active Directory und im Exchange-System-Manager dargestellt. In Active Directory-Standorte und -Dienste werden Objekte des Postfachspeichers und des Informationsspeichers für Öffentliche Ordner durch Endknoten dargestellt, die keine untergeordneten Objekte enthalten. Im Exchange-System-Manager werden die Objekte des Postfachspeichers und des Informationsspeichers für Öffentliche Ordner jedoch als Knoten in der Konsolenstruktur dargestellt. Diese Knoten enthalten mehrere untergeordnete Container, z. B. Anmeldungen, Postfächer oder Öffentliche Ordner, Öffentliche Ordner-Instanzen, Replikationsstatus und Volltextindizierung.
162
Objekte von Postfachspeichern und Informationsspeichern für Öffentliche Ordner in Active Directory-Standorte und -Dienste und im Exchange-System-Manager
Über die IExchangeManageStore-Schnittstelle abgerufene InformationenDie untergeordneten Container unter den Objekten des Postfachspeichers und des Informationsspeichers für Öffentliche Ordner sind virtuelle Container, die in Active Directory oder in anderen Diensten nicht vorhanden sind. Zum Anzeigen dieser Container muss der Exchange-System-Manager mit dem Exchange-Informationsspeicher über die IExchangeManageStore-Schnittstelle, eine interne MAPI-basierte Schnittstelle, kommunizieren. Diese MAPI-Kommunikation ist grundsätzlich dynamischer Natur und erfolgt, sobald Sie einen bestimmten Postfachspeicher oder Informationsspeicher für Öffentliche Ordner im Exchange-System-Manager erweitern. Sie können die untergeordneten Container eines Postfachspeichers oder Informationsspeichers für Öffentliche Ordner nicht anzeigen, wenn die Bereitstellung des Postfachspeichers oder des Öffentlichen Ordners aufgehoben wurde. Die Kommunikation per MAPI tritt ebenfalls auf, wenn Sie Postfachspeicher oder Informationsspeicher für Öffentliche Ordner zu einem Exchange-Server hinzufügen, die Eigenschaften eines einzelnen Postfachspeichers oder Informationsspeichers für Öffentliche Ordner anzeigen und wenn Sie Postfachspeicher oder Informationsspeicher für Öffentliche Ordner bereitstellen oder deren Bereitstellung aufheben.
163
Hinweis: Für die MAPI-basierte Kommunikation ist es erforderlich, dass Sie ein Exchange-System-Manager-Konto verwenden, das Mitglied der lokalen Administratorgruppe ist. Damit erhalten Sie Schreibberechtigungen für das Verzeichnis \System32 auf dem lokalen Computer. Durch den Schreibzugriff auf dieses Verzeichnis kann der Exchange-System-Manager ein dynamisches MAPI-Profil erstellen. Ohne ein MAPI-Profil kann keine Kommunikation über MAPI mit einem Exchange-Server erfolgen.
Der Exchange-System-Manager ruft die folgenden IExchangeManageStore-Methoden auf, um dynamische Informationen über Postfachspeicher und Informationsspeicher für Öffentliche Ordner zu erhalten:
GetMailboxTable Die Methode GetMailboxTable ruft Informationen zu allen Postfächer in einem Postfachspeicher ab. Durch diese Methode wird ein Zeiger auf eine MAPI-IMAPITable-Schnittstelle zurückgegeben, die Informationen über alle Postfächer im angegebenen Exchange-Informationsspeicher enthält. Jede Zeile in dieser MAPI-Tabelle steht für ein einzelnes Postfach. Die Spalten in der Tabelle enthalten ausführliche Informationen über das Postfach, z. B. den Namen, die Anzahl und Größe der Nachrichten, den Windows-Benutzerkontonamen des letzten beim Postfach angemeldeten Benutzers sowie Datum und Uhrzeit der letzten Anmeldung des Benutzers. Außerdem wird in den Spalten angegeben, ob für ein Postfach zum gegenwärtigen Zeitpunkt die zulässigen Speichergrenzwerte eingehalten werden.
GetPublicFolderTable Die Methode GetPublicFolderTable ruft Informationen zu allen Öffentlichen Ordnern in einem Informationsspeicher für Öffentliche Ordner ab. Durch diese Methode wird ein Zeiger auf eine MAPI-IMAPITable-Schnittstelle zurückgegeben, die Informationen über alle Öffentlichen Ordner im angegebenen Exchange-Informationsspeicher enthält. Jede Zeile in dieser MAPI-Tabelle steht für einen einzelnen Öffentlichen Ordner. Die Spalten in der Tabelle enthalten ausführliche Informationen über den Öffentlichen Ordner, z. B. den Namen, die Anzahl der zugeordneten Nachrichten, die Größe (in Bytes) aller zugeordneten Nachrichten, die Anzahl der zugeordneten Nachrichten mit Anlagen, die Anzahl der zwischengespeicherten Spalten und Kategorisierungen für den Öffentlichen Ordner, die Anzahl der Kontakte für Öffentliche Ordner, Datum und Uhrzeit des Zugriffs auf das Replikat eines Öffentlichen Ordners sowie Datum und Uhrzeit der letzten Änderungen eines Objekts im Öffentlichen Ordner.
Tipp: Sie können alle Informationen anzeigen, die für einen Postfachspeicher oder einen Informationsspeicher für Öffentliche Ordner verfügbar sind. Ausführliche Anweisungen finden Sie unter Anzeigen aller für einen Postfachspeicher oder einen Informationsspeicher für Öffentliche Ordner verfügbaren Informationen.
164
Exchange-System-Manager und MAPI-basierte ClientsDa der Exchange-System-Manager über MAPI dynamische Informationen aus dem Exchange-Informationsspeicher abruft, dürfen keine MAPI-basierten Clients (z. B. Microsoft Outlook) auf Exchange-Servern oder Arbeitsstationen installiert werden, auf denen der Exchange-System-Manager ausgeführt wird. Der Exchange-System-Manager verwendet die Datei Mapi32.dll, um mit dem Exchange-Informationsspeicher zu kommunizieren. Die Datei Mapi32.dll ist eine Hauptkomponente des MAPI-Subsystems und befindet sich im Ordner Winnt\System32. Wenn Sie Microsoft Office Outlook 2000 oder höher auf einem Computer installieren, auf dem der Exchange-System-Manager installiert ist, wird das MAPI-Subsystem in den Ordner Programme\Gemeinsame Dateien\System\Mapi\1033\NT verschoben. Normalerweise installiert Outlook eine Basisversion von MAPI im Ordner Winnt\System32, durch die MAPI-Aufrufe dann an die Outlook-Implementierung weitergeleitet werden. Wenn Sie die Exchange Server 2003-Version von Mapi32.dll durch die Outlook-Implementierung ersetzen, können unter Umständen Versionskonflikte im MAPI-Subsystem und Fehler im Exchange-System-Manager auftreten.
Hinweis: Wenn Sie Outlook und Exchange Server 2003 auf demselben Computer installieren, da beispielsweise für eine Lösung eines anderen Anbieters (z. B. ein MAPI-basiertes Sicherungsprogramm) Outlook-Komponenten erforderlich sind, lesen Sie zunächst den Microsoft Knowledge Base-Artikel 266418: „Microsoft does not support installing Exchange Server components and Outlook on the same computer“.
DAV-basierte KommunikationZum Erstellen, Verwalten und Löschen von Öffentliche Ordner-Ressourcen kommuniziert der Exchange-System-Manager (insbesondere das Snap-In Öffentliche Ordner) über DAV mit dem Exchange-Informationsspeicher. DAV ist ein HTTP-basiertes Protokoll. Daher wird der Zugriff auf den Exchange-Informationsspeicher durch den WWW-Publishingdienst (w3svc) bereitgestellt. DAV-Befehle wie PROPFIND, SEARCH, DELETE, MOVE, COPY und OPTIONS sind XML-codiert.
Hinweis: Der Exchange-System-Manager verwendet DAV für die Verwaltung Öffentlicher Ordner, da DAV das einzige remote verwendbare Protokoll in Exchange Server 2003 ist, das mit MAPI-basierten und allgemeinen Öffentliche Ordner-Hierarchien funktioniert.
165
DAV-basierte Kommunikation und virtuelle HTTP-VerzeichnisseStandardmäßig erstellt Exchange Server 2003 auf einem Exchange-Server die folgenden virtuellen HTTP-Verzeichnisse:
Exchweb In diesem Verzeichnis werden Grafiken und zusätzliche Dateien gespeichert, die für Microsoft Office Outlook Web Access für Exchange Server 2003 benötigt werden. Exchweb ist ein virtuelles Standardverzeichnis, das auf das Verzeichnis \Programme\Exchsrvr\Exchweb auf der Festplatte des Servers verweist.
Exchange Wird von Outlook Web Access für den Postfachzugriff verwendet. Dieses virtuelle Verzeichnis ist an den URL \\.\BackOfficeStorage\<vollqualifizierter Domänenname des Servers>\mbx gebunden.
Öffentlich Wird von Outlook Web Access für den Zugriff auf Öffentliche Ordner verwendet. Dieses virtuelle Verzeichnis ist an den URL \\.\BackOfficeStorage\<vollqualifizierter Domänenname des Servers>\public folders gebunden.
Exadmin Wird von dem Exchange-System-Manager zum Verwalten der Öffentlichen Ordner verwendet. Dieses virtuelle Verzeichnis ist an den URL \\.\BackOfficeStorage gebunden.
Das virtuelle Verzeichnis Exadmin ist das wichtigste virtuelle HTTP-Verzeichnis für den Exchange-System-Manager. Exadmin bietet Zugriff auf alle Öffentliche Ordner-Hierarchien (auch als Öffentliche Ordner-Strukturen bezeichnet) auf einem Exchange-Server. Dieser Zugriff ist möglich, da das Verzeichnis Exadmin direkt auf den Namespace BackOfficeStorage verweist. Um den Zugriff auf alle Postfachspeicher und Informationsspeicher für Öffentliche Ordner auf einem Exchange-Server zu ermöglichen, registriert der ExOLEDB-Anbieter (Exchange-OLE-DB) den BackOfficeStorage-Namespace beim OLE-DB-RootBinder. Wenn Sie die Öffentliche Ordner-Hierarchie erweitern oder Öffentliche Ordner im Exchange-System-Manager erstellen, verwalten oder löschen, erfolgt die Kommunikation über das virtuelle Verzeichnis Exadmin.
Der Exchange-System-Manager verwendet auch andere virtuelle HTTP-Verzeichnisse. Beispielsweise wird das virtuelle Verzeichnis Öffentlich vom Exchange-System-Manager verwendet, um den Inhalt MAPI-basierter Öffentlicher Ordner anzuzeigen. Das virtuelle Verzeichnis Öffentlich ist auf allen Exchange-Servern vorhanden. Wenn Sie jedoch eine weitere allgemeine Öffentliche Ordner-Struktur erstellen und diese mit einem zusätzlichen Öffentlichen Informationsspeicher verknüpfen, kann der Exchange-System-Manager die Inhalte Öffentlicher Ordner erst anzeigen, nachdem Sie ein virtuelles Verzeichnis erstellt haben, mit dem ein HTTP-basierter Zugriff auf diese Hierarchie ermöglicht wird. Weitere Informationen zum Erstellen und Konfigurieren von Öffentliche Ordner-Hierarchien und -Informationsspeichern finden Sie im Exchange Server 2003 Administration Guide .
In der folgenden Abbildung ist dargestellt, wie der Inhalt eines Öffentlichen Ordners im Exchange-System-Manager angezeigt wird.
166
Inhalt eines MAPI-basierten Öffentlichen Ordners im Exchange-System-Manager
Exchange-System-Manager und das virtuelle Verzeichnis „Exadmin“Der größte Teil der Interaktion zwischen dem Snap-In für Öffentliche Ordner im Exchange-System-Manager und dem Exchange-Informationsspeicher erfolgt über das virtuelle Verzeichnis Exadmin. Exadmin ist vom ExOLEDB-Anbieter abhängig, der eine nicht remotefähige Komponente ist. Der Exchange-System-Manager muss auf das virtuelle Verzeichnis Exadmin auf dem Exchange-Server zugreifen, auf dem sich der Öffentliche Informationsspeicher für die Öffentliche Ordner-Hierarchie befindet. Dieser Server wird durch Informationen bestimmt, die von dem Verzeichnisobjekt abgerufen wurden, das der Öffentliche Ordner-Hierarchie entspricht. In der folgenden Abbildung ist dargestellt, wie der Exchange-System-Manager über das virtuelle Verzeichnis Exadmin mit einem Exchange-Informationsspeicher kommuniziert.
167
Kommunikation mit einem Öffentlichen Informationsspeicher über das virtuelle Verzeichnis „Exadmin“
Der Exchange-System-Manager führt beim Verbinden mit dem virtuellen Verzeichnis Exadmin folgende Schritte durch:
1. Abrufen einer Liste der Exchange-Informationsspeicher vom Hierarchieobjekt Der Exchange-System-Manager liest das Attribut msExchOwningPFTreeBL des Öffentliche Ordner-Hierarchieobjekts in Active Directory. Durch dieses Attribut wird die Liste der Exchange-Server bestimmt, die mit der Öffentliche Ordner-Hierarchie verknüpfte Öffentliche Informationsspeicher enthalten.
Tipp: Sie können die Liste der im Attribut msExchOwningPFTreeBL aufgeführten Exchange-Informationsspeicher mit den Eigenschaften der Öffentliche Ordner-Hierarchie im Exchange-System-Manager anzeigen. Die Informationsspeicher sind auf der Registerkarte Allgemein unter Der Ordnerstruktur zugeordnete Öffentliche Informationsspeicher aufgeführt.
2. Auswählen der Zielserver und Abrufen der Exadmin-Bindungsinformationen Der Exchange-System-Manager wählt einen Server aus, der ein Replikat der Öffentliche Ordner-Hierarchie enthält. Anschließend liest der Exchange-System-Manager die Konfigurationsinformationen des virtuellen Verzeichnisses Exadmin auf diesem Server. Das virtuelle Verzeichnis Exadmin wird in Active Directory durch ein Verzeichnisobjekt mit der Bezeichnung Exadmin dargestellt, das unter dem standardmäßigen virtuellen HTTP-Server (Virtueller Exchange-Server) dieses Servers aufgeführt ist. Das Attribut msExchServerBindings dieses Verzeichnisobjekts enthält die TCP-Anschlussnummer, die der Exchange-System-Manager verwenden muss, um eine Verbindung mit dem virtuellen Verzeichnis Exadmin auf dem Exchange-Server herzustellen, der als Host für
168
die Öffentliche Ordner-Hierarchie fungiert. Falls dieses Attribut nicht festgelegt ist, verwendet der Exchange-System-Manager den standardmäßigen TCP-Anschluss 80.
Hinweis: Wenn Sie den Exchange-System-Manager lokal auf einem Exchange-Server ausführen, der einen mit der Öffentliche Ordner-Hierarchie verknüpften Öffentlichen Informationsspeicher enthält, versucht der Exchange-System-Manager, zuerst eine Verbindung mit dem lokalen Server herzustellen.
3. Verwenden von Bindungsinformationen zum Verbinden mit dem virtuellen Verzeichnis „Exadmin“ Der Exchange-System-Manager verwendet die vom Attribut msExchServerBindings abgerufene TCP-Anschlussnummer, um eine Verbindung mit dem virtuellen Verzeichnis Exadmin auf dem ausgewählten Exchange-Server herzustellen. Anschließend wird vom Exchange-System-Manager eine Liste mit allen Öffentlichen Ordnern der obersten Ebene in der Hierarchie angefordert. Im User-Agent-HTTP-Header der HTTP-Anforderung identifiziert sich der Exchange-System-Manager als Exchange-Admin-Client. Internetinformationsdienste (IIS) authentifiziert den Client und gibt die Liste der Öffentlichen Ordner der obersten Ebene an den Exchange-System-Manager zurück.
4. Anzeigen der Öffentlichen Ordner der obersten Ebene Der Exchange-System-Manager zeigt die Öffentlichen Ordner der obersten Ebene als Containerobjekte in der Konsolenstruktur unter der Öffentliche Ordner-Hierarchie an. Dieser Schritt ist in der obigen Abbildung nicht dargestellt.
Hinweis: Standardmäßig werden nur die Ordner der obersten Ebene der IPM-Unterstruktur (Interpersonal Message) angezeigt. Sie können jedoch auch Ordner in der Nicht-IPM-Unterstruktur anzeigen, indem Sie mit der rechten Maustaste auf das Hierarchieobjekt klicken und dann die Option Systemordner anzeigen auswählen.
Verbinden mit einem bestimmten Exchange-ServerSie können eine Öffentliche Ordner-Hierarchie mit Informationsspeichern für Öffentliche Ordner von mehreren Exchange-Servern verknüpfen. Hierbei wird die Hierarchie zwischen diesen Öffentlichen Informationsspeichern automatisch repliziert. Durch diese Replikation wird sichergestellt, dass alle Informationsspeicher für Öffentliche Ordner aktuelle Informationen über sämtliche Öffentliche Ordner in der Hierarchie enthalten. Daher können Sie zum Verwalten von Öffentliche Ordner-Ressourcen eine Verbindung mit jedem dieser Exchange-Server herstellen. Durch einen Wechsel von einem zu einem anderen Server können Sie überprüfen, ob alle Öffentliche Informationsspeicher über eine einheitliche Ansicht der Hierarchie verfügen. Sie können diese Vorgehensweise beispielsweise
169
anwenden, um Probleme im Zusammenhang mit einer Replikation der Hierarchie zu diagnostizieren. Ausführliche Anweisungen zum Verbinden mit einem bestimmten Exchange-Server finden Sie unter Verbinden mit einem bestimmten Exchange-Server im Exchange-System-Manager.
Hinweis: Der Exchange-System-Manager stellt immer direkt eine Verbindung mit dem Exchange-Server her, der den mit der ausgewählten Öffentliche Ordner-Hierarchie verknüpften Öffentlichen Informationsspeicher enthält. Sie können keine Verbindung mit einem Öffentlichen Informationsspeicher über einen Front-End-Server herstellen.
Exchange-System-Manager und die StandardwebsiteUnabhängig davon, ob Sie einen Informationsspeicher für Öffentliche Ordner zur Verbindung angeben oder dem Exchange-System-Manager diese Auswahl überlassen, wird stets derselbe Verbindungsmechanismus angewendet, wie bereits vorher in diesem Abschnitt erläutert wurde. Das virtuelle Verzeichnis Exadmin muss sich dabei jedoch auf dem Exchange-Server auf der Standardwebsite von IIS befinden. Stellen Sie in IIS-Manager sicher, dass IP-Adresse auf (Keine zugewiesen) und TCP-Anschluss auf 80 festgelegt und kein Hostheaderwert angegeben ist. Der Grund hierfür ist, dass der Exchange-System-Manager standardmäßig eine Verbindung mit TCP-Anschluss 80 herstellt und den Namen des Exchange-Servers im Hostheaderwert der HTTP-Anforderungen angibt. Wenn Sie in IIS-Manager einen Hostheaderwert für die Standardwebsite angeben, der nicht mit dem Servernamen identisch ist, kann der Exchange-System-Manager nicht auf das Verzeichnis Exadmin zugreifen. Daher wird eine Fehlermeldung ausgegeben, die darauf hinweist, dass der Vorgang aufgrund eines ungültigen Formats in der HTTP-Anforderung nicht ausgeführt werden konnte. In diesem Fall können keine Ressourcen von Öffentlichen Ordnern verwaltet werden, obwohl Sie unter Umständen in Outlook Web Access auf Öffentliche Ordner zugreifen können. Weitere Informationen zu Problemen beim Zugriff auf das virtuelle Verzeichnis Exadmin finden Sie im Microsoft Knowledge Base-Artikel 325920 „Error Message When You View Public Folders in Exchange System Manager“.
Hinweis: Der Hostheaderwert, der vom Exchange-System-Manager zum Verbinden mit dem virtuellen Verzeichnis Exadmin verwendet wird, kann von Ihnen nicht geändert werden. Der Exchange-System-Manager verwendet stets den NetBIOS-Namen des Exchange-Zielservers. Aus diesem Grund muss durch die Website entweder der NetBIOS-Name des Servers im Parameter Hostheaderwert definiert werden, oder es darf kein Wert festgelegt sein.
Sie können jedoch der Standardwebsite, die als Host für das virtuelle Verzeichnis Exadmin fungiert, mit IIS-Manager eine dedizierte IP-Adresse und einen benutzerdefinierten TCP-
170
Anschluss zuweisen. Geben Sie beim Anzeigen der Eigenschaften der Website auf der Registerkarte Website eine IP-Adresse oder einen benutzerdefinierten TCP-Anschluss an. Der Exchange-System-Manager versucht, zuerst eine Verbindung mit dem TCP-Anschluss 80 herzustellen. Falls dieser Verbindungsversuch nicht erfolgreich ist, kommuniziert der Exchange-System-Manager mit dem IIS-Verwaltungsdienst auf dem Exchange-Server über Remoteprozeduraufrufe (RPCs), um die erforderliche Anschlussnummer zu ermitteln. Der IIS-Verwaltungsdienst gibt die benutzerdefinierte Anschlussnummer an den Exchange-System-Manager zurück, da diese in der IIS-Metabase registriert ist. Der Exchange-System-Manager registriert dann diese benutzerdefinierte Anschlussnummer im Attribut msExchServerBindings des Verzeichnisobjekts Exadmin. Anschließend stellt der Exchange-System-Manager eine Verbindung mit dem virtuellen Verzeichnis Exadmin her, wie bereits zuvor in diesem Abschnitt erläutert.
Die Kommunikation mit dem IIS-Verwaltungsdienst ist nicht möglich, wenn RPCs auf dem Exchange-Server und dem Computer, auf dem der Exchange-System-Manager ausgeführt wird, nicht unterstützt werden. Beispielsweise wird diese Kommunikation möglicherweise durch eine Firewall verhindert, die den Zugriff auf die RPC-Endpunktzuordnung über den TCP-Anschluss sperrt. In diesem Fall kann der Exchange-System-Manager den benutzerdefinierten Anschluss nicht dynamisch ermitteln. Daher wird empfohlen, für das virtuelle Verzeichnis Exadmin die Standardanschlussnummer 80 zu verwenden.
Hinweis: Die Verwendung des Exchange-System-Managers über Netzwerkverbindungen ohne RPC-Unterstützung wird nicht unterstützt.
Virtuelles Verzeichnis „Exadmin“ und SSL-VerschlüsselungDie Exchange Server 2003-Version des Exchange-System-Managers bietet vollständige Unterstützung für SSL (Secure Sockets Layer). Daher können Sie ein SSL-Zertifikat auf dem Exchange-Server installieren und die SSL-Verschlüsselung über HTTP erzwingen, um virtuelle Verzeichnisse von Exchange Server 2003 (z. B. Öffentlich und Exadmin) zu schützen. Das Erzwingen eines sicheren Kommunikationskanals ist empfehlenswert, wenn der Exchange-Server und der Computer, auf dem der Exchange-System-Manager ausgeführt wird, über ein öffentliches oder nicht vertrauenswürdiges Netzwerksegment miteinander kommunizieren müssen.
In der folgenden Abbildung ist dargestellt, wie die Verbindungsherstellung mit einem virtuellen Verzeichnis Exadmin über HTTP mit SSL (HTTPS) funktioniert.
171
Verbindungsherstellung mit „Exadmin“ über HTTPS
Bei der erstmaligen Verbindungsherstellung über HTTPS führt der Exchange-System-Manager die folgenden Schritte durch:
1. Der Exchange-System-Manager versucht, eine Verbindung über HTTP herzustellen, wie in zuvor in diesem Abschnitt erläutert.
2. Da für das Verzeichnis Exadmin HTTPS erforderlich ist, reagiert der Webserver auf die HTTP-Anforderung durch Senden des HTTP-Statuscodes „403 – Verboten“.
3. Der Exchange-System-Manager fordert vom IIS-Verwaltungsdienst mittels RPCs SSL-spezifische Informationen an, beispielsweise den SSL-Anschluss, der zur Verbindung mit der Website verwendet werden muss, die als Host für das virtuelle Verzeichnis Exadmin fungiert. Durch den IIS-Verwaltungsdienst werden diese Informationen an den Exchange-System-Manager zurückgegeben.
4. Der Exchange-System-Manager stellt über HTTPS eine Verbindung mit dem virtuellen Verzeichnis Exadmin her und zeigt die Liste der Öffentlichen Ordner in der Hierarchie an.
Hinweis: In dem Sicherheitszertifikat, das Sie für die Website registrieren, die Host für das virtuelle Verzeichnis Exadmin ist, muss der vollqualifizierte Domänenname (FQDN) des lokalen Exchange-Servers als gemeinsamer Name (CN) der
172
Website aufgeführt sein. Außerdem muss der Computer, auf dem der Exchange-System-Manager ausgeführt wird, der Zertifizierungsstelle vertrauen, von der das SSL-Zertifikat ausgestellt wurde. Andernfalls weist der Exchange-System-Manager in einer Fehlermeldung darauf hin, dass das SSL-Zertifikat falsch ist. Die Öffentliche Ordner-Hierarchie wird in diesem Fall nicht angezeigt.
5. Der Exchange-System-Manager trägt die SSL-Anschlussnummer in das Attribut msExchSecureBindings des Verzeichnisobjekts ein, das dem virtuellen Verzeichnis Exadmin entspricht. Bei späteren Verbindungen muss dann der Algorithmus zum Abrufen der SSL-Anschlussnummer vom Server nicht erneut ausgeführt werden.
Anzeigen aller für einen Postfachspeicher oder einen Informationsspeicher für Öffentliche Ordner verfügbaren InformationenIn diesem Thema wird das Anzeigen aller für einen Postfachspeicher oder einen Informationsspeicher für Öffentliche Ordner verfügbaren Informationen im Detailausschnitt des Exchange-System-Managers erläutert.
VerfahrenAnzeigen aller für einen Postfachspeicher oder einen Informationsspeicher für
Öffentliche Ordner verfügbaren Informationen
1. Klicken Sie dazu mit der rechten Maustaste auf den gewünschten untergeordneten Container (z. B. Postfächer oder Anmeldungen).
2. Zeigen Sie auf Ansicht.
3. Wählen Sie Spalten hinzufügen/entfernen aus.
4. Fügen Sie im Dialogfeld Spalten hinzufügen/entfernen der Liste Angezeigte Spalten alle Einträge aus der Liste Verfügbare Spalten hinzu.
5. Klicken Sie auf OK.
173
Verbinden mit einem bestimmten Exchange-Server im Exchange-System-ManagerIn diesem Thema wird das Verbinden mit einem bestimmten Exchange-Server im Exchange-System-Manager erläutert. Sie können diese Vorgehensweise anwenden, um Probleme im Zusammenhang mit einer Replikation der Hierarchie zu diagnostizieren. Durch einen Wechsel von einem zu einem anderen Server können Sie überprüfen, ob alle Öffentliche Informationsspeicher über eine einheitliche Ansicht der Hierarchie verfügen.
VerfahrenVerbinden mit einem bestimmten Exchange-Server im Exchange-System-Manager
1. Klicken Sie auf das Öffentliche Ordner-Hierarchieobjekt (z. B. Öffentliche Ordner) im Exchange-System-Manager.
2. Wählen Sie Verbinden mit aus.
3. Wählen Sie den gewünschten, als Ziel fungierenden Informationsspeicher für Öffentliche Ordner im Dialogfeld Wählen Sie einen Öffentlichen Informationsspeicher aus aus.
Integration in die Windows-VerwaltungsinstrumentationDer Exchange-System-Manager ist auch eine WMI-Verwaltungsanwendung (Windows-Verwaltungsinstrumentation – Windows Management Instrumentation – WMI). WMI kommuniziert mit dem Dienst Windows-Verwaltungsinstrumentation (Winmgmt), um auf dynamische Exchange-Systeminformationen zuzugreifen. WMI ist ein Subsystem von Microsoft Windows Server 2003, das ein sprachenunabhängiges Programmierungsmodell zur Abfrage und Steuerung von Verwaltungsinformationen in einer Unternehmensumgebung bereitstellt. Alle WMI-Schnittstellen sind COM-basiert (Component Object Model). Daher beruht auch die Kommunikation zwischen dem Exchange-System-Manager und Winmgmt auf RPCs.
WMI beruht auf einem dreistufigen Modell, das aus Verwaltungsanwendungen, dem CIM-Objekt-Manager (Common Information Model) und WMI-Anbietern besteht.
174
In der folgenden Abbildung ist die allgemeine Architektur von WMI dargestellt.
Dreistufige WMI-Architektur
Verwaltungsanwendungen, die WMI-Daten verarbeiten, befinden sich auf der obersten Stufe der WMI-Architektur. Der Exchange-System-Manager ist ein Beispiel für eine WMI-Verwaltungsanwendung. Sie können auch benutzerdefinierte Anwendungen und Skripts zur Verarbeitung von WMI-Daten erstellen. WMI wird als gemeinsame API von den Verwaltungsanwendungen verwendet, um mit dem CIM-Objekt-Manager auf der mittleren Stufe zu kommunizieren. Der CIM-Objekt-Manager stellt die programmierbaren Objektklassen bereit, die die zugrunde liegenden Informationsquellen darstellen.
Der CIM-Objekt-Manager ist im WMI-Dienst in Windows Server 2003 implementiert. Der WMI-Dienst verwaltet eine eigene Datenbank, die CIM-Datenbank, mit der protokolliert werden kann, welche WMI-Klassen verfügbar sind und welcher Anbieter für die Bereitstellung von Instanzen dieser Klassen verantwortlich ist. Die Klassendefinitionen sind in der CIM-Datenbank gespeichert. Statische Daten können ebenfalls in der CIM-Datenbank gespeichert und ohne einen Anbieter abgerufen werden. Das WMI-Subsystem dient jedoch dazu, dynamische Informationen über ein verwaltetes System, z. B. Exchange Server 2003, abzurufen. Dies erfolgt vollständig über WMI-Anbieter.
WMI-Anbieter sind die Grundlage der WMI-Architektur. WMI-Anbieter greifen über verschiedene standardisierte COM-Schnittstellen auf den CIM-Objekt-Manager zu und fungieren als Vermittler zwischen dem verwalteten System und dem CIM-Objekt-Manager. WMI-Anbieter extrahieren Verwaltungsinformationen aus dem zugrunde liegenden
175
verwalteten System. Anschließend werden diese Informationen Objektklassen zugeordnet, die der CIM-Objekt-Manager an die WMI-Verwaltungsanwendungen übergibt. Exchange Server 2003 enthält zahlreiche WMI-Anbieter und -Klassen. Weitere Informationen zu diesen Klassen finden Sie unter WMI documentation in the Exchange SDK.
Der Exchange-System-Manager verwendet die folgenden WMI-Anbieter:
ExchangeDsAccessProvider Durch diesen WMI-Anbieter kann der Exchange-System-Manager mit der DSAccess-Komponente kommunizieren, um Domänencontroller und globale Katalogserver anzuzeigen und einzustellen, die DSAccess für den Zugriff auf Active Directory-Informationen verwendet. Der Exchange-System-Manager kommuniziert mit dem ExchangeDsAccessProvider, wenn Sie in den Exchange Server 2003-Servereigenschaften auf die Registerkarte Verzeichniszugriff klicken.
Der WMI-Anbieter ExchangeDsAccessProvider ist im Microsoft Exchange-Verwaltungsdienst (MSExchangeMGMT) implementiert. Wenn dieser Dienst beendet wird, steht ExchangeDsAccessProvider nicht mehr zur Verfügung. Die Liste der Domänencontroller und globalen Katalogserver, die von DSAccess auf diesem Exchange-Server verwendet werden, kann dann ebenfalls nicht mehr angezeigt oder geändert werden. Für die Funktion von DSAccess ist jedoch der Exchange-Verwaltungsdienst nicht erforderlich. DSAccess verwendet weiterhin die vordefinierte Liste der Domänencontroller und globalen Katalogserver oder bestimmt diese auf dynamische Weise. Weitere Informationen zu DSAccess finden Sie unter Exchange Server 2003 und Active Directory .
ExchangeMessageTrackingProvider Dieser WMI-Anbieter liefert Informationen über Nachrichten, die durch das mit der Nachrichtenverfolgung aktivierte Transportmodul eines Exchange-Servers geleitet werden. Die Nachrichtenverfolgung ist eine Funktion, die es Ihnen ermöglicht, die Pfade von Nachrichten während der Übertragung durch die Exchange-Organisation zu verfolgen. Standardmäßig ist die Nachrichtenverfolgung deaktiviert. Auf der Registerkarte Allgemein des Servers können Sie die Nachrichtenverfolgung für jeden einzelnen Server auswählen. Bei aktivierter Nachrichtenverfolgung werden Statusinformationen in tägliche Protokolldateien geschrieben, die im Verzeichnispfad \Programme\Exchsrvr\<Servername>.log (z. B. \Programme\Exchsrvr\Server01.log) gespeichert werden. Der Name der Protokolldatei hat das Format <JJJJMMTT>.LOG (beispielsweise 20040321.LOG). Protokolldateien für die Nachrichtenverfolgung sind durch Tabulatoren getrennte Textdateien, die zum Netzwerkzugriff auf allen Exchange-Servern freigegeben sind. Der Freigabename lautet <SERVERNAME>.LOG.
Sie können Nachrichtenverfolgungsinformationen durch direktes Öffnen der Protokolldateien für die Nachrichtenverfolgung in einem Texteditor oder im Snap-In Exchange-Nachrichtenstatus analysieren. Exchange-Nachrichtenstatus ist ein eigenständiges Snap-In und steht im Exchange-System-Manager unter dem Knoten Tools zur Verfügung. Dieses Snap-In kann auch separat in benutzerdefinierten MMC-Tools verwendet werden. In Exchange Server 2003 werden von diesem Snap-In die
176
Verfolgungsinformationen von ExchangeMessageTrackingProvider auf dem lokalen Computer gelesen. Bei Verwendung von Remoteservern für die Nachrichtenübertragung kommuniziert ExchangeMessageTrackingProvider auf dem lokalen Server mit ExchangeMessageTrackingProvider auf den jeweiligen Remoteservern. Auf diese Weise wird der Nachrichtenpfad jeweils von Server zu Server über die gesamte Exchange-Organisation hinweg verfolgt. Anschließend werden vollständige Informationen an das Snap-In Exchange-Nachrichtenstatus zurückgegeben.
ExchangeMessageTrackingProvider ist ebenfalls im Microsoft Exchange-Verwaltungsdienst implementiert. Wenn dieser Dienst auf dem lokalen Server, auf dem Exchange Server 2003 installiert ist, nicht ausgeführt wird, ist ExchangeMessageTrackingProvider nicht verfügbar, und Exchange-Nachrichtenstatus funktioniert nicht. Wenn der Exchange-Verwaltungsdienst auf einem Remoteserver mit Exchange Server 2003 nicht ausgeführt wird, werden unter Umständen unvollständige Nachrichtenverfolgungsinformationen zurückgegeben. Zur Gewährleistung der Abwärtskompatibilität mit Exchange 2000 Server kann der Nachrichtenstatus jedoch auch mit dem SMB-Protokoll (Windows Server 2003 Message Block) direkt auf die Netzwerkfreigaben für die Nachrichtenverfolgung zugreifen.
In der folgenden Abbildung ist dargestellt, wie die Exchange-Anbieter und der Exchange-Verwaltungsdienst in das WMI-Subsystem integriert sind.
177
Exchange-Anbieter im WMI-Subsystem
Dienstkonfiguration im Exchange-System-ManagerZur Unterstützung der Remoteaktualisierung von in der Registrierung gespeicherten Konfigurationseinstellungen erfordert der Exchange-System-Manager, dass der Remoteregistrierungsdienst auf allen Exchange-Servern ausgeführt wird. Wenn Sie beispielsweise die Eigenschaften eines Serverobjekts im Exchange-System-Manager anzeigen und zur Registerkarte Diagnoseprotokoll wechseln, um die Ereignisprotokolliergrade für die verschiedenen Kategorien der Exchange-Dienste anzuzeigen oder festzulegen, greift der Exchange-System-Manager über die Registrierungs-API auf Registrierungseinstellungen für die entsprechenden Dienste zu. Die Kategorien, die für einen Dienst auf der Registerkarte Diagnoseprotokoll angezeigt werden, entsprechen den Parametern REG_DWORD, die im Unterschlüssel Diagnostics des Exchange-Diensts unter HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services gespeichert sind. In der folgenden Abbildung ist diese Beziehung anhand der DSAccess-Komponente dargestellt.
178
Diagnoseprotokollierungseinstellungen im Registrierungs-Editor und im Dialogfeld „Eigenschaften“ für ein Serverobjekt im Exchange-System-Manager
Bei der Bearbeitung von Registrierungseinstellungen auf dem lokalen Computer wird der Remoteregistrierungsdienst umgangen. Wenn Sie jedoch den Diagnoseprotokolliergrad für einen Exchange-Server remote einstellen möchten, muss der Exchange-System-Manager zuerst mit der Funktion RegConnectRegistry der Registrierungs-API eine Verbindung mit dem Registrierungsschlüssel herstellen, der auf dem Remotecomputer geöffnet werden soll. Für diesen Funktionsaufruf muss der Exchange-Administrator Berechtigungen zum Zugriff auf den Remoteregistrierungsdienst besitzen. Andernfalls kann die Remoteverbindung mit der Registrierung nicht hergestellt werden.
Vorsicht: Eine fehlerhafte Bearbeitung der Registrierung kann zu ernsthaften Problemen führen, die möglicherweise eine Neuinstallation des Betriebssystems erforderlich machen. Dadurch entstandene Probleme können unter Umständen nicht mehr behoben werden. Sichern Sie vor dem Ändern der Registrierung alle wichtigen Daten.
179
In der Standardkonfiguration von Windows wird nur lokalen Administratoren der Remotezugriff auf die Registrierung gestattet. Um sicherzustellen, dass Exchange-Administratoren einen Exchange-Server remote verwalten können, fügt die Systemaufsicht die Konten mit einer Exchange-Administratorfunktion automatisch zur Zugriffssteuerungsliste (ACL, Access Control List) des Registrierungsschlüssels WinReg hinzu und gewährt diesen Konten die Berechtigung Vollzugriff. Dieser Schlüssel befindet sich unter folgendem Unterschlüssel: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers.
Mit den erforderlichen Berechtigungen für den Remoteregistrierungsdienst kann der Exchange-Administrator eine Remoteverbindung mit der Zielregistrierung herstellen. Dies bedeutet jedoch nicht, dass der Exchange-Administrator auch berechtigt ist, Einstellungen anderer Registrierungsschlüssel zu lesen oder zu schreiben. Beispielsweise kann es vorkommen, dass einem Administrator zwar die Berechtigung Vollzugriff für den Schlüssel WinReg zugewiesen sind, jedoch die Berechtigung für den Schlüssel MSExchangeMTA in der Dienststeuerungsdatenbank verweigert wird. In diesem Fall könnte der Exchange-System-Manager eine Verbindung mit der Registrierung des Remoteservers herstellen, jedoch möglicherweise keine Liste der Dienste oder Diagnosekategorien auf der Registerkarte Diagnoseprotokoll anzeigen. Um sicherzustellen, dass ein Exchange-Administrator die Einstellungen für Exchange-Dienste lesen und schreiben kann, wird Exchange-Administratoren von der Systemaufsicht Vollzugriff auf den Schlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Services gestattet. Sämtliche Unterschlüssel unter diesem Registrierungsschlüssel erben diese Berechtigungseinstellungen. Weitere Informationen zu den Registrierungseinstellungen für Exchange-Dienste finden Sie unter Dienstabhängigkeiten in Exchange Server 2003 .
Wenn der Exchange-System-Manager auf den Schlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Services auf einem Exchange-Server nicht zugreifen kann, weil eine Verbindung mit dem Remoteregistrierungsdienst nicht hergestellt werden kann oder Sie nicht über ausreichende Zugriffsberechtigungen verfügen, werden Sie in einer Fehlermeldung darüber informiert, dass der Netzwerkpfad nicht gefunden werden konnte und Sie den Server nicht verwalten können.
NachrichtenroutingarchitekturBeim Routing einer Nachricht wird diese in Übereinstimmung mit verschiedenen Nachrichtenroutingregeln vom Absender an den Empfänger geleitet. Eine Nachrichtenroute kann mehrere „Hops“ enthalten. Ein Hop ist ein Knoten auf dem Routingpfad. In der Routingarchitektur einer Microsoft Exchange Server 2003-Organisation werden die Knoten auf der Nachrichtenroute durch Routinggruppen dargestellt. Durch Messagingconnectors werden diese Knoten oder Routinggruppen in der internen Messagingumgebung miteinander verbunden. Eine Exchange-Organisation kann auch über Messagingconnectors mit einer externen Messagingumgebung, z. B. dem Internet, verbunden werden, sodass Nachrichten
180
von außen in die Exchange-Organisation eingehen oder aus der Organisation heraus gesendet werden können.
Folgende Themen werden in diesem Abschnitt behandelt:
Wichtige Elemente der Exchange Server 2003-Routingtopologie Sie müssen die Komponenten der Nachrichtenroutingtopologie einer Exchange-Organisation kennen, um die Grundlagen des Nachrichtenrouting in Exchange Server 2003 zu verstehen.
Exchange Server 2003-Nachrichtenverarbeitung Bevor Sie sich den eigentlichen Routingmechanismen in Exchange Server 2003 zuwenden, müssen Sie zunächst damit vertraut sein, wie Exchange Server 2003 Nachrichten an Empfänger weiterleitet, die sich auf demselben Exchange-Server wie der Absender befinden bzw. auf anderen Exchange-Servern in derselben Routinggruppe, in anderen Routinggruppen oder auf externen Messagingsystemen.
Nachrichtenrouting in Exchange Server 2003 In Exchange Server 2003 werden dynamische Routingentscheidungen anhand von Verbindungsstatusinformationen getroffen, sodass Routingentscheidungen nicht von einer statischen Routingtabelle abhängig sind. Um die Funktionsweise des dynamischen Nachrichtenrouting in Exchange Server 2003 zu verstehen, müssen Sie sich zunächst damit vertraut machen, wie Exchange Server 2003 Nachrichtenrouten auswählt und wie sich Änderungen an der Routingtopologie auf den Nachrichtenroutingprozess auswirken.
Übertragung von Verbindungsstatusinformationen Es müssen entsprechende Verfahren zum Replizieren der Verbindungsstatusinformationen zwischen Exchange-Servern vorhanden sein. Durch diese Verfahren wird sichergestellt, dass jeder Server über genaue Informationen zur gesamten Organisation verfügt. Mithilfe dieser Informationen kann der Server den optimalen Pfad zu einem beliebigen Ziel in der Messagingumgebung entsprechend dem aktuellen Zustand der Routingtopologie neu berechnen. Sie müssen Kenntnisse darüber haben, wie Server Änderungen auf die Nachrichtenroutingtopologie in einer Exchange Server 2003-Organisation übertragen. Außerdem müssen Sie die Details der Verbindungsstatustabelle (die Tabelle, die die Routinginformationen enthält) und den Algorithmus kennen, nach dem die Verbindungsstatusinformationen zwischen Exchange-Servern repliziert werden.
Abwärtskompatibilität mit Exchange Server 5.5 Bei der Integration von Exchange Server 2003 in eine Exchange Server 5.5-Organisation ergeben sich verschiedene Routingprobleme. Sie müssen diese Probleme kennen, um zu verstehen, wie Exchange Server 5.5 Connectors von Exchange Server 2003 verwenden kann und umgekehrt.
In diesem Abschnitt wird davon ausgegangen, dass Sie mit dem Aufbau der Routinggruppentopologie und der Konfiguration von Messagingconnectors vertraut sind. Weitere Informationen zum Transport und Routing finden Sie unter Exchange Server 2003 Transport and Routing Guide .
181
Nachrichtenroutingtopologie in Exchange Server 2003In der folgenden Abbildung ist die Routingtopologie einer Exchange Server 2003-Organisation dargestellt, bei der mehrere interne Routinggruppen durch Routinggruppenconnectors und einen weiteren Connector verbunden sind, der die Exchange-Organisation mit einem externen Messagingsystem verbindet. In dieser Topologie ist Routinggruppe A ein zentraler Routinghub. Alle Nachrichten an Remoteroutinggruppen (Routinggruppen B und C) sowie das Exchange-fremde Messagingsystem werden durch die Routinggruppe A geleitet. Durch die Bereitstellung mehrerer Bridgeheadserver in Routinggruppe A werden redundante Nachrichtenübertragungspfade zur Verfügung gestellt.
Eine Nachrichtenroutingtopologie in Exchange Server 2003
Die in der Abbildung oben dargestellte Nachrichtenroutingtopologie enthält folgende Hauptkomponenten:
Routinggruppen Logische Serversammlungen, die zur Steuerung des Nachrichtenflusses und zum Verweis auf Öffentliche Ordner verwendet werden. Routinggruppen verwenden gemeinsam eine oder mehrere physische Verbindungen. Die Kommunikation und Nachrichtenübertragung erfolgt zwischen allen Exchange-Servern in einer Routinggruppe auf direktem Weg über virtuelle SMTP-Server (Simple Mail Transfer
182
Protocol). Wenn sich eine Organisation im einheitlichen Modus befindet, können Routinggruppen Server aus verschiedenen administrativen Gruppen enthalten. In einer Organisation im gemischten Modus können sich Routinggruppen hingegen aufgrund der Abwärtskompatibilität mit Exchange Server 5.5 nicht über mehrere administrative Gruppen erstrecken. Dies ist darin begründet, dass die Routingtopologie in Exchange 5.5 durch Standorte definiert wird und Standorte über die Funktionalität der administrativen Gruppe und der Routinggruppe verfügen.
Tipp: SMTP ist für alle TCP/IP-Verbindungstypen gut geeignet. Durch eine Routinggruppe werden daher nicht zwangsläufig Computernetzwerkbereiche mit hoher Netzwerkbandbreite definiert. Routinggruppen können sich auch über relativ langsame Netzwerkverbindungen erstrecken, sofern die Verbindung dauerhaft und stabil ist. Wenn beispielsweise alle Server in Abbildung 5.1 direkt über TCP/IP kommunizieren können, könnten Sie alle Exchange-Server in einer Routinggruppe zusammenfassen und somit auf vier der fünf Bridgeheadserver und alle Routinggruppenconnectors verzichten. Dadurch wird die Routinggruppentopologie erheblich optimiert. In Abbildung 5.1 muss der Bridgeheadserver, der einen Connector zum externen Messagingsystem ausführt, mit diesem externen Messagingsystem verbunden bleiben. Beachten Sie jedoch, dass alle Server in einer Routinggruppe in regelmäßigen Abständen den Routinggruppenmaster abfragen. Um die Kontrolle über die Kommunikation zwischen einzelnen Servern zu erhalten, müssen Sie möglicherweise mehrere Routinggruppen implementieren. Dies ist insbesondere dann wichtig, wenn durch die Kommunikation über WAN-Verbindungen (Wide Area Network) Kosten entstehen. Weitere Informationen zum Aufbau und zur Konfiguration von Routinggruppentopologien finden Sie im Transport- und Routing-Handbuch für Exchange Server 2003 unter (http://go.microsoft.com/fwlink/?LinkId=26041http://go.microsoft.com/fwlink/?LinkId=26041).
Routinggruppenconnectors Ein Routinggruppenconnector ermöglicht die Nachrichtenübertragung zwischen zwei Routinggruppen. Folgende Exchange-Connectors können zum Einrichten der Nachrichtenübertragungspfade zwischen Routinggruppen verwendet werden:
Routinggruppenconnectors Ein Routinggruppenconnector stellt einen unidirektionalen Verbindungspfad bereit, auf dem Nachrichten von Servern einer Routinggruppe zu den Servern einer anderen Routinggruppe geleitet werden. Routinggruppenconnectors verwenden SMTP (Simple Mail Transfer Protocol) zur Kommunikation mit den Servern in der verbundenen Routinggruppe. Routinggruppenconnectors bieten die bestmögliche Verbindung zwischen Routinggruppen.
183
Hinweis: Der Routinggruppenconnector (als Eigenname) ist ein spezieller Connectortyp, der nur dazu dient, Routinggruppen miteinander zu verbinden. Andere Connectors zur Verbindung von Routinggruppen sind der SMTP-Connector und der X.400-Connector. Mit diesen Connectors kann jedoch auch eine Exchange-Organisation mit einem externen Messagingsystem über SMTP oder X.400 verbunden werden. Um Verwechslungen vorzubeugen, wird in diesem Handbuch der Begriff Routinggruppenconnector (fett formatiert) als Bezeichnung für den speziellen Connector verwendet, der nur zwischen Routinggruppen eingesetzt werden kann. Der normal formatierte Begriff Routinggruppenconnector bezieht sich auf alle Typen von Connectors, die zur Verbindung von Routinggruppen verwendet werden können.
SMTP-Connector Mit einem SMTP-Connector können Routinggruppen zwar ebenfalls miteinander verbunden werden, dies ist jedoch nicht empfehlenswert. SMTP-Connectors dienen zur externen Nachrichtenübermittlung. SMTP-Connectors definieren bestimmte Pfade für E-Mail-Nachrichten, die über das Internet oder an ein externes Ziel, z. B. ein anderes Messagingsystem als Exchange, gesendet werden sollen.
X.400-Connectors Obwohl Sie mit X.400-Connectors auch Routinggruppen verbinden können, sind diese Connectors eigentlich zur Verbindung von Exchange-Servern mit anderen X.400-Systemen oder mit Servern bestimmt, auf denen Exchange Server 5.5 ausgeführt wird und die sich außerhalb einer Exchange-Organisation befinden. Ein Server, auf dem Exchange Server 2003 ausgeführt wird, kann dann unter Verwendung des X.400-Protokolls Nachrichten über diesen Connector senden.
Hinweis: X.400-Connectors stehen nur in der Exchange Server 2003 Enterprise Edition zur Verfügung.
Connectors zu Exchange-fremden Messagingsystemen Diese Connectors unterstützen die Nachrichtenübertragung und Verzeichnissynchronisierung zwischen Exchange-Messagingsystemen und anderen Messagingsystemen. Wenn geeignete Connectors implementiert sind, ähnelt sich das Anwendungsverhalten auf beiden Messagingsystemen, und die Übertragung von Nachrichten sowie anderen Informationen zwischen dem Exchange-System und dem fremden Messagingsystem ist für den Benutzer transparent. Manche Nachrichteneigenschaften gehen jedoch unter Umständen verloren, wenn Nachrichten aus einem Exchange-Format in ein Exchange-fremdes Format oder umgekehrt konvertiert werden.
Postfachserver Ein Postfachserver ist ein Exchange-Server, der als Host für Postfächer konfiguriert ist. Benutzer können über verschiedenste Clients auf ihre
184
Postfächer zugreifen, z. B. über Microsoft Office Outlook, Microsoft Office Outlook Web Access, Microsoft Office Outlook Mobile Access, POP3-basierte Clients (Post Office Protocol, Version 3) und IMAP4-basierte Clients (Internet Message Access Protocol, Version 4rev1). In der Exchange Server 2003-Routingtopologie sind Postfachserver typische Quellen und Ziele von E-Mail-Nachrichten.
Bridgeheadserver Ein Bridgeheadserver ist ein Verbindungspunkt, der die Nachrichtenübermittlung von einer Routinggruppe zu einer anderen Routinggruppe oder zu einem externen Messagingsystem übernimmt. In großen Organisationen werden Bridgeheadserver oft von Postfachservern getrennt, um Leistungsengpässe zu vermeiden. Aufgrund der erhöhten Verarbeitungserfordernisse während der Spitzenzeiten der Nachrichtenübertragung verursachen Postfachserver Leistungsengpässe. Bridgeheadserver sind wie folgt als lokale oder Remotebridgeheadserver zu erkennen:
Lokale Bridgeheadserver Dieser Server fungiert als Host für einen Connector und verwendet diesen zur Übertragung von Nachrichten. Beim Erstellen des Connectors legen Sie mindestens einen Exchange-Server als Bridgeheadserver fest. Außerdem können Sie aus Gründen des Lastenausgleichs, der Leistungssteigerung und der Redundanz auch mehrere Bridgeheadserver definieren. Beispielsweise gilt für Routinggruppenconnectors standardmäßig die Option Jeder lokale Server kann E-Mail über diesen Connector senden. In diesem Fall können alle Exchange-Server in der lokalen Routinggruppe den Connector zur Übertragung von Nachrichten verwenden.
Remotebridgeheadserver Der Remotebridgeheadserver, der in einer Connectorkonfiguration angegeben wird, ist der Server (in der verbundenen Routinggruppe oder in einem anderen Messagingsystem als Exchange), der alle über einen Connector übertragenen Nachrichten empfängt. Einem Routinggruppenconnector können mehrere Remotebridgeheadserver (d. h. virtuelle SMTP-Remoteserver) zugeordnet sein. Ein SMTP-Connector oder X.400-Connector kann jedoch nur über einen Remotebridgeheadserver pro Connectorinstanz verfügen. Remotebridgeheadserver werden auch als Zielbridgeheadserver bezeichnet.
Nachrichtenverarbeitung in Exchange Server 2003Die Nachrichtenübertragung in Exchange 2003 ist hauptsächlich Aufgabe des SMTP-Diensts. Das Exchange 2003-SMTP-Transportmodul ist an der gesamten Nachrichtenverarbeitung beteiligt, unabhängig vom endgültigen Ziel der Nachricht. Eine Nachricht kann für einen Benutzer bestimmt sein, der sich auf demselben Server, einem anderen Server in derselben Routinggruppe, einem Server in einer anderen Routinggruppe oder einem Server in einem externen Messagingsystem befindet. In der folgenden Abbildung ist die SMTP-Transportarchitektur von Exchange Server 2003 dargestellt. Ausführliche Informationen zu
185
den Komponenten im SMTP-Transportmodul und deren Aufgaben finden Sie in Kapitel 6 unter SMTP-Transportarchitektur.
Die Exchange Server 2003-Transportarchitektur
In Exchange Server 2003 werden Nachrichten vom SMTP-Transportmodul folgendermaßen verarbeitet:
186
1. Wie in der folgenden Tabelle erläutert, kann eine Nachricht durch SMTP, Remoteprozeduraufrufe (RPCs) oder die Übertragungsprotokolle X.400 bzw. MAPI empfangen werden.
Übertragungsprotokolle für eingehende Nachrichten
Übertragungsprotokoll Beschreibung
SMTP Exchange 2000- und Exchange Server 2003-Server kommunizieren über SMTP miteinander. Andere Hosts als Exchange sowie POP3- und IMAP4-Clients verwenden ebenfalls SMTP, um Nachrichten auf einen Server zu übertragen, auf dem Exchange Server 2003 ausgeführt wird. Diese Nachrichten werden durch den SMTP-Protokolldienst empfangen, der diese im Ordner \Exchsrvr\Mailroot\vsi 1\Queue im Dateisystem speichert. Anschließend werden die Nachrichten an die Warteschlange vor der Übertragung übergeben. Jeder virtuelle SMTP-Server auf einem Exchange 2003-Server verwaltet ein eigenes Unterverzeichnis im Ordner Exchsrvr\Mailroot\. Beispielsweise lautet der Pfad zum Mailroot-Verzeichnis des standardmäßigen virtuellen SMTP-Servers \Exchsrvr\Mailroot\vsi 1.
Eine andere Methode zur Übermittlung von Nachrichten an den SMTP-Dienst besteht darin, diese im Unterverzeichnis \Pickup im Ordner Mailroot des virtuellen SMTP-Servers abzulegen. Diese Nachrichtenübertragung gilt ebenfalls als SMTP-basierte Methode, da die Nachrichtendatei im Format RFC-822 vorliegen muss, damit der SMTP-Dienst diese Nachricht abrufen und erfolgreich verarbeiten kann.
187
Übertragungsprotokoll Beschreibung
RPCs Exchange 5.5-Server kommunizieren am lokalen Standort über RPCs miteinander. Exchange 5.5-MTAs (Message Transfer Agents) verwenden RPCs zur Übertragung von E-Mail-Nachrichten an andere MTAs am lokalen Standort, ohne dass ein Messagingconnector definiert sein muss. Wenn Exchange Server 2003 an einem vorhandenen Exchange 5.5-Standort bereitgestellt ist, werden Nachrichten mit Exchange 5.5 durch RPCs mithilfe des Diensts Microsoft Exchange MTA-Stacks ausgetauscht.
Bei Verwendung eines Standortconnectors kommunizieren Exchange 5.5-Server an verschiedenen Standorten ebenfalls über RPCs miteinander. Exchange 2003 kann mit einem Standortconnector kommunizieren, wenn Sie einen Routinggruppenconnector bereitstellen, der mit einem Exchange 5.5-Server an einem Remotestandort verbunden ist. In diesem Fall verwendet der Routinggruppenconnector kein SMTP, sondern wechselt automatisch in den RPC-Modus, um die Abwärtskompatibilität mit Exchange 5.5 zu gewährleisten.
188
Übertragungsprotokoll Beschreibung
X.400 Wenn Sie Nachrichten mit einem X.400-Remote-MTA (Message Transfer Agent) austauschen möchten, muss ein X.400-Connector konfiguriert sein. Wie bereits zuvor erwähnt, können Sie X.400-Connectors auch dazu verwenden, um Routinggruppen in einer Exchange-Organisation miteinander zu verbinden. Der Dienst Microsoft Exchange MTA-Stacks empfängt eingehende X.400-Nachrichten und übergibt diese an den Exchange-Informationsspeicher. Vom Exchange-Informationsspeichertreiber werden diese Nachrichten dann in der Warteschlange vor der Übermittlung abgelegt. Weitere Informationen zur X.400-Architektur finden Sie unter X.400-Transportarchitektur.
189
Übertragungsprotokoll Beschreibung
MAPI MAPI-basierte Clients (z. B. Microsoft Outlook) sowie MAPI-basierte Messagingconnectors (z. B. Connector für Lotus Notes und Connector für Novell GroupWise) kommunizieren direkt mit dem Exchange-Informationsspeicher. Beispielsweise legen MAPI-Clients ausgehende Nachrichten im Ordner Postausgang des Postfachs des Benutzers ab und informieren den Exchange-Informationsspeicher dann über die Übertragung der Nachricht. MAPI-basierte Messagingconnectors verwenden jedoch als Warteschlange für eingehende Nachrichten den Ordner MTS-IN im Exchange-Informationsspeicher. Eingehende Nachrichten werden von MAPI-basierten Messagingconnectors in das Exchange-Format umgewandelt und anschließend im Ordner MTS-IN gespeichert. In jedem Fall wird die MAPI-Nachricht im Exchange-Informationsspeicher abgelegt. Anschließend wird die Nachricht vom Exchange-Informationsspeichertreiber in die Warteschlange vor der Übermittlung eingereiht. Weitere Informationen zu MAPI-basierte Messagingconnectors finden Sie unter Architektur von Gateway-Messaging-Connectors.
2. Die Warteschlange vor der Übermittlung ist der Eintrittspunkt in das erweiterte Warteschlangenmodul. Nachdem eine Nachricht in die Warteschlange vor der Übermittlung eingereiht wurde, wird diese Nachricht durch benutzerdefinierten SMTP-Verarbeitungscode (z. B. Ereignissenken zur Virenschutzüberprüfung) verarbeitet. Das erweiterte Warteschlangenmodul verschiebt die Nachricht dann in die Warteschlange vor der Kategorisierung, sodass das Kategorisierungsmodul, eine interne Komponente des SMTP-Transportmoduls, die Nachricht weiterverarbeiten kann.
3. Das Kategorisierungsmodul löst die Empfänger- und Absenderadressen auf, gliedert E-Mail-aktivierte Gruppen auf, überprüft Beschränkungen, wendet Beschränkungen auf Absender- und Empfängerebene an und führt weitere Vorgänge durch. Wenn sich das Postfach des Empfängers in der lokalen Exchange Server 2003-Organisation befindet,
190
kennzeichnet das Kategorisierungsmodul den Empfänger als lokal, indem eine empfängerspezifische Eigenschaft festgelegt wird, die den vollqualifizierten Domänenname (FQDN) des Stammservers des Empfängers angibt. Hierbei handelt es sich um einen wichtigen Routingschritt. Anschließend ermittelt das erweiterte Warteschlangenmodul den Nachrichtenübertragungspfad anhand des FQDN des Stammservers des Empfängers.
4. Nach der Kategorisierung legt das erweiterte Warteschlangenmodul die Nachricht in der Warteschlange nach der Kategorisierung ab. Ab diesem Zeitpunkt muss zwischen Nachrichten für lokale Empfänger und Nachrichten für Empfänger auf Remotesystemen wie folgt unterschieden werden:
Lokale Übermittlung Für lokale Empfänger erfolgt kein Routing. Der Postfachspeicher, der das Zielpostfach enthält, wird in der Nachricht angegeben, und das erweiterte Warteschlangenmodul überträgt die Nachricht an die Warteschlange für lokale Übermittlung. Der Exchange-Informationsspeichertreiber ruft die Nachricht aus der Warteschlange für lokale Übermittlung ab und speichert sie im Postfach des Empfängers.
Remoteübermittlung Das Routingmodul muss alle an externe Empfänger gerichtete Nachrichten verarbeiten, da das SMTP-Transportmodul einen verfügbaren Übertragungspfad für das Ziel finden muss. Dementsprechend überträgt das erweiterte Warteschlangenmodul die Nachricht an die Warteschlange vor dem Routing, ruft das Routingmodul auf und übergibt danach die Zieladresse (d. h. für interne Empfänger den FQDN des Stammservers des Empfängers oder für externe Empfänger den SMTP-Domänennamen) an das Routingmodul. Das Routingmodul gibt den nächsten Hop zurück, der von der Nachricht auf dem Weg zum Aufrufenden verwendet wird, und klassifiziert den nächsten Hop gemäß der Einteilung in der folgenden Tabelle.
Hoptypen für die Remoteübermittlung
Hoptyp Beschreibung
Nächster Hop führt zum lokalen Server Hiermit wird angegeben, dass das Transportmodul die Nachricht an den Exchange-MTA für die Übermittlung übergeben muss. Die Übergabe kann durch RPCs an einen Exchange 5.5-Server in der lokalen Routinggruppe, durch einen X.400-Connector an einen X.400-Remote-MTA oder durch einen MAPI-basierten Messagingconnector (z. B. Connector für Lotus Notes oder Connector für Novell GroupWise) an ein anderes Messagingsystem als Exchange erfolgen.
191
Hoptyp Beschreibung
Nächster Hop führt zu einem Server in der lokalen Routinggruppe
Hiermit wird angegeben, dass das Transportmodul die Nachricht an den standardmäßigen virtuellen SMTP-Server zur SMTP-Übertragung an das Ziel übergeben muss.
Nächster Hop führt zu einem Server in einer Remoteroutinggruppe
Hiermit wird angegeben, dass das Transportmodul die Nachricht an einen Routinggruppenconnector auf dem lokalen Exchange-Server übergeben muss. Es ist jedoch anzumerken, dass dieser Typ nur für Nachrichten gilt, die per SMTP übertragen werden. Wenn Sie X.400-Connectors zum Verbinden von Routinggruppen verwenden, übergibt das Transportmodul die Nachrichten an den Exchange-MTA (d. h. der nächste Hop führt zum lokalen Server).
Nächster Hop führt zu einem Server außerhalb der Exchange-Organisation
Hiermit wird angegeben, dass das Transportmodul die Nachricht an einen SMTP-Connector oder einen virtuellen SMTP-Server übergeben muss, der die Nachricht an das externe Messagingsystem übermitteln kann. Auch dieser Hoptyp betrifft nur Ziele, die per SMTP erreichbar sind. Wenn die Nachricht für ein anderes Messagingsystem als Exchange bestimmt ist, das über einen MAPI-basierten Connector verbunden ist, der durch den Exchange-MTA gesteuert wird, übergibt das Transportmodul die Nachrichten an den Exchange-MTA (d. h. der nächste Hop führt zum lokalen Server).
Nächster Hop führt zu einem derzeit nicht erreichbaren Server
Hiermit wird angegeben, dass ein Zielpfad zwar vorhanden, jedoch derzeit nicht verfügbar ist. Das Transportmodul bewahrt die Nachricht auf, bis der Übertragungspfad wieder verfügbar ist oder bis die Nachricht abläuft und mit einem Unzustellbarkeitsbericht an den Absender zurückgesendet werden muss.
192
Hoptyp Beschreibung
Nächster Hop führt zu einem nicht erreichbaren Server
Hiermit wird angegeben, dass kein endgültiger Zielpfad vorhanden ist und das Transportmodul die Nachricht mit einem Unzustellbarkeitsbericht an den Absender zurücksendet.
5. Das erweiterte Warteschlangenmodul speichert die Informationen zum nächsten Hoptyp und zum Ziel im Cache und verschiebt die Nachricht in die entsprechende Verbindungswarteschlange. Verbindungswarteschlangen sind dynamisch und werden durch den Warteschlangen-Manager verwaltet. Der Name jeder Verbindungswarteschlange entspricht dem Ziel der Remoteübermittlung.
Hinweis: Verbindungswarteschlangen sind in der Warteschlangenanzeige des Exchange-System-Managers nur dann vorhanden und verfügbar, wenn Nachrichten zur Übertragung an das entsprechende Ziel anstehen. Etwa eine Minute nach der Übermittlung der letzten Nachricht aus der Verbindungswarteschlange lässt der Warteschlangen-Manager diese Verbindungswarteschlange verfallen.
6. Nachrichten in Verbindungswarteschlangen werden im Unterschied zur Exchange-MTA-Warteschlange mit dem SMTP-Protokollmodul übertragen. Nachrichten in der Exchange-MTA-Warteschlange werden jedoch an die Exchange-MTA-Warteschlange für ausgehende Nachrichten (ein Systemordner mit der Bezeichnung MTS-OUT) im Exchange-Informationsspeicher übertragen. Der Exchange-Informationsspeichertreiber führt diese Aufgabe aus. Der Exchange-MTA erhält die Nachricht und kommuniziert dann mit dem Routingmodul über MTARoute.dll, um einen geeigneten und verfügbaren Connector zu ermitteln. Wenn die Nachricht für einen Connector bestimmt ist, der eine Verbindung zu einem anderen Messagingsystem als Exchange herstellt, legt der Exchange-MTA die Nachricht in der Warteschlange für ausgehende Nachrichten dieses Connectors im Exchange-Informationsspeicher ab (im Ordner MTS-OUT des Connectors). Andernfalls überträgt der MTA die Nachricht direkt über RPCs oder einen X.400-Connector. Weitere Informationen zu Exchange-MTA finden Sie unter X.400-Transportarchitektur.
Nachrichtenrouting unter Exchange Server 2003Wenn Nachrichten nicht an lokale Empfänger gerichtet sind, müssen für das erweiterte Warteschlangenmodul vom Routingmodul Informationen zum Host für den nächsten Hop auf
193
dem Übertragungspfad des Ziels sowie zum Typ des nächsten Hops bereitgestellt werden (siehe vorheriger Abschnitt). Der Host für den nächsten Hop stellt die tatsächliche Routingadresse dar. Durch den Typ des nächsten Hops wird bestimmt, wie die Nachricht durch das erweiterte Warteschlangenmodul verarbeitet wird. Zur Bereitstellung dieser entscheidenden Informationen muss das Routingmodul über eine umfassende Ansicht der gesamten Routingtopologie verfügen, einschließlich aller Routinggruppen und deren Server, Routinggruppenconnectors und Connectors zu externen Messagingsystemen. Unter Exchange Server 2003 stehen diese Informationen im Active Directory-Verzeichnisdienst zur Verfügung.
Nachrichtenrouten und die VerbindungsstatustabelleJeder Exchange 2003-Server verwaltet im Speicher dynamisch eine eigene, als Verbindungsstatustabelle bezeichnete Routingtabelle, die wie im Folgenden erläutert auf Active Directory und Verbindungsstatusinformationen beruht:
Routing-bezogene Active Directory-Informationen Diese Informationen werden in Attributen des Organisationsobjekts, von Routinggruppenobjekten, Connectorobjekten und Serverobjekten gespeichert. Diese Objekte befinden sich in der Konfigurationsverzeichnispartition und definieren die Routingtopologie der gesamten Exchange-Organisation.
Hinweis: Administrative Gruppen sind nicht Teil der Routingtopologie in einer Exchange-Organisation.
Verbindungsstatusinformationen Durch diese Informationen wird angegeben, ob ein Connector in der Routingtopologie verfügbar (in Betrieb) oder nicht verfügbar (außer Betrieb) ist. Verbindungsstatusinformationen sind dynamisch und können sich unter Umständen ändern, wenn an einem Connector Übertragungsprobleme auftreten oder Übertragungsprobleme behoben werden. Weitere Informationen zu Verbindungsstatusänderungen sowie zum Verteilen von Verbindungsstatusinformationen in einer Exchange-Organisation finden Sie unter Verbindungsstatusweitergabe.
Initialisieren der VerbindungsstatustabelleNach dem Starten initialisiert jeder Exchange-Server seine Verbindungsstatustabelle anhand der folgenden Informationen aus Active Directory:
Organisationsobjekt Die Grenze der Routingtopologie ist die Exchange-Organisation. Die Verbindungsstatustabelle enthält somit keine Informationen über externe Bridgeheadserver oder Messagingconnectors in einem externen Messagingsystem. Aus Sicht des Routingmoduls endet die Routingtopologie am Connector zum externen
194
Messagingsystem. Dementsprechend liest das Routingmodul die im Attribut objectGUID des Exchange-Organisationsobjekts in Active Directory registrierte GUID und kennzeichnet die Verbindungsstatustabelle mit dieser GUID, um die Organisation zu identifizieren, zu der diese Routinginformationen gehören.
Routinggruppenobjekte Das Routingmodul listet alle in administrativen Gruppen enthaltenen Routinggruppen auf und fragt die einzelnen Routinggruppen nach allen Objektattributen ab, u. a. auch das Attribut msExchRoutingGroupMembersBL, das eine Liste aller Routinggruppen-Mitgliedsserver enthält. Das Routingmodul legt diese Informationen in der Verbindungsstatustabelle ab. Durch das Routingmodul werden außerdem die Server und die zugehörigen Routinggruppen-GUIDs des jeweiligen Servers in einem Servercache im Speicher abgelegt. Jeder Eintrag im Servercache besteht aus jeweils einem Server-FQDN, dem die Routinggruppen-GUID des Servers hinzugefügt wurde.
Ein weiteres wichtiges Routinggruppenattribut ist das Attribut msExchRoutingMasterDN, das auf den DN des Routinggruppenmasters in der ausgewählten Routinggruppe verweist. Weitere Informationen zu den Aufgaben und Funktionen des Routinggruppenmasters finden Sie in den folgenden Ausführungen dieses Abschnitts.
Messagingconnectorobjekte Das Routingmodul listet alle untergeordneten Objekte mit dem Objekttyp msExchconnector auf, die im Verbindungscontainer jeder Routinggruppe enthalten sind. Bei den Objekten vom Typ msExchconnector im Verbindungscontainer handelt es sich um die Routinggruppenconnectors und Connectors zu externen Messagingsystemen, die in der Routinggruppe konfiguriert sind. Das Routingmodul liest alle Attribute von diesen Connectorobjekten, um Adressbereiche, Kostenwerte, Beschränkungen und andere Parameter zu ermitteln. Das Routingmodul legt diese Informationen für jeden Connector in der Verbindungsstatustabelle ab. Dadurch können Nachrichten an Ziele außerhalb der lokalen Gruppe weitergeleitet werden.
Dieser Vorgang wird fortgesetzt, bis das Routingmodul alle direkt und indirekt verbundenen Routinggruppen identifiziert und die Konfigurationsdetails ihrer Messagingconnectors abgefragt hat. Nach Abschluss dieses Vorgangs verfügt das Routingmodul über eine vollständige Ansicht aller verfügbaren Übertragungspfade in der gesamten Exchange-Organisation. Es wird davon ausgegangen, dass alle Verbindungen betriebsbereit und zur Nachrichtenübertragung verfügbar sind. Nach der Initialisierung der Verbindungsstatustabelle kommuniziert das Routingmodul mit dem Dienst Microsoft Exchange-Routingmodul auf dem lokalen Server, um dynamische Verbindungsstatusinformationen zu erhalten, die den aktuellen Zustand jedes Connectors angeben. Der Dienst Exchange-Routingmodul stellt über den TCP-Anschluss 691 eine Verbindung mit dem Routinggruppenmaster in der lokalen Routinggruppe her, um diese Informationen abzurufen. Weitere Informationen zu Verbindungsstatusinformationen finden Sie im Abschnitt „Überprüfen der Verbindungsstatustabelle“ weiter unten in diesem Abschnitt.
195
Routingmodul und der Dienst Exchange-RoutingmodulDas Routingmodul im Transportsubsystem und der Dienst Exchange-Routingmodul führen jeweils unterschiedliche Funktionen aus. Der Dienst Exchange-Routingmodul führt kein Nachrichtenrouting durch. Stattdessen kommuniziert der Dienst Exchange-Routingmodul Verbindungsstatusinformationen zwischen Servern in der lokalen Routinggruppe, auf denen Exchange 2000 Server und Exchange Server 2003 ausgeführt wird. Der Dienst Exchange-Routingmodul wird in der Datei resvc.dll implementiert, die sich im Verzeichnis \Programme\Exchsrvr\bin\ befindet. Der Dienstname lautet RESvc. Weitere Informationen zu den Microsoft Windows-Diensten von Exchange Server 2003 finden Sie unter Dienstabhängigkeiten in Exchange Server 2003 .
Beim Dienst Exchange-Routingmodul handelt es sich im Grunde nicht um ein Routingmodul, sondern um einen Dienst zur Verbindungsstatuskommunikation innerhalb einer Routinggruppe. Das eigentliche Routingmodul, das vom erweiterten SMTP-Warteschlangenmodul und Exchange-MTA zum Nachrichtenrouting verwendet wird, wird in der Datei reapi.dll implementiert. Zusätzlicher Programmcode für den Exchange-MTA ist in mtaroute.dll enthalten. Wenn daher der Dienst Exchange-Routingmodul beendet wird, können Nachrichten vom erweiterten Warteschlangenmodul und Exchange-MTA trotzdem noch mit dem Programmcode der Datei reapi.dll geroutet werden. Es werden lediglich keine dynamischen Aktualisierungen der Verbindungsstatustabelle mehr empfangen.
Hinweis: Obwohl dies im Allgemeinen nicht empfohlen wird, können Sie den Dienst Exchange-Routingmodul auf allen Servern deaktivieren, auf denen Exchange Server 2003 in einer Organisation ausgeführt wird. Mit dem Code in reapi.dll kann die Verbindungsstatustabelle dennoch auf jedem Server mit Informationen aus Active Directory initialisiert werden, es erfolgen jedoch keine dynamischen Aktualisierungen der Verbindungsstatustabelle mehr. In diesem Fall wird von Exchange Server 2003 ein statisches Nachrichtenrouting ausgeführt.
Überprüfen der VerbindungsstatustabelleBei der Verbindungsstatustabelle handelt es sich um eine kleine, im Arbeitsspeicher abgelegte Datenbank, die nicht auf der Festplatte gespeichert wird. Zum Überprüfen der Einträge, auf deren Grundlage das Routingmodul entsprechende Routingentscheidungen trifft, können Sie das Tool Exchange Server 2003 WinRoute (Winroute.exe) verwenden, das auf der Website Downloads for Exchange Server 2003 heruntergeladen werden kann.
Hinweis: Das Tool WinRoute ist zwar ebenfalls im Lieferumfang von Exchange 2000 Server enthalten, es wird jedoch empfohlen, die Exchange Server 2003-Version dieses Tools
196
herunterzuladen und für alle Exchange 2000- und Exchange Server 2003-Server in der Organisation zu verwenden.
Das Tool WinRoute stellt eine Verbindung mit dem Verbindungsstatusanschluss (TCP-Anschluss 691) auf dem ausgewählten Exchange-Server her und extrahiert die Verbindungsstatustabelle. Die Informationen in dieser Tabelle bestehen aus GUIDs und ASCII-Text zur Bezeichnung von Routinggruppen, Routinggruppenmitgliedern und Connectors in den Routinggruppen. Die Verbindungsstatustabelle enthält auch Informationen über die Konfiguration jedes einzelnen Connectors. Die Informationsfelder in der Verbindungsstatustabelle sind wie folgt durch Klammern voneinander getrennt:
'General Info' ('Routing Group' 'Routing Group Master' 'Version Info' 'Routing Group
Addresses' (Routing Group Members) (Connectors in Routing Group (Connector
configuration))).
Im folgenden Beispiel wird eine gekürzte Version einer Verbindungsstatustabelle dargestellt (außer für eine Routinggruppe wurden alle Felder entfernt):
d38082e7c9ecd74dbff32bada8932642 d037d6eaf2fa7cd10934aca433390623
(489416bfa3a4ff459b8f4403f20cad0d 1650c1fe32aef740be236e1089e0da6a 8 0 2
c2da71f9b39ec748aaf44119a2bdcb36 {26}*.489416BF-A3A4-FF45-9B8F-4403F20CAD0D
{4c}c=DE;a= ;p=TailspinToys;o=Exchange;cn=489416BF-A3A4-FF45-9B8F-4403F20CAD0D;*
{55}/o=TailspinToys/ou=First administrative Group/*/489416BF-A3A4-FF45-9B8F-
4403F20CAD0D ( 1650c1fe32aef740be236e1089e0da6a YES 1 1b20 {10}0701000000000101 )
( aa582d35e9621c4ca8ae57aa33d953a1 ( CONFIG {4}SMTP {}
{23}_aa582d35e9621c4ca8ae57aa33d953a1_D {63}/o=TailspinToys/ou=First administrative
Group/cn=Configuration/cn=Connections/cn=RGC RG A <-> RG B 0 0 0 0 ffffffff ffffffff 0
1 0 () 0 () 0 () 0 () ARROWS ( {2}RG {20}83bd0e29fad06d4eb8b00faab3265cd5 1 {4}X400
{23}c=DE;a= ;p=TailspinToys;o=Exchange; 1 ) BH () TARGBH
( 766a192b43bfc3459ee85608d65a98a9 CONN_AVAIL {19}server01.TailspinToys.com ) STATE
UP)))
(... next routing group... (... next routing members...) (... connectors in routing
group (... connector configuration..)))
In der folgenden Tabelle werden diese Informationen den verschiedenen Informationsfeldern in der Verbindungsstatustabelle zugeordnet.
Informationen in der Verbindungsstatustabelle
Feld Wert Beschreibung
Organisations-objectGUID d38082e7c9ecd74dbff32bada8
932642
Die GUID, die im objectGUID-Attribut des Exchange-Organisationsobjekts in Active Directory registriert ist.
197
Feld Wert Beschreibung
Adressräume ARROWS ( {2}RG
{20}83bd0e29fad06d4eb8b00f
aab3265cd5 1 {4}X400
{23}c=DE;a= ;p=TailspinToy
s;o=Exchange; 1 )
Jedem Connector ist mindestens ein Adressraum zugeordnet. Das Routingmodul ermittelt anhand dieser Informationen mögliche Connectors für eine bestimmte Nachricht, indem es die Empfängeradressen mit den verfügbaren Informationen über Adressräume vergleicht.
In der Verbindungsstatustabelle enthält die Liste ARROWS () die einzelnen Adressräume, die zu dem Connector gehören. Jeder Adressraumeintrag enthält die folgenden drei Datenelemente:
Adressraumtyp Der Adressraumtyp bestimmt das Format der Adressrauminformationen, die in der nächsten Position folgen. Beispielsweise erfordert ein X.400-Adressraum Adressrauminformationen in einem gültigen X.400-Format. Ein SMTP-Adressraum enthält hingegen Teile eines SMTP-Domänennamens. Für Routinggruppenconnectors gilt der Adressraumtyp RG, der
198
Feld Wert Beschreibung
für die objectGUID einer Routinggruppe steht.
Adressraum Durch den Adressraum wird das Adressmuster angegeben, das vom Routingmodul zur Identifikation des Ziels der Nachricht mit den Empfängeradressen verglichen wird. Adressräume für externe und interne Empfänger werden vom Routingmodul jeweils unterschiedlich verwendet.
Für externe Empfänger ist das Ziel ein Messagingconnector zum externen Messagingsystem. Das erweiterte Warteschlangenmodul übergibt die externen Adressinformationen an das Routingmodul, und das Routingmodul wählt den Connector aus, der die größtmögliche Übereinstimmung mit dem Ziel aufweist. Wenn ein SMTP-Connector z. B. über den Adressraum SMTP: *.net und ein anderer SMTP-Connector über den Adressraum SMTP: * verfügt, wählt das Routingmodul den ersten SMTP-Connector
199
Feld Wert Beschreibung
für alle Empfänger in .NET-Domänen und den zweiten SMTP-Connector für alle verbleibenden Internetempfänger aus.
Für Empfänger in der lokalen Organisation sind in den Empfängerrichtlinien Adressräume definiert (Adressraumeinstellung Diese Exchange-Organisation ist für die gesamte E-Mail-Übermittlung an diese Adresse verantwortlich). Wenn die Adresse eines Empfängers mit einem Adressraum für die lokale Organisation übereinstimmt, ermittelt das Kategorisierungsmodul den Stammserver des Empfängers anhand des msExchHomeServerName-Attributs des Empfängers. Das Kategorisierungsmodul kennzeichnet den Empfänger mit dem FQDN des Stammservers. Das erweiterte Warteschlangenmodul übergibt diesen FQDN dann an das Routingmodul zur Weiterleitung der
200
Feld Wert Beschreibung
Nachricht an das Ziel in der lokalen Organisation. Das Routingmodul sucht anhand des FQDN nach dem entsprechenden Servercache. Der vom Routingmodul gefundene Eintrag für den Stammserver enthält die GUID des Stammservers des Empfängers.
Das Routingmodul bestimmt anhand der GUID des Stammservers des Empfängers, wie die Nachricht übertragen werden muss:
a. Wenn die Routinggruppen-GUID des Stammservers mit der GUID der lokalen Routinggruppe übereinstimmt, befindet sich der Empfänger in der lokalen Routinggruppe, und die Nachricht muss direkt mit dem standardmäßigen virtuellen SMTP-Server des Exchange-Servers an den Stammserver des Empfängers übertragen werden. Das Routingmodul gibt den FQDN des
201
Feld Wert Beschreibung
Stammservers des Empfängers an das erweiterte Warteschlangenmodul zurück, um den Host für den nächsten Hop anzugeben.
Hinweis: Server, auf denen Exchange Server 5.5 ausgeführt wird, stellen eine Ausnahme dar. Diese Server kommunizieren mit Exchange 2003 in der lokalen Routinggruppe über Remoteprozeduraufrufe und den MTA-Dienst, wie in bereits an anderer Stellte in diesem Abschnitt erläutert.
b. Wenn die Routinggruppe des Stammservers nicht
202
Feld Wert Beschreibung
die lokale Routinggruppe ist, muss die Nachricht mit einem Routinggruppenconnector an das Ziel übertragen werden. Connectors, die Nachrichten an eine Routinggruppe übertragen können, müssen über einen Routinggruppen-Adressraum verfügen, der die GUID der Zielgruppe beinhaltet. Daher kann das Routingmodul eine Topologieansicht erstellen, die alle möglichen Übertragungspfade enthält, beginnend mit der Quelle bis hin zu sämtlichen möglichen Zielen in der Exchange-Organisation. Anhand der GUID der Routinggruppe des Empfängers kann das Routingmodul das endgültige Ziel der Nachricht in der Exchange-Organisation finden und dann den nächsten Hop auf dem kürzesten Weg
203
Feld Wert Beschreibung
zu diesem Ziel an das erweiterte Warteschlangenmodul zurückgeben. Dieser Vorgang wird weiter unten in diesem Abschnitt ausführlich beschrieben.
Kosten Kostenwerte sind Adressräumen zugeordnet. Anhand dieser Werte wird ermittelt, welcher Connector für die Nachrichtenübertragung zu bevorzugen ist. Der Wert kann im Bereich von 1 bis 100 liegen. Wenn für ein Ziel mehrere Connectors vorhanden sind, wird der Connector mit dem niedrigsten Kostenwert bevorzugt. Wenn mehreren Connectors der gleiche Kostenwert zugeordnet ist, wählt das Routingmodul einen zufälligen Connector aus und bietet so eine einfache Form von Lastenausgleich.
Quellbridgeheadserver BH () Im Feld BH werden die lokalen Bridgeheadserver für den Connector sowie deren Statusinformationen aufgeführt. Bridgeheadserver werden
204
Feld Wert Beschreibung
anhand der folgenden drei Angaben identifiziert:
Bridgeheadserver-objectGUID Die GUID eines virtuellen SMTP-Servers, der in der Connectorkonfiguration als lokaler Bridgeheadserver angegeben ist.
Bridgeheadserverstatus Informationen zur Angabe der Verfügbarkeit des Bridgeheadservers:
CONN_AVAIL Der Bridgeheadserver ist verfügbar.
VS_NOT_STARTED Ein virtueller SMTP-Server wurde beendet oder nicht gestartet.
CONN_NOT_AVAIL Die Verbindung steht auf dem Bridgeheadserver nicht zur Verfügung. Beispielsweise kann der Quellbridgeheadserver keine Verbindung zu einem Zielbridgeheadserver herstellen.
FQDN des virtuellen Servers Der FQDN des virtuellen Servers, der
205
Feld Wert Beschreibung
Zielbridgeheadserver TARGBH
( 766a192b43bfc3459ee85608
d65a98a9 CONN_AVAIL
{19}server01.TailspinToys.
com )
Die Liste TARGBH () enthält analog zur Liste BH () die Zielbridgeheadserver für einen Connector. Diese Liste ist insbesondere für Routinggruppenconnectors wichtig, denen mehrere Remotebridgeheadserver zugeordnet sein können.
Im nachstehenden Beispiel wird der Remotebridgeheadserver durch folgende Informationen identifiziert:
Bridgeheadserver-objectGUID 766a192b43bfc3459ee85608d65a98a9
Bridgeheadserverstatus CONN_AVAIL
FQDN des virtuellen Servers {19}server01.TailspinToys.com
Status STATE UP Der Connectorstatus. Dieses Feld kann zwei verschiedene Werte enthalten:
STATE UP Gibt an, dass der Connector verfügbar ist.
STATE DOWN Gibt an, dass der Connector nicht verfügbar ist.
Der Connectorstatus wird vom Status der Quellbridgeheadserver des Connectors abgeleitet. Ein
206
Feld Wert Beschreibung
Connector befindet sich nur dann im Zustand STATE UP, wenn mindestens ein Quellbridgeheadserver verfügbar ist (CONN_AVAIL). Wenn kein virtueller Quellbridgeheadserver des Connectors gestartet wurde (VS_NOT_STARTED) oder die Quellbridgeheadserver keine Verbindung herstellen können (CONN_NOT_AVAIL), gilt der Connectorstatus STATE DOWN.
Hinweis: Ein Connector wird nur dann als inaktiv (STATE DOWN) gekennzeichnet, wenn kein lokaler Bridgeheadserver für diesen Connector verfügbar ist. Routinggruppenconnectors, die zur Verwendung der Option Jeder lokale Server kann E-Mail über diesen Connector senden konfiguriert wurden, sowie SMTP-Connectors mit DNS-Routing und MAPI-basierte Connectors werden niemals als inaktiv gekennzeichnet. Routinggruppenconnectors, bei denen ein
207
Hinweis: Das Tool WinRoute bietet eine intuitive Ansicht der Routingtopologie und der Verbindungsstatustabelle. Dabei werden die GUIDs in der Verbindungsstatustabelle zu Namen in einem lesbaren Format aufgelöst, wenn das Tool Zugriff auf Active Directory hat. Im oberen Bereich des Programmfensters von WinRoute werden die umgewandelten Daten und im mittleren Bereich alle vorhandenen Adressräume angezeigt. Der untere Bereich enthält die unverarbeiteten Informationen aus der Verbindungsstatustabelle. Weitere Informationen über das Tool WinRoute finden Sie im Downloadbereich für Tools unter den Tools für Exchange Server 2003 .
Exchange-RoutingpfadauswahlIn einer Organisation mit mehreren Routinggruppen können unter Umständen verschiedene Pfade zum gleichen Ziel führen. In der Regel wird die effizienteste (d. h. die kürzeste oder kostengünstigste) Route für die Nachrichtenübertragung verwendet. Sollte die beste Route vorübergehend nicht zur Verfügung stehen, können zusätzliche, als Reserve bereitstehende Routen verwendet werden. Beispielsweise sind in der in der folgenden Abbildung dargestellten Topologie zwischen allen Routinggruppen mehrere Übertragungsrouten vorhanden.
208
Routingtopologie mit fünf Routinggruppen
Hinweis: Das Nachrichtenrouting sollte sich nach der physischen Netzwerktopologie richten. Wenn die zugrunde liegende Netzwerktopologie als eine echte Hub-and-Spoke-Anordnung (mit Routinggruppe A als Hub) konzipiert wurde, ist es kaum sinnvoll, die Routinggruppenconnectors wie in oben stehender Abbildung zu definieren. Stattdessen sollten die Routinggruppen B, C, D und E direkt mit der Routinggruppe A verbunden und die gesamte Nachrichtenübertragung zwischen verschiedenen Routinggruppen über die Routinggruppe A geleitet werden. In einer echten Hub-and-Spoke-Anordnung gibt es keine alternativen Nachrichtenpfade, und die Auswahl des Routingpfads erfolgt auf direktem Weg. Bei den Ausführungen in diesem Abschnitt wird jedoch davon ausgegangen, dass es sich bei der physischen Netzwerktopologie um ein Netz handelt, das der dargestellten Anordnung der Routinggruppenconnectors entspricht.
209
Das Routingmodul verwendet zur Bestimmung der besten Route die folgenden Informationen:
Adressraum Bei der Konfiguration von Routinggruppenconnectors werden auf der Registerkarte Verbundene Routinggruppen in den Connectoreigenschaften mögliche Ziele mit Messagingconnectors verknüpft. Der Routinggruppenconnector stellt jedoch diese Registerkarte nicht zur Verfügung. Da dieser Connector nur zur Verbindung mit Routinggruppen verwendet wird, kann das Routingmodul die Routinggruppen-Adressräume aus der Connectorkonfiguration ermitteln.
Routinggruppen-GUIDs und Routinggruppen-Adressräume
Adressräume können einem Connector über die Registerkarte Adressraum hinzugefügt werden. Wie in der Tabelle „Informationen in der Verbindungsstatustabelle“ angegeben, bestehen Adressräume aus einem Adresstyp (z. B. RG, SMTP, X400, MSMAIL oder CCMAIL), einer Adresse und einem Kostenwert. Der Kostenwert, den Sie einem
210
Adressraum zuweisen, stellt ein wichtiges Routingkriterium dar. Das Routingmodul trifft Routingentscheidungen mithilfe des Dijkstra-Algorithmus des kürzesten Weges. Dieser Algorithmus basiert auf Kostenwerten.
Connectorbereich Connectors zu externen Messagingsystemen können auf die Routinggruppe eines Connectors beschränkt werden, sodass die Verwendung des Connectors nur Benutzern in der lokalen Routinggruppe des Connectors gestattet wird. Standardmäßig ist für alle Connectors der Bereich Gesamte Organisation festgelegt.
Hinweis: Routinggruppenconnectors sind stets in der gesamten Organisation verfügbar.
Einschränkungen Das Routingmodul bestimmt die Nachrichtengröße, die Priorität und den Nachrichtentyp (d. h. Systemnachricht oder nicht vom System stammende Nachricht). Das Routingmodul vergleicht diese Eigenschaften mit den verfügbaren Informationen über Connectoreinschränkungen. Anschließend werden die Connectors, die diese Nachricht aufgrund wirksamer Connectoreinschränkungen nicht übertragen können, aus der Liste der potenziellen Connectors ausgeschlossen.
Status Nur verfügbare Connectors werden in den Prozess zur Routenauswahl aufgenommen. Im Statusfeld jedes Connectors ist angegeben, ob der Connector verfügbar (STATE UP) oder nicht verfügbar (STATE DOWN) ist.
Auswahl des RoutingpfadsZur Auswahl der besten Route zum Ziel berechnet das Routingmodul unter Verwendung des Dijkstra-Algorithmus des kürzesten Weges den kürzesten Übertragungsweg durch die Exchange-Organisation von der Quellroutinggruppe zur Zielroutinggruppe. Das Routingmodul bestimmt anschließend den nächsten Hop auf der kürzesten Route, die vom erweiterten Warteschlangenmodul für die Nachrichtenübertragung verwendet werden soll.
Die Auswahl des Routingpfads ist ein zweistufiger Vorgang:
1. Das erweiterte Warteschlangenmodul ruft in der IMessageRouter-Schnittstelle des Routingmoduls die GetMessageType-Methode auf. In der GetMessageType-Methode übergibt das erweiterte Warteschlangenmodul die Nachricht in Form eines MailMsg-Objekts an das Routingmodul.
Für diesen Schritt führt das Routingmodul die folgenden Vorgänge aus:
a. Das Routingmodul überprüft Nachrichtenverfolgungsinformationen, um Schleifen zu erkennen. Falls eine Nachrichtenschleife erkannt wird, löscht das Routingmodul diese Nachricht und sendet einen Unzustellbarkeitsbericht an den Absender.
b. Die aktuelle Organisationstopologie wird gelesen oder bei Bedarf neu berechnet (d. h. die Liste der kürzesten Routen zu allen Zielen in der Routingtopologie, beginnend bei der lokalen Routinggruppe, wird ermittelt).
211
c. Die Informationen über Einschränkungen bezüglich der Connectors in der Verbindungsstatustabelle werden überprüft und bei Bedarf aktualisiert.
d. Das Routingmodul bestimmt alle Connectors zum Nachrichtenziel in der Organisationstopologie und analysiert dann die Nachrichtenmerkmale und Connectoreinschränkungen, um alle Connectors auszuschließen, die nicht zur Übertragung der Nachricht verwendet werden dürfen.
e. Für die Nachricht wird ein Filterwert berechnet, der den Nachrichtentyp eindeutig definiert. Der Nachrichtentyp identifiziert den tatsächlichen Pfad, den Nachrichten mit ähnlichen Merkmalen verwenden können. Der Nachrichtentyp wird zwischengespeichert. Daher muss der Filterwert für darauf folgende Nachrichten mit ähnlichen Merkmalen nicht erneut durch das Routingmodul berechnet werden.
Hinweis: Das erweiterte Warteschlangenmodul verwaltet für jeden Nachrichtentyp jeweils eine gesonderte Nachrichtenwarteschlange.
f. Anschließend werden zugeordnete Nachrichtentypen erstellt. Ein zugeordneter Nachrichtentyp ähnelt dem tatsächlichen Nachrichtentyp, wird jedoch mit geringeren Einschränkungen berechnet. Zugeordnete Nachrichtentypen ermöglichen dem SMTP-Transportsubsystem die Rückgabe erweiterter Fehlercodes, wenn ein Übertragungspfad für den tatsächlichen Nachrichtentyp aufgrund von Connectoreinschränkungen nicht verfügbar sein sollte.
g. Der Index des zwischengespeicherten Nachrichtentyps wird an das erweiterte Warteschlangenmodul zurückgegeben.
2. Das Routingmodul ermittelt den nächsten Hop auf der kürzesten Route. Zum Abschließen dieses Schritts ruft das erweiterte Warteschlangenmodul in der IMessageRouter-Schnittstelle die GetMessageType-Methode auf. Die wichtigsten Informationen, die das erweiterte Warteschlangenmodul zu diesem Zeitpunkt an das Routingmodul übergibt, sind die Zieladresse und die Nachrichtentyp-ID. Die Zieladresse für Empfänger in der Exchange-Organisation ist der FQDN des Stammservers des Empfängers. Das Routingmodul ermittelt die Zielroutinggruppe aus dem Servercache, überprüft die verfügbare Route für den Nachrichtentyp und gibt den nächsten Hop in der Route zur Zielroutinggruppe an das erweiterte Warteschlangenmodul zurück. Das erweiterte Warteschlangenmodul kann die Nachricht dann an den nächsten Hop auf dem Weg zum Ziel übertragen.
Dijkstra-Algorithmus des kürzesten WegesDamit das Routingmodul richtige Routingentscheidungen treffen kann, muss es die kürzeste Route zu allen möglichen Zielen in der Routingtopologie kennen. Das Routingmodul muss die kürzesten Routen aus allen verfügbaren Übertragungsrouten zu allen Zielen in einer
212
komplexen Routingtopologie suchen. Dieses Problem wird auch als „Problem der kürzesten Weges von einem Ausgangspunkt“ bezeichnet.
In der folgenden Abbildung wird veranschaulicht, dass sogar in einer relativ einfachen Routingtopologie zahlreiche Routen von einer Routinggruppe zu jeder anderen Routinggruppe führen können. In der Abbildung werden die Routinggruppenconnectors aus Abbildung 5.4 in vereinfachter Form mit dem standardmäßigen Kostenwert 1 dargestellt.
Routinggruppenconnectors mit Standardkostenwerten
Im Jahr 1959 wurde das Problem des kürzesten Weges von einem Ausgangspunkt durch Professor Edsger Dijkstra gelöst. Professor Dijkstra entwickelte einen Algorithmus, mit dem die kürzesten Wege von einem gegebenen Ausgangspunkt zu allen Punkten in einer Topologie mittels einer einzigen Berechnung ermittelt werden können.
Das Routingmodul verwendet den Dijkstra-Algorithmus wie folgt:
1. Es wird davon ausgegangen, dass die Routingtopologie alle Pfade von einer Routinggruppe zu allen anderen Routinggruppen in einer umfassenden Struktur abbildet. Daraus ergibt sich, dass die Topologie alle Routinggruppen und Routinggruppenconnectors enthalten muss und dass zwischen Routinggruppen keine Schleifen bestehen dürfen. Daher sind Pfade in der Routingtopologie, auf denen eine Nachricht zur Quellroutinggruppe zurückkehren kann, unzulässige Übertragungspfade und werden nicht in die Berechnung einbezogen.
213
2. Auf Grundlage des Algorithmus von Dijkstra verwaltet das Routingmodul zwei Sätze von Routinggruppen. Der erste Satz enthält alle Gruppen, für die der kürzeste Pfad von der Quellroutinggruppe aus bereits bestimmt wurde. Der zweite Satz umfasst alle übrigen Routinggruppen. Zunächst ist der Satz der Routinggruppen, für die die kürzesten Pfade von der Quellroutinggruppe aus bereits bestimmt wurde, noch leer. Solange noch Routinggruppen vorhanden sind, die noch nicht verarbeitet wurden, führt das Routingmodul die Schritte 3 bis 6 wie folgt aus.
3. Das Routingmodul sortiert die verbleibenden Routinggruppen nach der aktuellen besten Schätzung der Entfernung (d. h. die Summe der Kostenwerte) zur Quellroutinggruppe.
4. Anschließend wird die am nächsten liegende Routinggruppe zum Satz der Routinggruppen hinzugefügt, deren kürzeste Pfade bereits bestimmt wurden.
5. Das Routingmodul aktualisiert dann die Kosten aller mit dieser Routinggruppe verbundenen Routinggruppen (falls sich dadurch die beste Schätzung des kürzesten Pfads für jede der restlichen Routinggruppen verbessert), indem der Kostenwert des Connectors zwischen diesen Routinggruppen in den Entfernungswert einbezogen wird.
6. Für alle aktualisierten Routinggruppen wird dann auch der Vorgänger aktualisiert. Durch die Liste der Vorgänger wird schließlich der kürzeste Pfad von jeder Routinggruppe zur Zielroutinggruppe definiert.
Im folgenden Schritt wird veranschaulicht, wie das Routingmodul den kürzesten Pfad von der Routinggruppe A zu allen anderen Routinggruppen in der Routingtopologie ermittelt:
1. Die Quelle ist Routinggruppe A. Aus diesem Grund beginnt die Berechnung bei Routinggruppe A. Der Entfernungswert der Routinggruppe A zu sich selbst ist gleich null. Der Entfernungswert aller anderen Routinggruppen wurde noch nicht ermittelt.
2. Routinggruppe A wird zum Satz der Routinggruppen hinzugefügt, deren kürzeste Pfade von der Quellroutinggruppe aus bereits bestimmt wurden. Anschließend wird der Entfernungswert aller Routinggruppe A benachbarten Routinggruppen mit den Kostenwerten der entsprechenden Connectors aktualisiert. Der Vorgänger (Ausgangspunkt der schwarzen Pfeile) dieser Routinggruppen wird dann aktualisiert. Der Vorgänger ist Routinggruppe A.
3. Das Routingmodul sortiert die restlichen Routinggruppen nach der aktuellen besten Schätzung der jeweiligen Entfernung zur Quellroutinggruppe. Die am nächsten liegende Routinggruppe wird zum Satz der Routinggruppen hinzugefügt, deren kürzeste Pfade bereits bestimmt wurden. Da der Entfernungswert für die Routinggruppen B und C jeweils gleich ist, wählt das Routingmodul eine Routinggruppe nach dem Zufallsprinzip aus. In diesem Beispiel wird angenommen, dass Routinggruppe B ausgewählt wird.
4. Das Routingmodul berechnet den Entfernungswert aller übrigen Routinggruppe B benachbarten Routinggruppen, indem der Kostenwert des Connectors zwischen Routinggruppe B und der benachbarten Routinggruppe mit dem Entfernungswert von Routinggruppe B kombiniert wird. Der Entfernungswert einer benachbarten
214
Routinggruppe wird nur dann aktualisiert, wenn der berechnete Entfernungswert kleiner als der Wert ist, der dieser Routinggruppe bereits zugeordnet ist. Nur in diesem Fall wird auch der Vorgänger aktualisiert (durch schwarze Pfeile gekennzeichnet).
Die Nachbarn von Routinggruppe B sind die Routinggruppen C, D und E. Der aktuelle Entfernungswert der Routinggruppen C und D ist nicht definiert. Daher wird der Entfernungswert dieser Routinggruppen durch die Kostenwerte der entsprechenden Connectors aktualisiert, zuzüglich des Entfernungswerts der Routinggruppe B (1+1). Dann wird der Vorgänger (Ausgangspunkt der schwarzen Pfeile) dieser Routinggruppen aktualisiert. Der Vorgänger ist Routinggruppe B.
Routinggruppe C wird nicht aktualisiert, da die Summe aus dem Entfernungswert von Routinggruppe C und dem Connectorkostenwert (1+1) größer ist als der aktuelle Entfernungswert von Routinggruppe C.
5. Das Routingmodul sortiert die restlichen Routinggruppen nach der aktuellen besten Schätzung der Entfernung zur Quellroutinggruppe und fügt die am nächsten liegende Routinggruppe zum Satz der Routinggruppen hinzu, deren kürzeste Pfade bereits ermittelt wurden. Der Algorithmus wählt nun Routinggruppe C aus, da dieser Routinggruppe der kleinste Entfernungswert zugeordnet ist.
6. Das Routingmodul berechnet den Entfernungswert aller übrigen Routinggruppe C benachbarten Routinggruppen, indem der Kostenwert des Connectors zwischen Routinggruppe C und den benachbarten Routinggruppen mit dem Entfernungswert von Routinggruppe C kombiniert wird. Der Entfernungswert einer benachbarten Routinggruppe wird nur dann aktualisiert, wenn der berechnete Entfernungswert kleiner als der Wert ist, der dieser Routinggruppe bereits zugeordnet ist. Nur in diesem Fall wird auch der Vorgänger aktualisiert (durch schwarze Pfeile gekennzeichnet).
Die übrigen als Nachbarn von Routinggruppe C geltenden Routinggruppen sind die Routinggruppen D und E (die Routinggruppen A und B wurden bereits verarbeitet).
Der aktuelle Entfernungswert der Routinggruppen D und E beträgt 2. Dieser Wert ist kleiner als die Summe der Connectorkosten und des Entfernungswerts der Routinggruppe C (1+2). Aus diesem Grund werden der Entfernungswert und die Vorgängerliste der Routinggruppen D und E nicht aktualisiert.
7. Das Routingmodul sortiert die restlichen Routinggruppen (Routinggruppe D und E) nach der aktuellen besten Schätzung ihrer Entfernung zur Quellroutinggruppe und fügt die am nächsten liegende Routinggruppe zum Satz der Routinggruppen hinzu, deren kürzeste Pfade bereits ermittelt wurden.
Da der Entfernungswert für die Routinggruppen D und E jeweils gleich ist, wählt das Routingmodul eine Routinggruppe nach dem Zufallsprinzip aus. In diesem Beispiel wird angenommen, dass Routinggruppe D ausgewählt wird.
Der einzige verbleibende Nachbar ist Routinggruppe E, deren aktueller Entfernungswert 2 beträgt. Dieser Wert ist kleiner als die Summe der Connectorkosten
215
und des Entfernungswerts von Routinggruppe D (1+2). Aus diesem Grund werden der Entfernungswert und die Vorgängerliste von Routinggruppe E nicht aktualisiert.
Routinggruppe E ist die letzte Routinggruppe, die noch nicht zur Liste der Routinggruppen hinzugefügt wurde, deren kürzeste Pfade ermittelt wurden. Es sind keine benachbarten Routinggruppen mehr vorhanden. Die Berechnung des kürzesten Pfads ist somit abgeschlossen. Die kürzesten Pfade von Routinggruppe A zu jeder anderen Routinggruppe in der Topologie wurden ermittelt.
Lastenausgleich bei der NachrichtenübertragungWenn mehrere Pfade mit jeweils gleichen Kostenwerten vorhanden sind, wählt das Routingmodul – wie im vorhergehenden Schritt erläutert – einen Übertragungspfad nach dem Zufallsprinzip aus. Das Routingmodul führt jedoch keinen Lastenausgleich durch. Wie bereits an früherer Stelle erläutert, speichert das Routingmodul die Informationen zum Nachrichtentyp, die auf den kürzesten Pfad verweisen, auf dem eine Nachricht zum Ziel gelangen kann. Daher werden alle Nachrichten eines bestimmten Typs auf demselben Pfad übertragen, selbst wenn ein anderer Pfad mit dem gleichen Kostenwert vorhanden ist (z. B. „Routinggruppe A > Routinggruppe B > Routinggruppe E“ und „Routinggruppe A > Routinggruppe C > Routinggruppe E“).
Lastenausgleich zwischen RoutinggruppenEchter Lastenausgleich zwischen Routinggruppen kann nur mithilfe eines Routinggruppenconnectors mit mehreren Bridgeheadservern erzielt werden.
In der folgenden Tabelle werden die Lastenausgleichskonfigurationen aufgeführt, die zwischen Routinggruppen verwendet werden können.
216
Mögliche Konfigurationen zwischen Routinggruppen
Mögliche Konfiguration Beschreibung
Ein einzelner Routinggruppenconnector mit mehreren Quell- und/oder Zielbridgeheadservern.
Bei diesen Connectortypen gibt das Routingmodul in den Informationen zum nächsten Hop die Connector-GUID für das erweiterte Warteschlangenmodul zurück. Das erweiterte Warteschlangenmodul wählt dann nach dem Zufallsprinzip den zu verwendenden Bridgeheadserver aus und führt so einen Lastenausgleich für die Nachrichtenübertragung über alle Bridgeheadserver aus.
Bei Eingang einer Nachricht auf einem Quellbridgeheadserver eines Routinggruppenconnectors mit mehreren Quellbridgeheadservern wird diese Nachricht nicht an einen anderen Quellbridgeheadserver umgeleitet. Nach Eingang der Nachricht beim Routinggruppenconnector erfolgt eine direkte Nachrichtenübertragung an die Zielroutinggruppe. Daher verwenden Benutzer, die Postfächer auf dem Bridgeheadserver besitzen, stets den lokalen Server für die Nachrichtenübertragung an die Zielroutinggruppe.
Hinweis: Es wird empfohlen, mehrere Quell- und Zielbridgeheadserver für einen einzelnen Routinggruppenconnector zwischen zwei Routinggruppen anzugeben. Auf diese Weise wird der Lastenausgleich und die Redundanz verbessert.
217
Mögliche Konfiguration Beschreibung
Mehrere Connectors mit demselben Adressraum (oder derselben verbundenen Routinggruppe) und derselben Gewichtung (Kosten), wobei für jeden Connector ein Quell- und ein Zielbridgeheadserver vorhanden ist
Bei diesem Konfigurationstyp wird kein echter Lastenausgleich erreicht. Der Lastenausgleich beschränkt sich auf die anfängliche Auswahl eines Connectors für einen angegebenen Nachrichtentyp. Durch das Routingmodul wird der Nachrichtentyp einmalig bestimmt und zwischengespeichert. Anschließend werden alle Nachrichten desselben Typs über diesen Connector geleitet. Der zweite Connector wird nur bei Ausfall des ersten Connectors verwendet. Ein zweiter Server kann jedoch unter Umständen den zweiten Connector auswählen und auf diese Weise einen gewissen Lastenausgleich erzielen.
Hinweis: Ein Lastenausgleich mit mehreren Connectorinstanzen zwischen den Routinggruppen ist nicht sinnvoll, da auf diese Weise kein echter Lastenausgleich erzielt werden kann.
Mehrere Connectors mit demselben Adressraum (oder derselben verbundenen Routinggruppe) und unterschiedlicher Gewichtung (Kosten), wobei für jeden Connector ein Quell- und ein Zielbridgeheadserver vorhanden ist
Wenn Connectors für einen automatischen Failover konfiguriert werden sollen, können Sie auf verschiedenen Bridgeheadservern zwei getrennte Connectors mit unterschiedlichen Kosten erstellen. Der Verbindungsstatus eines Connectors wird durch den zugehörigen lokalen Bridgeheadserver festgelegt. Wenn der Bridgeheadserver des bevorzugten Connectors mit den niedrigsten Kosten nicht verfügbar ist, wird dieser Connector beim Routing als nicht verfügbar betrachtet und der zweite Connector gewählt. Ist der Bridgeheadserver des Connectors mit den niedrigsten Kosten wieder verfügbar, wird dieser von den Servercomputern mit Exchange erneut verwendet.
218
Lastenausgleich zwischen Connectors und externen SystemenAbhängig vom jeweiligen Szenario kann der Lastenausgleich über mehrere SMTP-Connectors hinweg auf verschiedene Weise erzielt werden.
Wenn Sie Lastenausgleich für ausgehende Anforderungen in der sendenden Organisation über mehrere Server hinweg durchführen möchten, konfigurieren Sie mehrere Quellbridgeheadserver.
Wenn Sie den Lastenausgleich des Datenverkehrs über mehrere Zielserver hinweg durchführen möchten, muss der Zieladministrator DNS (mithilfe einer geeigneten Konfiguration von MX- und A-Datensätzen) ordnungsgemäß konfigurieren, oder Sie geben mehrere Smarthostadressen für den Connector an.
Wenn Sie Failoverflexibilität sicherstellen möchten, können Sie auch mehrere SMTP-Connectors erstellen, die für den gleichen Adressraum gültig sind, jedoch unterschiedliche Kostenwerte und Bridgeheadserver besitzen. Wenn der Bridgeheadserver des bevorzugten Connectors mit den niedrigsten Kosten nicht verfügbar ist, wird der Connector beim Routing als nicht verfügbar bewertet und der zweite Connector gewählt. Wenn Sie zwei Connectors mit den gleichen Kostenwerten verwenden, wählen die Servercomputer mit Exchange nach dem Zufallsprinzip aus, welcher Bridgeheadserver und Connector verwendet wird. Wenn dann dieser Bridgeheadserver nicht mehr verfügbar ist, wird ein Failover auf den zweiten Connector durchgeführt. Wird jedoch der erste Bridgeheadserver erneut verfügbar, erfolgt kein Failover auf diesen Server, da diese Route dieselben Kosten aufweist wie die bereits verwendete.
Bei der Connectorkonfiguration in der folgenden Abbildung handelt es sich beispielsweise nicht um eine Lastenausgleichskonfiguration für Failover, da die Adressräume nicht übereinstimmen. An externe Benutzer in einer .NET-Domäne gesendete Nachrichten durchlaufen immer den SMTP-Connector mit dem .NET-Adressraum. Der Grund hierfür ist, dass das Routingmodul vor einer Bewertung der Kosten den detailliertesten, d. h. die am genauesten bestimmte Adresse auswählt.
219
Connectorkonfiguration ohne Lastenausgleich oder Fehlertoleranz
Hinweis: Wenn für den Connector mit dem .NET-Adressraum Einschränkungen festgelegt wurden und diese Einschränkungen verhindern, dass bestimmte Nachrichten diesen Connector durchlaufen (z. B. weil dem Absender die Nachrichtenübertragung über diesen Connector verweigert wird), gibt das Routingmodul die Nachricht mit einem Unzustellbarkeitsbericht an den Absender zurück. Das Routingmodul wechselt nicht zum zweiten Connector, um diese Nachrichten zu senden. Durch den detailliertesten Adressraum wird festgelegt, welche Connectors zur Übertragung einer Nachricht verwendet werden können. Connectors mit einem Adressraum, der weniger genau bestimmt ist, werden aus der Routenberechnung ausgeschlossen.
Erneutes Routing von Nachrichten anhand von VerbindungsstatusinformationenWenn Nachrichten von einem Connector nicht übertragen werden können, informiert das erweiterte Warteschlangenmodul das Routingmodul über einen Verbindungsfehler. Dies kann unter Umständen dazu führen, dass das Routingmodul den Connector als nicht verfügbar kennzeichnet und alle in der Warteschlange befindlichen Nachrichten umgeleitet werden.
Ein Connector wird vom Routingmodul als nicht verfügbar eingestuft, wenn eine der folgenden Bedingungen zutrifft:
Das Routingmodul kann mit mindestens einem Quellbridgeheadserver des Connectors keine Verbindung herstellen, und es besteht keine TCP/IP-Verbindung mit Anschluss 691 zwischen dem Routinggruppenmaster und den Quellbridgeheadservern. Nicht verfügbare Quellbridgeheadserver werden in der Verbindungsstatustabelle durch den Eintrag VS_NOT_STARTED gekennzeichnet.
220
Kein Quellbridgeheadserver kann die Nachricht erfolgreich an einen Zielbridgeheadserver übertragen. Quellbridgeheadserver, die keine Nachrichten an das Ziel übertragen können, werden mit CONN_NOT_AVAIL gekennzeichnet.
Hinweis: Wenn Sie X.400-Connectors verwenden und der Connector keine Nachrichten übertragen kann, informiert der Exchange-MTA das Routingmodul darüber, dass ein Verbindungsfehler aufgetreten ist. In diesem Fall erhält der Quellbridgeheadserver den Status CONN_NOT_AVAIL. X.400-Connectors können nur mit jeweils einem Quellbridgeheadserver verbunden sein.
Erneutes Routing von NachrichtenZur Gewährleistung einer effizienten Nachrichtenübertragung informiert das Routingmodul das erweiterte Warteschlangenmodul und den Exchange-MTA sofort über alle Verbindungsstatusänderungen. Damit Nachrichten nicht über unterbrochene Übertragungspfade gesendet werden, müssen alle in der Warteschlange befindlichen Nachrichten umgeleitet werden. Dieser Vorgang wird als erneutes Routing bezeichnet. Beim erneuten Routing löscht das erweiterte Warteschlangenmodul alle zwischengespeicherten Informationen über den nächsten Hop, da diese nicht mehr gültig sind. Alle Nachrichten, die gegenwärtig zur Übertragung anstehen, werden erneut an das Routingmodul übergeben, das den nächsten Hop erneut berechnet. Dies kann eine ressourcenintensive Aufgabe sein.
In der folgenden Abbildung wird als Beispiel ein erneuter Routingvorgang veranschaulicht, bei dem der Bridgeheadserver in Routinggruppe E nicht verfügbar ist. Es können derzeit keine Nachrichten an diese Routinggruppe übertragen werden. Bei der Neuberechnung der kürzesten Pfade zu den Empfängern in Routinggruppe E erkennt das Routingmodul, dass kein Pfad verfügbar ist. Connectors, die als nicht verfügbar gekennzeichnet sind, werden vom Routingvorgang ausgeschlossen. Aus diesem Grund ist die Routinggruppe E derzeit isoliert.
221
Unterbrochene Verbindung zwischen Routinggruppenconnectors
Da keine gültigen Pfade vorhanden sind, kann das Routingmodul keinen gültigen nächsten Hop für Nachrichten ermitteln, die zur Übertragung an die Routinggruppe E anstehen. Das Routingmodul informiert das erweiterte Warteschlangenmodul in den Informationen über den nächsten Hop darüber, dass der nächste Hop nicht erreichbar ist. Das erweiterte Warteschlangenmodul muss die Nachricht solange speichern, bis mindestens wieder ein Übertragungspfad verfügbar ist oder bis die Nachricht abläuft und mit einem Unzustellbarkeitsbericht an den Absender zurückgesendet wird.
Hinweis: Wenn nur ein Connector zu einer Routinggruppe vorhanden ist und keine alternativen Pfade vorhanden sind, wird der Verbindungsstatus immer als verfügbar gekennzeichnet, um die Anzahl der Verbindungsstatusänderungen in der Routingtopologie zu verringern. Die Nachrichten werden von Exchange Server 2003 in eine Warteschlange gestellt und gesendet, sobald die Route wieder zur Verfügung steht.
Erneutes Routing und AdressräumeIn Exchange Server 2003 kann (analog zum Lastenausgleich) ein erneutes Routing von Nachrichten nur über Connectors ausgeführt werden, die denselben Adressraum besitzen. Beispielsweise können Sie zwei separate Connectors auf verschiedenen Bridgeheadservern einrichten, wobei beiden Connectors jeweils derselbe Adressraum, jedoch unterschiedliche
222
Kostenwerte zugeordnet sind. Wenn der bevorzugte Connector ausfällt, wählt das Routingmodul automatisch den zweiten Connector aus, bis der primäre Connector wieder zur Verfügung steht.
Hinweis: Das Routingmodul leitet Nachrichten von einem Connector mit einem genau bestimmten Adressraum nicht an einen Connector mit einem weniger genau bestimmten Adressraum um, da das Routingmodul diesen als ein anderes Ziel betrachtet. Die Nachrichten verbleiben daher auf dem Quellbridgeheadserver, bis der Connector mit dem genau bestimmten Adressraum wieder verfügbar ist.
Wenn für den Connector mit dem .NET-Adressraum Einschränkungen festgelegt wurden und diese Einschränkungen verhindern, dass bestimmte Nachrichten diesen Connector durchlaufen – z. B. weil dem Absender die Nachrichtenübertragung über diesen Connector verweigert wird –, gibt das Routingmodul die Nachricht mit einem Unzustellbarkeitsbericht an den Absender zurück. Das Routingmodul wechselt nicht zum zweiten Connector, um diese Nachrichten zu senden. Durch den detailliertesten Adressraum wird festgelegt, welche Connectors für die Übertragung einer Nachricht verwendet werden können. Connectors mit einem Adressraum, der weniger genau bestimmt ist, werden aus der Routenberechnung ausgeschlossen.
ConnectorwiederherstellungDas Routingmodul ermittelt nach einer der folgenden Methoden, ob ein Connector wieder zur Verfügung steht:
VS_NOT_STARTED Der Routinggruppenmaster stellt eine Verbindung mit TCP-Anschluss 691 auf dem Quellbridgeheadserver her. Der Quellbridgeheadserver wird mit dem Status CONN_AVAIL gekennzeichnet. Da mindestens ein Quellbridgeheadserver für den Connector verfügbar ist, wechselt der Connectorstatus zu STATE UP.
CONN_NOT_AVAIL Bei nicht verfügbaren Connectors erfolgt durch die Quellbridgeheadserver alle 60 Sekunden ein erneuter Versuch zum Herstellen einer Verbindung, selbst wenn keine Nachrichten zur Übertragung anstehen. Nachdem eine Verbindung hergestellt wurde, meldet das erweiterte Warteschlangenmodul oder der Exchange-MTA eine erfolgreich hergestellte ausgehende Verbindung vom Quellbridgeheadserver an das Routingmodul. Das Routingmodul ändert daraufhin den Status des Quellbridgeheadservers in CONN_AVAIL und den Connectorstatus in STATE UP.
223
Erneutes Routing und AktivierungszeitpläneBei allen Connectortypen kann ein Zeitplan für den Connector konfiguriert werden, mit dem sich E-Mail-Nachrichten jeweils zu bestimmten Zeiten übertragen lassen. Connectors können wahlweise so konfiguriert werden, dass sie stets aktiv sind, nur zu bestimmten Zeitpunkten aktiviert werden oder niemals aktiv sind. Im letzten Fall werden keine Nachrichten über den Connector übertragen, bis der Connectorzeitplan erneut geändert wird. Sie können einen Connector auch mit Remote eingeleitet konfigurieren, sodass der Connector selbst keine Verbindung initiiert. Stattdessen wartet der Connector, bis ein Remoteserver die Verbindung herstellt und die Nachrichtenübertragung startet.
Der Connectorzeitplan betrifft lediglich die Nachrichtenübertragung. Er hat keinen Einfluss auf das Routing der Nachrichten. Connectors mit einem beliebigen Zeitplantyp werden vom Routingmodul als verfügbar betrachtet, wenn für diese Connectors der Status STATE UP angegeben wird. Daher können Nachrichten unter Umständen auch an Connectors geleitet werden, deren Aktivierungszeitplan auf Nie festgelegt wurde. Für diese Connectors werden jedoch keine Verbindungsstatusänderungen und kein erneutes Routing ausgeführt. Die Nachrichten verbleiben dann in der Warteschlange des Connectors, bis der Aktivierungszeitplan geändert wird. Dies gilt auch für remote eingeleitete Connectors. Nachrichten werden nicht erneut geroutet, während sie auf das Abrufen warten.
Tipp: Wenn Sie das Nachrichtenrouting an einen Connector verhindern möchten, legen Sie die maximale Nachrichtengröße auf 1 KB fest.
VerbindungsstatusweitergabeZur Gewährleistung eines effizienten und zuverlässigen Nachrichtenroutings muss die Verbindungsstatustabelle eines Exchange-Servers stets aktuelle Informationen enthalten. Diese Informationen müssen der Zustand aller Bridgeheadserver und Messagingconnectors genau wiedergeben. Zur Weitergabe von Verbindungsstatusinformationen an alle Server in einer Exchange-Organisation wird ein Übermittlungsprotokoll verwendet, das als Verbindungsstatusalgorithmus (LSA, Link State Algorithm) bezeichnet wird.
Die Weitergabe von Verbindungsstatusinformationen an alle Server hat folgende Vorteile:
Jeder Exchange-Server kann die optimale Nachrichtenroute von der Quelle ermitteln, anstatt die Nachrichten auf einer Route zu senden, auf der kein Connector verfügbar ist.
Nachrichten werden nicht zwischen Servern hin- und hergesendet, da jeder Exchange-Server feststellen kann, ob andere oder redundante Verbindungen verfügbar sind.
Nachrichtenschleifen treten nicht mehr auf.
224
VerbindungsstatusalgorithmusDie Weitergabe von Verbindungsstatusinformationen erfolgt innerhalb von Routinggruppen und zwischen Routinggruppen unterschiedlich. Innerhalb von Routinggruppen wird eine zuverlässige TCP/IP-Verbindung vorausgesetzt. Die Server kommunizieren daher über direkte TCP/IP-Verbindungen miteinander. Zwischen verschiedenen Routinggruppe sind jedoch unter Umständen keine direkten TCP/IP-Verbindungen möglich. Aus diesem Grund werden Verbindungsstatusinformationen von Exchange Server 2003 zwischen Routinggruppen über SMTP oder X.400 weitergegeben.
Exchange Server 2003 übermittelt Verbindungsstatusinformationen folgendermaßen:
LSA innerhalb einer Routinggruppe Innerhalb einer Routinggruppe erfasst der Routinggruppenmaster die Verbindungsstatusinformation und übermittelt diese an die übrigen Server in der Routinggruppe. Die übrigen Server werden auch als Mitgliedsknoten oder Routinggruppenmitglieder bezeichnet. Wenn ein Mitgliedsknoten gestartet wurde und seine Routingtabelle mit Informationen aus Active Directory initialisiert hat, wird eine TCP/IP-Verbindung mit Anschluss 691 hergestellt. Anschließend authentifiziert sich der Mitgliedsknoten beim Routinggruppenmaster und bezieht aktuelle Informationen über den Status aller Verbindungen in der Routingtopologie. Alle Verbindungen innerhalb einer Routinggruppe erfordern eine bidirektionale Authentifizierung. Die Verbindung bleibt bestehen, sodass der Master und der untergeordnete Knoten bei jeder neuen Verbindungsstatusänderung miteinander kommunizieren können.
Master und untergeordneter Knoten in einer Routinggruppe
Innerhalb einer Routinggruppe aktualisiert Exchange Server 2003 Verbindungsstatusinformationen wie folgt:
a. Wenn das erweiterte Warteschlangenmodul oder der Exchange-MTA ein Problem mit einem Bridgeheadserver oder einem Routinggruppenconnector feststellen, wird das lokale Routingmodul informiert, wie in „Erneutes Routing von Nachrichten anhand von Verbindungsstatusinformationen“ unter Nachrichtenrouting unter Exchange Server 2003 erläutert.
225
b. Das lokale Routingmodul, das als Cacheproxy zwischen dem Routinggruppenmaster und dem erweiterten Warteschlangenmodul oder dem Exchange-MTA fungiert, leitet diese Verbindungsstatusinformation an den Routinggruppenmaster über eine entsprechende Verbindung an den TCP-Anschluss 691 weiter.
c. Nachdem der Routinggruppenmaster über eine Aktualisierung informiert wurde, wird die Verbindungsstatustabelle mit den neuen Informationen überschrieben. Auf Grundlage dieser neuen Informationen erstellt der Routinggruppenmaster einen neuen MD5-Hashwert, fügt diesen in die Verbindungsstatustabelle ein und übermittelt diese neuen Informationen an alle Server in der Routinggruppe. Die Kommunikation erfolgt über den TCP-Anschluss 691.
Hinweis: Ein MD5-Hashwert ist ein verschlüsselter Datenblock, der unter Verwendung eines Hashalgorithmus aus einer Nachricht abgeleitet wurde. Mit diesem Hashalgorithmus wird ein 128-Bit-Hashwert aus einer Liste von Blöcken mit 512 Bit generiert. Für eine Nachricht wird stets derselbe Hashwert erzeugt, wenn sie denselben Hashalgorithmus durchläuft. Für Nachrichten, die sich auch nur durch ein Zeichen unterscheiden, werden völlig verschiedene Hashwerte ausgegeben.
d. Der Routinggruppenmaster sendet die gesamte Verbindungsstatustabelle (d. h. ein OrgInfo-Paket) an jedes einzelne Routinggruppenmitglied. Jedes Routinggruppenmitglied vergleicht den MD5-Hashwert des neuen OrgInfo-Pakets mit dem MD5-Hashwert in der eigenen Verbindungsstatustabelle und ermittelt, ob der lokale Server über die neuesten Informationen verfügt.
e. Wenn die MD5-Hashwerte nicht übereinstimmen, wird das OrgInfo-Paket vom Routinggruppenmitglied verarbeitet. Nachdem die Verbindungsstatustabelle im Speicher ersetzt wurde, sendet das Routinggruppenmitglied eine kurze Antwort an den Routinggruppenmaster, in der auf den neuen MD5-Hashwert verwiesen wird.
f. Der Routinggruppenmaster verarbeitet diese Informationen, stellt fest, dass das Routinggruppenmitglied aktualisiert wurde, und sendet eine kurze Bestätigung an das Routinggruppenmitglied.
g. Anschließend fordert das Routinggruppenmitglied alle fünf Minuten aktuelle Routinginformationen vom Master an. Master und Mitgliedsknoten vergleichen ihre MD5-Hashwerte, um festzustellen, ob Änderungen aufgetreten sind.
Hinweis: Alle Server innerhalb einer Routinggruppe müssen über eine zuverlässige TCP/IP-Verbindung mit dem Routinggruppenmaster kommunizieren.
LSA zwischen verschiedenen Routinggruppen Verbindungsstatusinformationen werden auf indirekte Weise über Bridgeheadserver und Routinggruppenconnectors zwischen Routinggruppen übertragen. Zum Senden von Verbindungsstatusinformationen
226
an eine andere Routinggruppe überträgt der Routinggruppenmaster die Verbindungsstatusinformationen in Form eines Orginfo-Pakets, das an den Bridgeheadserver einer Routinggruppe über den TCP-Anschluss 691 gesendet wird. Der Bridgeheadserver leitet diese Informationen dann unter Verwendung der verschiedenen verfügbaren Routinggruppenconnectors an alle Bridgeheadserver in anderen Routinggruppen weiter, mit denen der Server verbunden ist.
Wenn die Kommunikation zwischen Routinggruppen SMTP-basiert ist (d. h. über Routinggruppenconnectors oder SMTP-Connectors erfolgt), werden vor der regulären Nachrichtenübertragung Verbindungsstatusinformationen mit dem erweiterten SMTP-Befehl X-LINK2STATE ausgetauscht, wie im Folgenden erläutert:
a. Der Quellbridgeheadserver stellt eine TCP/IP-Verbindung mit dem Zielbridgeheadserver über den TCP-Anschluss 25 her.
b. Die Bridgeheadserver authentifizieren sich gegenseitig mit dem Befehl X-EXPS GSS API.
c. Nach der Verbindungsherstellung und der Authentifizierung beginnt die Verbindungsstatuskommunikation mit dem Befehl X-LINK2STATE.
d. Zunächst vergleichen die Bridgeheadserver ihre MD5-Hashwerte, um ggf. Änderungen in den Verbindungsstatusinformationen zu ermitteln. Anschließend fordert der lokale Bridgeheadserver mit dem Verb DIGEST_QUERY den MD5-Hashwert vom Remotebridgeheadserver an. Das Verb DIGEST_QUERY enthält die GUID der Exchange-Organisation und den MD5-Hashwert des lokalen Bridgeheadservers.
e. Der Remotebridgeheadserver vergleicht dann den eigenen MD5-Hashwert mit dem MD5-Hashwert, der über DIGEST_QUERY empfangen wurde. Wenn die Hashwerte identisch sind, sendet der Remotebridgeheadserver das Verb DONE_RESPONSE, durch das angegeben wird, dass die Verbindungsstatustabelle nicht aktualisiert werden muss. Andernfalls wird vom Remotebridgeheadserver das gesamte OrgInfo-Paket gesendet.
f. Nach Empfang des OrgInfo-Pakets werden die Funktionen des Remotebridgeheadservers und des lokalen Bridgeheadservers vertauscht, und der lokale Bridgeheadserver sendet sein eigenes OrgInfo-Paket an den Remotebridgeheadserver. Beide Bridgeheadserver übertragen das empfangene OrgInfo-Paket an ihren Routinggruppenmaster. Durch den Routinggruppenmaster wird ermittelt, ob die Verbindungsstatustabelle mit den Informationen aus dem OrgInfo-Paket aktualisiert werden muss. Eine höhere Versionsnummer weist darauf hin, dass es sich um ein aktuelleres OrgInfo-Paket handelt.
227
Hinweis: Routinggruppenmaster nehmen niemals Informationen über ihre lokale Routinggruppe von einem Routinggruppenmaster in einer Remoteroutinggruppe an.
g. Nach dem Austausch von OrgInfo-Paketen startet der Remotebridgeheadserver die Übertragung von E-Mail-Nachrichten oder sendet den Befehl QUIT, um die SMTP-Verbindung zu beenden.
Einzelheiten zur SMTP-Kommunikation zwischen Servern mit Exchange Server 2003 finden Sie unter SMTP-Transportarchitektur.
Hinweis: Wenn Sie Routinggruppen durch einen X.400-Connector verbinden, werden im Rahmen der normalen Nachrichtenübertragung Verbindungsstatusinformationen zwischen den MTAs ausgetauscht. Ein als OrgInfo-Paket bezeichnetes Binärobjekt wird dabei in einer Systemmeldung an den empfangenden MTA gesendet, bevor IPM-Nachrichten übertragen werden. Der empfangende MTA überträgt das Orginfo-Paket dann an das lokale Routingmodul, das die Übertragung dem Routinggruppenmaster mitteilt.
Beispiel für einen LSAIn der folgenden Abbildung wird die Funktionsweise des Verbindungsstatusalgorithmus (LSA, Link State Algorithm) in einer Exchange-Organisation mit mehreren Routinggruppen dargestellt. In der Abbildung wird eine Umgebung mit einem nicht verfügbaren Bridgeheadserver in Routinggruppe E gezeigt. Die Bridgeheadserver der anderen Routinggruppen haben keine Informationen darüber erhalten, dass ein Routingproblem besteht.
228
Eine Organisation mit einem nicht verfügbaren Bridgeheadserver vor Änderung des Verbindungsstatus
Das Routingproblem wird von Exchange Server 2003 auf folgende Weise erkannt:
1. Ein Benutzer in Routinggruppe A sendet einem Empfänger in Routinggruppe E eine Nachricht.
2. Das Routingmodul wählt den in Abbildung 5.9 dargestellten Weg. Die Nachricht wird daher an den Bridgeheadserver in Routinggruppe B übermittelt.
3. Der Bridgeheadserver in Routinggruppe B versucht eine direkte Übertragung an den Bridgeheadserver in Routinggruppe E. Da der Remotebridgehead nicht verfügbar ist, schlägt dieser Versuch fehl. Nach drei aufeinanderfolgenden Verbindungsversuchen wird der lokale Bridgeheadserver des Routinggruppenconnectors als CONN_NOT_AVAIL gekennzeichnet. Da es in der Konfiguration des Connectors keine weiteren Bridgeheads gibt, wird der Connector als STATE DOWN gekennzeichnet.
229
Ausfall des ersten Connectors
4. Der Bridgeheadserver in Routinggruppe B stellt über den TCP-Anschluss 691 eine Verbindung mit seinem Routinggruppenmaster her und überträgt die neuen Verbindungsstatusinformationen. Die Informationen werden vom Master in die Verbindungsstatustabelle aufgenommen, und alle Server der Routinggruppe werden über die Änderung informiert.
5. Durch die Änderung des Verbindungsstatus erfolgt ein erneutes Routing in Routinggruppe B. Zwei Wege mit den gleichen Kosten sind für Exchange Server 2003 verfügbar. In diesem Beispiel wird die Nachricht an Routinggruppe C gesendet. Der Übertragungsweg wird vom Routingmodul zufällig ausgewählt.
6. Bevor die eigentliche Nachricht gesendet wird, vergleichen die beiden Bridgeheadserver in Routinggruppe B und C ihre MD5-Hashwerte. Da die MD5-Hashwerte nicht übereinstimmen, tauschen die Server Verbindungsstatusinformationen aus. Der Bridgeheadserver in Routinggruppe B informiert die verbleibenden benachbarten Remotebridgeheadserver (in Routinggruppe A, C und D) über die Änderungen des Verbindungsstatus.
7. Der Bridgeheadserver in Routinggruppe C stellt über den TCP-Anschluss 691 eine Verbindung mit seinem Routinggruppenmaster her und überträgt die neuen Verbindungsstatusinformationen. Die Informationen werden vom Routinggruppenmaster in die Verbindungsstatustabelle aufgenommen, und alle Server der Routinggruppe werden über die Änderung informiert. Alle Server in Routinggruppe B und C sind nun
230
darüber informiert, dass der Routinggruppenconnector zwischen Routinggruppe B und Routinggruppe E nicht verfügbar ist.
8. Der Bridgeheadserver in Routinggruppe B versucht eine direkte Übertragung an den Bridgeheadserver in Routinggruppe E. Da der Remotebridgehead nicht verfügbar ist, schlägt dieser Verbindungsversuch fehl. Nach drei Verbindungsversuchen wird der Connector als STATE DOWN gekennzeichnet.
Ausfall des zweiten Connectors
9. Der Bridgeheadserver in Routinggruppe C stellt über den TCP-Anschluss 691 eine Verbindung mit seinem Routinggruppenmaster her und überträgt die neuen Verbindungsstatusinformationen. Die Informationen werden vom Routinggruppenmaster in die Verbindungsstatustabelle aufgenommen, und alle anderen Server der Routinggruppe werden über die Änderung informiert.
10. Durch die Änderung des Verbindungsstatus erfolgt ein erneutes Routing in Routinggruppe C. Die Nachricht wird nun an Routinggruppe D gesendet, da das Routingmodul noch eine bestehende Verbindung zwischen den Routinggruppen D und E erkennt. Der Bridgeheadserver in Routinggruppe C informiert die verbleibenden benachbarten Remotebridgeheadserver (in den Routinggruppen A, B und C) über die Änderungen des Verbindungsstatus.
11. Die Nachricht wird an Routinggruppe D übermittelt. Vor der eigentlichen Übertragung vergleichen jedoch die Bridgeheadserver der Routinggruppen B und C ihre MD5-Hashwerte und tauschen Verbindungsstatusinformationen aus.
231
12. Der Bridgeheadserver in Routinggruppe D stellt über den TCP-Anschluss 691 eine Verbindung mit seinem Routinggruppenmaster her und überträgt die neuen Verbindungsstatusinformationen. Die Informationen werden vom Routinggruppenmaster in die Verbindungsstatustabelle aufgenommen, und alle Server der Routinggruppe werden über die Änderung informiert. Alle Server in Routinggruppe D sind nun darüber informiert, dass die Routinggruppenconnectors zwischen den Routinggruppen B und E sowie C und E nicht verfügbar sind.
13. Der Bridgeheadserver in Routinggruppe D versucht eine direkte Übertragung an den Bridgeheadserver in Routinggruppe E. Da der Remotebridgehead nicht verfügbar ist, schlägt dieser Verbindungsversuch jedoch fehl. Nach drei Verbindungsversuchen wird der Connector als STATE DOWN gekennzeichnet.
Ausfall des dritten Connectors
14. Der Bridgeheadserver in Routinggruppe D stellt über den TCP-Anschluss 691 eine Verbindung mit seinem Routinggruppenmaster her und überträgt die neuen Verbindungsstatusinformationen. Die Informationen werden vom Master in die Verbindungsstatustabelle aufgenommen, und alle Server der Routinggruppe werden über die Änderung informiert.
15. Durch die Änderung des Verbindungsstatus erfolgt ein erneutes Routing in Routinggruppe D. Da für Routinggruppe E keine zusätzlichen Übertragungswege zur Verfügung stehen, bleibt die Nachricht in Routinggruppe D, bis mindestens ein
232
Übertragungsweg verfügbar ist. Sobald der Bridgeheadserver in Routinggruppe E verfügbar ist, wird die Nachricht an Routinggruppe E übermittelt.
16. Der Bridgeheadserver in Routinggruppe D informiert die verbleibenden benachbarten Remotebridgeheadserver (in Routinggruppe B und C) über die Änderungen des Verbindungsstatus. Diese Routinggruppen übermitteln die Verbindungsstatusänderungen anschließend an Routinggruppe A.
Verbindungsstatusänderungen und VerbindungsstatusübermittlungDie Verbindungsstatustabelle enthält Versionsinformationen für jede Routinggruppe in Form von Haupt-, Neben- und Benutzerversionsnummern. Hauptversionsänderungen haben die höchste Priorität, gefolgt von Nebenversionsänderungen und Änderungen der Benutzerversionsnummern.
Exchange Server 2003 erkennt Verbindungsstatusänderungen auf die im Folgenden beschriebene Weise:
Hauptversionsnummer Als Hauptversionsänderungen gelten physikalische Änderungen an der Routingtopologie. Ein Beispiel für eine Hauptversionsänderung wäre das Hinzufügen eines neuen Connectors zu einer Routinggruppe oder die Änderung einer Connectorkonfiguration. Damit der Routinggruppenmaster über Hauptversionsänderungen an der Routingtopologie seiner Routinggruppe informiert wird, registriert er sich mithilfe von DSAccess bei Active Directory für den Empfang von Änderungsmitteilungen. Der Konfigurationsdomänencontroller sendet diese Mitteilungen entsprechend dem LDAP-Standard (Lightweight Directory Access Protocol) über Änderungsbenachrichtigungsvorgänge an den Exchange-Server. Wenn ein Routinggruppenmaster vom Konfigurationsdomänencontroller eine Aktualisierung der Routingtopologie erhält, sendet er die aktualisierten Informationen an alle Mitgliedsserver seiner Routinggruppe. Außerdem benachrichtigt er alle Bridgeheadserver in Remoteroutinggruppen, wie oben im Abschnitt „Verbindungsstatusalgorithmus“ beschrieben. Weitere Informationen zur Funktion von DSAccess und den Konfigurationsdomänencontroller in Exchange 2003 finden Sie in Exchange Server 2003 und Active Directory .
Nebenversionsnummer Als Nebenversionsänderungen gelten Änderungen am Verbindungsstatus, z. B. wenn ein Connector vom Status STATE UP in den Status STATE DOWN wechselt. Unzuverlässige Netzwerkverbindungen können allerdings dazu führen, dass Connectors häufig als UP bzw. DOWN gekennzeichnet werden. Dadurch werden zusätzliche Verbindungsstatusaktualisierungen in der gesamten Exchange-Organisation verursacht. Es kann dadurch zu einem deutlichen Anstieg der Verarbeitungslast in Folge von zusätzlichen Zurücksetzungen der Route und erneutem Routing von Nachrichten kommen. In der Standardeinstellung verringert Exchange Server 2003 oszillierende Connectors, indem Verbindungsstatusänderungen um einen
233
Zeitraum von zehn Minuten verzögert werden. In dieser Zeit werden vorkommende Änderungen zusammengeführt und anschließend gebündelt per Stapelverarbeitung in der Organisation repliziert. Dennoch kann eine oszillierende Verbindung Verbindungsstatus-Datenverkehr erzeugen, wenn Änderungen über längere Zeiträume vorkommen.
Sie können das Aktualisierungszeitfenster mit dem folgenden Registrierungsparameter vergrößern oder verkleinern.
Speicherort HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Services\RESvc\
Parameters\
Wert StateChangeDelay
Typ REG_DWORD
Wert Zeitraum zwischen Verbindungsstatusaktualisierungen in Sekunden. Der Standardwert beträgt zehn Minuten. Der Höchstwert beträgt sieben Tage. Für die Fehlerbehebung bei Verbindungsproblemen kann es hilfreich sein, diesen Parameter auf 0 zu setzen. Fehler spiegeln sich dann sofort im Connectorstatus wider.
Mit dem folgenden Registrierungsschlüssel können Sie verhindern, dass der Routinggruppenmaster seine Connectors als DOWN kennzeichnet. Dies kann vor allem in Hub-and-Spoke-Routingszenarios hilfreich sein, in denen jeder Zielort nur durch einen einzigen Connector erreichbar ist. Es kann zum erneuten Routing von Nachrichten kommen, wenn keine alternativen Connectors zur Verfügung stehen.
Speicherort HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Services\RESvc\
Parameters\
Wert SuppressStateChanges
Typ REG_DWORD
Wert Über den Wert 0x1 werden Verbindungsstatusänderungen deaktiviert.
234
Benutzerversionsnummer Zu den Benutzeraktualisierungen zählen minimale Änderungen, wie der Wechsel des Routinggruppenmasters, das Starten und Beenden von Diensten auf einem Exchange-Server, das Hinzufügen eines Servers zu der Routinggruppe oder der Ausfall der Verbindung zwischen einem Mitgliedsserver und dem Routinggruppenmaster.
Ändern des RoutinggruppenmastersDer erste installierte Server der Routinggruppe wird automatisch als Routinggruppenmaster festgelegt. Wenn dieser Server ausfällt oder offline geschaltet wird, werden Verbindungsstatusinformationen in der Routinggruppe nicht mehr weitergegeben. Alle Server der Routinggruppe arbeiten weiterhin auf Basis der älteren Informationen. Sobald der Routinggruppenmaster wieder verfügbar ist, rekonstruiert er seine Verbindungsstatusinformationen. Es wird mit den Servern und Connectors begonnen, die als nicht verfügbar gekennzeichnet sind. Der Routinggruppenmaster ermittelt alle nicht verfügbaren Server und aktualisiert die Mitglieder der Routinggruppe.
Wenn Sie einen Routinggruppenmaster für längere Zeit herunterfahren, sollten Sie einen anderen Routinggruppenmaster benennen, um ein ineffizientes Nachrichtenrouting zu vermeiden. Erweitern Sie im Exchange-System-Manager die gewünschte Routinggruppe, und wählen Sie den Container Mitglieder. Klicken Sie im Detailbereich mit der rechten Maustaste auf den Server, den Sie zum Routinggruppenmaster heraufstufen möchten, und wählen Sie die Option Als Master festlegen.
Hinweis: Das Wechseln des Routinggruppenmasters stellt eine wesentliche Verbindungsstatusänderung dar. Bei einer Verbindungsstatusänderung werden Verbindungsstatusinformationen in der gesamten Organisation weitergegeben, und alle Exchange-Server müssen ihre Nachrichten neu routen. Der Routinggruppenmaster sollte daher nicht häufig gewechselt werden.
Konflikte zwischen RoutinggruppenmasternIn einer Routinggruppe wird nur ein Server als Routinggruppenmaster anerkannt. Diese Konfiguration wird durch einen Algorithmus erzwungen, bei dem (N/2) +1 Server in der Routinggruppe den Master akzeptieren und erkennen müssen. N steht dabei für die Anzahl der Server in der Routinggruppe. Die Mitgliederknoten senden daher ATTACH-Verbindungsstatusdaten an den Master.
Gelegentlich verwenden zwei oder mehr Server den falschen Server als Routinggruppenmaster. Wird beispielsweise ein Routinggruppenmaster verschoben oder gelöscht, ohne dass ein anderer gewählt wird, verweist das Attribut msExchRoutingMasterDN, über das in Active Directory der Routinggruppenmaster festlegt wird, unter Umständen auf einen gelöschten Server, da das Attribut nicht verbunden ist.
235
Ein solcher Fall kann auch eintreten, wenn ein alter Routinggruppenmaster die Trennung als Master ablehnt, oder ein Rogue-Routinggruppenmaster weiterhin die ATTACH-Verbindungsstatusinformation an einen alten Routinggruppenmaster sendet. Wenn msExchRoutingMasterDN in Exchange 2003 auf ein gelöschtes Objekt verweist, gibt der Routinggruppenmaster seine Funktion als Master auf und initiiert die Beendigung der Masterrolle.
So beheben Sie das Problem:
Überprüfen Sie die ordnungsgemäße Verbindungsstatusübermittlung in der Routinggruppe an Anschluss 691. Stellen Sie sicher, dass kein Firewall für SMTP-Filter die Kommunikation blockiert.
Stellen Sie sicher, dass kein Exchange-Dienst gestoppt wurde.
Überprüfen Sie die Active Directory-Replikationswartezeiten mithilfe des Replikationsmonitors von Active Directory (Replmon.exe), der in Microsoft Windows Server 2003 enthalten ist.
Überprüfen Sie Netzwerkprobleme und Wartezeiten in der Netzwerkkommunikation.
Überprüfen Sie gelöschte Routinggruppenmaster oder nicht mehr vorhandene Server. In diesen Fällen wird das Transportereignis 958 im Anwendungsprotokoll der Ereignisanzeige protokolliert. Dieses Ereignis gibt an, dass ein Routinggruppenmaster nicht mehr vorhanden ist. Überprüfen Sie diese Informationen mit einem Verzeichniszugriffstool, wie LDP (ldp.exe) oder ADSI-Bearbeitung (adsiEdit.msc). Diese Anwendungen sind Teil der Supporttools von Windows Server 2003.
Abwärtskompatibilität mit Exchange Server 5.5Exchange Server 5.5 verwendet die GWART (Gateway Address Routing Table) zur Auswahl der Routen innerhalb einer Exchange-Organisation. Diese Methode verwendet einen Distance-Vector-Routing-Algorithmus, der als Ursache für Routingschleifen in bestimmten Situationen in Frage kommt. Im Gegensatz hierzu wählt Exchange Server 2003 Routen mit einer im Arbeitsspeicher gespeicherten Verbindungsstatustabelle sowie mit dem Dijkstra-Algorithmus für kürzeste Wege aus. Für die Abwärtskompatibilität muss Exchange 2003 allerdings eine GWART erzeugen, damit Exchange 5.5-Server auch Exchange 2003-Connectors verwenden können. Außerdem muss das Routingmodul bereits vorhandene Exchange 5.5-Connectors in die Verbindungsstatustabelle einbeziehen, damit Server unter Exchange Server 2003 diese Übertragungswege verwenden können.
236
Erzeugen der GWART Die GWART wird vom Exchange-MTA erzeugt. Um die Routinginformationen zu beziehen, kommuniziert der Exchange-MTA über den Wrapper der Routingschnittstelle, MTARoute.dll, mit dem Routingmodul. Anschließend schreibt er diese Informationen in das Attribut gatewayRoutingTree des Objekts legacy GWART, das sich in der administrativen Gruppe des Exchange-Servers befindet. Außerdem aktualisiert der MTA das Attribut GWARTLastModified, um die jüngsten Änderungen wiederzuspiegeln. Der Standortreplikationsdienst (SRS) repliziert das GWART-Objekt in das Exchange 5.5-Verzeichnis. Danach können Exchange 5.5-Server auch Exchange Server 2003-Connectors in ihre Routingentscheidungen einbeziehen.
Routingprobleme im gemischten ModusDer Standortreplikationsdienst repliziert auch Informationen der Exchange Server 5.5-Connectors in Active Directory. Server, auf denen Exchange Server 2003 ausgeführt wird, können deshalb auch Nachrichten über Exchange Server 5.5-Connectors routen. Benutzer von Exchange Server 2003 haben dadurch die Möglichkeit, Nachrichten über jeden vorhandenen Connector zu senden, zum Beispiel Connectors, die unter Exchange Server 2003 nicht verfügbar sind. Hierzu zählen auch Connectors zu Microsoft Mail für PC-Netzwerke. Die Funktionen von Routinggruppen im gemischten Modus, in dem auf einigen Servern Exchange Server 2003 oder Exchange 2000 Server und auf anderen Servern Exchange 5.5 ausgeführt wird, sind auf folgende Weise eingeschränkt:
Routinggruppen können sich nicht über mehrere administrative Gruppen erstrecken Dies liegt daran, dass die Routingtopologie in Exchange Server 5.5 durch Standorte definiert wird. Unter Exchange Server 5.5 bieten Standorte sowohl die Funktionen der administrativen Gruppen als auch der Routinggruppen in Exchange Server 2003. Aufgrund dieser unterschiedlichen Routingtopologie ist der Funktionsumfang von Routinggruppen im gemischten Modus eingeschränkt.
Sie können keine Server zwischen Routinggruppen verschieben, die sich in unterschiedlichen administrativen Gruppen befinden.
Exchange Server 5.5-Connectors mit lokalem Bereich stehen allen Exchange 2003-Benutzern in der Organisation zur Verfügung, da es für diesen Connectorbereich keine Entsprechung in Exchange Server 2003 gibt. In Exchange Server 5.5 können drei verschiedene Ebenen der Connectorverfügbarkeit festgelegt werden: Organisation, Standort und Serverstandort. In Exchange Server 2003, stehen dagegen nur die Bereiche Organisation und Routinggruppe (Standort) zur Verfügung.
237
TopologieaktualisierungenDa Exchange Server 5.5-Server keine Verbindungsstatustabelle verwenden, senden Routinggruppen mit einem Routinggruppenmaster, auf dem Exchange Server 5.5 ausgeführt wird (also Standorte ohne Server mit Exchange Server 2003), keine Topologieaktualisierungen. Zur Lösung dieses Problems beziehen Routinggruppenmaster die Routinggruppentopologie für alle über Exchange Server 5.5 gesteuerten Routinggruppen regelmäßig aus Active Directory. Anschließend replizieren sie diese Informationen in die Exchange Server 2003-Routingtopologie.
Wenn Sie festlegen möchten, wann das Routingmodul die Topologieinformationen aus Active Directory liest, können Sie den folgenden Registrierungsschlüssel auf einem Routinggruppenmaster konfigurieren.
Speicherort HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Services\RESvc\
Parameters\
Wert ReloadOsInterval
Typ REG_DWORD
Wert Zeitraum zwischen dem erneuten Laden der Topologieinformationen aus Active Directory in Sekunden.
Unterbrochene VerbindungsstatusübermittlungServer, auf denen Exchange 2003 Server ausgeführt wird, erwarten keinen Austausch von Verbindungsstatusinformationen mit Servern, auf denen Exchange Server 5.5 ausgeführt wird. Wenn jedoch ein Exchange 5.5-Bridgeheadserver in einer Exchange-Routinggruppe durch einen Server ersetzt wird, der mit Exchange 2003 arbeitet, und als Bridgeheadserver deklariert wird, nimmt die Routinggruppe an der Weitergabe von Verbindungsstatusinformationen teil. Sie hat dann nicht mehr die Hauptversionsnummer Null. Die Hauptversionsnummer Null weist auf einen Server hin, der bei den Verbindungsstatusinformationen nicht berücksichtigt wird oder nicht am Austausch von Verbindungsstatusinformationen teilnimmt. Alle Server, auf denen Exchange 5.5 ausgeführt wird, haben die Versionsnummer Null, da sie keine Verbindungsstatusinformationen austauschen.
Wenn eine Routinggruppe Verbindungsstatusinformationen weitergibt, erhöht sich ihre Hauptversionsnummer. Bridgeheadserver in anderen Routinggruppen erwarten den Empfang von Verbindungsstatusänderungen aus dieser Routinggruppe. Es wird allerdings zu Problemen kommen, wenn Sie den Bridgeheadserver wieder unter Exchange Server 5.5
238
betreiben, da er dann über keine Verbindungsstatustabelle verfügt. Andere Server erwarten dann vom Bridgeheadserver, auf dem zuvor Exchange Server 2003 und nun Exchange Server 5.5 ausgeführt wird, dass er an der Verbindungsstatusübermittlung teilnimmt. Deshalb warten andere Server darauf, dass sie von ihm aktualisierte Verbindungsstatusinformationen erhalten. Ist dies der Fall, wird diese Routinggruppe isoliert und nimmt nicht an den dynamischen Verbindungsstatusaktualisierungen in der Organisation teil.
Die folgende Abbildung veranschaulicht eine Situation, in der diese isolierte Routinggruppe problematisch sein kann. Insbesondere weil der Exchange 5.5-Bridgeheadserver in der Exchange 5.5-Routinggruppe früher ein Exchange 2000- oder Exchange 2003-Bridgeheadserver war, erwarten die anderen Server, dass er an der Weitergabe des Verbindungsstatus teilnimmt. In Abbildung 5.13 leiten Exchange Server 5.5 Internet Mail Connector und Exchange Server 2003 SMTP-Connector E-Mails über einen einzelnen Smarthost an das Internet weiter. Der Smarthost ist dann nicht mehr verfügbar. Aus diesem Grund kennzeichnet der Bridgeheadserver, auf dem Exchange Server 2003 ausgeführt wird, die Route über seinen SMTP-Connector als nicht verfügbar. Da jedoch der Bridgeheadserver vom Server, auf dem Exchange 5.5 ausgeführt wird, Verbindungsstatusinformationen zu seinen Routinggruppen und Connectors erwartet, nimmt er an, dass die Route über den Internet Mail Connector verfügbar ist und versucht, die Nachrichten über diese Route zu senden. Nach einem Fehlversuch erkennt der Server mit Exchange 2003 eine mögliche Schleife und verwendet diese Route nicht mehr zum Senden.
Verbindungsherstellung von Exchange 5.5- und Exchange 2003-Servern mit einem Smart Host
Die Weitergabe des Verbindungsstatus kann auch durch eine Firewall im System unterbrochen werden, die diese Weitergabe blockiert. Die Anschlüsse 25 und 691 sind beispielsweise innerhalb einer Routinggruppe erforderlich, während der Anschluss 25 zwischen Routinggruppen erforderlich ist. Auch darf der ESMTP-Befehl X-LINK2STATE (Extended Simple Mail Transfer Protocol) nicht durch eine Firewall blockiert werden.
Zur Problembehebung stehen zwei Lösungen zur Verfügung:
239
Aktualisieren Sie den Exchange 5.5-Bridgeheadserver auf einen Exchange 2000- oder Exchange 2003-Server, oder senden Sie die Verbindungsstatusinformationen zu dieser Routinggruppe über einen anderen Exchange 2000- oder Exchange 2003-Server. Mit diesen beiden Möglichkeiten können Sie das Problem am einfachsten beheben.
Wenn Sie die nicht verbundenen Routinggruppen auf einen Verbindungsstatus mit Hauptversionsnummer 0 zurücksetzen möchten, fahren Sie alle Exchange-Server in der Organisation gleichzeitig herunter, und starten Sie sie anschließend neu.
Konfigurieren Sie die Firewall so, dass die Weitergabe des Verbindungsstatus nicht verhindert wird.
Weitere Informationen über isolierte Routinggruppen und die Hauptversionsnummern finden Sie im Microsoft Knowledge Base-Artikel 842026: „Routing status information is not propagated correctly to all servers in Exchange 2000 Server or in Exchange Server 2003“.
SMTP-TransportarchitekturDas Transportsubsystem von Microsoft Exchange Server 2003 besteht aus einer Reihe von COM-basierten Modulen (Component Object Model), die sich nahtlos in den SMTP-Dienst (Simple Mail Transfer Protocol) von Microsoft Windows 2000 Server und Microsoft Windows Server 2003 einfügen. Da Exchange Server 2003 den Windows SMTP-Dienst mit eigenen Komponenten erweitern muss, können Sie das Setupprogramm von Exchange Server 2003 nur auf einem Computer unter Windows Server 2003 ausführen, auf dem auch der SMTP-Dienst installiert ist. Beachten Sie, dass Exchange-Komponenten, wie das erweiterte Warteschlangenmodul, das Kategorisierungsmodul oder das Routingmodul, nicht nur eine Erweiterung des SMTP-Diensts darstellen, sondern auch SMTP-Komponenten durch Exchange-spezifische Komponenten ersetzen. Die erweiterte Version des SMTP-Diensts unterstützt folgende Funktionen:
Erweiterte SMTP-Befehle zur effizienten Kommunikation zwischen Exchange-Servern
Integration mit dem Microsoft Active Directory-Verzeichnisdienst für das Kategorisieren und Routing von Nachrichten
Integration mit dem Exchange-Informationsspeicher für die lokale Übermittlung
Nachrichtenverfolgung zur Analyse von Nachrichtenpfaden in Ihrer Exchange-Organisation
Folgende Themen werden in diesem Abschnitt behandelt:
Entwurf des SMTP-Diensts Der SMTP-Dienst wird im Inetinfo-Prozess ausgeführt. Wenn er durch Exchange-Ereignissenken erweitert wird, verarbeitet er alle ein- und ausgehenden Nachrichten. Wenn Nachrichten durch das Transportsubsystem übermittelt werden, greift SMTP stark auf IIS-Ressourcen (Internet Information Services) zurück. Für
240
das vollständige Verständnis des Exchange 2003-Transportsubsystems ist es wichtig, dass Sie den Entwurf des SMTP-Diensts verstehen.
Erweitertes Warteschlangenmodul Das erweiterte Warteschlangenmodul ist eine zentrale Komponente des SMTP-Transportsubsystems und der wichtigste Verteiler für Transportereignisse. Zum Verständnis der Interaktion zwischen den zentralen SMTP-Transportkomponenten und den Erweiterungen für Exchange-Ereignissenken ist es wichtig, die Funktionen des erweiterten Warteschlangenmoduls zu verstehen.
Transportkomponenten Diese Komponenten verarbeiten jede Nachricht, die von einem Remotehost oder Messagingclient empfangen wurde. In Exchange Server 2003 müssen alle Nachrichten durch das SMTP-Transportsubsystem übermittelt werden. Dies gilt auch für Nachrichten, die über MAPI-Clients, wie Microsoft Office Outlook 2003, Microsoft Office Outlook Web Access, das DAV-Protokoll (Distributed Authoring and Versioning), X.400 oder jeden EDK-basierten Connector (Exchange Development Kit), gesendet werden – selbst wenn dies ohne SMTP geschieht oder sich die Postfächer von Empfängern und Sender in demselben Postfachspeicher befinden. Wenn Sie den SMTP-Dienst auf einem Server anhalten, auf dem Exchange Server 2003 ausgeführt wird, werden alle Übertragungen und Zustellungen von Nachrichten auf diesem Server beendet. Für das Verständnis der Verarbeitung von Nachrichten durch Transportereignissenken ist es wichtig, die Nachrichtenverarbeitung in Exchange Server 2003 zu verstehen.
Informationsspeichertreiber Exchange Server 2003 implementiert einen Exchange-Informationsspeichertreiber, damit der SMTP-Dienst ausgehende Nachrichten vom Exchange-Informationsspeicher erhalten und eingehende Nachrichten an Exchange-Empfänger übermitteln kann. Es ist wichtig, die Implementierung des Informationsspeichertreibers zu verstehen, um den physischen Ort von Nachrichten auf ihrem Weg durch das Transportsubsystem ermitteln zu können.
Protokollerweiterungen Protokollerweiterungen implementieren Exchange-spezifische SMTP-Protokollbefehle, die auch erweiterte SMTP-Verben genannt werden. Sie müssen die Implementierung der Protokollerweiterungen verstanden haben, um die Funktionsweise Exchange-spezifischer SMTP-Protokollfunktionen zu verstehen.
Protokollierung und Nachrichtenverfolgung Protokollaufzeichnung, Ereignisprotokollierung und Nachrichtenverfolgung sind Funktionen, die zur Analyse der Einzelheiten bei der Nachrichtenübertragung dienen. Die Kenntnis der Implementierung dieser Funktionen ist besonders für die Problembehandlung wichtig.
In diesem Abschnitt wird davon ausgegangen, dass Sie mit den Grundbegriffen der Nachrichtenverarbeitung in Exchange Server 2003 vertraut sind. Weitere Informationen zur Nachrichtenverarbeitung finden Sie unter Nachrichtenroutingarchitektur. In diesem Abschnitt wird außerdem davon ausgegangen, dass Sie mit den Grundprinzipien der Konfiguration virtueller SMTP-Server, SMTP-Connectors und Routinggruppenconnectors vertraut sind. Weitere Informationen zu diesen Begriffen finden Sie unter Exchange Server 2003 Transport and Routing Guide.
241
Entwurf des SMTP-DienstsDas zentrale SMTP-Protokollmodul wird in der Datei SMTPSvc.dll implementiert, die sich im Verzeichnis \WINDOWS\system32\inetsrv befindet. Dieses Protokollmodul wird als nicht verwalteter Code im IIS-Inetinfo-Prozess ausgeführt und verarbeitet ein- und ausgehende SMTP-Verbindungen auf der Sitzungsebene. In der folgenden Abbildung wird veranschaulicht, dass der SMTP-Dienst entsprechend dem OSI-Modell (Open Systems Interconnection) der ISO (International Organization for Standardization) in der Sitzungs-, Präsentations- und Anwendungsschicht angesiedelt ist.
Inetinfo-Prozess und SMTP-Dienst im OSI-Modell
Hinweis: Als nicht verwalteter Code wird Code bezeichnet, der direkt vom Betriebssystem ausgeführt wird, d. h. außerhalb der CLR (Common Language Runtime) von Microsoft .NET Framework. Nicht verwalteter Code verfügt über eine eigene Speicherverwaltung, Typprüfung und Sicherheitsunterstützung. Verwalteter Code bezieht diese Dienste von der CLR.
242
IIS-Integration (Internetinformationsdienste)An dem Umstand, dass der SMTP-Dienst im Inetinfo-Prozess ausgeführt wird, lässt sich erkennen, dass das Transportsubsystem von Exchange Server 2003 IIS-Ressourcen mit anderen Diensten gemeinsam verwendet, die ebenfalls in IIS ausgeführt werden – beispielsweise die Dienste POP3 (Post Office Protocol Version 3), IMAP4 (Internet Mail Access Protocol Version 4) oder RESvc (Exchange Routing Engine). Bei Inetinfo.exe handelt es sich um den zentralen Prozess von IIS. Dieser wird durch den IIS-Verwaltungsdienst gesteuert. Ausführlichere Informationen hierzu erhalten Sie unter Dienstabhängigkeiten in Exchange Server 2003 .
Asynchrone Ausführung von ThreadsEine der wichtigsten Ressourcen, die der SMTP-Dienst mit allen anderen Diensten im Inetinfo-Prozess gemeinsam verwendet, ist die asynchrone Threadwarteschlange (ATQ – Asynchronous Thread Queue). Hierbei handelt es sich um einen Pool von Threads, der von IIS verwendet wird, um alle eingehenden Netzwerkverbindungsanforderungen zu verarbeiten. Ein Thread ist eine Codeausführungsinstanz innerhalb eines Prozesses. Ein Prozess besteht aus einem virtuellen Adressraum, dem Prozessorkontext und mindestens einem Thread. Threads werden mithilfe der CreateThread()-Methode des Betriebssystems erstellt und innerhalb des virtuellen Adressraums des aufrufenden Prozesses (d. h. des IIS-Inetinfo-Prozesses) ausgeführt.
Bei der asynchronen Verarbeitung wird jeder Thread im Inetinfo-Prozess ausgeführt, ohne dass auf das Ende der Verarbeitung anderer Prozesse gewartet wird. Bei der synchronen Verarbeitung werden Threads nacheinander und synchronisiert ausgeführt (bei einem Funktionsaufruf wird die Ausführung von Code so lange blockiert, bis die Funktion beendet ist). Zum Synchronisieren asynchroner Threads (beispielsweise um Konflikte wegen aufeinanderfolgender Zugriffe auf eine bestimmte Ressource zu vermeiden) stellt das Betriebssystem Synchronisierungsobjekte zur Verfügung. Bei einem Synchronisierungsobjekt für eine bestimmte Ressource kann es sich zum Beispiel um ein Ereignisobjekt für einen Windows-Socket handeln. Mithilfe von Ereignisobjekten erhält der SMTP-Dienst Benachrichtigungen über eingehende SMTP-Verbindungen. Bei einem Windows-Socket handelt es sich um eine Kombination aus einer IP-Adresse und einer Portnummer. Der Standardport für den Zugriff auf das SMTP-Protokollmodul ist der TCP-Port 25. Zusammen mit der IP-Adresse des Exchange-Servers, auf dem der SMTP-Dienst ausgeführt wird, bildet diese Portnummer den Socket des virtuellen SMTP-Standardservers, zum Beispiel: 192.168.1.100:25.
Hinweis: Auf einem Exchange-Server ist nur der virtuelle Standardserver für SMTP vorhanden. Der virtuelle Standardserver für SMTP nimmt eingehende Verbindungen am TCP-Port 25 für alle IP-Adressen des Servers an. Sie können diese Konfiguration
243
im Exchange-System-Manager auf der Registerkarte Allgemein unter Virtueller Standardserver für SMTPändern.
Verarbeiten eingehender SMTP-VerbindungenDer Inetinfo-Prozess verarbeitet eingehende SMTP-Verbindungen wie folgt:
1. Wenn Sie den SMTP-Dienst starten, initialisiert der Inetinfo-Prozess den TCP/IP-Socket des virtuellen SMTP-Servers, um eingehende Verbindungsanforderungen zu überwachen. Für die Unterstützung mehrerer gleichzeitiger Verbindungen über denselben virtuellen Server wird der Socket für überlappende E/A-Vorgänge im nicht blockierenden Modus initialisiert. In der Standardeinstellung kann ein virtueller SMTP-Server theoretisch unbegrenzt viele eingehende Netzwerkverbindungen annehmen (allerdings liegt seine physische Höchstgrenze über 5000).
Hinweis: Unter Microsoft Windows Server 2003 kann der Server nur etwa 2.000 gleichzeitige Verbindungen verarbeiten. Unter Windows Server 2003 Service Pack 1 wurde der Standardwert von 2.000 auf 5.000 erhöht und lässt sich durch eine Einstellung in der Metabasis noch weiter steigern.
2. Der Inetinfo-Prozess erstellt ein Synchronisierungsobjekt, um dem Betriebssystem mitzuteilen, dass bei eingehenden Verbindungen über den Socket eine Netzwerkereignisbenachrichtigung an den Prozess gesendet werden soll. Die asynchrone Threadwarteschlange wird mit diesem Synchronisierungsobjekt verknüpft, sodass ein Thread aus diesem Threadpool benachrichtigt werden kann, wenn das Synchronisierungsobjekt eine eingehende Netzwerkverbindung meldet.
3. Der TCP/IP-Transportstack empfängt eine eingehende SMTP-Verbindung und meldet dieses Ereignis dem Inetinfo-Prozess. Nun kann ein Thread aus der asynchronen Threadwarteschlange ausgeführt werden, um Daten vom SMTP-Socket zu lesen.
Hinweis: Der Inetinfo-Prozess kann weitere Threads in der asynchronen Threadwarteschlange erstellen, um zu gewährleisten, dass eine ausreichende Anzahl an Threads für die Überwachung eingehender Verbindungsabfragen verfügbar ist. Sie können die Leistung von IIS optimieren, indem Sie mit dem folgenden Registrierungsparameter eine maximale Anzahl an Threads festlegen, die im System erstellt werden können:
Speicherort HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Services\InetInfo\
Parameters
244
Wert PoolThreadLimit
Geben Sie Folgendes ein REG_DWORD
Wert 0 - 4,294,967,295 (unlimited)
Beschreibung PoolThreadLimit ist ein fester Grenzwert, der alle IIS-Poolthreads einschließt.
4. IIS führt den Code in der Datei SMTPSvc.dll aus und antwortet auf die eingehende Anforderung des Clients mit einer Begrüßungsmeldung, einem so genannten SMTP-Banner, zum Beispiel: 220 server01.TailspinToys.com Microsoft ESMTP MAIL Service, Version: 6.0.3790.0 ready at Sun, 21 Mar 2004 23:48:47 +0100.
5. Der SMTP-Remotehost überträgt die Nachricht, und der SMTP-Dialog wird fortgesetzt. Bei jedem Empfang eines SMTP-Befehls führt ein Thread aus der asynchronen Threadwarteschlange den SMTP-Protokollcode in der Datei SMTPSvc.dll aus und löst Ereignisse im SMTP-Dienst aus, die die Ausführung von Code in anderen DLLs veranlassen. So schreibt zum Beispiel der NTFS-Informationsspeichertreiber die Nachricht als Datei im Dateisystem in den Ordner \Queue des SMTP-Servers.
6. Wenn der aktuelle SMTP-Befehl verarbeitet wurde, setzt der Inetinfo-Prozess den Thread, mit dem die SMTP-Verarbeitung durchgeführt wurde, zurück in die asynchrone Threadwarteschlange, um neue eingehende Befehle oder Verbindungsanforderungen zu überwachen. IIS verwendet vorhandene Threads erneut, um die zusätzliche Arbeitslast zu vermeiden, die bei jedem Empfang eines neuen Threads oder einer neuen Verbindungsanforderung durch das Erstellen eines jeweils neuen Threads entstehen würde.
7. Der Remotehost gibt einen Quit-Befehl aus, und der SMTP-Dienst gibt die Verbindung frei.
Hinweis: Inaktive Threads in der asynchronen Threadwarteschlange verfügen über eine Gültigkeitsdauer (TTL – Time to Live) von 24 Stunden. Der Inetinfo-Prozess stellt jederzeit mindestens zwei Threads in der asynchronen Threadwarteschlange bereit, um auf eingehende Verbindungsanforderungen antworten zu können.
Beschränken der Anzahl der SMTP-ThreadsIn der Standardeinstellung kann der SMTP-Dienst bis zu 90 Prozent der verfügbaren Threads in der asynchronen Threadwarteschlange beanspruchen. Da dieser Threadpool gemeinsam mit anderen IIS-Diensten genutzt wird, die unter Umständen auf demselben Server ausgeführt werden (z. B. FTP, POP3, RESvc oder IMAP4), kann eine hohe SMTP-Last zu
245
einem Leistungsengpass im Inetinfo-Prozess führen. Möglicherweise können FTP, POP3, RESvc oder IMAP4 nicht mehr ausgeführt werden.
Sie können dies verhindern, indem Sie den Prozentsatz der Threads, die der SMTP-Dienst verwenden kann, begrenzen und eine angemessene Anzahl von Threads für andere IIS-Dienste reservieren. Dies lässt sich über folgende Registrierungsparameter erreichen:
Speicherort HKEY_LOCAL_MACHINE\System\
CurrentControlSet\Services\SMTPSVC\
Queuing
Wert MaxPercentPoolThreads
Geben Sie Folgendes ein REG_DWORD
Wert Der Standardwert lautet 0x5A (90%).
Beschreibung Begrenzt den Prozentsatz der Threads aus der asynchronen Threadwarteschlange, die der SMTP-Dienst verwenden kann. Empfohlene Einstellung:
MaxPercentPoolThreads = 90/(2*Anzahl der Instanzen virtueller SMTP-Server)
Wenn genügend Arbeitsspeicher für zusätzliche Threads zur Verfügung steht, können Sie über den folgenden Registrierungsparameter auch die Gesamtzahl der Threads im Inetinfo-Prozess erhöhen.
Speicherort HKEY_LOCAL_MACHINE\System\
CurrentControlSet\Services\SMTPSVC\
Queuing
Wert AdditionalPoolThreadsPerProc
Geben Sie Folgendes ein REG_DWORD
Wert Der Standardwert lautet 0x5A (90%).
246
Beschreibung Legt die zusätzlichen Poolthreads pro Prozessor fest, die der Inetinfo-Prozess beim Starten des SMTP-Diensts erstellt. Empfohlene Einstellung:
AdditionalPoolThreadsPerProc =
((9/(MaxPercentPoolThreads/100))–4)/2
Hinweis: Wenn der Wert für AdditionalPoolThreadsPerProcvalue größer als 200 ist, müssen Sie unter HKEY_LOCAL_MACHINE\ System\CurrentControlSet\Services\InetInfo\Parameters\ den Wert des Parameters PoolThreadLimit erhöhen. Der Wert für PoolThreadLimit sollte mindestens so hoch sein wie der Wert für AdditionalPoolThreadsPerProc.
COM-basierte SMTP-ErweiterungenDas SMTP-Protokoll unterstützt das Senden mehrerer Nachrichten in einer einzigen Sitzung. Während eine Nachricht übermittelt oder weitergeleitet wird, kann die nächste Nachricht übertragen werden. Die im SMTP-Protokoll festgelegte Kennzeichnung des Endes von E-Mail-Daten (ein Wagenrücklauf mit Zeilenvorschub gefolgt von einem Punkt und einem weiteren Wagenrücklauf mit Zeilenvorschub) bzw. der letzte BDAT-Abschnitt jeder einzelnen Nachricht veranlasst den empfangenden SMTP-Dienst, die Empfänger und Daten der jeweiligen Nachricht zu verarbeiten. Diese Art der Verarbeitung wird als Transportverarbeitung bezeichnet, da die Nachricht an den lokalen Exchange-Informationsspeicher übermittelt beziehungsweise an den Stammserver des Empfängers weitergeleitet wird, wenn sich dessen Postfach nicht auf dem lokalen Server befindet. Der SMTP-Dienst kann auch Nachrichten an externe Empfänger weiterleiten. Das Weiterleiten von Nachrichten wird zum Beispiel ausgeführt, wenn Exchange-Benutzer, die mit Internetclients arbeiten, Nachrichten an externe Empfänger senden.
Wenn eine Nachricht über SMTP empfangen wurde, wird sie an das erweiterte Warteschlangenmodul (Phatq.dll) übergeben. Anschließend wird der Thread, mit dem der SMTP-Dienst die Nachricht an das erweiterte Warteschlangenmodul übergibt, an die asynchrone Threadwarteschlange zurückgegeben. Das erweiterte Warteschlangenmodul verwendet zum Verarbeiten von Nachrichten in der Warteschlange seinen eigenen
247
Threadpool. Dieser Threadpool ist nicht identisch mit dem Threadpool für die Verarbeitung von SMTP-Protokollvorgängen. Weitere Informationen zum erweiterten Warteschlangenmodul finden Sie unter Erweitertes Warteschlangenmodul.
Ereignisse im SMTP-TransportsubsystemWenn Threads den Protokollcode in der Datei Smtpsvc.dll oder Transportcode in der Datei Phatq.dll ausführen, lösen sie Ereignisse aus, die zum Ausführen von Code in anderen DLLs führen. Diese Ereignisarchitektur basiert vollständig auf COM. SMTP verwendet zum Auslösen von SMTP-Ereignissen die Microsoft Server Extension Object COM-Bibliothek (Seo.dll) und instanziiert mithilfe der COM-Aktivierung die für jedes einzelne Ereignis registrierten Ereignissenken. Unter anderem können SMTP-Ereignisse die Übertragung bzw. Ankunft eines SMTP-Protokollbefehls oder die Übermittlung einer Nachricht in das SMTP-Transportsubsystem anzeigen. Ereignissenken, wie SMTP-Protokollerweiterungen, Kategorisierungsmodul und Routingmodul, registrieren spezifische Ereignisse im SMTP-Dienst.
Folgende Ereignistypen können im SMTP-Transportsubsystem von Exchange 2003 vorkommen:
SMTP-Protokollereignisse Diese Ereignisse sind SMTP-spezifisch und ermöglichen den Ereignissenken das Ändern des SMTP-Protokollmodulverhaltens, indem sie ein- und ausgehende Befehle sowie die Reaktionen darauf ändern, deaktivieren oder hinzufügen. So implementiert zum Beispiel die Protokollereignissenke X-LSA Sink aus Exchange Server 2003 den zusätzlichen SMTP-Befehl X-LINK2STATE, mit dem Verbindungsstatusinformationen über Routinggruppen übermittelt werden. Informationen hierzu finden Sie unter Nachrichtenroutingarchitektur. Mit Protokollereignissenken lassen sich auch Standard-SMTP- und ESMTP-Befehle wie EHLO ändern, um den Funktionsumfang des SMTP-Protokolls zu erweitern. Informationen zu Protokollereignissenken finden Sie unter SMTP-Protokollerweiterungen.
SMTP-Speicherereignisse Mithilfe dieser Ereignisse können Speicherereignissenken (Implementierungen von Informationsspeichertreibern) den Inhalt von Nachrichten in Dateisystemverzeichnissen oder im Exchange-Informationsspeicher beibehalten. Informationsspeicherereignisse werden beispielsweise im Transportsubsystem von Exchange Server 2003 für die lokale Übermittlung an Exchange-Empfänger verwendet. Informationen über Speichertreiber finden Sie unter Informationsspeichertreiber des SMTP-Diensts.
SMTP-Transportereignisse Diese Ereignisse treten auf, wenn Nachrichten am Server ankommen, das zentrale Transportsubsystem durchlaufen oder an Exchange-Empfänger übermittelt bzw. an andere SMTP-Hosts weitergegeben werden. In Exchange Server 2003 dienen Transportereignisse zum Kategorisieren und Routing von Nachrichten. Informationen zum Routingmodul finden Sie unter
248
Nachrichtenroutingarchitektur. Informationen zu Kategorisierungsereignissenken erhalten Sie unter SMTP-Transportkomponenten.
SMTP-Systemereignisse Diese Ereignisse werden in Aufrufe für eine Senke übersetzt, die als Systemkomponente fungiert. Beispielsweise ist die SMTP-Ereignisprotokollsenke eine Systemkomponente, die Systemereignisse registriert, um interne Verarbeitungsinformationen in das Anwendungsereignisprotokoll zu schreiben.
Ereignissenken im SMTP-Dienst
Hinweis: SMTP-Ereignissenken ermöglichen anderen Herstellern als Microsoft die Implementierung benutzerdefinierter Erweiterungen, wie E-Mail-Filter und Virenscanner, für das SMTP-Transportsubsystem. SMTP-Ereignissenken unterstützen keine COM+-Anwendungen.
Ereignisverteiler und EreignisbenachrichtigungenWenn ein Ereignis eintritt, überprüft ein als Ereignisverteiler fungierender Thread des SMTP-Diensts die Ereignisregistrierungen (die als Ereignisbindungen in der IIS-Metabasis gespeichert sind), um festzustellen, ob Ereignissenken damit verknüpft sind. Der Ereignisverteiler ermittelt alle Ereignissenken, die zum Ausführen registriert sind, und bestimmt den jeweiligen Ausführungszeitpunkt. Die Reihenfolge ist von der Priorität der
249
Senke abhängig, die in den Ereignisbindungsinformationen festgelegt wurde. Die Senken werden nacheinander über Ereignisse benachrichtigt. Die Senken mit der niedrigsten Priorität werden zuerst ausgeführt.
Für jede Senke wird der folgende Vorgang ausgeführt:
1. Der Ereignisverteiler vergleicht die Ereignisregistrierung der Senke mit den Ereignisbedingungen. Wenn die Bedingungen erfüllt werden, wird die Senke ausgeführt.
Hinweis: Einige SMTP-Ereignisse, z. B. Speicherereignisse, haben keine Ereignisbedingungen.
2. Gegebenenfalls erstellt der Ereignisverteiler mithilfe der Klassen-ID (CLSID) der COM-Klasse für die Ereignissenke eine Instanz der Senke.
Hinweis: Senken können zwischengespeichert werden, um diesen Schritt bei folgenden Ereignissen zu vermeiden.
3. Der Ereignisverteiler ruft die COM-Methode IUnknown::QueryInterface auf, um die geeignete Ereignisbenachrichtigungs-Schnittstelle der Ereignissenke abzurufen. Die meisten Senken implementieren die Senkenschnittstelle mithilfe der ATL (Active Template Library).
4. Der Ereignisverteiler führt die Senke aus, indem er die entsprechende Ereignismethode für die Senkenschnittstelle aufruft. Für Transportereignisse übergibt der Ereignisverteiler die Nachricht in Form eines MailMsg-Objekts an die Ereignisschnittstelle. Dieses Objekt enthält die gesamte Nachricht und die Felder des Transportumschlags. Die Nachricht und die Umschlagfelder können von der Senke geändert werden.
5. Wenn die Senke die Verarbeitung abgeschlossen hat, übermittelt sie ein Ereignisstatuskennzeichen an den Ereignisverteiler. Der Ereignisverteiler überprüft dieses Kennzeichen, um festzustellen, ob die nachfolgenden Senken benachrichtigt werden müssen. Beispielsweise könnte der Ereignisverteiler von einer Ereignissenke angewiesen werden, alle verbleibenden Senken zu überspringen, um jede weitere Verarbeitung von Nachrichten abzubrechen.
Ereignissenken zeigen mit den folgenden Rückgabecodes an, ob nachfolgende Senken benachrichtigt werden müssen:
S_OK Senken mit gleicher oder niedrigerer Priorität werden aufgerufen.
S_FALSE Senken mit gleicher oder niedrigerer Priorität werden nicht aufgerufen.
Hinweis: SMTP-Protokollereignissenken können auch den Wert MAILTRANSPORT_S_PENDING zurückgeben und damit anzeigen, dass die
250
Verarbeitung durch Aufrufen der NotifyAsyncCompletoin-Methode asynchron abgeschlossen wird. Eine Protokollereignissenke kann die NotifyAsyncCompletion-Methode aufrufen, um dem eingehenden Protokollereignisverteiler mitzuteilen, dass die asynchrone Verarbeitung abgeschlossen ist, und um das Verarbeitungsergebnis zu übermitteln.
6. Bei Transportereignissen wird, nachdem jede Senke benachrichtigt wurde oder eine Senke anzeigt, dass die verbleibenden Senken übersprungen werden, das Statusumschlagfeld der Nachricht überprüft, um die nächste Aktion festzulegen. Eine Nachricht kann entweder an den entsprechenden Ort gesendet, verworfen oder im Dateisystem im Ordner \Badmail des virtuellen SMTP-Servers abgelegt werden.
Hinweis: Im SMTP-Dienst übernehmen das Protokollmodul und das erweiterte Warteschlangenmodul die Funktion des Ereignisverteilers. Das Protokollmodul verteilt Protokollereignisse. Das erweiterte Warteschlangenmodul verteilt Transportereignisse. Sowohl das Protokollmodul als auch das erweiterte Warteschlangenmodul verteilen auch Speicher- und Systemereignisse.
VerwaltungsschnittstellenDas wichtigste Programm für die Verwaltung von SMTP-Protokolleinstellungen und virtuellen SMTP-Servern auf einem Server mit Exchange Server 2003 ist der Exchange-System-Manager, insbesondere das Exchange SMTP-Snap-In (\Programme\Exchsrvr\bin\SMTPMgr.dll). Dieses Snap-In befindet sich im Exchange-System-Manager unter jedem Serverobjekt im Container SMTP unter Protokolle. Es können fast alle für den eingehenden Nachrichtenverkehr geltenden SMTP-Einstellungen und mit Einschränkungen auch die Einstellungen für ausgehende Nachrichten geändert werden. Mit dem Exchange-System-Manager können Sie auch zusätzliche virtuelle SMTP-Server auf Ihrem Exchange-Server erstellen. Jeder virtuelle SMTP-Server bildet eine Instanz des SMTP-Diensts und wird durch eine eindeutige Kombination aus einer IP-Adresse und einer TCP-Portnummer definiert. Jeder virtuelle SMTP-Server löst seine eigenen Ereignisse aus und verwaltet seinen eigenen Satz an Ereignissenken. Weitere Informationen über die Konfiguration von virtuellen SMTP-Servern finden Sie im Transport- und Routing-Handbuch für Exchange Server 2003 .
Hinweis: Das Erstellen mehrerer virtueller SMTP-Server auf einem Server mit Exchange Server 2003 führt nicht zu einer Steigerung der Systemleistung. Jeder virtuelle SMTP-Server arbeitet im Multithreadmodus und kann zahlreiche Verbindungen gleichzeitig verarbeiten. Beispielsweise sind in der Standardeinstellung maximal 100 gleichzeitige ausgehende Verbindungen pro SMTP-Domäne festgelegt, und die maximale Zahl aller gleichzeitigen ausgehenden Verbindungen insgesamt beträgt 1.000.
251
Konfigurationseinstellungen und EreignisbindungenDas SMTP-Transportsubsystem von Exchange Server 2003 greift für Konfigurationseinstellungen auf die folgenden drei Repositorys zurück:
Active Directory Der Exchange-System-Manager speichert die meisten Konfigurationsinformationen in Active Directory und ruft sie auch von dort ab. So werden zum Beispiel die Eigenschaften und Einschränkungen von Empfängern, die Routingtopologie einer Exchange-Organisation einschließlich aller Routinggruppen und Messaging-Connectors in Active Directory definiert. Wie unter Exchange Server 2003 und Active Directory erläutert, kommunizieren die Komponenten im SMTP-Transportsubsystem zum Abrufen dieser Informationen mit Active Directory.
IIS-Metabasis Die im Lieferumfang von Windows Server 2003 enthaltenen Kernkomponenten des SMTP-Diensts unterstützen Active Directory nicht. Beispielsweise müssen alle Einstellungen, die Sie auf einem virtuellen SMTP-Server vornehmen, von Active Directory in die IIS-Metabasis übertragen werden. Dies ist die Aufgabe des Metabasis-Aktualisierungsdiensts. Der Metabasis-Aktualisierungsdienst registriert sich beim Konfigurationsdomänencontroller, der von Exchange Server 2003 verwendet wird, um Benachrichtigungen über alle Änderungen an der eigenen Konfiguration zu erhalten. Diese Benachrichtigungen erfolgen innerhalb von 15 Sekunden nach einer Änderung. Sobald die Änderung auf den Konfigurationsdomänencontroller repliziert wurde, repliziert der IIS-Metabasis-Aktualisierungsdienst die Änderung in die IIS-Metabasis.
Registrierung Die meisten Konfigurationseinstellungen, die Sie für das SMTP-Transportsubsystem konfigurieren können, werden in Active Directory oder der IIS-Metabasis gespeichert. Allerdings werden einige Systemparameter, die Auswirkungen auf den SMTP-Dienst haben, zum Beispiel MaxPercentPoolThreads or AdditionalPoolThreadsPerProc, in der Registrierungsdatenbank unter folgendem Schlüssel gespeichert: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSVC.
Ebenfalls von wesentlicher Bedeutung ist der folgende Schlüssel: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\InetInfo. Dieser Schlüssel enthält Konfigurationsparameter für den Inetinfo-Prozess, der als Host für den SMTP-Dienst fungiert. Weiter oben in diesem Abschnitt wurden weitere wichtige Registrierungsparameter beschrieben.
Da es sich bei allen SMTP-Ereignissenken um COM-Komponenten handelt, müssen sie in der Registrierung unter der HKEY_CLASSES_ROOT-Struktur registriert werden. Sie können COM-Komponenten unter Verwendung von Regsvr32.exe manuell in die Registrierung ein- bzw. austragen.
252
Konfigurationsinformationen in Active DirectoryDer Exchange-System-Manager speichert Konfigurationsinformationen für virtuelle SMTP-Server auf der Konfigurationsverzeichnispartition von Active Directory. Jeder virtuelle Server wird durch ein eigenes Konfigurationsobjekt repräsentiert. Der Speicherort dieses Objekts entspricht der im Exchange-System-Manager dargestellten Hierarchie der Konfigurationsobjekte, und der allgemeine Name entspricht der Ziffer des virtuellen Servers in der IIS-Metabasis. Zum Beispiel ist der virtuelle Standardserver für SMTP der erste virtuelle SMTP-Server in IIS. Der entsprechende gemeinsame Name (CN – Common Name) des Konfigurationsobjekts des virtuellen Standardservers für SMTP in Active Directory lautet daher 1 (siehe folgendes Beispiel: CN=1,CN=SMTP,CN=Protocols,CN=SERVER01,CN=Servers,CN=First administrative
Group,CN=Administrative Groups,CN=TailspinToys,CN=Microsoft
Exchange,CN=Services,CN=Configuration,DC=TailspinToys,DC=com).
In der folgenden Tabelle werden wichtige Konfigurationsinformationen aufgeführt, die von Exchange Server 2003 für virtuelle SMTP-Server in Active Directory gespeichert werden. Informationen über das Verwalten der Einstellungen für virtuelle SMTP-Server in Active Directory über Programmcode finden Sie unter Setting Message Restriction on an SMTP Virtual Server Using ADSI.
Wichtige Attribute für virtuelle SMTP-Server in Active Directory
Active Directory-Attribut Beschreibung
msExchServerBindings Legt die IP-Portbindungen (Internet Protocol) für SSL-Verbindungen (Secure Sockets Layer) fest.
msExchAuthenticationFlags Gibt an, welchen Authentifizierungstyp dieser virtuelle SMTP-Server akzeptiert.
msExchMaxIncomingConnections Legt die maximale Anzahl eingehender Verbindungen fest, die für diesen virtuellen SMTP-Server zugelassen sind.
msExchLogType Legt die Protokollformate fest, die dieser virtuelle SMTP-Server zur Protokollaufzeichnung verwendet.
msExchAccessSSLFlags Gibt an, welche Art von verschlüsseltem Kanal dieser virtuelle SMTP-Server unterstützt.
253
Active Directory-Attribut Beschreibung
msExchServerAutoStart Legt fest, wann der virtuelle Server gestartet werden soll. Wenn der Wert TRUE ist, wird der virtuelle Server beim Starten des Betriebssystems gestartet.
msExchNTAuthenticationProviders Legt eine Liste von SSPI-Paketen (Security Support Provider Interface) fest, die zur Authentifizierung für diesen SMTP-Server verwendet werden können. Exchange Server 2003 unterstützt die Kerberos-Authentifizierung über GSSAPI (Generic Security Services Application Programming Interface) sowie das ältere Microsoft Windows NT LAN Manager Authentication Protocol (NTLM).
msExchIncomingConnectionTimeout Legt die maximale Zeitspanne fest, nach der inaktive eingehende Verbindungen beendet werden.
msExchSmtpMaxOutgoingConnections Legt die maximale Anzahl ausgehender Verbindungen für diesen virtuellen SMTP-Server fest.
msExchSmtpOutgoingConnectionTimeout Legt die maximale Zeitspanne fest, nach der inaktive ausgehende Verbindungen beendet werden.
msExchSmtpMaxOutgoingConnectionsPerDomain
Legt die maximale Anzahl ausgehender Verbindungen zwischen diesem virtuellen SMTP-Server und einer bestimmten Domäne fest.
msExchSmtpOutgoingPort Legt die Portnummer für ausgehende Verbindungen fest, über die der virtuelle SMTP-Server Kontakt zu einem SMTP-Remotehost aufnimmt.
msExchSmtpOutgoingSecurePort Legt die Portnummer für ausgehende Verbindungen fest, über die der virtuelle SMTP-Server Kontakt zu einem SMTP-Remotehost aufnimmt, wenn der Übertragungskanal mit TLS (Transport Layer Security) geschützt ist.
254
Active Directory-Attribut Beschreibung
msExchSmtpMaxHopCount Legt die maximal zulässige Anzahl der Hops für den Nachrichtentransport von diesem virtuellen SMTP-Server zum Zielort fest.
msExchSmtpMaxMessageSize Legt die maximal zulässige Größe einer über diesen virtuellen SMTP-Server übermittelten Nachricht fest.
msExchSmtpMaxSessionSize Legt das maximale Datenaufkommen in KB fest, das pro SMTP-Sitzung übertragen werden kann.
msExchSmtpMaxRecipients Legt die maximale Anzahl der Empfänger fest, die für eine von diesem virtuellen SMTP-Server übermittelte Nachricht zulässig sind.
msExchSmtpLocalQueueExpirationTimeout Legt die Zeitspanne fest, nach der eine nicht zugestellte lokale Nachricht von diesem virtuellen SMTP-Server verworfen wird.
msExchSmtpLocalQueueDelayNotification Legt die Zeitspanne fest, nach der dieser virtuelle SMTP-Server den Absender benachrichtigen muss, dass eine lokale Nachricht ihr Ziel nicht erreicht hat.
msExchSmtpRemoteQueueExpirationTimeout
Legt die Zeitspanne fest, nach der eine nicht zugestellte ausgehende Nachricht von diesem virtuellen SMTP-Server verworfen wird.
msExchSmtpRemoteQueueDelayNotification
Legt die Zeitspanne fest, nach der dieser virtuelle SMTP-Server den Absender benachrichtigen muss, dass eine ausgehende Nachricht ihr Ziel nicht erreicht hat.
msExchSmtpSmartHost Legt eine Smarthost-Route für ausgehende Nachrichten von diesem virtuellen SMTP-Server fest.
msExchSmtpSmartHostType Legt den Typ des Smarthost fest.
255
Active Directory-Attribut Beschreibung
msExchSmtpMaxOutboundMsgPerDomain Legt die maximale Anzahl ausgehender Nachrichten pro Domäne fest, die dieser virtuelle SMTP-Server in einer Sitzung übermitteln kann.
msExchSmtpOutboundSecurityFlag Legt fest, welcher Authentifizierungstyp bei ausgehenden Verbindungen von diesem virtuellen SMTP-Server aus verwendet wird.
msExchSmtpInboundCommandSupportOptions
Legt fest, welche SMTP-Befehle für eingehende Verbindungen unterstützt werden. Durch die Änderung dieses Werts können Features wie 8BITMIME, BDAT, CHUNKING und PIPELINING deaktiviert werden.
msExchSmtpRelayForAuth Legt fest, ob für das Weitergeben von Nachrichten eine Authentifizierung erforderlich sein soll.
msExchSmtpPerformReverseDnsLookup Legt fest, ob für die Zustellung DNS-Reverse-Lookups (Domain Name System) durchgeführt werden sollen.
msExchSmtpDoMasquerade Legt fest, ob für Unzustellbarkeitsberichte eine Maskeradendomäne verwendet werden soll. Wenn aktiviert, wird die Maskeradendomäne verwendet. Unzustellbarkeitsberichte werden an die Alternativdomäne und nicht an die Domäne zurückgegeben, aus der die E-Mail-Nachrichten ursprünglich stammen.
msExchSmtpBadMailDirectory Legt den Speicherort im Dateisystem für Badmail fest (Nachrichten aus dem Ordner BadMail).
jmsExchSmtpSendBadmailTo Legt eine Adresse fest, an die Badmail gesendet werden soll.
msExchSmtpFullyQualifiedDomainName Legt den vollqualifizierten Domänennamen (FQDN – Fully Qualified Domain Name) für diesen virtuellen SMTP-Server fest.
msExchSmtpPickupDirectory Legt das Verzeichnis fest, aus dem E-Mail-Nachrichten abgerufen werden.
256
Active Directory-Attribut Beschreibung
msExchSmtpQueueDirectory Legt das Verzeichnis fest, aus dem E-Mail-Nachrichten in der Warteschlange platziert werden.
msExchSmtpRemoteQueueRetries Legt den ersten, zweiten, dritten und alle folgenden Versuche für die Zustellung von Remotemail fest.
msExchSmtpRelayIpList Legt eine Liste von IP-Adressen für Weitergabeeinschränkungen fest.
msExchBridgeheadedLocalConnectorsDNBL
Legt eine Liste von Connectors in der Routinggruppe des virtuellen SMTP-Servers fest, für die dieser virtuelle SMTP-Server als Bridgehead fungiert.
msExchBridgeheadedRemoteConnectorsDNBL
Legt eine Liste von Connectors in Remoteroutinggruppen fest, für die dieser virtuelle SMTP-Server als Bridgehead fungiert.
Hinweis: Der Metabasis-Aktualisierungsdienst repliziert sämtliche dieser Konfigurationseinstellungen in die IIS-Metabasis.
SMTP-Konfigurationseinstellungen in der MetabasisBei IIS-Metabasis handelt es sich um einen hierarchischen Informationsspeicher für Konfigurations- und Schemainformationen, der zur Konfiguration von IIS-Ressourcen verwendet wird. Die Konfigurationseinstellungen und Schemata für IIS 4.0 und IIS 5.0 werden in einer Binärdatei (MetaBase.bin) gespeichert, die allerdings nur schwer gelesen und bearbeitet werden kann. Zum Lesen und Bearbeiten der Metabasis für IIS 4.0 und IIS 5.0 benötigen Sie das Tool MetaEdit. MetaEdit 2.2 kann unter folgender Adresse heruntergeladen werden: http://go.microsoft.com/fwlink/?LinkId=47942.
In IIS 6.0 wurden die früheren Binärdateien durch Dateien im XML-Format (Extensible Markup Language) mit der Bezeichnung MetaBase.xml und MBSchema.xml ersetzt. Die Konfigurationsinformationen für IIS werden in der Datei MetaBase.xml und das Schema der Metabasis in der Datei MBSchema.xml gespeichert. Beim Starten von IIS werden diese Dateien von der Metabasis-Speicherschicht gelesen und anschließend durch
257
Verwaltungsdatenbankobjekte (ABO – Admin Base Objects) in die Metabasis im Arbeitsspeicher geschrieben (siehe folgende Abbildung).
Die Metabasis-Architektur von IIS 6.0
SMTP-KonfigurationsschlüsselMitglieder der lokalen Administratorgruppe können die Datei MetaBase.xml anzeigen und ändern. Bei der Datei handelt es sich um eine unformatierte Textdatei, die sich im Ordner "\Windows\System32\Inetsrv" befindet. Metabasis-Einträge, die sich auf den SMTP-Dienst und seine virtuellen SMTP-Server beziehen, beginnen mit "IIsSmtp".
Die Hierarchie der Konfigurationsobjekte wird in den Konfigurationseinträgen über die Eigenschaft Location definiert. In dem Eintrag Location ="/LM/SmtpSvc/1" steht „LM“ beispielsweise für den lokalen Computer, "SmtpSvc" steht für den SMTP-Dienst im Allgemeinen, und die Ziffer 1 repräsentiert den virtuellen SMTP-Server. Der Zähler 1 entspricht dem CN-Attribut des virtuellen SMTP-Standardserverobjekts in Active Directory.
In der folgenden Abbildung wird die Hierarchie der Konfigurationseinträge für virtuelle SMTP-Server entsprechend der Eigenschaft Location für jeden IIsSmtp-Metabasis-Eintrag dargestellt.
258
Hierarchie der SMTP-Konfigurationseinträge in der IIS-Metabasis
Parameter, die sich auf den SMTP-Dienst im Allgemeinen beziehen, werden in der Metabasis im Knoten "SmtpSvc" gespeichert. Sie finden diesen Knoten, indem Sie nach Location ="/LM/SmtpSvc" suchen. Im folgenden Abschnitt wird eine abgekürzte Auflistung dieses Schlüssels aufgeführt:
<IIsSmtpService Location ="/LM/SmtpSvc"
ConnectionTimeout="600"
DefaultDomain="server01.TailspinToys.com"
DomainRouting=""
EnableReverseDnsLookup="FALSE"
FullyQualifiedDomainName="server01.TailspinToys.com"
259
...
SmtpRemoteProgressiveRetry="15,30,60,240"
SmtpRemoteRetryThreshold="3"
>
<Custom
Name="AuthFlags"
ID="6000"
Value="AuthBasic | AuthAnonymous | AuthNTLM"
Type="DWORD"
UserType="IIS_MD_UT_SERVER"
Attributes="INHERIT"
/>
...
<Custom
Name="UnknownName_61537"
ID="61537"
Value="0"
Type="DWORD"
UserType="IIS_MD_UT_SERVER"
Attributes="NO_ATTRIBUTES"
/>
</IIsSmtpService>
Unter dem Knoten "SmtpSvc" befinden sich die Konfigurationseinstellungen für jeden virtuellen SMTP-Server, den Sie auf dem Server mit Exchange Server 2003 erstellt haben. Virtuelle SMTP-Server erben die für den SMTP-Dienst konfigurierten allgemeinen Einstellungen und können diese Einstellungen überschreiben. Im Folgenden wird eine schematische Auflistung des Konfigurationsabschnitts für den virtuellen Standardserver für SMTP aufgeführt. Beachten Sie insbesondere die Angaben für Location.
<IIsSmtpServer Location ="/LM/SmtpSvc/1"
... property definitions that apply only to the
particular virtual server ...
>
260
<Custom
... custom property defintion...
/>
</IIsSmtpServer>
Hinweis: Wenn Sie die Parameternamen für virtuelle SMTP-Server in der IIS-Metabasis mit den Attributen für virtuelle SMTP-Server in Active Directory vergleichen, werden Sie eine enge Übereinstimmung feststellen. So entspricht zum Beispiel der Metabasis-Parameter PickupDirectory dem Active Directory-Attribut msExchSmtpPickupDirectory.
Direktes Bearbeiten der MetabasisDas es sich bei der Datei MetaBase.xml um eine Textdatei handelt, können Mitglieder der Administratorgruppe die Metabasis von IIS 6.0 direkt mit üblichen Text-Editoren wie Editor bearbeiten. Wenn IIS ausgeführt wird, ist diese Datei allerdings geöffnet und gesperrt. Für das direkte Bearbeiten müssen Sie im IIS-Manager die Option Direktes Bearbeiten der Metabasis ermöglichen aktivieren. Detaillierte Anweisungen zum Aktivieren der direkten Bearbeitung der IIS-Metabasis finden Sie unter Aktivieren der Option „Direktes Bearbeiten der Metabasis ermöglichen“ im IIS-Manager.
Registrierung lokaler DomänenUnter jedem virtuellen SMTP-Serverknoten in der Metabasis befinden sich wichtige untergeordnete Knoten, zum Beispiel die Knoten Domain (Location ="/LM/SmtpSvc/1/Domain") und EventManager (Location ="/LM/SmtpSvc/1/EventManager"). Der Domänenknoten enthält Definitionen zur Festlegung der Routing-Aktionen, die der virtuelle SMTP-Server durchführen soll. Zum Beispiel muss der SMTP-Dienst, entsprechend der Definitionen in den Empfängerrichtlinien, Nachrichten für alle lokalen SMTP-Domänen akzeptieren, während er unter Umständen gleichzeitig alle Versuche, Nachrichten an nicht lokale Domänen weiterzugeben ablehnen soll. Der Metabasis-Aktualisierungsdienst repliziert die Domäneninformationen aus den Empfängerrichtlinien für alle virtuellen SMTP-Server in die IIS-Metabasis.
Hinweis: Die Domäneninformationen enthalten auch Einträge, die auf Active Directory-Standorte verweisen. Ein Beispiel für einen solchen Domänenamen ist 705260ab-46c4-454d-bfdd-96b9c605364c._msdcs.fabrikam.com. Die Routing-Aktion für diese Einträge veranlasst den virtuellen SMTP-Server dazu, die Nachrichten im Verzeichnis \Drop abzulegen, aus dem sie von Active Directory abgerufen werden
261
können. Sie sollten diese Domäneneinträge nicht ändern oder löschen, um Probleme bei der Verzeichnisreplikation zu vermeiden. Active Directory verwendet den SMTP-Dienst für die Replikation von Änderungen an Verzeichnissen zwischen Standorten.
Registrierung von EreignissenkenBei den Einträgen unter dem Knoten EventManager handelt es sich um Ereignisregistrierungen. Damit der SMTP-Dienst mit Ereignissenken arbeiten kann, müssen diese in der IIS-Metabasis registriert sein, sodass sie vom SMTP-Dienst erstellt und ausgeführt werden können, wenn entsprechende Ereignisse eintreten. Objekte vom Typ IIsConfigObject definieren Ereignisbindungen in der IIS-Metabasis. Beispiel:
<IIsConfigObject Location ="/LM/SmtpSvc/1/EventManager/
EventTypes/{283430C9-1850-11D2-9E03-00C04FA322BA}/
Bindings/{A928AD15-1610-11D2-9E02-00C04FA322BA}/
SinkClass"
>
<Custom
Name="MD_0"
ID="0"
Value="Exchange.Router"
Type="STRING"
UserType="UNKNOWN_UserType"
Attributes="NO_ATTRIBUTES"
/>
</IIsConfigObject>
Diese Bindung ordnet dem globalen eindeutigen Bezeichner (GUID) eines bestimmten Ereignisses (z. B. 283430C9-1850-11D2-9E03-00C04FA322BA) eine Ereignissenke (z. B. die Senke Exchange Router) zu. Der zweite GUID-Eintrag in den Bindungsinformationen {A928AD15-1610-11D2-9E02-00C04FA322BA} ist die Kennung (ID) dieses speziellen Ereignisbindungseintrags. Die Kennungen von Ereignisbindungen müssen in der Metabasis eindeutig sein. Einem bestimmten Ereignis können jedoch mehrere Ereignissenken zugeordnet sein (siehe Abbildung 6.4 weiter oben in diesem Abschnitt).
Die Parameter von Ereignisbindungen werden in der Metabasis-Hierarchie unter jedem Knoten einer Ereignissenke definiert. Im obigen Codebeispiel wird ein Wert SinkClass definiert, über den eine Zuordnung zwischen dem SMTP-Transportereignis OnGetMessageRouter und der Senkenklasse Exchange.Router erstellt wird. Es gibt
262
darüber hinaus weitere Bindungseinträge, mit denen der Anzeigename der Ereignissenke als Exchange Router sowie andere Parameter, wie die Priorität der Ereignissenke, definiert werden. In der folgenden Tabelle werden Parameter aufgeführt, die für eine Ereignisbindung festgelegt werden können.
Ereignisbindungsinformationen
Beschreibung der Eigenschaft Beschreibung der Eigenschaft
ID Ein globaler Bezeichner (GUID), über den die Bindung eindeutig identifiziert wird. Diese Angabe ist erforderlich.
DisplayName Ein optionaler benutzerfreundlicher Name für die Bindung.
SinkClass Die ProgID (Programmatic Identifier) der Klasse der Ereignissenke.
Aktiviert Ein Kennzeichen, das anzeigt, ob die Bindung gegenwärtig aktiviert ist. Wenn für dieses Kennzeichen kein Eintrag vorhanden ist, ist die Ereignissenke aktiviert. Dieser Parameter ist optional.
MaxFirings Die Anzahl der Ereignisbenachrichtigungen, die die Senke empfangen kann, bevor die Bindung deaktiviert wird. Dieser Parameter ist optional.
EventBindingProperties Ein Wörterbuch (oder Hash) mit zusätzlichen für die gesamte Bindung definierten Eigenschaften. Dieser Parameter ist optional.
SinkProperties Senkeneigenschaften gelten jeweils nur für die Implementierung einer bestimmten Senke. Wenn eine Senke eine Benachrichtigung über Ereignis erhält, gibt der Ereignisverteiler die gesammelten Senkeneigenschaften an die Ereignissenke weiter. Zum Beispiel kann eine Ereignissenke, mit der einer Nachricht eine Haftungsausschlusserklärung hinzugefügt wird, den entsprechenden Text über eine Senkeneigenschaft empfangen.
263
Beschreibung der Eigenschaft Beschreibung der Eigenschaft
SourceProperties Quelleigenschaften werden jeweils durch eine Implementierung eines Ereignisverteilers definiert. Zum Beispiel verwendet der Ereignisverteiler für ein- und ausgehende Protokollereignisse die Eigenschaften Rule und Priority, um festzulegen, wann eine Senke über ein Ereignis benachrichtigt wird. Die meisten Transportereignissenken verwenden bis auf das Ereignis OnTransportSubmission keine Rule-Quelleigenschaften. Alle Protokoll- und Transportereignisse unterstützen die Verwendung der Quelleigenschaft Priority.
Die folgenden Quelleigenschaften werden für Ereignisbindungen und Protokoll- und Transportereignisse verwendet:
Rule Eine Zeichenkette, die einen Protokollfilter für die Senkenbindung kennzeichnet. Der Verteiler verwendet die Regel als Bedingung bzw. als Gruppe von Bedingungen, die festlegen, ob die Senke benachrichtigt wird. Die Regeln sind SMTP-Protokollbefehlsregeln, zum Beispiel EHLO. Regeln können Bedingungen wie EHLO=*.contoso.com beinhalten. Mehrere Regeln werden durch Semikolons getrennt.
Priority Die Benachrichtigungspriorität der Senke im Vergleich zu anderen Senken, die für den Empfang von Benachrichtigungen über das Ereignis registriert sind. Der Wertebereich liegt zwischen 0 (höchste Priorität) und 32767 (niedrigste Priorität). Diese Eigenschaft ist optional. Die Standardeinstellung lautet 24575. Senken mit derselben Priorität werden ohne bestimmte Reihenfolge ausgeführt.
264
ServererweiterungsobjekteGlobale eindeutige Bezeichner in Ereignissenken gewährleisten eine eindeutige Verknüpfung zwischen einem Ereignistyp und einer Ereignissenke. Diese Bezeichner können jedoch problematisch sein, da sie nicht zwingend logisch sind. Wenn Sie zum Beispiel wissen möchten, welches Ereignis der Ereignissenke in der Liste aus der vorstehenden Tabelle zugeordnet ist, müssen Sie in der Registrierung unter HKEY_CLASSES_ROOT\Component Categories nach dem globalen Bezeichner 283430C9-1850-11D2-9E03-00C04FA322BA suchen. Sie können dann feststellen, dass dieser Bezeichner das SMTP-Transportereignis vom Typ OnGetMessageRouter kennzeichnet. Der zweite globale Bezeichner in diesem Beispiel einer Bindungsdefinition, A928AD15-1610-11D2-9E02-00C04FA322BA, ist die in der Datei Reapi.dll implementierte Klassen-ID (CLSID) der Klasse Exchange Router. Der Registrierungsschlüssel für diese COM-Komponente lautet HKEY_CLASSES_ROOT\CLSID\{A928AD15-1610-11d2-9E02-00C04FA322BA}. Allerdings wird mit dieser Klassen-ID lediglich eine eindeutige Kennung für die Ereignisbindung in der Metabasis erstellt. Worauf es eigentlich ankommt ist der SinkClass-Wert, der die Verknüpfung zwischen dem Ereignistyp und der Klasse der Ereignissenke definiert.
Sie müssen jedoch nicht mit globalen Bezeichnern arbeiten, um die Bindungen von Ereignissenken zu verwalten. Sie können stattdessen die in der Datei Seo.dll implementierten Servererweiterungsobjekte verwenden. Microsoft hat ein Skript entwickelt, in dem veranschaulicht wird, wie Ereignisbindungen für den SMTP-Dienst mithilfe von Servererweiterungsobjekten verwaltet werden. Dieses Skript trägt den Namen SMTPReg.vbs und befindet sich unter smtpreg.vbs Event Management Script. Zusammen mit dem folgenden Befehl können Sie SMTPReg.vbs zum Beispiel dazu verwenden, alle SMTP-Ereignisbindungen aus der IIS-Metabasis in eine Datei mit der Bezeichnung Event_Bindings.txt zu schreiben: cscript smtpreg.vbs /enum > Event_Bindings.txt. In der folgenden Auflistung wird die Ausgabe für den Bindungseintrag Exchange Router dargestellt:
---------
| Binding |
---------
Event: SMTP Transport OnGetMessageRouter
ID: {A928AD15-1610-11D2-9E02-00C04FA322BA}
Name: Exchange Router
SinkClass: Exchange.Router
Enabled: True
SourceProperties: {
265
priority = 8192
}
Aktivieren der Option „Direktes Bearbeiten der Metabasis ermöglichen“ im IIS-ManagerIn diesem Verfahren wird das Aktivieren der Option Direktes Bearbeiten der Metabasis ermöglichen im IIS-Manager erläutert. Dieses Verfahren muss ausgeführt werden, um die Datei MetaBase.xml in der IIS 6.0-Metabase direkt während der Ausführung von IIS zu bearbeiten.Andernfalls bleibt diese Datei geöffnet und gesperrt, wenn IIS ausgeführt wird.
Bevor Sie beginnenBevor Sie das Verfahren in diesem Thema durchführen, sollten Sie Folgendes berücksichtigen:
Da es sich bei der Aktualisierung der IIS-Metabase aus Active Directory um eine Replikation in eine Richtung handelt, sollten Sie beim Ändern von Einstellungen direkt in der IIS-Metabase vorsichtig vorgehen. Es könnte sein, dass der Metabase-Aktualisierungsdienst geänderte Werte für den virtuellen SMTP-Server im nächsten Aktualisierungszyklus überschreibt. Es empfiehlt sich, für die Konfiguration des SMTP-Diensts auf einem Exchange 2003-Server den Exchange-System-Manager zu verwenden und nur diejenigen Parameter zu ändern, die im Exchange-System-Manager nicht vorhanden sind, wie etwa die Einstellung ConnectResponse.
Vorsicht: Eine unsachgemäße Bearbeitung der Metabase kann zu ernsten Problemen führen, die eine Neuinstallation des Exchange-Servers erfordern. Microsoft kann keine Garantie dafür übernehmen, dass Sie die aus einer falschen Bearbeitung der IIS-Metabase resultierenden Probleme beheben können. Die Bearbeitung der Metabase erfolgt auf eigene Gefahr. Stellen Sie sicher, dass Sie über eine aktuelle Sicherungskopie der Metabase-Dateien verfügen, bevor Sie Änderungen vornehmen.
VerfahrenSo aktivieren Sie die Option „Direktes Bearbeiten der Metabasis ermöglichen“ im IIS-
Manager
1. Klicken Sie im IIS-Manager mit der rechten Maustaste auf das Serverobjekt, und klicken
266
Sie anschließend auf Eigenschaften.
2. Aktivieren Sie das Kontrollkästchen Direktes Bearbeiten der Metabasis ermöglichen.
3. Wenn Sie Parameter ändern möchten, die im Exchange-System-Manager nicht zur Verfügung stehen, können Sie direkt die Einstellungen der Metabase bearbeiten. Sie können zum Beispiel das SMTP-Banner Ihres SMTP-Servers ändern, indem Sie dem Konfigurationsobjekt (<IIsSmtpServerLocation ="/LM/SmtpSvc/1">) des virtuellen Standardservers für SMTP, wie im Folgenden beschrieben, einen Wert für die Eigenschaft ConnectResponse hinzufügen, um zu vermeiden, dass bei der SMTP-Kommunikation Exchange-spezifische Versionsinformationen preisgegeben werden:
<IIsSmtpServer Location ="/LM/SmtpSvc/1"
AdminACL="4963... ... ...a472"
ClusterEnabled="FALSE"
ConnectionTimeout="600"
...
4. Wenn Sie nicht gern mit Editor arbeiten, können Sie die Metabase-Einstellungen auch mit ADSI (Active Directory Service Interfaces) bearbeiten. Mit dem folgenden Codeabschnitt erreichen Sie dieselbe Änderung am SMTP-Banner. In der folgenden Abbildung wird das geänderte SMTP-Banner gezeigt.
' Get the configuration object for the default SMTP virtual server
' Configure the ConnectResponse setting
' Write the changed parameter into the metabase
5. Weitere Informationen über den Zugriff auf Einstellungen der IIS-Metabase mithilfe von ADSI finden Sie im Microsoft Platform SDK unter Using ADSI to Configure IIS.
Hinweis: Sie müssen den IIS-Verwaltungsdienst und alle von ihm abhängigen Dienste einschließlich des SMTP-Diensts neu starten, um die Änderungen zu speichern. Der SMTP-Dienst ist so konzipiert, dass Änderungen an der Systemkonfiguration ohne Neustart automatisch übernommen werden können. Bei einigen Änderungen, wie der Änderung des SMTP-Banners, kann jedoch ein Neustart erforderlich sein.
267
Ersetzen der Versionsinformationen von Exchange im SMTP-Banner
Erweitertes WarteschlangenmodulDas erweiterte Warteschlangenmodul ist eine zentrale Komponente für die Nachrichtenverarbeitung in Exchange 2003, da alle Nachrichten dieses Modul durchlaufen müssen, selbst wenn sich Absender und Empfänger auf demselben Server mit Exchange Server 2003 befinden. Auf diese Weise können die Übertragungskomponenten aus Exchange Server 2003 jede Nachricht verarbeiten. Das Transportsubsystem kann von keiner E-Mail-Nachricht umgangen werden.
Hinweis: Der zentrale SMTP-Dienst von Windows Server 2003 verarbeitet empfangene Nachrichten mithilfe eines erweiterten Warteschlangenmoduls, das in der Datei Aqueue.dll implementiert ist. In der erweiterten Version des SMTP-Diensts wird Aqueue.dll nicht verwendet. In Exchange Server 2003 wird diese Komponente durch ein in der Datei Phatq.dll implementiertes erweitertes Exchange-Warteschlangenmodul ersetzt. Um Phatq.dll zu laden, ändert Exchange Server 2003 die Eigenschaft SmtpAdvQueueDll für den SMTP-Dienst in der IIS-Metabase und erstellt einen Verweis auf das erweiterte Exchange-Warteschlangenmodul.
268
Aqueue.dll und Phatq.dll dienen ähnlichen Funktionen, doch nur Phatq.dll ist mit Exchange Server 2003 kompatibel.
Durch das erweiterte Warteschlangenmodul ausgelöste EreignisseDer folgenden Abbildung können Sie entnehmen, dass das erweiterte Warteschlangenmodul als Informationssteuerung oder Verteiler für System-, Speicher- und Transportereignisse agiert, um jede Nachricht nach ihrem Eintritt in das SMTP-Transportsubsystem zu verarbeiten.
Das erweiterte Warteschlangenmodul in der SMTP-Architektur
Das erweiterte Warteschlangenmodul verteilt die folgenden Ereignisse.
SMTP-Transport OnSubmission Dieses Ereignis tritt ein, wenn eine Nachricht über das PICKUP-Verzeichnis, eine SMTP-Verbindung oder den Exchange-Informationsspeichertreiber im Transportsubsystem ankommt. Die Nachricht muss zwecks Kategorisierung, Routing und Zustellung an das erweiterte Warteschlangenmodul weitergegeben werden. Diese Aktion löst ein Ereignis vom Typ OnSubmission (oder OnTransportSubmission) aus. Das erweiterte Warteschlangenmodul ruft mit diesem Ereignis Ereignissenken wie einen Antivirenscanner auf, die alle eingehenden Nachrichten vor jeder weiteren Übertragung überprüfen. Dementsprechend ist zum Beispiel die Exchange-Transportereignissenke AntiVirus API für das Ereignis OnSubmission registriert. Eine weitere für dieses Ereignis registrierte Senke ist die
269
Exchange-Transportereignissenke XEXCH50 Submission, die Nachrichten mit XEXCH50-Umschlagdaten für die weitere Verarbeitung auf Remoteservern mit Exchange Server 2003 vorbereitet.
Hinweis: Das Ereignis OnSubmission ist das einzige Ereignis mit einer CDO-Schnittstelle (Collaboration Data Objects). Sie können Ereignissenken daher mit Microsoft Visual Basic oder Visual Basic Scripting Edition (VBScript) programmieren. Alle anderen Ereignissenken müssen mit C/C++ oder Microsoft Visual C# programmiert werden.
CDO-basierte Ereignissenken können für das Ereignis CDO_OnArrival registriert werden, bei dem es sich um einen Wrapper für das Ereignis OnSubmission handelt, der einen Handle für die Nachricht im CDO-Nachrichtenformat zur Verfügung stellt. Der größte Vorteil bei der Verwendung von CDO_OnArrival besteht darin, dass die CDO-Nachrichtenobjektschnittstelle über zahlreiche hilfreiche Methoden wie etwa die Analyse von MIME- und RFC 822-Headern (Request for Comments) verfügt. Ausführliche Informationen zur Erweiterung des SMTP-Diensts über eine CDO-Senke finden Sie im Microsoft Knowledge Base-Artikel 837851, „How to configure an Internet Information Services SMTP virtual server to archive or to remove messages in an Exchange Server 2003 test environment “.
Der größte Nachteil von CDO-basierten Ereignissenken besteht darin, dass die CDO-Schnittstelle zusätzliche Verarbeitungslast verursacht. VBScript-basierte Ereignissenken sind nicht so schnell wie Senken, die in C, C++ oder Visual C# geschrieben wurden. Beachten Sie auch, dass CDO-basierte Ereignissenken synchron arbeiten und es eine Zeitbegrenzung von 60 Sekunden für die Verarbeitung einer Nachricht gibt. Nach 60 Sekunden geht das erweiterte Warteschlangenmodul davon aus, dass das Skript nicht antwortet, und beendet die Verarbeitung. Das Zeitlimit von 60 Sekunden ist im Code festgelegt und kann nicht geändert werden. Außerdem akzeptiert die CDO-Schnittstelle keine Änderung des Inhalts von Nachrichten, die aus dem Informationsspeicher eingereicht werden. Diese Einschränkung haben die Ereignissenken vom Typ CDO_OnArrival mit allen anderen Ereignissenken gemeinsam. Die Einschränkung besteht, da Exchange eine aus dem Informationsspeicher eingereichte Nachricht in eine temporäre SMTP-Version umwandelt, die von der Ereignissenke bearbeitet werden kann und nach der Verarbeitung verworfen wird. Weitere Informationen zu diesem Thema finden Sie im Microsoft Knowledge Base-Artikel 273233, „PRB: CDOEX: Sie können MAPI-Nachrichten nicht ändern, die in einer SMTP-Transportereignissenke abgefangen werden“
Da Exchange die temporäre Kopie einer vom Informationsspeicher eingereichten Nachricht verwirft, können Sie ausgehenden Nachrichten mit dieser Ereignissenke keine Haftungsausschlusserklärung oder andere Änderungen hinzufügen, es sei denn, Sie erzwingen, dass alle Nachrichten über SMTP empfangen werden. Hierfür müssen Sie die Ereignissenke auf einem Bridgeheadserver installieren, der von den Postfachservern in
270
Ihrer Organisation getrennt ist. Da Server, auf denen Exchange Server 2003 ausgeführt wird, miteinander über SMTP kommunizieren, werden alle an den Bridgehead übermittelten Nachrichten über SMTP empfangen.
SMTP-Transport OnPreCategorize Dieses Ereignis tritt unmittelbar vor dem Senden einer Nachricht an das Kategorisierungsmodul ein. Es hat Ähnlichkeit mit dem Ereignis OnSubmission, bietet jedoch keine CDO-Version. In der Standardeinstellung ist für dieses Ereignis keine Senke registriert.
SMTP-Transport OnCategorize Dieses Ereignis tritt ein, wenn eine Nachricht kategorisiert werden muss. Es handelt sich dabei nicht um ein einzelnes Ereignis, sondern um eine Ereigniskategorie. Für Senken, die an diese Kategorie gebunden sind, können zehn verschiedene Arten von Ereignissen ausgelöst werden. Eine Ereignissenke, die an diese Kategorie gebunden ist, bildet die Senke des Kategorisierungsmoduls, die Absender und Empfänger auflöst und Kategorisierungsinformationen wie den Stammserver jedes Empfängers an das erweiterte Warteschlangenmodul liefert. In Exchange Server 2003 sind zwei Ereignissenken für das Ereignis OnCategorize registriert: Das Exchange-Kategorisierungsmodul und Outlook Mobile Access Push Categorizer (in der IIS-Metabase als Mobile Categorizer registriert). Das Exchange-Kategorisierungsmodul verarbeitet E-Mail-Nachrichten, um Empfängerinformationen aufzulösen, Verteilerlisten aufzugliedern, empfängerspezifische Beschränkungen zu prüfen und vieles mehr. Das mobile Kategorisierungsmodul (Mobile Categorizer) implementiert Aktualisierungsbenachrichtigungen für mobile Geräte.
SMTP-Transport OnPostCategorize Dieses Ereignis tritt direkt nach der Kategorisierung der Nachricht ein. Zu diesem Zeitpunkt wurden alle Verteilerlisten (deren Server für die Aufgliederung von Verteilerlisten ein lokaler Server ist) aufgegliedert, und die tatsächlichen Empfänger sind im Nachrichtenübertragungsumschlag aufgeführt. In der Standardeinstellung ist für dieses Ereignis keine Senke registriert.
Hinweis: Das Exchange-Kategorisierungsmodul kann in einem als Verzweigung bezeichneten Vorgang eine Nachricht in mehrere getrennte Kopien mit unterschiedlichen Inhalten oder Umschlägen aufteilen. Nach der Kategorisierung wird das SMTP-Transportereignis OnPostCategorize für jede Kopie der Nachricht einzeln und unabhängig von den anderen ausgelöst. Die Empfänger der Nachricht können auf mehrere verschiedene Kopien der Nachricht verteilt werden.
SMTP-Transport OnGetMessageRouter Dieses Ereignis tritt ein, wenn eine Nachricht für Remoteempfänger bestimmt ist und weitergeleitet werden muss. Es handelt sich dabei nicht um ein einzelnes Ereignis, sondern um eine Ereigniskategorie. Für eine Senke, die an diese Kategorie gebunden ist, können mehrere Ereignisse ausgelöst werden. Beispielsweise heißt die Senke, die in Exchange Server 2003 die Kennung des Nachrichtentyps und die Informationen über den nächsten Hop ermittelt, Exchange Router. Wie in Nachrichtenroutingarchitektur beschrieben, verwendet das erweiterte
271
Warteschlangenmodul die Senke Exchange Router zur Aktualisierung von Verbindungsstatusinformationen, wenn sich der Status lokaler Messaging-Connectors ändert.
Hinweis: Der zentrale SMTP-Dienst von Windows Server 2003 implementiert keine Routersenke und sendet Nachrichten über Point-to-Point an den endgültigen Empfänger.
SMTP-Transport OnMsgTrackLog Dieses Ereignis tritt ein, wenn das erweiterte Warteschlangenmodul eine Nachricht verarbeitet, damit eine Senke Verfolgungsinformationen über die Nachricht in einer Protokolldatei beibehalten kann. Exchange Server 2003 implementiert eine Senke vom Typ MsgTrackLog für dieses Ereignis, um Statusinformationen über alle Nachrichten, die durch das erweiterte Warteschlangenmodul geleitet werden, in Protokolldateien für die Nachrichtenverfolgung aufzuzeichnen. Diese werden im Verzeichnis \Programme\Exchsrvr\<Servername>.log gespeichert (z. B. \Programme\Exchsrvr\Server01.log).
Hinweis: Standardmäßig ist die Nachrichtenverfolgung deaktiviert.
SMTP-Transport OnDnsResolveRecord Dieses Ereignis tritt ein, wenn ein Domänenname in eine IP-Adresse aufgelöst werden muss. Exchange Server 2003 registriert für dieses Ereignis eine Senke mit dem Namen Exchange LoadBalancer. Sie dient dazu, die bei der Übertragung ausgehender Nachrichten entstehende Arbeitslast für Routinggruppenconnectors auf mehrere Bridgeheadserver zu verteilen.
SMTP-Transport OnMaxMsgSize Dieses Ereignis tritt ein, wenn der Inhalt einer eingereichten Nachricht die in der Konfiguration festgelegte Maximalgröße überschreitet. Eine Senke, die dieses Ereignis verarbeitet, kann die Standardblockierung aufheben. In der Standardeinstellung ist für dieses Ereignis keine Senke registriert.
SMTP StoreDriver Dieses Ereignis tritt ein, wenn eine Nachricht auf Festplatte oder im Exchange-Informationsspeicher gespeichert werden muss. Es handelt sich dabei nicht um ein einzelnes Ereignis, sondern um eine Ereigniskategorie. Für eine Senke, die an diese Kategorie gebunden ist, können mehrere Ereignisse ausgelöst werden. Das erweiterte Warteschlangenmodul löst zum Beispiel zahlreiche Ereignisse vom Typ StoreDriver aus, wenn eine Nachricht das Transportsubsystem durchläuft. Weitere Informationen zu Ereignissenken vom Typ StoreDriver finden Sie weiter unten in diesem Abschnitt.
Hinweis: Ereignisse vom Typ StoreDriver können vom erweiterten Warteschlangenmodul oder dem Protokollmodul ausgelöst werden.
272
Nachrichtenwarteschlangen im erweiterten WarteschlangenmodulDas erweiterte Warteschlangenmodul verwaltet eine Reihe von Nachrichtenwarteschlangen im Arbeitsspeicher. Diese internen Warteschlangen werden von einem internen Pool von Threads bearbeitet. Sie können diese Warteschlangen im Exchange-System-Manager anzeigen. Insbesondere kommuniziert das in Exadmin.dll implementierte Snap-In Exchange-Warteschlangenanzeige über die Verwaltungsschnittstelle für Warteschlangen (PhatQAdm.dll) mit dem erweiterten Warteschlangenmodul, um diese Warteschlangen aufzulisten und Verwaltungsfunktionen für die Warteschlangen, wie das Fixieren von Nachrichten bzw. dessen Aufhebung, durchzuführen. In der folgenden Abbildung sind die wichtigsten Nachrichtenwarteschlangen im erweiterten Warteschlangenmodul und ihr jeweiliger Bezug zu Transportereignissen dargestellt.
Nachrichtenwarteschlangen und Transportereignisse
Das erweiterte Warteschlangenmodul verwendet die folgenden Nachrichtenwarteschlangen:
Nachrichten mit ausstehender Übertragung Diese Warteschlange wird auch als Warteschlange vor der Übermittlung bezeichnet. Dies ist der Eintrittspunkt in das erweiterte Warteschlangenmodul. Das Ereignis OnSubmission wird für alle Nachrichten
273
in dieser Warteschlange ausgelöst. Bei erfolgreicher Ausführung dieses Ereignisses werden die Nachrichten in die Warteschlange vor der Kategorisierung übermittelt.
Nachrichten warten auf Verzeichnissuche Diese Warteschlange wird auch als Warteschlange vor der Kategorisierung bezeichnet. Sie übernimmt eine bremsende Funktion für das Kategorisierungsmodul. In dieser Warteschlange befinden sich Nachrichten, bevor sie in das Kategorisierungsmodul gelangen. Das Kategorisierungsmodul löst unter anderem die Sender- und Empfängerinformationen über Active Directory auf, gliedert Verteilerlisten auf, überprüft Einschränkungen und führt sender- und empfängerspezifische Beschränkungen aus. Das Kategorisierungsmodul wird im Abschnitt „Exchange-Kategorisierungsmodul“ unter SMTP-Transportkomponenten ausführlicher erläutert.
Während der Kategorisierung befinden sich die Nachrichten in keiner Warteschlange. Wenn eine Nachricht kategorisiert wird, befindet sie sich im Kategorisierungsmodul und wird in keiner Warteschlange geführt. Daher kann es sein, dass die Warteschlangenanzeige eine leere Warteschlange vor der Kategorisierung anzeigt, obwohl der Systemmonitor für den Leistungsindikator Ausgeführte Kategorisierungen einen positiven Wert angibt. In der Standardeinstellung erlaubt das erweiterte Warteschlangenmodul maximal 1.000 anstehende Kategorisierungen, bevor Nachrichten in der Warteschlange vor der Kategorisierung zurückgehalten werden. Dieser Schwellenwert kann mit dem folgenden Registrierungsschlüssel geändert werden.
Speicherort HKEY_LOCAL_MACHINE\System\
CurrentControlSet\Services\SMTPSVC\
Queuing
Wert MaxPendingCat
Typ REG_DWORD
Wert 0x3E8
Beschreibung Zeigt die maximale Anzahl anstehender Kategorisierungen an, bevor das erweiterte Warteschlangenmodul damit beginnt, Nachrichten in der Warteschlange vor der Kategorisierung zurückzuhalten. Der Standardwert ist 1.000 Verbindungen.
Nachrichten warten auf Routing Diese Warteschlange wird auch als Warteschlange vor dem Routing bezeichnet. Sie enthält alle Nachrichten, die nach ihrer Kategorisierung, und nachdem Ereignisse nach der Kategorisierung ausgelöst wurden, für die lokale und Remotezustellung in eine Warteschlange kommen. An diesem Punkt legt das erweiterte Warteschlangenmodul fest, welche Nachrichten in die Warteschlange für die lokale Übermittlung gelangen und welche weitergeleitet werden müssen. Für alle Nachrichten
274
an Remoteempfänger gilt, dass das erweiterte Warteschlangenmodul in einem Ereignis vom Typ OnGetMessageRouter das Routingmodul aufruft, um den nächsten Hop für jede Nachricht in dieser Wartschlange festzulegen und die Nachrichten in ihre jeweiligen Verbindungswarteschlangen zu verschieben.
Lokale Übermittlung Wenn sich das Postfach des Empfängers auf dem lokalen Server mit Exchange Server 2003 befindet, werden die Nachrichten durch die Warteschlange vor dem Routing geleitet und gelangen in die Warteschlange für die lokale Übermittlung. Das Kategorisierungsmodul markiert den Empfänger als lokal, indem es, anhand des Empfängerattributs homeMDB, welches auf den Postfachspeicher des Empfängers verweist, eine empfängerspezifische Eigenschaft definiert, die den Zielserver angibt. Bei lokalen Empfängern wird das Ereignis OnGetMessageRouter übersprungen. Das erweiterte Warteschlangenmodul verschiebt Nachrichten in die Warteschlangen für die lokale Übermittlung und löst anschließend ein Ereignis vom Typ StoreDriver aus. Das StoreDriver-Ereignis informiert den Exchange-Informationsspeicherdienst darüber, dass Nachrichten in den Microsoft Exchange-Informationsspeicher übermittelt werden müssen.
Dynamische Übermittlung Bei diesen Warteschlangen handelt es sich um Domänenwarteschlangen, deren Namen mit der Remotedomäne oder der Adresse des nächsten Hop in der Verknüpfung übereinstimmen. Der Name der Warteschlange gibt den Zielort an.
Einen Sonderfall stellt die Nachrichtenübermittlung über den Exchange-MTA dar, die auch als Gatewayübermittlung bezeichnet wird, da der MTA auch für alle MAPI-basierten Connectors zu Messagingsystemen zuständig ist, die nicht mit Exchange arbeiten. Dies wird eingehender in X.400-Transportarchitektur und Architektur von Gateway-Messaging-Connectors erläutert. Das SMTP-Transportsubsystem verwendet den Exchange-Informationsspeichertreiber, um Nachrichten über den Exchange-Informationsspeicher in den bzw. aus dem MTA zu verschieben. Das erweiterte Warteschlangenmodul kann jedoch erst entscheiden, ob eine Nachricht über SMTP oder den MTA übermittelt werden muss, wenn das Routingmodul diese Informationen ausgibt. Wenn der nächste Hop des Empfängers über einen Connector ohne SMTP erfolgt (Routinggruppenconnectors gelten als SMTP-Connectors, es sei denn, die Instanz eines Routinggruppenconnectors hat einen Exchange 5.5-Bridgehead), wird die Nachricht an die Warteschlange des Exchange-MTA und anschließend an die Warteschlange für die lokale Übermittlung gesendet. Vor dort übermittelt sie der Exchange-Informationsspeichertreiber an den Exchange-Informationsspeicher. Anhand der Empfängereigenschaften, die das Kategorisierungsmodul im Nachrichtenübermittlungsumschlag festlegt, lässt sich entscheiden, für welche Empfänger die Übermittlung an ein lokales Postfach bzw. an den Exchange-MTA erfolgen soll.
System Diese Warteschlangen enthalten Nachrichten mit spezifischen Parametern. Die folgende Tabelle enthält eine Liste der vom erweiterten Warteschlangenmodul zusätzlich zu den Übermittlungswarteschlangen verwalteten Systemwarteschlangen.
275
Systemwarteschlangen im erweiterten Warteschlangenmodul
Warteschlange Beschreibung
Nachrichten mit nicht erreichbarem Ziel In dieser Warteschlange befinden sich Nachrichten, die nicht an ihren Zielserver gelangen können. Es kann z. B. sein, dass Exchange eine Route oder einen Connector zum Endziel nicht ermitteln kann oder alle verfügbaren Routen bzw. Connectors als „nicht verfügbar“ gekennzeichnet sind.
Nachrichten in Warteschlange für verzögerte Übermittlung
In dieser Warteschlange befinden sich Nachrichten, die für die spätere Übermittlung in die Warteschlange gestellt werden. Sie kann unter Umständen Nachrichten enthalten, die von älteren Versionen von Microsoft Outlook, z. B. Microsoft Outlook 2000, gesendet wurden. Neuere Versionen von Outlook speichern diese Art von Nachrichten im Exchange-Informationsspeicher. Nachrichten in der Warteschlange für die verzögerte Übermittlung verbleiben bis zu ihrem geplanten Übermittlungszeitpunkt darin.
Hinweis: Diese Warteschlange kann auch Nachrichten enthalten, die an ein Postfach gesendet wurden, das vor kurzem in einen anderen Postfach- oder Exchange-Informationsspeicher verschoben wurde, und die dort verbleiben, bis die Verzeichnisreplikation den Speicherort des Postfachs aktualisiert hat.
276
Warteschlange Beschreibung
DSN-Nachrichten mit ausstehender Übertragung
In dieser Warteschlange befinden sich Benachrichtigungen über den Übermittlungsstatus, die noch von Exchange dargestellt werden müssen. Wenn eine Nachricht zum Beispiel für einen längeren Zeitraum in einer Warteschlange verbleibt, erzeugt das erweiterte Warteschlangenmodul eine Benachrichtigung über den Übermittlungsstatus, um dem Absender mitzuteilen, dass die Nachricht zugestellt wurde. Auch Unzustellbarkeitsberichte (NDR, Non-Delivery Report) sind Benachrichtigungen über den Übermittlungsstatus. Weitere Informationen zu Benachrichtigungen über den Übermittlungsstatus finden Sie in den folgenden Microsoft Knowledge Base-Artikeln:
284204, "Benachrichtigungen zum Übermittlungsstatus in Exchange Server und Small Business Server"
256321, "Enhanced Status Codes for Delivery - RFC 1893“
Nachrichten mit fehlerhafter Übermittlung In dieser Warteschlange befinden sich Nachrichten, die nicht in eine Warteschlange eingefügt werden konnten. Die Übermittlung einer Nachricht in eine Warteschlange kann aus verschiedenen Gründen fehlschlagen. Der Fehler kann sich bereits vor jeder Art von Verarbeitung ereignen. Nachrichten gelangen in diese Warteschlange, wenn sie beschädigt sind oder wenn keine ausreichenden Systemressourcen vorhanden sind.
277
Begrenzen der Anzahl von Nachrichten in WarteschlangenJede Nachricht in einer Warteschlange beansprucht mindestens vier Kilobyte (KB) des Arbeitsspeichers. Eine sehr lange Warteschlange kann daher den Arbeitsspeicher überlasten. Um dies zu vermeiden, können Sie mit dem folgenden Parameter die Anzahl der Nachrichten begrenzen, die sich in einer Warteschlange befinden dürfen.
Vorsicht: Die fehlerhafte Verwendung des Registrierungs-Editors kann zu ernsthaften Problemen führen, die möglicherweise eine Neuinstallation des Betriebssystems erforderlich machen. Microsoft übernimmt keine Garantie dafür, dass durch unsachgemäßes Verwenden des Registrierungs-Editors verursachte Probleme behoben werden können. Sie verwenden den Registrierungs-Editor auf eigene Verantwortung.
Speicherort HKEY_LOCAL_MACHINE\Software\Microsoft\
Exchange\Mailmsg
Wert MaxMessageObjects
Typ REG_DWORD
Wert 0x000186a0
Beschreibung Wenn kein Wert festgelegt wird, beträgt der Standardwert 0x000186a0 (100,000) Nachrichten Die Festlegung eines kleineren Werts verringert die maximale Anzahl an Nachrichten, die sich im erweiterten Warteschlangenmodul befinden. Dadurch wird der maximale Speicherplatzbedarf für SMTP verringert. Nach dem Erreichen dieser Grenze wird für jede SMTP-Verbindung mit dem Server ein Fehler wegen zu geringen Speichers zurückgegeben. Wenn dieser Wert beispielsweise auf 10.000 gesetzt wird, werden alle Nachrichten, die über diesem Wert liegen, von SMTP abgelehnt.
278
SMTP-TransportkomponentenIn Exchange Server 2003 übermittelt das erweiterte Routingmodul Nachrichten mithilfe der folgenden sechs Transportereignissenken an ihre Zielorte:
Exchange-Transport XEXCH50 Submission Diese Ereignissenke ist in Peexch50.dll implementiert und ermöglicht dem SMTP-Transportsubsystem den Empfang von Nachrichten von Exchange-Remoteservern via SMTP über den Befehl XEXCH50. Diese Ereignissenke ist für das Ereignis OnSubmission registriert.
Exchange-Transport AntiVirus API Diese Ereignissenke ist in OnSubmit.dll implementiert und ermöglicht anderen Anbietern als Microsoft die Implementierung von Virenscannern, die jede Nachricht auf bösartige Anlagen und Datenstrukturen untersuchen, bevor sie an ihren Zielort gelangen. Diese Ereignissenke ist für das Ereignis OnSubmission registriert.
In der Standardeinstellung ist das Scannen während der Übertragung deaktiviert, da Nachrichten dadurch zwei Mal (in der SMTP-Schicht und im Exchange-Informationsspeicher) gescannt werden. Wenn Sie eine Exchange-Organisation jedoch via Front-End-Server mit dem Internet verbinden, können Sie die Funktion auf diesen Servern mit dem folgenden Registrierungsschlüssel aktivieren.
Location HKey_Local_Machine\Software\Microsoft\
Exchange\TransportAVAPI
Wert Enabled
Typ REG_DWORD
Daten für Wert 0x1
Beschreibung Das Scannen während der Übertragung wird durch den Wert 0x1 aktiviert. Mit dem Wert 0x0 wird das Scannen während der Übertragung deaktiviert. Wenn kein Wert festgelegt wird, lautet die Standardeinstellung 0x0.
Hinweis: Das Scannen während der Übertragung steht nur bei Exchange-Virenscannern zur Verfügung, die auf VSAPI 2.5 (Virus Scanning Application Programming Interface) basieren.
Exchange-Kategorisierungsmodul Diese Ereignissenke ist in Phatcat.dll implementiert und für die verschiedenen Ereignisse in der Ereigniskategorie
279
OnCategorize registriert. Das Kategorisierungsmodul ist eine der wichtigsten Komponenten des Transportsubsystems. Es führt die Adressauflösung und die Nachrichtenweiterleitung durch, setzt Kennzeichen für die Formatkonvertierung von ein- und ausgehenden über das Internet gesendete Nachrichten, gliedert Verteilergruppen auf und erzwingt globale Einstellungen für das Sperren von Benachrichtigungen über den Übermittlungsstatus. Außerdem kann das Kategorisierungsmodul unter anderem alternative Empfänger für eine Nachricht hinzufügen, wenn dies für Journale gewünscht wird, oder auch Nachrichten verzweigen (wenn mehrere Kopien einer Nachricht benötigt werden). Das Kategorisierungsmodul wird weiter unten in diesem Kapitel im Thema „Exchange-Kategorisierungsmodul“ ausführlicher erläutert.
Mobiles Kategorisierungsmodul Diese in Miscat.dll implementierte Ereignissenke ist ebenfalls für die verschiedenen Ereignisse in der Ereigniskategorie OnCategorize registriert. Diese Ereignissenke unterstützt als neue Funktion in Exchange Server 2003 Aktualisierungsinformationen für mobile Geräte, z. B. Microsoft Pocket PC. Aktualisierungsbenachrichtigungen werden in der Standardeinstellung zusammen mit Exchange Server 2003 installiert. Bei der Erzeugung eines Ereignisses, etwa wenn ein Benutzer eine Nachricht empfängt, wird eine Benachrichtigung an seinen Pocket PC gesendet. Der Pocket PC kann dann im Hintergrund eine Synchronisierung durchführen, um die aktuellsten Informationen bereitzuhalten, wenn der Benutzer das Gerät das nächste Mal überprüft.
Hinweis: Aktualisierungsbenachrichtigungen stehen nur auf Geräten mit dem Betriebssystem Microsoft Windows Mobile™ 2003 zur Verfügung.
Exchange Router Diese Ereignissenke ist in Reapi.dll implementiert und für die Ereignisse in der Ereigniskategorie OnGetMessageRouter registriert. Die Senke „Exchange Router“ ist die zweitwichtigste Komponente im Transportsubsystem. Das erweiterte Warteschlangenmodul verwendet diese Komponente zur Bestimmung des nächsten Hop zum Endziel der Nachricht. Ausführliche Informationen zur Routingarchitektur von Exchange 2003 finden Sie unter Nachrichtenroutingarchitektur.
Exchange LoadBalancer Diese Ereignissenke ist in Reapi.dll implementiert und für das Ereignis OnDnsResolveRecord registriert. Das erweiterte Warteschlangenmodul verwendet diese Senke zur gleichmäßigen Verteilung des Verkehrsaufkommens ausgehender Nachrichten über alle für einen Routinggruppenconnector festgelegten Bridgeheadserver. Weitere Informationen über die Lastenverteilung des Nachrichtentransfers zwischen Routinggruppen finden Sie unter Nachrichtenroutingarchitektur.
Exchange-KategorisierungsmodulDas System für die Kategorisierung von Nachrichten in Exchange besteht aus zwei Komponenten, dem zentralen Kategorisierungsmodul und dem Exchange-
280
Kategorisierungsmodul. Das zentrale Kategorisierungsmodul besteht aus Code, der ursprünglich in die Datei Aqueue.dll implementiert war. Exchange Server 2003 ersetzt diese Datei durch die Registrierung einer DLL namens Phatq.dll. Phatq.dll enthält neben allen Funktionen aus Aqueue.dll noch weitere, Exchange-spezifische Funktionen. Das Exchange-Kategorisierungsmodul ist in die Datei PhatCat.dll implementiert, die für die Ereignisse in der Ereigniskategorie OnCategorize registriert ist. Das erweitete Warteschlangenmodul löst diese Ereignisse durch das zentrale Kategorisierungsmodul aus. Das zentrale Kategorisierungsmodul und das Exchange-Kategorisierungsmodul verarbeiten die Nachricht in zehn Kategorisierungsereignissen.
Hinweis: Das zentrale Kategorisierungsmodul löst die Ereignisse aus, die den Vorgang der Nachrichtenkategorisierung steuern.
Das erweiterte Warteschlangenmodul löst die folgenden zehn Kategorisierungsereignisse aus:
Registrierung Das zentrale Kategorisierungsmodul und das Exchange-Kategorisierungsmodul initialisieren mit diesem Ereignis ihre Schnittstellen. Das Exchange-Kategorisierungsmodul initialisiert seine Schnittstellen zum Beispiel für die Verzeichnisdienstzugriff-Komponente (DSAccess – Directory Service Access), das Routingmodul und den Informationsspeichertreiber. Wenn die Initialisierung einer dieser Schnittstellen fehlschlägt, kann das Exchange-Kategorisierungsmodul nicht initialisiert werden.
Alle Kategorisierungsmodule benötigen aus folgenden Gründen Schnittstellen zu diesen Komponenten:
a. Durch die Kommunikation mit DSAccess wird festgestellt, ob sich Empfänger im DSAccess-Cache befinden. Wenn dies der Fall ist, können die erforderlichen Informationen direkt aus DSAccess bezogen werden, und es entsteht keine Verarbeitungslast durch Suchvorgänge in Active Directory.
Außerdem ermittelt das Exchange-Kategorisierungsmodul die Liste der globalen Katalogserver aus DSAccess und gibt sie an das zentrale Kategorisierungsmodul weiter, das sie für LDAP-Lookups verwendet (Lightweight Directory Access Protocol). In der Standardeinstellung ermittelt das zentrale Kategorisierungsmodul die globalen Katalogserver für LDAP-Lookups mithilfe der Domänentopologie aus Active Directory. Auf einem Server mit Exchange Server 2003 sollte das Kategorisierungsmodul allerdings die globalen Katalogserver verwenden, die von DSAccess dynamisch auf Grundlage der Standorttopologie von Active Directory oder, wenn globale Katalogserver in einem DSAccess-Profil in der Registrierung codiert sind, statisch ermittelt wurden. Weitere Informationen über den Ermittlungsvorgang in DSAccess finden Sie unter Exchange Server 2003 und Active Directory .
b. Die Kommunikation mit dem Routingmodul ist zum Beispiel dann erforderlich, wenn eine Einmaladresse, die kein SMTP verwendet, in eine SMTP-Adresse gekapselt
281
wird. Eine Einmaladresse ist eine Adresse, die nicht anhand eines Empfängerobjekts in Active Directory aufgelöst wird. Das Exchange-Kategorisierungsmodul ruft das Routingmodul auf, um zu ermitteln, ob eine Route zum Ziel vorhanden ist. Wenn keine Route vorhanden ist, erzeugt das Kategorisierungsmodul einen NDR. Wenn eine Route vorhanden ist, versieht das Kategorisierungsmodul den Einmalempfänger mit der im MailMsg-Objekt gekapselten Adresse. Später gibt das erweiterte Warteschlangenmodul die Adressinformationen an das Routingmodul weiter, das dann den nächsten Hop für den Empfänger ermittelt.
Hinweis: Das MailMsg-Objekt ist eine im Speicher befindliche Struktur, die einen Nachrichtenübermittlungsumschlag sowie einen Zeiger auf die eigentliche Nachricht entweder im NTFS-Informationsspeicher oder im Exchange-Informationsspeicher enthält. Der Nachrichtenübermittlungsumschlag enthält alle Eigenschaften des Nachrichtenheaders und alle Benutzerinformationen des Empfängers, die zur Verarbeitung der Nachricht durch das Kategorisierungsmodul erforderlich sind.
c. Die Kommunikation mit dem Exchange-Informationsspeichertreiber ist in einigen Situationen während der Kategorisierung erforderlich. Es kann z. B. sein, dass das Exchange-Kategorisierungsmodul eine Nachricht aus dem Ordner \Queue kopieren muss, damit der Exchange-Informationsspeicher RFC 822-Inhalte mit der Inhaltskonvertierungslogik verarbeiten und konvertieren kann, die in die Komponente IMAIL (Internet Mail) des Exchange-Informationsspeichers implementiert ist.
BeginMessageCategorization Dieses Ereignis wird einmal für jedes an das zentrale Kategorisierungsmodul übergebene MailMsg-Objekt aufgerufen und zeigt den Beginn der Kategorisierung einer Nachricht an.
EndMessageCategorization Dieses Ereignis wird für jedes an das zentrale Kategorisierungsmodul übergebene MailMsg-Objekt aufgerufen. Dadurch wird das Ende der Nachrichtenkategorisierung angezeigt.
BuildQuery Dieses Ereignis wird einmal für jeden Empfänger und den Empfänger aufgerufen, der ermittelt werden muss. Mitglieder abfragebasierter Verteilergruppen werden allerdings nicht ermittelt, da ihre Attribute bereits bei der Verarbeitung der abfragebasierten Verteilergruppe ermittelt werden. Das Exchange-Kategorisierungsmodul überprüft für jeden zu ermittelnden Empfänger, ob er sich im DSAccess-Cache befindet. Wenn dies der Fall ist, gibt das Exchange-Kategorisierungsmodul ein IcategorizerItemAttributes-Objekt zurück, um den Code des zentralen Kategorisierungsmoduls für Verzeichnisdienst-Suchvorgänge zu umgehen. Die Verarbeitung wird für diesen Empfänger mit dem Ereignis ProcessItem fortgeführt. Wenn sich der Empfänger nicht im DSAccess-Cache befindet, erzeugt der Code der LDAP-Suchfunktion des zentralen Kategorisierungsmoduls einen LDAP-kompatiblen Suchfilter für den Benutzer. Dieser basiert in der Regel auf dem proxyAddresses-Attribut und der Eingabeadresse, zum Beispiel:
282
(proxyAddresses=smtp:[email protected])
Bei der Eingabeadresse kann es sich je nach Herkunft und Ziel der Nachricht um eine SMTP-Adresse, eine X.400-Adresse oder eine nicht aus Exchange stammende Adresse handeln.
Tipp: Als Beispiel für die Verwendung eines LDAP-Filters auf der Basis von proxyAddresses für die Suche eines bestimmten Empfängerobjekts in Active Directory können Sie das Tool LDIFDE (Ldifde.exe) aus Windows Server 2003 verwenden. Über den Befehlszeilenparameter „r“ können Sie einen LDAP-Suchfilter angeben. Beispielsweise können Sie Ted mithilfe des folgenden Befehls in der Domäne fabrikam.com auf dem Server01 im globalen Katalog suchen: ldifde -f c:\Ted.ldf -s Server01 -t 3268 -d "dc=fabrikam,dc=com" -p subtree -r "(proxyAddresses=smtp:[email protected])". Wenn Ted die SMTP-Adresse [email protected] hat, kann LDIFDE das Empfängerobjekt in Active Directory auffinden und seine Attribute in eine unformatierte Textdatei namens Ted.ldf schreiben. Das Exchange-Kategorisierungsmodul verwendet dasselbe Prinzip, um Empfängerobjekte zu suchen, SMTP-, X.400- und legacyExchangeDN-Standardattribute vom Empfänger abzurufen und diese als Eigenschaften im MailMsg-Objekt festzulegen. Später verwendet das Exchange-Kategorisierungsmodul diese Informationen bei der Nachrichtenverarbeitung
Das Exchange-Kategorisierungsmodul verwendet das proxyAddresses-Attribut für fast alle Adresstypen (ausgenommen ältere Exchange- und X.500-DNs (Distinguished Names), da diese Adressinformationen nicht im proxyAddresses-Attribut gespeichert werden). Wenn zum Beispiel ein Outlook-Benutzer eine Nachricht an einen anderen Benutzer in der Exchange-Organisation oder an einen externen Benutzer mit einem E-Mail-aktivierten Empfängerobjekt in Active Directory sendet, gibt der Outlook-Client in der ausgehenden Nachricht zwecks Abwärtskompatibilität mit Exchange Server 5.5 die legacyExchangeDN-Adresse des Empfängers an. Das Exchange-Kategorisierungsmodul verwendet das legacyExchangeDN-Attribut dann für die Suche des Empfängerobjekts in Active Directory.
Bei der Auflösung der Mitglieder einer Verteilergruppe muss das Exchange-Kategorisierungsmodul X.500-DNs verarbeiten, da die Gruppenmitglieder im Mitgliedattribut mit ihren DNs aufgelistet sind. In dieser Situation analysiert das Exchange-Kategorisierungsmodul den jeweiligen DN, um den RDN (Relative Distinguished Name) des Empfängers zu ermitteln, welcher der allgemeine Name (CN, Common Name) des Empfängers in Active Directory ist. Anschließend verwendet das Exchange-Kategorisierungsmodul das cn-Attribut im Suchfilter mit dem Rest des DN (der auf den übergeordneten Container des Empfängerobjekts in Active Directory zeigt) als Basis für die LDAP-Suche nach dem Empfängerobjekt. In der Standardeinstellung ist das cn-Attribut in Active Directory indiziert, was eine effiziente Verzeichnissuche ermöglicht.
283
BuildQueries Dieses Ereignis wird einmal für jede Stapelverarbeitungssuche aufgerufen. Mithilfe dieses Ereignisses bündelt das zentrale Kategorisierungsmodul bis zu 20 einzelne Suchvorgänge nach Empfängern in einer einzigen Anfrage. Das Ereignis SendQuery kann dann eine einzelne Suche durchführen, die einen Stapel an Empfängern zurückgibt. In der Regel ist eine einzige Suche nach mehreren Empfängern effizienter als mehrere Suchen nach mehreren Empfängern. Dies gilt sogar, obwohl die Verarbeitung eines Ereignisses vom Typ SortQueryResults bei einer Stapelverarbeitungssuche und der Zuordnung ihrer Ergebnisse zu den einzelnen Empfängern einer Nachricht zusätzlichen Verarbeitungsaufwand bedeutet. Die bei weniger als 20 Ergebnissen erforderliche Zuordnung ist effektiver als die andernfalls benötigte Durchführung mehrerer vollständiger LDAP-Anfragen an Active Directory. Es folgt ein Beispiel für einen LDAP-kompatiblen Suchfilter, mit dem mehrere Benutzer gleichzeitig gefunden werden können:
(|(proxyAddresses=smtp:[email protected]) (proxyAddresses=smtp:[email protected]))
Tipp: Als Beispiel für die Funktionsweise eines LDAP-Filters für mehrere Benutzer können Sie Ted und Birgit mithilfe des folgenden Befehls in einer Domäne namens fabrikam.com im globalen Katalog auf Server01 suchen: ldifde -f c:\TedandBirgit.ldf -s Server01 -t 3268 -d "dc=fabrikam,dc=com" -p subtree -r "(|(proxyAddresses=smtp:[email protected]) (proxyAddresses=smtp:[email protected]))". Wenn Ted die SMTP-Adresse [email protected] und Birgit die SMTP-Adresse [email protected] hat, findet LDIFE beide Empfängerobjekte in Active Directory und schreibt all ihre Attribute in getrennten Abschnitten in eine unformatierte Textdatei namens TedandBirgit.ldf. Das Kategorisierungsmodul verwendet dasselbe Prinzip, um mehrere Empfängerobjekte zu suchen.
SendQuery Das Kategorisierungsmodul löst dieses Ereignis für jede Stapelverarbeitungssuche einmal aus und führt die anschließende Verzeichnissuche asynchron aus.
SortQueryResult Das Kategorisierungsmodul ruft dieses Ereignis einmal für jede Stapelverarbeitungssuche auf und ermittelt anschließend, welche Empfänger zu welchem Verzeichnisobjekt (die aus der Suche hervorgegangenen LDAP-Ergebnisse) gehören. Das proxyAddresses-Attribut dient der Zuordnung der Suchergebnisse auf der Basis von SMTP-, X.400- und von nicht aus Exchange stammenden Adressen. Das legacyExchangeDN-Attribut dient der Zuordnung von Suchen mit legacyExchangeDN, und das distinguishedName-Attribut dient der Zuordnung bei Suchen auf der Basis von X.500-DNs. Dafür muss jeder Empfänger durch seine Adressinformationen eindeutig identifiziert werden. Nicht eindeutig unterscheidbare Werten führen zu einem NDR mit dem Code 5.1.4. In der folgenden Tabelle wird der NDR mit dem Code 5.1.4 ausführlich beschrieben.
284
Ausführliche Informationen zu NDRs mit Code 5.1.4
Zahlencode 5.1.4
Mögliche Ursache Zwei Objekte haben die gleiche (Proxy-)Adresse, und Nachrichten werden an diese Adresse gesendet.
Problembehandlung Überprüfen Sie die Empfängeradresse, und senden Sie die Nachricht erneut. Das Problem kann ebenfalls auftreten, wenn der Empfänger auf dem Remoteserver nicht vorhanden ist.
Beschreibung Weitere Informationen über NDR-Codes finden Sie im Microsoft Knowledge Base-Artikel 284204, „Delivery status notifications in Exchange Server and in Small Business Server“.
ProcessItem Das zentrale Kategorisierungsmodul löst dieses Ereignis aus, um dem MailMsg-Objekt die SMTP-, X.400-, X.500 und legacyExchangeDN-Adressen für jeden Empfänger hinzuzufügen. Die vom Exchange-Kategorisierungsmodul für den Empfänger festgelegten Adressen basieren auf den Attributen, die von Active Directory für den Empfänger zurückgegeben wurden. Das mail-Attribut enthält die SMTP-Adresse, das textEncodedORAddress-Attribut die X.400-Adresse, das distinguishedName-Attribut die X.500-Adresse und das legacyExchangeDN-Attribut die ältere Exchange-Adresse.
Hinweis: Die nach diesem Zeitpunkt für den Empfänger verwendeten Adressen stimmen nicht unbedingt mit den Adressen überein, die für die Empfängersuche in Active Directory verwendet wurden. Es kann zum Beispiel sein, dass ein Nicht-Exchange-Benutzer eine Nachricht an die sekundäre Proxyadresse eines Exchange-Benutzers sendet. Während des Ereignisses ProcessItem ersetzt das Exchange-Kategorisierungsmodul die sekundäre Proxyadresse durch die primäre Adresse des Exchange-Benutzers.
Das Exchange-Kategorisierungsmodul verfügt außerdem über speziellen Code für die Verarbeitung von Kontakten und Einmal-Adressen. Kontakte sind Empfänger ohne Exchange, die jedoch in Active Directory gespeichert sind. Einmal-Adressen sind nicht in Active Directory vorhanden. Der Absender könnte die Empfängeradresse direkt in der Zeile An eingegeben haben oder hat vielleicht ein Kontaktobjekt aus seinem persönlichen Ordner Kontakte in Outlook definiert. In beiden Fällen ist nur die Zieladresse des Empfängers bekannt und wird dem MailMsg-Objekt hinzugefügt. Wenn eine Kontakt-Adresse oder eine Einmal-SMTP-Adresse mit einem Adressraum der lokalen Exchange-Organisation übereinstimmt, entsteht ein Konflikt, da Kontakte und
285
Einmal-Adressen auf Empfänger außerhalb der lokalen Exchange-Organisation verweisen müssen.
Wenn Sie das Kontrollkästchen Diese Exchange-Organisation ist für die gesamte E-Mail-Übermittlung an diese Adresse verantwortlich aktivieren, erzwingt das Kategorisierungsmodul seine Autorität bei Adressen, die mit Adressräumen übereinstimmen, die in Empfängerrichtlinien festgelegt sind. Wenn ein Benutzer eine Nachricht an eine Adresse sendet, die nicht in Active Directory enthalten ist, jedoch mit einem Adressraum in einer autorisierenden Empfängerrichtlinie übereinstimmt, versieht das Exchange-Kategorisierungsmodul den Empfänger mit einem Fehlerstatus, der später das erweiterte Warteschlangenmodul veranlasst, einen NDR vom Typ 5.1.1 zu erzeugen, welcher bei unbekannten Adressen ausgegeben wird. Das Exchange-Kategorisierungsmodul gilt für sich selbst als autorisierend für legacyExchangeDN- und X.400-Adressen, die mit dem Adressraum des Standorts der lokalen Verwaltungsgruppe übereinstimmen.
Hinweis: Wenn Sie auf einem virtuellen SMTP-Server einen alternativen Server konfiguriert haben (die Einstellung Alle E-Mails mit nicht ausgewerteten Empfängern weiterleiten an Host) leitet das Kategorisierungsmodul Nachrichten an nicht vorhandene Adressen in seinen autorisierenden Adressräumen an diesen alternativen Server weiter, anstatt einen NDR vom Typ 5.1.1 für die Empfänger zu erzeugen. Dieser Vorgang wird während des Ereignisses CompleteItem ausgeführt.
In der folgenden Tabelle wird der NDR mit dem Code 5.1.1 ausführlich beschrieben.
Ausführliche Informationen zu NDRs mit Code 5.1.1
Zahlencode 5.1.1
286
Mögliche Ursache Das E-Mail-Konto ist in der Organisation, an die die Nachricht gesendet wurde, nicht vorhanden. Wenn zum Beispiel ein Internetbenutzer eine Nachricht an [email protected] sendet, Ihr Server der autorisierende Server für fabrikam.com ist und niemand in Active Directory diese Adresse hat, wird ein NDR mit Code 5.1.1 erzeugt.
Ein NDR mit Code 5.1.1 bedeutet „Autorisierung nicht gefunden“. Er gilt für SMTP-Adressen gemäß den Empfängerrichtlinien, legacyExchangeDN-Empfänger gemäß dem legacyExchangeDN-Attribut der lokalen Verwaltungsgruppe und X.400-Adressen gemäß der X.400-Standortadresse der Verwaltungsgruppe. Ansonsten wird bei jedem Vorkommen einer Adresse, die keine SMTP-Adresse ist, nicht weitergeleitet werden kann und keinem Empfängerobjekt in Active Directory entspricht, ein NDR mit Code 5.1.2 erzeugt.
Problembehandlung Entweder ist die Empfängeradresse nicht ordnungsgemäß formatiert oder das Kategorisierungsmodul ist nicht in der Lage, den Empfänger richtig aufzulösen. Überprüfen Sie die Empfängeradresse, und senden Sie die Nachricht erneut, um diesen Fehler zu beheben.
Weitere Informationen über NDR-Codes finden Sie im Microsoft Knowledge Base-Artikel 284204, „Delivery status notifications in Exchange Server and in Small Business Server“.
Bei Adressen, die sich nicht in Active Directory befinden und mit keiner autorisierenden Empfängerrichtlinie bzw. keinem Adressraum eines lokalen Standorts übereinstimmen, registriert das Kategorisierungsmodul keinen Fehler. Stattdessen registriert es eine Weitergabe an ein anderes Ziel.
287
ExpandItem Das Kategorisierungsmodul löst dieses Ereignis zur Verarbeitung der folgenden Aufgaben aus:
Aufgliederung von Verteilerlisten Wenn es sich bei dem lokalen Server um einen Server für die Aufgliederung der Verteilergruppen in der Nachricht handelt, können die Verteilergruppen lokal aufgegliedert werden. Das msExchExpansionServerName-Attribut listet den Server mit Exchange Server 2003 auf, der für die Aufgliederung von Verteilerlisten zuständig ist. Wenn dieses Attribut nicht festgelegt wurde, kann jeder Server, auf dem Exchange ausgeführt wird, diese Verteilergruppe aufgliedern. Wenn ein Server angegeben wurde und es sich dabei nicht um den lokalen Server handelt, muss das Kategorisierungsmodul die Nachricht an diesen Server weiterleiten, da die E-Mail-aktivierte Gruppe speziell auf diesem Server aufgegliedert werden muss. Wenn eine Verteilergruppe aufgegliedert wird, löst das Kategorisierungsmodul jeden einzelnen Empfänger auf.
Einschränkungsüberprüfung Das Kategorisierungsmodul prüft ggf. vorhandene sender- und empfängerspezifische Einschränkungen, Einstellungen für das Nachrichtenformat und Grenzwerte und kennzeichnet jeden Empfänger entsprechend. Wenn ein Absender zum Beispiel über eine Empfängerbeschränkung verfügt und eine Nachricht diesen Grenzwert überschreitet, veranlasst das Kategorisierungsmodul das erweiterte Warteschlangenmodul, einen NDR mit Code 5.5.3 zu erzeugen, um dafür zu sorgen, dass keine Nachricht mehr als die erlaubte Anzahl an Empfängern hat.
Ausführliche Informationen zu NDRs mit Code 5.5.3
Zahlencode 5.5.3
Mögliche Ursache Zu viele Empfänger in der gesendeten Nachricht.
Problembehandlung Die Empfängerbeschränkung ist ein konfigurierbarer Grenzwert auf dem empfangenden Server. Um das Problem zu beheben, können Sie entweder die Anzahl der Empfänger erhöhen oder die Nachricht in mehrere Nachrichten aufteilen, um so der Serverbegrenzung zu entsprechen.
Beschreibung Weitere Informationen über NDR-Codes finden Sie im Microsoft Knowledge Base-Artikel 284204, „Delivery status notifications in Exchange Server and in Small Business Server“.
288
Alternative Empfänger In Active Directory-Benutzer und -Computer können Sie unter Übermittlungsoptionen auf der Registerkarte Exchange – Allgemein alternative Empfänger für Exchange-Benutzer festlegen. Das Exchange-Kategorisierungsmodul fügt dem MailMsg-Objekt diese Empfängerinformationen hinzu und leitet die Nachricht weiter. Bei der Übertragung der Nachricht in einer Exchange-Organisation wird ein Kennzeichen mit dem ursprünglichen Empfänger über XEXCH50 im Nachrichtenübermittlungsumschlag gesendet. Dadurch wird verhindert, dass mehrere Kopien einer Nachricht an einen alternativen Empfänger weitergeleitet werden. Wenn das Exchange-Kategorisierungsmodul dieses Kennzeichen für einen ursprünglichen Empfänger erkennt, überspringt es den Code für das Hinzufügen des alternativen Empfängers.
Das Exchange-Kategorisierungsmodul führt auch eine Überprüfung auf Schleifenbedingungen (wenn beispielsweise Ted an Birgit weiterleitet und Birgit an Ted) durch. Wenn eine Schleife erkannt wird, weist das Kategorisierungsmodul das erweiterte Warteschlangenmodul an, für den ersten Benutzer in der Schleife einen NDR mit Code 5.4.6 zu erzeugen.
Ausführliche Informationen zu NDRs mit Code 5.4.6
Zahlencode 5.4.6
Mögliche Ursache Das Auftreten einer Weiterleitungsschleife im Kategorisierungsmodul wurde festgestellt. Es wird ein targetAddress-Attribut mit einer Adresse in einer autorisierenden SMTP-Domäne für einen postfachaktivierten Benutzer festgelegt. Das targetAddress-Attribut muss auf eine Remotedomäne verweisen.
Ein NDR mit Code 5.4.6 wird auch erzeugt, wenn es eine Weiterleitungsschleife in Active Directory gibt. Dieser NDR wird z. B. erzeugt, wenn eine Kette von Exchange-Benutzern alternative Benutzer aufweist, die zirkulär aufeinander verweisen.
Problembehandlung Überprüfen Sie den alternativen Empfänger des Kontakts.
Prüfen und entfernen Sie das targetAddress-Attribut von postfachaktivierten Benutzern.
289
Beschreibung Weitere Informationen über NDR-Codes finden Sie im Microsoft Knowledge Base-Artikel 284204, „Delivery status notifications in Exchange Server and in Small Business Server“.
Verzweigung von Nachrichten Wenn Empfänger unterschiedliche Nachrichtenformate benötigen, verzweigt das Exchange-Kategorisierungsmodul die Nachrichten und erstellt mehrere Kopien. Die Verzweigung von Nachrichten wird weiter unten in diesem Abschnitt ausführlicher erläutert.
CompleteItem Das zentrale Kategorisierungsmodul ruft dieses Ereignis auf, um die abschließende Verarbeitung durchzuführen, nachdem die Arbeit aller anderen Ereignissenken des Kategorisierungsmoduls abgeschlossen wurde. Die abschließende Verarbeitung umfasst folgende Aufgaben:
Journalfunktion Mit der Journalfunktion werden Nachrichten, die von Benutzern gesendet oder empfangen wurden, auf einem Exchange-Server in ein Nachrichtenarchiv kopiert. Wenn der aktuelle Server der erste Server ist, der einen Absender oder Empfänger bearbeitet, für den ein Journaleintrag erforderlich ist (da beispielsweise Journaleintragungen für den lokalen Postfachspeicher des Absenders oder Empfängers deaktiviert sind), fügt das Exchange-Kategorisierungsmodul die Journaladresse des Postfachspeichers in den Umschlag für den Nachrichtentransport ein und überträgt die Nachricht.
Die Konfiguration der Journalfunktion wird in Active Directory gespeichert und steht allen Exchange-Servern in der Organisation zur Verfügung. Möglicherweise sendet ein Exchange-Benutzer (für dessen Stamm-Postfachspeicher die Journalfunktion aktiviert ist) mit einem Internet-Client Nachrichten per SMTP an einen Bridgeheadserver, der zu einer Exchange-Organisation gehört. Der Bridgeheadserver fügt dann die Journaladresse in den Nachrichtenübermittlungsumschlag ein und leitet eine Kopie der Nachricht an das Archivpostfach dieses Absenders weiter. Server mit Exchange Server 2003 tauschen die Informationen aus Nachrichtenübermittlungsumschlägen, einschließlich der Liste mit Journaladressen für Absender und Empfänger, mithilfe des Befehls XEXCH50 aus. Wenn mehrere Server an einer Nachrichtenübermittlung beteiligt sind und ein Server in einem Nachrichtenübermittlungsumschlag eine Journaladresse findet, fügt er diese Adresse nicht erneut hinzu und vermeidet dadurch doppelte Einträge im Nachrichtenarchiv.
Hinweis: Bei Bcc-Empfängern, Empfängern aus Weiterleitungsregeln und Empfängern aus aufgegliederten Verteilergruppen funktioniert die Journalfunktion für Nachrichten möglicherweise nicht zuverlässig. Wenn Sie zusätzlich zu den
290
Nachrichtendaten auch die Daten aus dem Umschlag für den Nachrichtentransport aufzeichnen müssen, müssen Sie die Journalfunktion für Umschläge aktivieren. Dies erfolgt über das Tool für die erweiterte E-Mail-Journalkonfiguration, das auf der Erweiterte Konfiguration für Exchange Server-E-Mail-Journale-Website zum Download bereitsteht.
Weiterleitung nicht ausgewerteter Empfänger Wenn Sie den virtuellen SMTP-Server so konfiguriert haben, dass er alle Nachrichten mit nicht ausgewerteten Empfängern an einen alternativen Host weiterleitet, stellt das Exchange-Kategorisierungsmodul den Zielserver für alle nicht ausgewerteten Empfänger auf den vollqualifizierten Domänennamen (FQDN – Fully Qualified Domain Name) des alternativen Servers ein.
Markierung von Empfängern Das Exchange-Kategorisierungsmodul markiert jeden Empfänger, indem es eine empfängerspezifische Eigenschaft für die Nachricht festlegt. Durch diese Eigenschaft wird der Zielserver für jeden Empfänger angezeigt. Das übliche Format dieser Eigenschaft ist der vollqualifizierte Domänenname des Stammservers des Empfängers. Auf Grundlage des vollqualifizierten Domänennamens, der vom Kategorisierungsmodul für jeden Empfänger festlegt wird, entscheidet das erweiterte Warteschlangenmodul, ob die Nachricht lokal zugestellt oder das Routingmodul aufgerufen wird. Alle Nachrichten, die mit dem vollqualifizierten Domänennamen des lokalen Servers übereinstimmen, werden ohne Nachrichtenrouting aus der Warteschlange vor dem Routing direkt in die Warteschlange für die lokale Übermittlung übertragen. Bei nicht lokalen Empfängern muss das erweiterte Warteschlangenmodul später das Routingmodul aufrufen, um den nächsten Hop für diese Nachrichtenübermittlung zu ermitteln.
Hinweis: Der vollqualifizierte Domänenname des Stammservers eines Empfängers wird vom Exchange-Kategorisierungsmodul über eine Komponente namens MDAccess ermittelt. MDAccess verwendet für die Bestimmung der Netzwerkadresse des Servers, der als Host eines Empfängerpostfachs agiert, die Konfigurationsinformationen in Active Directory. Wenn sich das Postfach des Empfängers auf dem lokalen Exchange-Server befindet, legt das Exchange-Kategorisierungsmodul das homeMDB-Attribut des Empfängers im Nachrichtenübermittlungsumschlag als Eigenschaft für den Empfänger fest. Anhand dieser Information wird vom Exchange-Informationsspeichertreiber später der Postfachspeicher des Empfängers ermittelt, in den die Nachricht zugestellt wird.
Umleiten von Benachrichtigungen über den Übermittlungsstatus Wenn ein Benutzer eine Nachricht im Namen einer Verteilergruppe sendet (wenn er also diese Gruppe im Feld Von angibt) und Übermittlungs- oder Lesebestätigungen anfordert, werden die Benachrichtigungen über den Übermittlungsstatus erzeugt und an die ganze Verteilergruppe und nicht nur an den Absender gesendet. Um dieses Problem
291
zu beheben und Benachrichtigungen zum Übermittlungsstatus an den tatsächlichen Sender umzuleiten, wird die Absenderadresse im Nachrichtenübermittlungsumschlag der Nachricht vom Kategorisierungsmodul gegen die Adresse des tatsächlichen Absenders ausgetauscht.
Es kommt selten vor, dass Benutzer Nachrichten im Namen einer Verteilergruppe senden. Häufiger ist, dass ein Benutzer mehrere Abwesenheitsbenachrichtigungen, automatische Antworten und Benachrichtigungen über den Übermittlungsstatus (z. B. NDRs) erhält, nachdem er eine Nachricht an eine große Verteilergruppe gesendet hat. Aus diesem Grund werden in der Standardeinstellung Abwesenheitsbenachrichtigungen und automatische Antworten vom Exchange-Kategorisierungsmodul unterdrückt, wenn Nachrichten an Verteilergruppen gesendet werden. Hierzu fügt das Exchange-Kategorisierungsmodul den Empfängern im Umschlag der Nachricht eine Eigenschaft hinzu. Der Exchange-Informationsspeicher verwendet diese Eigenschaft bei der lokalen Zustellung als Parameter für die Unterdrückung von Regeln, die andernfalls Abwesenheitsbenachrichtigungen und automatische Antworten erzeugen würden. Wenn die einzelnen Mitglieder der Verteilergruppe auf verschiedenen Postfachservern angesiedelt sind, wird diese erweiterte Eigenschaft des Nachrichtenumschlags über den Befehl XEXCH50 zwischen Servern mit Exchange Server 2003 übertragen.
Das Exchange-Kategorisierungsmodul leitet Abwesenheitsbenachrichtigungen, automatische Antworten und Benachrichtigungen über den Übermittlungsstatus entsprechend der in der folgenden Tabelle aufgeführten Kriterien um oder löscht sie.
292
Kriterien für das Umleiten und Löschen von Benachrichtigungen über den Übermittlungsstatus
Kriterium Vorgang
Es gibt einen Besitzer der Verteilergruppe, und Zustellbarkeitsberichte müssen laut Konfiguration an ihn gesendet werden.
Unzustellbarkeitsberichte werden umgeleitet, um den Besitzer der Gruppe über Fehler bei der Zustellung einer Nachricht zur Gruppe oder einem ihrer Mitglieder zu informieren. Das Kategorisierungsmodul leitet alle Unzustellbarkeitsberichte für Gruppenmitglieder um, die normalerweise an den Absender zurückgesendet würden.
In der Standardeinstellung werden nur NDRs an den Gruppenbesitzer umgeleitet. Wenn ein Absender ausdrücklich Statusbenachrichtigungen (z. B. Übermittlungsbestätigungen) wünscht, werden Berichte über Erweiterungen des SMTP-Protokolls für Benachrichtigungen zum Übermittlungsstatus erzeugt. Wenn ein Absender in einer Nachricht an eine Gruppe, für die die Umleitung von Berichten aktiviert ist, eine Benachrichtigung über den Übermittlungsstatus anfordert, erhält er diese Benachrichtigung, wenn die Gruppe entweder erfolgreich aufgegliedert oder aber (wenn der lokale Server nicht der Server für die Aufgliederung der Gruppe ist) an ihren Server für die Aufgliederung umgeleitet wurde.
293
Kriterium Vorgang
Zustellbarkeitsberichte müssen laut Konfiguration an den Verfasser der Nachricht gesendet werden.
Benachrichtigungen über den Übermittlungsstatus werden an den Absender der Nachricht gesendet. Das Kategorisierungsmodul unterdrückt Abwesenheitsbenachrichtigungen und automatische Antworten, wenn das Kontrollkästchen Abwesenheitsnachrichten an Absender der Nachrichten senden auf der Registerkarte Exchange – Erweitert für diese Gruppe nicht aktiviert ist. Dieses Kontrollkästchen ist in der Standardeinstellung nicht aktiviert.
294
Kriterium Vorgang
Die Verteilergruppe unterdrückt laut Konfiguration Zustellbarkeitsberichte für Gruppenmitglieder, um keine Informationen über Mitgliedschaften preiszugeben.
Alle Abwesenheitsbenachrichtigungen, automatischen Antworten und alle Arten von Benachrichtigungen über den Übermittlungsstatus (z. B. Empfangs- und Lesebestätigungen) werden unterdrückt. Dies erfolgt ähnlich wie die Umleitung von Unzustellbarkeitsberichten, mit dem Unterschied, dass das Kategorisierungsmodul alle Arten von Übermittlungsbenachrichtigungen einschließlich Unzustellbarkeitsberichten für einzelne Gruppenmitglieder unterdrückt. Zur Sperrung aller Zustellbarkeitsberichte ändert das Kategorisierungsmodul im Nachrichtenübermittlungsumschlag die Absenderadresse in die Zeichenfolge „<>“.
Wenn ein Absender in der Nachricht an eine Gruppe eine Benachrichtigung über den Übermittlungsstatus (z. B. eine Empfangsbestätigung) anfordert, werden Benachrichtigungen zum Übermittlungsstatus über Erweiterungen des SMTP-Protokolls für die Benachrichtigung zum Übermittlungsstatus erzeugt, wenn die Gruppe entweder erfolgreich aufgegliedert oder aber (wenn der lokale Server nicht der Server für die Aufgliederung der Gruppe ist) an ihren Server für die Aufgliederung umgeleitet wurde.
Hinweis: In der Standardeinstellung werden Abwesenheitsbenachrichtigungen, automatische Antworten und Benachrichtigungen über den Übermittlungsstatus vom Kategorisierungsmodul unterdrückt, wenn ein Benutzer eine Nachricht an eine Verteilerliste sendet. Sie können diese Einstellung konfigurieren, indem Sie im Dialogfeld für die Verteilergruppeneigenschaften auf der Registerkarte Exchange – Erweitert das Kontrollkästchen Abwesenheitsnachrichten an Absender der Nachrichten senden aktivieren. Weitere Informationen finden Sie im Microsoft Knowledge Base-Artikel 325469, "Automatische Antworten von
295
Verteilergruppen funktionieren in Exchange Server 2003 oder Exchange 2000 Server nicht."
Zuordnung von Statuscodes Das Exchange-Kategorisierungsmodul übernimmt auch die Zuordnung von Statuscodes, die von früheren Senken des Kategorisierungsmoduls in der E-Mail-Nachricht an die Empfänger zurückgegebenen wurden. Fehlercodes veranlassen dann das erweiterte Warteschlangenmodul, NDRs für betroffene Empfänger zu erzeugen.
Verzweigung von NachrichtenWie bereits weiter oben erwähnt, kann das Kategorisierungsmodul im Verlauf der Kategorisierung mehrere Kopien einer Nachricht erstellen. Dieser Vorgang wird als Verzweigung bezeichnet und wird immer dann ausgeführt, wenn verschiedene Empfänger unterschiedliche Kopien derselben Nachricht erhalten sollen. Die Verzweigung wird aus folgenden Gründen durchgeführt:
Inhaltskonvertierung Eine Inhaltskonvertierung ist immer dann erforderlich, wenn ein Exchange-Benutzer eine Nachricht im MAPI-Format an einen Benutzer sendet, der MAPI nicht verwendet. Das ist zum Beispiel der Fall, wenn ein Outlook-Benutzer eine Nachricht an einen Benutzer im Internet sendet. Das Kategorisierungsmodul muss dann eine Inhaltskonvertierung von MAPI in ein Internet-Nachrichtenformat durchführen. Eine Inhaltskonvertierung ist auch erforderlich, wenn in einer Exchange-Organisation im gemischten Modus eine MAPI-Nachricht über einen SMTP-basierten Routinggruppenconnector gesendet werden muss. Die Inhaltskonvertierung erfordert eine Verzweigung, da der Inhalt vorhandener Nachrichten vom Kategorisierungsmodul nicht geändert werden kann. Weitere Informationen zur Inhaltskonvertierung finden Sie weiter unten in diesem Abschnitt.
Empfängerspezifische Entfernung der Anfragen von Übermittlungs- und Lesebestätigungen Dies ist erforderlich, wenn eine Nachricht mit Anforderung einer Lesebestätigung an eine Verteilergruppe mit verborgenen Mitgliedschaftsinformationen und einen weiteren einzelnen Empfänger in der Zeile An gesendet wird. Da die Mitgliedschaften der Gruppe vertraulich bleiben müssen, dürfen keine Lesebestätigungen erzeugt werden, wenn die Gruppenmitglieder die Nachricht erhalten. Andernfalls könnte der Absender anhand der empfangenen Lesebestätigungen die einzelnen Mitglieder der Gruppe erkennen. Um dies zu vermeiden, werden für die Verteilergruppe mit verborgener Mitgliedschaft und für den einzelnen Empfänger zwei verschiedene Kopien der Nachricht erstellt. Aus der Nachricht für die Verteilergruppe wird die Anforderung der Lesebestätigung entfernt.
Benachrichtigungen über den Übermittlungsstatus mit mehreren Empfängern Wenn das Exchange-Kategorisierungsmodul Benachrichtigungen über den Übermittlungsstatus mit mehreren Empfängern entdeckt, verzweigt es die Nachricht für jeden Empfänger, da der Exchange-MTA (aufgrund der Kompatibilität mit dem
296
Standard X.400) nur einen Empfänger pro Benachrichtigung unterstützt. Da das Kategorisierungsmodul nicht feststellen kann, ob der MTA an der Nachrichtenübermittlung beteiligt ist (nur das Routingmodul ist hierzu in der Lage), muss es für jeden Empfänger eine eigene Benachrichtigung über den Übermittlungsstatus erstellen.
Die Verzweigung erfolgt auf dem Server mit Exchange Server, wenn die Nachricht vom Client übergeben wird. Die Anzahl neuer, vom Kategorisierungsmodul erstellter Nachrichten können Sie mit dem Systemmonitor überprüfen. In der folgenden Abbildung ist der entsprechende Leistungsindikator dargestellt.
Der Leistungsindikator: für verzweigte Nachrichten
InhaltskonvertierungBenutzer von MAPI-Clients wie Outlook können jeweils pro Nachricht oder pro Empfänger angeben, ob die Nachricht im Rich-Text- oder im HTML-Format bzw. als unformatierter Text gesendet werden soll. Dementsprechend wird die Nachricht vom Kategorisierungsmodul gesendet. Administratoren können außerdem in Active Directory bevorzugte Formate in den Eigenschaften E-Mail-aktivierter Empfängerobjekte festlegen oder Internet-E-Mail-Formate jeweils pro Adressraum definieren (z. B. im Exchange-System-Manager unter Globale Einstellungen jeweils pro Internet-Domäne). Nachrichten, die an Benutzer in einer
297
Internetdomäne gesendet werden, können daher das Rich-Text-, MIME- (Multipurpose Internet Mail Extensions) oder UUEncode-Format (Unix-to-Unix Encode) aufweisen. Das Kategorisierungsmodul verwendet eine bestimmte Logik, um diese verschiedenen Formateinstellungen den einzelnen Empfängern zuzuordnen. Bei der Auflösung der Nachrichtenempfänger stellt das Kategorisierungsmodul unter Umständen fest, dass für Gruppen von Empfängern oder für einzelne Empfänger verschiedene Nachrichtenformate benötigt werden. Das Kategorisierungsmodul muss die Nachricht daraufhin verzweigen, damit jeder Empfänger das richtige Nachrichtenformat erhält, also Rich-Text, HTML oder unformatierten Text.
Die Inhaltskonvertierung ist auch bei MAPI-Nachrichten an Exchange-Empfänger in der lokalen Exchange-Organisation erforderlich, wenn die Nachrichten per SMTP übertragen werden. Server in der lokalen Routinggruppe, auf denen Exchange Server 2003 ausgeführt wird, kommunizieren stets über SMTP miteinander. In verschiedenen Routinggruppen befindliche Server, auf denen Exchange Server 2003 ausgeführt wird, kommunizieren über SMTP, wenn der Routinggruppenconnector oder SMTP-Connectors bereitgestellt werden. Zur Unterstützung von SMTP muss das MAPI-Format in das RFC 822-Format konvertiert werden, damit die Nachricht übertragen werden kann.
Hinweis: Die Inhaltskonvertierung erfolgt auf dem Server, auf dem der Benutzer die Nachricht abschickt. So kann die Nachricht per SMTP ohne weitere Konvertierung von Server zu Server übertragen werden. Die Inhaltskonvertierung wird nur bei MAPI-Nachrichten durchgeführt.
IMAILDie Nachrichtenkonvertierung in Exchange Server 2003 wird als IMAIL bezeichnet. IMAIL ist eine interne Komponente des Exchange-Informationsspeichers. Die eigentliche Nachrichtenkonvertierung wird nicht vom Exchange-Kategorisierungsmodul ausgeführt. Das Exchange-Kategorisierungsmodul erstellt Kopien der Nachricht nur mithilfe des Exchange-Informationsspeichertreibers und legt im Nachrichtenübermittlungsumschlag jeder Kopie bestimmte Eigenschaften fest. Der Informationsspeichertreiber verwendet die eingestellten Eigenschaften als Parameter, um anzugeben, welches Format angefordert werden soll, wenn der RFC 822-Inhalt aus dem Exchange-Informationsspeicher angefordert wird. Der Exchange-Informationsspeicher konvertiert die MAPI-Nachricht mittels IMAIL unter Verwendung der angeforderten Formatierungsparameter in das RFC 822-Format. Wenn der RFC 822-Inhalt einer Nachricht erzeugt wird, erzeugt IMAIL nur eine Wiedergabe der MAPI-Nachricht. Die eigentliche Nachricht im Exchange-Informationsspeicher wird nicht geändert. Änderungen am wiedergegebenen RFC 822-Inhalt werden nicht dynamisch der MAPI-Nachricht zugeordnet, die zur Erzeugung des RFC 822-Inhalts verwendet wurde.
298
TNEFExchange Server 2003 verwendet TNEF (Transport Neutral Encapsulation Format), um MAPI-Nachrichten in das RFC 822-Format zu konvertieren. TNEF wird bei einer Nachricht als MIME-Anlage vom Typ application/ms-tnef angezeigt. Die Anlage trägt die Bezeichnung Winmail.dat. Sie enthält den vollständigen Nachrichteninhalt und alle angehängten Dateien. Nur MAPI-Clients wie Outlook können die Anlage Winmail.dat decodieren. Nicht-MAPI-Clients sind nicht in der Lage, TNEF zu decodieren und stellen Winmail.datAttribut ggf. als normale, jedoch nutzlose Datei dar.
Hinweis: Empfänger mit Postfächern auf einem Exchange-Server, die für den Zugriff auf ihre Nachrichten Internet-Clients verwenden, gelten nicht als Nicht-MAPI-Empfänger. Der Grund hierfür ist, dass der Exchange-Informationsspeicher, in dem sich die Postfächer befinden, den erforderlichen RFC 822-Inhalt in einem Nicht-MAPI-Format erstellen kann, wenn Benutzer MAPI-Nachrichten über einen POP3- oder IMAP4-Client von ihrem Posteingang downloaden.
Es gibt verschiedene mögliche Szenarios für die Übertragung zwischen Exchange-Systemen, bei denen die Konvertierung von MAPI in RFC 822 erforderlich ist:
Empfänger befindet sich auf einem Exchange-Server in derselben Routinggruppe Exchange Server 2003 stellt MAPI-Nachrichten im S/TNEF (Summary-TNEF) dar, einem speziellen TNEF-Typ ohne unformatierten Text, der als 8-Bit-Binärformat wiedergegeben wird. S/TNEF-Nachrichten bestehen nur aus der Datei Winmail.dat.
Hinweis: In einer Routinggruppe verwendet Exchange Server 2003 stets S/TNEF, da die Nachricht bei allen Remoteübermittlungen mit Sicherheit einen SMTP-Hop in unmittelbarer Nähe eines Servers mit Exchange 2000 Server bzw. Exchange Server 2003 passiert oder zum Exchange-MTA gelangt. Exchange 2000 Server und Exchange Server 2003 unterstützen binäre MIME-Daten. Wenn die Nachricht dagegen an den Exchange-MTA übergeben wird, um über RPCs an einen Server mit Exchange Server 5.5 übermittelt zu werden, ist keine Nachrichtenkonvertierung erforderlich, da das RFC 822-Format nicht verwendet wird.
Empfänger befindet sich auf einem Exchange-Server in einer anderen Routinggruppe, und die Exchange-Organisation arbeitet im einheitlichen Modus Exchange Server 2003 gibt MAPI-Nachrichten im S/TNEF wieder, da eine Exchange-Organisation im einheitlichen Modus nur Server enthalten kann, auf denen Exchange 2000 Server oder Exchange Server 2003 ausgeführt wird, die binäre MIME-Daten unterstützen.
299
Empfänger befindet sich auf einem Exchange-Server in einer anderen Routinggruppe, und die Exchange-Organisation arbeitet im gemischten Modus Im gemischten Modus kann der Internet Mail-Dienst von Exchange Server 5.5 als SMTP-Connector verwendet werden. Der Internet Mail-Dienst unterstützt jedoch keine binären MIME-Daten. Da die RFC 822-Darstellung von S/TNEF, die von IMAIL erzeugt wird, binäre MIME-Daten sind, kann der Internet Mail-Dienst S/TNEF-Nachrichten nicht übertragen. Das Exchange-Kategorisierungsmodul kann nicht im Voraus entdecken, welche Route eine Nachricht nimmt. Daher konvertiert das Kategorisierungsmodul die Nachricht für einen Empfänger, der sich auf einem Server im gemischten Modus außerhalb der lokalen Routinggruppe befindet, nicht in S/TNEF. Um der Möglichkeit Rechnung zu tragen, dass sich eine Instanz des Internet Mail-Diensts im Übertragungsweg befindet, konvertiert das Exchange-Kategorisierungsmodul die Nachricht in einen Teil mit unformatiertem Text und in eine Legacy-TNEF-Anlage. Diese enthält 7-Bit-MIME-Daten, die der Internet Mail-Dienst übertragen kann.
Der Empfänger ist ein MAPI-Empfänger außerhalb der lokalen Exchange-Organisation Benutzer und Administratoren können die Übertragung von TNEF über die Grenzen der lokalen Exchange-Organisation hinweg für Empfänger in externen Messagingumgebungen, die Outlook verwenden, aktivieren. Da sich der Empfänger nicht in der lokalen Exchange-Organisation befindet, kann das Exchange-Kategorisierungsmodul nicht feststellen, ob alle an der Nachrichtenübertragung beteiligten SMTP-Hosts binäre MIME-Daten unterstützen. Dementsprechend konvertiert das Exchange-Kategorisierungsmodul die Nachricht in einen Teil mit unformatiertem Text und in eine Legacy-TNEF-Anlage.
Hinweis: Nicht-MAPI-Empfänger ziehen es in der Regel vor, eine Nachricht als unformatierten Text oder im HTML-Format ohne TNEF zu empfangen, da ihre Clients die Datei Winmail.dat nicht decodieren können, die die Nachricht und alle Anlagen enthält. Aufgrund der TNEF-Kapselung können Nicht-MAPI-Clients nicht auf die Anlagen zugreifen. Nicht-Microsoft-Tools wie EPOC WMDecode for Windows können unter Umständen Anlagen aus Winmail.dat-Dateien extrahieren.
An Öffentliche Ordner gesendete MAPI-Nachrichten Nachrichten, die an Öffentliche Ordner gesendet werden, werden stets im Legacy-TNEF weitergegeben. Weitere Informationen über die Nachrichtenverarbeitung für Öffentliche Ordner finden Sie weiter unten in diesem Abschnitt.
MAPI-Nachrichten, die über SMTP an einen Aufgliederungsserver gesendet werden Wenn eine Nachricht eine Verteilerliste mit einem expliziten Aufgliederungsserver enthält, bei dem es sich nicht um den lokalen Server handelt, wird die Nachricht im Legacy-TNEF an den Aufgliederungsserver weitergeleitet (wenn SMTP für die Nachrichtenübertragung verwendet wird). In diesem Fall wird durch XEXCH50 eine Eigenschaft im Nachrichtenübermittlungsumschlag übermittelt, die dem
300
Aufgliederungsserver die Zeit mitteilt, zu der die Nachricht ursprünglich vom Exchange-Informationsspeichertreiber empfangen wurde. Wenn das Kategorisierungsmodul auf dem Aufgliederungsserver die Verteilerliste erweitert, müssen auf die einzelnen Empfänger die entsprechenden RFC 822-Nachrichtenformate angewendet werden. Das Kategorisierungsmodul kopiert die Nachricht mithilfe des Exchange-Informationsspeichertreibers in den Exchange-Informationsspeicher. Dort liest IMAIL die TNEF-Daten und erstellt eine MAPI-Nachricht mit der Übermittlungszeit der ursprünglichen Nachricht. Das SMTP-Transportsubsystem liest die MAPI-Nachricht anschließend aus dem Informationsspeicher in ein RFC 822-Format, das den Formatierungsanforderungen des Empfängers entspricht.
Sie können das Verhalten des TNEF-Formats für das Senden von Nachrichten steuern, indem Sie den folgenden Registrierungsschlüssel hinzufügen. Die Zahl nn stellt die virtuelle Serverinstanz für diesen Computer dar.
Pfad HKey_Local_Machine\Software\Microsoft\
Exchange\StoreDriver\Exchange\nn\EnableTnef
Wert Disabled
Typ REG_DWORD
Daten für Wert 0x0
Beschreibung Ein Wert von 0x0 disables TNEF, and messages are generated without using
TNEF. A value of 0x1 will generate a
message using legacy TNEF when S/TNEF
would ordinarily be generated. A value of
0x2 has no effect, as that is the default
behavior.
Nachrichtenverarbeitung für Öffentliche OrdnerÖffentliche Ordner können E-Mail-aktiviert sein, sodass Benutzer Nachrichten an diese Ordner senden können. Im Unterschied zu postfachaktivierten Benutzerkonten, deren Postfächer sich nur auf einem bestimmten Exchange-Server in einer Organisation befinden können, lassen sich Öffentliche Ordner auf mehreren Servern replizieren, während sie auf anderen Servern fehlen können, deren Informationsspeicher für Öffentliche Ordner mit der obersten Hierarchieebene des Öffentlichen Ordners verknüpft ist. Daher ist es schwierig, den Übermittlungsort für Nachrichten zu bestimmen, die an den Öffentlichen Ordner gesendet werden.
301
Für die Nachrichtenübermittlung muss das Exchange-Kategorisierungsmodul die Nachricht an einen Informationsspeicher für Öffentliche Ordner übermitteln, dem bekannt ist, wo sich die Replikate des Öffentlichen Ordners befinden. Diese Informationen sind im Exchange-Informationsspeicher im PTagReplicaList-Attribut enthalten. Nur der Exchange-Informationsspeicher mit einem Informationsspeicher für Öffentliche Ordner, der mit der obersten Hierarchieebene des Öffentlichen Ordners verknüpft ist, verfügt über diese PTagReplicaList-Informationen.
Bei der Suche nach einem Informationsspeicher für Öffentliche Ordner, der mit der obersten Hierarchieebene des Öffentlichen Ordners verknüpft ist, liest das Exchange-Kategorisierungsmodul das homeMDB-Attribut des Öffentlichen Ordners. Das homeMDB-Attribut enthält den DN (Distinguished Name) des Objekts der obersten Hierarchieebene in Active Directory. Dieses Objekt wiederum enthält das ExchOwningPFTreeBL-Attribut, das die Informationsspeicher für Öffentliche Ordner auflistet, die mit der obersten Hierarchieebene verknüpft sind. Das Exchange-Kategorisierungsmodul wählt anschließend einen Informationsspeicher für Öffentliche Ordner aus dieser Liste und leitet die Nachricht an diesen Informationsspeicher für Öffentliche Ordner weiter. Der Informationsspeicher für Öffentliche Ordner ermittelt den Eintrag PTagReplicaList für den betreffenden Ordner, adressiert die Nachricht wieder an einen Informationsspeicher für Öffentliche Ordner, der ein Replikat des Öffentlichen Ordners enthält, und übermittelt die Nachricht erneut. Die Nachricht passiert nochmals das erweiterte Warteschlangenmodul und wird kategorisiert. Wenn das Exchange-Kategorisierungsmodul den aktualisierten Pfad im Informationsspeicher für Öffentliche Ordner findet, legt es den aktualisierten Pfad als Ziel der Nachricht fest und leitet die Nachricht erneut weiter.
Das Exchange-Kategorisierungsmodul verwendet die folgenden Prioritäten (absteigend), um den Informationsspeicher für Öffentliche Ordner für die Nachricht auszuwählen:
1. Informationsspeicher für Öffentliche Ordner auf dem lokalen Server mit Exchange Server haben die höchste Priorität.
2. Informationsspeicher für Öffentliche Ordner in der lokalen Routinggruppe
3. Informationsspeicher für Öffentliche Ordner in der lokalen administrativen Gruppe
4. Informationsspeicher für Öffentliche Ordner in der lokalen Exchange-Organisation
5. Informationsspeicher für Öffentliche Ordner auf Servern mit Exchange Server 5.5
Hinweis: Wenn es in der lokalen Routinggruppe mehrere Informationsspeicher für Öffentliche Ordner gibt, wählt das Exchange-Kategorisierungsmodul den ersten Informationsspeicher in der Liste.
302
Optimieren der Leistung des KategorisierungsmodulsWie im Abschnitt „Exchange-Kategorisierungsmodul“ weiter oben in diesem Thema erwähnt, ermittelt das Exchange-Kategorisierungsmodul in DSAccess die Liste globaler Katalogserver, die für LDAP-Lookups verwendet werden müssen. DSAccess ermittelt diese Liste dynamisch auf Basis der Active Directory-Standorttopologie oder statisch, wenn Sie globale Katalogserver in einem DSAccess-Profil fest in der Registrierung codiert haben, wie in Exchange Server 2003 und Active Directory erläutert.
In der Standardeinstellung ermittelt DSAccess die Liste globaler Katalogserver dynamisch, sodass globale Katalogserver aus der Liste ausgeschlossen werden, wenn sie aus einem bestimmten Grund nicht mehr verfügbar sind. Der Zeitraum für wiederholte Versuche, eine Verbindung mit einem globalen Katalogserver herzustellen, beträgt fünf Minuten. In der Standardeinstellung wird die Liste von DSAccess mindestens alle 15 Minuten neu berechnet. Das Exchange-Kategorisierungsmodul ruft DSAccess einmal pro Stunde auf, um die Liste globaler Katalogserver zu aktualisieren.
Die Liste globaler Katalogserver wird vom Exchange-Kategorisierungsmodul außerdem aktualisiert, wenn pro globalem Katalogserver mehr als 100 Verbindungsfehler aufgetreten sind. Ein globaler Katalogserver kann zwecks Wartung oder aus anderen Gründen inaktiv sein. Es ist auch möglich, dass der LDAP-Verbindungsfehler durch ein Problem mit der Netzwerkkommunikation hervorgerufen wird. Mit den folgenden Registrierungsparametern können Sie die Timeoutwerte festlegen, die vom Kategorisierungsmodul verwendet werden, um LDAP-Verbindungen als nicht funktionsfähig zu klassifizieren.
Vorsicht: Die fehlerhafte Verwendung des Registrierungs-Editors kann zu schwerwiegenden Problemen führen, die möglicherweise eine Neuinstallation des Betriebssystems erforderlich machen. Microsoft kann keine Garantie dafür übernehmen, dass Probleme, die aus der unsachgemäßen Verwendung des Registrierungs-Editors herrühren, behoben werden können. Sie verwenden den Registrierungs-Editor auf eigene Verantwortung.
Speicherort HKEY_LOCAL_MACHINE\System\
CurrentControlSet\Services\SMTPSVC\
Parameters
Wert LdapResultTimeout
Typ REG_DWORD
Daten für Wert 0x79
303
Beschreibung Hiermit wird in Sekunden angegeben, wie lange das Exchange-Kategorisierungsmodul bei ausstehenden Suchvorgängen maximal auf neue Ergebnisse des globalen Katalogservers wartet. Wenn das Exchange-Kategorisierungsmodul bei Ablauf des Timeouts keine neuen Ergebnisse empfangen hat, können die in der LDAP-Verbindung ausstehenden Suchvorgänge nicht ausgeführt werden, und es wird der Statuscode LDAP_SERVER_DOWN zurückgegeben. Das Exchange-Kategorisierungsmodul kann diese Suchvorgänge anschließend über neue LDAP-Verbindungen erneut übermitteln. Die normale Timeoutdauer beträgt zwei Minuten und eine Sekunde (121 Sekunden).
Speicherort HKEY_LOCAL_MACHINE\System\
CurrentControlSet\Services\SMTPSVC\
Parameters
Wert LdapRequestTimeLimit
Typ REG_DWORD
Daten für Wert 0x258
Beschreibung Dies ist die maximale Zeitdauer in Sekunden, die das Kategorisierungsmodul für eine ausstehende LDAP-Anforderung zulässt. Länger dauernde Suchvorgänge können nicht ausgeführt werden und geben den Statuscode LDAP_TIMELIMIT_EXCEEDED zurück, auch wenn der globale Katalogserver mit Ergebnissen für den Suchvorgang antwortet. Der Standardwert beträgt zehn Minuten (600 Sekunden).
Speicherort HKEY_LOCAL_MACHINE\System\
CurrentControlSet\Services\SMTPSVC\
Parameters
304
Wert MaxConnectionRetries
Typ REG_DWORD
Daten für Wert 0x14
Beschreibung Hiermit wird angegeben, wie oft LDAP-Verbindungsversuche für eine einzelne Kategorisierung maximal fehlschlagen und wie oft Suchanforderungen über eine neue Verbindung nochmals gesendet werden können, bis die betreffende Kategorisierung fehlschlägt und in eine Wiederholungswarteschlange gestellt wird. Die Standardeinstellung beträgt 20 Fehler.
Wenn eine Kategorisierung fehlschlägt, da MaxConnectionRetries überschritten wird, wird die betreffende Nachricht vom Kategorisierungsmodul wieder in die Warteschlange vor der Kategorisierung gestellt. Das erweiterte Warteschlangenmodul wird darüber informiert, dass die Kategorisierung bei einem späteren Versuch ggf. erfolgreich ist. In der Standardeinstellung wiederholt das erweiterte Warteschlangenmodul die Kategorisierung nach einer Stunde. Sie können diese Zeitdauer mit dem folgenden Registrierungsparameter einstellen.
Speicherort HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Services\SMTPSVC\
Queuing
Wert CatRetryMinutes
Typ REG_DWORD
Daten für Wert 0x3C
Beschreibung Hiermit wird in Minuten angegeben, wie lange das Kategorisierungsmodul wartet, bevor erneut ein Kategorisierungsversuch für eine Nachricht erfolgt. Dies gilt für Kategorisierungen, die mit einem Fehler abgebrochen wurden, der durch einen erneuten Versuch behoben werden kann, beispielsweise mit einem LDAP-Verbindungsfehler. Der Standardwert beträgt eine Stunde (60 Minuten).
305
Lastenausgleich für globale KatalogeWenn einem Server mit Exchange Server 2003 mehrere globale Katalogserver zur Verfügung stehen, kann das Exchange-Kategorisierungsmodul LDAP-Suchvorgänge per Lastenausgleich auf alle diese globalen Kataloge verteilen. In der Standardeinstellung beginnt das Exchange-Kategorisierungsmodul mit dem Lastenausgleich für LDAP-Suchvorgänge, wenn auf einem globalen Katalogserver mehr als 16 LDAP-Suchvorgänge ausstehen. Das Exchange-Kategorisierungsmodul wählt globale Katalogserver auf Grundlage von Kostenwerten aus. Die Kostenwerte werden durch die folgenden Eigenschaften bestimmt:
Anzahl bestehender LDAP-Verbindungen Das Exchange-Kategorisierungsmodul behandelt bestehende LDAP-Verbindungen gegenüber neuen Verbindungen bevorzugt, da es effizienter ist, eine bereits hergestellte Verbindung zu nutzen, als eine neue Verbindung mit einem globalen Katalogserver herzustellen. Das Herstellen von Verbindungen bedeutet eine erhöhte Verarbeitungslast.
In der Standardeinstellung kann das Basiskategorisierungsmodul pro globalen Katalogserver bis zu acht (je nach Auslastung) gleichzeitige LDAP-Verbindungen für Verzeichnissuchläufe öffnen. Sie können die Anzahl der Verbindungen mit dem folgenden Registrierungsschlüssel anpassen.
Speicherort HKEY_LOCAL_MACHINE\System\
CurrentControlSet\Services\SMTPSVC\
Parameters
Wert MaxLdapConnections
Typ REG_DWORD
Daten für Wert 0x8
306
Beschreibung Dies ist die maximale Anzahl von LDAP-Verbindungen, die die Komponenten im SMTP-Dienst auf einem globalen Katalogserver öffnen können. Der Standardwert beträgt acht Verbindungen.
Hinweis: Dieser Wert gilt für jeden Prozess im Kategorisierungsmodul, bei dem LDAP-Lookups durchgeführt werden: in einem Prozess werden während der Kategorisierung Empfänger für übermittelte Nachrichten aufgelöst, und im anderen Prozess werden die Nachrichteneinschränkungen pro Empfänger überprüft. Für jeden dieser Prozesse sind bis zu acht Verbindungen möglich, sodass maximal insgesamt 16 Verbindungen mit globalen Katalogservern zulässig sind.
Status bestehender LDAP-Verbindungen Das Exchange-Kategorisierungsmodul bevorzugt verfügbare LDAP-Verbindungen ohne ausstehende Suchvorgänge.
Nähe zum Exchange-Server Das Exchange-Kategorisierungsmodul bevorzugt globale Katalogserver am lokalen Active Directory-Standort gegenüber globalen Katalogservern an Remotestandorten. Es wird angenommen, dass TCP/IP-Verbindungen am lokalen Standort schnell und zuverlässig sind.
Anzahl ausstehender LDAP-Abfragen Das Kategorisierungsmodul zieht Leerlaufverbindungen gegenüber Verbindungen mit ausstehenden Abfragen vor. Stehen bei allen Verbindungen Abfragen aus, wählt das Exchange-Kategorisierungsmodul die Verbindung mit der geringsten Anzahl ausstehender Abfragen aus.
Das Exchange-Kategorisierungsmodul wählt den globalen Katalogserver mit den niedrigsten Kosten aus. Wenn mehrere globale Katalogserver den gleichen Kostenwert aufweisen, führt das Kategorisierungsmodul für alle verfügbaren LDAP-Verbindungen einen Lastenausgleich nach dem Roundrobinverfahren aus. Das Exchange-Kategorisierungsmodul wählt eine Verbindung folgendermaßen aus:
1. Das Exchange-Kategorisierungsmodul arbeitet wiederholt die Liste bestehender LDAP-Verbindungen ab und wählt automatisch die erste Verbindung ohne ausstehende Suchvorgänge aus.
307
2. Wenn keine LDAP-Verbindung besteht bzw. keine Verbindung verfügbar ist, stellt das Exchange-Kategorisierungsmodul eine neue Verbindung mit dem globalen Katalogserver her.
LDAP-SuchstapelDas Exchange-Kategorisierungsmodul kann Suchvorgänge asynchron und für Stapel von bis zu 20 Empfängern durchführen. Ein Active Directory-Suchvorgang für mehrere Empfängerobjekte unter Verwendung eines LDAP-OR-Filters kann zu einem Leistungszuwachs führen, auch wenn für die Zuordnung der Ergebnisse zu den Empfängern der Nachricht zusätzliche Verarbeitungsleistung benötigt wird. LDAP-Stapelsuchvorgänge eignen sich gut für einzelne Empfängerobjekte, die in einer einzelnen Abfrage eines globalen Katalogs zusammengefasst werden können Die meisten Vorgänge des Exchange-Kategorisierungsmoduls fallen unter diese Kategorie; es gibt jedoch Ausnahmen.
In den folgenden Situationen verwendet das Kategorisierungsmodul keine Stapelabfragen:
Das Kategorisierungsmodul muss eine dynamische Verteilergruppe erweitern.
Das Kategorisierungsmodul muss ausgelagerte Attribute anfordern. Dies ist z. B. bei Verteilergruppen mit mehr als 1.000 Mitgliedern der Fall.
Hinweis: Das Exchange-Kategorisierungsmodul stellt mithilfe von DSAccess fest, ob ein Empfängerobjekt im DSAccess-Cache enthalten ist. Verzeichnissuchläufe werden nicht für Objekte im Cache durchgeführt.
Sie können die Leistung des Exchange-Kategorisierungsmoduls mit den folgenden Registrierungsschlüsseln verwalten. Sie können z. B. die maximale Anzahl von Empfängern in einem Stapelsuchlauf erhöhen. Eine drastische Erhöhung dieser Zahl kann sich jedoch negativ auf die Leistung auswirken, da der Aufwand für die Zuordnung der Ergebnisse zu den Empfängern ebenfalls steigt. Die Standardwerte reichen im Allgemeinen in den meisten Fällen aus. Es ist daher nicht sinnvoll, diese Werte ohne Unterstützung durch einen Spezialisten des Microsoft Software Service zu ändern.
Speicherort HKEY_LOCAL_MACHINE\System\
CurrentControlSet\Services\SMTPSVC\
Parameters
Wert MaxSearchBlockSize
Typ REG_DWORD
Daten für Wert 0x14
308
Beschreibung Dies ist der „Stapelgrenzwert“ oder die maximale Anzahl von Suchvorgängen des Kategorisierungsmoduls, die als eine einzelne LDAP-Suche gesendet werden können. Standardwert ist der Hexadezimalwert 0x14 oder dezimal ausgedrückt 20 Suchvorgänge des Kategorisierungsmoduls.
Speicherort HKEY_LOCAL_MACHINE\System\
CurrentControlSet\Services\SMTPSVC\
Parameters
Wert MaxPendingSearches
Typ REG_DWORD
Daten für Wert 0x3C
Beschreibung Dies ist die maximale Anzahl vorab gestapelter, ausstehender Suchvorgänge pro LDAP-Verbindung. Standardwert ist der Hexadezimalwert 0x3C oder dezimal ausgedrückt 60 ausstehende Suchvorgänge.
Erneute Kategorisierung von NachrichtenNachrichten werden nur einmal kategorisiert. Für Nachrichten im Ordner \Queue des Dateisystems verwendet das Kategorisierungsmodul alternative Datenströme, eine wenig bekannte NTFS-Funktion, um den Eigenschaftenstream MailMsg beizubehalten, der Informationen über den Nachrichtenumschlag und die Kategorisierung enthält. Alternative Datenströme ermöglichen die Datenspeicherung in verborgenen Dateien, die mit einer sichtbaren Datei auf einer NTFS-Partition verknüpft sind. Wenn der SMTP-Dienst eine Nachricht nicht sofort übertragen kann und den Versuch zu einem späteren Zeitpunkt wiederholen muss, wird die Nachricht gespeichert und geschlossen. Bei diesem Vorgang wird auch der vorhandene MailMsg-Eigenschaftenstream gespeichert, sodass er erneut geladen und verwendet werden kann, wenn die Nachrichtenübertragung wiederholt wird. Wenn Sie eine Nachricht allerdings nochmals kategorisieren müssen, (beispielsweise wenn sie für einen nicht mehr bestehenden Zielserver in eine Warteschlange gestellt wird), werden Sie feststellen, dass die Kategorisierung nicht ein zweites Mal durchgeführt wird.
Das erweiterte Warteschlangenmodul speichert Nachrichten entweder als EML-Dateien im Verzeichnis \Queue des virtuellen SMTP-Servers oder als ExIFS-Dateien (Exchange
309
Installable File System – installierbares Dateisystem von Exchange) im Exchange-Informationsspeicher. Für EML-Dateien verwendet das Kategorisierungsmodul während der Kategorisierung zwei alternative NTFS-Datenströme namens PROPERTIES und PROPERTIES-LIVE, damit die Eigenschaften des MailMsg-Objekts und die Kategorisierungsinformationen erhalten bleiben. Der Datenstrom PROPERTIES enthält eine Kopie der ursprünglichen Nachricht. Der Datenstrom PROPERTIES-LIVE enthält eine Kopie der aktuellen Nachricht. Die alternativen Datenströme werden entfernt, wenn der SMTP-Dienst eine Nachricht in den Ordner \Badmail verschiebt. In diesem Fall wird die Nachricht mit der Dateierweiterung .bad gespeichert, während der Eigenschaftenstream in einer eigenen Datei mit dem gleichen Dateinamen, jedoch mit der Dateierweiterung .bdp gespeichert wird.
Hinweis: Die Speicherung des Eigenschaftenstreams richtet sich nach dem verwendeten Informationsspeichertreiber. Der NTFS-Informationsspeichertreiber speichert Eigenschaftenstreams mithilfe alternativer Datenströme. Der Exchange-Informationsspeichertreiber speichert Eigenschaftenstreams, indem er die Daten in eine spezielle binäre MAPI-Eigenschaft der Nachricht (bei kleinem Eigenschaftenstream) oder in eine separate ExIFS-Datei kopiert (bei großem Eigenschaftenstream). In diesem Fall wird in der binären MAPI-Eigenschaft eine Verknüpfung mit der ExIFS-Datei gespeichert.
Alternative Datenströme im WarteschlangenverzeichnisMit Editor können Sie die alternativen Datenströme für eine EML-Datei im Verzeichnis \Queue des virtuellen SMTP-Servers anzeigen. Mit dem folgenden Befehl werden z. B. die Kategorisierungsinformationen für eine Testnachricht mit dem Dateinamen NTFS_0ec25fe701c4120a00000001.EML angezeigt: notepad C:\NTFS_0ec25fe701c4120a00000001.EML:PROPERTIES-LIVE. Beachten Sie, dass der Punkt am Ende Bestandteil des Befehls ist. Wenn Sie den Punkt weglassen, wird vom Editor die Dateinamenerweiterung .txt an PROPERTIES-LIVE angefügt. PROPERTIES-LIVE.txt ist jedoch nicht der Name des alternativen Datenstroms. Der erste Teil des Dateinamens verweist auf die übergeordnete Datei des Stroms. Der zweite Teil ist der eigentliche Name des Stroms.
In der folgenden Abbildung wird ein Beispiel für den Inhalt der übergeordneten Datei (links) gezeigt sowie die im alternativen Datenstrom enthaltenen Informationen über die Eigenschaft MailMsg (rechts). Der PROPERTIES-LIVE-Strom im oberen Fenster enthält ausführliche Empfängerinformationen, die für den Absender und Empfänger aus Active Directory abgerufen wurden.
310
Nachrichtendatei mit einem alternativen Datenstrom für Kategorisierungsinformationen
Hinweis: Wenn Sie eine NTFS-Datei mit einem alternativen Datenstrom auf eine FAT-Partition (File Allocation Table) verschieben, geht der alternative Datenstrom verloren, da FAT diese Eigenschaft nicht unterstützt. Dabei gehen auch die Kategorisierungsinformationen und der Nachrichtenübertragungsumschlag verloren. Wenn Sie diese Datei später in das Abholverzeichnis verschieben, wird die Nachricht mithilfe der P2 (RFC 822)-Empfängerliste übermittelt, wenn die Header „x-sender“ und „x-receiver“ nicht angegeben sind. Diese Liste unterscheidet sich ggf. von der P1 (RFC 821)-Empfängerliste, die ursprünglich zum Senden der Nachricht verwendet wurde. Daher erhalten einige Empfänger die Nachricht ggf. zwei Mal. Empfänger, die im Feld Bcc angegeben wurden, erhalten die Nachricht möglicherweise überhaupt nicht, während nicht vorgesehene Empfänger eine Kopie der Nachricht erhalten können. Dies ist möglich, da die ursprüngliche P1-Empfängerliste mit dem Eigenschaftenstream MailMsg verloren gegangen ist, sodass der SMTP-Dienst nur noch über die Informationen aus der P2-Empfängerliste verfügt. Die P2-
311
Empfängerliste ist jedoch nicht für die Verwaltung einer Liste von Empfängern zwecks Nachrichtenübermittlung vorgesehen.
Erzwingen der erneuten KategorisierungDie obigen Erläuterungen zeigen, dass es nicht sinnvoll ist, Dateien auf eine FAT-Partition zu verschieben, um den MailMsg-Eigenschaftenstream zu löschen und das Transportsubsystem auf diese Weise zu zwingen, die Nachricht erneut zu kategorisieren.
In folgenden Fällen müssen Sie eventuell die erneute Kategorisierung einer Nachricht erzwingen:
Beschädigung der Metabase Wenn die IIS-Metabase (Internetinformationsdienste) beschädigt ist oder durch eine Nicht-Exchange-Version ersetzt wird, werden die Nachrichten eventuell mit der falschen Kategorisierungsmodulversion kategorisiert. Um die Nachrichten mit dem Exchange-Kategorisierungsmodul zu kategorisieren (beispielsweise nach einer Neuinstallation von Exchange Server 2003), müssen Sie die Nachrichten erneut kategorisieren.
Falscher Aufgliederungsserver Wenn Sie den Aufgliederungsserver für eine Verteilerliste ändern, wird das Nachrichtenobjekt eventuell mit dem falschen Aufgliederungsserver gestempelt, bis die Änderungen an der Verteilerliste in Active Directory repliziert sind. In diesem Fall wird die Nachricht an den falschen Aufgliederungsserver gesendet. Wenn der Aufgliederungsserver z. B. aus dem Netzwerk entfernt wird und bereits Nachrichten auf dem lokalen Server kategorisiert sind, müssen Sie die Nachrichten erneut kategorisieren, um sie an den richtigen Aufgliederungsserver zu senden.
Falscher Back-End-Server Kategorisierungsprobleme können auch entstehen, wenn Sie Postfächer auf einem anderen Exchange-Server als dem ursprünglichen Server in der Organisation wiederherstellen. Möglicherweise stellen Sie bei Ausfall der Hardware eines Postfachservers die Postfächer auf einem anderen Server wieder her. Vorhandene Nachrichten in Warteschlangen auf anderen Servern mit Exchange Server (beispielsweise Front-End-Servern) werden dann ggf. nicht übermittelt, da das erweiterte Warteschlangenmodul die Übermittlung an den nicht vorhandenen Server versucht. Nur wenn Sie die Nachrichten erneut kategorisieren, ist der vollqualifizierte Domänenname des vorherigen Servers im Nachrichtenübertragungsumschlag enthalten.
In diesen Fällen müssen Sie die Nachrichten nochmals kategorisieren. Serverneustarts haben jedoch keine Auswirkungen auf alternative Datenströme. Aus diesem Grund werden Nachrichten durch den Neustart des Servers mit Exchange Server nicht neu kategorisiert. Um eine Neukategorisierung ohne Verschieben von Dateien auf eine FAT-Partition auszulösen, müssen Sie den Nachrichtenstatus mit dem folgenden Registrierungsschlüssel zurücksetzen:
312
Vorsicht: Die fehlerhafte Verwendung des Registrierungs-Editors kann zu ernsthaften Problemen führen, die möglicherweise eine Neuinstallation des Betriebssystems erforderlich machen. Microsoft übernimmt keine Garantie dafür, dass durch unsachgemäßes Verwenden des Registrierungs-Editors verursachte Probleme behoben werden können. Sie verwenden den Registrierungs-Editor auf eigene Verantwortung.
Speicherort HKEY_LOCAL_MACHINE\System\
CurrentControlSet\Services\SMTPSVC\
Queuing\
Wert ResetMessageStatus
Typ REG_DWORD
Daten für Wert 0x1
Beschreibung Dieser Parameter erzwingt die Neukategorisierung aller in Aufzählungen enthaltenen Nachrichten. Wenn dieser Parameter nicht vorhanden ist, erfolgt in der Standardeinstellung keine Neukategorisierung (0x0).
Damit die Änderungen wirksam werden, müssen Sie den SMTP-Dienst beenden und neu starten. Nach dem Neustart des SMTP-Diensts werden alle zuvor in Warteschlangen gestellte Nachrichten vom Kategorisierungsmodul aufgezählt und neu verarbeitet. Wenn die Nachrichten den Ordner \Queue verlassen, müssen Sie den Schlüssel ResetMessageStatus wieder löschen. Danach können Sie den SMTP-Dienst neu starten und den normalen Betrieb wieder aufnehmen.
313
Informationsspeichertreiber des SMTP-DienstsDas erweiterte Warteschlangenmodul gibt ein MailMsg-Objekt (ein im Speicher enthaltenes Nachrichtenobjekt, das eine schnelle Verarbeitung ermöglicht) von Ereignissenke zu Ereignissenke weiter. Das MailMsg-Objekt besteht aus einem Nachrichtenübertragungsumschlag und einem Zeiger auf die eigentliche physische Nachricht, wenn sich die Nachricht im NTFS im Verzeichnis \Queue befindet. Wenn sich die Nachricht im Exchange-Informationsspeicher befindet, verweist der Zeiger auf den RFC 822-Inhalt der Nachricht und somit auf eine temporäre Datei in der Streamingdatenbank. Beachten Sie, dass Ereignissenken bei MAPI-Nachrichten nicht direkt funktionieren und dass Änderungen an einer MAPI-Nachricht während der Nachrichtenverarbeitung im Transportsubsystem nicht erhalten bleiben. Komponenten wie das Kategorisierungsmodul verwenden den Nachrichtenzeiger vorwiegend zum Auslesen von Daten aus dem Nachrichteninhalt. Das erweiterte Warteschlangenmodul verwendet den Nachrichtenzeiger zudem zur Löschung von Nachrichten, wenn diese angefordert wird.
Hinweis: Der MailMsg-Eigenschaftenstream ist der wichtigste Mechanismus, der von Transportkomponenten für permanente Änderungen an einer Nachricht verwendet wird. Der MailMsg-Eigenschaftenstream bleibt auch beim Neustart von Diensten erhalten.
Um das MailMsg-Objekt für eine empfangene Nachricht im Speicher zu erstellen und mit der eigentlichen Nachricht zu arbeiten, verwendet das erweiterte Warteschlangenmodul die folgenden Informationsspeichertreiber:
NTFS-Informationsspeichertreiber Dieser Informationsspeichertreiber ist in der Datei NTFSDrv.dll implementiert, die sich im Ordner \Windows\System32\Inetsrv befindet. Dies ist der in Windows Server 2003 enthaltene grundlegende Informationsspeichertreiber. Er bietet eine dauerhafte Speicherung des Inhalts eines MailMsg-Objekts und stellt im Dateisystem Eigenschaften für Nachrichtenübertragungsumschläge bereit.
Exchange-Informationsspeichertreiber Dieser Informationsspeichertreiber ist in der Datei Drviis.dll implementiert, die sich im Ordner \Programme\Exchsrvr\bin befindet. Dieser Treiber wird von Exchange Server 2003 implementiert, um die permanente Speicherung des Inhalts eines MailMsg-Objekts zu gewährleisten und Eigenschaften des Übermittlungsumschlags im Exchange-Informationsspeicher bereitzustellen. Der Informationsspeichertreiber übernimmt auch die lokale Nachrichtenübermittlung.
Hinweis: Änderungen am Inhalt der Nachricht sind nicht immer permanenter Natur. Bei Nachrichten, die durch den Exchange-Informationsspeichertreiber gesichert wurden,
314
gehen die Änderungen verloren, da der Exchange-Informationsspeicher nur mit einer temporären Kopie der Nachrichten arbeitet.
NTFS-InformationsspeichertreiberDer SMTP-Dienst speichert eingehende Nachrichten auf einer Festplatte, bevor er die Übertragung bestätigt und die SMTP-Verbindung mit dem Remotehost trennt. Wenn Nachrichten über das SMTP-Protokollmodul eintreffen, werden die Daten als NTFS-Datei (EML-Datei) in den Ordner \Queue des Dateisystems geschrieben. Dieser Ordner befindet sich im Verzeichnis \Mailroot des virtuellen SMTP-Servers. Der Pfad zum Verzeichnis \Mailroot des standardmäßigen virtuellen SMTP-Servers lautet: \Programme\Exchsrvr\Mailroot\Vsi 1. Wenn Sie im Exchange-System-Manager zusätzliche virtuelle SMTP-Server erstellen, werden im Verzeichnis \Mailroot entsprechend der Nummer des virtuellen SMTP-Servers zusätzliche \Vsi x-Ordner erstellt. Alle \Vsi x-Verzeichnisse befinden sich unter \Programme\Exchsrvr\Mailroot und werden der Reihe nach benannt (also \Vsi 1, \Vsi 2 usw.).
Hinweis: Das Setupprogramm von Exchange Server 2003 verschiebt das Verzeichnis \Mailroot des SMTP-Diensts von \Inetpub\Mailroot nach \Programme\Exchsrvr\Mailroot. Die vorherige Ordnerstruktur wird nicht gelöscht. Nachrichten in den ehemaligen Ordnern \Pickup und \Queue werden jedoch nicht übermittelt. Damit diese Nachrichten gesendet werden, müssen Sie sie manuell in den aktuellen \Pickup-Ordner des virtuellen SMTP-Servers verschieben.
Jeder \Vsx-Ordner enthält drei oder vier Unterordner, die für die folgenden Zwecke vorgesehen sind:
\Badmail In diesem Ordner werden unzustellbare Nachrichten gespeichert. Durch eine unzustellbare Nachricht wird das erweiterte Warteschlangenmodul aufgefordert, die Nachricht zusammen mit einem Unzustellbarkeitsbericht an den Absender zurückzusenden. Wenn der Unzustellbarkeitsbericht nicht übermittelt werden kann, wird die Nachricht im Ordner \Badmail in drei separaten Dateien gespeichert.
\Pickup Dieser Ordner bietet eine alternative Methode zum Senden von E-Mail-Nachrichten. In diesen Ordner können Sie zur Übermittlung Nachrichten in Form von Textdateien stellen, die nach RFC 822 formatiert sind. Der Inetinfo-Prozess verwendet einen Thread der asynchronen Threadwarteschlange zur Überwachung des \Pickup-Verzeichnisses jedes virtuellen SMTP-Servers. Dieser Thread empfängt unverzüglich Nachrichten aus dem Ordner \Pickup, erstellt eine neue Datei im Verzeichnis \Queue, analysiert danach den Inhalt der Datei im Verzeichnis \Pickup und schreibt die Daten in die Datei im Verzeichnis \Queue. Beachten Sie, dass der Inhalt während dieses Prozesses unter Umständen geändert wird. Die Header „x-sender“ und „x-receiver“ werden z. B. nicht in die Datei geschrieben, die sich im Verzeichnis \Queue befindet.
315
Das folgende ist ein Beispiel für eine Internettextnachricht mit erweiterten Headerinformationen für Empfänger und Absender. Der Header „x-receiver“ kennzeichnet einen einzelnen Empfänger. Wenn Sie mehrere Empfänger eintragen möchten, fügen Sie für jeden Empfänger den Header „x-receiver“ hinzu. Der Header muss am Anfang der Textdatei stehen, wobei der Header „x-sender“ als erstes aufgeführt sein muss. Nach RFC 822 muss sich zwischen den Headerinformationen und dem Nachrichtentext eine Leerzeile befinden.
Der Dateiname des Nachrichtenobjekts ist nicht wichtig. Der SMTP-Dienst verwendet seine eigene Logik zur Benennung der Nachrichtendatei im Verzeichnis \Queue und hängt die Dateinamenerweiterung .eml an, z. B. NTFS_7224ae2001c4125c0000001b.eml.
x-sender: [email protected]
x-receiver: [email protected]
From: [email protected]
Subject: RFC 822 Pickup Message
This message is passed to the SMTP service through the \Pickup directory.
Hinweis: Sie sollten die Textnachrichten in einem anderen Ordner des Dateisystems erstellen und die Nachrichten anschließend in den Ordner \Pickup verschieben. Um Konflikte mit dem überwachenden SMTP-Dienst zu vermeiden, erstellen Sie die Dateien nicht direkt im Ordner \Pickup.
\Queue Dieser Ordner enthält alle über SMTP empfangenen Nachrichten, die zurzeit auf die Übertragung an ein Remoteziel per SMTP warten. Dieses Verzeichnis enthält jedoch keine Nachrichten, die während der Verarbeitung im SMTP-Transportsubsystem über den Exchange-Informationsspeicher empfangen wurden. Wenn eine Verbindung belegt oder derzeit nicht verfügbar ist, können sich in diesem Ordner Nachrichten anhäufen.
Hinweis: Das erweiterte Warteschlangenmodul versucht, im Ordner \Queue enthaltene Nachrichten in festgelegten Intervallen erneut zu senden. Sie können diese Intervalle im Exchange-System-Manager in den Eigenschaften für virtuelle SMTP-Server auf der Registerkarte Übermittlung konfigurieren. Der Inhalt des Ordners \Queue wird jedoch nicht in Intervallen erfasst. Der Inhalt des Ordners \Queue wird nur erfasst, wenn Sie einen Dienst starten oder wenn Sie einen virtuellen SMTP-Server neu starten.
316
\Filter Dieser Ordner ist in der Standardeinstellung nicht vorhanden. Er wird automatisch erstellt, sobald die erste Nachricht gefiltert wird, nachdem Sie auf einem bestimmten virtuellen Server die Nachrichtenfilterung aktiviert haben. Wählen Sie zur Aktivierung der Nachrichtenfilterung im Exchange-System-Manager die Eigenschaften des virtuellen SMTP-Servers aus, wählen Sie die Registerkarte Allgemein aus, und klicken Sie auf Erweitert.
Hinweis: Darüber hinaus gibt es den Ordner \Windows\NTDS\Drop, den der SMTP-Dienst auf Domänencontrollern zur Übermittlung standortübergreifender Replikationsnachrichten an Active Directory verwendet. Der Ordner \Drop wird nicht zur Übermittlung von Exchange-Nachrichten verwendet.
Verschieben des MailrootverzeichnissesIn Exchange Server 2003 können Sie die Ordner \Badmail und \Queue mit Exchange-System-Manager an einen anderen Ort im Dateisystem verschieben (dies geschieht in den Eigenschaften des virtuellen SMTP-Servers auf der Registerkarte Nachrichten). Die Ordner \Badmail und \Queue sind die wichtigsten Ordner für die Nachrichtenverarbeitung in Exchange, da es sich um die Hauptordner des SMTP-Diensts handelt. Es ist auch möglich, den Ordner \Pickup zu verschieben. Dazu müssen Sie in Active Directory mit ADSI-Bearbeitung (AdsiEdit.msc) msExchSmtpPickupDirectory für das virtuelle SMTP-Serverobjekt festlegen. Der Metabase-Aktualisierungsdienst überträgt die Konfigurationseinstellungen in die IIS-Metabase, wie weiter oben in diesem Abschnitt erläutert wurde.
Verschieben Sie das Verzeichnis \Mailroot nicht auf eine FAT-Partition, da FAT-Partitionen keine alternativen Datenströme für ein Dateiobjekt unterstützen und für sie außerdem weitere Einschränkungen gelten. FAT16-Partitionen unterstützen beispielsweise maximal 65.535 Dateien. Auf einem stark ausgelasteten Bridgeheadserver kann dies ein Problem darstellen. Wenn sich eine Warteschlange zu füllen beginnt, können Einträge gelöscht werden, damit neue Dateien erstellt werden können. Dieser Prozess ist jedoch kompliziert, da für jede Nachricht drei Dateien benötigt werden. Da alternative Datenströme auf einer FAT-Partition nicht verfügbar sind, muss der NTFS-Informationsspeichertreiber für jede Nachricht drei unterschiedliche Dateien erstellen anstatt lediglich eine Datei mit zwei alternativen Datenströmen. Die Leistung von FAT auf großen Datenträgern ist schlecht, da nur eine minimale Fehlertoleranz gegeben ist und nach einem unerwarteten Systemhalt keine Möglichkeit zur Wiederherstellung besteht. Das Verschieben des Verzeichnisses \Mailroot auf ein leistungsstarkes Datenträgersubsystem wie RAID (Redundant Array of Independent Disks) wirkt sich unter Umständen positiv auf die Leistung aus. RAID 0+1 mit acht bis zehn Datenträgern ist bereits eine gute Lösung für eine Nachrichtenübermittlung mit hohem Datenaufkommen. Ein RAID-Controller mit einem Zwischenspeicher von mehr als 64 MB trägt ebenfalls zur Leistungssteigerung bei.
317
Hinweis: Alle vom SMTP-Protokollmodul verarbeiteten Nachrichten werden auf Datenträger geschrieben und dann in ein MailMsg-Objekt eingelesen.
Exchange-InformationsspeichertreiberDer Exchange-Informationsspeichertreiber löst ein interessantes Problem in der Übermittlungsarchitektur von Exchange Server 2003. Im Inetinfo-Prozess werden die Threads des erweiterten Warteschlangenmoduls ausgeführt, es werden jedoch nicht alle Nachrichten über das SMTP-Protokollmodul empfangen. Wie aus der folgenden Abbildung hervorgeht und in Nachrichtenroutingarchitektur erläutert wurde, werden Nachrichten von MAPI-Clients wie Outlook und vom Exchange-MTA durch den Microsoft Exchange-Informationsspeicherdienst an das SMTP-Transportsubsystem übergeben. Da diese Nachrichten nicht über das SMTP-Protokollmodul empfangen werden, müssen sie auf eine andere Weise an das erweiterte Warteschlangenmodul weitergeleitet werden. Dieses alternative Verfahren wird vom Exchange-Informationsspeichertreiber übernommen.
Darüber hinaus verlassen Nachrichten einen Server, auf dem Exchange Server 2003 ausgeführt wird, eventuell nicht über das SMTP-Protokollmodul. Eine Nachricht wird beispielsweise an einen Empfänger mit einem Postfach im lokalen Exchange-Informationsspeicher adressiert. In diesem Fall wird die Nachricht durch den Exchange-Informationsspeichertreiber übermittelt. Nachrichten für Remoteempfänger, die über den Exchange-MTA erreicht werden, müssen ebenfalls in den Exchange-Informationsspeicher übertragen werden, da sich die Warteschlange des Exchange-MTA für ausgehende Nachrichten im Exchange-Informationsspeicher befindet. Der Exchange-MTA steuert die Nachrichtenübertragung an Exchange 5.5-Server in der lokalen Routinggruppe, an Exchange-Remote-MTAs und an Nicht-Exchange-X.400-MTAs mithilfe eines X.400-Connectors bzw. an ein Nicht-Exchange-Messagingsystem mithilfe eines MAPI-basierten Messagingconnectors. Weitere Informationen zu Exchange-MTA finden Sie unter X.400-Transportarchitektur.
318
Nicht-SMTP-Nachrichtenübertragung durch das erweiterte Warteschlangenmodul
Architektur des Exchange-InformationsspeichertreibersEs ist wichtig zu wissen, dass der Exchange-Informationsspeicher (Store.exe) und der IIS Inetinfo-Prozess (Inetinfo.exe) separate Prozesse des Betriebssystems sind, wie aus der folgenden Abbildung hervorgeht. Die virtuellen Adressräume separater Prozesse werden
319
nicht direkt gemeinsam genutzt, sodass Inetinfo.exe nicht auf die Daten im virtuellen Adressraum von Store.exe zugreifen kann und umgekehrt. Um eine MAPI-Nachricht in die Vorübermittlungswarteschlange des erweiterten Warteschlangenmoduls aufzunehmen, muss der Exchange-Informationsspeichertreiber einen Funktionsaufruf vom virtuellen Adressraum von Store.exe zum virtuellen Adressraum des Inetinfo-Prozesses weitergeben. Außerdem muss der Exchange-Informationsspeichertreiber bei der lokalen Übermittlung einer Nachricht an ein Empfängerpostfach oder an die Nachrichtenwarteschlange des Exchange-MTA einen Funktionsaufruf in die andere Richtung weitergeben, also vom IIS-Inetinfo-Prozess zum Exchange-Informationsspeicher.
Architektur des Exchange-Informationsspeichertreibers
Die Ereignissenke des Exchange-Informationsspeichertreibers ermöglicht die Prozesskommunikation zwischen dem Exchange-Informationsspeicher und Inetinfo mithilfe der drei folgenden Hauptkomponenten. Diese Komponenten bilden zusammen den Exchange-Informationsspeichertreiber.
Drviis.dll Diese DLL wird im Inetinfo-Prozess ausgeführt und kommuniziert über SMTP StoreDriver COM-Ereignisse mit dem erweiterten Warteschlangenmodul.
Epoxy.dll Diese DLL implementiert den Exchange Inter-Process Communications Layer (ExIPC – Exchange-Prozesskommunikationsschicht) zwischen IIS und dem Exchange-Informationsspeicher. IIS und der Exchange-Informationsspeicher verwenden diese Kommunikationsschicht für den schnellen Austausch von Daten direkt über Prozessgrenzen. Dies geschieht über den gemeinsam genutzten Speicher, der von dieser DLL in den virtuellen Adressraum beider Prozesse geladen wird.
Das Modell für den gemeinsam genutzten Speicher von Epoxy.dll beruht auf dem SMQ-Modell (Shared Memory Circular Queue). Das bedeutet, dass einzelne Umlaufwarteschlangen fester Größe auf der Epoxy.dll-Schicht für die Datenübertragung in beide Richtungen verwendet werden. Die Epoxy.dll-Schicht umfasst eine
320
Bindungseinrichtung, die es dem Informationsspeichertreiber ermöglicht, eine beliebige Anzahl von Umlaufwarteschlangen zwischen IIS und dem Exchange-Informationsspeicher zu erstellen und zu verbinden. Zu dieser Bindungseinrichtung gehört ein zentraler Warteschlangen-Manager, der die Warteschlangen überwacht, die über diesen Prozess miteinander kommunizieren. Diese Bindungseinrichtung wird auch zum Lösen von Warteschlangenbindungen und zum Bereinigen von Warteschlangen verwendet.
Hinweis: Epoxy.dll verwendet lokale Remoteprozeduraufrufe (LRPCs, Local Remote Procedure Calls) und einen gemeinsam genutzten Speicherheap für die Übergabe von Daten zwischen IIS und dem Exchange-Informationsspeicher. Der gemeinsam genutzte Speicher funktioniert nur bei Prozessen, die auf demselben Computer ausgeführt werden. Wenn Epoxy.dll verwendet wird, ist die Kommunikation zwischen Remoteprozessen wie in einem reinen RPC-Szenario nicht möglich.
ExSMTP.dll Diese DLL wird im Exchange-Informationsspeicherprozess ausgeführt und implementiert den Protokollstub für die Kommunikation mit dem Exchange-Informationsspeicher über EPOXY und mit der Inetinfo-Schnittstelle von Drviis.dll.
Installierbares Dateisystem von ExchangeZur Minimierung der Unterschiede zwischen dem Exchange-Informationsspeichertreiber und dem NTFS-Informationsspeichertreiber, der in Windows Server 2003 enthalten ist, implementiert Exchange Server 2003 ein Microsoft Win32-Dateisystem mithilfe der Streamingdatenbanken (.stm) im Exchange-Informationsspeicher. Die STM-Datei eines Exchange-Informationsspeichers enthält Internetnachrichten in ihrem jeweiligen Format (unformatierter Text, MIME oder UUEncode), während in der entsprechenden EDB-Datei Nachrichten im MAPI-Format gespeichert sind. Die STM-Datei der Streamingdatenbank enthält keine Verzeichnisstruktur. Die Strukturen des Exchange-Informationsspeicher werden in der EDB-Datei in Nachrichtentabellen verwaltet. Weitere Informationen zur Architektur und zum Design von Messagingdatenbanken finden Sie unter Architektur des Exchange-Informationsspeicherdiensts.
Das installierbare Dateisystem von Exchange besteht aus den folgenden Hauptkomponenten (siehe folgende Abbildung):
Exifs.sys Dies ist ein Kernelmodustreiber, mit dem der Exchange-Informationsspeichertreiber Elemente aus Messagingdatenbanken lesen bzw. Elemente in diese Datenbanken schreiben kann. Dieser Treiber enthält die Win32-Datei-API für den Exchange-Informationsspeicher.
Exwin32.dll Dies ist eine Erweiterung des Exchange-Informationsspeichers, die im Prozess Store.exe ausgeführt wird und Exifs.sys-Anforderungen für Vorgänge auf
321
Dateiebene (wie Erstellen, Öffnen, Umbenennen, Übergeben, Löschen usw.) verarbeitet. Beachten Sie, dass es sich hierbei um eine Benutzermoduskomponente handelt, die für Operationen im Win32-Dateisystem verwendet wird. Die Win32-Dateien werden nicht vom SMTP-Transportsubsystem verwendet.
Ifsproxy.dll Dies ist ein Benutzermoduswrapper für Exwin32.dll, der eine unkomplizierte Schnittstelle für Win32-Dateisystemaufrufe zur Verfügung stellt. Ifsproxy.dll spielt zudem eine entscheidende Rolle bei der Zuordnung von freiem Speicherplatz in der STM-Datei. ExIFS fordert bei der Zuordnung von freiem Speicherplatz in einer Datenbank Speicherplatz von ESE an. Wenn der Exchange-Informationsspeichertreiber z. B. ein neues Element im Exchange-Informationsspeicher erstellt, um eine Nachricht lokal zu übermitteln, fordert ExIFS Speicherplatz von ESE an.
ExIFS unterstützt zwei verschiedene Dateizugriffsmodi.
Win32 Dieser Modus beruht auf Dateinamen und dient dazu, den Exchange-Informationsspeicher im Dateisystem ähnlich darzustellen wie ein Festplattenlaufwerk. Das Betriebssystem ordnet den Dateinamespace \\.\backofficestorage dem installierbaren Dateisystem von Exchange zu. Dieser Namespace ermöglicht den Zugriff auf alle privaten und öffentlichen Datenbanken. Das Format lautet file://./backofficestorage/Domänenname, beispielsweise file://./backofficestorage/fabrikam.com.
Hinweis: Hinweis Win32-Dateien werden vorwiegend vom HTTP-DAV-Protokoll sowie von den APIs EXOLEDB und CDOEX verwendet.
EA EA ist das Akronym für Extended Attributes (erweiterte Attribute), die in einer speziellen Eigenschaft jeder Nachricht gespeichert werden. ExIFS kopiert die erweiterten Attribute in eine speicherinterne Struktur, die so genannte Scatterliste (SLIST). Bei der Scatterliste handelt es sich eigentlich um ein BLOB (Binary Large Object), das zum Öffnen eines Nachrichtenelements verwendet werden kann. EA-Dateien sind für die interne Verwendung durch das Exchange-Transportsubsytem vorgesehen und können von Benutzern nicht durch eine der dokumentierten APIs bzw. eines der dokumentierten Protokolle angezeigt werden. Ein EA-Pfad kann folgendermaßen dargestellt werden: \;E:\Ted\$705260a-46c4-454d-b0dd-96b9c605364\369b6c05-0256-46c7-fad3-54ffa867d089-0000001e.
Hinweis: Hinweis Die Komponenten im SMTP-Transportsubsystem verwenden zum Öffnen von Dateien im ExIFS ausschließlich erweiterte Attribute.
322
Integration of IIS and the Exchange store
Übertragung ausgehender NachrichtenDer Exchange-Informationsspeichertreiber führt an einer ausgehenden Nachricht die folgenden Schritte aus, um sie an die Vorübermittlungswarteschlange des erweiterten Warteschlangenmoduls zu übergeben.
1. Wenn ein Benutzer von Outlook eine Nachricht sendet, wird sie in den Postausgang des Benutzerpostfachs gestellt und zur Übermittlung gekennzeichnet.
2. Der Exchange-Informationsspeicher stellt die Nachricht in seinen internen SendQ-Ordner und ruft den Exchange-Informationsspeichertreiber auf, die Nachricht an IIS zu übertragen.
3. ExSMTP.dll ermittelt die Ordner-ID (FID, Folder Identifier) und die Nachrichten-ID (MID, Message Identifier) der Nachricht und liest die übermittlungsrelevanten Nachrichteneigenschaften (Absender- sowie Empfängeradresse und ob Übermittlungsberichte angefordert werden). ExSMTP.dll formatiert diese Eigenschaften in einen Eigenschaftenstream für das MailMsg-Objekt um. ExSMTP.dll fügt die FID und MID der Nachricht hinzu, sodass der Nachrichteninhalt später gegebenenfalls von Drviis.dll im Inetinfo-Prozess abgerufen werden kann. Durch die FID wird der Nachrichtenordner im
323
Exchange-Informationsspeicher, der die Nachricht enthält, eindeutig bestimmt. Durch die MID erhält die Nachricht selbst eine eindeutige Kennung.
Hinweis: Hinweis Der Nachrichtenumschlag enthält nicht den Nachrichteninhalt. Die Informationen im Nachrichtenumschlag werden von Epoxy.dll an Inetinfo übergeben. ExIFS.sys dient dazu, bei Bedarf den Nachrichteninhalt bereitzustellen. Ein Zugriff auf den Inhalt der Nachricht ist unter Umständen niemals erforderlich, wenn es sich um eine Übermittlung zwischen lokalen Adressen oder um eine Übermittlung von einer lokalen Adresse an einen Exchange-MTA handelt. Der RFC 822-Inhalt muss nur bei der Übermittlung an Empfänger in anderen Postfachspeichern, bei ausgehender SMTP-Übermittlung oder bei Ereignissenken erzeugt werden, die den Inhalt während eines Übermittlungsereignisses anfordern.
4. ExSMTP.dll übergibt mittels einer Umlaufwarteschlange für den gemeinsamen Speicher einen Zeiger auf den gemeinsam genutzten Speicherabschnitt an Drviis.dll. Wie aus Abbildung 6.13 hervorgeht, verweist der Zeiger auf den Abschnitt des zugeordneten gemeinsamen Speichers, der den Eigenschaftenstream des Umschlags, die Ordner-ID und die Nachrichten-ID enthält.
Inter-process communication using EPOXY
Hinweis: Hinweis Speicher für den Code und den Stapel wird nicht nur während der Laufzeit durch das Betriebssystem zugeordnet, sondern Speicher wird auch dynamisch durch einen Heap zugeordnet und freigegeben.
5. Der Zeiger wird auf der Inetinfo-Seite von Drviis.dll aus der Speicherumlaufwarteschlange entfernt. Der Zeiger verweist auf den gemeinsamen Speicher, der den Eigenschaftenstream des Umschlags, die Ordner-ID und die Nachrichten-ID enthält.
324
6. Drviis.dll liest mithilfe des Speicherzeigers den Eigenschaftenstream aus dem gemeinsamen Speicher in ein MailMsg-Objekt. Wie bereits weiter oben in diesem Kapitel erwähnt, besteht das MailMsg-Objekt aus einem Nachrichtenübertragungsumschlag, der die Informationen zum Weiterleiten der Nachricht zum nächsten Hop enthält, sowie aus einem Zeiger auf die eigentliche physische Nachricht. An diesem Punkt enthält das MailMsg-Objekt die Informationen des Nachrichtenübertragungsumschlags, da sich sämtliche Eigenschaften des MailMsg-Objekts in dem gemeinsam genutzten Speicherblock befinden, der von ExSMTP.dll erstellt wurde.
7. Drviis.dll stellt das MailMsg-Objekt in die Vorübermittlungswarteschlange. Die Nachricht kann nun vom Transportsubsystem verarbeitet werden.
8. Das erweiterte Warteschlangenmodul löst seine Übermittlungs- und Systemereignisse aus, um das Basis- und das Exchange-Kategorisierungsmodul, das Routingmodul und weitere registrierte Ereignissenken aufzurufen und die Nachricht zu verarbeiten. Die meisten Übermittlungsschritte werden mithilfe des Nachrichtenübertragungsumschlags ausgeführt. Der Nachrichteninhalt wird erst dann geöffnet, wenn dies explizit erforderlich ist. Dies geschieht z. B., wenn das Exchange-Kategorisierungsmodul den Inhalt konvertieren muss. Muss die Nachricht per SMTP zum nächsten Hop übertragen werden, muss das SMTP-Protokollmodul auf den Nachrichteninhalt im RFC 822-Format zugreifen.
Hinweis: Hinweis Bei lokaler Übermittlung von MAPI-Nachrichten (die ohne Inhaltskonvertierung von demselben Server gesendet und empfangen werden) wird der Inhalt nie von den SMTP-Transportkomponenten geöffnet (es sei denn, Sie haben benutzerdefinierte Ereignissenken installiert, die den RFC 822-Nachrichteninhalt zu lesen versuchen, beispielsweise eine Archivsenke).
9. Wenn der Nachrichteninhalt von einer Komponente im Transportsubsystem durch Aufrufen der Methode ReadContent oder WriteContent des MailMsg-Objekts geöffnet wird, erfolgt der Zugriff auf den Nachrichteninhalt wie auf eine Datei; dies lässt sich mit dem Zugriff auf Nachrichtenelemente im Ordner \Queue des Dateisystems vergleichen (z. B. bei Nachrichten, die per SMTP gesendet werden müssen). Werden Nachrichten durch den Exchange-Informationsspeicher übermittelt, werden ExIFS-Dateien anstelle von NTFS-Dateien verwendet.
10. Für Nachrichten im Exchange-Informationsspeicher ruft MailMsg die Bibliothek Drviis.dll auf, um eine gewöhnliche Dateizugriffsnummer zu öffnen. Der Nachrichteninhalt wird im RFC 822-Format angefordert. Bei kategorisierten Nachrichten enthält der Eigenschaftenstream eventuell auch einige zusätzliche ausgehende Konvertierungswerte, mit denen beim Abrufen des Inhalts ein bestimmtes Format angefordert werden kann.
11. Wie weiter oben in diesem Kapitel erwähnt, speichert Drviis.dll einen Zeiger auf die physische Nachricht im MailMsg-Objekt. Dieser Zeiger besteht aus der Ordner-ID und
325
der Nachrichten-ID der Nachricht. Drviis.dll verwendet diesen Zeiger sowie zusätzliche Parameter für die Inhaltsformatierung, um durch Epoxy.dll ein Nachrichtenanforderungspaket an Exsmtp.dll im Prozess Store.exe zu übergeben.
12. Exsmtp.dll ruft eine interne Methode des Exchange-Informationsspeichers namens EcGetMime zusammen mit der Ordner-ID und der Nachrichten-ID auf, um den Inhalt der Nachricht im RFC 822-Format anzufordern. Dabei werden eventuell weitere Parameter angegeben, die von Drviis.dll übergeben wurden.
Hinweis: Hinweis In Einträgen des Anwendungsereignisprotokolls sehen Sie möglicherweise, dass für den Aufruf der Methode EcGetMime als Ereignisquelle „MSExchangeTransport“ und als Ereigniskategorie „Exchange-Informationsspeichertreiber“ angegeben wird. For an example, see Microsoft Knowledge Base article 319682, "XGEN: The Exchange 2000 Information Store Reports an Event ID327 Warning Message and Virtual Memory May Be FragmentedXGEN: The Exchange 2000 Information Store Reports an Event ID327 Warning Message and Virtual Memory May Be Fragmented."
13. Da die Nachricht von Outlook übermittelt wurde, hat die Nachricht nicht das RFC 822-Format. Die Nachricht weist das MAPI-Format auf und ist in der EDB-Datei gespeichert. Daher ist der von Exsmtp.dll angeforderte Inhalt nicht in der Streamingdatenbank (die von ExIFS verwendet wird) vorhanden, wenn die Nachricht von einer Transportkomponente oder einem Internetclient geöffnet wird.
Hinweis: Hinweis Exchange Server 2003 speichert Nachrichten, die von MAPI-Clients, X.400-Connectors oder EDK-basierten Connectors (Exchange Development Kit) empfangen wurden, in der EDB-Datenbank im MAPI-Format.
14. Wenn die Nachricht nicht in der Streamingdatenbank vorhanden ist, muss sie mithilfe der verschiedenen Eigenschaften und Tabellen erstellt werden, die in der EDB-Datenbank enthalten sind und die die Nachricht beschreiben. Daher verwendet der Exchange-Informationsspeicher IMAIL, um eine temporäre ExIFS-Datei zu erstellen, und stellt die Nachricht aus der Datenbank entsprechend den angeforderten und übergebenen Formatierungsparametern in dieser Datei im RFC 822-Format dar.
Hinweis: Hinweis Das Exchange-Kategorisierungsmodul wendet mithilfe des IMAIL-Mechanismus Nachrichtenformate auf den Inhalt an. Maßgeblich sind hierbei die Festlegungen für Internetdomänen im Exchange-System-Manager bzw. die Festlegungen des Benutzers für den jeweiligen Empfänger in Outlook. Werden keine Formatierungsparameter an IMAIL übergeben, werden MAPI-Nachrichten im S/TNEF formatiert.
326
15. In Exchange Server 2003 erstellt ExIFS.sys eine temporäre ExIFS-Datei, sodass eine fehlerhaft arbeitende Ereignissenke, die den RFC 822-Inhalt zu ändern versucht, die übermittelten Seiten in der Streamingdatenbank nicht beschädigen kann. Die Ereignissenke schreibt keine wirklichen Inhaltsseiten, sondern lediglich eine Kopie.
16. Sobald die temporäre ExIFS-Datei erzeugt ist, wird die Dateizugriffsnummer wieder an Exsmtp.dll übergeben. Exsmtp.dll ruft ExIFS auf, um einen Zeiger auf die Seiten abzurufen, welche die Datei in der Streamingdatenbank belegt (d. h., einen Zeiger auf die erweiterten Attribute, die ExIFS in eine speicherinterne Struktur, die Scatterliste, kopiert).
17. Exsmtp.dll kopiert die Scatterliste in den gemeinsam genutzten Speicher und übergibt die Liste durch Epoxy.dll wieder an Drviis.dll.
18. Drviis.dll öffnet mithilfe dieser Scatterliste die ExIFS-Datei als EA-Datei. Da Drviis.dll jetzt über die geöffnete ExIFS-Dateizugriffsnummer verfügt, wird die Dateizugriffsnummer an MailMsg zurückgegeben, sodass Anforderungen an die Methode ReadContent oder WriteContent für den RFC 822-Nachrichteninhalt verarbeitet werden können.
19. Das SMTP-Protokollmodul kann nun den Nachrichteninhalt lesen und die Daten per SMTP an einen Remotehost oder einen Exchange-Server übertragen.
20. Nach der erfolgreichen Nachrichtenübertragung löscht das erweiterte Warteschlangenmodul das MailMsg-Objekt, da es nicht mehr benötigt wird. Dementsprechend ruft das erweiterte Warteschlangenmodul den Exchange-Informationsspeichertreiber (drviis.dll) auf, um die Nachricht zu löschen. Drviis.dll erzeugt eine Anforderung zum Löschen der Nachricht im gemeinsam genutzten Speicher und überträgt die Anforderung durch EPOXY an Exsmtp.dll. Exsmtp.dll verschiebt die Nachricht entweder aus dem Postausgang des Absenders in den Ordner Gesendete Objekte oder löscht die Nachricht.
Hinweis: Hinweis Der Inhalt wird bei jeder Anforderung neu dargestellt. Dabei wird jedes Mal eine temporäre ExIFS-Datei erzeugt. Solange diese Datei geöffnet bleibt, kann sie verwendet werden. Nachdem die Datei geschlossen wurde, wird sie automatisch verworfen, da es sich lediglich um eine temporäre Kopie der Nachricht handelt. Um die Anzahl der Darstellungszyklen zu minimieren, bleibt die Inhaltsdatei im erweiterten Warteschlangenmodul geöffnet, bis die Nachricht übertragen oder zugestellt wurde. Die Inhaltsdatei wird nur geschlossen, wenn Nachrichten gelöscht werden können oder zu einem späteren Zeitpunkt ein erneuter Übermittlungsversuch geplant ist. Die Übermittlung der Nachricht wird möglicherweise zu einem späteren Zeitpunkt wiederholt, entweder da der Remoteserver nicht verfügbar ist oder weil mehr als 10.000 Inhaltsdateien geöffnet sind und aktiv in der Warteschlange verarbeitet werden. Sind über 10.000 Inhaltsdateien geöffnet, die aktiv verarbeitet werden, müssen einige Dateien geschlossen werden, um Platz für andere Nachrichten zu schaffen. Wenn eine Nachricht zu einem späteren Zeitpunkt erneut geöffnet wird (z. B. da die Nachrichtenübertragung wiederholt wird), muss der Inhalt
327
neu dargestellt werden. Es ist wichtig zu wissen, dass IMAIL eine neue temporäre ExIFS-Datei darstellt, wenn die Datei geöffnet wird. Änderungen an dieser ExIFS-Datei gehen verloren, wenn die Datei geschlossen wird.
Übertragung eingehender NachrichtenFür eingehende Nachrichten, die an einen lokalen Empfänger oder den Exchange-MTA übermittelt werden müssen, führt der Exchange-Informationsspeichertreiber die folgenden Schritte aus.
1. Eine Nachricht wird entweder durch das SMTP-Protokollmodul oder den Exchange-Informationsspeichertreiber in die Vorübermittlungswarteschlange gestellt, anschließend kategorisiert und zur lokalen Übermittlung gekennzeichnet.
2. Das erweiterte Warteschlangenmodul löst ein SMTP StoreDriver-Ereignis aus, um der Ereignissenke des Exchange-Informationsspeichertreibers zu signalisieren, dass eine Nachricht an den Exchange-Informationsspeicher übertragen werden soll.
3. Wenn die Nachricht über eine SMTP-Verbindung oder über den Ordner \Pickup empfangen wird, befindet sich die Nachricht weiterhin im Ordner \Queue. Dementsprechend ruft Drviis.dll die Methode CreateFile() auf, um eine neue Datei in ExIFS zu erstellen, und kopiert das Nachrichtenobjekt in die neue Datei im Exchange-Informationsspeicher.
Hinweis: Hinweis Werden Nachrichten von demselben Postfachspeicher gesendet, in dem sie empfangen werden, wird der Inhalt nicht in den Informationsspeicher kopiert. Werden Nachrichten von verschiedenen Postfachspeichern auf demselben Server gesendet und empfangen, wird die Nachricht unter Verwendung von RFC 822 S/TNEF als Zwischenformat kopiert. Der Inhalt wird vom Exchange-Informationsspeicher nicht für den Inetinfo-Prozess bereitgestellt. Die Verarbeitung erfolgt im Exchange-Informationsspeicher. IMAIL stellt den Inhalt auf Anforderung durch Exsmtp.dll im S/TNEF in einer ExIFS-Datei dar. Mithilfe dieser ExIFS-Datei erstellt der Exchange-Informationsspeicher eine neue Nachricht, die an den Postfachspeicher übermittelt wird, der das Postfach des Empfängers enthält.
4. Bei Verwendung von SMTP und des Ordners \Pickup gibt ExIFS die Scatterliste zurück, die den Ort der Daten des neuen Elements in der Streamingdatenbank angibt.
5. Drviis.dll ordnet Speicher aus dem gemeinsam genutzten Speicherheap zu und fügt die Scatterliste in den zugeordneten Speicherblock ein. Ein Zeiger auf diesen Abschnitt des zugeordneten gemeinsamen Speichers wird daraufhin in die Warteschlange für den Store.exe-Prozess aufgenommen.
328
6. ExSMTP.dll empfängt den Zeiger von der Warteschlange auf der Seite des Exchange-Informationsspeichers. Der Zeiger verweist auf den gemeinsam genutzten Speicher, der die Scatterliste für die eingehende Nachricht enthält.
7. ExSMTP.dll ruft Ifsproxy.dll mit der Scatterliste auf, um von ExIFS eine Dateizugriffsnummer zu erhalten. Zur Übergabe des Objekts an die Datenbank muss eine Nachricht erstellt werden. Daher ruft ExSMTP.dll den Exchange-Informationsspeicherkernel (Store.exe) über die externe Schnittstelle der Messagingdatenbank (MDBEIF, Messaging Database External Interface) auf, um ein Nachrichtenobjekt zu erstellen. ExSMTP.dll übergibt anschließend die Dateizugriffsnummer für den Inhalt explizit an den Exchange-Informationsspeicherkernel. Dieser wiederum übergibt die Dateizugriffsnummer an ESE, um die Daten zu übermitteln, wenn ExSMTP.dll das Nachrichtenobjekt übergibt.
Hinweis: Hinweis In der MAPI-basierten Datenbankdatei (.edb) werden Seitenprüfsummen gespeichert. Die Streamindatenbankdatei (.stm) enthält keine Seitenprüfsummen.
8. Der Exchange-Informationsspeicher informiert Outlook, wenn eine neue Nachricht eintrifft, und Outlook listet die Nachricht im Ordner Posteingang auf.
9. ExSMTP.dll informiert Drviis.dll durch EPOXY darüber, dass die Übermittlung abgeschlossen ist. Daraufhin gibt Drviis.dll an das erweiterte Warteschlangenmodul ein positives Ergebnis zurück. Die Nachricht kann anschließend vom erweiterten Warteschlangenmodul auf folgende Weise gelöscht werden:
Die Nachricht wurde über SMTP oder das Verzeichnis \Pickup empfangen Das Verzeichnis \Queue enthält eine EML-Datei für die Nachricht. Das erweiterte Warteschlangenmodul ruft erneut MailMsg auf, damit die Nachricht gelöscht wird. Da das MailMsg-Objekt an den NTFS-Informationsspeichertreiber gebunden ist, wird der Aufruf an NTFSDrv.dll übergeben. NTFSDrv.dll löscht die Nachricht aus dem Verzeichnis \Queue im Dateisystem.
Die Nachricht wurde über den Exchange-Informationsspeichertreiber übermittelt Das erweiterte Warteschlangenmodul ruft erneut MailMsg auf, damit die Nachricht gelöscht wird. Da das MailMsg-Objekt an den Exchange-Informationsspeichertreiber gebunden ist, wird der Aufruf an Drviis.dll übergeben und eine EPOXY-Anforderung an ExSMTP.dll in eine Warteschlange gestellt. ExSMTP.dll verschiebt die Nachricht daraufhin entweder aus dem Postausgang des Absenders in den Ordner Gesendete Objekte oder löscht die Nachricht.
Hinweis: Hinweis Nachrichten für Remoteempfänger, die über das Verzeichnis \Pickup oder das SMTP-Protokollmodul eintreffen, erreichen den Exchange-Informationsspeicher nicht. Sie bleiben vielmehr im Ordner \Queue des Dateisystems, bis sie erfolgreich
329
zum nächsten Hop auf der Route zu ihrem Ziel übertragen werden. Das Kategorisierungsmodul verwendet unter Umständen jedoch den Exchange-Informationsspeicher für Nachrichten, die nicht durch den Exchange-Informationsspeichertreiber übermittelt werden. Das Kategorisierungsmodul muss eventuell Benachrichtigungen über den Übermittlungsstatus erzeugen, die im Exchange-Informationsspeicher erstellt werden.
Wiederholte ÜbertragungsversucheBeachten Sie, dass Nachrichten, die über den Exchange-Informationsspeichertreiber in das erweiterte Warteschlangenmodul gelangen, während des Kategorisierungs- und Routingprozesses sowie während der eigentlichen Übertragung im Exchange-Informationsspeicher bleiben. Die Nachrichten werden nicht in den Ordner \Queue des virtuellen SMTP-Servers kopiert. Diese Nachrichten bleiben auch dann im Exchange-Informationsspeicher, wenn ein Verbindungsfehler aufgetreten ist und die Verbindung erneut hergestellt werden muss. Wenn eine Nachricht nicht sofort übertragen werden kann, wird sie in eine temporäre Tabelle verschoben. Die Nachricht wird daher nicht mehr im Ordner Postausgang des Absenders angezeigt und in den Ordner Gesendete Objekte kopiert (wenn Outlook so konfiguriert ist, dass eine Kopie aller Nachrichten in diesem Ordner abgelegt wird). Die Nachricht bleibt in der temporären Tabelle, bis sie erfolgreich übertragen wird oder abgelaufen ist. Mit dem Snap-In Warteschlangenanzeige des Exchange-System-Managers können Sie diese Nachrichten in der Warteschlange für Nachrichten mit fehlerhafter Übermittlung anzeigen.
SMTP-ProtokollerweiterungenDas erweiterte Warteschlangenmodul ist nicht der einzige Verteiler von COM-Ereignissen im SMTP-Dienst. Das SMTP-Protokollmodul ist ebenfalls ein wichtiger Verteiler von COM-Ereignissen, insbesondere von SMTP-Ereignissen. Das zentrale SMTP-Protokollmodul ist für die gesamte normale SMTP-Kommunikation verantwortlich und verwaltet die meisten standardmäßigen SMTP-Diensterweiterungen (d. h. den ESMTP-Standard (Extended Simple Mail Transfer Protocol), der in RFC 821 und RFC 1869 definiert ist). SMTP kann mithilfe von Protokollereignissen bearbeitet werden. Auf diese Weise ist es möglich, neue ESMTP-Befehle hinzuzufügen oder sogar die Wirkung vorhandener Befehle zu ändern. Exchange Server 2003 verwendet diese Protokollereignisse zur Implementierung Exchange-spezifischer erweiterter SMTP-Befehle, um effizienter als über das normale SMTP mit anderen Exchange-Servern in der Organisation zu kommunizieren.
Wenn Sie über Telnet eine Verbindung mit dem TCP-Anschluss des virtuellen SMTP-Servers herstellen, können Sie überprüfen, ob die erweiterten SMTP-Befehle für Exchange Server 2003 geladen sind. Wie die folgende Abbildung zeigt, gibt die Serverantwort die Funktionen an, die vom virtuellen SMTP-Server unterstützt werden, wenn Sie den Befehl
330
EHLO senden, um eine ESMTP-Verbindung zu starten. Wenn Sie den Befehl HELP senden, werden die Standardbefehle aufgelistet.
Standardmäßige und erweiterte SMTP-Befehle von Exchange Server 2003
In der folgenden Tabelle werden die SMTP-Funktionen erläutert, die der erweiterte SMTP-Dienst von Exchange unterstützt.
In Exchange Server 2003 unterstützte SMTP-Funktionen
SMTP-Serverantwort Beschreibung
8BITMIME Gibt an, dass der lokale virtuelle SMTP-Server 8-Bit-MIME-Nachrichten unterstützt.
AUTH, AUTH GSSAPI NTLM LOGIN und AUTH=LOGIN
Signalisiert, dass der lokale virtuelle SMTP-Server die SMTP-Diensterweiterung für die Authentifizierung unterstützt. Mit den zusätzlichen Angaben nach dem Schlüsselwort AUTH werden die unterstützten Authentifizierungsmechanismen angegeben.
331
SMTP-Serverantwort Beschreibung
BDAT, CHUNKING Eine Alternative zum Befehl DATA, der zwei Argumente annimmt. Wenn ein virtueller SMTP-Server auf das Schlüsselwort EHLO mit CHUNKING antwortet, zeigt der SMTP-Server an, dass er den Befehl BDAT unterstützt und Nachrichten in Abschnitten entgegennimmt.
Das erste Argument gibt die Länge des binären Datenpakets an, sodass der SMTP-Host nicht ständig nach dem Ende der Daten suchen muss. Der empfangende Server zählt die Bytes in der Nachricht und geht bei Erreichen der vom Befehl BDAT gesendeten Nachrichtengröße davon aus, dass alle Nachrichtendaten empfangen wurden. Das zweite Argument gibt an, ob es sich bei dem Datenpaket um das letzte Paket der aktuellen Übertragung handelt. Das zweite Argument ist optional.
BINARYMIME Gibt an, dass der virtuelle SMTP-Server Nachrichten entgegennimmt, die binäre Daten ohne Transportcodierung enthalten. Dazu wird beim Befehl MAIL der Parameter BODY mit dem Wert "BINARYMIME" verwendet. Wenn der SMTP-Server einen MAIL-Befehl mit dem Wert BINARYMIME für den Parameter BODY akzeptiert, gibt der Server an, dass alle Bits in jedem mit dem Befehl BDAT übergebenen Oktett erhalten bleiben. Die SMTP-Erweiterung BINARYMIME kann nur zusammen mit CHUNKING verwendet werden.
DATA Wird von einem Remotehost gesendet, um die Übertragung des Nachrichteninhalts zu initiieren.
DSN Ein ESMTP-Befehl, der Benachrichtigungen über den Übermittlungsstatus ermöglicht, wie sie in RFC 1891 definiert sind.
332
SMTP-Serverantwort Beschreibung
EHLO Wird von einem Client gesendet, um den Beginn einer ESMTP-Sitzung zu signalisieren. Der Server kann in seiner Antwort auf EHLO angeben, ob er ESMTP-Befehle unterstützt (Abbildung 6.14).
ENHANCEDSTATUSCODES Gibt an, dass der SMTP-Server erweiterte Fehlerstatuscodes ausgibt. Den Textteilen aller SMTP-Statusantworten außer der Begrüßungsformel und Antworten auf HELO oder EHLO wird ein in RFC 1893 definierter Statuscode vorangestellt.
ETRN Wird von einem SMTP-Server gesendet, um den lokalen virtuellen Server aufzufordern, alle E-Mail-Nachrichten zu senden, die sich in der Warteschlange des Servers befinden und die für die im Befehl ETRN angegebenen Domänen bestimmt sind.
HELO Wird von einem Client gesendet, um sich selbst zu identifizieren, in der Regel mit einem Domänennamen, und um den Beginn einer normalen SMTP-Sitzung zu signalisieren.
HELP Gibt eine Liste von SMTP-Befehlen zurück, die vom virtuellen SMTP-Server bei normalen SMTP-Sitzungen (im Gegensatz zu ESMTP-Sitzungen) unterstützt werden.
MAIL Kennzeichnet den Beginn einer Nachrichtenübertragung durch Identifizierung des Absenders der Nachricht;wird im Formular MAIL FROM verwendet.
PIPELINING Bietet die Option, einen Strom von Befehlen zu senden, ohne auf eine Antwort nach jedem Befehl warten zu müssen.
QUIT Signalisiert das Ende einer normalen oder erweiterten SMTP-Sitzung.
333
SMTP-Serverantwort Beschreibung
RCPT Identifiziert die Empfänger der Nachricht; wird im Formular RCPT TO verwendet.
RSET Hebt die gesamte Nachrichtentransaktion auf und setzt den Puffer zurück.
SIZE Bietet einen Mechanismus, durch den der virtuelle SMTP-Server die maximal unterstützte Nachrichtengröße angeben kann. Kompatible Server müssen Größenerweiterungen bieten, um die maximale Nachrichtengröße anzugeben, die akzeptiert werden kann. Remotehosts sollten keine Nachrichten senden, die die vom Server angegebene Größe überschreiten.
STARTTLS Gibt an, dass der SMTP-Server sicheres SMTP über TLS unterstützt. Die SMTP-Diensterweiterung für sicheres SMTP über TLS ist in RFC 2487 definiert.
TURN Ermöglicht, dass die Rollen von Remotehost und lokalem Host getauscht werden und E-Mail-Nachrichten in die umgekehrte Richtung gesendet werden können, ohne dass eine neue Verbindung hergestellt werden muss.
VRFY Stellt sicher, dass ein Postfach für die Nachrichtenübermittlung zur Verfügung steht. Zum Beispiel stellt VRFY TED sicher, dass ein Postfach für Ted auf dem lokalen Server vorhanden ist. Dieser Befehl ist in Exchange 2003 standardmäßig verfügbar, dient jedoch nicht zur Überprüfung von Benutzern. Der Server informiert den Remotehost darüber, dass die Identität des Benutzers zwar nicht bestätigt werden kann, dass Nachrichten jedoch akzeptiert werden. Die Serverantwort hat folgendes Format: 252 2.1.5 Cannot VRFY user, but will take message for <[email protected]>
334
SMTP-Serverantwort Beschreibung
XEXCH50 Bietet die Möglichkeit, während einer Exchange Server 2003-Kommunikation zwischen Servern erweiterte Eigenschaften für den Umschlag des Nachrichtentransports im MDBEF (Message Database Encoding Format) zu senden.
X-EXPS GSSAPI NTLM LOGIN, X-EXPS=LOGIN
X-EXPS ist ein proprietärer Befehl von Exchange. Er ist mit AUTH vergleichbar, da er die Methoden angibt, die von Servern mit Exchange Server 2003 und Exchange 2000 Server für die Authentifizierung verwendet werden können. Hierzu gehören folgende Methoden:
GSSAPI Generic Security Services Application Programming Interface; eine Methode, welche die Authentifizierung durch Kerberos ermöglicht.
NTLM Windows NT and LAN Manager; eine Methode, welche die Authentifizierung über das Protokoll Windows NT Herausforderung/Rückmeldung ermöglicht.
LOGIN AUTH LOGIN, eine Standardauthentifizierungsmethode, bei der ein Benutzername und Kennwort verwendet werden, die mit Base 64 codiert sind.
X-LINK2STATE Erweitert den SMTP-Dienst um Unterstützung der Verbindungsstatusübermittlung. Einzelheiten zum Verbindungsstatusalgorithmus, mit dem Verbindungsstatusinformationen innerhalb und zwischen Routinggruppen übermittelt werden, finden Sie unter Nachrichtenroutingarchitektur.
335
Hinweis: Alle Exchange-spezifischen SMTP-Befehle beginnen mit „X-“(ohne die Anführungszeichen). Wenn diese Befehle nicht in der EHLO-Antwort des virtuellen SMTP-Servers aufgeführt werden, wird auf dem Server die Windows Server 2003-Basisversion des SMTP-Diensts ausgeführt. In diesem Fall müssen Sie Exchange Server 2003 und etwaige Service Packs neu installieren.
ProtokollereigniskategorienDas SMTP-Protokollmodul löst Protokollereignisse aus, um die Kommunikation zwischen Hosts zu steuern. Es gibt drei Haupttypen von Ereignissen, die in einer solchen Kommunikation über SMTP auftreten können:
Der SMTP-Dienst empfängt einen SMTP-Befehl Diese Ereignisse treten auf, wenn eine SMTP-Remotehost oder -Client eine Verbindung mit dem lokalen SMTP-Dienst herstellt und durch Senden des Befehls HELO oder EHLO eine Sitzung einrichtet. Ereignisse dieser Kategorie sind OnInboundCommand-SMTP-Ereignisse in eingehenden Verbindungen.
Der SMTP-Dienst empfängt eine SMTP-Antwort Diese Ereignisse treten auf, wenn der lokale SMTP-Dienst von einem SMTP-Remotehost oder -Client Antworten auf ausgehende SMTP-Befehle empfängt. Ereignisse dieser Kategorie sind OnServerResponse-SMTP-Ereignisse in ausgehenden Verbindungen.
Der SMTP-Dienst sendet einen SMTP-Befehl Diese Ereignisse treten auf, wenn der lokale SMTP-Dienst eine Verbindung mit einem SMTP-Remotehost herstellt und zur Übertragung von Nachrichten eine Sitzung einrichtet. Ereignisse dieser Kategorie sind die SMTP-Ereignisse OnSessionBegin, OnMessageStart, OnPerRecipient, OnBeforeData und OnSessionEnd in ausgehenden Verbindungen.
In der folgenden Tabelle wird ein Überblick über die Zwecke der einzelnen SMTP-Ereignisse gegeben.
Protokollereignisse im SMTP-Dienst
Ereignis Beschreibung
OnInboundCommand Tritt auf, wenn der SMTP-Dienst einen SMTP-Befehl empfängt, der einer Ereignissenke die Möglichkeit zu einer Antwort gibt.
OnServerResponse Tritt auf, wenn der SMTP-Dienst eine SMTP-Antwort auf einen zuvor gesendeten SMTP-Befehl empfängt.
336
Ereignis Beschreibung
OnSessionBegin Tritt auf, bevor der Befehl EHLO übertragen wird.
OnMessageStart Tritt auf, bevor der Befehl MAIL FROM übertragen wird.
OnPerRecipient Tritt auf, bevor der Befehl RCPT TO übertragen wird.
OnBeforeData Tritt auf, bevor der Protokollbefehl DATA übertragen wird.
OnSessionEnd Tritt auf, bevor der Befehl QUIT übertragen wird.
Exchange-spezifische SMTP-ProtokollerweiterungenDas Exchange Server 2003-Installationsprogramm registriert Exchange-spezifische SMTP-Protokollerweiterungen für die folgenden SMTP-Protokollfunktionen:
XEXCH50 Diese Funktion wird mithilfe von neun Ereignissenken implementiert, um die vollständige Kommunikation zwischen zwei Servern zu unterstützen, auf denen Exchange Server ausgeführt wird. In der folgenden Tabelle sind die Protokollereignisse den entsprechenden XEXCH50-Ereignissenken zugeordnet. Alle XEXCH50-Senken sind in peexch50.dll implementiert. Diese Datei befindet sich im Verzeichnis \Programme\Exchsrvr\bin.
Protokollerweiterungen für den Befehl XEXCH50
Ereignissenke Protokollereignis Beschreibung
Senke des Exchange SMTP-Protokolls XEXCH50 für bevorstehende Datenübertragung
OnBeforeData Benachrichtigt die XEXCH50-Senke über die bevorstehende Übertragung des Protokollbefehls DATA. Die XEXCH50-Senke hat nun die Möglichkeit, den SMTP-Dienst zu veranlassen, anstelle des Starts einer XEXCH50-Kommunikation einen XEXCH50-Befehl zu senden.
337
Ereignissenke Protokollereignis Beschreibung
Senke des Exchange SMTP-Protokolls XEXCH50 für eingehende EHLO-Befehle
OnInboundCommand Benachrichtigt die XEXCH50-Senke über den Empfang eines EHLO-Befehls.
Senke des Exchange SMTP-Protokolls XEXCH50 für eingehende XEXCH50-Befehle
OnInboundCommand Implementiert den XEXCH50-Befehl zum Start einer XEXCH50-Kommunikation.
Senke des Exchange SMTP-Protokolls XEXCH50 für eingehende MAIL-Befehle
OnInboundCommand Implementiert den MAIL-Befehl in einer XEXCH50-Kommunikation.
Senke des Exchange SMTP-Protokolls XEXCH50 für eingehende RCPT-Befehle
OnInboundCommand Ermöglicht es dem lokalen virtuellen SMTP-Server, die Empfängerinformationen in einer eingehenden XEXCH50-Kommunikation zu empfangen.
Senke des Exchange SMTP-Protokolls XEXCH50 für Empfängerinformationen
OnPerRecipient Ermöglicht es dem lokalen virtuellen SMTP-Server, die Empfängerinformationen in einer ausgehenden XEXCH50-Kommunikation zu senden.
338
Ereignissenke Protokollereignis Beschreibung
Senke des Exchange SMTP-Protokolls XEXCH50 für EHLO-Antworten
OnServerResponse Ermöglicht es dem lokalen virtuellen SMTP-Server, nach dem Senden eines EHLO-Befehls an den Remotehost eine Antwort zu empfangen. Die Antwort vom Remotehost weist möglicherweise darauf hin, dass XEXCH50-Kommunikationen unterstützt werden. Exchange nimmt XEXCH50 in die Liste der unterstützten Befehle auf, die an den die Verbindung herstellenden Host zurückgesendet werden (Abbildung 6.14).
Senke des Exchange SMTP-Protokolls XEXCH50 für Antworten
OnServerResponse Ermöglicht es dem lokalen virtuellen SMTP-Server, nach dem Senden eines ausgehenden XEXCH50-Befehls eine Antwort zu empfangen. Wenn beispielsweise der lokale SMTP-Dienst einen XEXCH50-Befehl ohne vorherige Authentifizierung gesendet hat, antwortet der Remoteserver mit: 504 Zuerst Authentifizierung erforderlich.
339
Ereignissenke Protokollereignis Beschreibung
Senke des Exchange SMTP-Protokolls XEXCH50 für RCPT-Antworten
OnServerResponse Ermöglicht es dem lokalen virtuellen SMTP-Server, für jeden in einem ausgehenden RCPT-Befehl angegebenen Empfänger eine Antwort vom Exchange-Remoteserver zu empfangen. Möglicherweise liegt eine Empfängeradresse in einem falschen Format vor oder der Server kann Nachrichten nicht weiterleiten. Wenn die Empfängerangaben korrekt sind, sendet der virtuelle SMTP-Remoteserver die Adresse zusammen mit Statusinformationen an den lokalen SMTP-Dienst zurück, z. B.: 250 2.1.5 [email protected].
X-LINK2STATE Diese Funktion wird mithilfe von fünf Ereignissenken implementiert. Wie in der folgenden Tabelle dargestellt, wird eine Ereignissenke jedoch für zwei verschiedene Ereignisse verwendet. Sämtliche X-LINK2STATE-Ereignissenken sind in Xlsasink.dll im Verzeichnis \Programme\Exchsrvr\bin implementiert.
Protokollerweiterungen für den Befehl X-LINK2STATE
Ereignissenke Protokollereignis Beschreibung
X-LSA-Senke des Handlers für eingehende EHLO-Befehle
OnInboundCommand Benachrichtigt die X-LINK2STATE-Ereignissenken über den Empfang eines eingehenden EHLO-Befehls.
X-LSA-Senke des Handlers für eingehende Befehle
OnInboundCommand Benachrichtigt die X-LINK2STATE-Ereignissenken über den Empfang eines eingehenden X-LINK2STATE-Befehls.
340
Ereignissenke Protokollereignis Beschreibung
X-LSA-Senke OnMessageStart, OnSessionEnd
Signalisiert den Start (Befehl MAIL) und das Ende (Befehl QUIT) einer ausgehenden X-LINK2STATE-Kommunikation. Da der virtuelle SMTP-Remoteserver der endgültige Empfänger des übertragenen Orginfo-Pakets ist, müssen in einem ausgehenden RCPT-Befehl keine Empfänger angegeben werden. Diese Ereignissenke überträgt die Verbindungsstatusinformationen.
X-LSA-Senke für den Antworthandler
OnServerResponse Antwortet auf einen eingehenden X-LINK2STATE-Befehl mit Informationen über die Übertragungsweise von Verbindungsstatusinformationen. Beispiel für eine Antwort: 200 LAST CHUNK={00000029} MULTI (5) ({00000010} DONE_RESPONSE). Auf diese Weise wird der letzte Datenteil gekennzeichnet, der vom virtuellen SMTP-Server gesendet wurde.
X-LSA-Senke des Handlers für EHLO-Antworten
OnServerResponse Beantwortet einen eingehenden EHLO-Befehl durch Auflisten des X-LINK2STATE-Befehls in der Serverantwort.
X-EXPS Diese Funktion wird mit fünf Ereignissenken implementiert, wie in der folgenden Tabelle angegeben. Alle Protokollsicherheitserweiterungen sind in Exps.dll im Verzeichnis \Programme\Exchsrvr\bin implementiert.
341
X-EXPS-Protokollsicherheitserweiterungen
Ereignissenke Protokollereignis Beschreibung
Exchange SMTP-Protokollsicherheitssenke für EXPS-EOD
OnInboundCommand Signalisiert das Ende der Datenübertragung (_EOD).
Exchange SMTP-Protokollsicherheitssenke für EXPS-AUTH
OnInboundCommand Signalisiert einen eingehenden AUTH-Befehl.
Exchange SMTP-Protokollsicherheitssenke für EHLO
OnInboundCommand, OnServerResponse
Signalisiert einen eingehenden EHLO-Befehl und antwortet auf EHLO durch Auflisten des X-EXPS-Befehls in der Serverantwort.
Exchange SMTP-Protokollsicherheitssenke für MAIL
OnInboundCommand, OnServerResponse, OnMessageStart
Signalisiert den Start der Datenübertragung. Diese Ereignissenke ist für alle relevanten MAIL-Befehlsszenarien implementiert. Sie verarbeitet Ereignisse, die einen eingehenden MAIL-Befehl melden, auf einen eingehenden MAIL-Befehl antworten und einen ausgehenden MAIL-Befehl senden können.
Exchange SMTP-Protokollsicherheitssenke für EXPS
OnInboundCommand, OnServerResponse, OnMessageStart
Signalisiert den Start einer X-EXPS-Sitzung. Diese Ereignissenke ist für alle relevanten X-EXPS-Befehlsszenarien implementiert. Sie verarbeitet Ereignisse, die einen eingehenden X-EXPS-Befehl melden, auf einen eingehenden X-EXPS-Befehl antworten und einen ausgehenden X-EXPS-Befehl senden können.
342
Kontrolle unerwünschter Werbe-E-Mails Diese Funktion wird mithilfe von drei Ereignissenken implementiert, die Sender- und Empfängerinformationen über eingehende SMTP-Verbindungen verarbeiten (siehe folgende Tabelle). Die Ereignissenken für die Kontrolle unerwünschter Werbe-E-Mails sind in Turflist.dll im Verzeichnis \Programme\Exchsrvr\bin implementiert.
SMTP-Erweiterungen für die Kontrolle unerwünschter Werbe-E-Mails
Ereignissenke Protokollereignis Beschreibung
Senke des Handlers für eingehende RCPT-Befehle
OnInboundCommand Signalisiert einen eingehenden RCPT-Befehl mit einer Empfängeradresse, die überprüft werden soll.
TURF-Senke des Handlers für eingehende MAIL-Befehle
OnInboundCommand Signalisiert einen eingehenden MAIL-Befehl mit einer Empfängeradresse, die überprüft werden soll.
Senke des Handlers für eingehende EOD-Befehle
OnInboundCommand Signalisiert einen eingehenden _EOD-Befehl.
Weitere InformationenVollständige Informationen zu SMTP finden Sie unter SMTP-Server.
Protokollaufzeichnungen, Ereignisprotokollierung und NachrichtenverfolgungDas SMTP-Transportsubsystem von Exchange Server 2003 implementiert die folgenden Ereignissenken, um den Verlauf aller Aktivitäten des SMTP-Diensts zu überwachen:
Exchange SMTP-Protokollierungssenke Diese Ereignissenke ist in Protolog.dll implementiert und für die Protokollereignisse OnServerResponse und OnInboundCommand registriert, um den Verlauf aller eingehenden SMTP-Befehle und die Serverantworten verfolgen zu können. Die Protokollierungssenke wird für die folgenden SMTP-Befehle aufgerufen: RCPT, QUIT, EHLO, X-EXPS, STARTTLS, TLS, X-LINK2STATE, HELO, XEXCH50, MAIL.
343
SMTP-Ereignisprotokollierungssenke Diese Ereignissenke ist in Tranmsg.dll implementiert und für die Systemereignisse StoreDriver und OnEventlog registriert.
MsgTrackLog-Senke Diese Ereignissenke ist in Msgtrack.dll implementiert und für das Systemereignis OnMsgTrackLog registriert.
ProtokollaufzeichnungenWenn Sie den Verlauf sämtlicher SMTP-Protokollaktivitäten speichern, können Sie belegen, dass eine bestimmte Nachricht von Ihrem Server gesendet wurde, und überprüfen, ob der virtuelle SMTP-Server die Aufgaben wie vorgesehen ausführt oder Kommunikationsprobleme vorliegen. Außerdem können Sie Angriffe aus dem Internet erkennen.
Auf der Registerkarte Allgemein des Exchange-System-Managers kann in den virtuellen Servereigenschaften für einen virtuellen SMTP-Server die folgende Protokollaufzeichnung konfiguriert werden:
Keine Protokolleinträge Es werden keine SMTP-Protokollaktivitäten über die Ereignissenke verfolgt.
Microsoft IIS-Protokolldateiformat Über die Ereignissenke werden SMTP-Protokollaktivitäten in einer Klartextdatei mit durch Komma getrennten Werten aufgezeichnet. Es werden folgende Informationen erfasst: die IP-Adresse des Remotehosts, der Hostname (falls angegeben), Datum und Uhrzeit der Anforderung, der Statuscode, die Anzahl der empfangenen Bytes, die seit der Anforderung vergangene Zeit, die Anzahl der gesendeten Bytes sowie die ergriffene Maßnahme. Die Werte sind durch Kommas getrennt, und die Liste kann nicht angepasst werden. Sie können den Pfad zu den Protokolldateien im Exchange-System-Manager konfigurieren. Der Standardpfad zum Verzeichnis der Protokolldateien lautet Windows\System32\LogFiles.
Hinweis: Wählen Sie für die detailliertesten Protokolle im Textformat die Option Microsoft IIS-Protokolldateiformat.
Allgemeines Protokolldateiformat für NCSA Über die Ereignissenke werden SMTP-Protokollaktivitäten in einer Klartextdatei mit durch Komma getrennten Werten aufgezeichnet. Hierbei handelt es sich um ein feststehendes, nicht anpassbares ASCII-Format, das grundlegende Informationen enthält: den Remotehostnamen, den Benutzernamen, Datum, Uhrzeit, Befehlstyp, Statuscode und die Anzahl der empfangenen Bytes. Die Werte sind durch Leerzeichen getrennt.
ODBC-Protokollierung Über die Ereignissenke werden SMTP-Protokollaktivitäten in einer ODBC-kompatiblen Datenbank (z. B. Microsoft Access oder Microsoft SQL Server) aufgezeichnet. Zum Zweck der Problembehebung genügt es u. U., Protokollaktivitäten in einer ASCII-Textdatei anstatt in einer ODBC-kompatiblen Datenbank zu protokollieren.
344
Hinweis: IIS enthält eine SQL-Vorlagendatei, die in einer SQL-Datenbank ausgeführt werden kann, um eine Tabelle zu erstellen, die Protokolleinträge von IIS akzeptiert.
Erweitertes Protokolldateiformat für W3C Über die Ereignissenke werden SMTP-Protokollaktivitäten in einer anpassbaren Klartextdatei mit durch Komma getrennten Werten aufgezeichnet. Wenn Sie dieses Format wählen, können Sie alle Felder aus der Protokolldatei ausschließen, die keine für SMTP-Protokollaktivitäten wesentlichen Informationen enthalten, z. B. den Benutzernamen bei einer anonymen SMTP-Kommunikation. Auf diese Weise können Sie durch das Weglassen unerwünschter Felder die Protokollgröße verringern. Die Felder sind durch Leerzeichen getrennt.
EreignisprotokollierungIn Exchange Server 2003 wird die SMTP-Ereignisprotokollsenke verwendet, um Ereignisse für interne SMTP-Dienstkomponenten im Anwendungsereignisprotokoll aufzuzeichnen. Als Ereignis in diesem Sinne wird jede beliebige Erscheinung im System bezeichnet, die möglicherweise die Aufmerksamkeit des Administrators erfordert. Ereignisprotokolle können Ihnen dabei helfen, die Quelle aktueller Systemprobleme zu diagnostizieren oder potenzielle Probleme zu erkennen. Standardmäßig wird nur ein Minimum an Informationen im Ereignisprotokoll aufgezeichnet. Allerdings können Sie mithilfe der im Exchange-System-Manager verfügbaren Diagnoseprotokolleinstellungen die Menge der aufzuzeichnenden Informationen erhöhen.
Hinweis: Um die Menge der während des normalen Betriebs im Anwendungsereignisprotokoll eingetragenen Informationen zu reduzieren, werden in Exchange Server 2003 mehrmals pro Stunde auftretende Ereignisse nur einmal protokolliert.
Genaue Anweisungen zum Aktivieren des Diagnoseprotokolls finden Sie unter Aktivieren der Diagnoseprotokollierung für den SMTP-Dienst im Exchange-System-Manager.
Produktsupport-ProtokollierungÜber Protokollierungsgrade wird die Menge der Daten gesteuert, die im Anwendungsprotokoll gespeichert werden. Je mehr Ereignisse protokolliert wurden, desto mehr Transport-bezogene Ereignisse werden im Anwendungsereignisprotokoll angezeigt, und um so höher ist die Chance, die Ursachen des Nachrichtenflussproblems zu ermitteln. Wenn Sie die ausführlichsten Informationen über den SMTP-Dienst benötigen, können Sie die Diagnoseprotokollierungsstufe für die internen SMTP-Dienstkomponenten auf Produktsupport einstellen, um das Protokollieren von Ablaufverfolgungsstufen-Ereignissen
345
zu aktivieren. Produktsupport kann nicht im Exchange-System-Manager ausgewählt werden, sondern nur mithilfe des Registrierungs-Editors festgelegt werden.
Detaillierte Anweisungen zum Festlegen der Diagnoseprotokollierungsstufe für MSExchangeTransport-Kategorien auf Produktsupport finden Sie unter Festlegen des Diagnoseprotokolliergrads für MSExchangeTransport-Kategorien auf Produktsupport.
Weitere Informationen zur Produktsupport-Protokollierung finden Sie im Microsoft Knowledge Base-Artikel 262308 XCON: How to Generate Application Log Events for Non-Delivery Report Failures).
NachrichtenverfolgungMithilfe der Funktion Nachrichtenstatus können Nachrichten in einer Exchange-Organisation verfolgt werden. Sie können alle Typen von Nachrichten verfolgen, einschließlich Systemnachrichten und regulärer E-Mail-Nachrichten, die vom Messagingsystem eines Drittanbieters stammen oder an ein solches System gesendet werden. Ein Beispiel für Systemmeldungen sind Replikationsmeldungen Öffentlicher Ordner, die die Exchange-Informationsspeicher auf mehreren Servern miteinander austauschen, um die Synchronisierung von Instanzen Öffentlicher Ordner auf separaten Servern zu gewährleisten. Sie können den Nachrichtenstatus zum Suchen von Nachrichten verwenden, die nicht in den Postfächern der Benutzer angekommen sind, z. B. Nachrichten, die die Warteschlange eines Connectors nicht verlassen können.
Die Nachrichtenverfolgung ist in der Standardeinstellung deaktiviert. Sie müssen diese Funktion auf jedem Server aktivieren, für den die Nachrichtenverfolgung durchgeführt werden soll. Nach dem Aktivieren verwendet Exchange Server 2003 die MsgTrackLog-Senke des SMTP-Diensts, um den Nachrichtenverfolgungsprotokollen die Verfolgungsinformationen über Nachrichten hinzuzufügen, die über den Server geleitet werden. Zum Aktivieren der Nachrichtenverfolgung für mehrere Server können Sie eine Serverrichtlinie verwenden.
Genaue Anweisungen zum Aktivieren der Nachrichtenverfolgung finden Sie unter Aktivieren der Nachrichtenverfolgung im Exchange-System-Manager. Sie können auch konfigurieren, wie in Exchange Server 2003 die Nachrichtenverfolgungs-Protokolldateien verwaltet werden. Sie können z. B. festlegen, dass Protokolldateien nicht gelöscht werden bzw. wie lange Protokolldateien aufbewahrt werden. Die Standardeinstellung für den Speicherzeitraum ist sieben Tage. Weitere Informationen zum Verwenden der Nachrichtenverfolgung finden Sie im Microsoft Knowledge Base-Artikel 262162 XADM: Using the Message Tracking Center to Track a Message).
Hinweis: Nachrichtenverfolgungsprotokolle können auf Bridgeheadservern, die zahlreiche eingehende und ausgehende Nachrichten verarbeiten, rasch größer werden. Stellen Sie sicher, dass auf den Datenträgern genügend Speicherplatz für Verfolgungsprotokolldateien vorhanden ist.
346
Aktivieren der Diagnoseprotokollierung für den SMTP-Dienst im Exchange-System-ManagerIn diesem Verfahren wird erläutert, wie im Exchange-System-Manager die Diagnoseprotokollierung für den SMTP-Dienst aktiviert wird. Dieses Verfahren führen Sie aus, wenn Sie die Informationsmenge vergrößern möchten, die ins Systemereignisprotokoll geschrieben werden kann.
Bevor Sie beginnenBevor Sie das Verfahren in diesem Thema durchführen, sollten Sie Folgendes berücksichtigen:
Wenn die Diagnoseprotokollierungsstufe auf Maximal eingestellt wird, werden viele Ereignisse in das Anwendungsereignisprotokoll eingetragen. Es wird empfohlen, die Größe des Anwendungs- und des Systemereignisprotokolls auf 30 MB einzustellen und die Option zum Überschreiben von Ereignissen bei Bedarf zu aktivieren. Vergessen Sie nicht, wieder die Standardeinstellung Keine einzustellen, nachdem Sie das Problem behoben haben.
VerfahrenAktivieren der Diagnoseprotokollierung für den SMTP-Dienst im Exchange-System-
Manager
1. Zeigen Sie die Eigenschaften des Exchange Server-Objekts an, das als Host des virtuellen SMTP-Servers fungiert.
2. Klicken Sie auf die Registerkarte Diagnoseprotokoll.
3. Klicken Sie unter Dienste auf MSExchangeTransport.
4. Wählen Sie unter Kategorien alle Kategorien aus, die der SMTP-Dienst zur Verfügung stellt, einschließlich Routingmodul/dienst, Kategorisierungsmodul, Warteschlangenmodul, Exchange-Informationsspeichertreiber, NTFS-Informationsspeichertreiber, SMTP-Protokoll und Verbindungs-Manager.
5. Klicken Sie unter Protokolliergrad auf die geeignete Protokollierungsstufe. Zur Problembehebung empfiehlt es sich, die Ereignisprotokollierungsstufe für die MSExchangeTransport-Dienste auf Maximal einzustellen, um die ausführlichsten Informationen zu erhalten.
347
Festlegen des Diagnoseprotokolliergrads für MSExchangeTransport-Kategorien auf ProduktsupportIn diesem Verfahren wird das Festlegen des Diagnoseprotokolliergrads für MSExchangeTransport-Kategorien auf Produktsupport erläutert. Dieses Verfahren wird ausgeführt, um das Protokollieren von Ablaufverfolgungsstufen-Ereignissen im SMTP-Dienst zu aktivieren und dazu beizutragen, die Ursache von Nachrichtenflussproblemen festzustellen.
Bevor Sie beginnenBevor Sie das Verfahren in diesem Thema durchführen, sollten Sie Folgendes berücksichtigen:
Die Einstellung Produktsupport beeinträchtigt die Serverleistung. Sie sollte nur unter Anleitung des Microsoft-Produktsupports bei der Behebung komplexer Transportprobleme verwendet werden.
Dieser Artikel enthält Informationen zum Bearbeiten der Registrierung.
Vorsicht: Die falsche Verwendung des Registrierungs-Editors kann zu ernsthaften Problemen führen, die möglicherweise eine Neuinstallation des Betriebssystems erforderlich machen. Dadurch entstandene Probleme können unter Umständen nicht mehr behoben werden. Sichern Sie vor dem Ändern der Registrierung alle wichtigen Daten.
VerfahrenFestlegen des Diagnoseprotokolliergrads für MSExchangeTransport-Kategorien auf
Produktsupport
1. Starten Sie den Registrierungs-Editor, und öffnen Sie folgenden Registrierungsschlüssel: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeTransport\Diagnostics.
2. Doppelklicken Sie nacheinander auf die Einträge für die einzelnen MSExchangeTransport-Kategorien, und stellen Sie den Wert 0x7 ein. Doppelklicken Sie z. B. auf den Eintrag 2 Categorizer im rechten Fensterbereich, und ändern Sie dann den Wert in 0x7.
3. Starten Sie den SMTP-Dienst neu. In der Regel müssen Dienste nicht neu gestartet
348
werden, damit die Änderung wirksam wird. Wenn Sie die Registrierung manuell bearbeiten, müssen Sie diesen Schritt jedoch ausführen.
Weitere InformationenWeitere Informationen zur Produktsupport-Protokollierung finden Sie im Microsoft Knowledge Base-Artikel 262308 XCON: How to Generate Application Log Events for Non-Delivery Report Failures).
Aktivieren der Nachrichtenverfolgung im Exchange-System-ManagerIn diesem Thema wird das Aktivieren der Nachrichtenverfolgung im Exchange-System-Manager erläutert. Mit diesem Feature können Sie alle Typen von Nachrichten verfolgen, einschließlich Systemnachrichten und regulärer E-Mail-Nachrichten, die über Ihre Exchange-Organisation vom Messagingsystem eines Drittanbieters eingehen oder an ein solches System gesendet werden. Sie können den Nachrichtenstatus zum Suchen von Nachrichten verwenden, die nicht in den Postfächern der Benutzer angekommen sind, z. B. Nachrichten, die die Warteschlange eines Connectors nicht verlassen können.
Bevor Sie beginnenBevor Sie das Verfahren in diesem Thema durchführen, sollten Sie Folgendes berücksichtigen:
Die Nachrichtenverfolgung ist in der Standardeinstellung deaktiviert. Sie müssen diese Funktion auf jedem Server aktivieren, für den die Nachrichtenverfolgung durchgeführt werden soll. Zum Aktivieren der Nachrichtenverfolgung für mehrere Server können Sie eine Serverrichtlinie verwenden.
Hinweis: Nachrichtenverfolgungsprotokolle können auf Bridgeheadservern, die zahlreiche eingehende und ausgehende Nachrichten verarbeiten, rasch größer werden. Stellen Sie sicher, dass auf den Datenträgern genügend Speicherplatz für Verfolgungsprotokolldateien vorhanden ist.
349
VerfahrenNachrichtenverfolgung aktivieren
1. Starten Sie den Exchange-System-Manager, und zeigen Sie die Eigenschaften des Servers an, auf dem Sie die Nachrichtenverfolgung aktivieren möchten.
2. Aktivieren Sie auf der Registerkarte Allgemein das Kontrollkästchen Nachrichtenverfolgung aktivieren.
3. Klicken Sie auf das Kontrollkästchen Nachrichtenbetreff protokollieren und anzeigen, um zusätzlich zu den Umschlaginformationen wie An, Von und Gesendet am die Betreffzeile jeder Nachricht zu verfolgen.
ReferenzWeitere Informationen zum Verwenden der Nachrichtenverfolgung finden Sie im Microsoft Knowledge Base-Artikel 262162 XADM: Using the Message Tracking Center to Track a Message).
X.400-TransportarchitekturMicrosoft Exchange Server 2003 verwendet für die standardmäßige Nachrichtenübertragung SMTP (Simple Mail Transfer Protocol). Die Kernkomponenten von Exchange Server 2003 beinhalten jedoch auch einen MTA (Message Transfer Agent), der mit den X.400-Empfehlungen von 1988 kompatibel ist. Infolgedessen können Sie zum Einrichten des Nachrichtenbackbones Ihrer Exchange-Organisation oder für die Verbindung mit einem externen X.400-Messagingsystem X.400-Connectors verwenden. Wenn Sie anstelle von SMTP-Connectors X.400-Connectors verwenden, fügen Sie eine zusätzliche Sicherheitsebene hinzu. Ursache hierfür ist, dass sich MTAs für den X.400-Standard authentifizieren müssen, bevor Nachrichten übertragen werden können. Beachten Sie jedoch, dass die Verwaltung von X.400-MTAs und X.400-Connectors aufwendiger ist als für SMTP-Connectors. X.400-E-Mail-Adressen sind aufgrund ihrer zahlreichen Attribute nicht benutzerfreundlich. X.400 stellt einen komplexen Standard dar, der basierend auf den folgenden Empfehlungen die Architektur eines MHS (Message Handling System) festlegt: X.200, X.217, X.218, X.227, X.228, X.402, X.411, X.413, X.419, X.420, X.435, X.680, X.690, X.880, X.881 und X.882.
Der X.400-Standard wurde ursprünglich in den 1980ern von Telekommunikationsunternehmen unter der Schirmherrschaft des CCITT (Committee for International Telephone and Telegraph) entwickelt, der späteren ITU-T (Telecommunications Standardization Sector of the International Telecommunication Union). ITU-T veröffentlicht alle 4 Jahre aktualisierte X.400-Empfehlungen. Jede Aktualisierung führt neue Funktionen
350
ein, bleibt jedoch mit vorangegangenen Versionen kompatibel. Die erste offizielle X.400-Empfehlung wurde 1984 veröffentlicht und wird wegen der Farbe des Buchumschlags als „Red Book“ bezeichnet. Die X.400-Empfehlung aus dem Jahr 1984 wies mehrere Schwachstellen im Bereich der Nachrichtenverarbeitung auf. Die X.400-Empfehlungen aus dem Jahr 1988 führten zusätzliche X.400-Nachrichtentextteile und Umschlageigenschaften ein. Objektkennungen beschreiben Nachrichtenanlagen präzise, sodass Anlagennamen und andere Objekteigenschaften erhalten bleiben. Der X.400-Standard von 1988 wird als „Blue Book“ bezeichnet.
Hinweis: Die ITU-T verwendet Buchstaben aus dem englischen Alphabet, um ihre Standards zu kategorisieren: Das „X“ in X.400 gibt an, dass der Standard für Datennetzwerke und offene Systemkommunikation bestimmt ist. Weitere Einzelheiten zu „X“-Standards finden Sie auf der ITU-T-Website (http://www.itu.int/).
Folgende Themen werden in diesem Abschnitt behandelt:
Exchange-MTA in der Exchange Server 2003-Architektur In diesem Abschnitt wird erläutert, wie Exchange-MTA in andere Exchange Server 2003-Komponenten integriert ist. Außerdem finden Sie hier einen allgemeinen Überblick zur Nachrichtenübertragung über X.400- oder MAPI-basierte Gatewayconnectors.
X.400-Connectors und Transportstapel Die X.400-Nachrichtenübertragung wird über Protokolle geregelt, die die Kommunikation zwischen MTAs festlegen. X.400-Connectors und Transportstapel ermitteln diese Kommunikationsparameter für Exchange-MTA. Die Konfiguration von Connectors und Transportstapeln erfordert eine gute Kenntnis dieser Protokolle und Parameter. Sie müssen die Voraussetzungen der X.400-Kommunikation verstehen, um Probleme mit X.400-Verbindungen beheben zu können.
Verbinden von Routinggruppen mithilfe von X.400-Connectors Wenn Exchange-MTAs miteinander über X.400-Connectors kommunizieren, stimmen sie nicht notwendigerweise mit allen Aspekten von X.400 überein. Das bedeutet konkret, Exchange-MTAs unterstützen Nachrichtenformate, die nicht in X.400 definiert sind. Es werden Verbindungsstatusinformationen ausgetauscht, sodass alle Server einer Organisation, auf denen Exchange Server 2003 ausgeführt wird, dynamisches Nachrichtenrouting ausführen können. Dies ist in Nachrichtenroutingarchitektur erläutert.
Exchange-MTA in einer Organisation im gemischten Modus Wenn Sie eine Organisation in einem gemischten Modus betreiben, müssen Sie die unterschiedlichen Aufgaben verstehen, die der Exchange-MTA zum Unterstützen der nahtlosen Integration von Exchange Server 2003 mit Exchange Server 5.5 ausführen muss.
Dieser Abschnitt setzt voraus, dass Sie mit dem Entwurf von Nachrichtenroutingtopologien und der Konfiguration von X.400-Connectors vertraut sind. Weitere Informationen zur Konfiguration von X.400-Connectors finden Sie unter Exchange Server 2003 Administration Guide.
351
Exchange-MTA in der Exchange Server 2003-ArchitekturDer Exchange-MTA stellt eine Kernkomponente von Exchange Server 2003 dar und ist zuständig für alle Nachrichtenübertragungen, die nicht auf SMTP beruhen. Hierzu zählt die Nachrichtenübertragung an externe X.400-Messagingsysteme und Exchange-Server, die über X.400-Connectors verbunden sind. Die Nachrichtenübertragung an Messagingsysteme, die nicht zu Exchange gehören (z. B. Lotus Notes und Domino oder Microsoft Exchange Connector für Novell GroupWise), wird durch den Exchange-MTA über MAPI-basierte Connectors wie Microsoft Exchange Connector für Lotus Notes oder Microsoft Exchange Connector für Novell GroupWise überwacht. Außerdem ist Exchange-MTA auch für die RPC-basierte Kommunikation mit Exchange Server 5.5 verantwortlich. Es wird empfohlen, Exchange-MTA auf allen Servern zu implementieren, die Exchange Server 2003 ausführen.
Exchange-MTA-KommunikationspartnerDer Exchange-MTA ist in einem Microsoft Windows®-Dienst mit der Bezeichnung Microsoft Exchange MTA-Stacks implementiert. Wenn Sie die Eigenschaften des Diensts Microsoft Exchange MTA-Stacks im Programm Dienste anzeigen und auf die Registerkarte Abhängigkeiten klicken, können Sie feststellen, dass dieser Dienst von der Systemaufsicht abhängt. Die Systemaufsicht fungiert als Host der Verzeichnisdienstzugriff-Komponente (DSAccess – Directory Service Access), die vom MTA verwendet wird, um Empfänger- und Konfigurationsinformationen aus dem Active Directory abzurufen. Wie in der folgenden Abbildung veranschaulicht, besteht jedoch nicht nur eine Abhängigkeit mit der Systemaufsicht.
352
MTA-Kommunikationspartner
Exchange-MTA kommuniziert mit folgenden Komponenten:
Active Directory Die Kommunikation mit Active Directory ist erforderlich, da sich das MTA-Konfigurationsobjekt und das X.400-Connectorobjekt in der Konfigurationsverzeichnispartition von Active Directory befinden. Exchange-MTA kann nicht gestartet werden, wenn Active Directory nicht verfügbar ist.
Registrierungsdatenbank Nicht alle MTA-Konfigurationseinstellungen werden in Active Directory verwaltet. Wichtige Einstellungen für den Dienst Microsoft Exchange-MTA-Stacks werden auch in der Registrierungsdatenbank des Servers an folgendem Speicherort gespeichert: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeCalCon. In diesem Abschnitt werden verschiedene Einstellungen erläutert, die Sie unter dem Schlüssel Parameter finden. Durch manuelles Konfigurieren der Registrierungsparameter mithilfe des Registrierungs-Editors können Sie eine Feinabstimmung der MTA-Leistung vornehmen.
Vorsicht: Die fehlerhafte Verwendung des Registrierungs-Editors kann zu schwerwiegenden Problemen führen, die möglicherweise eine Neuinstallation des Betriebssystems erforderlich machen. Microsoft übernimmt keine Garantie dafür, dass durch unsachgemäßes Verwenden des Registrierungs-Editors
353
verursachte Probleme behoben werden können. Sie verwenden den Registrierungs-Editor auf eigene Verantwortung.
SMTP-Dienst In Exchange Server 2003 führt der Exchange-MTA kein Nachrichtenrouting aus. Das Nachrichtenrouting erfolgt über das Routingmodul, das Bestandteil des SMTP-Diensts ist. Zum Treffen von Routingentscheidungen kommuniziert der Exchange-MTA über Mtaroute.dll mit dem Routingmodul.
Beachten Sie, dass die Kommunikation mit dem SMTP-Dienst in beide Richtungen verläuft. Der MTA kommuniziert zum Zweck des Nachrichtenroutings mit dem SMTP-Dienst. Bei Änderungen an der Routingtopologie initialisiert der SMTP-Dienst die Kommunikation, um den MTA darüber zu informieren, dass alle Nachrichten neu weitergeleitet werden müssen. Informationen zur Interaktion von MTA und SMTP-Dienst finden Sie unter Verbinden von Routinggruppen mithilfe von X.400-Connectors.
Exchange-Informationsspeicher Wie in der folgenden Abbildung dargestellt, leitet der SMTP-Dienst ausgehende Nachrichten über die MTA-Nachrichtenwarteschlange im Exchange-Informationsspeicher an den Exchange-MTA weiter. Der Exchange-MTA leitet auch eingehende Nachrichten an den SMTP-Dienst über den Exchange-Informationsspeicher weiter. Die Kommunikation mit dem Exchange-Informationsspeicher ist erforderlich, wenn Nachrichten über MAPI-basierte Nachrichtenconnectors übertragen werden müssen, für die der Exchange-MTA zuständig ist. MAPI-basierte Nachrichtenconnectors unterhalten – ähnlich wie der SMTP-Dienst – Nachrichtenwarteschlangen im Exchange-Informationsspeicher. Ausführlichere Informationen hierzu finden Sie unter Architektur von Gateway-Messaging-Connectors.
354
MTA-Kommunikation über den Exchange-Informationsspeicher
Für die Kommunikation mit dem Exchange-Informationsspeicher verwendet der MTA eine interne API mit der Bezeichnung XAPI, die einen Wrapper für MAPI darstellt. Zum erfolgreichen Starten des Diensts Microsoft Exchange MTA-Stacks benötigt der Exchange-Informationsspeicher mindestens einen Postfachspeicher zum Hosten der Nachrichtenwarteschlangen. Weitere Informationen über die Verarbeitung ausgehender und eingehender Nachrichten erhalten Sie weiter unten in diesem Abschnitt.
Hinweis: Wenn Ihr Bridgeheadserver unter Exchange Server 2003 als Host vieler X.400-Connectors fungiert oder Verbindungen mit Messagingsystemen von Drittanbietern (z. B. Lotus Notes und Novell GroupWise) herstellt, sollten Sie erwägen, die Transaktionsprotokolle und Datenbankdateien des Exchange-Informationsspeichers auf separaten Laufwerken unterzubringen, auch wenn der Exchange-Informationsspeicher keine Benutzerpostfächer enthält. Durch das Verteilen der Datenbankdateien auf mehrere physische Laufwerke kann die Systemleistung gesteigert werden.
Dateisystem Der Exchange-MTA verwendet zwei wichtige Verzeichnisse im Dateisystem. Diese Verzeichnisse werden als MTA-Datenbankverzeichnis und MTA-Ausführungsverzeichnis bezeichnet. Das Datenbankverzeichnis enthält Warteschlangendateien und Nachrichten, die gerade übertragen werden, in Form von
355
DAT-Dateien. Diese Sammlung von DAT-Dateien wird als MTA-Datenbank bezeichnet. Das Ausführungsverzeichnis enthält Vorlagendateien (so genannte „Ausführungsdateien“). Ausführungsdateien legen fest, wie Daten vom MTA mithilfe von ASN.1 (Abstract Syntax Notation One) formatiert werden. In der Standardeinstellung verweisen sowohl das Datenbankverzeichnis als auch das Ausführungsverzeichnis auf das gleiche physische Verzeichnis im Dateisystem. Wie in Abbildung 7.2 dargestellt, handelt es sich dabei um das Verzeichnis \Programme\Exchsrvr\Mtdata. Es empfiehlt sich, die Datenbank und das Ausführungsverzeichnis zu trennen. Informationen hierzu finden Sie weiter unten in diesem Abschnitt.
Hinweis: Das Ausführungsverzeichnis enthält nicht die eigentliche Programmdatei (Emsmta.exe) und die DLL-Dateien (Dynamic Link Libraries) des Diensts Microsoft Exchange MTA-Stacks. Emsmta.exe und die DLL-Dateien (z. B. Mtaroute.dll) befinden sich im Verzeichnis \Programme\Exchsrvr\bin.
Remote-X.400-MTA Der Exchange-MTA kommuniziert über X.400-Connectors mit Remote-X.400-MTAs. Ein X.400-Connector ist ein Konfigurationsobjekt in Active Directory, das die Kommunikationsparameter und Nachrichtenformate beschreibt, die der Exchange-MTA für die Nachrichtenübertragung verwendet. Bei einem Remote-X.400-MTA kann es sich um den MTA eines Drittanbieters oder um einen Exchange-MTA handeln, der über einen X.400-Connector verbunden ist. Weitere Informationen zur X.400-Kommunikation finden Sie unter MTA-Transportstacks und X.400-Connectors.
Exchange 5.5-Server in derselben Routinggruppe Für die Kommunikation mit Servern in der lokalen Routinggruppe, auf denen Exchange Server 5.5 ausgeführt wird, werden vom Exchange-MTA keine X.400-Connectorobjekte benötigt. Diese MTA-Typen werden auch als LAN-MTAs bezeichnet, um hervorzuheben, dass an der Kommunikation kein expliziter X.400-Connector beteiligt ist. LAN-MTAs verwenden Remoteprozeduraufrufe, um miteinander zu kommunizieren. Weitere Informationen zur Kommunikation zwischen Exchange Server 2003 und Exchange 5.5 finden Sie unter Exchange-MTA in einer Organisation im gemischten Modus.
Exchange-MTA-Konfigurationseinstellungen in Active DirectoryDer Exchange-MTA erhält seine Konfigurationseinstellungen aus der lokalen Registrierung sowie von einem MTA-Objekt in Active Directory. Das MTA-Verzeichnisobjekt befindet sich unter den einzelnen Exchange-Serverobjekten in der Konfigurationsverzeichnispartition. Im Folgenden finden Sie ein Beispiel für den DN eines MTA-Objekts auf einem Server mit der Bezeichnung SERVER01 in der Domäne tailspintoys.com: CN=Microsoft MTA,CN=SERVER01,CN=Servers,CN=First Administrative Group,CN=Administrative
Groups,CN=Tailspin Toys,CN=Microsoft.
356
Im Exchange-System-Manager unterscheidet sich der Speicherort des MTA-Konfigurationsobjekts geringfügig. Wie in der folgenden Abbildung dargestellt, finden Sie das MTA-Konfigurationsobjekt unter dem Serverobjekt im Container Protokolle. Der Objektname lautet X.400, obwohl eigentlich MTA- und nicht nur X.400-Einstellungen konfiguriert werden. Sie können das Konfigurationsobjekt X.400 zum Definieren des MTA-Namens und seines lokalen Kennworts verwenden. Außerdem können Sie das MTA-Datenbankverzeichnis angeben, in dem sich die Nachrichtenwarteschlange befindet. Auf der Registerkarte Standardwerte für die Nachrichtenübermittlung können Sie die allgemeinen Kommunikationsparameter konfigurieren, z. B. die Werte für wiederholte Verbindungsversuche, die der MTA für die Kommunikation mit LAN-MTAs verwendet. Beim Konfigurieren von X.400-Connectors können Sie diese Einstellungen außer Kraft setzen.
Das MTA-Konfigurationsobjekt im Exchange-System-Manager
MTA-Konfigurationsobjekte sind Instanzen der MTA-Objektklasse. Sie können diese Informationen z. B. in einem LDAP (Lightweight Directory Access Protocol)-Filter verwenden, um sämtliche Einstellungen aller MTAs einer Exchange-Organisation in eine Textdatei zu exportieren. Dieser Schritt wird anhand des folgenden LDAP LDFIDE-Befehls (Data Interchange Format Directory Exchange) veranschaulicht: ldifde -f c:\AllMTAs.ldf -s localhost -d "CN=First Organization,CN=Microsoft
Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com" -p subtree -r
"(objectClass=mTA)". Sie benötigen Leseberechtigungen für alle administrativen Gruppen in der Organisation.
In der folgenden Tabelle werden die wesentlichen Attribute des MTA-Verzeichnisobjekts mit ihrem jeweiligen Zweck aufgeführt.
357
Wichtige Attribute des MTA-Verzeichnisobjekts
Verzeichnisattribut Zweck
objectClass Identifiziert das Verzeichnisobjekt als MTA-Objekt.
cn Enthält den gemeinsamen Namen (CN – Common Name) des MTA.
transRetryMins Bestimmt die Zeitspanne zwischen den Übertragungswiederholungen in Minuten. Der Standardwert ist 5 Minuten.
transTimeoutMins Bestimmt die Dauer bis zur Zeitüberschreitung bei der Nachrichtenübertragung in Minuten. Der Standardwert ist 20 Minuten.
mTALocalDesig Gibt den X.400-Namen des lokalen MTA an. Dieser aus bis zu 32 Zeichen bestehende Name wird dazu zu verwendet, den lokalen Exchange-MTA gegenüber Remote-MTAs und LAN-MTAs zu identifizieren.
delivContLength Legt die maximale Größe von Nachrichten in KB fest, die über den MTA gesendet werden können.
diagnosticRegKey Gibt den Speicherort des Diagnoseregistrierungsschlüssels an. Wenn dieser Schlüssel nicht vorhanden ist, verwendet der MTA den folgenden Registrierungsschlüssel: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMTA\Diagnostics.
358
Verzeichnisattribut Zweck
expandDLsLocally Entspricht der Einstellung Remoteverteilerlisten lokal expandieren in den MTA-Eigenschaften. Wenn expandDLsLocally den Wert True (Wahr) aufweist und ein Benutzer eine Nachricht an eine Remoteverteilerliste sendet, erweitert der MTA die Verteilerliste lokal. Der Exchange-MTA ermittelt dann auf Grundlage des Standorts der Empfänger in der Liste die beste Route für die Nachricht. Durch dieses Verfahren wird die effizienteste Nachrichtenverarbeitung gewährleistet. Die Verarbeitung von umfangreichen Verteilerlisten kann jedoch die Serverleistung beeinträchtigen.
msExchHomeRoutingGroupDNBL Eine Rückverbindung zur Routinggruppe, deren Mitglied dieser MTA ist.
associationLifetime Legt die Zeitspanne in Sekunden fest, für die das System nach dem Senden einer Nachricht eine Zuordnung zu einem Remote-X.400-MTA aufrechterhält. Der Standardwert ist 300 Sekunden.
numOfOpenRetries Gibt die maximale Anzahl von Versuchen des Exchange-MTA zum Öffnen einer Verbindung an, bevor ein Unzustellbarkeitsbericht gesendet wird. Der Standardwert ist 144.
numOfTransferRetries Legt die maximale Anzahl von Versuchen fest, die einem Exchange-MTA zum Senden einer Nachricht über eine geöffnete Verbindung zur Verfügung stehen. Der Standardwert ist 2.
openRetryInterval Gibt die Wartezeit in Sekunden nach einem Fehler an, bevor das System versucht, eine Verbindung erneut zu öffnen. Der Standardwert ist 600 Sekunden.
359
Verzeichnisattribut Zweck
rTSCheckpointSize Legt die Datenmenge in KB fest, nach der ein Prüfpunkt eingefügt wird. Wenn ein Fehler auftritt und die Nachricht erneut gesendet werden muss, wird der Vorgang ab dem letzten Prüfpunkt neu gestartet. Der Wert 0 gibt an, dass keine Prüfpunkte eingefügt werden.
rTSRecoveryTimeout Gibt die Wartezeit nach einer Verbindungsunterbrechung an, bis ein MTA die Informationen (einschließlich der Prüfpunkte) löscht und die Übertragung von Anfang an neu startet.
rTSWindowSize Legt die Anzahl der Prüfpunkte fest, die nicht bestätigt werden müssen, bevor die Datenübertragung angehalten wird. Wenn für rTSCheckpointSize der Wert 0 angegeben wurde, hat der Wert für rTSWindowSize keine Bedeutung.
sessionDisconnectTimer Gibt die Wartezeit in Sekunden an, bis der Exchange-MTA eine Verbindung beendet, nachdem alle Zuordnungen über diese Verbindung beendet wurden.
tempAssocThreshold Legt die maximale Anzahl von Nachrichten in der Warteschlange fest, die das System an ein Remotesystem senden kann. Wenn dieser Wert überschritten wird, öffnet der MTA eine weitere Zuordnung.
transferRetryInterval Legt die Wartezeit in Sekunden nach dem Abbrechen einer Nachrichtenübertragung fest, bis die Nachricht erneut über eine geöffnete Verbindung gesendet wird. Der Standardwert ist 120 Sekunden.
transferTimeoutNonUrgent Gibt die Wartezeit in Sekunden pro KB an, bis vom System für eine nicht dringende Nachricht ein Unzustellbarkeitsbericht gesendet wird.
360
Verzeichnisattribut Zweck
transferTimeoutNormal Gibt die Wartezeit in Sekunden pro KB an, bis vom System für eine normale Nachricht ein Unzustellbarkeitsbericht gesendet wird.
transferTimeoutUrgent Gibt die Wartezeit in Sekunden pro KB an, bis vom System für eine dringende Nachricht ein Unzustellbarkeitsbericht gesendet wird.
msExchMTADatabasePath Gibt den Pfad zum MTA-Datenbankverzeichnis an.
msExchResponsibleMTAServerBL Enthält den DN des Servers, der als Host des MTA fungiert.
msExchEncryptedPassword Gibt das MTA-Kennwort an, das von Remote-MTAs beim Verbinden mit diesem MTA verwendet werden muss. Das Kennwort kann aus bis zu 64 Zeichen bestehen und wird in verschlüsselter Form in Active Directory gespeichert.
Hinweis: Das MTA-Kennwort wird in verschlüsselter Form in Active Directory gespeichert. Dies bedeutet jedoch nicht, dass MTA-Namen und Kennwörter sicher sind. X.400-MTAs tauschen ihre Namen und Kennwörter beim Herstellen von Verbindungen in Klartext aus.
Interne Exchange-MTA-ArchitekturDie interne Architektur des Exchange-MTA basiert auf Threadpools, Nachrichtenwarteschlangen und Datenbankwarteschlangen. Threads führen die eigentliche Verarbeitung innerhalb des Exchange-MTA-Prozesses (Emsmta.exe) aus. Nachrichtenwarteschlangen (in der folgenden Abbildung durch Pfeile hervorgehoben) sind für Interaktionen und Benachrichtigungen zwischen Threads zuständig. Datenbankwarteschlangen enthalten Nachrichten, die auf die Verarbeitung durch einen der Threadpools warten. Beispielsweise handelt es sich bei der in der folgenden Abbildung dargestellten Arbeitswarteschlange um eine Datenbankwarteschlange, in der Nachrichten
361
aufbewahrt werden, bis der MTA sie erfolgreich übertragen hat oder bis sie abgelaufen sind und mit einem Unzustellbarkeitsbericht an den Sender zurückgeschickt werden. Das Ausführen mehrerer Threads ermöglicht es dem Exchange-MTA, mehrere Aufgaben gleichzeitig auszuführen. In dieser Abbildung wird die interne Architektur des Exchange-MTA dargestellt.
Interne Exchange-MTA-Architektur
Die interne Exchange-MTA-Architektur basiert auf folgenden Elementen:
XFER IN- und XFER OUT-Threads Diese Threads sind für die eigentliche Nachrichtenübertragung in den und aus dem MTA-Prozess zuständig. Diese Kommunikation erfolgt über folgende Mechanismen:
X.400 Kommunikation mit einem Remote-X.400-MTA oder einem Exchange-Server in einer Remoteroutinggruppe mithilfe eines X.400-Connectors.
RPCs Kommunikation mit einem LAN-MTA (d. h. ein Server in der lokalen Routinggruppe, auf dem Exchange Server 5.5 ausgeführt wird).
XAPI Kommunikation mit dem Exchange-Informationsspeicher per MAPI.
Sie können die Anzahl der Übertragungsthreads mithilfe des folgenden Registrierungsparameters steuern:
Speicherort HKEY_LOCAL_MACHINE\System\
CurrentControlSet\Services\
MSExchangeMTA\Parameters
Wert Transfer threads
362
Typ REG_DWORD
Wert 0x1
Beschreibung Legt die Anzahl der MTA-Übertragungsthreads fest. Dieser Wert wird für die zwei Untertypen von Übertragungsthreads (XFER IN und XFER OUT) mit zwei multipliziert.
Der Standardwert ist 0x1. Wenn dieser MTA mit mehreren Remote-MTAs kommuniziert, sei es innerhalb einer Routinggruppe oder zwischen Routinggruppen, lautet der empfohlene Wert 0x3.
Arbeitswarteschlange Der Exchange-MTA schreibt alle Nachrichten in DAT-Dateien im MTA-Datenbankverzeichnis des Dateisystems. Anschließend wird für jede DAT-Datei in der Arbeitswarteschlange ein Zeiger erstellt. Die Arbeitswarteschlange verwaltet Verweise auf alle Nachrichten, für die der MTA zuständig ist. Die MTA-Datenbank und DAT-Dateien werden weiter unten in diesem Abschnitt behandelt.
Verteiler Der Verteiler stellt den Kern des MTA-Prozesses dar und ist für das Nachrichtenrouting und die Verarbeitung von Ergebnissen verantwortlich. Der Verteiler verwendet für die Nachrichtenverarbeitung Router-, Auffächerungs- und Ergebnisthreads. Der Verteiler führt folgende Schlüsselaufgaben aus:
Nachrichtenrouting, Auffächerung und Übertragung Der Verteiler verwendet einen Routingthread, um mit dem Routingmodul zu kommunizieren und den nächsten Hop für die Nachrichtenübertragung zu ermitteln. Wenn eine Nachricht an Empfänger in unterschiedlichen Zielen adressiert wird, die über separate Verbindungen (wie zwei X.400-Connectors auf demselben Server) erreicht werden, verwendet der Verteiler einen Auffächerungsthread. Der Auffächerungsthread erstellt mehrere Nachrichtenkopien und reiht sie in die entsprechenden Verbindungswarteschlangen ein. Der Verteiler löst dann XFER OUT-Threads aus, um die Auffächerungsnachrichtenkopien zu verarbeiten.
Hinweis: Der Vorgang des Erstellens mehrerer Nachrichtenkopien im MTA wird als Auffächerung bezeichnet. Dies unterscheidet sich vom Begriff Gabelung, mit dem das Erstellen mehrerer Nachrichtenkopien im Kategorisierungsmodul des SMTP-Transportsubsystems bezeichnet wird. Ausführliche Informationen zum Kategorisierungsmodul finden Sie unter SMTP-Transportarchitektur.
Verarbeiten von Ergebnissen Basierend auf den Ergebnissen von Routing-, Auffächerungs- und Übertragungsvorgängen erstellt der Verteiler auch Berichte.
363
Wenn z. B. eine Nachricht erfolgreich über einen X.400-Connector übertragen wurde, aktualisiert der Verteiler die Verantwortungsbereichsflags für die Nachrichtenempfänger in der Arbeitswarteschlange, um den Übertragungserfolg anzuzeigen.
Für jede Nachricht in der Arbeitswarteschlange gibt es ein Bitmuster, das aus einem Bit pro Empfänger besteht. Am Anfang werden die Bits für alle Empfänger auf 1 gesetzt, um anzuzeigen, dass die Nachricht noch nicht übertragen wurde. Nachdem die Auffächerungskopie einer Nachricht von einem XFER OUT-Thread erfolgreich übertragen wurde, löscht der Verteiler das Bit des entsprechenden Empfängers dieser Auffächerungskopie. Der MTA entfernt die Nachricht aus der Arbeitswarteschlange, wenn die Nachricht erfolgreich an die Empfänger übertragen wurde oder wenn die Nachricht abgelaufen ist. Zu diesem Zeitpunkt erstellt der MTA einen Unzustellbarkeitsbericht für jeden Empfänger, dem die Nachricht nicht zugestellt werden konnte.
Sie können die Anzahl der Verteilerthreads mithilfe des folgenden Registrierungsparameters steuern:
Speicherort HKEY_LOCAL_MACHINE\System\
CurrentControlSet\Services\
MSExchangeMTA\Parameters
Wert Dispatcher threads
Typ REG_DWORD
Wert 0x1
Beschreibung Legt die Anzahl der MTA-Verteilerthreads fest, die für die Nachrichtenverarbeitung zuständig sind. Dieser Wert wird für die drei Untertypen für Verteilerthreads (Router-, Auffächerungs-, Ergebnisthreads) mit drei multipliziert.
Der Standardwert ist 0x1. Wenn der MTA mit mehr als fünf LAN-MTAs kommuniziert, lautet der empfohlene Wert 0x3.
Übermittlungs- und Zustellthreads Diese Threadpools stammen noch aus Exchange Server 5.5. Sie werden in Exchange 2000 Server und Exchange Server 2003 i. d. R. nicht verwendet, da in Exchange Server 2000 und Exchange Server 2003 keine direkte Übermittlung und Zustellung durchgeführt wird. Alle Nachrichten müssen den SMTP-Dienst durchlaufen. Wie unter SMTP-Transportarchitektur erläutert, überträgt der SMTP-
364
Dienst Nachrichten über den Treiber für Exchange-Informationsspeicher an lokale Empfänger.
Der Exchange-MTA behandelt den SMTP-Dienst ähnlich wie einen MAPI-basierten Connector mit Nachrichtenwarteschlangen im Exchange-Informationsspeicher. XAPI-Gateways sind für die Nachrichtenübertragung von und zu den Nachrichtenwarteschlangen im Exchange-Informationsspeicher zuständig. Bei XAPI-Gateways handelt es sich um Threads im Exchange-Informationsspeicher, die mit den XFER IN- und XFER OUT-MTA-Threads interagieren.
Der Exchange-MTA verwendet für die Kommunikation zwischen Prozessen sowie zum Ausführen von Systemfunktionen wie dem Aktualisieren von Konfigurationsinformationen bei Änderungen die folgenden Threads:
OSI-Stack Der Exchange-MTA verwendet mehrere Threadpools für die Kommunikation zwischen den verschiedenen Schichten des OSI-Stacks (Open System Interconnection). Diese Threadpools umfassen RTS-Threads (Reliable Transfer Service), Kernelthreads, RPC-Threads, Transportthreads und TCP/IP- bzw. X.25-Threads. Weitere Informationen zur Funktion dieser Threads finden Sie unter MTA-Transportstacks und X.400-Connectors.
Zeitgeber Der Exchange-MTA führt Zeitgeberthreads in verschiedenen Situationen aus, z. B für den Wartevorgang nach dem Abbrechen einer Nachrichtenübertragung, bevor eine Nachricht erneut über eine geöffnete Verbindung gesendet wird.
Verzeichnisabfrage Der Exchange-MTA verwendet einen separaten Thread, um Active Directory alle zehn Minuten nach Konfigurationsänderungen abzufragen.
Threads, die nicht dem MTA gehören Das Routingmodul und das DSAccess-Modul besitzen Threads, die im MTA-Prozess ausgeführt werden, um den Exchange-MTA über auftretende Änderungen zu informieren. Das Routingmodul ruft z. B. bei Änderungen an der Routingtopologie die Funktion RoutingReset() des MTA auf, damit eine Nachrichtenumleitung für alle Nachrichten in der Warteschlange ausgelöst wird. DSAccess kommuniziert mit dem Exchange-MTA, um zwischengespeicherte Verzeichnisinformationen zur Verfügung zu stellen.
Exchange-MTA-DatenbankDer Exchange-MTA verwaltet alle übertragenen Nachrichten in der MTA-Datenbank. Wie in der folgenden Abbildung dargestellt, handelt es sich bei der MTA-Datenbank um eine aus DAT-Dateien bestehende Flatfile-Datenbank. Es sind separate DAT-Dateien für Datenbankwarteschlangen und die eigentlichen Nachrichten vorhanden. Datenbankwarteschlangen enthalten zwar Verweise oder Zeiger auf die Nachrichten, jedoch nicht die Nachrichten selbst. Der MTA speichert jede Nachricht in einer separaten DAT-Nachrichtendatei im MTA-Datenbankverzeichnis. In einer aktiven Datenbank befindet sich eine DBREFS-Datei, die die Anzahl der Verweise für Objekte enthält. Mit dieser Datei stehen
365
tertiäre Sicherungsinformationen zur Verfügung. Die DBREFS-Datei wird nach dem Neustart des MTA oder nach dem Ausführen des Tools MTACheck neu erstellt.
Es ist schwierig, in einer aktiven MTA-Datenbank zwischen den verschiedenen DAT-Dateien zu unterscheiden. Das Exchange 2000 Server Resource Kit (in Buchhandlungen erhältlich) enthält das Tool MTAView. Mithilfe von MTAView können Sie den Inhalt der MTA-Warteschlangen und der Nachrichtenheader in diesen Warteschlangen anzeigen. In der folgenden Abbildung wird das Tool MTAView mit einer geöffneten MTA-Datenbank dargestellt. Das Fenster im Vordergrund zeigt die DAT-Dateien im Verzeichnis der MTA-Nachrichtenwarteschlange.
Nachrichtenwarteschlangen und DAT-Dateien des Exchange-MTA
Die MTA-DAT-Dateien werden in zwei Kategorien unterteilt:
366
DAT-Kerndateien Die DAT-Kerndateien fungieren als Referenzreihen und -spalten der MTA-Datenbank. Im Nachrichtenwarteschlangenverzeichnis (\Programme\Exchsrvr\Mtadata) gibt es 38 DAT-Kerndateien, die alle zum Ausführen des Exchange-MTA benötigt werden. Die meisten DAT-Kerndateien sind im Lieferumfang von Exchange Server 2003 enthalten. Sie finden diese Dateien auf der Produkt-CD im Verzeichnis \Setup\i386\Exchange\Bootenv. Das Exchange Server 2003-Installationsprogramm kopiert diese Dateien während der Installation in das Verzeichnis \Programme\Exchsrvr\Mtdata. Die mit Exchange Server 2003 gelieferten DAT-Kerndateien sind hexadezimal von DB000001.dat bis DB000026.dat nummeriert.
Der Exchange-MTA erstellt dynamisch weitere DAT-Dateien für wichtige Datenbankwarteschlangen. Beispielsweise erstellt der MTA bei jedem Neustart die MTA-Arbeitswarteschlange neu. Während dieses Vorgangs werden keine Nachrichten übermittelt, da der MTA zunächst alle DAT-Dateien auswerten muss. Anschließend startet die Nachrichtenübertragung.
Zu den wichtigsten DAT-Kerndateien in einer aktiven MTA-Datenbank zählen die folgenden:
DB00001.dat Hierbei handelt es sich um die wichtigste Datenbankwarteschlange, die so genannte Masterwarteschlange. Die Masterwarteschlange enthält eine Liste von Warteschlangenobjekt-IDs und Verweise auf andere Warteschlangen mit eigenen DAT-Dateien.
DB000020.dat Hierbei handelt es sich um die XAPI-Arbeitswarteschlange, in der Verweise auf für den SMTP-Dienst oder für MAPI-basierte Gatewayconnectors bestimmte Nachrichten verwaltet werden. Dazu gehören z. B. Connector für Lotus Notes und Connector für Novell GroupWise, die über eigene Nachrichtenwarteschlangen im Exchange-Informationsspeicher verfügen.
DB000025.dat Hierbei handelt es sich um die Warteschlange für Abwesenheitsnachrichten, die Objekte für Abwesenheitsbenachrichtigungen enthält.
DB000026.dat Hierbei handelt es sich um die Verweisdatenwarteschlange. Aus Redundanzgründen wird in den DAT-Warteschlangendateien mehrmals auf die DAT-Dateien verwiesen.
DB000027.dat Hierbei handelt es sich um die MTA-Arbeitswarteschlange, die eine Liste von Nachrichten enthält, die auf die Übertragung warten.
DAT-Nachrichten- und -Platzhalterdateien Bei den übrigen DAT-Dateien im Datenbankverzeichnis handelt es sich um Nachrichten- und Platzhalterdateien. Der MTA erstellt für jede zu übertragende Nachricht eine DAT-Nachrichtendatei. Da der numerische Teil des Dateinamens (DB######.dat) nach dem Zufallsprinzip zugewiesen wird, sind doppelte Dateinamen möglich. Um das Überschreiben vorhandener Dateien zu vermeiden, erstellt der Exchange-MTA zusammen mit jeder DAT-Nachrichtendatei eine DAT-Platzhalterdatei. Die DAT-Platzhalterdatei ist nur ein Byte groß und wird verwendet, wenn eine DAT-Nachrichtendatei wegen eines doppelten Dateinamens nicht erstellt
367
werden kann. Die oben stehende Abbildung enthält eine DAT-Nachrichtendatei von 2 MB (DB00002D.dat) und eine DAT-Platzhalterdatei von 0 KB (DB00002E.dat). Der MTA erstellt für jede Nachricht zwei DAT-Dateien.
Nach der Übertragung einer Nachricht löscht der Exchange-MTA die Daten aus den DAT-Dateien und setzt die Dateien auf die Größe von 1 Byte zurück (statt die DAT-Dateien zu löschen). Der Exchange-MTA kann dann die DAT-Dateien für zukünftige Nachrichten wiederverwenden. Dieser Mechanismus trägt zur Leistungssteigerung des MTA bei, da das Erstellen und Löschen von Dateien wertvolle Zeit in Anspruch nimmt. Die Anzahl der DAT-Dateien im Verzeichnis der Nachrichtenwarteschlange gibt die maximale Anzahl von Nachrichten an, die sich gleichzeitig in der Warteschlange befinden können. Auf einem ausgelasteten Bridgeheadserver unter Exchange Server 2003 befinden sich im MTA-Datenbankverzeichnis u. U. Hunderte von DAT-Dateien.
Ändern des Speicherorts für das MTA-DatenbankverzeichnisMit dem Exchange-System-Manager können Sie das MTA-Datenbankverzeichnis einem anderen Speicherort im Dateisystem zuordnen. (Klicken Sie im Container Protokolle des Servers mit der rechten Maustaste auf das Konfigurationsobjekt X.400, klicken Sie auf Eigenschaften und dann auf der Registerkarte Allgemein unter Verzeichnis für Nachrichtenwarteschlange auf Ändern). Wenn Sie den Speicherort des Warteschlangenverzeichnisses im Exchange-System-Manager ändern, werden die Datenbankdateien an den neuen Speicherort verschoben und das msExchMTADatabasePath-Attribut des MTA-Verzeichnisobjekts so geändert, dass es auf den neuen Speicherort verweist. Das msExchMTADatabasePath-Attribut dient jedoch nur zu Informationszwecken. Viel wichtiger ist der folgende Registrierungsschlüssel, den der Exchange-System-Manager ebenfalls aktualisiert.
Speicherort HKEY_LOCAL_MACHINE\System\
CurrentControlSet\Services\
MSExchangeMTA\Parameters
Wert MTA database path
Typ REG_SZ
Wert C:\Program Files\Exchsrvr\Mtadata
368
Beschreibung Verweist auf den Ort der Datenbankdateien (Warteschlangendateien und Nachrichtendateien) für den Exchange-MTA. Wenn dieser Pfad ungültig ist oder auf ein leeres Verzeichnis verweist, kann der MTA nicht gestartet werden.
Sie sollten das MTA-Datenbankverzeichnis nicht auf einer FAT-Partition platzieren. FAT16-Partitionen unterstützen maximal 65535 Dateien. Diese Beschränkung kann auf einem ausgelasteten Bridgeheadserver problematisch werden. Beim Füllen der Warteschlange werden verfügbare Einträge zum Erstellen neuer Dateien u. U. innerhalb eines einzigen Tages ausgeschöpft. Da für jede Nachricht zwei DAT-Dateien benötigt werden, wird das Problem weiter verschärft. Außerdem ist die Leistung von FAT-Partitionen bei großen Datenträgern gering. Es besteht nur eine geringe Fehlertoleranz, und eine Wiederherstellungsfunktion bei unerwarteten Systemzusammenbrüchen ist nicht verfügbar.
Auf einem ausgelasteten X.400-Bridgeheadserver unter Exchange Server 2003 können Sie die Leistung steigern, indem Sie das MTA-Datenbankverzeichnis auf einem hochleistungsfähigen Laufwerksubsystem (z. B. ein RAID-System) einrichten. Ein RAID 0+1 mit 8 bis 10 Festplatten stellt einen guten Ausgangspunkt bei der Übertragung sehr umfangreicher Nachrichten dar. Ein RAID-Controller mit einem Zwischenspeicher von mehr als 64 MB trägt ebenfalls zur Leistungssteigerung bei.
Hinweis: Unter dem Registrierungsschlüssel MTA database path befindet sich der Registrierungsschlüssel MTA Run Directory. Dieser Registrierungsschlüssel verweist auf das Verzeichnis, in dem sich die Ausführungsdateien des Exchange-MTA befinden. Es empfiehlt sich, für das Datenbank- und das Ausführungsverzeichnis unterschiedliche Laufwerke zu verwenden.
Gesicherte und ungesicherte NachrichtenkopienNachrichten in der MTA-Arbeitswarteschlange werden als gesicherte Nachrichten bezeichnet, da sie stets in DAT-Dateien gespeichert werden. Diese DAT-Dateien sind auch dann noch verfügbar, wenn der Exchange-MTA-Prozess unerwartet beendet wird. Der Verteiler verwendet gesicherte Nachrichten in der Arbeitswarteschlange als Quelldateien und erstellt ungesicherte Nachrichtenkopien. Der Verteiler fügt dann die zum Übertragen der Nachrichten geeigneten Verbindungswarteschlangen für Connectors oder die Verbindungen für den nächsten Hop an. Wenn eine Nachricht für mehrere Ziele bestimmt ist, die über separate Verbindungen erreicht werden, erstellt der Verteiler für jede Verbindung eine Auffächerungskopie. Jede Auffächerungskopie verweist auf die gesicherte Nachricht in der
369
MTA-Arbeitswarteschlange. Der MTA entfernt gesicherte und ungesicherte Nachrichtenkopien aus den Warteschlangen, nachdem die Nachricht erfolgreich übertragen wurde.
Nachrichten in Verbindungswarteschlangen sind Verweiszeiger auf Nachrichtenobjekte und nicht die eigentlichen Objekte. Gesicherte Nachrichten sind in DAT-Dateien verfügbar. Dies trifft jedoch nicht notwendigerweise auch für ungesicherte Kopien zu. Ungesicherte Kopien werden zum Steigern der MTA-Leistung hauptsächlich im Arbeitsspeicher aufbewahrt. Der Verteiler speichert ungesicherte Kopien nur dann in DAT-Dateien, wenn im Arbeitsspeicher nicht genug Zwischenspeicherplatz zum Speichern der Objekte vorhanden ist. Der Zwischenspeicher ist ein fester Pool aus Pufferbereichen von je 4 KB objektspezifischen Strukturen, dessen Gesamtgröße sich an der Threadpoolgröße orientiert. Sie können die Anzahl von Datenpuffern pro Objekt im Arbeitsspeicher mit dem folgenden Registrierungsparameter anpassen.
Speicherort HKEY_LOCAL_MACHINE\System\
CurrentControlSet\Services\
MSExchangeMTA\Parameters
Wert DB data buffers per object
Typ REG_DWORD
Wert 0x3
Beschreibung Gibt die Anzahl der für jedes Datenbankobjekt konfigurierten Datenbankserverpuffer an. Bei mehr Puffern wird mehr Arbeitsspeicher verbraucht, es ist jedoch auch weniger wahrscheinlich, dass ein Datenbankobjekt aufgrund zu geringen Pufferspeichers auf die Festplatte ausgelagert wird.
Der Standardwert ist 0x3. Wenn dieser MTA mit mehreren Remote-MTAs kommuniziert, sei es innerhalb einer Routinggruppe oder zwischen Routinggruppen, lautet der empfohlene Wert 0x3. Sie sollten diese Einstellung weiter anpassen, wenn auf diesem Server ein MAPI-basierter Connector installiert ist.
370
MTA-Datenbank in einem ServerclusterEs ist nicht möglich, die MTA-Datenbanken und DAT-Dateien so zu unterteilen, dass die MTA-Datenbank gleichzeitig von mehreren MTA-Instanzen verwendet werden kann. Dies ist jedoch z. B. erforderlich, wenn ein MTA mithilfe des Microsoft Windows Server™ 2003-Clusterdiensts auf mehreren Clusterknoten in einem Servercluster ausgeführt werden soll. Da nur ein MTA als Eigentümer der MTA-Datenbank möglich ist, kann der Exchange-MTA nur auf dem ersten initialisierten Knoten im Cluster ausgeführt werden. Bei einem Failover beendet der Clusterdienst den MTA auf dem ausgefallenen Knoten und startet ihn auf einem anderen Knoten. Der MTA wird dann mithilfe derselben DAT-Dateien wiederhergestellt, und Verbindungen werden erneut aufbaut.
Beschädigte Nachrichten in GatewaywarteschlangenExchange Server 2003 überträgt Nachrichten, die für MAPI-basierte Connectors bestimmt sind, über den Exchange-Informationsspeicher an den MTA. Nachrichten werden vom MTA über den Exchange-Informationsspeicher zurück zum Connector-Postfach gesendet. In der Standardeinstellung gibt es nur zwei Threads (jeweils einer für die eingehenden und für die ausgehenden Übertragungen), die mit dem MTA kommunizieren. Daher kann eine beschädigte Nachricht an der Spitze einer Gateway-Verbindungswarteschlange im MTA den gesamten Nachrichtenfluss von und zum Exchange-Informationsspeicher blockieren. Zum Beseitigen der Blockierung können Sie die betroffenen Nachrichten im Exchange-System-Manager mit dem Warteschlangenanzeige-Snap-In löschen.
Hinweis: Sie sollten DAT-Dateien nicht direkt im MTA-Datenbankverzeichnis löschen, da das versehentliche Löschen einer DAT-Kerndatei zur Beschädigung der gesamten Datenbank führen kann.
Mithilfe der folgenden Registrierungsparameter können Sie auch die Anzahl der ein- und ausgehenden Gatewaythreads im Exchange-Informationsspeicherprozess für jeden Postfachspeicher steigern. Wenn der Exchange-Informationsspeicher mit dem Exchange-MTA über mehrere Threads kommuniziert, wird ein Thread u. U. durch eine beschädigte Nachricht blockiert, doch andere Threads können nach wie vor weitere Nachrichten verarbeiten. Wenn durch mehrere beschädigte Nachrichten alle Gateways blockiert sind, ist das möglicherweise ein Hinweis auf ein schwerwiegendes Problem (z. B. ein fehlerhafter Festplattencontroller).
Speicherort HKEY_LOCAL_MACHINE\System\
CurrentControlSet\Services \MSExchangeIS\
<Servername>\Private-<Datenbank-GUID>
371
Wert Gateway In Threads Gateway Out Threads
Typ REG_DWORD
Wert 0x1
Beschreibung Der Standardwert für beide Parameter ist 0x1. Wenn dieser MTA mit mehreren LAN-MTAs kommuniziert oder für MAPI-basierte Nachrichtenconnectors zuständig ist, lautet der empfohlene Wert 0x3.
Sie müssen diese Parameter allen Schlüsseln für Postfachspeicher in der Registrierung hinzufügen. Jeder eingehende und ausgehende Gatewaythread benötigt ca. 1 MB des virtuellen Speichers. Dies kann bei Servern mit vielen privaten Datenbanken ein Problem darstellen. Wenn beispielsweise 10 private Datenbanken vorhanden sind und diese Parameter von 0x1 auf 0x3 erhöht werden (eine Erhöhung um insgesamt 4 Threads), werden 4 x 10 = 40 Threads erstellt. Dadurch werden 40 MB an virtuellem Speicher beansprucht.
Reparieren beschädigter MTA-DatenbankenWenn durch das Löschen einer beschädigten Nachricht aus einer Nachrichtenwarteschlange nicht alle Probleme im Zusammenhang mit MTA-Warteschlangen behoben werden, können Sie mit dem Tool MTACheck (Mtacheck.exe) Probleme in der MTA-Datenbank analysieren und korrigieren. Führen Sie MTACheck aus, wenn Sie eine Beschädigung der MTA-Datenbank vermuten oder das Ereignisprotokoll Fehlereinträge enthält. Das Tool MTACheck muss direkt auf dem Server ausgeführt werden. Hierzu müssen Sie den Dienst Microsoft Exchange MTA-Stacks beenden. Das Tool MTACheck überprüft die Zeiger in den Datenbankwarteschlangen und stellt sicher, dass die in den Warteschlangendateien angegebenen DAT-Dateien wirklich vorhanden sind. Das Tool entfernt beschädigte Nachrichten (d. h. Nachrichten mit inkonsistenten Zeigern). Beschädigte Nachrichten werden in das Verzeichnis \Programme\Exchsrvr\Mtadata\Mtacheck.out verschoben. Sie können zum Löschen von Replikationsnachrichten für Öffentliche Ordner und andere Systemnachrichten auch Befehlszeilenoptionen verwenden, doch müssen Sie dabei vorsichtig vorgehen. Weitere Informationen finden Sie in der Dokumentation zum Tool MTACheck. Das Tool MTACheck mit der zugehörigen Dokumentation erhalten Sie auf der Downloads for Exchange Server 2003 -Website.
372
Leeren der MTA-DatenbankAuf einem ausgelasteten Bridgeheadserver mit mehreren X.400- oder MAPI-basierten Connectors kann das MTA-Datenbankverzeichnis mehr als 10000 DAT-Dateien enthalten. Dieses Problem wird noch verschärft, wenn aufgrund von beschädigten Nachrichten oder Netzwerkproblemen Übertragungsprobleme auftreten. Der physische Grenzwert für die Anzahl von DAT-Dateien, die auf einer Festplatte erstellt werden können, wird vom verfügbaren Speicherplatz bestimmt. Der Dienst Microsoft Exchange MTA-Stacks wird heruntergefahren, wenn auf der Festplatte mit der MTA-Datenbank weniger als 10 MB Speicherplatz verfügbar sind.
Stellen Sie vor dem Neustart des Diensts Microsoft Exchange MTA-Stacks sicher, dass mehr als 10 MB Speicherplatz zur Verfügung stehen. Hierfür ist u. U. das vorübergehende Verschieben aller DAT-Dateien aus dem MTA-Datenbankverzeichnis in ein anderes Verzeichnis oder eine Netzwerkfreigabe erforderlich. Der Vorgang des Verschiebens von Dateien mit dem Ziel eines leeren Datenbankverzeichnisses wird als MTA-Leerung bezeichnet. Eine MTA-Leerung empfiehlt sich beim Beheben von Problemen mit der MTA-Datenbank (z. B. zahlreiche beschädigte Nachrichten, die die Datenbankwarteschlangen blockieren).
Ausführliche Informationen zum Leeren der MTA-Metabasis finden Sie unter Leeren der MTA-Datenbank.
Vorsicht: Wenn Sie eine MTA-Datenbank leeren müssen, wenden Sie sich an den Microsoft-Produktsupport, um sicherzustellen, dass die Schritte ordnungsgemäß durchgeführt werden. Wenn Sie die Schritte unsachgemäß ausführen, gehen aktuell in der MTA-Nachrichtenwarteschlange gespeicherte E-Mail-Nachrichten u. U. verloren.
Wiedergeben von DAT-DateienZum Senden von Nachrichten, die sich zum Zeitpunkt der MTA-Datenbankleerung in der MTA-Datenbank befanden, müssen Sie die DAT-Dateien wiedergeben. Sie können diesen Vorgang auf drei verschiedene Arten durchführen:
Vollständige Wiedergabe Am einfachsten können Sie die DAT-Dateien wiedergeben, indem Sie sie alle gleichzeitig auf dem Server wiedergeben, auf dem sie sich ursprünglich befanden. Hierfür sollten die MTA-Warteschlangen auf dem ursprünglichen Exchange-Server leer sein. Wenn sich in den MTA-Warteschlangen Nachrichten befinden, warten Sie, bis der MTA diese Nachrichten gesendet hat und alle Warteschlangen leer sind.
Remotewiedergabe Die DAT-Dateien müssen nicht auf dem Exchange-Server wiedergegeben werden, auf dem sie sich ursprünglich befanden. Handelt es sich bei dem ursprünglichen Exchange-Server z. B. um einen ausgelasteten Bridgeheadserver, der
373
kontinuierlich große Mengen an E-Mail-Nachrichten überträgt und dessen MTA-Warteschlangen nie leer werden, können Sie die Nachrichten auf einem anderen Server wiedergeben, auf dem Exchange Server ausgeführt wird.
Inkrementelle Wiedergabe Eine inkrementelle Wiedergabe erfolgt durch Aufteilen der DAT-Dateien in mehrere kleine Gruppen, die nacheinander wiedergegeben werden. Dieses Verfahren ist komplexer als eine vollständige Wiedergabe oder eine Remotewiedergabe. Es kann sich jedoch beim Umgang mit einer großen Anzahl von DAT-Dateien als hilfreich erweisen. Eine inkrementelle Wiedergabe empfiehlt sich möglicherweise auch, wenn wichtige Nachrichten zugestellt werden müssen, der MTA jedoch durch eine beschädigte Nachricht in einer Warteschlange unerwartet beendet wird. Sie können eine inkrementelle Wiedergabe auf dem ursprünglichen Exchange-Server oder auf einem anderen Exchange-Server in der Organisation ausführen.
Detaillierte Anweisungen zum Ausführen dieser Verfahren finden Sie unter Wiedergeben von DAT-Dateien nach einer MTA-Datenbankleerung.
Überprüfen der Exchange-MTA-VerarbeitungZum Überwachen des MTA werden hauptsächlich die Tools Systemmonitor und Ereignisanzeige verwendet. Mit dem Systemmonitor können Sie das Verhalten von Nachrichtenconnectors in Echtzeit überwachen. Sie können die Anzahl der in eingehenden und ausgehenden Nachrichtenwarteschlangen wartenden Nachrichten ermitteln. Sie können die Gesamtzahl der Nachrichten ermitteln, die von einem Connector seit dem Start des MTA übertragen wurden. Es empfiehlt sich, die Nachrichtenwarteschlangen mithilfe des Systemmonitors zu überprüfen, da zahlreiche Nachrichten in einem Nachrichtenconnector auf einen Leistungsengpass oder auf eine fehlerhafte Connectorkomponente hinweisen. Mithilfe der Ereignisanzeige können Sie die Quelle von Systemproblemen diagnostizieren oder potenzielle Probleme erkennen. Der Exchange-MTA schreibt schwerwiegende Ereignisse in das Anwendungsereignisprotokoll. Als Ereignis wird ein Vorgang im Exchange-MTA bezeichnet, der u. U. die Aufmerksamkeit des Administrators erfordert.
Überprüfen des Exchange-MTA mithilfe des SystemmonitorsMit dem Leistungsmonitor können einzelne Systemkomponenten untersucht werden. In Windows repräsentiert ein Objekt einen einzelnen Prozess, einen Teil des gemeinsam verwendeten Speichers oder ein physisches Gerät. Einem Objekt können mehrere Leistungsindikatoren zugeordnet sein. Das Objekt MSExchangeMTA verfügt über zahlreiche Leistungsindikatoren, u. a. den Indikator Länge der Arbeitswarteschlange, mit dem die Anzahl der Nachrichten in der MTA-Arbeitswarteschlange angegeben wird.
Wenn Sie dem Systemmonitor einen Leistungsindikator hinzufügen möchten, starten Sie das Tool Systemmonitor, und klicken Sie auf der Symbolleiste auf Hinzufügen (das Pluszeichen
374
(+)). Sie können dann im Dialogfeld Leistungsindikatoren hinzufügen in der Dropdownliste Leistungsobjekt das Objekt MSExchangeMTA auswählen. In der Liste Leistungsindikatoren wählen werden die zutreffenden Leistungsindikatoren aufgeführt.
In der folgenden Tabelle werden die für das Leistungsobjekt MSExchangeMTA verfügbaren Leistungsindikatoren aufgelistet.
Leistungsindikatoren für MSExchangeMTA
Leistungsindikator Beschreibung
Benachbarte MTA-Verknüpfungen Die Anzahl offener Zuordnungen dieses MTA zu anderen MTAs.
Nachrichten/Sek. Die Verarbeitungsrate der Nachrichten.
Nachrichten Bytes/Sek. Die Verarbeitungsrate der Nachrichten in Bytes/s.
Freie Elemente Die Anzahl freier Pufferelemente im MTA-Pool.
Freie Kopfzeilen Die Anzahl freier Pufferkopfzeilen im MTA-Pool.
Admin-Verbindungen Die Anzahl der mit dem MTA verbundenen MS Exchange-Administrationsprogramme.
Threads in Verwendung Die Anzahl der vom MTA verwendeten Threads. Mit diesem Wert kann ermittelt werden, ob zusätzliche Prozessoren von Vorteil wären.
Länge der Arbeitswarteschlange Die Anzahl der noch nicht übermittelten Nachrichten in der Arbeitswarteschlange. Dieser Wert gibt die Anzahl der vom MTA noch nicht vollständig verarbeiteten Nachrichten an.
XAPI-Gateways Die Anzahl der XAPI-Gateways, die über die XAPI-Schnittstelle mit dem MTA verbunden sind. Für ein einzelnes Gateway können mehrere XAPI-Gatewaysitzungen bestehen.
XAPI-Clients Die Anzahl der XAPI-Clients, die über die XAPI-Schnittstelle mit dem MTA verbunden sind. Für einen einzelnen Client können mehrere XAPI-Clientsitzungen bestehen.
375
Leistungsindikator Beschreibung
Dateilöschoperationen/Sek. Die Anzahl der Dateilöschvorgänge pro Sekunde.
Dateisynchronisationen/Sek. Die Anzahl der Dateisynchronisationen pro Sekunde.
Dateiöffnungen/Sek. Die Anzahl der Dateiöffnungen pro Sekunde.
Dateileseoperationen/Sek. Die Anzahl der Dateilesevorgänge pro Sekunde.
Dateischreiboperationen/Sek. Die Anzahl der Dateischreibvorgänge pro Sekunde.
ExDS-Leseaufrufe/Sek. Die Anzahl der Leseaufrufe für den Verzeichnisdienst.
Empfangene XAPI-Bytes/Sek. Die Anzahl der Bytes, die pro Sekunde über eine XAPI-Verbindung empfangen werden.
Übertragene XAPI-Bytes/Sek. Die Anzahl der Bytes, die pro Sekunde über eine XAPI-Verbindung übertragen werden.
Empfangene Bytes Admin-Schnittstelle/Sek. Die Anzahl der Bytes, die pro Sekunde über eine Admin-Verbindung empfangen werden.
Übertragene Bytes Admin-Schnittstelle/Sek. Die Anzahl der Bytes, die pro Sekunde über eine Admin-Verbindung übertragen werden.
Übertragene Bytes LAN/Sek. Die Anzahl der Bytes, die pro Sekunde über ein LAN an MTAs übertragen werden.
Empfangene Bytes LAN/Sek. Die Anzahl der Bytes, die pro Sekunde über ein LAN von MTAs empfangen werden.
Empfangene Bytes RAS/Sek. Die Anzahl der Bytes, die pro Sekunde über eine RAS-Verbindung empfangen werden. RAS-basierte X.400-Connectors stehen in Exchange Server 2003 nicht zur Verfügung.
Übertragene Bytes RAS/Sek. Die Anzahl der Bytes, die pro Sekunde über eine RAS-Verbindung übertragen werden. RAS-basierte X.400-Connectors stehen in Exchange Server 2003 nicht zur Verfügung.
Empfangene Bytes TCP/IP/Sek. Die Anzahl der Bytes, die pro Sekunde über eine TCP/IP-Verbindung empfangen werden.
376
Leistungsindikator Beschreibung
Übertragene Bytes TCP/IP/Sek. Die Anzahl der Bytes, die pro Sekunde über eine TCP/IP-Verbindung übertragen werden.
Empfangene Bytes TP4/Sek. Die Anzahl der Bytes, die pro Sekunde über eine TP4-Verbindung empfangen werden. TP4-basierte X.400-Connectors stehen in Exchange Server 2003 nicht zur Verfügung.
Übertragene Bytes TP4/Sek. Die Anzahl der Bytes, die pro Sekunde über eine TP4-Verbindung übertragen werden. TP4-basierte X.400-Connectors stehen in Exchange Server 2003 nicht zur Verfügung.
Empfangene Bytes X.25/Sek. Die Anzahl der Bytes, die pro Sekunde über eine X.25-Verbindung empfangen werden.
Übertragene Bytes X.25/Sek. Die Anzahl der Bytes, die pro Sekunde über eine X.25-Verbindung übertragen werden.
Außerdem verfügt der Exchange-MTA über Leistungsobjekte für jede durch den MTA hergestellte Verbindung. Wählen Sie im Dialogfeld Leistungsindikatoren hinzufügen in der Dropdownliste Leistungsobjekt das Objekt MSExchangeMTA-Verbindungen aus. Die einzelnen Verbindungsinstanzen werden unter Instanzen wählen aufgeführt. Jede MSExchangeMTA-Verbindungsinstanz beschreibt eine einzelne Verbindung. Sie können jedoch auch alle Instanzen zusammen überwachen.
377
Leistungsindikatoren für einzelne vom MTA hergestellte Verbindungen
In der folgenden Tabelle werden die für Leistungsobjekte vom Typ MSExchangeMTA-Verbindungen verfügbaren Leistungsindikatoren aufgeführt.
Leistungsindikatoren für MSExchangeMTA -Verbindungen
Leistungsindikator Beschreibung
Verknüpfungen Die Anzahl der Zuordnungen zwischen dem MTA und dem verbundenen MTA. MTAs können mehrere Zuordnungen öffnen, falls ein erhöhter Datendurchsatz erforderlich ist.
Empfangene Bytes/Sek. Die Anzahl der Bytes, die pro Sekunde von der verbundenen Entität empfangen werden.
Gesendete Bytes/Sek. Die Anzahl der Bytes, die pro Sekunde an die verbundene Entität gesendet werden.
Empfangene Nachrichten/Sek. Die Anzahl der Nachrichten, die pro Sekunde von der verbundenen Entität empfangen werden.
378
Leistungsindikator Beschreibung
Gesendete Nachrichten/Sek. Die Anzahl der Nachrichten, die pro Sekunde an die verbundene Entität gesendet werden.
Hinweis: Wenn zahlreiche Nachrichten an den Exchange-MTA gesendet werden, steigt und fällt während des Nachrichtenflusses der unter MSExchangeMTA-Verbindungen – SMTP-Server<GUID> angezeigte Wert Gesendete Nachrichten/Sek.. Der Wert für MSExchangeMTA – Länge der Arbeitswarteschlange ist jedoch stets 0. Wenn mithilfe eines X.400-Connectors Nachrichten von Exchange an einen Remote-MTA gesendet werden, wird sowohl unter MSExchangeMTA – Länge der Arbeitswarteschlange als auch unter MSExchange-MTA-Verbindungen – X.400-Connector Aktivität angezeigt. Ursache hierfür sind die unterschiedlichen Mechanismen, die vom MTA für die Verarbeitung eingehender und ausgehender XAPI-Nachrichten verwendet werden. Für eingehende Nachrichten an das SMTP-Postfach (ein XAPI-Gateway) überträgt der MTA die Nachrichten unverzüglich an die XAPI-Arbeitswarteschlange (DB000020.dat). Hierbei handelt es sich nicht um die MTA-Arbeitswarteschlange (DB0000028.dat). Für X.400-MTAs oder LAN-MTAs platziert der MTA die Nachrichten jedoch in der MTA-Arbeitswarteschlange und schließt die Übertragung erst ab, wenn der Remote-MTA den Empfang der Nachricht bestätigt hat. Auf diese Weise kann der Systemmonitor zum Ermitteln von Einzelheiten der internen MTA-Verarbeitung verwendet werden.
Exchange-MTA-EreignisprotokollierungDer Vorgang zum Beheben von MTA-Problemen sollte eine Überprüfung des Anwendungsereignisprotokolls umfassen. Der Exchange-MTA verfolgt wichtige Ereignisse automatisch. Sie können jedoch auch selbst MTA-Diagnoseprotokollstufen nach Kategorien festlegen, um die Menge der vom Exchange-MTA in das Ereignisprotokoll eingetragenen Informationen zu erhöhen. Zeigen Sie im Exchange-System-Manager die Eigenschaften des gewünschten Serverobjekts an, und klicken Sie dann auf die Registerkarte Diagnoseprotokoll. Markieren Sie unter Dienste das Objekt MSExchangeMTA, und wählen Sie dann Kategorien aus, um die Kategorien für den MTA aufzulisten. Jede MTA-Kategorie verfügt über eine Diagnoseprotokollstufe. Wenn der MTA ein Ereignis mit einem Signifikanzwert generiert, der kleiner oder gleich dem Protokolliergrad ist, wird das Ereignis im Ereignisprotokoll aufgezeichnet. Wenn der Signifikanzwert größer als der Protokolliergrad ist, wird das Ereignis nicht protokolliert. In der folgenden Tabelle werden die Exchange-MTA-Kategorien aufgeführt, die für die Diagnoseprotokollierung aktiviert werden können.
Während des normalen Betriebs sollte der Protokolliergrad für alle Exchange-MTA-Kategorien auf Keine festgelegt werden. Auf dieser Stufe werden nur Fehlerereignisse und
379
wichtige Nachrichten in das Ereignisprotokoll eingetragen. Wählen Sie beim Erhöhen des Protokolliergrads nur die für das Problem relevanten Kategorien aus. Wenn zu hohe Protokollierungsstufen für zu viele Kategorien eingestellt werden, wird das Ereignisprotokoll u. U. schnell mit irrelevanten Informationen gefüllt. Vergessen Sie nicht, den Protokolliergrad aller Kategorien auf Keine zurückzusetzen, wenn das Überprüfen des MTA abgeschlossen ist.
Tipp: Es ist auch möglich, Ereignisse nach Ereignisquelle und Kategorie zu filtern. Wählen Sie in der Ereignisanzeige die Option Anwendungsprotokoll aus, klicken Sie auf Ansicht und dann auf Filter. Wählen Sie unter Ereignisquelle die Option MSExchangeMTA aus. Wenn Sie alle Ereignisse des Exchange-MTA anzeigen möchten, müssen Sie in der Ereignisanzeige für Kategorie die Option Alle festgelegen. Ereignisprotokolle können lokal oder remote angezeigt und auch als EVT-Dateien gespeichert werden.
Diagnoseprotokollkategorien für den Exchange-MTA
Kategorie Beschreibung
X.400-Dienst Protokolliert Ereignisse in Verbindung mit der X.400-Protokollbehandlung, z. B. die Nachrichtenübermittlung an einen Remote-MTA.
Ressource Protokolliert Ereignisse in Verbindung mit der Verwendung von MTA-Ressourcen.
Sicherheit Protokolliert Ereignisse in Verbindung mit der MTA-Sicherheit und Sicherheitsverletzungen.
Schnittstelle Protokolliert Ereignisse in Verbindung mit der Kommunikation zwischen dem MTA und dem Exchange-Informationsspeicher sowie der Kommunikation zwischen MTAs mithilfe von Remoteprozeduraufrufen.
Produktsupport Protokolliert Ereignisse in Verbindung mit dem Debuggen von MTA-Vorgängen. Diese Ereignisse liefern Einzelheiten über die interne Verarbeitung im Exchange-MTA und stellen eine nützliche Informationsquelle für die Mitarbeiter des Microsoft-Produktsupports dar.
380
Kategorie Beschreibung
MTA-Administration Protokolliert Ereignisse in Verbindung mit Nachrichtenwarteschlangen. Generiert diese Ereignisse mithilfe des Warteschlangenanzeige-Snap-Ins des Exchange-System-Managers in Zusammenarbeit mit MTA-Warteschlangen.
Konfiguration Protokolliert Ereignisse in Verbindung mit Problemen bei den MTA-Konfigurationseinstellungen. Diese Ereignisse können von beschädigten Ausführungsdateien im Verzeichnis \Mtadata oder ungültigen Registrierungsparametern ausgelöst werden.
Verzeichniszugriff Protokolliert Ereignisse in Verbindung mit der Active Directory-Kommunikation.
Betriebssystem Protokolliert Ereignisse in Verbindung mit Betriebssystemdiensten, die vom MTA zum Erstellen und Verwalten von Dateien und Threads verwendet werden.
Interne Verarbeitung Protokolliert Ereignisse in Verbindung mit der internen Verarbeitung im Exchange-MTA und und stellt eine nützliche Informationsquelle für die Mitarbeiter des Microsoft-Produktsupports dar.
381
Kategorie Beschreibung
Interoperabilität Diese Kategorie veranlasst den MTA nicht dazu, Informationen in das Anwendungsereignisprotokoll zu schreiben. Stattdessen wird mit dieser Kategorie der Binärinhalt von Protokollnachrichten verfolgt. Verwenden Sie diese Kategorie in Verbindung mit der Kategorie Schnittstelle, um über interne Schnittstellen gesendete Nachrichten in AP*.LOG-Protokolldateien im Verzeichnis \Programme\Exchsrvr\Mtadata zu protokollieren. Mit AP*.LOG-Dateien können Sie z. B MTA-Stacks- und XAPI-Ablaufverfolgungen erstellen. Interoperabilitätsprotokolle können beim Verfolgen von Konfigurationsproblemen von MTAs nützlich sein.
AP*.LOG-Dateien werden erstellt, wenn Sie die Diagnoseprotokollstufen für die Kategorien Interoperabilität und Schnittstelle auf Mittel oder höher festlegen. Das aktuelle Protokoll weist stets die Bezeichnung Ap0.log auf. Ältere Protokolle erhalten die Bezeichnung AP#.log, wobei die Nummer (#) mit dem Alter des Protokolls steigt. Wenn eine Protokolldatei die Größe von 5 MB erreicht, wird es umbenannt und eine neue AP*.LOG-Datei erstellt.
Hinweis: AP*.LOG-Dateien wachsen sehr schnell und beeinträchtigen die Leistung des Exchange-MTA.
382
Kategorie Beschreibung
APDU (Application Protocol Data Unit) Diese Kategorie veranlasst den MTA nicht dazu, Informationen in das Anwendungsereignisprotokoll zu schreiben. Stattdessen werden mit dieser Kategorie der Inhalt des Nachrichtenumschlags (P1) für vom MTA gesendete und empfangene Nachrichten sowie die vollständig codierten APDUs verfolgt, die zwischen den MTAs übertragen werden.
Verwenden Sie diese Kategorie in Verbindung mit der Kategorie X.400-Dienst, um Informationen in BF*.LOG-Dateien im Verzeichnis \Programme\Exchsrvr\Mtadata zu protokollieren. BF*.LOG-Dateien sind bei der Diagnose von Interoperabilitäts- oder Konformitätsproblemen hilfreich, beispielsweise wenn Nachrichten von Remote-MTAs falsch oder fehlerhaft formatiert sind. Zum Decodieren der Daten einer BF*.LOG-Datei kann ein ASN.1-Analysetool wie das Tool Aspirin (im Exchange 2000 Server Resource Kit enthalten und im Buchhandel erhältlich) verwendet werden.
BF*.LOG-Dateien werden erstellt, wenn Sie die Diagnoseprotokollstufen für die Kategorien APDU und X.400-Dienst auf Mittel oder höher festlegen. Das aktuelle Protokoll weist stets die Bezeichnung Bf0.log auf. Ältere Protokolle erhalten die Bezeichnung BF#.log, wobei die Nummer (#) mit dem Alter des Protokolls steigt. Wenn eine Protokolldatei die Größe von 5 MB erreicht, wird es umbenannt und eine neue BF*.LOG-Datei erstellt.
Hinweis: BF*.LOG-Dateien wachsen sehr schnell und beeinträchtigen die Leistung des Exchange-MTA.
383
Ereignisprotokollierung im TextformatLegen Sie zum Speichern aller MTA-Ereignisprotokollinformationen in EV*.LOG-Dateien im Verzeichnis \Exchsrvr\Mtadata den folgenden Registrierungsparameter fest. Die EV*.LOG-Dateien stellen eine nicht lokalisierte Textkopie der MSExchangeMTA-Ereignisse dar, die in das Anwendungsereignisprotokoll eingetragen werden. Die Kategorien und Protokolliergrade der in die Protokolldateien eingetragenen Ereignisse werden wie in obiger Tabelle beschrieben gesteuert. EV*.LOG-Dateien können beim Beheben von MTA-Problemen einfacher gelesen, durchsucht und kopiert werden als das entsprechende Anwendungsereignisprotokoll.
Speicherort HKEY_LOCAL_MACHINE\CurrentControlSet\
Services\MSExchangeMTA\Parameters
Wert TextEventLogging
Typ REG_DWORD
Wert 0x1
Beschreibung Durch Festlegen dieses Werts auf 0x1 wird die Textprotokollierung in EV*.LOG-Dateien aktiviert.
Weitere Informationen zu den verschiedenen Protokollen, die vom Exchange-MTA erstellt werden können, finden Sie im Microsoft Knowledge Base-Artikel 153188, „XCON: Description of MTA Diagnostics Logging Options“.
Ablaufverfolgungsstufen-ProtokollierungJe höher die Diagnoseprotokollierebene, desto mehr MTA-bezogene Ereignisse finden Sie im Anwendungsereignisprotokoll. Diese zusätzlichen Informationen erleichtern Ihnen das Ermitteln der Ursachen eines Nachrichtenflussproblems. Die ausführlichsten Informationen über den Exchange-MTA erhalten Sie, wenn Sie die Diagnoseprotokollierebene für die MTA-Kategorien auf Verfolgungsebene festlegen. Die Protokollierung auf Ablaufverfolgungsstufe ist im Exchange-System-Manager nicht verfügbar, sondern muss mithilfe des Registrierungs-Editors festgelegt werden.
Hinweis: Durch die Ablaufverfolgungsstufen-Protokollierung wird die Serverleistung erheblich beeinträchtigt. Verwenden Sie die Ablaufverfolgungsstufen-Protokollierung unter Anleitung des Microsoft-Produktsupports, wenn Sie komplexe Probleme mit dem Exchange-MTA beheben.
384
Vorsicht: Die fehlerhafte Verwendung des Registrierungs-Editors kann zu schwerwiegenden Problemen führen, die möglicherweise eine Neuinstallation des Betriebssystems erforderlich machen. Microsoft übernimmt keine Garantie dafür, dass durch unsachgemäßes Verwenden des Registrierungs-Editors verursachte Probleme behoben werden können. Sie verwenden den Registrierungs-Editor auf eigene Verantwortung.
Führen Sie zum Festlegen der Diagnoseprotokollierebene für MSExchangeMTA-Kategorien auf Verfolgungsebene die folgenden Schritte aus:
1. Starten Sie den Registrierungs-Editor, und öffnen Sie folgenden Registrierungsschlüssel: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMTA\Diagnostics
2. Doppelklicken Sie auf jeden Eintrag für die einzelnen MSExchangeMTA-Kategorien, und legen Sie den Wert jeweils auf 0x7 fest. Doppelklicken Sie z. B. im rechten Fensterbereich auf den Eintrag X.400-Dienst, und ändern Sie dann den Wert in 0x7.
3. Starten Sie den Dienst Microsoft Exchange MTA-Stacks neu. In der Regel müssen Dienste nicht neu gestartet werden, damit die Änderung wirksam wird. Wenn Sie die Registrierung manuell bearbeiten, müssen Sie diesen Schritt jedoch ausführen.
MTACheck-ProtokollierungEin selten verwendetes Tool zur Problembehebung stellt eine aktuelle, ausführliche MTACHECK.LOG-Protokolldatei dar. Diese Protokolldatei enthält die Ergebnisse von Mtacheck.exe. Sie können das Tool MTACheck manuell starten, es wird jedoch auch automatisch ausgeführt, wenn der Dienst Microsoft Exchange-MTA-Stacks feststellt, dass der MTA zuvor nicht ordnungsgemäß beendet wurde. Wenn das Tool MTACheck automatisch ausgeführt wird, werden Ereignisse in das Anwendungsereignisprotokoll eingetragen und im Verzeichnis \Programme\Exchsrvr\Mtada\Mtacheck.out wird eine MTACHECK.LOG-Datei erstellt. Mithilfe der MTACHECK.LOG-Datei können Sie folgende Aufgaben ausführen:
Schnelles Abrufen einer Liste aller gesicherten Warteschlangen und ihrer zugehörigen Objekt-IDs.
Schnelles Identifizieren der Warteschlange, in der sich ein Nachrichtenobjekt beim Starten des MTA befindet.
Verknüpfen von Daten und Bezugsobjekten, die sich beim Starten in der Arbeitswarteschlange befinden.
Weitere Informationen zur MTACHECK.LOG-Datei finden Sie im Microsoft Knowledge Base-Artikel 163323, „XCON: Mtacheck.log“.
385
Objekt-IDs und Nachrichten-IDsEs gibt für jedes Objekt, das vom Exchange-MTA verarbeitet wird, eine aus acht Ziffern bestehende Objekt-ID. Die ersten zwei Ziffern der Objekt-ID geben die Objektklasse an. Die letzten sechs Ziffern der ID entsprechen einer DB<6Ziffern>.DAT-Datei, wenn das Objekt auf die Festplatte geschrieben wird. Werte für MTA-Objektklassen reichen von (hexadezimal) 01 bis 0E. Die zwei wichtigsten Objektklassen sind 01 (Warteschlangen) und 06 (Nachrichten). Das folgende Ereignis bezieht sich z. B. auf ein Nachrichtenobjekt mit der ID 0600002D.
Event ID: 272
Source: MSExchangeMTA
Type: Information
Category: X.400 Service
received from entity /DC=COM/DC=CONTOSO/CN=CONFIGURATION/CN=SERVICES/CN=MICROSOFT
EXCHANGE/CN=FIRST ORGANIZATION/CN=CONNECTIONS/CN=SMTP (SERVER01-{43D5C017-4A4B-4AFD-
85AF-06EAB90057AA}). The entity is a XAPI-Gateway , object is a Normal priority
Message, the MTS identifier is C=US;A= ;P=First Organizati;L=SERVER01-040503155933Z-4,
and content length is 1719. The number of objects sent so far = 1. External trace
information (first 100 bytes) =
3080638061801302555300006280130120000013104669727374204F7267616E697A61746900003180800D
3034303530333136303234315A8201008302060000000000. (10)
Hinweis: Nicht alle vom MTA verarbeiteten Objekte werden auf die Festplatte geschrieben. Ungesicherte Objekte befinden sich möglicherweise nur im Arbeitsspeicher.
Jede Nachricht verfügt auch über eine zugeordnete ID. Diese wird entweder als Nachrichten-ID oder als MTS-ID (Nachrichtenübertragungsdienst) bezeichnet. Anders als Objekt-IDs, die nur vom lokalen Exchange-MTA verwendet werden, ist die Nachrichten-ID Teil der Nachricht selbst und kann über mehrere MTAs hinweg verfolgt werden.
Eine typische Nachrichten-ID, die von einem Exchange-MTA generiert wurde, weist das folgende Format auf: C=<country>;A= ;P=<organization>;L=<server>-<date><greenich mean time>-<message number>. Ein Beispiel wird in Ereignis 272 in Fettformatierung angezeigt (siehe oben). Je nach Nachrichtenquelle gibt es mehrere Varianten des Werts L=. Nicht aus Exchange stammende Nachrichten-IDs unterscheiden sich u. U., haben jedoch denselben Zweck. MTS-IDs erleichtern das Verknüpfen von Nachrichtenkopien mit einer bestimmten Nachrichtenquelle. Wenn z. B. eine Nachricht an eine Verteilungsgruppe mit Hunderten von Empfängern gesendet wird, besitzt jede erzeugte Auffächerungskopie der Nachricht dieselbe Nachrichten-ID, auch nachdem die Nachrichten den MTA verlassen haben.
386
Leeren der MTA-DatenbankIn diesem Verfahren wird das Leeren der MTA-Datenbank erläutert, insbesondere das Verschieben von Dateien, um ein leeres Datenbankverzeichnis zu erstellen.
Bevor Sie beginnenBevor Sie das Verfahren in diesem Thema durchführen, sollten Sie Folgendes berücksichtigen:
Wenn Sie eine MTA-Datenbank leeren müssen, wenden Sie sich um Unterstützung an den Microsoft Product Support Services, damit gewährleistet ist, dass alle Schritte ordnungsgemäß ausgeführt werden. Wenn Sie die Schritte unsachgemäß durchführen, gehen derzeit in der MTA-Nachrichtenwarteschlange gespeicherte E-Mail-Nachrichten u. U. verloren.
VerfahrenLeeren der MTA-Datenbank
1. Starten Sie das Tool Dienste (Programmgruppe Verwaltung im Menü Start), um sicherzustellen, dass der Dienst Microsoft Exchange-MTA-Stacks beendet ist.
2. Kopieren Sie den gesamten Inhalt des MTA-Datenbankverzeichnisses (in der Standardeinstellung das Verzeichnis \Programme\Exchsrvr\Mtadata) an einen anderen Ort. Dieses Vorgehen ist dem alleinigen Verschieben der DAT-Dateien vorzuziehen, da Microsoft Support Services zum Ermitteln der Problemursache möglicherweise den gesamten Inhalt des Verzeichnisses Mtadata benötigt.
Hinweis: Löschen Sie nicht die DAT-Originaldateien, bevor die Nachrichten wiederhergestellt wurden.
3. Stellen Sie sicher, dass der Kopiervorgang erfolgreich abgeschlossen wurde, und löschen Sie dann die DAT-Dateien aus dem MTA-Datenbankverzeichnis.
4. Kopieren Sie alle auf der Exchange Server 2003-Produkt-CD im Verzeichnis \Setup\i386\Exchange\Bootenv enthaltenen Dateien in das MTA-Datenbankverzeichnis. Ohne die DAT-Kerndateien kann der Dienst Microsoft Exchange-MTA-Stacks nicht starten.
5. Entfernen Sie die Schreibschutzattribute von den kopierten Dateien. Im MTA-Datenbankverzeichnis dürfen sich keine schreibgeschützten Dateien befinden.
6. Starten Sie den Dienst Microsoft Exchange-MTA-Stacks neu. Wenn der MTA zuvor
387
Probleme mit beschädigten Nachrichten in den DAT-Dateien hatte, kann nun der Betrieb und die Nachrichtenübertragung fortgesetzt werden.
Weitere InformationenNach der Leerung der MTA-Datenbank müssen die Nachrichten in den DAT-Dateien, die aus dem MTA-Datenbankverzeichnis verschoben wurden, wiedergegeben werden, bevor sie übermittelt werden können. Ausführliche Anweisungen zum Wiedergeben von DAT-Dateien nach der MTA-Datenbankleerung finden Sie unter Wiedergeben von DAT-Dateien nach einer MTA-Datenbankleerung.
Wiedergeben von DAT-Dateien nach einer MTA-DatenbankleerungNach der Leerung der MTA-Datenbank können die Nachrichten in den DAT-Dateien, die aus dem MTA-Datenbankverzeichnis verschoben wurden, nicht übermittelt werden, solange sie nicht wiedergegeben wurden. Dieses Thema enthält Verknüpfungen zu den folgenden drei Verfahren für die Wiedergabe von DAT-Dateien nach einer MTA-Datenbankleerung.
Vollständige Wiedergabe: Die DAT-Dateien werden auf einmal auf dem Exchange-Server wiedergegeben, auf dem sie ursprünglich gespeichert waren)
Remotewiedergabe: Die DAT-Dateien werden auf einem anderen Exchange-Server als dem, auf dem sie ursprünglich gespeichert waren, wiedergegeben.
Inkrementelle Wiedergabe: Die DAT-Dateien werden in mehrere kleine Gruppen aufgeteilt, die nacheinander wiedergegeben werden.
Bevor Sie beginnenBevor Sie die Verfahren in diesem Thema ausführen, sollten Sie sich mit den Unterschieden zwischen den drei Methoden vertraut machen. Einen Überblick über die drei Methoden finden Sie im Abschnitt "Wiedergeben von DAT-Dateien" unter Exchange-MTA in der Exchange Server 2003-Architektur .
VerfahrenSo geben Sie die DAT-Dateien nach einer MTA-Datenbankleerung wieder
Wählen Sie eine der drei folgenden Methoden aus:
Wiedergeben von DAT-Dateien nach einer MTA-Datenbankleerung über eine
388
vollständige Wiedergabe
Wiedergeben von DAT-Dateien nach einer MTA-Datenbankleerung mittels einer Remotewiedergabe
Wiedergeben von DAT-Dateien nach einer MTA-Datenbankleerung mittels inkrementeller Wiedergabe
ReferenzAllgemeine Informationen zum Leeren von MTA-Datenbanken und zum Wiedergeben von DAT-Dateien finden Sie in den Abschnitten „Leeren der MTA-Datenbank“ und „Wiedergeben von DAT-Dateien“ in Exchange-MTA in der Exchange Server 2003-Architektur .
Wiedergeben von DAT-Dateien nach einer MTA-Datenbankleerung über eine vollständige WiedergabeIn diesem Verfahren wird das Wiedergeben von DAT-Dateien nach einer MTA-Datenbankleerung über eine vollständige Wiedergabe beschrieben, insbesondere das gleichzeitige Wiedergeben aller Nachrichten auf dem Server, auf dem sie ursprünglich gespeichert waren. Im allgemeinen ist dies die einfachste Methode, die DAT-Dateien wiederzugeben.
Bevor Sie beginnenBevor Sie das Verfahren in diesem Thema durchführen, sollten Sie Folgendes berücksichtigen:
Überzeugen Sie sich während der Vorbereitung auf die Wiedergabe davon, dass die MTA-Warteschlangen auf dem ursprünglichen Exchange-Server leer sind. Wenn sich derzeit keine Nachrichten in den MTA-Warteschlangen befinden, kann der MTA beendet werden. Die aktuellen DAT-Dateien können problemlos verschoben und schließlich gelöscht werden, da keine zu übermittelnden Nachrichten vorhanden sind. Wenn sich in den MTA-Warteschlangen Nachrichten befinden, warten Sie, bis der MTA diese Nachrichten gesendet hat und alle Warteschlangen leer sind. Anschließend muss der MTA sofort beendet werden. Nachdem der MTA beendet wurde, verschieben Sie die aktuellen DAT-Dateien an einen anderen Speicherort. Lassen Sie keine DAT-Dateien im MTA-Datenbankverzeichnis zurück. Kopieren Sie die wiederzugebenden DAT-Dateien in das MTA-Datenbankverzeichnis.
389
VerfahrenSo führen Sie eine vollständige Wiedergabe nach einer MTA-Datenbankleerung aus
1. Stellen Sie sicher, dass alle Warteschlangen auf dem Exchange-Server leer sind. Wenn die Warteschlangen nicht leer sind, warten Sie, bis der MTA das Übermitteln aller in den Warteschlangen befindlichen Nachrichten abgeschlossen hat.
Hinweis: Sie können das Tool Systemmonitor (Perfmon.msc) verwenden, um sicherzustellen, dass sich in den MTA-Warteschlangen keine Nachrichten befinden. Um z. B. die Arbeitswarteschlange zu überprüfen, wählen Sie das Leistungsobjekt MSExchangeMTA aus und dann den Leistungsindikator Länge der Arbeitswarteschlange (siehe folgende Abbildung).
Überprüfen der Anzahl von Nachrichten in der MTA-Arbeitswarteschlange
2. Wenn die MTA-Arbeitswarteschlange leer ist, beenden Sie den Dienst Microsoft Exchange-MTA-Stacks.
3. Kopieren Sie den gesamten Inhalt des MTA-Datenbankverzeichnisses an einen anderen Ort. Diese Dateien können schließlich verworfen werden, wenn die MTA-Warteschlangen beim Beenden des MTA leer waren.
390
4. Löschen Sie die DAT-Dateien aus dem MTA-Datenbankverzeichnis.
5. Kopieren Sie die DAT-Dateien aus dem Verzeichnis, das die DAT-Originaldateien enthält, die Sie im MTA-Datenbankverzeichnis wiedergeben möchten.
6. Starten Sie den Dienst Microsoft Exchange-MTA-Stacks neu.
7. Überwachen Sie die MTA-Warteschlangen und Ereignisprotokolle, um die erfolgreiche Übermittlung aller Nachrichten und die normale Funktion des MTA sicherzustellen.
Weitere Informationen Informationen zum Wiedergeben von DAT-Dateien nach einer MTA-Datenbankleerung
über eine Remotewiedergabe finden Sie unter Wiedergeben von DAT-Dateien nach einer MTA-Datenbankleerung mittels einer Remotewiedergabe.
Informationen zum Wiedergeben von DAT-Dateien nach einer MTA-Datenbankleerung über eine inkrementelle Wiedergabe finden Sie unter Wiedergeben von DAT-Dateien nach einer MTA-Datenbankleerung mittels inkrementeller Wiedergabe.
Wiedergeben von DAT-Dateien nach einer MTA-Datenbankleerung mittels einer RemotewiedergabeIn diesem Verfahren wird das Wiedergeben von DAT-Dateien nach einer MTA-Datenbankleerung mittels einer Remotewiedergabe beschrieben, insbesondere das Wiedergeben der Dateien auf einem anderen Server als demjenigen, auf dem sie ursprünglich gespeichert waren. Sie könnten dieses Verfahren der Einfachheit halber ausführen, falls es sich bei dem ursprünglichen Exchange-Server z. B. um einen ausgelasteten Bridgeheadserver handelt, der kontinuierlich große Mengen an E-Mail-Nachrichten überträgt und dessen MTA-Warteschlangen nie leer werden. Der Remotewiedergabeserver kann sich in jeder beliebigen Routinggruppe in der Exchange-Organisation befinden.
Bevor Sie beginnenBevor Sie das Verfahren in diesem Thema durchführen, sollten Sie Folgendes berücksichtigen:
Die für die Wiedergabe der DAT-Dateien erforderlichen Schritte sind nahezu identisch mit den Schritten, die für die vollständige Wiedergabe der DAT-Dateien auf dem ursprünglichen Server erforderlich sind. Sie müssen jedoch vor der Remotewiedergabe
391
auf dem Server unter Exchange Server, auf dem Sie die DAT-Dateien wiedergeben möchten, einen speziellen Registrierungsschlüssel festlegen.
Genau wie bei der Vorbereitung einer vollständigen Wiedergabe müssen Sie vor der Remotewiedergabe sicherstellen, dass die Warteschlangen des MTA auf dem ursprünglichen Exchange-Server leer sind. Wenn sich derzeit keine Nachrichten in den MTA-Warteschlangen befinden, kann der MTA beendet werden. Die aktuellen DAT-Dateien können problemlos verschoben und schließlich gelöscht werden, da keine zu übermittelnden Nachrichten vorhanden sind. Wenn sich in den MTA-Warteschlangen Nachrichten befinden, warten Sie, bis der MTA diese Nachrichten gesendet hat und alle Warteschlangen leer sind. Anschließend muss der MTA sofort beendet werden. Nachdem der MTA beendet wurde, verschieben Sie die aktuellen DAT-Dateien an einen anderen Speicherort. Lassen Sie keine DAT-Dateien im MTA-Datenbankverzeichnis zurück. Kopieren Sie die wiederzugebenden DAT-Dateien in das MTA-Datenbankverzeichnis.
Dieses Thema enthält Informationen zum Bearbeiten der Registrierung.
Vorsicht: Eine fehlerhafte Bearbeitung der Registrierung kann zu ernsthaften Problemen führen, die möglicherweise eine Neuinstallation des Betriebssystems erforderlich machen. Dadurch entstandene Probleme können unter Umständen nicht mehr behoben werden. Sichern Sie vor dem Ändern der Registrierung alle wichtigen Daten.
VerfahrenWiedergeben der DAT-Dateien nach einer MTA-Datenbankleerung mittels
Remotewiedergabe
1. Legen Sie auf dem Server unter Exchange Server, auf dem Sie die DAT-Dateien wiedergeben möchten, den folgenden Registrierungsschlüssel fest.
Speicherort HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\
MSExchangeMTA\Parameters
Wert Dispatch remote MTA messages
Typ REG_DWORD
Wert 0x1
392
Beschreibung Veranlasst den MTA, jeder Nachricht vor dem Routing zusätzliche Ablaufverfolgungsinformationen hinzuzufügen, sodass empfangende Exchange-Server, die die Nachrichten ursprünglich verarbeitet haben, die Nachrichten nicht als Übermittlungsschleife einstufen.
Dieser Registrierungswert unterstützt Groß- und Kleinschreibung und muss exakt wie oben angezeigt eingegeben werden. Nachdem der MTA die Übermittlung aller wiederzugebenden Nachrichten erfolgreich abgeschlossen hat, sollte der Registrierungsschlüssel entfernt oder auf 0x0 gesetzt werden.
2. Befolgen Sie die Schritte in diesem Verfahren: Wiedergeben von DAT-Dateien nach einer MTA-Datenbankleerung über eine vollständige Wiedergabe
3. Nachdem der MTA die Übermittlung aller wiederzugebenden Nachrichten erfolgreich abgeschlossen hat, sollte der für die Remotewiedergabe festgelegte Registrierungsschlüssel entfernt werden.
Weitere Informationen Informationen zum Wiedergeben von DAT-Dateien nach einer MTA-Datenbankleerung
mittels einer vollständigen Wiedergabe finden Sie unter Wiedergeben von DAT-Dateien nach einer MTA-Datenbankleerung über eine vollständige Wiedergabe.
Informationen zum Wiedergeben von DAT-Dateien nach einer MTA-Datenbankleerung mittels einer inkrementellen Wiedergabe finden Sie unter Wiedergeben von DAT- Dateien nach einer MTA-Datenbankleerung mittels inkrementeller Wiedergabe.
Wiedergeben von DAT-Dateien nach einer MTA-Datenbankleerung mittels inkrementeller WiedergabeIn diesem Verfahren wird das Wiedergeben von DAT-Dateien nach einer MTA-Datenbankleerung mittels inkrementeller Wiedergabe erläutert. Bei der inkrementellen Wiedergabe werden die DAT-Dateien in mehrere kleine Gruppen aufgeteilt, die nacheinander wiedergegeben werden. Dieses Verfahren ist komplexer als eine vollständige Wiedergabe oder Remotewiedergabe. Es kann sich jedoch beim Umgang mit einer sehr großen Anzahl von DAT-Dateien als hilfreich erweisen. Eine inkrementelle Wiedergabe könnte auch dann
393
ratsam sein, wenn wichtige Nachrichten zugestellt werden müssen, jedoch eine beschädigte Nachricht in einer Warteschlange das unerwartete Beenden des MTA verursacht.
Bevor Sie beginnenBevor Sie das Verfahren in diesem Thema durchführen, sollten Sie Folgendes berücksichtigen:
Wenn Sie eine inkrementelle Wiedergabe auf einem anderen Exchange-Server vornehmen als dem, auf dem die DAT-Dateien ursprünglich gespeichert waren, müssen Sie zuerst den Registrierungsschlüssel Dispatch remote MTA messages auf 0x1 festlegen. Genaue Anweisungen zum Festlegen dieses Registrierungsschlüssels finden Sie unter Wiedergeben von DAT-Dateien nach einer MTA-Datenbankleerung mittels einer Remotewiedergabe.
Dieser Artikel enthält Informationen zum Bearbeiten der Registrierung.
Vorsicht: Eine fehlerhafte Bearbeitung der Registrierung kann zu ernsthaften Problemen führen, die möglicherweise eine Neuinstallation des Betriebssystems erforderlich machen. Dadurch entstandene Probleme können unter Umständen nicht mehr behoben werden. Sichern Sie vor dem Ändern der Registrierung alle wichtigen Daten.
VerfahrenSo geben Sie die DAT-Dateien nach einer MTA-Datenbankleerung mittels
inkrementeller Wiedergabe wieder
1. Erstellen Sie eine zweite Kopie aller DAT-Dateien. Bewahren Sie einen Dateisatz als Sicherung auf, während Sie den anderen Satz für die inkrementelle Wiedergabe verwenden. Idealerweise befinden sich die wiederzugebenden Dateien auf demselben Laufwerk wie das MTA-Datenbankverzeichnis.
Hinweis: Es empfiehlt sich, einen vollständigen Satz der DAT-Dateien an einem separaten Ort aufzubewahren, damit eine vollständige Sicherung verfügbar ist, falls die inkrementelle Wiedergabe fehlschlägt.
2. Stellen Sie sicher, dass die MTA-Warteschlangen des für die Wiedergabe vorgesehenen Servers leer sind.
3. Wenn sich in der MTA-Arbeitswarteschlange keine Nachrichten befinden, beenden Sie den Dienst Microsoft Exchange-MTA-Stacks, und kopieren Sie die aktuellen DAT-Dateien an einen anderen Speicherort. Diese DAT-Dateien können schließlich
394
gelöscht werden, da sich in ihnen keine zu übermittelnden Nachrichten befinden.
4. Löschen Sie alle DAT-Dateien im MTA-Datenbankverzeichnis.
5. Kopieren Sie alle auf der Exchange Server 2003-Produkt-CD im Verzeichnis \Setup\i386\Exchange\Bootenv enthaltenen Dateien in das MTA-Datenbankverzeichnis.
6. Entfernen Sie die Schreibschutzattribute von den kopierten Dateien.
7. Verschieben Sie einen Teil der wiederzugebenden DAT-Dateien in das MTA-Datenbankverzeichnis. Wenn Sie z. B. 30.000 DAT-Dateien wiedergeben müssen, können Sie die Nachrichten in Teilen zu je 5.000 oder 10.000 DAT-Dateien wiedergeben.
Hinweis: Achten Sie darauf, die Dateien zu verschieben. Wenn Sie die Dateien nur kopieren, wird es später schwierig, die bereits wiedergegebenen Dateien von Dateien zu unterscheiden, die noch wiedergegeben werden müssen. Die wiederholte Wiedergabe einer Nachricht führt zu mehreren Nachrichtenübermittlungen. Befindet sich die Arbeitskopie der DAT-Dateien im selben Verzeichnis wie das MTA-Datenbankverzeichnis, wird das Verschieben der Dateien in das MTA-Datenbankverzeichnis vereinfacht.
8. Führen Sie Mtacheck \V aus, um die MTA-Datenbank zu überprüfen.
9. Starten Sie den Dienst Microsoft Exchange-MTA-Stacks, und überwachen Sie die MTA-Warteschlange und die Ereignisprotokolle, um sicherzustellen, dass alle Nachrichten erfolgreich verarbeitet werden und der MTA normal funktioniert.
10. Wiederholen Sie diese Schritte, bis alle DAT-Dateien wiedergegeben wurden.
11. Wenn Sie eine inkrementelle Remotewiedergabe durchführen, vergessen Sie nicht, danach den Registrierungsschlüssel Dispatch remote MTA messages zu entfernen oder auf 0x0 festzulegen.
Weitere Informationen Informationen zum Wiedergeben von DAT-Dateien nach einer MTA-Datenbankleerung
mittels einer vollständigen Wiedergabe finden Sie unter Wiedergeben von DAT-Dateien nach einer MTA-Datenbankleerung über eine vollständige Wiedergabe.
Informationen zum Wiedergeben von DAT-Dateien nach einer MTA-Datenbankleerung mittels Remotewiedergabe finden Sie unter Wiedergeben von DAT-Dateien nach einer MTA-Datenbankleerung mittels einer Remotewiedergabe.
395
MTA-Transportstacks und X.400-ConnectorsDer X.400-Standard basiert auf dem OSI-Referenzmodell (Open Systems Interconnection), das in der X.200-Empfehlung definiert ist. Der Exchange-MTA enthält Programmcode für die oberen vier Schichten des OSI-Stapels (d. h. Anwendungs-, Darstellungs-, Sitzungs- und Transportschicht). Unterhalb der OSI-Transportschicht stützt sich der MTA auf Treiber, die im Betriebssystem installiert sind.
Wie in der folgenden Abbildung dargestellt, besteht das OSI-Referenzmodell aus sieben Schichten.
ITU-Standards im OSI-Referenzmodell
Wie in der Abbildung ersichtlich, passt das TCP/IP-Protokoll nicht genau in den OSI-Stapel. Ursache dafür ist, dass das TCP/IP-Protokoll zwar einen geschichteten Protokollstapel darstellt, jedoch nicht OSI-konform ist (obwohl die meisten TCP/IP-Elemente dem OSI-Modell zugeordnet werden können). TCP/IP wurde ursprünglich von ARPA (Advanced Research Projects Agency) auf der Basis eines Vier-Schichten-Modells mit der Bezeichnung TCP/IP-Modell (manchmal Internetmodell genannt) entwickelt. Um die X.400-Kommunikation über TCP/IP nach dem OSI-Standard zu unterstützen, implementiert der Exchange-MTA eine in RFC 1006 definierte TP0-Schnittstelle (Transport Class 0), die auf TCP/IP aufsetzt.
Der Exchange-MTA kann als Transportmechanismus für die Kommunikation mit LAN-MTAs und XAPI-Gateways auch RPCs verwenden. RPCs stellen einen Kommunikationsmechanismus auf der Anwendungsschicht dar, da die RPC-Laufzeitbibliothek Darstellungs- und Sitzungsdienste enthält. Im Kontext des MTA-Stapels
396
implementieren RPCs eine Schnittstelle unterhalb der Sitzungsschicht. Die internen Dienste der RPC-Laufzeitkomponente sind für den MTA transparent.
Das X.25-Protokoll ist ein OSI-konformes Protokoll, das speziell für WAN-Verbindungen in paketvermittelten Netzwerken entwickelt wurde (z. B. ein öffentlicher X.400-Anbieter). Die MTA-Transportschicht setzt direkt auf das X.25-Protokoll auf, da X.25 über eine TP0-Protokollschnittstelle zur Transportschicht verfügt. Auf der OSI-Seite der Datenverbindungsschicht stützt sich X.25 auf das HDLC-LABP-Protokoll (High-level Data Link Control – Link Access Procedure Balanced). HDLC-LAPB ist das Protokoll, dass EICON X.25-Karten für die Kommunikation mit dem synchronen Modem verwenden, das den Server mit dem öffentlichen X.25-Netzwerk verbindet. X.25 ist das Netzwerkprotokoll, das auf HDLC aufsetzt, damit das lokale System mit dem nächsten Knoten im X.25-Netzwerk kommunizieren kann. Exchange unterstützt nur EICON X.25-Karten.
Hinweis: Das OSI-Referenzmodell definiert 5 Protokolle in der Transportschicht: TP0 bis TP4. Die Komplexität dieser Protokolle steigert sich von TP0 zu TP4. Für Aufgaben der Segmentierung und erneuten Zusammenfügung ist TP0 zuständig. TP1 erledigt das Segmentieren, das erneute Zusammenfügen und die Fehlerbehebung. TP2 verfügt über Multiplexing- und Demultiplexingfunktionen. TP3 kombiniert alle Funktionen von TP0, TP1 und TP2. TP4 fügt TP3 zuverlässige Transportdienste hinzu. TP4 ist im Grunde das OSI-Äquivalent zu TCP und wird meist von X.400-MTAs eingesetzt, die das TCP/IP-Protokoll nicht verwenden können (z. B. ältere Versionen von MS Mail-Gateway zu X.400). Exchange Server 2003 unterstützt TP4 nicht, da für Windows Server 2003 kein TP4-Protokollstapel verfügbar ist. Registrierungsparameter wie TP4 control blocks und TP4 threads, die Sie unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMTA\Parameters finden, sind Parameter für die Kompatibilität mit Exchange Server 5.5 unter Microsoft Windows NT® (für das ein TP4-Protokoll verfügbar war). Diese Einstellungen sind für Exchange Server 2003 ohne Bedeutung.
NachrichtenübertragungsdienstDie XFER IN- und XFER OUT-Threads im MTA-Prozess, die in diesem Abschnitt bereits beschrieben wurden, starten den Nachrichtenübertragungsdienst des MTA. MTSE (Message Transfer Service Element) verwendet RTSE (Reliable Transfer Service Element), um Nachrichten über eine Verbindung an einen Remote-MTA zu senden, und ACSE (Association Control Service Elements), um Verbindungen herzustellen und zu beenden.
Die Nachrichten, die MTSEs untereinander austauschen, werden zur Kennzeichnung ihres Formats als P1-Nachrichten bezeichnet. Das P1-Protokoll definiert das Format eines Nachrichtenübertragungsumschlags. Der Umschlag enthält die eigentliche Nachricht und darüber hinaus Routing- und Steuerungsfelder, sodass MTSEs eine Nachricht weiterleiten und verfolgen und Nachrichteninhalte überwachen können. In der folgenden Abbildung ist ein
397
Beispiel für einen P1-Nachrichtenübertragungsumschlag im Tool Aspirin dargestellt. Aspirin ist ein ASN.1-Analyseprogramm, das Sie im Exchange 2000 Server Resource Kit (im Buchhandel erhältlich) finden können. In X.400 werden Daten mithilfe der ASN.1-Syntax formatiert.
P1-Nachrichtenübertragungsumschlag
Die eigentliche Nachricht befindet sich im Teil X400COM_Content des P1-Umschlags. Die Nachricht ist normalerweise gemäß dem P2/P22-Protokoll formatiert, das das Format für Nachrichten zwischen Personen beschreibt. Exchange-MTAs unterstützen auch andere Nachrichtenformate, z. B. P772 und P42 für Nachrichten bei den Streitkräften. In der folgenden Tabelle sind die Nachrichtenformate aufgelistet, die vom Exchange-MTA unterstützt werden. Beachten Sie jedoch, dass nicht alle diese Formate dem X.400-Standard entsprechen. Einige Nachrichtenformate sind Exchange Server-spezifisch.
398
Unterstützte Nachrichtenformate in Exchange Server 2003
Format Inhaltstyp Objekt-ID
MDBEF MDBEF (Microsoft Database Encoding Format)
Microsoft-definierter und -registrierter Inhaltstyp
Wird auch als „MS Exchange-Inhalte“ bezeichnet
Ist nicht X.400-konform, kann nur zwischen Exchange-MTAs in derselben Organisation verwendet werden
2A864886F7140501
Öffentlicher Ordner-MDBEF Microsoft-definierter Inhaltstyp für Replikationsnachrichten Öffentlicher Ordner
Ist nicht X.400-konform, kann nur zwischen Exchange-MTAs in derselben Organisation verwendet werden
2A864886F7140502
P2 In der X.400-Spezifikation für das Konformitätsjahr 1984 definiert
Definiert das Format für IPMs (InterPersonal Messages)
56010A00
P22 In der X.400-Spezifikation für das Konformitätsjahr 1988 definiert
Erweitert das in X.400-84 definierte Format für IPMs
56010A01
399
Format Inhaltstyp Objekt-ID
P772 Nachricht bei den Streitkräften
Ergänzt das P22-Protokoll mit Erweiterungen für das in „Allied Communication Publication (ACP) 123“ definierte DMS-System (Defense Message System)
Diese Erweiterungen (bzw. zusätzlichen Eigenschaften) werden vom X.400-Standard zugelassen und normalerweise nur durch DMS-geeignete Clients sowie STANAG 4406-Clients der Version 1.7 und 3 angezeigt.
2B1A00A236000401
P42 Sichere Nachricht bei den Streitkräften
Nachricht bei den Streitkräften, die mithilfe von MSP3 (Message Security Protocol 3) digital signiert, verschlüsselt oder signiert und verschlüsselt wurde (im DMS ist ein alleiniges Verschlüsseln nicht zulässig)
X.509-Zertifikate, die S/MIME Version 1 entsprechen
Wird auch als „MSP3“ bezeichnet
60.864.801.650.201.024A
400
Format Inhaltstyp Objekt-ID
CSP Allgemeines Sicherheitsprotokoll (Common Security Protocol)
Wird innerhalb des DMS zum Definieren einer sicheren Nachricht bei den Streitkräften verwendet
Nachrichten bei den Streitkräften, die mithilfe von MSP4 (Message Security Protocol 4) digital signiert oder signiert und verschlüsselt wurden
X.509-Zertifikate, die S/MIME Version 3 entsprechen
Wird innerhalb des DMS-Programms als „ACP120“ oder „MSP4“ bezeichnet
608648016502010203
401
Format Inhaltstyp Objekt-ID
TNEF TNEF (Transport Neutral Encoding Format)
Microsoft-definierter und -registrierter Inhaltstyp
Wird auch als „MAPI“ bezeichnet
Ist X.400-konform, da die Nachricht und alle Anlagen gekapselt und der Nachricht als Binäranlage hinzugefügt werden
Der empfangende Client muss in der Lage sein, TNEF zu decodieren, da andernfalls eine nutzlose Anlage (Winmail.dat) angezeigt wird. Weitere Informationen zu TNEF finden Sie unter SMTP-Transportarchitektur.
2A864886F7140502
In der folgenden Abbildung ist dargestellt, wie die Protokolle P1 und P2 der Architektur von Exchange Server 2003 zugeordnet sind.
Umschlag- und Nachrichtenprotokolle
402
Hinweis: Der X.400-Standard definiert Protokolle für Clients, um mit einem MTA (P3) und einem Nachrichteninformationsspeicher (P7) zu interagieren. Allerdings werden diese Protokolle in Exchange Server 2003 nicht verwendet. In Exchange Server 2003 kommunizieren Clients nicht direkt mit dem MTA oder verwenden RPCs (z. B. das Snap-In Warteschlangenanzeige). Die Clientkommunikation mit dem Exchange-Informationsspeicher basiert auf MAPI- oder Internetprotokollen.
RTS (Reliable Transfer Service)Wenn MTSE eine Nachricht an einen anderen MTA senden soll, wird zum Aufrufen von RTSE die Schnittstelle RTSI (Reliable Transfer Service Interface) verwendet. Der MTA enthält ein Statusmodul, das darüber entscheidet, welche Datenpakte durch RTSE gesendet werden. RTSE sendet dann die Pakete. Der MTA übermittelt z. B. an RTSE die Anforderung RT_TRANSFER_REQUEST. RTSE versucht dann, diese Nachricht an den anderen MTA zu übertragen. Nachdem die Nachricht gesendet wurde, gibt RTSE ein RT_TRANSFER_CONFIRMED an MTSE zurück, damit der MTA die Nachricht als übertragen kennzeichnen kann. Einzelheiten zum Statusmodul finden Sie in X.228.
RTSE ermöglicht eine zuverlässige Datenübertragung, indem die Daten in eine Folge von Oktetts umgewandelt werden. Diese wird dann in Segmente mit der Bezeichnung „APDU“ (Application Protocol Data Units) aufgeteilt. Jede APDU wird anschließend zur Übermittlung an die Darstellungsschicht übergeben. RTSE stellt sicher, dass die APDUs bei der Übertragung zwischen MTAs nicht beschädigt und auch nicht verdoppelt werden. Wenn eine Verbindung aus einem beliebigen Grund unterbrochen wird, ist RTSE für die Wiederholung der Datenübertragung verantwortlich. Durch das Erstellen von Prüfpunkten unterstützt RTSE die intelligente Wiederherstellung von APDUs. Prüfpunkte ermöglichen die Wiederaufnahme die APDU-Übertragung an der Stelle, an der die Unterbrechung aufgetreten ist, statt die gesamte APDU erneut übertragen zu müssen. Aktivitäts- und geringfügige Synchronisierungsfunktionen der Sitzungsschicht unterstützen die Unterbrechung und Wiederaufnahme der Datenübertragung, falls die Netzwerkverbindung unterbrochen wird.
Hinweis: Sie können die Prüfpunktgröße, Fenstergröße und Wiederherstellungstimeouts in den RTS-Werten des X.400-Connectors oder des MTA-Verzeichnisobjekts konfigurieren.
RTSE bietet Dienste in den folgenden 3 Kategorien:
Herstellen von Zuordnungen Eine Zuordnung ist eine logische Verbindung zwischen zwei MTAs, die für die Nachrichtenübertragung über eine physische Verbindung verwendet wird. Zum gleichzeitigen Senden mehrerer Nachrichten können MTAs mehrere Zuordnungen über eine einzelne physische Verbindung herstellen. RTSE verwendet eine RTORQ-APDU (RT-OPEN REQUEST), um Zuordnungen herzustellen.
403
Bei positiver Antwort auf die Anforderung zum Herstellen einer Zuordnung zwischen zwei MTAs wird eine RTOAC-APDU (RT-OPEN-ACCEPT) verwendet. Bei einer negativen Antwort auf diese Anforderung wird eine RTORJ-APDU (RT-OPEN-REJECT) verwendet.
Datenübertragung Für die Datenübertragung verwendet RTSE die RT-TRANSFER-APDUs. Der Dialog verläuft entweder in eine oder abwechselnd in beide Richtungen, je nachdem, ob Daten nur von einem MTA oder abwechselnd in beide Richtungen übertragen werden. Für jede Zuordnung über eine abwechselnd in beide Richtungen verlaufende Verbindung wird ein Token verwendet, das immer nur ein MTA besitzen kann und mit dem festgelegt wird, welcher MTA an der Reihe ist. Wenn ein MTA eine Nachricht senden muss, jedoch für eine offene Zuordnung nicht über die Sendeberechtigung verfügt, muss er zunächst die Anzahl der für die Verbindung geöffneten Zuordnungen ermitteln. Wenn weniger als acht Zuordnungen vorhanden sind, versucht der MTA eine neue Zuordnung zu öffnen, für die er dann die Sendeberechtigung besitzt. Wenn bereits acht Zuordnungen geöffnet sind, sendet der MTA über eine der Zuordnungen eine RT_TURN_PLEASE-Anforderung. Wenn der empfangende MTA die Sendeberechtigung nicht benötigt, sendet er eine RT_TURN_GIVE-Antwort zurück, und der anfordernde MTA erhält die Erlaubnis zur Nachrichtenübertragung. Wenn der empfangende MTA die Sendeberechtigung nicht abgeben kann, antwortet er einfach so lange nicht, bis es sie nicht mehr benötigt. Bei einer Kommunikation, die abwechselnd in beide Richtungen verläuft, kann RTSE zum Wechseln der Datenübertragungsrichtung wie folgt RT-TURN-PLEASE- und RT-TURN-GIVE-APDUs verwenden:
RT-TURN-PLEASE Wenn ein MTA an der Reihe ist und vom anderen MTA eine RT-TURN-PLEASE-Anforderung empfängt, sendet er ein P-TOKEN-PLEASE-Element zurück, damit der anfordernde MTA die Sendeberechtigung erhält. RT_TURN_PLEASE-Anforderungen können unterschiedliche Prioritäten aufweisen, die im Zusammenhang mit der jeweiligen Nachrichtenpriorität stehen. Priorität 0 ist für MTAs vorbehalten, die eine Zuordnung beenden oder Routinginformationen senden möchten.
RT-TURN-GIVE Wenn ein MTA an der Reihe ist und von einem anderen MTA ein RT-TURN-GIVE-Anforderungselement empfängt, sendet es ein P-CONTROL-GIVE-Element und wird der empfangende MTA.
Beenden von Zuordnungen Zum Beenden einer Zuordnung verwendet RTSE wie folgt die APDUs RT-CLOSE, RT-U-ABORT und RT-P-ABORT:
RT-CLOSE Ein RTSE sendet möglicherweise eine RT-CLOSE-Anforderung, wenn es die Sendeberechtigung besitzt und keine RT-TRANSFER-Bestätigungen ausstehen. Wenn RTSE eine RT-CLOSE-Antwort empfängt, sendet es ein A-RELEASE-Paket, um die Zuordnung zu beenden.
RT-U-ABORT Hierbei handelt es sich um einen vom MTA ausgehenden Abbruch, der ausgelöst wird, wenn der MTA eine Zuordnung abbrechen möchte. Beispielsweise kann ein dem Konformitätsjahr 1984 entsprechender MTA eine
404
Zuordnung abbrechen, wenn der andere MTA ihn durch Verwendung von X.400-Funktionen aus dem Konformitätsjahr 1988 überfordert.
RT-P-ABORT Dies ist ein vom Anbieter ausgehender Abbruch einer Zuordnung, die ausgelöst wird, wenn ein Kommunikationsfehler nicht behoben werden kann. Beispielsweise führt der Empfang von Datenpaketen mit ungültigen Zuständen zu einem RT-P-ABORT (etwa wenn eine APDU gesendet wird, ohne zuvor eine Zuordnung herzustellen).
Der Exchange-MTA verwendet für die RTSE-Schicht des OSI-Stapels einen RTS-Threadpool. Sie können die Anzahl der RTS-Threads mithilfe des folgenden Registrierungsparameters beeinflussen.
Vorsicht: Die fehlerhafte Verwendung des Registrierungs-Editors kann zu ernsthaften Problemen führen, die möglicherweise eine Neuinstallation des Betriebssystems erforderlich machen. Microsoft übernimmt keine Garantie dafür, dass durch unsachgemäßes Verwenden des Registrierungs-Editors verursachte Probleme behoben werden können. Sie verwenden den Registrierungs-Editor auf eigene Verantwortung.
Speicherort HKEY_LOCAL_MACHINE\System\
CurrentControlSet\Services\
MSExchangeMTA\Parameters
Wert RTS threads
Typ REG_DWORD
Wert 0x1
405
Beschreibung Legt die Anzahl der RTS-Threads fest.
Der Standardwert ist 0x1. Der empfohlene Wert ist 0x3, sofern dieser MTA mit mehreren Remote-MTAs kommuniziert, sei es innerhalb einer Routinggruppe oder zwischen Routinggruppen.
Hinweis: Ein zu hoher Wert für die Anzahl der RTS-Threads kann zu einer Überlastung der übrigen Threads im OSI-Stapel führen und so eine Verlangsamung der Nachrichtenübertragung verursachen.
ACSE – Association Control Service ElementBei ACSE handelt es sich um eine Komponente jeder verbindungsorientierten Anwendungsentität im OSI-Modell (z. B ein X.400-MTA), die eine MTA-zu-MTA-Zuordnung für die Datenübertragung über eine Verbindung herstellen muss. Eine Zuordnung stellt den Kontext für die Kommunikation zwischen den MTAs her. Wenn beispielsweise ein MTA-Prozess Daten an den anderen MTA sendet, muss dieser in der Lage sein, die Daten zu interpretieren und darauf korrekt zu reagieren. Zum gleichzeitigen Übertragen mehrerer Nachrichten können MTAs mehrere Zuordnungen über eine einzelne physische Verbindung herstellen.
ACSE stellt RTSE zwei Diensttypen zur Verfügung:
Herstellen von Zuordnungen Das Herstellen von Zuordnungen wird durch den A-ASSOCIATE-Dienst bereitgestellt.
Beenden von Zuordnungen Das Beenden von Zuordnungen erfolgt durch drei Dienste.
A-RELEASE Dies ist der normale Freigabemechanismus zum Beenden einer Zuordnung.
A-ABORT Dies ist ein unbestätigter (plötzlicher) Abbruch einer Zuordnung.
A-P-ABORT Dies ist ein unbestätigter (plötzlicher) Abbruch einer Zuordnung, der mit A-ABORT vergleichbar ist. Der Unterschied besteht darin, dass bei A-P-ABORT dem Remote-MTA angezeigt wird, dass die Zuordnung von Dienstanbietern in unteren OSI-Schichten unterbrochen wurde.
406
Jede Verbindung zwischen zwei MTAs kann bis zu 10 Zuordnungen aufweisen. Da letztlich jede Zuordnung eine Kommunikation darstellt, können über einen einzelnen X.400-Connector gleichzeitig bis zu 10 Nachrichten gesendet werden. Zwei der 10 Zuordnungen sind für das Senden dringender Nachrichten reserviert. Jeder MTA besitzt die Sendeberechtigung für eine dieser beiden Zuordnungen und gibt sie auch nie ab. Wenn ein Remote-MTA versucht, gleichzeitig mehr als acht Zuordnungen für Nachrichten mit normaler Priorität zu erstellen, verweigert der Exchange-MTA diese zusätzlichen Zuordnungen und protokolliert im Anwendungsereignisprotokoll ein Ereignis mit dem Ereignis-ID 58. Es folgt ein Beispiel für dieses Ereignis:
Event Type: Warning
Event Source: MSExchangeMTA
Event Category: X.400 Service
Event ID: 58
Date: 04/01/2004
Time: 4:27:34 AM
User: N/A
Computer: SERVER01
Description:
The /O=TAILSPIN TOYS/OU=FIRST ADMINISTRATIVE GROUP/CN=CONFIGURATION/CN=SERVERS/CN=
SERVER01/CN=MICROSOFT MTA entity has reached the per-entity receive association limit
of 8, equal to 80 percent of the total 10. [MTA XFER-IN 36 34] (12)
Hinweis: Der Exchange-MTA kann insgesamt maximal 2.050 Zuordnungen über sämtliche Verbindungen (einschließlich X.400-Connectors, RPS-Verbindungen mit LAN-MTAs und XAPI-Sitzungen) aufrechterhalten. Dieser Grenzwert ist im Programmcode vorgegeben und kann nicht geändert werden.
Darstellungs- und SitzungsdiensteDer Darstellungsdienstanbieter stellt RTSE einen grundlegenden Datenübertragungsdienst zum Übermitteln von RT-TRANSFER-APDUs an Remote-MTAs bereit. Der Darstellungsdienstanbieter packt die APDUs der übergeordneten Schicht in PPDUs (Presentation Protocol Data Units), und der Dienstanbieter der Sitzungsschicht fügt den Datenpaketen weitere Informationen hinzu, um gültige Sitzungsprotokoll-Dateneinheiten (SPDUs) zu erstellen.
Die erste über die Darstellungsschicht gesendete Information ist eine P-ACTIVITY-START-Anzeige. Wenn die Nachricht lang ist, muss der MTA möglicherweise mehrere P-DATA-
407
Pakete senden. P-DATA-Pakete werden vom Empfänger-MTA nicht bestätigt, sodass der Sender-MTA zwischen den P-DATA-Paketen auch P-MINOR-SYNCHRONIZE-Anzeigen sendet. Der Empfänger-MTA bestätigt Synchronisierungspunkte ohne Dringlichkeit mit P-MINOR-SYNCHRONZE-Bestätigungselementen. Synchronisierungspunkte ohne Dringlichkeit müssen jedoch nicht sofort bestätigt werden. Ein Übertragungsfenster legt fest, wie viele Synchronisierungspunkte ohne Dringlichkeit jeweils unbestätigt sein dürfen. Nach der Übertragung der gesamten Nachricht wird eine P-ACTIVITY-END-Anforderung gesendet. Wenn der Empfänger-MTA die P-ACTIVITY-END-Anforderung bestätigt, sendet RTSE ein RT_TRANSFER_CONFIRMED-Element an den MTA zurück, und dieser kennzeichnet die Empfänger als verarbeitet.
Dieser Übertragungsvorgang wird durch die folgenden Ereignisse in der Darstellungsschicht gesteuert.
1. RT-TRANSFER-Anforderung
2. P-ACTIVITY-START-Anzeige, gefolgt von jeweils mindestens einem P-DATA-Paket, mit Ausnahme der letzten, auf die eine P-MINOR-SYNCHRONIZE-Anzeige folgt
3. P-MINOR-SYNCHRONIZE-Bestätigung
4. P-ACTIVITY-END-Anzeige
5. P-ACTIVITY-END-Bestätigung
Zum Schutz vor Datenverlust erfordert RTSE auch Synchronisierungsdienste, die von der Sitzungsschicht bereitgestellt werden. RTSE muss speziell zwischen Daten unterscheiden, die erfolgreich an den Empfänger-MTA gesendet wurden und Daten, deren Übertragung fehlgeschlagen ist. In diesem Fall fordert RTSE eine erneute Datenübertragung an.
Der Exchange-MTA verwendet für die Darstellungs- und Sitzungsdienste des OSI-Stapels einen Pool von Kernelthreads. Sie können die Anzahl der Kernelthreads mithilfe des folgenden Registrierungsparameters beeinflussen:
Speicherort HKEY_LOCAL_MACHINE\System\
CurrentControlSet\Services\
MSExchangeMTA\Parameters
Wert Kernel threads
Typ REG_DWORD
Wert 0x1
408
Beschreibung Legt die Anzahl der MTA-Kernelthreads für die Darstellungs- und Sitzungsschicht des OSI-Stapelss fest.
Der Standardwert ist 0x1. Passen Sie diesen Wert an, wenn dieser MTA mittels RPC über langsame oder durch lange Wartezeiten gekennzeichnete Netzwerkverbindungen mit LAN-MTAs kommuniziert.
Empfohlene Einstellung:
0x3 Die Standardempfehlung.
0x8 Wenn der Exchange Server 2003-MTA zu einer Routinggruppe mit mehr als 15 Exchange 5.5-Servern gehört.
0xC (12) Wenn der Exchange Server 2003-MTA zu einer Routinggruppe mit mehr als 30 Exchange 5.5-Servern gehört.
MTA-TransportstapelDamit der Exchange-MTA unter Verwendung der OSI-Transportschicht mit Remote-X.400-MTAs kommunizieren kann, müssen Sie in der Netzwerk-, Transport-, Sitzungs- und Darstellungsschicht mehrere OSI-Adressen definieren. Dies wird mithilfe von MTA-Transportstapeln erreicht. Sie können Transportstapel im Exchange-System-Manager installieren, wenn Sie mit der rechten Maustaste auf das Konfigurationsobjekt X.400 klicken, auf Neu zeigen und dann auf TCP/IP X.400-Dienst-Transportstapel oder X.25 X.400-Dienst-Transportstack klicken. Ein Dialogfeld wird angezeigt, in dem Sie Netzwerkadresse (d. h. einen Hostnamen, eine IP-oder X.121-Adresse), TSAP (Transport Service Access Point), SSAP (Session Service Access Point) und PSAP (Presentation Service Access Point) angeben. Geben Sie in den Feldern T-Selektor, S-Selektor und P-Selektor jeweils die Werte für TSAP, SSAP und PSAP ein.
Da der Dienst Microsoft Exchange-MTA-Stapel den OSI-Stapel nicht gemeinsam mit anderen MTA nutzt, sind auf einem Exchange-Server TSAP, SSAP und PSAP optionale Parameter. Wenn der Remote-MTA für die Verbindung mit dem lokalen MTA jedoch OSI-Adressinformationen verwendet, müssen Sie diese Parameter für den lokalen MTA definieren. Andernfalls kommt keine Kommunikation zustande. Die OSI-Adressinformationen können für einzelne X.400-Connectors überschrieben werden. Die Konfigurationsparameter für X.400-Connectors werden an späterer Stelle in diesem Abschnitt behandelt.
409
Hinweis: Dem Konformitätsjahr 1984 entsprechende X.400-MTAs unterstützen lediglich TSAPs. Es sollten keine SSAPs und PSAPs angegeben werden.
Zum Unterstützen von X.400-Connectors müssen Sie einen der beiden folgenden MTA-Transportstapel installieren:
TCP/IP MTA-Transportstapel TCP/IP empfiehlt sich für die X.400-Nachrichtenübertragung über das Internet sowie in Intranets. Der TCP/IP-Transportstapel implementiert auf TCP/IP aufsetzende ISO-Transportdienste (in RFC 1006 definiert). Wenn Sie einen TCP/IP-Transportstapel installieren und konfigurieren, erstellen Sie in Active Directory ein Konfigurationsobjekt, das Dienstzugriffspunkte und andere vom MTA verwendete Einstellungen definiert. Transportstapelobjekte befinden sich in der Konfigurationsverzeichnispartition unterhalb des MTA-Verzeichnisobjekts. Mit dem folgenden LDIFDE-Befehl können Sie sämtliche TCP/IP-Transportstapel, die auf allen Servern einer Exchange-Organisation konfiguriert wurden, in eine Datei mit dem Namen Stacklist.ldf exportieren: ldifde -f c:\Stacklist.ldf -s localhost -d "CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com"
-p subtree -r "(objectClass= rFC1006Stack)"
In der folgenden Tabelle sind die wichtigen Attribute des TCP/IP-Transportstapels beschrieben.
Wichtige Attribute des TCP/IP-Transportstapelobjekts
Attribut Beschreibung
objectClass Gibt die Klasse des Verzeichnisobjekts als rFC1006Stack an.
nAddressType Gibt den Informationstyp im nAddress-Attribut an. Die Adressinformationen enthalten entweder einen Hostnamen oder eine IP-Adresse.
nAddress Gibt den Hostnamen oder die IP-Adresse des lokalen Exchange-MTA an.
tSelector Gibt den TSAP in den OSI-Adressinformationen des Stapels an.
sSelector Gibt den SSAP in den OSI-Adressinformationen des Stapels an.
pSelector Gibt den PSAP in den OSI-Adressinformationen des Stapels an.
supportingStackBL Listet die DN der X.400-Connectors auf, die diesen Transportstapel verwenden.
410
Attribut Beschreibung
x400SelectorSyntax Gibt den Informationstyp der Attribute im tSelector, sSelector und pSelector an. Die OSI-Adressinformationen sind Werte im Hexadezimal- oder Dezimalformat.
name Gibt den Namen des Transportstapelobjekts an, wie er im Exchange-System-Manager angezeigt wird.
X.25 MTA-Transportstapel Sie müssen auf dem Exchange Server 2003 ausführenden Server eine EICON-X.25-Karte sowie unter Windows Server 2003 die EICON-WAN-Treiber installieren, damit X.400-Connectors über X.25 unterstützt werden. Die X.25-Konfiguration ist sehr komplex und kann nur durch Verwendung der Konfigurationshilfsprogramme ausgeführt werden, die im Lieferumfang der EICON-X.25-Karte enthalten sind. Die X.121-Adresse (mit einer Telefonnummer vergleichbar) ist die wichtigste zu konfigurierende Angabe. X.121-Adressdaten, Anrufbenutzerdaten sowie Einrichtungsdaten, die Sie im X.25-Transportstapel angeben, müssen mit der EICON-Kartenkonfiguration übereinstimmen, die vom X.25-Dienstanbieter festgelegt wurde.
Mit dem folgenden LDIFDE-Befehl verwenden können Sie sämtliche X.25-Transportstapel, die auf allen Servern einer Exchange-Organisation aus Active Directory konfiguriert wurden, in eine Datei mit dem Namen Stacklist.ldf exportieren: ldifde -f c:\Stacklist.ldf -s localhost -d "CN=First Organization,CN=Microsoft
Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com" -p subtree -r
"(objectClass= x25Stack)"
In der folgenden Tabelle sind die wichtigen Attribute des X.25-Transportstapels beschrieben.
Wichtige Attribute des X.25-Transportstapelobjekts
Attribut Beschreibung
objectClass Gibt die Klasse des Verzeichnisobjekts als x25Stack an.
nAddress Legt die lokale X.121-Adresse fest.
x25CallUserDataIncoming Gibt die Anrufbenutzerdaten für den X.25-Adapter an.
x25FacilitiesDataIncoming Gibt die Einrichtungsbenutzerdaten für den X.25-Adapter an.
x25LeasedLinePort Gibt die Anschlussnummer des X.25-Anschlusses an.
411
Attribut Beschreibung
tSelector Gibt den TSAP in den OSI-Adressinformationen des Stapels an.
sSelector Gibt den SSAP in den OSI-Adressinformationen des Stapels an.
pSelector Gibt den PSAP in den OSI-Adressinformationen des Stapels an.
supportingStackBL Listet die DN der X.400-Connectors auf, die diesen Transportstapel verwenden.
x400SelectorSyntax Gibt den Informationstyp der Attribute im tSelector, sSelector und pSelector an. Die OSI-Adressinformationen sind Werte im Hexadezimal- oder Dezimalformat.
name Gibt den Namen des Transportstapelobjekts an, wie er im Exchange-System-Manager angezeigt wird.
Beispiel für die MTA-KommunikationIn der folgenden Abbildung ist dargestellt, wie ein MTA über RTSI und den OSI-Stapel eine Verbindung öffnet. Jede Datenübertragung zwischen MTAs muss auf der einen Seite durch die Sitzungs- und Transportschicht des OSI-Stapels nach unten und dann auf der Seite des anderen MTA wieder im OSI-Stapel nach oben verlaufen. Wenn ein MTA eine Nachricht über den OSI-Stapel sendet, wird entweder eine Anforderung oder eine Antwort gesendet. Eine Anforderung erreicht den anderen MTA als Anzeige, eine Antwort wird als Bestätigung angezeigt.
412
Herstellen einer Verbindung zwischen zwei MTAs
Für die Kommunikation auf der Transportschicht des OSI-Stapels verwendet der MTA Transportthreads. Sie können die Anzahl der vom MTA verwendeten Transportthreads mithilfe des folgenden Registrierungsparameters konfigurieren:
Speicherort HKEY_LOCAL_MACHINE\System\
CurrentControlSet\Services\
MSExchangeMTA\Parameters
Wert Transport threads
413
Typ REG_DWORD
Wert 0x1
Beschreibung Legt die Anzahl der Transportthreads fest.
Der Standardwert ist 0x1. Der empfohlene Wert ist 0x3, sofern dieser MTA mit Remote-MTAs über mehrere X.400-Connectors kommuniziert.
X.400-ConnectorsIn einer verteilten Umgebung treten möglicherweise Kommunikationskonflikte auf, wenn die kommunizierenden MTA-Prozesse nicht sorgfältig koordiniert werden. Beispielsweise ist der Exchange-MTA ein 1988-konformer X.400-MTA und muss bei der Kommunikation mit einem X.400-1984-MTA einige seiner Funktionen deaktivieren.
Hinweis: Alle Exchange-Versionen enthalten X.400-MTAs des Konformitätsjahrs 1988. Ein Beispiel für einen X.400-1984-MTA ist das Gateway von Microsoft Mail für PC-Netzwerke zu X.400.
Konfigurieren eines X.400-ConnectorsUm die von einem Remote-X.400-MTA unterstützten Funktionen zu ermitteln, müssen Sie einen X.400-Connector zu diesem Remote-MTA konfigurieren. Stellen Sie im ersten Schritt sicher, dass Sie einen geeigneten MTA-Transportstapel konfiguriert haben, und erweitern Sie dann im Exchange-System-Manager die Routinggruppe, der Sie den X.400-Connector hinzufügen möchten, klicken Sie mit der rechten Maustaste auf Connectors, zeigen Sie auf Neu, und klicken Sie dann je nach Serverkonfiguration auf TCP X.400-Connector oder X.25 X.400-Connector.
Die folgende Abbildung zeigt das Eigenschaftendialogfeld für einen Beispiel-X.400-Connector.
414
Eigenschaften-Registerkarten eines X.400-Connectors
Es wird ein Dialogfeld mit folgenden Registerkarten angezeigt (siehe folgende Abbildung):
Allgemein Diese Registerkarte wird zum Angeben eines Namens, des Remote-X.400-MTA, eines Kennworts und des Transportstapels verwendet. Sie können auf dieser Registerkarte auch angeben, ob Remoteclients MAPI unterstützen und ob Verweise auf Öffentliche Ordner zulässig sind.
Zeitplan Diese Registerkarte wird zum Festlegen des Kommunikationszeitplans verwendet. Es können die Optionen Nie, Immer (ständige Kommunikation), Zu ausgewählten Zeiten (Abstände von bis zu 15 Minuten) und Remote eingeleitet konfiguriert werden.
Stapel Diese Registerkarte wird zum Angeben der erforderlichen Adressinformationen verwendet, z. B. der Name des Remotehosts oder die IP-Adresse (bzw. X.121-Adresse) sowie die Dienstzugriffspunkte für das Remotesystem.
415
Überschreiben Auf dieser Registerkarte können Sie die Werte der X.400-Standardattribute des lokalen MTA durch andere ersetzen.
Adressraum Diese Registerkarte wird dazu verwendet, den Typ und das Format von Routingadressen zu definieren. Zum Optimieren des Routings sind Adressräumen Kostenwerte zugeordnet. Zusätzlich können Sie angeben, ob dieser Connector der gesamten Organisation zur Verfügung steht oder auf die lokale Routinggruppe beschränkt ist.
Erweitert Diese Registerkarte wird zum Festlegen von X.400-Nachrichtenformaten und Übertragungsvorgängen verwendet, wenn Nachrichten an ein Remote-X.400-System oder an einen Exchange ausführenden Server gesendet werden.
Inhaltseinschränkungen Diese Registerkarte wird zum Angeben der Nachrichtentypen verwendet, die den Connector entsprechend ihrer Priorität (Hoch, Normal, Niedrig), des Nachrichtentyps (Systemnachrichten oder Nicht vom System stammende Nachrichten) und der Nachrichtengröße (Zugelassene Größen) passieren können.
Details Diese Registerkarte wird zum Angeben einer Verwaltungsnotiz für Informationszwecke verwendet.
Verbundene Routinggruppen Diese Registerkarte wird zum Angeben der Namen von Remoteroutinggruppen verwendet, die über diesen X.400-Connector erreicht werden können.
Empfangseinschränkungen Auf diese Registerkarte wird festgelegt, wer Nachrichten über diesen Connector senden darf. In der Standardeinstellung werden Nachrichten von allen Absendern angenommen.
VerbindungsanforderungsinformationenJede X.400-Verbindung stellt eine sichere Verbindung dar. Ein MTA, der mit einem anderen MTA eine Verbindung herzustellen versucht, muss sich also innerhalb der Verbindungsanforderung identifzieren. Zu den Identifizierungsinformationen gehören der Name und das Kennwort für den lokalen sowie den Remote-MTA. Wenn diese Informationen nicht der Konfiguration des Remote-X.400-Systems entsprechen, wird die Verbindungsanforderung abgelehnt, und es werden keine Nachrichten übertragen.
Im Container Protokolle des Servers können Sie in den Eigenschaften des X.400-Objekts den Namen und das Kennwort des lokalen MTA angeben. Der Administrator des Remote-MTA muss sicherstellen, dass diese Informationen auch auf dem Remote-MTA korrekt angegeben sind. Um den lokalen MTA ordnungsgemäß zu konfigurieren, müssen Sie außerdem vom Remoteadministrator den Namen und das Kennwort des Remote-MTA erhalten. Klicken Sie auf der Registerkarte Allgemein auf Ändern, um den Namen und das Kennwort des Remote-MTA anzugeben.
416
Hinweis: Beim MTA-Kennwort wird zwischen Groß- und Kleinschreibung unterschieden. Bei fehlerhafter Eingabe können keine Verbindungen hergestellt werden.
Insbesondere beim Verbinden mit einem öffentlichen X.400-Netzwerk sind Sie möglicherweise dazu gezwungen, den Namen und das Kennwort des lokalen MTA für einzelne Connectors durch andere Werte zu ersetzen. Betreiber öffentlicher X.400-Netzwerke stellen normalerweise die erforderlichen Informationen bereit. Passen Sie auf der Registerkarte Überschreiben die Konfiguration für einzelne Connectors an. Außerdem können Sie auf dieser Registerkarte die verschiedenen X.400-Protokollparameter anpassen, z. B. Höchstzahl der wiederholten Öffnungsversuche und Höchstzahl der wiederholten Übertragungsversuche, die weiter vorn in diesem Abschnitt behandelt wurden.
OSI-Adressinformationen für ausgehende und eingehende ÜbertragungenKonfigurieren Sie in den Connectoreigenschaften auf der Registerkarte Stapel die OSI-Adressinformationen, um anzugeben, wie eine Verbindung mit einem Remote-MTA hergestellt werden soll. Am wichtigsten ist es, die Netzwerkadresse des Remote-MTA (IP-Adresse, Hostname oder X.121-Adresse) sowie ggf. vorhandene TSAPs, SSAPs oder PSAPs anzugeben, sofern diese auf dem Remote-MTA definiert sind. Alle Werte auf der Registerkarte Stapel beziehen sich auf das Remotesystem. Wie bereits erläutert, werden die lokalen OSI-Adressinformationen im MTA-Transportstapel angegeben. Wenn Sie im lokalen MTA-Transportstapel keine OSI-Adressinformationen angegeben haben, erwartet der Exchange-MTA dieselben TSAP-, SSAP- oder PSAP-Werte, wie sie für die OSI-Adressinformationen des Remote-MTA definiert sind. Weitere Informationen zu OSI-Adresskonfigurationen finden Sie im Microsoft Knowledge Base-Artikel 152934, „XCON: X.400 Connector Stack Property Page Behavior“.
X.400-AdressenFür Nachrichtenrouting und -übermittlung verwenden X.400-Systeme ein komplexes Adressschema. Der wichtigste X.400-Adresstyp wird als mnemonischer O/R-Name (Originator/Recipient – Absender/Empfänger) oder als O/R-Adresse bezeichnet. Eine mnemonische O/R-Adresse identifiziert einen Empfänger anhand der Angaben zu Land, Administrationsverwaltungsdomänen (ADMD) und privater Verwaltungsdomäne (PRMD). Für eine vollständige Adresse sind weitere Adressinformationen wie Nachname und Vorname erforderlich.
Jede X.400-Adresse muss Informationen über die Verwaltungsdomäne enthalten. Eine Verwaltungsdomäne ist im Grunde ein Nachrichtennetzwerk, das durch eine einzelne Organisation verwaltet wird. Diese Organisation kann eine öffentliche Betreiberagentur (z. B. ein Telekommunikationsunternehmen) oder eine private Organisation sein. Wie vom ITU-T
417
empfohlen, werden interne Nachrichten von PRMDs verarbeitet. Für andere PRMDs bestimmte externe Nachrichten werden stets von öffentlichen ADMDs (Telekommunikationsunternehmen) verarbeitet. Theoretisch wird von PRMDs erwartet, miteinander über ADMDs zu kommunizieren. In der Praxis umgehen PRMDs häufig Telekomm-ADMDs, um zu geringeren Kosten direkt miteinander zu kommunizieren (z. B. mithilfe von TCP/IP über das Internet).
Hinweis: Die Felder Land, ADMD und PRMD müssen ausgefüllt werden. Wenn ein Nachrichtennetzwerk über keine ADMD verfügt, geben Sie im ADMD-Teil der X.400-Adresse ein einzelnes Leerzeichen ein. Ein Leerzeichen im ADMD-Teil ist gleichbedeutend mit „beliebige ADMD“.
In der folgenden Tabelle sind die Felder aufgelistet, die in einem O/R-Namen verwendet werden können.
O/R-Attribute in einer X.400-Adresse
Beschriftung Bedeutung Attributtyp Beispiel
C Land Land C=US;
A ADMD ADMD-Name A=MCI;
P PRMD PRMD-Name P=TAILSPINTOYS;
S Nachname Nachname S=BREMER;
G Vorname Vorname G=TED;
I Initials Initials I=TB;
Q Generation Generationsbezeichner
Q=SR;
CN Allgemeiner Name Common name CN=TED BREMER;
X.121 X.121 X.121-Adresse X.121=493098722102
N-ID N-ID Num. ID des Benutzer-Agents
N-ID=208973240
T-TY T-TY Terminaltyp T-TY=TTY;
T-ID T-ID Terminal-ID T-ID=309;
O Organisation Organisation O=EXCHANGE;
OU1 Org. Unit. 1 Organisationseinheit 1
OU1=IT;
418
Beschriftung Bedeutung Attributtyp Beispiel
OU2 Org. Unit. 2 Organisationseinheit 2
OU2=USA;
OU3 Org. Unit. 3 Organisationseinheit 3
OU3=SEA;
OU4 Org. Unit. 4 Organisationseinheit 4
OU4=DOWNTOWN;
DDA DDA Domänendefinierte Attribute (DDA:Typ=Attributwert)
Hinweis: Mit Ausnahme des DDA-Felds wird bei O/R-Namen nicht zwischen Groß- und Kleinschreibung unterschieden.
X.400-AdressräumeJeder X.400-Connector muss über mindestens einen zugeordneten Adressraum verfügen, den Sie auf der Registerkarte Adressraum angeben können. Das Routingmodul verwendet diese Informationen, um potenzielle Connectors für eine bestimmte Nachricht zu ermitteln, indem es Empfängeradressen mit verfügbaren Adressrauminformationen vergleicht. Normalerweise konfigurieren Sie einen X.400-Adressraum, wenn Sie eine Verbindung mit einem Remote-X.400-System herstellen. Sie können einem X.400-Connector jedoch auch andere Adresstypen zuordnen, indem Sie z. B. SMTP-Adressinformationen angeben (siehe folgende Abbildung). Eine an einen übereinstimmenden SMTP-Empfänger (z. B. [email protected]) gesendete Nachricht wird dann über den X.400-Connector geleitet. Der Exchange-MTA wandelt die Adressinformationen unter Verwendung von domänendefinierten Attributen (DDA) in eine X.400-Adresse um. DDA wurden bereits erläutert (siehe obige Tabelle).
419
Adressräume für einen X.400-Connector
Wenn Sie Nicht-X.400-Adressräume angeben, müssen Sie sicherstellen, dass der Empfänger-MTA die Nicht-X.400-Adressinformationen verarbeiten kann. Wenn z. B. das X.400-Zielsystem SMTP-DDA-Informationen nicht verarbeiten kann, sollte einem X.400-Connector, der auf dieses System verweist, kein SMTP-Adressraum zugeordnet werden. Im Remotesystem werden Nachrichten sonst nicht erfolgreich übertragen. Einige X.400-Systeme erwarten gekapselte SMTP-Adressinformationen, wie in RFC 2156 „MIXER (Mime Internet X.400 Enhanced Relay)“ definiert. In diesem RFC wird eine Methode zum Zuordnen von Nachrichtenformaten und Adressinformationen zwischen RFC 822/MIME und X.400 beschrieben. Ein entsprechender DDA-Adressteil sieht folgendermaßen aus: DDA:[email protected]. Exchange Server 2003 verwendet SMTP-DDAs anstelle von RFC822-DDA und unterstützt MIXER nicht.
Hinweis: Exchange Server 5.5 unterstützt die MIXER-Funktionen. Wenn Sie dieses Feature benötigen, ist in der Organisation ein Exchange 5.5-Bridgeheadserver erforderlich.
420
Konformitätsjahr und NachrichtenteileAuf der Registerkarte Erweitert können Sie X.400-Funktionen angeben, die beim Verbinden der Organisation mit einem Remote-X.400-System aktiviert werden sollten. Zu den wichtigen Einstellungen gehören das X.400-Konformitätsjahr und der X.400-Nachrichtenteil. Das MTA-Konformitätsjahr muss mit dem Konformitätsjahr des externen Systems übereinstimmen, da zwischen den X.400-Standards von 1984 und 1988 wesentliche Unterschiede bestehen. Andernfalls überlastet der lokale MTA den Remote-MTA, und es kommt zu Kommunikationsproblemen.
Registerkarte „Erweitert“ eines X.400-Connectors
Mithilfe der Liste X.400-Textkörper für Nachrichtentext können Sie auch einen Nachrichtenteil für den Nachrichtentext auswählen. Eine Nachricht kann aus mehreren Nachrichtenteilen bestehen, was das Anfügen von E-Mail-Anlagen ermöglicht. In der folgenden Tabelle sind die Nachrichtenteile aufgeführt, die von Exchange Server 2003 unterstützt werden.
421
X.400-Nachrichtenteile für IPM-Nachrichten
Nachrichtenteilnummer Nachrichtenteil
0 IA5-Text
1 Telex (ITA2 5-Bit)
2 Sprachnachricht
3 G3-Fax
4 TIFO (Text Interchange FOrmat)
5 Telex (T.61)
6 Videotext
7 National festgelegt
8 Verschlüsselt
9 Weitergeleitete IP-Nachricht
10 SFD (Simple Formatable Document)
11 TIF1 (Text Interchange Format 1)
12 Oktett
13 ISO6937-Text
14 Bilateral definiert (binär)
15 Binärdateiübertragung (erstmals 1988 definiert)
Wenn Sie eine Verbindung zu einem Exchange-Remote-MTA in derselben Organisation herstellen, können Sie das Kontrollkästchen Exchange-Inhalte zulassen aktivieren. Das Exchange-eigene Format ist nicht X.400-konform, doch zwischen Exchange-MTAs stellt dies kein Problem dar. Sie müssen das Kontrollkästchen jedoch bei der Kommunikation mit externen Exchange-MTAs deaktivieren, da Exchange-eigene Inhalte auch die legacyExchangeDN-Adressangaben umfassen, die nur in der lokalen Organisation gültig sind. Die durch die legacyExchangeDN-Adressen angegebenen Empfänger sind im Verzeichnis des externen Exchange-MTA nicht vorhanden.
Aktivieren Sie auf der Registerkarte Allgemein des Connectors das Kontrollkästchen Remoteclients unterstützen MAPI, damit Nachrichten an Exchange-Benutzer in externen Organisationen im Exchange-Format gesendet werden. Wenn Sie dieses Kontrollkästchen aktivieren, kapselt der Exchange-MTA die Nachrichten mithilfe von TNEF (Transport Neutral Encapsulation Format). Der MTA wandelt die Nachricht in einen Klarttextteil und eine Anlage
422
im kompatiblen TNEF-Format um. Weitere Informationen über den NNTP-Dienst finden Sie unter SMTP-Transportarchitektur.
NachrichtenschleifenerkennungX.400 definiert ein Konzept von Organisationsgrenzen, die den Umgang mit Ablaufverfolgungsinformationen beeinflussen, die dem P1-Nachrichtenübertragungsumschlag zum Zweck der Schleifenerkennung hinzugefügt wurden. Jeder MTA einer Organisation fügt den Nachrichten Ablaufverfolgungsinformationen hinzu, um anzuzeigen, dass die jeweilige Nachricht bereits vom MTA übertragen wurde. Wenn eine Nachricht denselben MTA ein zweites Mal erreicht, erkennt der MTA möglicherweise eine Nachrichtenschleife, verwirft die Nachricht und sendet einen Unzustellbarkeitsbericht.
Ablaufverfolgungsinformationen in einem P1-Nachrichtenübertragungsumschlag
Ein MTA kann dem P1-Nachrichtenübertragungumschlag die folgenden zwei Typen von Ablaufverfolgungsinformationen hinzufügen:
Externe Ablaufverfolgungsinformationen Externe Ablaufverfolgungsinformationen identifizieren die einzelnen X.400-Domänen, die die Nachricht übertragen haben. Die X.400-Domäne wird durch eine globale Domänen-ID definiert, die aus den X.400-Adressfeldern Land, ADMD und PRMD besteht.
423
Der MTA fügt einer Nachricht zusätzliche Ablaufverfolgungsinformationen hinzu, wenn die Nachricht die Organisation erreicht, z. B. wenn aus dem Exchange-Informationsspeicher eine Nachricht an den MTA übermittelt wird oder wenn der MTA eine Nachricht von einem MTA einer anderen Organisation empfängt. Wenn ein MTA eine Nachricht von einer externen Organisation erhält und in den externen Ablaufverfolgungsinformationen die eigene lokale globale Domänen-ID findet, wird eine Nachrichtenschleife zwischen den Organisationen erkannt. Das Vorhandensein der lokalen globalen Domänen-ID bedeutet, dass die lokale X.400-Domäne die Nachricht bereits verarbeitet und an die andere Domäne weitergeleitet hat. Wenn der MTA die Nachricht erneut akzeptiert, wird sie ein weiteres Mal an die andere Domäne geleitet, von der aus sie wieder zur lokalen Domäne gelangt. Dies stellt eine Nachrichtenschleife dar, und der MTA muss die Nachricht löschen und einen Unzustellbarkeitsbericht erstellen.
Hinweis: Der Exchange-MTA entfernt keine externen Ablaufverfolgungsinformationen aus Nachrichten.
Interne Ablaufverfolgungsinformationen Interne Ablaufverfolgungsinformationen identifzieren alle MTAs, die eine Nachricht innerhalb der Organisationsgrenzen übertragen haben. Interne Ablaufverfolgungsinformationen bestehen aus dem MTA-Namen und den Informationen über Weiterleitungsvorgänge (z. B. ob die Nachricht per Relay oder Routing weitergeleitet wurde oder eine Verteilerlistenaufgliederung durch diesen MTA verursacht hat). Wenn eine Nachricht zweimal zum selben MTA gelangt, wird sie u. U. gelöscht und ein Unzustellbarkeitsbericht erstellt.
Der MTA führt folgende Schritte aus, um Nachrichtenschleifen anhand der internen Ablaufverfolgungsinformationen zu erkennen:
a. Der MTA liest die Ablaufverfolgungsinformationsteil des P1-Nachrichtenübertragungsumschlags, um zu ermitteln, ob die Nachricht bereits einmal verarbeitet wurde.
b. Der MTA stellt fest, ob die globale Domänen-ID mit der lokalen globalen Domänen-ID übereinstimmt. Wenn dies der Fall ist, vergleicht der MTA den Namen des lokalen MTA mit den Namen in den internen Ablaufverfolgungsinformationen.
c. Wenn der Name des lokalen MTA nicht vorhanden ist, wird keine Nachrichtenschleife festgestellt. An dieser Stelle beendet der MTA die Überprüfung.
d. Wenn der Name des lokalen MTA vorhanden ist, überprüft der MTA die Routingvorgangsinformationen in den internen Ablaufverfolgungsinformationen. Wenn kein Routingvorgang vorhanden ist, wurde die Nachricht nicht über die lokale Domäne übertragen, und es wird keine Nachrichtenschleife festgestellt. An dieser Stelle beendet der MTA die Überprüfung.
e. Wenn der Routingvorgang anzeigt, dass die Nachricht per Relay weitergeleitet wurde, ist eine Nachrichtenschleife möglich. Der MTA überprüft dann die anderen
424
Aktionsfelder, um zu ermitteln, ob die Nachricht umgeleitet oder die Verteilerliste aufgegliedert wurde. Wenn keine dieser Bedingungen zutrifft, wurde die Nachricht möglicherweise aus berechtigten Gründen erneut an den MTA gesendet, sodass sie nicht mit einem Unzustellbarkeitsbericht gelöscht wird. Eine andere Möglichkeit für das berechtigte erneute Durchlaufen desselben MTA ist die Remotewiedergabe von Nachrichten. Dieses Szenario ist im Abschnitt „Wiedergeben von DAT-Dateien“ im Dokument Exchange-MTA in der Exchange Server 2003-Architektur beschrieben.
f. Wenn die Nachricht jedoch per Relay übermittelt wurde und keine weiteren Vorgänge angegeben sind, markiert der MTA die Nachricht als Schleife und löscht sie mit einem Unzustellbarkeitsbericht, um den Absender der Nachricht darüber zu informieren, dass diese ihr Ziel nicht erreicht hat.
Der MTA fügt dem P1-Nachrichtenübertragungsumschlag aller von ihm verarbeiteten Nachrichten interne Ablaufverfolgungsinformationen hinzu. Wenn der MTA jedoch erkennt, dass die Nachricht an eine externe X.400-Domäne übertragen wird, muss er alle internen Ablaufverfolgungsinformationen aus dem Nachrichtenumschlag entfernen, da für die Schleifenerkennung zwischen X.400-Domänen nur externe Ablaufverfolgungsinformationen verwendet werden. Um zu ermitteln, ob die internen Ablaufverfolgungsinformationen entfernt werden müssen, vergleicht der MTA seine lokale globale Domänen-ID mit der globalen Domänen-ID des Ziel-MTA.
Um die lokale globale Domänen-ID zu ermitteln, liest der Exchange-MTA die Standardempfängerrichtlinie. Der Exchange-MTA liest insbesondere die Informationen zu Land, ADMD und PRMD aus dem primären X.400-Adressraum, die in der Standardempfängerrichtlinie zum Erstellen der lokalen globalen Domänen-ID definiert wurde. Sie können die globale Standard-Domänen-ID des Exchange-MTA im Exchange-System-Manager konfigurieren. Rufen Sie unter Empfängerrichtlinien die Eigenschaften der Standardrichtlinie auf, und bearbeiten Sie dann den X.400-E-Mail-Adresseintrag. Die globale Standard-Domänen-ID lautet c=US ;p=<die ersten 16 Buchstaben des Namens der Exchange-Organisation>.
Hinweis: Der Exchange-MTA ermittelt die lokale globale Domänen-ID beim Initialisieren des MTA, d. h. wenn Sie den Dienst Microsoft Exchange-MTA-Stacks starten.
Um die globale Domänen-ID des Remote-MTA zu ermitteln, liest der lokale MTA die Informationen zu Land, ADMD und PRMD aus dem Adressraum, der dem X.400-Connector auf der Registerkarte Adressraum zugeordnet wurde. Sie können diese Informationen jedoch auf der Registerkarte Erweitert durch andere Werte ersetzen, indem Sie auf Globaler Domänenbezeichner klicken. Klicken Sie auf Angegebener GDI, und definieren Sie dann Land, ADMD und PRMD für die globale Domänen-ID an. Aktivieren Sie unter ADMD (a) die Option Beliebig, wenn Sie dem X.400-Connector die Verwendung eines beliebigen ADMD erlauben möchten. Dies entspricht einem leeren ADMD-Feld. Wenn Sie die Option Spezifische aktivieren, müssen Sie einen Wert für die ADMD eingeben.
425
Hinweis: Wenn Sie auf der Registerkarte Erweitert als Konformitätsjahr für den X.400-Connector das Jahr 1984 auswählen, müssen Sie die globale Domänen-ID explizit konfigurieren.
X.400-Connectorobjecte in Active DirectoryWenn Sie einen X.400-Connector installieren und konfigurieren, erstellen Sie in Active Directory ein Konfigurationsobjekt, das die X.400-Funktionen und Protokollparameter definiert, die der MTA verwenden muss. Connectorobjekte befinden sich in der Konfigurationsverzeichnispartition unterhalb der Routinggruppe des Connectors im Container Verbindungen. Das Routingmodul liest diese Informationen, um die Verbindungsstatustabelle zu initialisieren. Dies wird unter Nachrichtenroutingarchitektur behandelt.
Mit dem folgenden LDIFDE-Befehl können Sie alle X.400-Connectors einer Exchange-Organisation mit der Bezeichnung Erste Organisation in die Datei X400Connectors.ldf exportieren: ldifde -f c:\X400Connectors.ldf -s localhost -d "CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com" -p
subtree -r "(objectClass=x400Link)"
In der folgenden Tabelle werden wichtige Attribute von X.400-Connectorobjekten beschrieben.
Wichtige Attribute von X.400-Connectorobjekten
Attribut Beschreibung
activationSchedule Gibt den Aktivierungszeitplan für diesen X.400-Connector an.
activationStyle Gibt den Aktivierungsstil für diesen X.400-Connector an (0=Nie planen, 1=Zeitplan verwenden).
aDMD Gibt den ADMD-Teil einer manuell definierten globalen Domänen-ID an.
associationLifetime Legt die Zeitspanne in Sekunden fest, für die das System nach dem Senden einer Nachricht eine Zuordnung zu einem Remote-X.400-MTA aufrechterhält.
c Gibt den Land-Teil einer manuell definierten globalen Domänen-ID an.
426
Attribut Beschreibung
delivEITs Legt die in Übereinstimmung mit den für diesen Connector konfigurierten Inhaltseinschränkungen in codiertem Format übermittelbaren Nachrichtentypen fest.
delivExtContTypes Gibt die Objekt-IDs für Inhaltstypen an, die von diesem Connector unterstützt werden.
gatewayLocalDesig Gibt den Namen des Remote-X.400-MTA an, den der lokale MTA beim Herstellen einer Verbindung verwendet.
homeMTA Gibt den DN des MTA an, der diesen X.400-Connector verwendet.
lineWrap Gibt die Anzahl der Zeichen im Nachrichtentext an, nach der ein Zeilenumbruch eingefügt wird.
localInitialTurn Legt fest, ob bei neuen Zuordnungen zuerst der lokale MTA oder der Remote-MTA die Sendeberechtigung besitzt.
msExchConnectorType Kennzeichnet dieses Connectorobjekt als einen X.400-Connector.
msExchEncryptedPassword Gibt das Überschreibkennwort für den lokalen MTA an.
Hinweis: Das Kennwort ist in Active Directory geschützt, doch die X.400-MTAs übertragen MTA-Namen und -Kennwörter im Klartext.
msExchEncryptedPassword2 Gibt das verschlüsselte Kennwort an, das der lokale MTA beim Herstellen einer Verbindung mit dem Remote-X.400-MTA verwenden muss.
Hinweis: Das Kennwort ist in Active Directory geschützt, doch die X.400-MTAs übertragen MTA-Namen und -Kennwörter im Klartext.
427
Attribut Beschreibung
msExchNoPFConnection Gibt an, ob Bezüge auf Öffentliche Ordner über diesen X.400-Connector zulässig sind. Diese Einstellung ist nur dann von Bedeutung, wenn dieser Connector für Verbindungen mit einer anderen Routinggruppe in derselben Exchange-Organisation verwendet wird.
mTALocalDesig Gibt den Überschreibnamen für den lokalen MTA an.
nAddress Gibt den Hostnamen oder die IP-Adresse des lokalen Exchange-MTA an.
nAddressType Bezeichnet den Informationstyp im Attribut nAddress. Die Adressinformationen enthalten entweder einen Hostnamen oder eine IP-Adresse.
name Gibt den Namen des Transportstapelobjekts an, wie er im Exchange-System-Manager angezeigt wird.
numOfOpenRetries Gibt die maximale Anzahl von Versuchen des Exchange-MTA zum Öffnen einer Verbindung an, bevor ein Unzustellbarkeitsbericht gesendet wird.
numOfTransferRetries Legt die maximale Anzahl von Versuchen fest, die einem Exchange-MTA zur Verfügung stehen, um eine Nachricht über eine offene Verbindung zu senden.
objectClass Gibt die Klasse des Verzeichnisobjekts als x400Link an. Die folgenden Objektklassen sind von dieser Klasse abgeleitet:
rFC1006X400Link TCP/IP X.400-Connectors
x25X400Link X.25 X.400-Connectors
openRetryInterval Gibt die Wartezeit in Sekunden nach einem Fehler an, bevor das System versucht, eine Verbindung erneut zu öffnen.
428
Attribut Beschreibung
pRMD Gibt den PRMD-Teil einer manuell definierten globalen Domänen-ID an.
pSelector Gibt den PSAP in den OSI-Adressinformationen des Stapels an.
routingList Gibt den Adressraum an, der für diesen X.400-Connector konfiguriert wurde.
rTSCheckpointSize Legt die Datenmenge in KB fest, nach der ein Prüfpunkt eingefügt wird. Wenn ein Fehler auftritt und die Nachricht erneut gesendet werden muss, wird der Vorgang ab dem letzten Prüfpunkt neu gestartet. Der Wert 0 (null) gibt an, dass keine Prüfpunkte eingefügt werden.
rTSRecoveryTimeout Gibt die Wartezeit nach einer Verbindungsunterbrechung an, bis ein MTA die Informationen (einschließlich der Prüfpunkte) löscht und die Übertragung von Anfang an neu startet.
rTSWindowSize Legt die Anzahl der Prüfpunkte fest, die nicht bestätigt werden müssen, bevor die Datenübertragung angehalten wird. Wenn für rTSCheckpointSize der Wert 0 (null) angegeben wurde, hat der Wert für rTSWindowSize keine Bedeutung.
sessionDisconnectTimer Gibt die Wartezeit in Sekunden an, bis der Exchange-MTA eine Verbindung trennt, nachdem alle Zuordnungen über diese Verbindung abgebrochen wurden.
sSelector Gibt den SSAP in den OSI-Adressinformationen des Stapels an.
supportedApplicationContext Gibt die Objekt-IDs von Anwendungskontexten an, die eine OSI-Anwendung (z. B. der Exchange-MTA) unterstützt.
supportingStack Gibt den DN des MTA-Transportstapels an, den der MTA für die Kommunikation über diesen Connector verwendet.
429
Attribut Beschreibung
tempAssocThreshold Legt die maximale Anzahl von Nachrichten in der Warteschlange fest, die das System an ein Remotesystem senden kann. Wenn dieser Wert überschritten wird, öffnet der MTA eine weitere Zuordnung.
transferRetryInterval Legt die Wartezeit in Sekunden nach dem Fehlschlagen einer Nachrichtenübertragung fest, bis die Nachricht erneut über eine offene Verbindung gesendet wird.
transferTimeoutNonUrgent Gibt die Wartezeit in Sekunden pro KB an, bis vom System für eine nicht dringende Nachricht ein Unzustellbarkeitsbericht gesendet wird.
transferTimeoutNormal Gibt die Wartezeit in Sekunden pro KB an, bis vom System für eine normale Nachricht ein Unzustellbarkeitsbericht gesendet wird.
transferTimeoutUrgent Gibt die Wartezeit in Sekunden pro KB an, bis vom System für eine dringende Nachricht ein Unzustellbarkeitsbericht gesendet wird.
translationTableUsed Gibt die Übersetzungstabelle an, die der MTA zum Codieren des Nachrichtentexts verwendet.
transportExpeditedData Gibt an, ob beschleunigte Daten über den X.400-Connector unterstützt werden. Beschleunigte Daten umgehen die Flusskontrolle und bieten so eine Methode, das Übermitteln dringender Nachrichten (z. B. eine Anforderung zur plötzlichen Verbindungstrennung) zu beschleunigen. Wenn ein MTA den beschleunigten Datendienst anfordert, muss der andere MTA dessen Verwendung in der Verbindung zustimmen. Andernfalls ist das Feature nicht verfügbar.
tSelector Gibt den TSAP in den OSI-Adressinformationen des Stapels an.
430
Attribut Beschreibung
twoWayAlternateFacility Gibt an, ob die MTA-Zuordnung unidirektional oder abwechselnd bidirektional ist.
x400SelectorSyntax Legt die Syntax des P-, S- und T-Selektors fest (0 oder undefiniert=Hex, 1=Text).
Ausführen mehrerer X.400-ConnectorsDie Höchstzahl an X.400-Connectors, die Sie auf einem einzelnen Server unter Exchange Server installieren können, variiert je nach den praktischen Einschränkungen für den jeweiligen Server (z. B. Hardware und Netzwerkbandbreite). In der Standardeinstellung ist Exchange 2003 jedoch nicht für die Verwendung zahlreicher X.400-Connectors optimiert, da der Server pro Connectortyp (d. h. TCP/IP und X.25) maximal 20 gleichzeitige Verbindungen unterstützt. Bei 10 Zuordnungen pro Connector bedeutet dies maximal 2 X.400-Connectors über TCP/IP. Wenn Sie mehr als 30 TCP/IP-X.400-Connectors auf einem zentralen Bridgeheadserver konfigurieren und alle Zuordnungen verwendet werden, wird im Anwendungsereignisprotokoll möglicherweise die Ereignis-ID 9156 protokolliert:
Event ID: 9156
Source: MSExchangeMTA
Type: Warning
Category: Resource
Description: A resource limit has been reached while attempting to open an
association. There are no free control blocks available for network type 1. The
configured count is 70. [BASE IL MAIN BASE 1 282] (10)
Um auf einem Bridgeheadserver mehr als zwei X.400-Connectors zu unterstützen, sollten Sie mithilfe des folgenden Registrierungsparameters die Anzahl der Kontrollböcke erhöhen:
Speicherort HKEY_LOCAL_MACHINE\System\
CurrentControlSet\Services\
MSExchangeMTA\Parameters
Namen TCP/IP control blocks
TP4 control blocks
Eicon X.25 connections
Typ REG_DWORD
431
Wert 0x14 (20)
Beschreibung Legt die Höchstzahl der für X.400-Verbindungen verfügbaren Puffer fest. Es empfiehlt sich, für jeden X.400-Connector 10 Kontrollblöcke zur Verfügung zu stellen. Dazu kommt noch 1 weiterer Kontrollblock für eine eingehende Verbindung, falls die maximale Anzahl an Zuordnungen überschritten wurde. Wenn z. B. 30 TCP/IP-X.400-Connectors vorhanden sind, stellen Sie eine optimale Leistung 0x12D (301) TCP/IP-Kontrollblöcke bereit.
Um die Kommunikationsbelastung auf der TCP/IP-Schicht zu bewältigen, müssen Sie möglicherweise auch die Anzahl der vom MTA verwendeten TCP/IP-Threads mithilfe des folgenden Registrierungsparameters erhöhen:
Speicherort HKEY_LOCAL_MACHINE\System\
CurrentControlSet\Services\
MSExchangeMTA\Parameters
Wert TCP/IP threads
Typ REG_DWORD
Wert 0x2
Beschreibung Legt die Anzahl der MTA-Threads fest, die RFC1006-Verbindungen verarbeiten.
Der Standardwert ist 0x2. Dieser Wert wird für die zwei Untertypen von RFC1006-Threads (Treiber und asynchrone Benachrichtigung) mit 2 multipliziert.
Die tatsächliche Höchstzahl an Kontrollblöcken, die der Exchange-MTA verwenden kann, beträgt 1.250. Dieser Höchstwert gilt jedoch für den gesamten Pool von Kontrollblöcken für die TCP/IP-, TP4- und X.25-Transportstapel. Die angegebenen Registrierungsparameter gelten jeweils für die TCP/IP-, TP4- und X.25-Kontrollblöcke. In der Standardeinstellung ist für diese Parameter der Dezimalwert 20 eingestellt, sodass der Wert für die TCP/IP-Kontrollblöcke problemlos auf bis zu 1.210 erhöht werden kann. Dies erlaubt einen Höchstwert von 121 TCP/IP-X.400-Connectors auf einem einzelnen Server, von denen jeder die maximale Anzahl an verfügbaren Zuordnungen verwendet. Dies ist ein theoretischer
432
Wert. Die Kapazität des Bridgeheadservers beschränkt u. U. die tatsächliche Anzahl von X.400-Connectors.
Es ist unwahrscheinlich, dass die einzelnen X.400-Connectors so viele E-Mail-Nachrichten verarbeiten, dass die Höchstzahl an Zuordnungen pro Connector erforderlich ist. Wenn der X.25-Transportstapel nicht verwendet wird, können Sie außerdem den Wert des Eicon-X.25-Verbindungsparameters auf 0 (null) festlegen. Dadurch erhöht sich die Anzahl der für den TCP/IP-Stapel verfügbaren Kontrollblöcke um 20. In Exchange Server 2003 werden jedoch TP4-basierte X.400-Connectors nicht unterstützt. Deshalb werden durch das Reduzieren der TP4-Kontrollblöcke keine zusätzlichen Kontrollblöcke für TCP/IP frei.
Wenn Sie die maximale Gesamtanzahl der Kontrollblöcke auf einen zu hohen Wert festlegen, kann der Dienst Microsoft Exchange-MTA-Stacks nicht gestartet werden, und im Anwendungsereignisprotokoll wird das folgende Ereignis protokolliert:
Event ID: 4300
Source: MSExchangeMTA
Type: ERROR
Category: Configuration
Unable to initialize due to a bad configuration. Contact Microsoft Technical Support.
Error code=<variable> [1 POP4 MAIN BASE 1] (16)
Verbinden von Routinggruppen mithilfe von X.400-ConnectorsUnter Umständen ist es ratsam, zwischen Routinggruppen X.400-Connectors zu verwenden, insbesondere über unzuverlässige Netzwerkverbindungen. X.400 ist von Vorteil, da es eine intelligente Wiederherstellung von Übertragungszuordnungen unterstützt. Häufig kann die Nachrichtenübertragung an der Stelle einer Unterbrechung fortgesetzt werden. Bei X.400-Connectors erhöht sich außerdem nicht die Größe der Nachrichten, da Nachrichteninhalte ohne Umwandlungen im Exchange-eigenen Format übertragen werden. Im Gegensatz dazu müssen Routinggruppenconnectors und SMTP-Connectors Nachrichten in das RFC 822- und MIME-Format umwandeln. Dies führt zu einer Größensteigerung von 30 Prozent. Um Remoteroutinggruppen für einen X.400-Connector anzugeben, verwenden Sie in den Connectoreigenschaften die Registerkarte Verbundene Routinggruppen.
433
Lastenausgleich zwischen RoutinggruppenDie lokalen und Remote-MTAs eines X.400-Connector sind die einzigen Bridgeheadserver, die der Connector in der jeweiligen Routinggruppe verwenden kann. Wenn Sie mehrere Bridgeheadserver verwenden möchten, müssen Sie zusätzliche X.400-Connectors konfigurieren, die auf andere Remote-MTAs in der Zielroutinggruppe verweisen. Ein einzelner Server kann mehrere X.400-Connectors unterstützen, von denen jeder dieselben oder unterschiedliche MTA-Transportstacks verwendet. Sie können jedoch auch mehrere X.400-Connectors auf mehreren Servern konfigurieren, wie in der folgenden Abbildung dargestellt.
Mehrere Bridgeheadserver und X.400-Connectors zwischen 2 Routinggruppen
Beachten Sie jedoch, dass Exchange Server 2003 keinen wirklichen Lastenausgleich über mehrere Connectorinstanzen durchführt. Wie in Nachrichtenroutingarchitektur erläutert, ruft das erweiterte Warteschlangenmodul einmal das Routingmodul auf, um eine Nachrichtenroute zu ermitteln, speichert diese Informationen zwischen und überträgt dann alle Nachrichten dieses Typs über denselben Connector. Zusätzliche Connectors werden nur verwendet, wenn der erste Connector ausfällt. Ein zweiter Server kann jedoch unter Umständen den zweiten Connector auswählen und auf diese Weise einen gewissen Lastenausgleich erzielen.
Hinweis: Da das Routingmodul nicht zwischen lokalen und Remote-Connectors unterscheiden kann, ist es möglich, dass das erweiterte Warteschlangenmodul auf einem Bridgeheadserver in der lokalen Routinggruppe alle Nachrichten für die Zielroutinggruppe an einen anderen Bridgeheadserver in derselben lokalen Routinggruppe überträgt, obwohl es sich beim lokalen Server ebenfalls um einen Bridgeheadserver handelt, der die Nachrichten übertragen könnte.
434
Nachrichtenrouting über Exchange-MTAsIn einer Exchange-Organisation, in der Nachrichten über Exchange-MTAs übertragen werden, wird das Nachrichtenrouting vom Routingmodul zweimal ausgeführt. Das erste Routingereignis tritt im erweiterten Warteschlangenmodul auf. Das Routingmodul informiert das erweiterte Warteschlangenmodul darüber, dass vom Exchange-MTA eine Nachricht über einen Verbindungscontroller geleitet werden muss, und das erweiterte Warteschlangenmodul ordnet die Nachricht in die Nachrichtenwarteschlange des MTA ein. Der Treiber für den Exchange-Informationsspeicher legt die Nachricht im Exchange-Informationsspeicher im MTA-Ordner MTS-IN ab. Der Exchange-Informationsspeicher leitet die Nachricht dann mithilfe eines SMTP-XAPI-Gateways an den MTA weiter. Das folgende Beispielereignis zeigt eine an den MTA geleitete Nachricht, wie sie soeben beschrieben wurde. Die relevanten Informationen sind fett dargestellt.
Event ID: 272
Source: MSExchangeMTA
Type: Information
Category: X.400 Service
Object 0600002D received from entity
/DC=COM/DC=CONTOSO/CN=CONFIGURATION/CN=SERVICES/CN=MICROSOFT EXCHANGE/CN=FIRST
ORGANIZATION/CN=CONNECTIONS/CN= , object is a Normal priority Message, the MTS
identifier is C=US;A= ;P=First Organizati;L=SERVER01-040503155933Z-4, and content
length is 1719. The number of objects sent so far = 1. External trace information
(first 100 bytes) =
3080638061801302555300006280130120000013104669727374204F7267616E697A61746900003180800D
3034303530333136303234315A8201008302060000000000. (10)
SMTP-XAPI-GatewayAus der Perspektive eines Exchange-MTA arbeitet der SMTP-Dienst ähnlich wie ein MAPI-basierter Connector (z. B. Connector für Lotus Notes oder Connector für Novell GroupWise). Der Exchange-MTA erhält Nachrichten vom SMTP-XAPI-Gateway über den Gateway-Ordner MTS-IN und leitet Nachrichten an dieses Gateway über den Gateway-Ordner MTS-OUT. Diese Nachrichtenwarteschlangenordner befinden sich im SMTP-Postfach. Der Name des SMTP-Postfachs lautet SMTP <Servername> {<GUID des Postfachspeichers>}). Im oben angegebenen Ereignis lautet der Postfachname SMTP (SERVER01-{43D5C017-4A4B-4AFD-85AF-06EAB90057AA}). In Active Directory befindet sich im Container Verbindungen direkt unter dem Exchange-Organisationsobjekt ein entsprechendes Connectorobjekt für das XAPI-Gateway. Dieser Container wird im Exchange-System-Manager nicht angezeigt, doch Sie können ihn mithilfe von ADSI-Bearbeitung anzeigen oder den Inhalt mithilfe des Befehls LDIFDE exportieren. Beispielsweise können Sie mit folgendem Befehl alle SMTP-XAPI-Gatewayobjekte in die Datei SMTPXAPI.ldf exportieren: ldifde -f c:\SMTPXAPI.ldf -s
435
localhost -d "CN=Connections,CN=First Organization,CN=Microsoft
Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com" -r
"(objectClass=mailGateway)".
In der folgenden Tabelle sind die wichtigen Attribute des SMTP-XAPI-Gatewayobjekts beschrieben.
Wichtige SMTP-XAPI-Gatewayattribute
Attribut Beschreibung
objectClass Identifiziert das Verzeichnisobjekt als mailGateway- und msExchConnector-Objekt.
Common name Repräsentiert den Namen des Connectorobjekts in Active Directory relativ zum übergeordneten Container.
computerName Verweist auf den Bridgeheadserver, auf dem der SMTP-Dienst ausgeführt wird. Dieses Attribut muss exakt mit dem NetBIOS-Namen des Bridgeheadservers übereinstimmen, sonst kann das Snap-In Warteschlangenanzeige die Nachrichtenwarteschlangen nicht in Exchange-System-Manager anzeigen.
deliveryMechanism Gibt den Übermittlungsmechanismus an, der von Exchange Server 2003 zum Weiterleiten von Nachrichten an das XAPI-Gateway verwendet wird.
distinguishedName Gibt den DN (Distinguished Name) des Connectorobjekts in Active Directory an.
homeMDB Gibt den privaten Postfachspeicher an, der das Connectorpostfach enthält.
homeMTA Gibt den Exchange-MTA an, der für das Nachrichtenrouting an das XAPI-Gateway zuständig ist.
436
Attribut Beschreibung
legacyExchangeDN Gibt den DN (Distinguished Name) des Connectorobjekts im früheren Verzeichnisformat von Exchange Server 5.5 an. Dieses Attribut des Connectorobjekts muss festgelegt werden, damit das Snap-In für die Warteschlangenanzeige funktioniert.
delivExtContTypes Listet die Objekt-IDs für Inhaltstypen auf, die von diesem Connector unterstützt werden.
Name Gibt den Namen des Connectorobjekts an.
canPreserveDNs Gibt an, ob ein Connectorobjekt DNs in Empfängerinformationen verarbeiten kann.
Exchange-MTA-NachrichtenübertragungDie folgende Abbildung zeigt, wie der SMTP-Dienst und der Exchange-MTA miteinander interagieren.
437
Nachrichtenübermittlung über den Exchange-MTA
Nach dem Empfang einer Nachricht vom SMTP-XAPI-Gateway muss der MTA einen geeigneten Connector für die Nachrichtenübertragung an den nächsten Hop ermitteln. In Exchange 2000 Server und Exchange Server 2003 führt der MTA selbst kein
438
Nachrichtenrouting mehr durch, sondern stellt über MTARoute.dll Kontakt zum Routingmodul her, das dann eine Route für die Nachricht ermittelt. Möglicherweise wandelt der MTA jedoch den O/R-Empfängernamen in ein Format um, dass das Routingmodul passieren kann.
Der MTA ruft das Routingmodul nicht für Nachrichten auf, die von LAN-MTAs, X.400-MTAs oder MAPI-Connectors empfangen werden. Diese Nachrichten werden direkt an den Ordner MTS-OUT des SMTP-XAPI-Gateways weitergeleitet. Das erweiterte Warteschlangenmodul verarbeitet dann die Nachrichten und ruft selbst das Routingmodul auf, wenn eine Nachricht nicht an lokale Empfänger gerichtet ist. Es kann sogar vorkommen, dass eine Nachricht über den Exchange-Informationsspeicher und das SMTP-XAPI-Gateway zurück an den Exchange-MTA übertragen wird, wenn sie an einen anderen LAN-MTA, X.400-MTA oder ein Messagingsystem von einem Drittanbieter übermittelt werden muss. Der SMTP-Dienst markiert alle Nachrichten, die er an den Exchange-MTA überträgt, um anzuzeigen, dass der MTA das Routingmodul aufrufen muss. Ausführliche Informationen zum Nachrichtenroutingprozess finden Sie unter Nachrichtenroutingarchitektur.
Wenn das Routingmodul den nächsten Hop für eine Nachricht ermitteln kann, prüft der MTA, ob der nächste Hop über den lokalen SMTP-Dienst erreicht wird. Es kann beispielsweise vorkommen, dass ein X.400-Connector und ein Routinggruppenconnector beide auf dieselbe Routinggruppe verweisen. In diesem Fall leitet das erweiterte Warteschlangenmodul die Nachricht möglicherweise an den MTA zur Übertragung über den X.400-Connector. Daraufhin leitet der MTA die Nachricht u. U. für die Übertragung über den Routinggruppenconnector zurück an den SMTP-Dienst usw. Um eine solche Situation zu vermeiden, ruft der MTA das Routingmodul ein zweites Mal auf, wenn das erste Routing ergibt, dass der MTA die Nachricht zurück an den SMTP-Dienst senden soll. Der MTA übergibt beim ersten Weiterleitungsaufruf die X.400-Proxyadresse des Empfängers und beim zweiten Weiterleitungsaufruf den Wert für legacyExchangeDN. Dahinter steht die Erwartung, dass der Aufruf mit diesem Parameter zu einer anderen Route führt, die nicht über den SMTP-Dienst verläuft.
Verbindungsstatusinformationen und erneutes Routing von NachrichtenWenn das Routingmodul den nächsten Hop für eine Nachricht ermitteln kann, gibt es den Routingobjektnamen eines Connectors oder eines MTA zurück. Der MTA konvertiert diesen Routingobjektnamen in einen DN, um den Connector oder das MTA-Verzeichnisobjekt zu ermitteln, den der MTA für die Nachrichtenübertragung in Active Directory verwenden muss. Das Verzeichnisobjekt definiert den Übermittlungsmechanismus und die Kommunikationsparameter.
Wenn das Routingmodul den nächsten Hop infolge eines vorübergehenden Verbindungsausfalls nicht ermitteln kann, markiert das Routingmodul die Nachricht entsprechend, um den MTA darüber zu informieren, dass die Nachricht bei der nächsten
439
Änderung der Verbindungsstatusinformationen umgeleitet werden muss. Wie in Nachrichtenroutingarchitektur erläutert, ändern sich die Verbindungsstatusinformationen, wenn Sie die Connectorkonfiguration in Ihrer Organisation ändern, oder wenn das erweiterte Warteschlangenmodul oder der MTA einen Connector als betriebsbereit oder nicht betriebsbereit markiert. Der Verbindungsstatusalgorithmus gewährleistet, dass Verbindungsstatusinformationen an alle Server der Organisation weitergegeben werden, auf denen Exchange Server 2003 ausgeführt wird.
Wenn das Routingmodul auf dem lokalen Server entdeckt, dass die Verbindungsstatusinformationen geändert wurden, ruft es die Funktion RoutingReset() des MTA auf. Der MTA ruft dann das Routingmodul für alle Nachrichten auf, deren Route bereits ermittelt wurde, die jedoch noch nicht gesendet sind, um die Route neu zu bestimmen. Bis das Routingmodul aktualisierte Verbindungsstatusinformationen vom Routinggruppenmaster erhält, führen Routingaufrufe zu einem temporären Fehler, und der MTA legt die Nachrichten in der Warteschlange für Nachrichten ab, die auf ein erneutes Routing warten. Das erneute Routing ist erfolgreich, wenn die Verbindungsstatusinformationen für die gesamte Routinggruppe synchronisiert wurden.
Hinweis: Häufige Änderungen der Verbindungsstatusinformationen verursachen möglicherweise Nachrichtenübertragungsprobleme im Exchange-MTA. Beispielsweise werden Nachrichten möglicherweise wegen nicht erkannter O/R-Namen mit Unzustellbarkeitsberichten gelöscht. In einer Umgebung mit unzuverlässigen Netzwerkverbindungen müssen Sie u. U. die Weitergabe von Verbindungsstatusinformationen deaktivieren, wie in Nachrichtenroutingarchitektur dargestellt.
Austauschen von Verbindungsstatusinformationen zwischen RoutinggruppenIn einer Exchange-Organisation mit Routinggruppenconnectors werden Verbindungsstatusinformationen zwischen Routinggruppen mithilfe von SMTP ausgetauscht. Wenn zum Verbinden von Routinggruppen X.400-Connectors bereitgestellt werden, müssen die Verbindungsstatusinformationen ebenfalls über X.400 ausgetauscht werden. Dazu ruft der Exchange-MTA das Routingmodul auf, um den aktuellen MD5-Hashwert zu ermitteln. Dies ist eine verschlüsselte Signatur, die die Versionsnummer der Verbindungsstatustabelle repräsentiert. Anhand dieser Informationen können Routingmodule feststellen, ob sie über dieselben Verbindungsstatusinformationen verfügen.
Vor dem Senden von Nachrichten sendet der lokale MTA das GUID-Attribut der Exchange-Organisation sowie den aktuellen MD5-Hashwert in einem DIGEST_QUERY-Paket an den Remote-MTA. Wenn der Remote-MTA dieses Paket erkennt, leitet er die Informationen an
440
das eigene Routingmodul weiter. Das Routingmodul vergleicht den Hashwert mit der eigenen Hashwertkopie und liefert das Ergebnis an den MTA zurück. Der Remote-MTA sendet die Antwort dann zurück an den lokalen MTA.
Beispiel einer Hashwertabfrage und einer Abfrageantwort
Wenn sich die MD5-Hashwerte der Exchange-Server voneinander unterscheiden, folgt eine ausführlichere Kommunikation zwischen den MTAs, um OrgInfo-Pakete auszutauschen. Das OrgInfo-Paket enthält die Verbindungsstatustabelle mit allen Details und den Zuständen der Routingtopologie. Die MTAs übergeben die OrgInfo-Pakete an die lokalen Routingmodule, und diese ermitteln, welcher Server über die aktuelleren Informationen verfügt. Der Server mit den aktuelleren Informationen verwirft das empfangene OrgInfo-Paket. Der andere Server übergibt die aktualisierten Verbindungsstatusinformationen an den Routinggruppenmaster, und dieser aktualisiert die Verbindungsstatusinformationen auf allen Servern der lokalen Routinggruppe.
Exchange-MTAs übertragen Hashwertabfragen auch dann, wenn Verbindungen mit MTAs außerhalb der lokalen Exchange-Organisation hergestellt werden. Das empfangende Routingmodul überprüft die Organisations-GUID im DIGEST_QUERY-Paket, um zu ermitteln, ob die Verbindungsstatusinformationen von der lokalen Organisation stammen. Betreffen die Verbindungsstatusinformationen eine andere Organisation, wird der MD5-Hashwert ignoriert. In der Abfrageantwort wird angegeben, dass keine OrgInfo-Pakete ausgetauscht werden müssen.
441
Exchange-MTA in einer Organisation im gemischten ModusIn einer Organisation im gemischten Modus stellt der Exchange-MTA eine entscheidende Komponente für die Abwärtskompabilität mit Servern dar, auf denen Exchange Server 5.5 ausgeführt wird. Innerhalb des lokalen Standorts kommunizieren Exchange Server 5.5-MTAs mithilfe von RPCs direkt miteinander. Exchange Server 2003 muss deshalb den gleichen Mechanismus verwenden. MTAs und RPCs werden auch über Routinggruppenconnectors verwendet, für die ein Server unter Exchange Server 5.5 als Bridgeheadserver fungiert (d. h. ein Routinggruppenconnector fungiert in Exchange 5.5 als Standortconnector).
RPC-basierte MTA-KommunikationFür die Kommunikation über RPCs müssen Sie keinen OSI-Transportstack oder X.400-Connector konfigurieren. Wenn Exchange-Komponenten direkt miteinander kommunizieren, sind alle Parameter bekannt. Beispielsweise müssen Sie für Exchange Server 2003-MTAs keinen Connector für die Kommunikation mit Servern unter Exchange Server 5.5 in der lokalen Routinggruppe konfigurieren. Der Exchange-MTA kommuniziert mit dem Exchange-Informationsspeicher über XAPI, um Nachrichten an den SMTP-Dienst zu übertragen, sowie über MAPI-basierte Connectors, deren Nachrichtenwarteschlangen sich im Exchange-Informationsspeicher befinden. Diese Kommunikation basiert auf MAPI, einer RPC-basierten API. Wenn Sie im Exchange-System-Manager mithilfe des Warteschlangenanzeige-Snap-Ins die Nachrichten in der MTA-Nachrichtenwarteschlange anzeigen, basiert auch diese Kommunikation auf RPCs.
Der Exchange-MTA unterstützt über einen RPC-Threadpool die Kommunikation mit LAN-MTAs, dem Exchange-Informationsspeicher und mit Verwaltungsprogrammen. Sie können die minimale und maximale Anzahl der RPC-Threads mithilfe der folgenden Registrierungsparameter beeinflussen:
Speicherort HKEY_LOCAL_MACHINE\System\
CurrentControlSet\Services\
MSExchangeMTA\Parameters
Wert Min RPC Threads
Typ REG_DWORD
Wert 0x4
442
Beschreibung Legt die Mindestanzahl von RPC-Threads fest, die die RPC-Laufzeitbibliothek für den MTA-Prozess erstellen und verwalten soll.
Der Standardwert ist 0x4.
Speicherort HKEY_LOCAL_MACHINE\System\
CurrentControlSet\Services\
MSExchangeMTA\Parameters
Wert Max RPC Calls Outstanding
Typ REG_DWORD
Wert 0x32
Beschreibung Legt die maximale Anzahl von RPC-Threads fest. Durch diese Einstellung wird die maximale Anzahl von RPC-Aufrufen begrenzt, deren gleichzeitige Verarbeitung garantiert wird.
Der Standardwert lautet 0x32 (50). Der empfohlene Wert für Szenarios, in denen Exchange Server 5.5 und Exchange Server 2003 koexistieren, ist 0x80 (128). Der Wert für maximal ausstehende RPC-Aufrufe sollte nicht 0 betragen und muss größer sein als die Mindestanzahl der RPC-Threads.
Wenn Sie die maximale Anzahl von RPC-Threads erhöhen, sollten Sie auch die Anzahl eingehender und ausgehender Gatewaythreads für jeden Postfachspeicher im Exchange-Informationsspeicherprozess erhöhen. Verwenden Sie dazu in der Registrierung unter HKEY_LOCAL_MACHINE \System\CurrentControlSet \Services\MSExchangeIS\<Servername>\Private-<Datenbank-GUID> die Parameter Gateway In Threads und Gateway Out Threads, wie bereits in diesem Kapitel erläutert.
443
Auswirkungen auf die RPC-LeistungSie müssen sicherstellen, dass für den Bridgeheadserver keine Probleme mit der RPC-Kommunikation bestehen. So sollten beispielsweise in der Routinggruppe des Bridgeheadservers keine Server unter Exchange Server 5.5 vorhanden sein, die häufig nicht betriebsbereit sind. Da die RPC-Kommunikation synchron erfolgt, muss der MTA stets bis zum Ablauf eines Zeitlimits warten, bevor er andere ausgehende Verbindungen bedienen kann, die Vorrang vor eingehenden Verbindungen haben. Deshalb können RPC-Kommunikationsprobleme die Leistung des gesamten MTA beeinträchtigen, einschließlich aller X.400-Connectors. Dagegen stellen X.400-Connectors asynchrone Verbindungen her, die nur geringe oder keine Auswirkungen auf andere Connectors haben.
Hinweis: Zum Übertragen von Nachrichten in den und aus dem Exchange-Informationsspeicher verwendet der MTA RPCs. Die RPC-Kommunikation sollte jedoch während des normalen Serverbetriebs weder Probleme bereiten noch die Serverleistung beeinträchtigen.
RPC-Bindback-FehlerDas Herstellen einer RPC-Verbindung ist ein Bind- und-Bindback-Vorgang, bei dem sich der lokale MTA zunächst vergewissert, mit dem Remote-MTA zu kommunizieren (der Name und das Kennwort des Remote-MTA werden überprüft). Danach bestätigt der Remote-MTA die Identität des lokalen MTA (der Name und das Kennwort des lokalen MTA werden zurückgesendet und überprüft). Ein Exchange-MTA protokolliert RPC-Bindback-Fehler, wenn RPC-Verbindungen mit einem Remote-MTA hergestellt werden, der den vollqualifizierten Domänennamen des lokalen MTA nicht auflösen kann. Wenn der Remote-MTA versucht, mithilfe der bereitgestellten Verbindungszeichenfolge ein Bindback durchzuführen, und der vollqualifizierte Domänenname nicht aufgelöst werden kann, so treten Fehler beim Bindback-Vorgang auf, und im Ereignisprotokoll wird der folgende Fehler protokolliert.
Event ID: 9322
Source: MSExchangeMTA
Description: An interface error has occurred. An MtaBindBack over RPC has failed.
Locality Table (LTAB) index: %1, NT/MTA error code:1722. Comms error %3, Bind error
%4,Remote Server Name %5, Protocol String IP Address of Server.
Wenn ein Fehler beim Bindback-Vorgang auftritt, erhält der Server, von dem der Vorgang ausgeht, keine Antwort vom Remotesystem. Schließlich tritt in der RPC-Laufzeitbibliothek eine Zeitüberschreitung auf, und im Ereignisprotokoll wird der folgende Fehler protokolliert:
Event ID: 9318
Source: MSExchangeMTA - Interface
444
Description: An RPC communications error occurred. Unable to bind over RPC. Locality
Table (LTAB) index: 151, NT/MTA error code: 1722. Comms error 1722, Bind error 1722,
Remote Server Name SERVERNAME [MAIN BASE 1 500 %10] (14)
Um dieses Problem zu lösen, stellen Sie sicher, dass beide MTAs die vollqualifizierten Domänennamen des jeweils anderen in IP-Adressen auflösen können.
Gateway-AdressroutingtabelleZum Ausführen des Nachrichtenroutings verwenden Server mit Exchange Server 5.5 die Gateway-Adressroutingtabelle (GWART) und Server mit Exchange Server 2003 die Verbindungsstatusinformationen. In einer Organisation im gemischten Modus repliziert der Standortreplikationsdienst die Exchange Server 5.5-Verzeichnisinformationen mithilfe von Active Directory. Daher finden Server mit Exchange Server 2003 alle Connectors in der Konfigurationsverzeichnispartition. Das Routingmodul kann deshalb Connectors in die Verbindungsstatustabelle aufnehmen, die auf Exchange Server 5.5-Servern installiert sind. Dies ermöglicht Exchange Server 2003-Benutzern die Verwendung von Connectors, die in Exchange Server 2003 nicht zur Verfügung stehen, z. B. Connector für Lotus cc:Mails, Connector für PROFS (Professional Office System) oder Connector für SNADS (SNA Distribution System).
Damit Server unter Exchange Server 5.5 Connectors auf Exchange Server 2003-Servern verwenden können, wird eine Gateway-Adressroutingtabelle erstellt, die alle Connectorinformationen enthält. Benutzer von Exchange Server 5.5 können dann Nachrichten an Internetbenutzer über SMTP-Connectors senden, die unter Exchange Server 2003 installiert sind. Dies ist von Vorteil, da alle Exchange-Benutzer von den Spam- und Verbindungsfilterfunktionen in Exchange Server 2003 profitieren können.
Für die Abwärtskompabilität erstellt ein Exchange Server 2003-MTA die Gateway-Adressroutingtabelle und kommuniziert über ADSI (Active Directory Services Interface) mit Active Directory, um Einträge im GWART-Objekt vorzunehmen. Der MTA schreibt die Routinginformationen in binärer Form in das Attribut gatewayRoutingTree und aktualisiert das Attribut gWartLastModified des Verzeichnisobjekts, um die letzte Aktualisierung der GWART anzugeben. Das GWART-Objekt befindet sich in der administrativen Gruppe des Servers, auf dem Exchange Server ausgeführt wird. Der Standortreplikationsdienst repliziert das GWART-Objekt in das Exchange Server 5.5-Verzeichnis, und Exchange Server 5.5 repliziert die GWART auf alle Server unter Exchange Server 5.5, sodass diese Server Exchange Server 2003-Connectors in ihre Routingentscheidungen integrieren können.
Mit dem folgenden Befehl können Sie alle GWART-Objekte einer Exchange-Organisation exportieren: ldifde -f c:\GWART.ldf -s localhost -d " CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com" -p
subtree -r "(objectClass=siteAddressing)".
In Tabelle 7.12 sind die wichtigen Attribute des GWART-Verzeichnisobjekts beschrieben.
445
Important attributes of GWART object
Attribut Beschreibung
objectClass Identifiziert das Verzeichnisobjekt als GWART-Objekt, das auf der Objektklasse siteAddressing basiert.
gatewayRoutingTree Enthält die Routingtabelle in dem Format, das von Exchange Server 5.5-MTAs benötigt wird.
gWARTLastModified Gibt Datum und Uhrzeit der letzten Aktualisierung des GWART-Objekts an.
ridServer Verweist auf den Server, der die GWART für diese administrative Gruppe verwaltet.
Nachrichtenschleifen zwischen Exchange Server 5.5- und Exchange Server 2003-ServernIn einer Exchange-Organisation im gemischten Modus sollten Sie keine Server unter Exchange Server 2003 als Aufgliederungsserver für Verteilerlisten festlegen, die Exchange Server 5.5-Benutzer enthalten. Wenn ein Exchange Server 5.5-Benutzer eine Nachricht an eine solche Verteilerliste sendet, leitet der Exchange Server 5.5-MTA die Nachricht korrekt an den Exchange Server 2003-Aufgliederungsserver weiter. In Exchange Server 2003 ist die Aufgliederung von Verteilerlisten Aufgabe des Kategorisierungsmoduls im SMTP-Dienst. Das SMTP-Transportsubsystem fügt dem P1-Nachrichtenübertragungsumschlag jedoch keine Ablaufverfolgungsinformationen hinzu, um zu kennzeichnen, dass für die Nachricht die Verteilerliste aufgegliedert wurde. Nach der Aufgliederung der Verteilerliste leitet Exchange Server 2003 die Nachricht für alle Exchange Server 5.5-Empfänger an Exchange Server 5.5 zurück. Wenn eine Nachricht erneut zu einem Exchange Server 5.5-Server gelangt, der die Nachricht bereits verarbeitet hat, wird die Nachricht gelöscht und ein Unzustellbarkeitbericht erstellt. Dazu kommt es, weil eine Nachrichtenschleife festgestellt wird. SMTP kann die X.400-Ablaufverfolgungsinformationen nicht auswerten, und der X.400-basierte Exchange Server 5.5-MTA muss die Nachricht löschen, da die Ablaufverfolgungsinformationen im P1-Umschlag nicht anzeigen, dass es sich um eine Nachricht handelt, deren Verteilerliste aufgegliedert wurde. Um dieses Problem zu vermeiden, sollten für Verteilerlisten mit Exchange Server 5.5-Benutzern nur Server als Aufgliederungsserver eingesetzt werden, auf denen Exchange Server 5.5 ausgeführt wird.
446
Architektur von Gateway-Messaging-ConnectorsIn Microsoft Exchange Server 2003 gibt es zwei Messaging-Connectortypen: systemeigene Connectors und Gatewayconnectors. Zu den systemeigenen Connectors gehören der Routinggruppenconnector (in Exchange Server 5.5 ist dies der Standortconnector), der SMTP-Connector und der X.400-Connector. Exchange-Routinggruppen können mit diesen Connectors verbunden werden. Da der SMTP-Connector und der X.400-Connector Standardprotokolle verwenden (SMTP und X.400), können diese systemeigenen Connectors auch als Gatewayconnectors zu anderen Messagingsystemen verwendet werden.
Gatewayconnectors verwenden i. d. R. nicht standardisierte Protokolle und proprietäre APIs für Verbindungen zwischen Exchange und anderen Messagingsystemen, z. B. Novell GroupWise oder Lotus Notes. Die in Exchange Server 2003 enthaltenen Gatewayconnectors (Exchange Connector für Novell GroupWise und Exchange Connector für Lotus Notes) unterstützen Verzeichnissynchronisierung und Nachrichtenkonvertierung. Dies sind aber nicht die einzigen verfügbaren Gatewayconnectors. Herstellern von Messagingsystemen steht das Exchange Development Kit (EDK) zur Entwicklung eigener, proprietärer Gatewayconnectors zur Verfügung. Mit dem EDK entwickelte Gatewayconnectors basieren auf MAPI. Aus diesem Grund werden Gatewayconnectors in diesem Abschnitt als MAPI-Connectors bezeichnet.
Folgende Themen werden in diesem Abschnitt behandelt:
Allgemeine EDK-Connectorarchitektur Alle MAPI-Connectors haben einige gemeinsame Merkmale. Gute Kenntnisse der EDK-Connectorarchitektur sind unerlässlich, um beurteilen zu können, wie Microsoft-Connectors und Connectors anderer Hersteller in Exchange Server 2003 integriert werden. Ausführliche Informationen zum Programmieren von MAPI-Connectors finden Sie unter Exchange 2000 Sample Gateway .
Architektur des Connectors für Lotus Notes Dieser MAPI-Connector enthält Komponenten, die für die Kommunikation mit Lotus Notes erforderlich sind. Sie sollten Kenntnisse über die Zusammenarbeit dieser Komponenten haben, um die Nachrichtenübertragung und die Verzeichnissynchronisierung zwischen Exchange Server 2003 und Lotus Notes verstehen zu können.
Architektur des Connectors für Novell GroupWise Dieser MAPI-Connector enthält Komponenten, die für die Kommunikation mit Novell GroupWise erforderlich sind. Sie sollten Kenntnisse über die Zusammenarbeit dieser Komponenten haben, um die Nachrichtenübertragung und die Verzeichnissynchronisierung zwischen Exchange Server 2003 und Novell GroupWise verstehen zu können.
Architektur des Kalender-Connectors Der Kalender-Connector von Microsoft Exchange Server 2003 überträgt nicht wie andere Connectors Nachrichten. Stattdessen ermöglicht er Benutzern von Exchange Server 2003 und Lotus Notes oder
447
Novell GroupWise Zugriffe in nahezu Echtzeit auf die Frei-/Gebucht-Kalenderinformationen anderer Benutzer. Wenn Sie die Frei-/Gebucht-Informationen aus Exchange mit anderen Programmen synchronisieren möchten, müssen Sie verstehen, wie die Komponenten des Kalender-Connectors mit den Connectors für Lotus Notes und Novell GroupWise zusammenarbeiten.
In diesem Abschnitt wird die Architektur der MAPI-Connectors in Exchange Server 2003 erläutert. MAPI-Connectors werden ausschließlich zum Verbinden einer Exchange-Organisation mit einem anderen Messagingsystem wie Lotus Notes oder Novell GroupWise verwendet. Es wird davon ausgegangen, dass Sie mit der Konfiguration von Connectorkomponenten im Exchange-System-Manager vertraut sind. Weitere Informationen zum Verbinden anderer Messagingsysteme mit Exchange Server 2003 und das Migrieren zu Exchange Server 2003 finden Sie unter Exchange Server 2003 Interoperability and Migration Guide.
EDK-ConnectorarchitekturFür eine reibungslose Zusammenarbeit zwischen Exchange-Benutzern und Benutzern anderer Systeme müssen die Connectors zu diesen anderen Messagingsystemen die folgenden Schlüsselaufgaben übernehmen:
Bidirektionale Nachrichtenübertragung Die Übertragung von E-Mail-Nachrichten ist die wichtigste Aufgabe der Connectors. MAPI-Connectors führen in Exchange-Organisationen jedoch kein Nachrichtenrouting durch. MAPI-Connectors erhalten ausgehende Nachrichten von einem speziellen Exchange-Bridgeheadserver und übertragen eingehende Nachrichten ebenfalls an diesen Bridgeheadserver. Nachrichtenrouting und -übermittlung werden hierbei vom SMTP-Transportsubsystem durchgeführt. Ausführliche Informationen zur Exchange Server 2003-Nachrichtenverarbeitung finden Sie unter Nachrichtenroutingarchitektur.
Wie Übermittlung und Nachrichtenabruf außerhalb von Exchange bei Übertragungen zu und von einem anderen System durchgeführt werden, ist abhängig von den Funktionen und Schnittstellen des jeweils beteiligten Messagingsystems. Üblicherweise wird auf dieser Seite der Übertragung nur ein einzelner Kontaktpunkt verwendet. Der Connector für Lotus Notes beispielsweise stellt nur Verbindungen zu einem einzelnen Lotus Domino-Server her. Der Server des Messagingsystems ist dann selbst für die Weiterleitung der Nachrichten bis zu ihrem endgültigen Ziel verantwortlich.
Die folgende Abbildung bietet eine allgemeine Übersicht der Schritte, die ein MAPI-Connector ausführen muss, um die Übertragung eingehender und ausgehender Nachrichten zu gewährleisten.
448
Nachrichtenübertragung über einen MAPI-Connector
Die Nachrichtenübertragung von und zu anderen Messagingsystemen umfasst die folgenden Schritte:
a. Die Nachrichtenübertragung beginnt mit dem Abrufen der Nachrichten aus dem Quellsystem. MAPI-Connectors verwenden MAPI zum Abrufen der Nachrichten aus Exchange. Das zweite beteiligte Messagingsystem stellt ebenfalls eigene Programmierschnittstellen zum Abrufen der Nachrichten bereit, z. B. die Lotus Notes-Client-API oder den Novell GroupWise-API-Gateway.
b. Im nächsten Schritt der Nachrichtenübertragung werden die Nachrichten in das Format des Zielsystems konvertiert. Zu diesem Schritt gehören das Zuordnen von Adressen und das Übersetzen aus dem MAPI-Nachrichtenformat in andere Formate und umgekehrt.
c. Im letzten Schritt werden die konvertierten Nachrichten an das Zielsystem übertragen. Dabei verwenden EDK-Connectors erneut MAPI zur Übertragung der Nachrichten an den Exchange-Informationsspeicher. Auch in diesem Schritt stellt das zweite Messagingsystem eine eigene, proprietäre Schnittstelle, z. B. die Lotus Notes-Client-API oder den Novell GroupWise-API-Gateway, für die Übertragung bereit.
Verzeichnissynchronisierung Die zweite wichtige Aufgabe eines MAPI-Connectors ist das Durchführen einer Verzeichnissynchronisierung. Die Verzeichnissynchronisierung ist zwar nicht erforderlich, aber sehr hilfreich, da sie allen Benutzern den Zugriff auf vollständige Adresslisten aller Empfänger in Exchange und anderen Messagingumgebungen ermöglicht. In Exchange Server 2003 befinden sich die Verzeichnisinformationen im Microsoft® Active Directory®-Verzeichnisdienst. Die Verzeichnissynchronisierung wird mithilfe von LDAP (Lightweight Directory Access Protocol) und ADSI (Active Directory Service Interfaces) durchgeführt.
Ausführen von Supportfunktionen Nachrichtenübertragung und Verzeichnissynchronisierung sind die wichtigsten Aufgaben eines MAPI-Connectors. Zusätzlich sollten aber auch Supportfunktionen zur optimalen Integration in Exchange Server 2003 implementiert werden. Die folgenden Supportfunktionen sollten unterstützt werden:
449
Leistungsüberwachung MAPI-Connectors bieten Leistungsindikatoren, mit denen Administratoren Leistungsüberwachungsberichte erstellen können. Leistungsberichte werden mit dem Tool Systemmonitor erstellt, das sich im Startmenü unter Verwaltung befindet.
Ereignisprotokollierung MAPI-Connectors verfolgen wichtige Ereignisse (z. B. den Start oder das Beenden des Connector-Diensts oder das Konvertieren und Übertragen von Nachrichten) entsprechend den verschiedenen Diagnoseebenen im Ereignisprotokoll der Anwendung. Administratoren können mit dem Tool Ereignisanzeige unter Verwaltung überprüfen, ob der Connector fehlerfrei funktioniert. Das Ereignisprotokoll der Anwendung ist eine wichtige Informationsquelle für das Beheben von Problemen bei der Nachrichtenübertragung.
Fehlerbehandlung MAPI-Connectors senden Benachrichtigungen über den Übermittlungsstatus an den Absender einer Nachricht, wenn bei der Übertragung Probleme aufgetreten sind. Ein Connector sendet beispielsweise eine Unzustellbarkeitsbericht an den Absender der Nachricht, wenn der Connector einen Empfänger aufgrund einer fehlerhaften Adresse nicht ermitteln konnte.
Nachrichtenverfolgung MAPI-Connectors erfassen Informationen zu Nachrichten, die über den Connector weitergeleitet werden, in den Nachrichtenverfolgungsprotokollen von Exchange Server 2003, sodass ein Administrator den vollständigen Pfad der Nachricht vom Server des Absenders bis zum Verlassen der Exchange-Organisation analysieren kann. Bei eingehenden Nachrichten beginnt die Nachrichtenverfolgung, sobald die Nachrichten den MAPI-Connector erreichen und in die Exchange-Organisation übernommen werden. Die Nachrichtenverfolgung ist in der Standardeinstellung deaktiviert. Sie müssen diese Funktion auf allen Servern aktivieren, auf denen Sie die Nachrichtenübertragung verfolgen möchten, oder alternativ eine entsprechende Serverrichtlinie verwenden. Klicken Sie im Exchange-System-Manager im Dialogfeld Eigenschaften für den Server oder die Serverrichtlinie auf die Registerkarte Allgemein, und aktivieren Sie dann das Kontrollkästchen Nachrichtenverfolgung aktivieren.
ConnectorkomponentenMAPI-Connectors enthalten eine Vielzahl von Komponenten für eine nahtlose Integration in Exchange Server 2003. Dazu gehören Konfigurationsobjekte in Active Directory mit connectorspezifischen Einstellungen sowie die eigentlichen Connectoranwendungen für Nachrichtenkonvertierung und -übertragung. MAPI-Connectors bieten außerdem MMC-Snap-Ins (Microsoft Management Console) zur Integration in den Exchange-System-Manager, sodass Sie die Systemkonfiguration über eine einheitliche Oberfläche vornehmen können.
MAPI-Connectors enthalten die folgenden Komponenten:
Connector-Dienst Normalerweise werden MAPI-Connectors als Microsoft Windows®-Dienste implementiert, die direkt auf dem Exchange Server 2003-Bridgeheadserver
450
ausgeführt werden. Sie werden daher automatisch mit dem Server gestartet und in einem eigenen Sicherheitskontext ausgeführt. In Exchange Server 2003 verwenden alle Dienste, einschließlich der Dienste für MAPI-Connectors, das Konto LocalSystem. Weitere Informationen hierzu finden Sie unter Dienstabhängigkeiten in Exchange Server 2003 .
Hinweis: Connectorkomponenten können direkt auf einem Server mit Exchange Server 2003 ausgeführt werden oder auf einem separaten Computer, der über das Netzwerk mit Exchange Server 2003 kommuniziert. Auf das zweite Messagingsystem wird i. d. R. über das Computernetzwerk zugegriffen. Gegebenenfalls kann die Connectorleistung gesteigert werden, wenn das zweite Messagingsystem auf demselben Computer wie der Connectorserver ausgeführt wird. Sie können z. B. Exchange Server 2003 und Lotus Domino auf demselben Server ausführen.
Konvertierungs-DLLs MAPI-Connectors können für die Nachrichtenübersetzung Konvertierungs-DLLs im Exchange Server 2003-Framework registrieren, sodass der entsprechende Übersetzungscode aufgerufen wird, wenn der Connector eingehende oder ausgehende Nachrichten konvertiert. Diese DLLs müssen in der Registrierung im Schlüssel HKEY_LOCAL_MACHINE\Software\Classes\MAPI Conversions registriert werden. Für jede Konvertierungs-DLL muss ein eigener Unterschlüssel definiert sein. Der Name des DLL-Unterschlüssels muss dem Namen der DLL-Datei entsprechen. Die DLLs müssen auf dem Bridgeheadserver im Verzeichnis \System32 installiert werden. Jeder DLL-Schlüssel enthält einen Unterschlüssel für jeden Einstiegspunkt in einer Konvertierungs-DLL, die das Konvertierungsmodul für die Konvertierungen verwendet.
Hinweis: Konvertierungs-DLLs sind optionale Komponenten. Der Code für Nachrichtenkonvertierungen kann auch direkt in einen MAPI-Connector integriert werden. In diesem Fall werden keine Konvertierungs-DLLs verwendet. Beispielsweise benötigen der Connector für Lotus Notes und der Connector für Novell GroupWise keine zusätzlichen Konvertierungs-DLLs. Der Mechanismus, mit dem diese Connectors die Nachrichtenkonvertierung durchführen, wird in Abschnitten weiter unten beschrieben.
DLL für die Proxyadressgenerierung Proxyadressen sind Nicht-Exchange-Adressen, die der Empfängeraktualisierungsdienst den Exchange-Empfängerobjekten in Active Directory zuweist. So können Benutzer, die Exchange nicht verwenden, E-Mail-Nachrichten an Exchange-Benutzer senden und von diesen empfangen. Für den Exchange-Benutzer Ted Bremer könnte z. B. die NOTES-Proxy-E-Mail-Adresse Ted@Exchange festgelegt werden. Lotus Notes-Benutzer können Ted Bremer über diese E-Mail-Adresse Nachrichten senden. In einer Lotus Notes-Umgebung wird Ted Bremer als Benutzer der Lotus Notes-Domäne Exchange angezeigt, die mit dem Connector für Lotus Notes verknüpft ist. Auf diese Weise leitet Lotus Notes alle
451
Nachrichten an Ted@Exchange an den Connector für Lotus Notes weiter. Wenn der Connector für Lotus Notes die Nachricht empfängt, führt er eine Adressübersetzung durch und ersetzt die Lotus Notes-(Proxy)-Adresse des Exchange-Benutzers durch die tatsächliche Exchange-Adresse (die X.500-Adresse des Benutzers, die im legacyExchangeDN-Attribut angegeben ist). Entsprechend ersetzt der Connector für Lotus Notes die Exchange-Adressinformationen von Ted Bremer bei allen ausgehenden Nachrichten an Lotus Notes durch die Lotus Notes-Proxyadressinformationen. Das systemeigene Adressformat von Exchange Server 2003 ist SMTP.
Hinweis: Exchange-Benutzer werden in anderen Messagingsystemen i. d. R. als reguläre Empfänger innerhalb des jeweiligen Messagingsystems angezeigt.
Damit der Empfängeraktualisierungsdienst Proxyadressen im richtigen Format generieren kann, müssen MAPI-Connectors eine entsprechende DLL für die Proxyadressgenerierung auf dem Server mit Exchange Server 2003 installieren. Dieses Unterverzeichnis ist für den Netzwerkzugriff freigegeben (Freigabename: \\<Servername>\Address), damit der Empfängeraktualisierungsdienst auch dann auf die DLLs zugreifen kann, wenn der Messaging-Connector auf einem anderen Server mit Exchange Server installiert ist. Weitere Informationen zum Empfängeraktualisierungsdienst finden Sie unter Exchange Server 2003 und Active Directory .
Die folgende Abbildung zeigt ein Beispiel für Proxyadressen, die der Empfängeraktualisierungsdienst einem Exchange-Benutzer zugewiesen hat.
452
Proxyadressen für einen Exchange-Benutzer
Benutzer können über primäre und sekundäre Proxyadressen verfügen. Die Abbildung zeigt z. B. eine sekundäre Lotus Notes-Proxyadresse für Ted Bremer. Die primäre Proxyadresse wird als Absenderadresse in allen ausgehenden Nachrichten an andere Messagingsysteme verwendet. Die sekundären Proxyadressen werden für die Übertragung eingehender Nachrichten an den richtigen Empfänger in Exchange Server 2003 verwendet, sofern die Nachrichten nicht direkt an die primäre Proxyadresse adressiert sind. In diesem Beispiel kann Ted Bremer auch Lotus Notes-Nachrichten an Ted@Contoso empfangen, da dies seine sekundäre NOTES-Proxyadresse ist.
Hinweis: Proxyadressen für Exchange-Benutzer können Sie im Exchange-System-Manager in den Empfängerrichtlinien festlegen. Jeder Exchange-Benutzer besitzt nur eine primäre Proxyadresse pro Adresstyp, er kann aber über mehrere sekundäre Adressen verfügen. Alle Proxyadressen (primäre und sekundäre)
453
müssen innerhalb der Exchange-Organisation eindeutig sein. Es kann z. B. keine zwei Exchange-Empfänger mit der NOTES-Proxyadresse Ted@Contoso geben.
addrType-Objekt Durch das Speichern einer DLL für die Proxyadressgenerierung in einem Unterverzeichnis von \Programme\Exchsrvr\Address auf einem Server mit Exchange Server 2003 wird der Empfängeraktualisierungsdienst noch nicht veranlasst, Proxyadressen für einen bestimmten Adresstyp zu generieren. Zum Aktivieren eines Adresstyps muss der Connector den unterstützten Adresstyp zusätzlich in einem addrType-Objekt in Active Directory registrieren. Alle addrType-Objekte befinden sich auf der Konfigurationsverzeichnispartition von Active Directory im Container für Adresstypen. Den Inhalt dieses Containers können Sie mit dem Tool ADSI-Bearbeitung anzeigen. Sie können diesen Container auch in Active Directory-Standorte und -Dienste anzeigen, wenn Sie im Menü Ansicht die Option Dienstknoten anzeigen aktivieren. Der Pfad zum Container für Adresstypen lautet: \Dienste\Microsoft Exchange\<Name der Exchange-Organisation>\Addressing\Address-Types. In der Standardkonfiguration sind addrType-Objekte für CCMAIL, GWISE, MS, NOTES, SMTP und X400 definiert.
Die folgende Tabelle enthält wichtige Attribute von addrType-Objekten.
Attribute von addrType-Objekten
Attribute Beschreibung
Common-Name Der allgemeine Name des Adresstyps, der zum Erstellen des DN (Distinguished Name) des Objekts in Active Directory verwendet wird.
File-Version Die Versionsnummer der DLL-Datei für die Proxyadressgenerierung.
proxyGeneratorDLL Der Name der DLL für die Proxyadressgenerierung für diesen Adresstyp. Beim addrType-Objekt mit dem allgemeinen Namen NOTES:i386 wird in diesem Attribut z. B. als DLL für die Proxyadressgenerierung Ntspxgen.dll angegeben.
name Der Name des Adresstyps, z. B. NOTES:i386.
Adressvorlagen Zusätzlich zum addrType-Objekt können MAPI-Connectors auch Adress- und Optionsvorlagen installieren, um eine benutzerfreundliche Oberfläche bereitzustellen, über die benutzerdefinierte Empfänger für andere Messagingsysteme erstellt werden können. Diese Vorlagen beschreiben die Einstellungen in einem Dialogfeld, über die benutzerdefinierte Adressen eingegeben werden können.
454
Adressvorlagen verwenden ein Adresssyntaxprogramm, um die vom Benutzer eingegebenen Daten in eine Zeichenfolge für die Proxyadresse zu konvertieren. Sie können die Adressvorlagen im Exchange-System-Manager anpassen (unter Empfänger im Container Adressvorlagen).
Hinweis: Adressvorlagen und Adresssyntaxprogramme sind optionale Connectorkomponenten. Connector für Lotus Notes und Connector für Novell GroupWise installieren diese Komponenten nicht.
msExchConnector-Objekt Wichtiger als die Adressvorlagen ist das eigentliche Connectorobjekt, das für jeden MAPI-Connector in Active Directory vorhanden sein muss. Beim Starten des Servers durchläuft und liest das Routingmodul alle msExchConnector-Objekte aller Routinggruppen, um die Verbindungsstatustabelle zu initialisieren. Dies wird unter Nachrichtenroutingarchitektur erläutert.
Sie finden die Connectorobjekte im Exchange-System-Manager im Container Connectors unter ihren entsprechenden Routinggruppen. Zum Konfigurieren der Einstellungen des msExchConnector-Objekts ist ein entsprechendes Verwaltungs-Snap-In erforderlich. Die Einstellungen umfassen spezielle Attribute für den jeweiligen Connectortyp sowie allgemeine Attribute.
Hinweis: Außer im msExchConnector-Objekt in Active Directory können die Konfigurationsinformationen auch in der Registrierungsdatenbank auf dem Bridgeheadserver gespeichert werden.
Die folgende Tabelle enthält wichtige allgemeine Attribute, über die alle MAPI-Connectors verfügen.
Wichtige allgemeine Attribute von msExchConnector-Objekten
Attribute Beschreibung
Common name Gibt den Namen des Connectorobjekts in Active Directory relativ zu seinem übergeordneten Container an.
455
Attribute Beschreibung
computerName Verweist auf den Bridgeheadserver, auf dem der MAPI-Connector ausgeführt wird. Dieses Attribut muss genau mit dem NetBIOS-Namen (Network Basic Input/Output System) des Bridgeheadservers übereinstimmen, andernfalls werden die Nachrichtenwarteschlangen des Connectors nicht im Snap-In für die Warteschlangenanzeige im Exchange-System-Manager angezeigt.
deliveryMechanism Gibt den Übermittlungsmechanismus an, der von Exchange Server 2003 für das Weiterleiten von Nachrichten an den MAPI-Connector verwendet wird.
distinguishedName Gibt den DN (Distinguished Name) des Connectorobjekts in Active Directory an.
homeMDB Gibt den privaten Informationsspeicher mit dem Connector-Postfach an.
homeMTA Gibt den Exchange-MTA an, der für das Nachrichtenrouting an den MAPI-Connector verantwortlich ist.
legacyExchangeDN Gibt den DN (Distinguished Name) des Connectorobjekts im früheren Verzeichnisformat von Exchange Server 5.5 an. Dieses Attribut des Connectorobjekts muss festgelegt werden, damit das Snap-In für die Warteschlangenanzeige funktioniert.
msExchConnectorType Gibt den Connectortyp an. Der Connectortyp für den Connector für Lotus Notes ist z. B. NOTES, und der Connectortyp für den Connector für Novell GroupWise ist GWISE.
name Gibt den Namen des Connectorobjekts an. Der Exchange-System-Manager verwendet diesen Namen als Anzeigenamen für das Connectorobjekt.
456
Attribute Beschreibung
objectClass Identifiziert den Connector als msExchConnector und als mailGateway. Außerdem wird eine spezifische Objektklasse registriert, um den tatsächlichen Typ des Connectors zu identifizieren. msExchNotesConnector ist z. B. die Objektklasse für den Connector für Lotus Notes, und msExchGroupWiseConnector ist die Objektklasse des Gatewayobjekts für den Connector für Novell GroupWise.
Hinweis: Zur Unterstützung von connectorspezifischen Attributen müssen MAPI-Connectors, die nicht von Microsoft stammen, das Schema von Active Directory erweitern, um eine neue Objektklasse zu erstellen. MAPI-Connectors sollten in Active Directory als Objekte einer Klasse dargestellt werden, die von der mailGateway-Klasse erbt. Das mailGateway-Objekt ist wiederum eine untergeordnete Klasse von msExchConnector.
routingList Gibt die Adressräume an, die diesem Connector zugeordnet sind. Jedem Connector ist mindestens ein Adressraum zugeordnet. Das Routingmodul ermittelt anhand dieser Informationen mögliche Connectors für eine bestimmte Nachricht, indem es die Empfängeradressen mit den verfügbaren Informationen über Adressräume vergleicht.
Verwaltungs-Snap-In MAPI-Connectors sollten im Exchange-System-Manager ein MMC-Erweiterungs-Snap-In hinzufügen und registrieren, damit Exchange-Administratoren über eine benutzerfreundliche Oberfläche das msExchConnector-Objekt des Connectors in Active Directory (und mögliche Registrierungseinstellungen)
457
konfigurieren können. Der Connector für Lotus Notes enthält z. B. das Exchange Notes Connector-Snap-In und der Connector für Novell GroupWise das Exchange GroupWise-Connector-Snap-In. Beide Snap-Ins sind in der Datei Exadmin.dll implementiert. Dies wird unter Architektur des Exchange-System-Managers beschrieben.
Connector-Postfach Wenn für einen MAPI-Connector ein msExchConnector-Objekt in Active Directory erstellt wird, erstellt Exchange Server 2003 ein spezielles Postfach für den Connector in dem Postfachspeicher, der im homeMDB-Attribut des msExchConnector-Objekts angegeben ist. Der Exchange-Informationsspeicher erstellt dieses Postfach auf dem Bridgeheadserver, sobald der Connector-Dienst zum ersten Mal gestartet wird oder die erste Nachricht an den Connector weitergeleitet wird. Das Postfach enthält Warteschlangen für eingehende und ausgehende Nachrichten des MAPI-Connectors mit den Bezeichnungen MTS-IN und MTS-OUT sowie möglicherweise weitere Ordner mit den Bezeichnungen Badmail, ReadyIn und ReadyOut, Deferred Action, Spooler Queue und Temp, die der Connector während der Nachrichtenverarbeitung verwendet. Der Connector für Lotus Notes und der Connector für Novell GroupWise speichern fehlerhafte Nachrichten im Ordner Badmail. Ob weitere Ordner neben MTS-IN und MTS-OUT verwendet werden, ist von der entsprechenden Connectorimplementierung abhängig.
Hinweis: Jedes Connector-Postfach muss mindestens über die Ordner MTS-IN und MTS-OUT verfügen.
Nachrichtenübertragung zu und von Exchange Server 2003Prozesse, die mit anderen Messagingsystemen kommunizieren, sind immer auf den speziellen Connectortyp abgestimmt. Im Gegensatz hierzu verwenden alle EDK-Connectors MAPI für den Zugriff auf ihre Connector-Postfächer im Exchange-Informationsspeicher. Wie in der folgenden Abbildung dargestellt, platziert der Exchange-MTA (Message Transfer Agent) Nachrichten an andere Messagingsysteme im Ordner MTS-OUT, und der MAPI-Connector platziert eingehende Nachrichten, die er von anderen Messagingsystemen empfangen und konvertiert hat, im Ordner MTS-IN. Der Exchange-MTA wird unter X.400-Transportarchitektur ausführlich beschrieben.
Hinweis: Da die Nachrichtenwarteschlangen des Connectors immer verfügbar sind, werden MAPI-Connectors in der Verbindungsstatustabelle immer mit dem Status STATE_UP angegeben. Daher sendet der Exchange-MTA fortwährend Nachrichten an den MAPI-Connector, auch wenn der Connector-Dienst nicht ausgeführt wird. Aus diesem Grund können sich unzählige Nachrichten in der Warteschlange MTS-OUT ansammeln.
458
Connector-Warteschlangen im Exchange-Informationsspeicher
Übertragung ausgehender NachrichtenExchange Server 2003 führt die folgenden Schritte aus, um Nachrichten an ein anderes Messagingsystem zu übertragen:
1. Ein Exchange-Benutzer sendet eine Nachricht an einen Benutzer in einem anderen System. Die Nachricht wird für Routing und Übertragung an den SMTP-Dienst weitergeleitet.
2. Der SMTP-Dienst kategorisiert die Nachricht und leitet sie weiter. Dies wird im Dokument Nachrichtenroutingarchitektur beschrieben. Da die Nachricht an einen Benutzer außerhalb von Exchange gerichtet ist, weist das Routingmodul die Nachricht dem Exchange-MTA zu. Der Exchange-MTA ist für MAPI-Connectors zu anderen Messagingsystemen verantwortlich.
3. Der SMTP-Dienst leitet die Nachricht über den Exchange-Informationsspeicher an den Exchange-MTA weiter. Der Exchange-MTA platziert die Nachricht in einer internen Nachrichtenwarteschlange, die der MTA getrennt vom Exchange-Informationsspeicher im Dateisystem verwaltet (\Programme\Exchsrvr\Mtadata).
4. Der Exchange-MTA kommuniziert über MTARoute.dll mit dem Routingmodul im SMTP-Transportsubsystem, um den MAPI-Zielconnector zu bestimmen.
459
5. Das Routingmodul erkennt anhand der Adressräume den MAPI-Connector für den Empfänger und gibt diese Informationen an den Exchange-MTA zurück.
6. Der Exchange-MTA schließt die Nachricht in einen Umschlag für die Nachrichtenübermittlung (Message Transfer Envelope, MTE) ein und sendet sie an den Ordner MTS-OUT des MAPI-Zielconnectors. Der Umschlag für die Nachrichtenübermittlung enthält eine Liste der Empfänger, an die der MAPI-Connector die Nachricht übertragen muss, sowie die ursprüngliche Nachricht als Anlage.
Hinweis: Ein MAPI-Connector erkennt ausgehende Nachrichten im Ordner MTS-OUT, indem regelmäßig das Connector-Postfach abgerufen oder ein Anweisungsereignis vom Exchange-Informationsspeicher abgewartet wird, mit dem eine neue ausgehende Nachricht signalisiert wird.
Übertragung eingehender NachrichtenAuf der Exchange-Seite der Nachrichtenübertragung sind für die Übertragung eingehender Nachrichten weniger Schritte als für ausgehende Nachrichten erforderlich. Wenn ein MAPI-Connector eine eingehende Nachricht im Ordner MTS-IN platziert, leitet der Exchange-MTA die Nachricht direkt an das SMTP-Transportsubsystem weiter, in dem sie einer Kategorie zugeordnet, weitergeleitet und übermittelt wird. Der Exchange-MTA selbst führt kein Nachrichtenrouting durch.
Die Übertragung eingehender Nachrichten erfolgt anhand der folgenden Schritte:
1. Der MAPI-Connector erhält eine Nachricht vom sendenden Messagingsystem, führt die Adressübersetzung für die gewünschten Empfänger durch, konvertiert die Nachricht in das MAPI-Format und platziert die Nachricht dann im Exchange-Informationsspeicher im Ordner MTS-IN.
2. Der Exchange-MTA analysiert eine bestimmte Nachrichteneigenschaft, die nur festgelegt wird, wenn die Nachricht vom SMTP-Dienst kommt. Da diese Kennzeichnung fehlt, erkennt der MTA, dass die Nachricht nicht vom lokalen SMTP-Dienst stammt, sondern dass es sich um eine eingehende Nachricht handelt, für die der Exchange-MTA kein Nachrichtenrouting durchführen muss. Der MTA leitet die Nachricht direkt an den Ordner MTS-OUT des SMTP-Diensts weiter.
3. Der Treiber des Exchange-Informationsspeichers platziert die Nachricht in der Vorübermittlungswarteschlange, und das SMTP-Transportsubsystem ordnet sie einer Kategorie zu, leitet sie weiter und übermittelt die Nachricht. Dies wird in den Dokumenten Nachrichtenroutingarchitektur und SMTP-Transportarchitektur behandelt.
460
MAPI-Profile für MAPI-ConnectorsWie normale MAPI-Clients, z. B. Microsoft Office Outlook®, benötigen auch MAPI-Connectors ein MAPI-Profil für den Zugriff auf ihre Connector-Postfächer. In diesem MAPI-Profil werden die Einstellungen für die Kommunikation zwischen MAPI-Subsystem und Exchange-Informationsspeicher definiert. MAPI-Connectors verwenden die Funktion MAPILogonEx zum dynamischen Erstellen des erforderlichen Profils, ohne dass dafür ein MAPI-Client auf dem Server vorhanden sein muss. Ausführliche Informationen zum dynamischen Erstellen von MAPI-Profilen finden Sie im Microsoft Knowledge Base-Artikel 306962, „How to Create MAPI Profiles Without Installing OutlookHow to Create MAPI Profiles Without Installing Outlook“.
MAPI-Profile werden in der Registrierung unter der Struktur HKEY_USERS gespeichert. Auf einem Bridgeheadserver gibt es eine Reihe von Unterschlüsseln. Diese sind von den Sicherheits-IDs (SID) der System- und Benutzerkonten abhängig, mit denen sich aktive Serverprozesse und Administratoren am System anmelden. In Exchange Server 2003 sollten MAPI-Connectors im Kontext des Kontos LocalSystem ausgeführt werden, das die SID S-1-5-18 aufweist. Sie finden dann das MAPI-Profil eines MAPI-Connectors unter dem folgenden Schlüssel: HKEY_USERS\S-1-5-18\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles. Wenn Sie z. B. den Connector für Novell GroupWise auf dem Bridgeheadserver Server01 installiert und gestartet haben, finden Sie den Unterschlüssel SERVER01-LME-GWISE V5.5 im Schlüssel Profiles.
Sie können das Connectorprofil in den Unterschlüssel des derzeit angemeldeten Administrators kopieren und dann das Connector-Postfach mit einem einfachen MAPI-Tool öffnen. Mdbvu32.exe ist ein solches Tool, das auf der Website Downloads for Exchange Server 2003 zum Download verfügbar ist.
Die mit dem Tool gelieferte Datei Information Store Viewer.doc enthält ausführliche Informationen über das Verwenden von Mdbvu32.exe. Die folgende Abbildung zeigt die Verwendung des Tools Mdbvu32.exe. Alle Systemordner werden im Connector-Postfach angezeigt.
461
Systemordner in einem Connector-Postfach
Ausführliche Anweisungen zum Öffnen eines Connector-Postfachs mit Mdbvu32.exe finden Sie unter Öffnen eines Connector-Postfachs mit „Mdbvu32.exe“.
NachrichtenkonvertierungWenn ein MAPI-Connector eine Nachricht vom Connector-Postfach empfängt, muss er diese vor der Übertragung aus dem MAPI-Format in das Format des Zielsystems konvertieren. Entsprechend muss der Connector eingehende Nachrichten aus dem Format des anderen Messagingsystems in das MAPI-Format konvertieren, bevor er die Nachricht im Ordner MTS-IN ablegt. Die Nachrichtenkonvertierung umfasst die folgenden beiden, unabhängigen Prozesse:
Adressübersetzung Ein MAPI-Connector muss eine Adressübersetzung für den Nachrichtenabsender und alle Empfänger der Nachricht durchführen, damit die Nachricht
462
mit den richtigen Adressinformationen in den unterstützten Formaten an das Zielsystem übertragen wird.
Nachrichtenübersetzung Bei der Nachrichtenübersetzung konvertiert ein Gateway-Connector Nachrichten aus dem MAPI-Nachrichtenformat in das Nachrichtenformat des anderen Systems und umgekehrt. Diese Übersetzung basiert auf den Informationen zur Nachrichtenklasse und erfolgt für ein- und ausgehende Nachrichten.
AdressübersetzungMAPI-Connectors müssen für alle ein- und ausgehenden Nachrichten eine Adressübersetzung durchführen. Die folgenden drei Empfängerlisten sind allen Nachrichten zugeordnet, die ein MAPI-Connector verarbeitet:
Die ursprüngliche Liste der Empfänger Die Liste der Empfänger in der Nachricht selbst enthält alle Empfänger, an die die Nachricht adressiert ist. Die Postfächer dieser Empfänger können sich auf dem lokalen Exchange-Server, auf einem anderen Server in der Exchange-Organisation oder in einem Messagingsystem befinden, das dem Connector nicht zugeordnet ist. In Exchange Server 2003 wird die ursprüngliche Liste der Empfänger vom SMTP-Transportsubsystem verarbeitet. Das gleiche Prinzip gilt für eingehende Nachrichten. Eine Nachricht kann neben Exchange-Benutzern auch Empfänger auf anderen Servern eines anderen Messagingsystems enthalten.
Die Liste der Empfänger, die an den MTA gesendet wird Das SMTP-Transportsubsystem leitet eine Nachricht nur dann an den MTA weiter, wenn diese Empfänger enthält, an die der MTA die Nachricht direkt über Remoteprozeduraufrufe (Remote Procedure Call – RPC), über einen X.400-Connector oder über einen MAPI-Connector übertragen muss. Die vom SMTP-Transportsubsystem an den MTA weitergeleitete Empfängerliste kann alle oder nur einen Teil der Empfänger enthalten. Wenn z. B. ein Benutzer eine Nachricht an einen anderen Benutzer auf demselben Exchange-Server und an einen Lotus Notes-Benutzer sendet, überträgt das SMTP-Transportsubsystem die Nachricht an den Exchange-Benutzer direkt, aber es leitet eine weitere Instanz der Nachricht für den Lotus Notes-Benutzer an den Exchange-MTA weiter.
Die Liste der Empfänger auf dem Umschlag für die Nachrichtenübermittlung Der Exchange-MTA leitet nur die Nachrichten an einen MAPI-Connector weiter, die der Connector übertragen muss. Wenn der Exchange-MTA eine Nachricht an einen MAPI-Connector weiterleitet, erstellt er einen Umschlag für die Nachrichtenübermittlung (Message Transfer Envelope – MTE), an den der MTA die ursprüngliche Nachricht als Anlage anfügt. Der MTE enthält Informationen über die Empfänger, an die der Connector die Nachricht übermitteln muss. Der Exchange-MTA kann eine Nachricht mithilfe mehrerer Connectors übertragen. In diesem Fall ist ein bestimmter Connector nicht für alle Empfänger auf der Liste zuständig, die das SMTP-Transportsubsystem an den MTA weitergeleitet hat.
463
Die folgende Tabelle enthält die Elemente des MTE.
Eigenschaften des Umschlags für die Nachrichtenübermittlung
Eigenschaften Beschreibung
Eigenschaften auf Nachrichtenebene Viele dieser Eigenschaften sind systemeigene MAPI-Eigenschaften, die das Datum und die Zeit, zu der die Nachricht am Connector empfangen wurde, die Eintrags-ID der Nachricht, die Betreff-ID sowie Absender- und Ablaufverfolgungsinformationen angeben.
Die Ablaufverfolgungsinformationen geben den Nachrichtenpfad an. Wenn der Exchange-MTA eine Nachricht weiterleitet, fügt er der Nachricht die Landes-/Regionalkennzahl, die ADMD (Administrative Management Domain) und die PRMD (Private Management Domain) der lokalen Domäne hinzu. Außerdem fügt der MTA Zeitstempel und eine Aktionskennzeichnung hinzu, die angibt, ob die Nachricht erweitert, umgeleitet, per Relay weitergeleitet oder erneut geroutet wurde. Ablaufverfolgungsinformationen sind wichtig, um Übertragungsschleifen zu verhindern.
Eigenschaften auf Empfängerebene Für jeden Empfänger in der MTE-Empfängertabelle geben diese Eigenschaften den Empfängertyp an und ob eine Benachrichtigung zum Übermittlungsstatus für den Empfänger angefordert wurde, ob der MTA für den Absender der Nachricht eine Weiterleitungsadresse für einen Empfänger anfügen soll, ob der Absender für einen Empfänger eine Übertragungsbestätigung fordert sowie Diagnosecodes, die für einen Unzustellbarkeitsbericht (Non-Delivery Report – NDR) verwendet werden können.
464
Eigenschaften Beschreibung
Anlageneigenschaften Diese MAPI-Eigenschaften geben den Typ des angefügten Objekts und Möglichkeiten für den Zugriff auf den Inhalt der Anlage an.
Proxyadressen und EinmaladressenDie Adressübersetzung für Nachrichtenabsender und -empfänger basiert auf Proxyadressen. Alle Exchange-Benutzer benötigen eine Proxyadresse des geforderten Typs, damit der MAPI-Connector Active Directory durchsuchen und die richtige externe Adresse im Nachrichtenumschlag der ausgehenden Nachricht einfügen kann. Bei eingehenden Nachrichten erfolgt die Übersetzung in umgekehrter Richtung.
Wenn keine Adressinformationen für einen externen Absender oder Empfänger in Active Directory vorhanden sind, muss der MAPI-Connector Einmaladressen für diese Benutzer erstellen. Der Begriff „Einmal“ gibt an, dass diese Adressen nur einmal verwendet und nicht dauerhaft gespeichert werden. Einmaladressen werden nur in einer Nachricht verwendet und nicht für spätere Nachrichten beibehalten. Das Format von Einmaladressen ist in MAPI folgendermaßen definiert: Display name[Address type:E-mail address], z. B. Ted Bremer[NOTES:Ted@Exchange]
Einmaladressen können auch zum Kapseln externer Adressen verwendet werden. Wenn ein Benutzer z. B. eine Nachricht an einen Lotus Notes-Benutzer und an einen Benutzer im Internet sendet, ist für den Internetbenutzer i. d. R. kein Empfängerobjekt mit NOTES-Proxyadresse in Active Directory vorhanden. In diesem Fall kann der Connector für Lotus Notes den Internetbenutzer nicht direkt zuordnen und muss die SMTP-Adresse in einer Einmal-NOTES-Adresse kapseln, damit alle Empfänger, die in der ausgehenden Lotus Notes-Nachricht angegeben sind, in einem vom Zielsystem unterstützten Format zur Verfügung stehen.
Probleme bei der AdresszuordnungWenn ein MAPI-Connector die Absender- oder Empfängeradresse nicht zuordnen kann, müssen die folgenden Aktionen durchgeführt werden:
Absenderadresse Wenn der MAPI-Connector die Exchange-Adresse eines Absenders nicht in ein anderes Format als das von Exchange konvertieren kann, muss der Connector einen Unzustellbarkeitsbericht generieren. Der Connector markiert alle Empfänger der Nachricht, für die er zuständig ist, als unzustellbar. Der Grund hierfür ist, dass der Connector keine Antwortadresse für die Nachricht erstellen kann. Der Unzustellbarkeitsbericht wird an den Absender der Nachricht zurückgesendet, um diesen darüber zu informieren, dass kein Empfänger erreicht werden konnte.
465
Empfängeradresse im Zielsystem Wenn der MAPI-Connector die Adresse eines Empfängers, für den der Connector zuständig ist, nicht ermitteln kann, erstellt der Connector einen Unzustellbarkeitsbericht für diesen Empfänger, um den Absender der Nachricht darüber zu informieren, dass die Nachricht nicht an alle gewünschten Empfänger übermittelt wurde.
Empfängeradresse nicht im Zielsystem Wenn der MAPI-Connector die Adresse eines Empfänger, für den der Connector nicht zuständig ist, nicht ermitteln kann (z. B. die eines Empfängers in einem Messagingsystem, das nicht mit diesem Connector verbunden ist), erstellt der Connector keinen Unzustellbarkeitsbericht. Der Connector muss mithilfe der Adresskapselung möglichst viele Adressinformationen beibehalten. Der Connector kann den Empfänger auch aus der Nachricht entfernen oder die Empfängerinformationen in ein reines Textfeld einfügen.
NachrichtenkonvertierungExchange Server 2003 verwendet Nachrichtenklassen zum Definieren der in einer Nachricht enthaltenen Eigenschaften und Arten von Informationen sowie zur Behandlung der Nachricht. Jeder Nachrichtenklasse ist ein Satz von Eigenschaften zugeordnet, und da jede MAPI-Nachrichtenklasse andere Sätze von Eigenschaften unterstützt, müssen für das Konvertieren einer MAPI-Nachricht in das Nachrichtenformat eines anderen Messagingsystems verschiedene Algorithmen verwendet werden. Entsprechend sind bei einem Nachrichtenformat eines anderen Messagingsystems, das ebenfalls eigene Nachrichtenklassen unterstützt, andere Übersetzungsalgorithmen erforderlich.
Für die Behandlung einer Nachrichtenklasse konvertiert der Connector ausgehende Nachrichten in ein geeignetes Format (sofern das andere Messagingsystem über eine ähnliche Nachrichtenklasse verfügt) und eingehende Nachrichten in eine entsprechende MAPI-Nachrichtenklasse. Der Connector generiert außerdem verschiedene REPORT-Nachrichtenklassen, wenn diese für ein- oder ausgehende Nachrichten erforderlich sind. Neben der Behandlung einer Nachrichtenklasse konvertiert der Connector auch Nachrichtenanlagen.
Die folgende Tabelle enthält die Nachrichtenklassen, die MAPI-Connectors behandeln müssen.
466
Von MAPI-Connectors zu behandelnde Nachrichtenklassen
Nachrichtenklasse Beschreibung
ENVELOPE.{Nachrichtenklasse} Der MTE, der die Nachricht enthält. Die Standardnachrichtenklasse, die im MTE eingeschlossen ist, lautet IPM.NOTE. Dieses Nachrichtenobjekt kann mit der MAPI-IMessage-Schnittstelle geöffnet werden.
Hinweis: Neben der ENVELOPE-Nachrichtenklasse müssen MAPI-Connectors für die Nachrichtenkonvertierung auch die Standardnachrichtenklassen, z. B. IPM.NOTE, unterstützen, die im MTE eingeschlossen sind.
REPORT.{Nachrichtenklasse}.NDR Der Unzustellbarkeitsbericht. Der MAPI-Connector erstellt einen Unzustellbarkeitsbericht, wenn die Nachricht nicht übertragen werden kann. Dies ist z. B. der Fall, wenn der Connector die Adressen des Absenders oder der gewünschten Empfänger nicht ermitteln kann oder wenn er keine Verbindung zum anderen Messagingsystem herstellen kann. Das andere Messagingsystem kann auch einen Unzustellbarkeitsbericht senden, wenn ein angegebener Empfänger nicht vorhanden ist. Der Unzustellbarkeitsbericht wird an den ursprünglichen Absender gesendet und enthält die ursprüngliche Nachricht und die Empfängerliste als eingebettete Nachrichtenanlage.
467
Nachrichtenklasse Beschreibung
REPORT.{Nachrichtenklasse}.DR Der Übermittlungsbericht. Übermittlungsberichte sind optionale Berichte, die unterschiedliche Informationen über die Übertragung der ursprünglichen Nachricht enthalten. Diese Informationen sind vom Zielmessagingsystem abhängig. Wenn dieses Messagingsystem keine Übermittlungsberichte unterstützt, kann der MAPI-Connector einen Übermittlungsbericht erstellen, sobald er eine Nachricht erfolgreich an das andere Messagingsystem übertragen hat. Dieser Berichtstyp informiert den Absender nur darüber, dass das Zielsystem die Nachricht angenommen hat.
REPORT.{Nachrichtenklasse}.IPNRN Die persönliche Empfangsbenachrichtigung. Lesebestätigungen sind wie Übermittlungsberichte optionale Berichtsnachrichten. Lesebestätigungen informieren den Absender darüber, dass ein Empfänger eine Nachricht gelesen hat. Lesebestätigungen werden vom Messagingclient des Empfängers erstellt. Nicht alle Messagingsysteme unterstützen diesen Berichtstyp.
REPORT.{Nachrichtenklasse}.IPNNRN Die persönliche Benachrichtigung über Nichtempfang. Ungelesen-Bestätigungen ähneln Lesebestätigungen und informieren den Absender darüber, dass ein Empfänger eine Nachricht gelöscht hat, ohne diese zu öffnen. Ungelesen-Bestätigungen werden vom Messagingclient des Empfängers erstellt. Nicht alle Messagingsysteme unterstützen diesen Berichtstyp.
VerzeichnissynchronisierungMAPI-Connectors, z. B. der Connector für Lotus Notes und der Connector für Novell GroupWise, unterstützen die Verzeichnissynchronisierung, durch die eine konsistente globale Adressenliste für alle Messagingsysteme erstellt wird. MAPI-Connectors müssen außerdem
468
sicherstellen, dass die Verzeichnisinformationen in beiden Verzeichnissen aktuell sind. Wenn Sie z. B. einen Benutzer in einem anderen Messagingsystem ändern oder löschen, muss auch das entsprechende Empfängerobjekt in Active Directory geändert bzw. gelöscht werden. Daher verwendet der MAPI-Connector MAPI für die Interaktion mit dem Exchange-Informationsspeicher, aber ADSI für Active Directory.
Die Verzeichnissynchronisierung setzt sich aus zwei separaten, nacheinander ausgeführten Prozessen zusammen:
1. Synchronisieren der Empfänger aus einem anderen Messagingsystem mit Active Directory.
2. Synchronisieren der Empfänger aus Active Directory mit dem anderen Messagingsystem.
Verzeichnissynchronisierung aus einem anderen Messagingsystem in eine Exchange-OrganisationDie Verzeichnissynchronisierung aus einem anderen Messagingsystem in eine Exchange-Organisation umfasst folgende nacheinander ausgeführte Prozesse:
1. Extrahieren der Verzeichnisinformationen des Messagingsystems MAPI-Connectors verwenden Programmierschnittstellen, die vom Exchange-fremden Messagingsystem bereitgestellt werden, um die Verzeichnisinformationen aus diesem System zu extrahieren. Der Connector für Lotus Notes verwendet dafür z. B. die Lotus Notes-Client-API, und der Connector für Novell GroupWise verwendet Administratornachrichten, die er an den Novell GroupWise-API-Gateway weiterleitet.
2. Vorbereiten der Verzeichnisinformationen für das Importieren in Active Directory MAPI-Connectors erstellen die folgenden Arten von Empfängerobjekten für externe Benutzer in Active Directory:
Deaktivierte E-Mail-aktivierte Benutzerkonten Diese sind hilfreich, wenn externe Benutzer noch nicht in der Active Directory-Umgebung vorhanden sind, aber nach der Migration auf Exchange Server 2003 in das System aufgenommen werden.
Aktivierte E-Mail-aktivierte Benutzerkonten Diese sind hilfreich für externe Benutzer, die in der Active Directory-Umgebung arbeiten, auch wenn sie über kein Exchange-Postfach verfügen.
E-Mail-aktivierte Kontakte Diese sind hilfreich für externe Benutzer, die nicht in der Active Directory-Umgebung vorhanden sind und auch nicht in diese aufgenommen werden sollen. Internetbenutzer in externen Messagingsystemen sind ein Beispiel für diese Gruppe.
Ein MAPI-Connector kann Verteilerlisten als Kontaktobjekte synchronisieren. Dies ist ein Vorteil, da der Connector keine Mitgliedsinformationen für Verteilerlisten in
469
Active Directory verwalten muss. Nachrichten, die an eine Verteilerliste gesendet werden, müssen dann aber zur Aufgliederung der Verteilerliste zuerst an das alte Messagingsystem übertragen werden, bevor die Nachrichten an die einzelnen Empfänger gesendet werden können. Wenn die Verteilerliste Empfänger enthält, die zurück auf Benutzer in der Exchange Server 2003-Organisation verweisen, müssen die Nachrichten nach der Aufgliederung der Verteilerliste wieder zurück an die Exchange Server 2003-Organisation übertragen werden. Um unnötige Nachrichtenübertragungen zu verhindern, sollten Sie Verteilerlisten nicht synchronisieren. Wenn die Anzahl der Verteilerlisten überschaubar ist, können Sie E-Mail-aktivierte Gruppen in Active Directory erstellen und die einzelnen Mitglieder direkt angeben. In diesem Fall kann Exchange Server 2003 die Aufgliederung der Verteilerliste direkt ausführen, ohne dass zusätzliche Nachrichtenübertragungen an das alte Messagingsystem auftreten. Gruppen in Active Directory können beliebige Arten von Empfängerobjekten enthalten, z. B. Benutzerkonten, Kontakte oder andere Gruppen.
3. Importieren der Verzeichnisinformationen in Active Directory MAPI-Connectors erstellen mithilfe von ADSI E-Mail-aktivierte Benutzerkonten oder E-Mail-aktivierte Kontakte. Sowohl der Connector für Lotus Notes als auch der Connector für Novell GroupWise importieren Empfängerinformationen in eine einzige Zielorganisationseinheit in Active Directory. Die Zielorganisationseinheit, in die der MAPI-Connector die während der Verzeichnissynchronisierung von externen Benutzern erstellten Empfängerobjekte platziert, wird als Importcontainer bezeichnet. Es darf nur ein Importcontainer vorhanden sein.
Hinweis: Das Computerkonto des Exchange Server 2003-Bridgeheadservers mit dem MAPI-Connector benötigt Berechtigungen für das Erstellen und Ändern von Empfängern im ausgewählten Importcontainer.
Die folgende Abbildung veranschaulicht den allgemeinen Vorgang des Übertragens von Verzeichnisinformationen aus einem Messagingsystem ohne Exchange in eine Exchange-Organisation.
470
Verzeichnissynchronisierung zwischen einem anderen Messagingsystem und Active Directory
Verzeichnissynchronisierung aus einer Exchange-Organisation in ein anderes MessagingsystemDie Verzeichnissynchronisierung aus einer Exchange-Organisation in ein anderes Messagingsystem folgt denselben Prinzipien wie die Verzeichnissynchronisierung aus einem Messagingsystem in eine Exchange-Organisation. Der MAPI-Connector muss die Informationen über postfachaktivierte Benutzerkonten aus einer oder mehreren Organisationseinheiten (die auch als Exportcontainer bezeichnet werden) mithilfe von ADSI in Active Directory extrahieren, die Informationen verarbeiten und dann diese Informationen in das Nicht-Exchange-Verzeichnis importieren oder dort aktualisieren bzw. löschen. Damit die Verzeichnissynchronisierung aus Active Directory in das Nicht-Exchange-Verzeichnis funktioniert, muss das andere Messagingsystem Verzeichnisinformationen für Benutzer enthalten, die nicht zum lokalen Messagingsystem gehören. Die meisten Messagingsysteme unterstützen diese Funktion. Exchange-Benutzer werden in Lotus Notes z. B. als Benutzer in einer Lotus Notes-Fremddomäne angezeigt. Neben dem Exportieren von postfachaktivierten Benutzerkonten aus Active Directory unterstützen MAPI-Connectors auch das Exportieren von Kontakten und Gruppen, die dann in dem Nicht-Exchange-Verzeichnis als reguläre Exchange-Empfänger angezeigt werden.
471
Hinweis: Das Computerkonto des Exchange Server 2003-Bridgeheadservers mit dem MAPI-Connector benötigt Berechtigungen für das Zugreifen auf und das Lesen von Empfängerinformationen in dem ausgewählten Exportcontainer.
Die folgende Abbildung zeigt den allgemeinen Vorgang des Übertragens von Verzeichnisinformationen aus Active Directory in ein anderes Messagingsystem basierend auf ADSI und Nicht-Microsoft-APIs bzw. Importprogrammen, die die Empfängerobjekte im Nicht-Exchange-Verzeichnis platzieren. Die APIs und Tools, mit denen ein MAPI-Connector Verzeichnisinformationen in ein Nicht-Exchange-Verzeichnis importiert, müssen durch das Nicht-Exchange-Messagingsystem bereitgestellt werden. Der Connector für Lotus Notes verwendet für das Importieren von Verzeichnissen in Lotus Notes z. B. die Lotus Notes-Client-API, und der Connector für Novell GroupWise verwendet Administratornachrichten, die er an den Novell GroupWise-API-Gateway weiterleitet.
Verzeichnissynchronisierung aus Active Directory in ein anderes Messagingsystem
472
Öffnen eines Connector-Postfachs mit „Mdbvu32.exe“In diesem Thema wird erläutert, wie das Connector-Postfach mithilfe von Mdbvu32.exe, einem einfachen MAPI-Tool, geöffnet werden kann, nachdem Sie das Connectorprofil in den Unterschlüssel des derzeit angemeldeten Administrators kopiert haben.
Bevor Sie beginnenBevor Sie das Verfahren in diesem Thema durchführen, sollten Sie Folgendes berücksichtigen:
Mdbvu32.exe kann von der Website Downloads for Exchange Server 2003 gedownloadet werden.
Dieses Thema enthält Informationen zum Bearbeiten der Registrierung.
Vorsicht: Eine fehlerhafte Bearbeitung der Registrierung kann zu ernsthaften Problemen führen, die möglicherweise eine Neuinstallation des Betriebssystems erforderlich machen. Dadurch entstandene Probleme können unter Umständen nicht mehr behoben werden. Sichern Sie vor dem Ändern der Registrierung alle wichtigen Daten.
VerfahrenSo öffnen Sie ein Connector-Postfach mit „Mdbvu32.exe“
1. Stellen Sie sicher, dass der MAPI-Connector gestartet wurde.
2. Öffnen Sie Regedit, und suchen Sie den Unterschlüssel des Connectors unter HKEY_USERS\S-1-5-18\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles.
3. Klicken Sie mit der rechten Maustaste auf den Schlüssel für das MAPI-Profil des Connectors, und wählen Sie Exportieren aus. Exportieren Sie z. B. den Schlüssel SERVER01-LME-GWISE V5.5, wenn Sie die Nachrichtenwarteschlangen des Connectors für Novell GroupWise analysieren möchten.
4. Exportieren Sie den Schlüssel in eine REG-Datei, und schließen Sie dann den Registrierungs-Editor.
5. Öffnen Sie die exportierte REG-Datei in Editor, und ersetzen Sie alle Vorkommen von HKEY_USERS\S-1-5-18 durch HKEY_CURRENT_USER.
473
6. Speichern Sie die Änderungen, und schließen Sie Editor.
7. Doppelklicken Sie auf die REG-Datei, und bestätigen Sie im eingeblendeten Dialogfeld das Importieren der Registrierungseinstellungen in die Registrierung, indem Sie auf Ja klicken. Klicken Sie in dem Dialogfeld, in dem der Abschluss des Schritts bestätigt wird, auf OK.
8. Stellen Sie sicher, dass das Administratorkonto, mit dem Sie arbeiten, nicht Mitglied der Gruppen Organisations-Admins oder Domänen-Admins ist. Fügen Sie Ihr Konto vorübergehend der Gruppe Exchange Domain Servers hinzu, um Zugriffsberechtigungen für das Connector-Postfach zu erhalten.
9. Starten Sie Mdbvu32.exe, und klicken Sie im Dialogfeld MAPILogonEx auf OK.
10. Wählen Sie im Dialogfeld Profil auswählen das MAPI-Profil des Connectors, z. B. SERVER01-LME-GWISE V5.5, und klicken Sie dann auf OK.
11. Wählen Sie im Menü MDB den Eintrag OpenMessageStore aus. Überprüfen Sie im Dialogfeld Select Message Store To Open, dass der MAPI-Connector ausgewählt ist, und klicken Sie dann auf Open.
12. Wählen Sie im Menü MDB den Eintrag Open Root Folder, und doppelklicken Sie im Dialogfeld MAPI_FOLDER - Root auf den zu analysierenden Systemordner, z. B. MTS-IN.
13. Schließen Sie Mdbvu32.exe, und entfernen Sie Ihr Konto aus der Gruppe Exchange Domain Servers.
Architektur von Connector für Lotus NotesConnector für Lotus Notes kann eine Exchange-Organisation mit einem Lotus Notes- und Lotus Domino-Netzwerk verbinden. Exchange Server 2003 Service Pack 1 (SP1) unterstützt Lotus Notes, Version 3 und 4, sowie Lotus Domino, Version 4.5, 4.6, 5 und 6. Dieser MAPI-Connector verwendet die Lotus Notes-Client-API für die Kommunikation mit einem Lotus Notes- oder Lotus Domino-Server. Dafür muss auf dem Connectorserver ein Lotus Notes-Client vorhanden sein. Für das Verwenden der Clientsoftware ist eine Lizenz von Lotus Development erforderlich. Informationen zum Installieren und Konfigurieren von Connector für Lotus Notes finden Sie unter Exchange Server 2003 Interoperability and Migration Guide .
Hinweis: Da Connector für Lotus Notes die Lotus Notes-Client-API für die Kommunikation mit einem Lotus Notes- oder Lotus Domino-Server verwendet, benötigt der Connector eine dedizierte Notes-ID mit Berechtigungen für den Zugriff auf Lotus Notes-Datenbanken.
474
Die folgende Tabelle enthält die wesentlichen Komponenten von Connector für Lotus Notes.
Komponenten von Connector für Lotus Notes
Komponente Beschreibung
Connector-Postfach Als MAPI-Connector sucht Connector für Lotus Notes seine Nachrichtenwarteschlangen in einem Connector-Postfach im Standardpostfachspeicher auf dem Bridgeheadserver. Der Postfachname lautet Connector für Lotus Notes (<Servername>), z. B. Connector für Lotus Notes (SERVER01).
Connector-Dienst Die ausführbare Hauptdatei des Diensts Connector für Lotus Notes verfügt über die Bezeichnung Dispatch.exe. Dabei handelt es sich um einen Prozesscontroller, der mit den Parametern -cexchconn.ini -nLME-NOTES -pCONTROL-SERVICE -l"C:\Programme\Exchsrvr\bin" -vLME-NOTES gestartet wird, um die verschiedenen Aufgaben für die Nachrichtenübertragung und Verzeichnissynchronisierung an andere Prozesse zu verteilen. Als Grundlage dafür werden die Einstellungen aus der Datei Exchconn.ini verwendet. Die Datei Exchconn.ini wird automatisch während des Installations- und Konfigurationsvorgangs für Connector erstellt.
Die folgenden Komponenten sind an der Informationsverarbeitung beteiligt:
Dxanotes.dll Diese Komponente überprüft das Lotus Domino-Verzeichnis auf Empfängeraktualisierungen. Außerdem überträgt diese Komponente Änderungen in den Exchange-Adressinformationen an das Lotus Domino-/Notes-Adressbuch.
Dxamex.dll Diese Komponente
475
Komponente Beschreibung
überprüft Active Directory auf Empfängeraktualisierungen. Außerdem überträgt diese Komponente Änderungen in den Lotus Domino-/Notes-Adressinformationen an Active Directory.
Lsdxa.exe Hierbei handelt es sich um den Verzeichnisaustausch-Manager, der Dxanotes.dll und Dxamex.dll steuert.
Lsmexin.exe Diese Komponente ruft die konvertierten Nachrichten aus dem Ordner READYIN im Connector-Postfach ab, überprüft die Gültigkeit der Empfänger und platziert die Nachrichten in der MTS-IN-Warteschlange.
Lsmexnts.exe Diese Komponente ruft Nachrichten aus dem Ordner READYOUT im Connector-Postfach ab, konvertiert diese aus MAPI in das Lotus Notes-Format und schreibt sie in die Datenbank mail.box auf dem Domino-Server.
Lsmexout.exe Diese Komponente ruft ausgehende Nachrichten aus der MTS-OUT-Warteschlange ab, überprüft Active Directory, um die Zielempfängerinformationen durch die entsprechenden Lotus Notes-Adressen zu ersetzen, und platziert die Nachrichten im Ordner READYOUT im Connector-Postfach.
Lsntsmex.exe Diese Komponente lädt Nachrichten aus der Lotus Notes-Datenbank exchange.box herunter, konvertiert sie in das MAPI-Format und platziert sie im Ordner READYIN des Connector-Postfachs.
Neben diesen Prozessen umfasst Connector für Lotus Notes auch den Hilfsdienst Microsoft Exchange-Verbindungscontroller
476
Komponente Beschreibung
Lotus Notes-Datenbanken Connector für Lotus Notes verwendet die folgenden Datenbanken auf dem Lotus Notes- und Lotus Domino-Bridgeheadserver:
Exchange.box Hierbei handelt es sich um das Connector-Postfach in Lotus Notes und Domino, in dem die von Lotus Domino an Exchange weiterzuleitenden Nachrichten gespeichert werden. Sie müssen ein Fremddomänendokument erstellen, um die Exchange-Organisation als eine externe Domäne im Lotus Domino-Verzeichnis zu registrieren, und den Namen des Connector-Postfachs in diesem Dokument angeben. Alle von Lotus Domino an Exchange Server 2003 weitergeleiteten E-Mail-Nachrichten werden an das Connector-Postfach gesendet, aus dem sie von Connector für Lotus Notes abgerufen werden. Der Connector benötigt Manager-Rechte mit der Berechtigung zum Löschen, um E-Mail-Nachrichten aus dieser Datenbank abzurufen und Wartungsvorgänge an der Datenbank auszuführen.
Exchange.bad Hierbei handelt es sich um das Connector-Postfach für beschädigte Nachrichten (BadMail), das von Connector für Lotus Notes zum Speichern von Nachrichten verwendet wird, die nicht an Exchange Server 2003 übermittelt werden konnten. Der Connector benötigt Manager-Rechte mit der Berechtigung zum Löschen, um BadMail-Nachrichten in diese Datenbank verschieben und Wartungsvorgänge an der Datenbank ausführen zu können.
Mail.box Hierbei handelt es sich um das Serverpostfach des Lotus Domino-
477
Komponente Beschreibung
Servers. Connector für Lotus Notes platziert in diesem Postfach alle Nachrichten von Exchange Server 2003, die an Lotus Domino-Postfächer gerichtet sind. Der Connector benötigt Archivar-Berechtigungen für das Speichern von E-Mail-Nachrichten und das Durchführen von Wartungsvorgängen an der Datenbank.
Names.nsf Hierbei handelt es sich um die Lotus Domino-Standardverzeichnisdatei, die von Connector für Lotus Notes für die Verzeichnissynchronisierung verwendet wird. Sie können andere oder zusätzliche Adressbücher für Lotus Domino-Domänen angeben. Der Connector benötigt Editor-Berechtigungen mit Rechten zum Löschen, um die Verzeichnissynchronisierung durchzuführen.
Außerdem ist für Connector für Lotus Notes möglicherweise Lesezugriff auf die regulären Lotus Notes-Datenbanken erforderlich, um Notes-DocLinks in RTF-Anlagen oder OLE-Dokumente zu konvertieren.
478
Komponente Beschreibung
Connector-Informationsspeicher Connector für Lotus Notes verwendet eine Ordnerstruktur im Dateisystem, um Steuerdateien zu verwalten, die während der Verzeichnissynchronisierung verwendet werden. Steuerdateien sind Schemadefinitionsdateien und Zuordnungsregeldateien, die festlegen, wie die Attribute in einem Verzeichnis im anderen Verzeichnis zugeordnet werden. Der Connector-Informationsspeicher befindet sich im Verzeichnis \Programme\Exchrvr\Conndata.
Sie können die folgenden Schemadefinitions- und Zuordnungsregeldateien in Editor bearbeiten, um festzulegen, wie die Attribute des einen Verzeichnisses im anderen Verzeichnis zugeordnet werden:
MAP.TBL im Unterverzeichnis \Dxamex Definiert die zu synchronisierenden Exchange-Postfachattribute.
AMAP.TBL im Unterverzeichnis \Dxanotes Definiert die zu synchronisierenden Lotus Notes-Attribute.
MAPMEX.TBL im Unterverzeichnis \Dxanotes Legt die Attributzuordnung von Exchange Server 2003 nach Lotus Notes fest.
MAPNOTES.TBL im Unterverzeichnis \Dxamex Legt die Attributzuordnung von Lotus Notes nach Exchange Server 2003 fest.
Ausführliche Informationen zum Anpassen der Verzeichnissynchronisierung zwischen Lotus Domino und Exchange Server 2003 finden Sie im Microsoft Knowledge Base-Artikel 180517, „XFOR: Customizing Directory Synchronization Between
479
Komponente Beschreibung
Registrierungseinstellungen In der Registrierung werden die Einstellungen für Connector für Lotus Notes in der folgenden Struktur gespeichert: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LME-NOTES.
DLL für die Proxyadressgenerierung Die DLL für die Proxyadressgenerierung von Connector für Lotus Notes verfügt über die Bezeichnung Ntspxgen.dll und befindet sich im Verzeichnis \Programme\Exchsrvr\address\notes\i386.
addrType-Objekt Der allgemeine Name des addrType-Objekts von Connector für Lotus Notes in Active Directory lautet NOTES:i386.
msExchConnector-Objekt Im msExchConnector-Objekt von Connector für Lotus Notes in der Konfigurationsverzeichnispartition von Active Directory werden die meisten Konfigurationseinstellungen für den Connector gespeichert. Die folgenden Attribute gelten speziell für die msExchNotesConnector-Objektklasse, die von der msExchConnector-Objektklasse und der mailGateway-Objektklasse abgeleitet ist:
exportCustomRecipients Gibt an, ob E-Mail-aktivierte Kontakte bei der Verzeichnissynchronisierung an Lotus Notes weitergegeben werden.
msExchServer1AlwaysCreateAs Gibt an, wie X.500-Objekte synchronisiert werden.
msExchDeliveryOrder Gibt die Verarbeitungsreihenfolge von Nachrichten in der Warteschlange des Connectors an. Die Optionen lauten: FIFO, Priority (Standard) und Size.
msExchExportDLs Gibt an, ob E-Mail-aktivierte Verteilergruppen bei der
480
Komponente Beschreibung
Verzeichnissynchronisierung an Lotus Notes weitergegeben werden.
msExchPartnerLanguage Gibt die Sprache (Codeseite) des Lotus Notes- und Domino-Servers an, mit dem die Verbindung besteht.
msExchDirsyncSchedule Gibt die Zeiten an, zu denen die Verzeichnissynchronisierung automatisch durchgeführt wird.
msExchDirsyncStyle Gibt an, ob eine vollständige oder eine inkrementelle Verzeichnissynchronisierung durchgeführt wird.
msExchNotesNotesServer Gibt den Namen des Lotus Notes- und Domino-Servers (im Notes-Format) an, der vom Connector als Nicht-Exchange-Bridgeheadserver verwendet wird.
msExchNotesForeignDomain Gibt den Namen der Nicht-Exchange-Domäne in Lotus Notes an, die die Exchange-Organisation darstellt.
msExchNotesRtrMailbox Gibt den Namen des Lotus Notes- und Domino-Serverpostfachs an, das vom Lotus Notes-E-Mail-Router verwendet wird, auf dem Connector für Lotus Notes ausgehende Nachrichten an Lotus Notes bereitstellt. In der Regel handelt es sich dabei um mail.box.
msExchNotesConnectorMailbox Gibt den Namen des Lotus Notes-Postfachs an, aus dem Connector für Lotus Notes Nachrichten von Lotus Notes an Exchange abruft. In der Regel handelt es sich dabei um exchange.box.
msExchNotesLetterhead Gibt den
481
Komponente Beschreibung
Namen des Briefkopfformats von Lotus Notes an, das für Nachrichten von Exchange an Lotus Notes verwendet wird. Die Standardeinstellung ist unformatierter Text.
msExchNotesNotesLinks Gibt an, wie Lotus Notes-DocLinks in Nachrichten an Exchange konvertiert werden. Die Optionen lauten: RTF, OLE und URL. Der Standardwert ist RTF.
msExchNotesNotesINI Gibt den vollständigen Pfad und den Dateinamen der INI-Datei des Lotus Notes-Clients an, mit der sich der Connector am Lotus Notes- und Domino-Server anmeldet.
msExchNotesTargetBook Gibt den Standardnamen sowie das Standardadressbuch von Lotus Notes an, in das Exchange-Benutzer importiert werden.
msExchNotesSourceBooks Gibt die Liste der Lotus Notes-Namen und Adressbücher an, die bei der Verzeichnissynchronisierung nach Exchange exportiert werden.
msExchNotesExportGroups Gibt an, ob Lotus Notes-Gruppen bei der Verzeichnissynchronisierung nach Exchange exportiert werden. Der Standardwert ist TRUE.
msExchNotesExcludeGroups Gibt eine Liste von Lotus Notes-Gruppen an, die von der Verzeichnissynchronisierung ausgeschlossen werden. Die Standardwerte lauten OtherDomainServers und LocalDomainServers.
msExchExportContainersLinked Gib
482
Komponente Beschreibung
t den DN (Distinguished Name) der Organisationseinheiten in Active Directory an, die von Connector für Lotus Notes als Exportcontainer für die Verzeichnissynchronisierung verwendet werden.
msExchImportContainerLinked Gibt den DN der Organisationseinheit in Active Directory an, die von Connector für Lotus Notes als Importcontainer für die Verzeichnissynchronisierung verwendet wird.
msExchMaintenanceStyle Gibt die Art der Verwaltung für diesen Connector an.
msExchConnectorType Gibt den Typ des Exchange-Connectors an. Der Wert lautet NOTES.
Verwaltungs-Snap-In Die Bezeichnung für das Erweiterungs-Snap-In für Connector für Lotus Notes lautet Exchange Notes Connector. Dieses Snap-In erweitert den Knoten für den Connector, der sich im Exchange-System-Manager unter <Organisationsname>/Administrative Groups/<Name der administrativen Gruppe>/Routing Groups/<Name der Routinggruppe>/Connectors befindet.
NachrichtenübertragungIn der folgenden Abbildung wird der Vorgang zum Senden von Nachrichten von Exchange Server 2003 an Lotus Domino veranschaulicht.
483
Senden von Nachrichten von Exchange Server 2003 an Lotus Domino
Die Übertragung von Nachrichten von Exchange Server 2003 an Lotus Domino setzt sich aus den folgenden drei Schritten zusammen:
1. Exchange 2003 ermittelt anhand der Zieladresse des Benutzers, dass der Empfänger ein Lotus Domino-Benutzer ist, und sendet die Nachricht an den MTA (Message Transfer Agent).
2. Der MTA übermittelt die Nachricht in das Verzeichnis MTS-OUT. Der Prozess LSMEXOUT ruft die Nachricht aus diesem Verzeichnis ab, konvertiert die Adresse von einer X.400-Adresse in eine Lotus Domino-Adresse und sendet sie dann an das Verzeichnis READYOUT.
3. Der Prozess LSMEXNTS konvertiert die Nachricht in das Lotus Domino-Format und sendet sie zum Weiterleiten an die Datei mail.box auf dem Lotus Domino-Server.
In der folgenden Abbildung wird der Vorgang zum Senden von Nachrichten von Lotus Domino an Exchange Server 2003 veranschaulicht.
484
Senden von Nachrichten von Lotus Domino an Exchange Server 2003
Die Übertragung von Nachrichten von Lotus Domino an Exchange Server 2003 setzt sich aus den folgenden drei Schritten zusammen:
1. Lotus Domino empfängt eine Nachricht, die von einem Lotus Notes-Benutzer an einen Exchange Server 2003-Benutzer gesendet wird, und legt diese in der Datenbank mail.box des Mailrouters ab. Der Mailrouter erkennt, dass die Nachricht an Exchange Server 2003 gesendet wurde, und platziert sie in der Datei exchange.box.
2. Connector für Lotus Notes ruft die Nachricht aus der Datenbank exchange.box ab, konvertiert sie mit LSNTSMEX in das Exchange Server 2003-Format und überträgt sie dann in den Ordner READYIN auf dem Server mit Exchange Server 2003.
3. Der Prozess LSMEXIN empfängt die Nachricht, konvertiert die Adresse von einer Lotus Domino-Adresse in eine X.400-Adresse und platziert die Nachricht dann im Ordner MTS-IN. Der Exchange-MTA verarbeitet die Nachricht anschließend im Ordner MTS-IN und platziert sie im Ordner MTS-OUT des SMTP-Diensts (Simple Mail Transfer Protocol), aus dem sie dann weitergeleitet wird.
NachrichtenkonvertierungExchange Server 2003 und Lotus Domino unterstützen verschiedene Nachrichtentypen wie Besprechungsanfragen, Aufgaben, Aufgabenanforderungen und E-Mail-Nachrichten. Connector für Lotus Notes unterstützt die Zuordnung verschiedener Nachrichtentypen zwischen Exchange Server 2003 und Lotus Domino. Die Konvertierung von einem Format in ein anderes kann jedoch zu Änderungen an den Nachrichtenmerkmalen führen. So gehen z. B. bestimmte Funktionen von Lotus Domino-Nachrichten, wie das Ablaufdatum, verloren, wenn die Nachricht in das Exchange-Format konvertiert wird. Nachrichten, die keinem
485
entsprechenden Nachrichtentyp in der Zieldomäne zugeordnet werden können, werden in E-Mail-Nachrichten konvertiert.
Hinweis: Connector für Lotus Notes ist nicht für das Konvertieren von Nachrichten im HTML-Format vorgesehen. Wenn Sie Nachrichten im HTML-Format zwischen Exchange Server 2003 und Lotus Notes weiterleiten möchten (wenn Sie z. B. alle Nachrichten an und von Internet-Benutzern über Exchange Server 2003 weiterleiten möchten), sollten Sie anstelle von Connector für Lotus Notes einen SMTP-Connector einrichten.
In der folgenden Tabelle wird die Konvertierung verschiedener Nachrichtentypen zwischen Exchange Server 2003 und Lotus Domino veranschaulicht.
Nachrichtenkonvertierung zwischen Lotus Domino und Exchange Server 2003
Exchange Server 2003-Feature
Lotus Domino-Feature
Lotus Domino nach Exchange Server 2003
Exchange Server 2003 nach Lotus Domino
E-Mail-Nachrichten E-Mail-Nachrichten Ja Ja
E-Mail-Übermittlungsbestätigung
E-Mail-Übermittlungsbestätigung
Ja Ja
E-Mail-Lesebestätigung
E-Mail-Lesebestätigung
Ja Ja
Unzustellbarkeitsbericht
Unzustellbarkeitsbericht
Ja Ja
Wichtigkeit Wichtigkeit Ja Ja
Abstimmungsschaltflächen
Kein Feature Nein Nein
Eingebettetes OLE-Objekt
Eingebettetes OLE-Objekt
Ja Ja
Eingebettete Dateianlage
Eingebettete Dateianlage
Ja Ja
Nachrichtenablaufdatum
Nachrichtenablaufdatum
Nein Nein
Kein Feature Antwort von Nein Nein
Web-URL Web-URL Ja Ja
Kein Feature URL-Hotspot Nein Nein
486
Exchange Server 2003-Feature
Lotus Domino-Feature
Lotus Domino nach Exchange Server 2003
Exchange Server 2003 nach Lotus Domino
Besprechungsanfragen
Termine Ja Ja
Besprechungsannahme
Besprechungsannahme
Ja Ja
Besprechungsablehnung
Besprechungsablehnung
Ja Ja
Besprechungsannahme unter Vorbehalt
Besprechungsannahme
Wird als angenommen angezeigt
Wird als angenommen angezeigt
Besprechungsanfrage gelesen
Besprechungsanfrage gelesen
Ja Ja
Übermittlung von Besprechungsanfragen
Übermittlung von Besprechungsanfragen
Ja Ja
Besprechungsaktualisierungen
Besprechungsaktualisierungen
Werden als neue Besprechungsanfragen mit dem Wort „Aktualisiert“ in der Zeile Betreff angezeigt
Werden als neue Besprechungsanfragen mit dem Wort „Aktualisiert“ in der Zeile Betreff angezeigt
Besprechungsabsagen
Besprechungsabsagen
Ja Ja
Aufgabenanforderungen
Aufgaben Aufgabenanforderungen werden als E-Mail-Nachrichten oder Aufgaben angezeigt.
Aufgabenanforderungen werden als E-Mail-Nachrichten angezeigt.
Ganztägige Besprechungsanfragen
Kein Feature Nein Werden als Besprechungen mit Mitternacht als Anfangs- und Endzeit angezeigt
487
Exchange Server 2003-Feature
Lotus Domino-Feature
Lotus Domino nach Exchange Server 2003
Exchange Server 2003 nach Lotus Domino
Kein Feature Telefonische Nachrichten
Werden als E-Mail-Nachrichten angezeigt
Nein
Andere Nachrichten Andere Nachrichten Werden in der Standardeinstellung in E-Mail-Nachrichten konvertiert
Werden in der Standardeinstellung in E-Mail-Nachrichten konvertiert
Hinweis: Connector für Lotus Notes unterstützt weder signierte noch verschlüsselte Nachrichten.
Konvertierung des E-Mail-NachrichtentypsE-Mail-Nachrichten aus Exchange oder Lotus Domino werden in das Format des Zielmessagingsystems konvertiert. Connector für Lotus Notes verfolgt außerdem die Nachrichtenübermittlung mithilfe von Übermittlungsbestätigungen, Lesebestätigungen und Unzustellbarkeitsberichten.
Connector für Lotus Notes behandelt Besprechungsanfragen und telefonische Nachrichten wie folgt:
Besprechungsanfragen und Termine Connector für Lotus Notes synchronisiert Exchange-Besprechungsanfragen und Lotus Domino-Termine. Aktualisierte Besprechungsanfragen werden in der Betreffzeile als aktualisiert gekennzeichnet. Aufgrund der Einschränkungen durch die Lotus Domino-API werden Besprechungsanfragen, die Exchange Server 2003-Benutzer an Lotus Domino-Benutzer senden, nicht automatisch in Lotus Domino aktualisiert. Der Benutzer muss diese manuell aktualisieren.
Ganztägige Besprechungsanfragen Ganztägige Besprechungsanfragen haben in Exchange Server 2003 als Anfangs- und Endzeit Mitternacht.
Telefonische Nachrichten Telefonische Lotus Notes-Nachrichten werden in Exchange Server 2003 als E-Mail-Nachrichten angezeigt.
488
Zuordnen von E-Mail-NachrichteneigenschaftenIn Nachrichten eingebettete Objekte, die vom Exchange Server 2003-Client (Outlook) an den Lotus Domino-Client (Lotus Notes) gesendet werden, werden in Anlagen konvertiert. Eingebettete Objekte werden immer als Anlagen der primären Nachricht angezeigt, unabhängig davon, wo sie im ursprünglichen Thread angezeigt werden.
In der folgenden Tabelle wird veranschaulicht, welche Features aus Lotus Notes-E-Mail-Nachrichten in Microsoft Outlook richtig konvertiert werden.
E-Mail-Nachrichtenkonvertierung zwischen Lotus Notes und Microsoft Outlook
Lotus Notes Microsoft Outlook
Größe Wird richtig konvertiert
Farbe Wird richtig konvertiert
Fett Wird richtig konvertiert
Unterstrichen Wird richtig konvertiert
Kursiv Wird richtig konvertiert
Durchgestrichen Wird richtig konvertiert
Tabellen Werden richtig konvertiert, wenn Microsoft Word als primärer E-Mail-Editor in Outlook verwendet wird. Formatierungen gehen allerdings verloren. Werden nicht richtig konvertiert, wenn Outlook der E-Mail-Editor ist.
Eingebettete OLE-Objekte, einschließlich Grafiken
Werden richtig konvertiert und können bearbeitet werden
Doppelt durchgestrichen Wird ignoriert
Hochgestellt Wird ignoriert
Tiefgestellt Wird ignoriert
Schattiert Wird ignoriert
Umriss Wird in kursiv konvertiert
Relief Wird ignoriert
Gravur Wird ignoriert
Kapitälchen Wird ignoriert
Großbuchstaben Wird ignoriert
489
Lotus Notes Microsoft Outlook
Initiale Wird ignoriert
Ausgeblendet Wird ignoriert. Der Text ist sichtbar.
Unterstreichung, sofern nicht einfach Wird ignoriert
Nicht als OLE-Objekte eingebettete Bitmaps Werden nicht migriert. Die Formatierung geht verloren.
Aufzählungszeichen Werden ignoriert.
VerzeichnissynchronisierungIn der folgenden Abbildung wird die Verzeichnisverbindung zwischen Exchange Server 2003 und Lotus Domino dargestellt. Wie in der oben stehenden Tabelle dargestellt, ist der Prozess Lsdxa.exe für die Steuerung der Prozesse für die Verzeichnissynchronisierung, Dxamex.dll und Dxanotes.dll, verantwortlich. Lsdxa.exe wird automatisch mit dem Dienst Microsoft Exchange Connector für Lotus Notes gestartet. Weitere Informationen zum Konfigurieren der Verzeichnissynchronisierung finden Sie unter Exchange Server 2003 Interoperability and Migration Guide.
Hinweis: Connector für Lotus Notes erstellt für die Empfänger im Lotus Notes-Messagingsystem E-Mail-aktivierte Kontakte in Active Directory. Die legacyExchangeDN-Adresse (d. h., die X.500-Adresse des Exchange-Benutzers im Exchange 5.5-Format) stimmt im ersten Teil mit der legacyExchangeDN-Adresse des Connectors überein. Der erste Teil ist bei der X.500-Adresse der Teil, der die administrative Gruppe des Connectors angibt (d. h. /O=<Name der Organisation>/OU=<Name der administrativen Gruppe>).
Verzeichnissynchronisierung zwischen Lotus Domino und Exchange Server 2003
490
Auf Exchange-Seite kommuniziert Dxamex.dll über ADSI mit Active Directory, um die Empfängerinformationen aus den in der Konfiguration des Connectors angegebenen Exportcontainern zu extrahieren. Dxamex.dll ordnet die Empfängerattribute wie in Amap.tbl und Mapmex.tbl definiert zu und speichert die Ergebnisse im Message Interchange-Format (MIF) in einer temporären Datei mit der Bezeichnung Dxanotes.text im Verzeichnis \Programme\Exchsrvr\Conndata\Temp. Anschließend analysiert Dxanotes.dll die Datei Dxanotes.txt, verarbeitet die Adressen und speichert sie im Zielverzeichnis auf dem Lotus Domino-Server. Für die Kommunikation mit Lotus Domino verwendet Dxanotes.dll die Lotus Notes-Client-API.
Die folgende Liste stellt ein Beispiel für die Datei Dxanotes.txt dar:LoadAFULLNAME:AdministratorMAILDOMAIN:ExchangeCOMPANY:DEPARTMENT:FIRSTNAME:LASTNAME:AdministratorLOCATION:SHORTNAME:AdministratorUNID:DBC07527-91C1F649-8427525F-902428E2DN:CN=Administrator,CN=Users,DC=contoso,DC=comUSNCreated:8194Initials:Title:Phone:MobilePhn:Fax:Resource:CALDOM:ExchangeMAILSRV:
EndOfBuffer
Dxanotes.dll führt außerdem die Verzeichnissynchronisierung von Lotus Notes nach Active Directory durch. Für das Lesen des Lotus Domino-Verzeichnisses verwendet der Prozess die Lotus Notes-Client-API. Dxanotes.dll ordnet die Empfängerattribute wie in Amap.tbl und Mapnotes.tbl definiert zu und schreibt die Empfängerinformationen in die Datei Dxamex.txt im Verzeichnis \Programme\Exchsrvr\Conndata\Temp. Dxamex.dll verarbeitet die Datei Dxamex.txt und speichert die Empfängerinformationen in dem in der Konfiguration des Connectors angegebenen Importcontainer.
Die folgende Liste stellt ein Beispiel für die Datei Dxamex.txt dar:LoadUDN:adminTA:NOTES:admin@NotesALIAS:admin
491
NAME:adminFULLNAME:adminFIRSTNAME:Initials:LASTNAME:adminNOTESADDR:admin@NotesUNID:4a12766d-8684ea55-3e551cde-3bac7ae9COMPANY:DEPARTMENT:TITLE:OFFICE:PHONE:FAX:MOBILEPHN:USNCREATED:
EndOfBuffer
Architektur von Connector für Novell GroupWiseConnector für Novell GroupWise unterstützt die bidirektionale Nachrichtenübertragung und Verzeichnissynchronisierung zwischen einer Exchange-Organisation und einer Novell GroupWise-Umgebung. Es werden die Novell GroupWise-Versionen 4.2, 5.0 und 5.5 unterstützt. Dieser MAPI-basierte Connector verwendet das Novell GroupWise-API-Gateway für die Kommunikation mit Novell GroupWise. Informationen zum Installieren und Konfigurieren von Connector für Novell GroupWise finden Sie unter Exchange Server 2003 Interoperability and Migration Guide.
Hinweis: Novell GroupWise 6.0 oder höher wird von Microsoft offiziell nicht unterstützt. Da die zugrunde liegenden Technologien im Vergleich zu früheren Versionen aber nicht geändert wurden, bietet der Microsoft-Produktsupport angemessene technische Unterstützung in eingeschränktem Rahmen. Anstelle von Connector für Novell GroupWise können Sie für die Interoperabilität und Verzeichnissynchronisierung auch Novell GroupWise-Gateway für Microsoft Exchange verwenden. Wenn Sie eine Migration von Novell GroupWise 6.0 oder höher zu Exchange Server 2003 durchführen möchten, können Sie diesen Connector von Novell verwenden.
Die folgende Tabelle enthält die wesentlichen Komponenten von Connector für Lotus Notes.
492
Komponenten von Connector für Novell GroupWise
Komponente Beschreibung
Connector-Postfach Als MAPI-basierter Connector sucht Connector für Novell GroupWise seine Nachrichtenwarteschlangen in einem Connector-Postfach im Standardpostfachspeicher auf dem Bridgeheadserver. Der Postfachname lautet Connector für Novell GroupWise (<Servername>), z. B. Connector für Novell GroupWise (SERVER01).
Connector-Dienst Connector für Novell GroupWise verwendet mit Dispatch.exe die gleiche ausführbare Hauptdatei wie Connector für Lotus Notes. Dies ist möglich, da von Dispatch.exe nicht die eigentliche Nachrichtenverarbeitung ausgeführt wird. Dispatch.exe wird mit den Parametern -cexchconn.ini -nLME-GWISE -pCONTROL-SERVICE -l"C:\Programme\Exchsrvr\bin" -vLME-GWISE gestartet und verteilt die zum Ausführen der verschiedenen Aufgaben für die Nachrichtenübertragung und Verzeichnissynchronisierung mit Novell GroupWise erforderlichen Prozesse. Dispatch.exe startet die eigentlichen Prozesse basierend auf den Einstellungen in der Datei Exchconn.ini. Die Datei Exchconn.ini wird automatisch bei der Installation und Konfiguration des Connectors erstellt.
Drei der aktiven Connectorprozesse sind mit denen für Connector für Lotus Notes identisch. Dabei handelt es sich um die Prozesse Lsmexin.exe, Lsmexout.exe und Dxamex.dll, die mit Exchange Server 2003 kommunizieren. Zu den Komponenten speziell für Connector für Novell GroupWise zählen Mex2gw.exe, Gw2mex.exe und Dxagwise.dll.
493
Komponente Beschreibung
Die folgenden Komponenten sind an der Informationsverarbeitung beteiligt:
Dxagwise.dll Diese Komponente überprüft das Novell GroupWise-Verzeichnis auf Empfängeraktualisierungen. Außerdem überträgt diese Komponente Änderungen in den Exchange-Adressinformationen in das Novell GroupWise-Verzeichnis.
Dxamex.dll Diese Komponente überprüft Active Directory auf Empfängeraktualisierungen. Außerdem überträgt diese Komponente Änderungen in den Novell GroupWise-Adressinformationen an Active Directory.
Lsdxa.exe Hierbei handelt es sich um den Verzeichnisaustausch-Manager, der Dxagwise.dll und Dxamex.dll steuert.
Lsmexin.exe Diese Komponente ruft die konvertierten Nachrichten aus dem Ordner READYIN im Connector-Postfach ab, überprüft die Gültigkeit der Empfänger und platziert die Nachrichten in der MTS-IN-Warteschlange.
Mex2gw.exe Diese Komponente ruft Nachrichten aus dem Ordner READYOUT im Connector-Postfach ab, konvertiert sie aus dem MAPI- in das Novell GroupWise-Format und speichert sie dann als Dateien mit Nachrichtenheader und -text im Connector-Informationsspeicher auf dem Server mit Exchange Server 2003.
Lsmexout.exe Diese Komponente ruft ausgehende Nachrichten aus der MTS-OUT-Warteschlange ab, überprüft Active Directory, um die Zielempfängerinformationen durch die
494
Komponente Beschreibung
entsprechenden Novell GroupWise-Adressen zu ersetzen, und platziert die Nachrichten im Ordner READYOUT im Connector-Postfach.
Gw2mex.exe Diese Komponente konvertiert die Dateien mit Nachrichtenheader und -text im Connector-Informationsspeicher in eine Nachricht im Exchange Server 2003-Format, bevor sie diese im Ordner READYIN ablegt.
Neben diesen Prozessen umfasst Connector für Novell GroupWise auch den Hilfsdienst Microsoft Exchange-Verbindungscontroller (Lscntrl.exe), mit dem einzelne Connectorprozesse angehalten werden können.
Alle Dateien befinden sich im Verzeichnis \Programme\Exchsrvr\Bin.
Dienst Exchange Router für Novell GroupWise
Connector für Novell GroupWise verwendet den Dienst Microsoft Exchange Router für Novell GroupWise (Gwrouter.exe), der Nachrichten als Dateien mit Nachrichtenheader und -text zwischen dem Connector-Informationsspeicher und einem Novell GroupWise-API-Gateway überträgt.
Connector-Informationsspeicher Der Connector-Informationsspeicher, der sich im Verzeichnis \Programme\Exchrvr\Conndata befindet, fungiert als Kommunikationsmedium zwischen Connector für Novell GroupWise und Exchange Router für Novell GroupWise.
Connector für Novell GroupWise verwendet die folgenden Unterverzeichnisse des Connector-Informationsspeichers:
\Gwrouter Dieses Verzeichnis enthält weitere Unterverzeichnisse, die von Exchange Router für Novell GroupWise
495
Komponente Beschreibung
abgefragt werden. Die Unterverzeichnisse sind temporäre Repositorys für Nachrichtenheaderdateien mit der Dateinamenerweiterung .api und Dateien für Nachrichtentext und -anlagen mit der Dateinamenerweiterung .bdy, die von Exchange Router für Novell GroupWise zum und vom Novell GroupWise-API-Gateway übertragen werden. Die Dateien für Nachrichtenheader und -text sind schlüsselwortbasierte Textdateien, die vom Novell GroupWise-API-Gateway in Nachrichten im Novell GroupWise-Format konvertiert werden können.
Das Verzeichnis \Gwrouter verfügt über die folgenden Unterverzeichnisse:
\Archive Dieses Verzeichnis ist nur vorhanden, wenn die Archivierung für Connector für Novell GroupWise aktiviert ist. Zum Aktivieren der Archivierung muss der REG_DWORD-Registrierungsparameter Archive konfiguriert werden, der sich an folgendem Speicherort befindet: HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Services\LME-
GWISE\Parameters.
Legen Sie hierzu den Wert für diesen Registrierungsparameter auf 0x1 fest. Daraufhin wird beim erneuten Starten des Diensts Exchange Router für Novell GroupWise von Exchange 2003 im Verzeichnis \Programme\Exchsrvr\Conndata\Gwrouter das Verzeichnis \Archive erstellt. Das Verzeichnis \Archive enthält die folgenden Unterverzeichnisse: \
496
Komponente Beschreibung
Dirsync, \Freebusy, \Gw2mex, \Gw2mexa, \Mex2gw, \Mex2gwa und \Togwise.
\Badfiles In diesem Verzeichnis werden beschädigte Nachrichten aus Novell GroupWise gespeichert, die von Connector für Novell GroupWise nicht verarbeitet werden konnten.
\Dirsync In diesem Verzeichnis werden Antwortnachrichten gespeichert, die Novell GroupWise auf Anforderungen von Verzeichnisinformationen sendet.
\Freebusy In diesem Verzeichnis werden Antwortnachrichten gespeichert, die Novell GroupWise auf Frei-/Gebucht-Anforderungen sendet.
\Gw2mex In diesem Verzeichnis werden von Novell GroupWise eingehende Headerdateien mit der API-Dateinamenerweiterung gespeichert.
\Gw2mexa In diesem Verzeichnis werden von Novell GroupWise eingehende Dateien für Nachrichtentext und -anlagen mit der BDY-Dateinamenerweiterung gespeichert.
\Mex2gw In diesem Verzeichnis werden an Novell GroupWise ausgehende Headerdateien mit der API-Dateinamenerweiterung gespeichert.
\Mex2gwa In diesem Verzeichnis werden an Novell GroupWise ausgehende Dateien für
497
Komponente Beschreibung
Nachrichtentext und -anlagen mit der BDY-Dateinamenerweiterung gespeichert.
\Togwise In diesem Verzeichnis werden Systemnachrichten an Novell GroupWise gespeichert. Systemnachrichten werden zum Anfordern von Verzeichnis- oder Frei-/Gebucht-Informationen von Novell GroupWise verwendet.
\Dxagwise Dieses Verzeichnis enthält Steuerdateien, die bei der Verzeichnissynchronisierung verwendet werden. Steuerdateien sind Schemadefinitionsdateien und Zuordnungsregeldateien, die festlegen, wie die Attribute in einem Verzeichnis einem anderen Verzeichnis zugeordnet werden. Sie können die folgenden Schemadefinitions- und Zuordnungsregeldateien in Editor bearbeiten, um festzulegen, wie die Attribute des einen Verzeichnisses einem anderen Verzeichnis zugeordnet werden:
GWAMAP.TBL Gibt die zu synchronisierenden GroupWise-Schemaattribute an.
MAPMEX.TBL Gibt die Attributzuordnung von Exchange Server 2003 nach Novell GroupWise an.
MEXAMAP.TBL Gibt die zu synchronisierenden Exchange-Schemaattribute an.
MAPWISE.TBL Gibt die Attributzuordnung von Novell GroupWise nach Exchange Server 2003 an.
498
Komponente Beschreibung
Hinweis: Es gibt weitere Steuerdateien für den Connector für Vorgänge zum Überprüfen von Adressaktualisierungen, für die eine Synchronisierung erforderlich ist (EXTERNAL.TBL, GWPCTA.TBL und MEXPCTA.TBL). Bearbeiten Sie diese Dateien nicht, da die Verzeichnissynchronisierung sonst möglicherweise nicht ordnungsgemäß ausgeführt wird und Empfängerobjekte nicht synchronisiert werden.
499
Komponente Beschreibung
Novell GroupWise-API-Gateway Für die Kommunikation mit der Novell GroupWise-Umgebung verwendet Connector für Novell GroupWise das Novell GroupWise-API-Gateway. Hierbei handelt es sich um ein universelles GroupWise-Gateway, das anhand von schlüsselwortbasierten Textdateien mit anderen Messagingsystemen (z. B. Exchange Server 2003) kommuniziert. Das Novell GroupWise-API-Gateway verwaltet eine Ordnerstruktur mit den folgenden Verzeichnissen:
\API_IN Empfängt eingehende Nachrichtenheaderdateien aus Systemen, die nicht von GroupWise stammen.
\API_OUT Enthält ausgehende Nachrichtenheaderdateien an Systeme, die nicht von GroupWise stammen.
\ATT_IN Empfängt eingehende Dateien mit Nachrichtentext und -anlagen aus Systemen, die nicht von GroupWise stammen.
\ATT_OUT Enthält ausgehende Dateien mit Nachrichtentext und -anlagen an Systeme, die nicht von GroupWise stammen.
\WPCSIN Hierbei handelt es sich um die Eingangswarteschlange des GroupWise-MTA, in der eingehende Nachrichten nach der Verarbeitung durch dasAPI-Gateway abgelegt werden.
\WPCSOUT Hierbei handelt es sich um die Ausgangswarteschlange des GroupWise-MTA, in der ausgehende Nachrichten abgelegt werden, bevor sie in schlüsselwortbasierte Textdateien konvertiert und über das API-Gateway in API_OUT und ATT_OUT abgelegt
500
Komponente Beschreibung
Registrierungseinstellungen In der Registrierung werden die Einstellungen für Connector für Novell GroupWise in der folgenden Struktur gespeichert: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LME-GWISE.
DLL für die Proxyadressgenerierung Die DLL für die Proxyadressgenerierung von Connector für Novell GroupWise verfügt über die Bezeichnung Gwxpxgen.dll und befindet sich im Verzeichnis \Programme\Exchsrvr\address\gwise\i386.
addrType-Objekt Der allgemeine Name des addrType-Objekts von Connector für Novell GroupWise in Active Directory lautet GWISE:i386.
msExchConnector-Objekt Im msExchConnector-Objekt von Connector für Novell GroupWise in der Konfigurationsverzeichnispartition von Active Directory werden die meisten Konfigurationseinstellungen für den Connector gespeichert. Die folgenden Attribute gelten speziell für die msExchGroupWiseConnector-Objektklasse, die von der msExchConnector-Objektklasse und der mailGateway-Objektklasse abgeleitet ist:
exportCustomRecipients Gibt an, ob E-Mail-aktivierte Kontakte bei der Verzeichnissynchronisierung an Novell GroupWise weitergegeben werden.
msExchServer1AlwaysCreateAs Gibt an, wie X.500-Objekte synchronisiert werden.
msExchDeliveryOrder Gibt die Verarbeitungsreihenfolge von Nachrichten in der Warteschlange des Connectors an. Die Optionen lauten: FIFO, Priority (Standard) und Size.
msExchExportDLs Gibt an, ob E-
501
Komponente Beschreibung
Mail-aktivierte Verteilergruppen bei der Verzeichnissynchronisierung an Novell GroupWise weitergegeben werden.
msExchPartnerLanguage Gibt die Sprache (Codeseite) für das verbundene Novell GroupWise-Postoffice an.
msExchDirsyncSchedule Gibt die Zeiten an, zu denen die Verzeichnissynchronisierung automatisch durchgeführt wird.
msExchDirsyncStyle Gibt an, ob eine vollständige oder eine inkrementelle Verzeichnissynchronisierung durchgeführt wird.
msExchGWiseAPIGatewayPath Gibt den Pfad zum Verzeichnis des Novell GroupWise-API-Gateways an.
msExchGWiseUserId Gibt den Namen des Kontos an, das von Connector für Novell GroupWise für den Zugriff auf das Verzeichnis des Novell GroupWise-API-Gateways verwendet wird.
msExchEncryptedPassword Gibt verschlüsselt das Kennwort für das Konto an, das von Connector für Novell GroupWise für den Zugriff auf das Verzeichnis des Novell GroupWise-API-Gateways verwendet wird.
msExchExportContainersLinked Gibt den DN (Distinguished Name) der Organisationseinheiten in Active Directory an, die von Connector für Novell GroupWise als Exportcontainer für die Verzeichnissynchronisierung verwendet werden.
502
Komponente Beschreibung
msExchImportContainerLinked Gibt den DN der Organisationseinheit in Active Directory an, die von Connector für Novell GroupWise als Importcontainer für die Verzeichnissynchronisierung verwendet wird.
msExchGWiseForeignDomain Gibt den Namen der Messaging-Fremddomäne an, die in der Novell GroupWise-Umgebung die Exchange-Organisation darstellt.
msExchGWiseFilterType Gibt an, ob ein Filter für das Ein- oder Ausschließen von Adressen bei der Verzeichnissynchronisierung konfiguriert wurde.
msExchDirsyncFilters Gibt den Filter an, der für das Ein- oder Ausschließen von Adressen bei der Verzeichnissynchronisierung verwendet wird.
msExchMaintenanceStyle Gibt die Art der Verwaltung für diesen Connector an.
msExchConnectorType Gibt den Typ des Exchange-Connectors an. Der Wert lautet GWISE.
Verwaltungs-Snap-In Das Erweiterungs-Snap-In für Connector für Novell GroupWise verfügt über die Bezeichnung Exchange GroupWise-Connector. Dieses Snap-In erweitert den Knoten für den Connector, der sich im Exchange-System-Manager unter <Organisationsname>/Administrative Gruppen/<Name der administrativen Gruppe>/Routinggruppen/<Name der Routinggruppe>/Connectors finden.
503
NachrichtenübertragungIn der folgenden Abbildung wird der Vorgang zum Senden von Nachrichten von Exchange Server 2003 an Novell GroupWise veranschaulicht.
Senden von Nachrichten von Exchange Server 2003 an Novell GroupWise
Der Vorgang zum Übertragen von Nachrichten von Exchange Server 2003 an Novell GroupWise setzt sich aus den folgenden vier Schritten zusammen:
1. Exchange Server 2003 ermittelt anhand der Zieladresse des Benutzers, dass der Empfänger ein Novell GroupWise-Benutzer ist, und sendet die Nachricht an den Exchange-MTA.
2. Der MTA überträgt die Nachricht an das Verzeichnis MTS-OUT. Der Prozess Lsmexout.exe ruft sie aus diesem Verzeichnis ab, überprüft Active Directory, ersetzt die Empfängerinformationen durch die entsprechenden GroupWise-Adressen und überträgt die Nachricht dann in den Ordner READYOUT.
504
3. Der Prozess Mex2gw.exe konvertiert die Nachricht in das Novell GroupWise-Format, bevor er sie als Dateien für Nachrichtenheader und -text in den Connector-Informationsspeicher auf dem Server mit Exchange Server 2003 schreibt.
Hinweis: Bei den Dateien für Nachrichtenheader und -text handelt es sich um schlüsselwortbasierte Textdateien, die vom GroupWise-API-Gateway für die Kommunikation mit dem Connector für Novell GroupWise verwendet werden. Zum Lesen und Schreiben von schlüsselwortbasierten Textdateien in der Verzeichnisstruktur des API-Gateways können Sie einen Text-Editor wie Microsoft Editor verwenden.
4. Der Dienst Exchange Router für Novell GroupWise (Gwrouter.exe) platziert die Nachricht in den Verzeichnissen API_IN und ATT_IN des Novell GroupWise-API-Gateways. Bei der Übermittlung in der GroupWise-Organisation arbeitet das Gateway mit einem Novell GroupWise-MTA zusammen.
In der folgenden Abbildung wird der Vorgang zum Senden von Nachrichten von Novell GroupWise an Exchange Server 2003 veranschaulicht.
505
Senden von Nachrichten von Novell GroupWise an Exchange Server 2003
Der Vorgang zum Übertragen von Nachrichten von Novell GroupWise an Exchange Server 2003 setzt sich aus den folgenden vier Schritten zusammen:
1. Exchange Router für Novell GroupWise ruft die Nachricht aus den Verzeichnissen API_OUT und ATT_OUT des Novell GroupWise-API-Gateways als Dateien für Nachrichtenheader und -text ab und speichert sie im Connector-Informationsspeicher.
2. Der Prozess Gw2mex.exe konvertiert die Dateien mit Nachrichtenheader und -text in eine Nachricht im Exchange Server 2003-Format, bevor er sie im Ordner READYIN ablegt.
3. Der Prozess Lsmexin.exe ruft die konvertierte Nachricht aus dem Ordner READYIN ab, überprüft die Gültigkeit des Empfängers (und konvertiert ggf. die Adresse in das Exchange-Format) und überträgt die Nachricht an den Ordner MTS-IN.
506
4. Der Exchange-MTA verarbeitet die Nachricht anschließend im Ordner MTS-IN und platziert sie im Ordner MTS-OUT des SMTP-Diensts, aus dem sie dann an ihr Ziel in der Exchange-Organisation weitergeleitet wird.
NachrichtenkonvertierungNovell GroupWise unterstützt verschiedene spezielle Nachrichtentypen wie E-Mail-Nachrichten, Termine, Notizen, Aufgaben, Formulare, Präsentationen und Dokumente. Die MAPI-Nachrichtentypen werden soweit möglich den entsprechenden Nachrichtentypen in Novell GroupWise zugeordnet. Das bedeutet, dass E-Mail-Nachrichten als E-Mail-Nachrichten angezeigt werden, Besprechungsanfragen als Termine usw. Nachrichtentypen, die in Exchange Server 2003 nicht unterstützt werden, z. B. telefonische Novell GroupWise-Nachrichten, werden in reguläre E-Mail-Nachrichten konvertiert. Connector für Novell GroupWise kann Übermittlungsbestätigungen, Lesebestätigungen und Unzustellbarkeitsberichte nachverfolgen.
Nachrichtenkonvertierung zwischen Novell GroupWise und Exchange Server 2003
Exchange Server 2003-Feature
GroupWise-Feature GroupWise nach Exchange Server 2003
Exchange Server 2003 nach GroupWise
E-Mail-Nachrichten Nachrichten Ja Ja
E-Mail-Lesebestätigung
E-Mail-Lesebestätigung
Ja Ja
Unzustellbarkeitsbericht
Unzustellbarkeitsbericht
Ja Ja
Wichtigkeit Wichtigkeit Ja Ja (niedrige Priorität kann in GroupWise nicht dargestellt werden)
Vertraulichkeit Vertraulichkeit Ja Ja
Besprechungsanfragen
Termine Ja Ja
Besprechungsannahme
Besprechungsannahme
Ja Ja
Besprechungsablehnung
Besprechungsablehnung
Ja Ja
507
Exchange Server 2003-Feature
GroupWise-Feature GroupWise nach Exchange Server 2003
Exchange Server 2003 nach GroupWise
Besprechungsannahme unter Vorbehalt
Besprechungsannahme
Wird als angenommen angezeigt
Wird als angenommen angezeigt
Besprechungsanfrage gelesen
Besprechungsanfrage gelesen
Ja Ja
Übermittlung von Besprechungsanfragen
Übermittlung von Besprechungsanfragen
Ja Ja
Besprechungsaktualisierungen
Besprechungsaktualisierungen
Werden als neue Besprechungsanfragen mit dem Wort „Aktualisiert“ in der Zeile Betreff angezeigt
Werden als neue Besprechungsanfragen mit dem Wort „Aktualisiert“ in der Zeile Betreff angezeigt
Besprechungserinnerungszeiten
Besprechungserinnerungszeiten
Nein Nein
Besprechungsabsagen
Besprechungsabsagen
Nein Ja
Aufgabenanforderungen
Aufgaben Aufgabenanforderungen werden als E-Mail-Nachrichten angezeigt.
Aufgaben werden als
E-Mail-Nachrichten angezeigt
Ganztägige Besprechungsanfragen
Besprechungsanfragen
Ja Werden als Besprechungsanfragen angezeigt. Wenn die Besprechung allerdings mehrere Tage umfasst, wird sie als einzelne Instanz am ersten Tag eingefügt, der Datumsbereich wird im Nachrichtenfeld angezeigt.
508
Exchange Server 2003-Feature
GroupWise-Feature GroupWise nach Exchange Server 2003
Exchange Server 2003 nach GroupWise
Nein Telefonische Nachrichten
Werden als E-Mail-Nachrichten angezeigt
Nein
Andere Nachrichten Andere Nachrichten Werden in der Standardeinstellung in E-Mail-Nachrichten konvertiert
Werden in der Standardeinstellung in E-Mail-Nachrichten konvertiert
Hinweis: Connector für Novell GroupWise unterstützt weder signierte noch verschlüsselte Nachrichten.
Konvertierung des E-Mail-NachrichtentypsE-Mail-Nachrichten aus Exchange oder Novell GroupWise werden in das Format des Zielmessagingsystems konvertiert. Connector für Novell GroupWise verfolgt außerdem die Nachrichtenübertragung mithilfe von Übermittlungsbestätigungen, Lesebestätigungen und Unzustellbarkeitsberichten.
Connector für Novell GroupWise behandelt Besprechungsanfragen und telefonische Nachrichten wie folgt:
Besprechungsanfragen und Termine Exchange-Besprechungsanfragen und Novell GroupWise-Termine werden über Connector für Novell GroupWise übertragen. Aktualisierte Besprechungsanfragen werden in der Betreffzeile als aktualisiert gekennzeichnet. Aufgrund der Einschränkungen des GroupWise-API-Gateways können Besprechungsanfragen, die von Exchange Server 2003-Benutzern an GroupWise-Benutzer gesendet werden, nicht automatisch in Novell GroupWise aktualisiert werden, sondern müssen vom Benutzer manuell aktualisiert werden.
Hinweis: Das API-Gateway unterstützt keine Anfragen für Besprechungsserien von GroupWise, bei denen das AutoDate-Feature verwendet wird. Diese Anfragen für Besprechungsserien werden nicht an Exchange Server 2003 übertragen. Besprechungsserien, die von Exchange Server 2003 an Novell GroupWise übertragen werden, werden einmal im Novell GroupWise-Kalender hinzugefügt, und die Informationen zur Wiederholung werden dann am Anfang des Nachrichtentexts angezeigt. Der Benutzer muss dann selbst darauf achten, wann
509
die Besprechungen stattfinden, oder mehrere Besprechungstermine einzeln in den Kalender eintragen.
Ganztägige Besprechungsanfragen Ganztägige Besprechungsanfragen, die in Exchange Server 2003 erstellt wurden, werden in Novell GroupWise als Besprechungsanfragen angezeigt. Wenn die Besprechung allerdings mehrere Tage umfasst, erstellt der Connector eine einzige Instanz am ersten Tag, und der Datumsbereich wird dann im Nachrichtenfeld angezeigt.
Telefonische Nachrichten Telefonische Novell GroupWise-Nachrichten werden in Exchange Server 2003 als E-Mail-Nachrichten angezeigt.
Konvertierung von E-Mail-NachrichteneigenschaftenDer Connector entfernt RTF-Informationen (Rich Text Format) im Nachrichtentext von Exchange-Nachrichten, da das API-Gateway nur unformatierten Text unterstützt. In Nachrichten von Exchange Server 2003-Clients (Microsoft Office Outlook®) eingebettete Objekte werden in Anlagen konvertiert. Diese Anlagen werden, falls sie über mehr als eine Ebene eingebettet sind, als Anlagen der primären Nachricht angezeigt. Wenn ein Novell GroupWise-Benutzer eine Nachricht mit einer angefügten Nachricht sendet, die weitere Anlagen enthält, werden in Exchange Server 2003 alle Anlagen als einzelne Anlagen der primären Nachricht angezeigt.
E-Mail-Nachrichtenkonvertierung zwischen Novell GroupWise und Microsoft Outlook
Novell GroupWise Microsoft Outlook
Größe Wird richtig konvertiert
Farbe Wird ignoriert.
Fett Wird ignoriert.
Unterstrichen Wird ignoriert.
Kursiv Wird ignoriert.
Durchgestrichen Wird richtig konvertiert.
Tabellen Werden richtig konvertiert, wenn Microsoft Word als primärer E-Mail-Editor in Outlook verwendet wird. In Outlook werden Tabellen nicht richtig konvertiert.
Eingebettete OLE-Objekte, einschließlich Grafiken
Werden richtig konvertiert und können bearbeitet werden.
510
Novell GroupWise Microsoft Outlook
Doppelt durchgestrichen Wird ignoriert.
Hochgestellt Wird ignoriert.
Tiefgestellt Wird ignoriert.
Schattiert Wird ignoriert.
Umriss Wird in kursiv konvertiert.
Relief Wird ignoriert.
Gravur Wird ignoriert.
Kapitälchen Wird ignoriert.
Großbuchstaben Wird ignoriert.
Initiale Wird ignoriert.
Ausgeblendet Wird ignoriert, der Text ist sichtbar.
Unterstreichung, sofern nicht einfach Wird ignoriert.
Nicht als OLE-Objekte eingebettete Bitmaps Werden nicht migriert, die Formatierung geht verloren.
Aufzählungszeichen Werden ignoriert.
Hinweis: Wenn ein Exchange-Benutzer einen GroupWise-Benutzer in einer E-Mail-Nachricht mehrmals angibt (d. h., wenn der Benutzer mehrmals in der Zeile An, Cc oder Bcc vorhanden ist oder mehrmals in der Verteilergruppe angegeben wurde), erhält der GroupWise-Benutzer die E-Mail-Nachricht mehrfach.
VerzeichnissynchronisierungDie Verzeichnissynchronisierung mit Novell GroupWise erfolgt nach einem ähnlichen Muster wie die Verzeichnissynchronisierung mit Lotus Notes. Der Prozess Lsdxa.exe ist für das Steuern der eigentlichen Prozesse für die Verzeichnissynchronisierung verantwortlich. Anstelle von Dxanotes.dll verwendet der Prozess LSDXA allerdings Dxagwise.dll (dies ist der Novell GroupWise-DX-Agent) für die Verzeichnissynchronisierung mit Novell GroupWise. Dxagwise.dll kommuniziert über das Novell GroupWise-API-Gateway sowie den Dienst Exchange Router für Novell GroupWise und mithilfe von GroupWise-Administratornachrichten (Nachrichtentyp = Admin) mit Novell GroupWise. Weitere Informationen zum Konfigurieren der Verzeichnissynchronisierung finden Sie unter Exchange Server 2003 Interoperability and Migration Guide .
511
Hinweis: Connector für Novell GroupWise erstellt für die Empfänger im Novell GroupWise-Messagingsystem E-Mail-aktivierte Kontakte in Active Directory. Die legacyExchangeDN-Adresse (d. h., die X.500-Adresse des Exchange-Benutzers im Exchange 5.5-Format) stimmt im ersten Teil mit der legacyExchangeDN-Adresse des Connectors überein. Der erste Teil ist bei der X.500-Adresse der Teil, der die administrative Gruppe des Connectors angibt (d. h. /O=<Name der Organisation>/OU=<Name der administrativen Gruppe>).
Connector für Novell GroupWise führt bei der Verzeichnissynchronisierung mit Novell GroupWise die folgenden Schritte aus:
1. Dxamex.dll kommuniziert über ADSI mit Active Directory, um die Empfängerinformationen aus den in der Konfiguration des Connectors angegebenen Exportcontainern zu extrahieren.
2. Dxamex.dll ordnet die Empfängerattribute wie in Amap.tbl und Mapmex.tbl definiert zu und speichert die Ergebnisse im Message Interchange-Format (MIF) in einer temporären Datei mit der Bezeichnung Dxagwise.text im Verzeichnis \Programme\Exchsrvr\Conndata\Togwise. Im Folgenden finden Sie ein Beispiel für die Datei Dxagwise.txt:
LoadADOMAIN:POSTOFFICE:OBJECT:LASTNAME:FIRSTNAME:AdministratorDESCRIP:AdministratorACCOUNTID:TITLE:DEPARTMENT:PHONE:FAX:GWADDR:Exchange.First Administrative Group.AdministratorEXCHANGEID:Microsoft Exchange Connector for Novell GroupWise
EndOfBuffer
3. Dxagwise.dll analysiert die Datei Dxagwise.txt, verarbeitet die Adressen und speichert eine Administratornachricht zum Ausführen der Aktualisierungsoperation (Hinzufügen, Ändern oder Löschen von Empfängerobjekten) im Novell GroupWise-Verzeichnis unter \Programme\Exchsrvr\Conndata\Gwrouter\Togwise. Im Folgenden finden Sie ein Beispiel für eine Administratornachricht zum Aktualisieren von Empfängerobjekten im Novell GroupWise-Verzeichnis:
WPC-API= 1.2; Msg-Type= Admin; DS-External-Post-Office= Operation= Add; Domain= EXCHANGE;
512
Post-Office= FIRST ADMINISTRATIVE GROUP; Time-Zone= gmt; ; DS-User= Operation= Modify; Visibility= System; Domain= Exchange; Post-Office= First Administrative Group; Object= Administrator; Last-Name= \\; First-Name= Administrator; Description= Administrator; Account-ID= \\; Title= \\; Department= \\; Phone= \\; Fax= \\; Network-ID= \\; User-Def-5= Microsoft Exchange Connector for Novell GroupWise; ; -END-
4. Der Dienst Exchange Router für Novell GroupWise überträgt die Administratornachricht an das Verzeichnis API_IN des Novell GroupWise-API-Gateways.
5. Das Novell GroupWise-API-Gateway analysiert die Administratornachricht und führt die angegebene Aktion aus.
6. Wenn das Novell GroupWise-API-Gateway eine Administratornachricht mit einer Anforderung für Verzeichnisinformationen empfängt, gibt das API-Gateway die angeforderten Informationen als Administratornachricht zurück. Die Administratornachricht wird als API-Datei im Verzeichnis API_OUT gespeichert. Im Folgenden finden Sie ein Beispiel für eine Administratornachricht mit einer Anforderung für Verzeichnisinformationen vom Novell GroupWise-Verzeichnis:
WPC-API= 1.2;Msg-Type= Admin;-GET-DIRECTORY--END-
7. Der Dienst Exchange Router für Novell GroupWise empfängt die API-Datei und speichert sie im Verzeichnis \Programme\Exchsrvr\Conndata\Gwrouter\Dirsync.
8. Dxagwise.dll analysiert die API-Datei, extrahiert die Empfängerinformationen und schreibt die Aktualisierungen oder die vollständige Liste (vollständiges Laden) in die Datei Dxamex.txt.
9. Dxamex.dll verarbeitet die Datei Dxamex.txt und speichert die Empfängerinformationen in dem in der Konfiguration des Connectors angegebenen Importcontainer.
513
Architektur des Kalender-ConnectorsDer Kalender-Connector unterstützt die Synchronisierung von Frei-/Gebucht-Informationen zwischen Exchange Server 2003 und Lotus Notes oder Novell GroupWise, sodass Benutzer dieser Messagingsysteme beim Erstellen von Besprechungsanfragen die Frei-/Gebucht-Informationen anderer Benutzer abfragen können. Die Anforderungen für den Kalender-Connector ähneln denen für Connector für Lotus Notes und Connector für Novell GroupWise. Diese Connectors müssen in derselben administrativen Gruppe wie der Kalender-Connector installiert sein und sollten vor dem Kalender-Connector konfiguriert werden. Informationen über das Installieren und Konfigurieren des Kalender-Connectors finden Sie im Exchange Server 2003 Interoperability and Migration Guide .
Hinweis: Der Kalender-Connector kann nicht zu einer administrativen Gruppe ohne Server gehören (d. h. einer administrativen Gruppe, bei der einzelne Administratoren in einer Routinggruppe definiert werden), da in diesem Fall kein Server zum Speichern der Frei-/Gebucht-Informationen vorhanden ist. Der Kalender-Connector muss auf einem Server mit Exchange Server 2003 und mit einer Instanz des Öffentlichen Ordners mit Frei-/Gebucht-Informationen für die lokale administrative Gruppe installiert werden.
Frei-/Gebucht-InformationenFrei/Gebucht bezieht sich auf bestimmte Informationen, die von einem Messagingclient für einen Benutzer veröffentlich werden. Diese Informationen bestehen aus den persönlichen Verfügbarkeitsdaten des Benutzers, die anhand des Inhalts des Kalenderordners im entsprechenden Postfach bestimmt werden. Frei-/Gebucht-Daten werden insbesondere für das Planen von Besprechungen verwendet. Die Frei-/Gebucht-Daten werden in einem festgelegten Öffentlichen Systemordner gespeichert. Jede administrative Gruppe in der Exchange-Organisation beinhaltet einen Frei-/Gebucht-Ordner.
Sie müssen den Kalender-Connector auf einem Server mit Exchange Server installieren, der über ein Replikat des Frei-/Gebucht-Systemordners für die administrative Gruppe verfügt. Die Frei-/Gebucht-Daten können in der Exchange-Organisation auf einen beliebigen Server für Öffentliche Ordner repliziert oder auf einem einzelnen Server mit Exchange Server gespeichert werden. Innerhalb der Organisation werden die Frei-/Gebucht-Daten mithilfe der Standardreplikation für Öffentliche Ordner repliziert.
Sie müssen den Kalender-Connector auf einem Server mit Exchange Server installieren, der über ein Replikat des Frei-/Gebucht-Systemordners für die administrative Gruppe verfügt. Ausführliche Anleitungen finden Sie unter Prüfen des Vorhandenseins eines Replikats des Frei-/Gebucht-Systemordners für die administrative Gruppe auf einem Server mit Exchange Server.
514
Hinweis: Der Kalender-Connector benötigt Berechtigungen für das Lesen und Erstellen von Elementen im Frei-/Gebucht-Systemordner. Klicken Sie in den Eigenschaften des Frei-/Gebucht-Ordners für die lokale administrative Gruppe auf die Registerkarte Berechtigungen, und klicken Sie dann auf Clientberechtigungen. Überprüfen Sie im Dialogfeld Clientberechtigungen, ob dem Konto Standard die Rolle Herausgeber zugeordnet ist.
Veröffentlichen von Frei-/Gebucht-DatenDas Veröffentlichen von Frei-/Gebucht-Daten ist ein Clientvorgang, der von Outlook und Outlook Web Access durchgeführt wird. Der Exchange-Informationsspeicher ist, mit Ausnahme eines Öffentlichen Systemordners in einem Informationsspeicher für Öffentliche Ordner, der für das Speichern und Veröffentlichen von Daten verwendet wird, an diesem Vorgang nicht beteiligt.
Hinweis: Für das Replizieren von Frei-/Gebucht-Daten zwischen Exchange-Organisationen wird das Tool Exchsync mit einigen zusätzlichen Einstellungen verwendet.
Outlook empfängt zunächst einen Verweis vom Postfachserver für den zugeordneten Öffentlichen Ordner für Frei-/Gebucht-Informationen. Nachdem der Server gefunden wurde, wird mithilfe der Eigenschaften des Benutzerobjekts in Active Directory die Frei-/Gebucht-Nachricht im Öffentlichen Ordner gesucht.
Frei-/Gebucht-NachrichtenJede Frei-/Gebucht-Nachricht ist eine Darstellung der gebuchten und ungebuchten Tage und Zeiten für eine einzelne Person oder Ressource. Diese wird durch eine Folge von Zahlen auf dem Frei-/Gebucht-Server (ein Server für Öffentliche Ordner mit Replikaten eines oder mehrerer Frei-/Gebucht-Ordner) repräsentiert.
Eine Darstellung ist z. B. 002222000033333333, wobei jede Ziffer eine Erhöung um X Minuten darstellt (wie in der Anforderung angegeben, dabei sind 6 Minuten die kleinste Einheit). Die Interpretation der Zahlen wird in der folgenden Tabelle erläutert.
Frei-/Gebucht-Nachrichten
Zahl Bedeutung
0 Frei
1 Mit Vorbehalt
2 Gebucht
515
Zahl Bedeutung
3 Abwesend
Wenn mehrere Termine in einem Zeitrahmen vorhanden sind, wird der Termin mit der höchsten Statusnummer ausgewählt. Ein Zeitrahmen mit einem Termin mit dem Status "Abwesend" (3) und einem Termin mit dem Status "Mit Vorbehalt" (1) erhält den Status "Abwesend" (3).
Genauer gesagt werden Frei-/Gebucht-Daten in mehreren Gruppen von Arrays mit mehrwertigen Ganzzahlen gespeichert. Jede Gruppe stellt eine Gebucht-Klassifizierung dar (Gebucht, Mit Vorbehalt oder Abwesend), und jedes Element in der Gruppe stellt die Daten für einen Monat dar. Das Array selbst ist eine Gruppe von Paaren, in dem jedes Paar die Anzahl der Minuten im Monatsverlauf darstellt, die den Anfang und das Ende des gebuchten Zeitraums repräsentieren und die an die Zeitzone entsprechend der internationalen Datumsgrenze angepasst sind. Daten für freie Zeiten werden nicht gespeichert, sondern einfach als die Zeit berechnet, die nicht als gebucht gekennzeichnet ist.
Mit dem Termin wird auch der Anfangsmonat und die Anzahl der Monate gespeichert, sodass Clients entsprechende Berechnungen durchführen können.
Generieren von Frei-/Gebucht-DatenEs gibt verschiedene Möglichkeiten, Frei-/Gebucht-Daten zu generieren. Outlook ändert z. B. die Frei-/Gebucht-Einträge eines Benutzers beim Speichern von Kalendereinträgen und veröffentlicht diese Nachricht mit MAPI regelmäßig auf dem Server mit Exchange Server. Outlook Web Access- und Outlook Mobile Access-Clients generieren ebenfalls Frei-/Gebucht-Einträge beim Speichen von Kalendereinträgen. Von dort sendet Outlook Web Access oder Outlook Mobile Access die Nachricht mithilfe von Datenobjekten für die Zusammenarbeit (CDO – Collaboration Data Object) und WebDAV an die Systemaufsicht, die für die weitere Verarbeitung und Veröffentlichung auf dem Server mit Exchange Server verantwortlich ist.
Veröffentlichen von Frei-/Gebucht-Informationen in OutlookOutlook veröffentlicht Frei/Gebuch-Daten für Benutzer regelmäßig (in der Standardeinstellung alle 15 Minuten) sowie beim Herunterfahren. Bei jeder Veröffentlichung von Frei-/Gebucht-Informationen werden nicht nur die Änderungen, sondern der gesamte Frei-/Gebucht-Eintrag aktualisiert. Benutzer können die Anzahl der Monate angeben, die Frei-/Gebucht-Informationen im Voraus auf dem Server veröffentlicht werden sollen. Der Standardwert sind 2 Monate, wobei 36 Monate der Maximalwert ist. In der Standardeinstellung werden die Frei-/Gebucht-Daten rückwirkend für einen Monat veröffentlicht.
516
Bei einer Veröffentlichung bestimmt Outlook zunächst mithilfe des Werts von legacyExchangeDN des Benutzers den Ordner, in dem die Frei-/Gebucht-Daten veröffentlicht werden sollen. Der legacyExchangeDN-Wert besteht aus zwei Teilen: Der erste Teil bestimmt den Pfad des Frei-/Gebucht-Ordners (auch die administrative Gruppe, in der der Benutzer erstellt wurde, da der Wert von legacyExchangeDN nicht geändert wird, wenn Benutzerpostfächer zwischen administrativen Gruppen verschoben werden). Der zweite Teil ist der Betreff der Frei-/Gebucht-Nachricht. Der Speicherort der Frei-/Gebucht-Daten des Benutzers, der den legacyExchangeDN-Wert /o=Contoso/ou=CorpUsers/cn=Recipients/cn=UserName besitzt, ist der Ordner EX:/o=Constso/ou=CorpUsers, und die Nachricht hat den Betreff User-/cn=Recipients/cn=UserName.
Beim Frei-/Gebucht-Ordner handelt es sich um ein Unterverzeichnis des Ordners Schedule+ Frei/Gebucht unter NON_IPM_SUBTREE. Der Nachrichtenbetreff lautet USER-/cn=RECIPIENTS/cn=UserName. Wenn eine doppelte Frei-/Gebucht-Nachricht erstellt wird, fügt der Informationsspeicher automatisch das Suffix -2 an die URL der Nachricht an. Daher wird USER-/cn=RECIPIENTS/cn=UserName zu USER-/cn=RECIPIENTS/cn=UserName-2. Diese Verdopplung von Nachrichten tritt nicht häufig auf, kann aber aufgrund von Clientfehlerm, Replikationsfehlern usw. verursacht werden. Wenn Outlook beim Veröffentlichen von Daten doppelte Einträge für einen Benutzer ermittelt, löscht es diese. Der Veröffentlichungs-Agent der Systemaufsicht für Frei-/Gebucht-Informationen löscht ebenfalls doppelte Einträge, wenn er die Frei-/Gebucht-Informationen für Outlook Web Access oder Outlook Mobile Access aktualisiert.
Nachdem Outlook ermittelt hat, an welcher Stelle die Nachricht im Informationsspeicher für Öffentliche Ordner veröffentlicht werden soll, wählt es einen Frei-/Gebucht-Server aus. Die folgenden Schritte werden ausgeführt:
1. Bei der ersten Anmeldung informiert der Server den Client über den Server mit der Standardhierarchie. Diese Informationen werden im Benutzerprofil gespeichert. Wenn der Administrator die Einstellungen im Exchange-System-Manager ändert, muss sich der Benutzer ab- und wieder anmelden, um den neuen Wert zu erhalten. Anschließend stellt der Client die erste Verbindung mit diesem Server her und hält die Verbindung für die Dauer der Benutzersitzung aufrecht.
2. Der MAPI-Client fragt eine Hierarchietabelle für den Stamm des Informationsspeichers für Öffentliche Ordner ab. Diese Anforderung wird an den konfigurierten Standardinformationsspeicher für Öffentliche Ordner gesendet, und die auf Stammebene des Informationsspeichers für Öffentliche Ordner gespeicherten Ordner werden an den Client zurückgegeben.
3. Der Client durchläuft die Ordnereinträge in dieser Tabelle, um den gewünschten Ordner zu finden. Wenn dies erforderlich sein sollte, öffnet der Client nacheinander die Unterordner und deren Tabelle der Unterordner, um auch diese zu durchlaufen.
4. Nachdem der MAPI-Client den gewünschten Ordner ermittelt hat, fordert er das Inhaltsverzeichnis dieses Ordners an.
517
5. Der Dienstanbieter fragt den Server nach einer Liste von Inhaltsreplikaten für den Ordner ab.
6. Der Server ruft die Replikatliste für den Ordner aus der Datenbank ab und sortiert diese basierend auf den Connectorkosten für die Routinggruppe des Servers. Die anderen Inhaltsreplikate in derselben Routinggruppe wie der abgefragte Server weisen für die Connectorkosten den Wert Null (0) auf.
7. Die sortierte Liste wird zusammen mit der Anzahl der Einträge in der Servergruppe mit den niedrigsten Kosten an den Client zurückgegeben.
8. Wenn der Server, mit dem der Client bereits verbunden ist, im Replikatsatz enthalten ist (d. h. seine Kosten sind ebenfalls Null), wird die Suche nach Inhaltsreplikaten abgeschlossen. Fahren Sie mit Schritt 10 fort.
9. Auf den Wert von legacyDN für den Benutzer wird ein Hash angewendet, dessen Ergebnis dann durch die Anzahl der Server mit den niedrigsten Kosten dividiert wird. Der Divisionsrest wird zum Indizieren der zurückgegebenen Serverliste und zum Auswählen eines Servers verwendet, mit dem eine Verbindung hergestellt wird.
10. Der Dienstanbieter versucht, eine Verbindung mit dem ausgewählten Server herzustellen. Wenn die Verbindung hergestellt werden kann, ist der gesamte Vorgang abgeschlossen, und der Server gibt das Inhaltsverzeichnis an den MAPI-Client zurück.
11. Wenn die Verbindung nicht hergestellt werden kann oder der Server zurückgibt, dass er kein Replikatserver ist (der Replikatsatz wurde möglicherweise geändert, und die Änderung wurde noch nicht auf dem Server repliziert, von dem die Replikatliste abgerufen wurde), entfernt der Dienstanbieter diesen Server aus der Liste, verringert die Anzahl der Server mit den niedrigsten Kosten und beginnt, sofern die Anzahl nicht Null (0) ist, wieder bei Schritt 9.
12. Wenn die Liste der Server mit den niedrigsten Kosten leer ist, wird die Anzahl auf die Anzahl der verbleibenden Server in der Liste zurückgesetzt, der Vorgang wird ab Schritt 9 wiederholt. Wenn die gesamte Liste leer ist, wird ein Fehler an den MAPI-Client zurückgegeben.
Hinweis: Diese Schritte werden immer ausgeführt, unabhängig davon, welchen Ordner der Client abfragt (Offlineadressbuch, Frei/Gebucht oder einen anderen Ordner) oder aus welchem Grund der Inhalt des Ordners benötigt wird.
518
Veröffentlichen von Frei-/Gebucht-Informationen in Outlook Web Access und Outlook Mobile AccessDa Outlook Web Access und Outlook Mobile Access MAPI nicht verwenden, können sie Frei-/Gebucht-Daten nicht direkt im Informationsspeicher für Öffentliche Ordner veröffentlichen. Sie sind stattdessen auf einen Veröffentlichungs-Agenten für Frei-/Gebucht-Informationen (MadFB) angewiesen, der im Systemaufsichtsprozess (Mad.exe) ausgeführt wird.
MadFB hat zwei Funktionen:
Veröffentlichen von Frei-/Gebucht-Nachrichten für Outlook Web Access und Outlook Mobile Access
Löschen doppelter Frei-/Gebucht-Nachrichten
Als Teil der Transaktion für das Erstellen, Löschen oder Aktualisieren eines Termins, bei der die Anfangs- oder Endzeit geändert wird, sendet ein serverseitiger Aufruf eine Frei-/Gebucht-Aktualisierungsnachricht an das Postfach der Systemaufsicht. MadFB gehört zur Systemaufsicht und verarbeitet diese Nachrichten, um die Frei-/Gebucht-Daten im Öffentlichen MAPI-Ordner zu aktualisieren. Abhängig vom Nachrichtenabrufintervall der Systemaufsicht kann es zu einer Verzögerung von bis zu 15 Minuten kommen, bevor die aktualisierten Frei-/Gebucht-Daten veröffentlicht werden.
Der Veröffentlichungsprozess von MadFB entspricht dem bereits beschriebenen Veröffentlichungsprozess von Outlook. Daher wird an doppelte Nachrichten eine Zahl angefügt. Obwohl der Prozess in Outlook Web Access und Outlook Mobile Access dem von Outlook ähnelt, ist er bei Outlook Web Access und Outlook Mobile Access allgemein zuverlässiger, da die gesamte Verarbeitung auf Servern mit Exchange Server erfolgt.
Suchen von Frei-/Gebucht-DatenBeim Suchen von Frei-/Gebucht-Daten geht Outlook anders als Outlook Web Access und Outlook Mobile Access vor. Dies wird im Folgenden beschrieben. Bei allen Clients beinhaltet dieser Vorgang aber das Suchen des Öffentlichen Ordners mit den Frei-/Gebucht-Informationen und das anschließende Zugreifen auf die Frei-/Gebucht-Daten eines bestimmten Benutzers in diesem Ordner.
Outlook Bevor Outlook den Öffentlichen Ordner mit den Frei-/Gebucht-Informationen sucht, empfängt es zuerst einen Verweis vom Postfachserver für den entsprechenden Informationsspeicher für Öffentliche Ordner, den der Frei-/Gebucht-Server daraufhin abfragt (der Verweis und die Abfrage entsprechen dem Veröffentlichungsvorgang). Die Frei-/Gebucht-Daten werden als Nachrichten im Standortordner im Hauptordner für Frei-/Gebucht-Informationen gespeichert. Outlook ermittelt mithilfe von Active Directory
519
und Exchange Server den Wert von legacyExchangeDN für den Benutzer und analysiert diesen in zwei Teilen. Der erste Teil ist der Name des Standortordners. Der zweite Teil ist der Betreff der Nachricht.
Outlook Web Access und Outlook Mobile Access Diese Clients führen eine DAV-Abfrage für den anderen Benutzer durch, rufen die Frei-/Gebucht-Informationen ab und zeigen diese dann dem Benutzer an. Die DAV-Abfrage wird vom Server mit dem Dienst Outlook Web Access oder Outlook Mobile Access (dies ist häufig der Front-End-Server) auf dem Postfachserver des Benutzers (Back-End-Server) ausgeführt, auf dem die eigentliche Suche der Frei-/Gebucht-Daten erfolgt.
Hinweis: Damit Sie nach Frei-/Gebucht-Daten suchen können, müssen die Empfängerinformationen in Active Directory verfügbar sein, um den Zielsystemordner mit den Frei-/Gebucht-Daten zu bestimmen. Daher müssen Sie die Verzeichnissynchronisierung mit Lotus Notes oder Novell GroupWise aktivieren, wenn Sie Frei-/Gebucht-Informationen mit dem Kalender-Connector synchronisieren möchten. Wie bereits erwähnt erstellen Connector für Lotus Notes und Connector für Novell GroupWise E-Mail-aktivierte Kontakte mit einer legacyExchangeDN-Adresse, die der lokalen administrativen Gruppe des Connectors entspricht. Aufgrund dieser Abhängigkeit muss der Kalender-Connector in derselben administrativen Gruppe wie Connector für Lotus Notes bzw. Connector für Novell GroupWise installiert sein. Sie sollten den Kalender-Connector auf demselben Server wie Connector für Lotus Notes oder Connector für Novell GroupWise installieren.
Veröffentlichungs-Agent für Frei-/Gebucht-Informationen (MadFB)MadFB ermöglicht Outlook Web Access und Outlook Mobile Access das Veröffentlichen von Frei-/Gebucht-Daten. Als zweite Funktion löscht MadFB veraltete Frei-/Gebucht-Daten. In der Standardeinstellung verwaltet MadFB Frei-/Gebucht-Daten auf allen Servern mit Exchange Server, die keine Front-End-Server sind, täglich um 2:00 Uhr. MadFB verwaltet auf jedem Server die Standardinformationsspeicher für Öffentliche Ordner, die den lokalen Postfachspeichern der einzelnen Server zugeordnet sind (selbst wenn diese Informationsspeicher für Öffentliche Ordner auf einem anderen Server gespeichert sind). MadFB wird im Prozess der Systemaufsicht ausgeführt.
Zum Verwaltungsvorgang von MadFB gehört Folgendes:
Korrigieren der URLs von Frei-/Gebucht-Einträgen Ein Frei-/Gebucht-Eintrag muss in kanonischer Form vorliegen. Das bedeutet, dass der Eintrag über eine URL-Endung mit einem normalisierten Betreff wie USER-/CN=RECIPIENTS/CN=TED verfügen muss. Einträge können aufgrund von Duplikaten nicht in kanonischer Form auftreten. Einer URL
520
könnte beispielsweise zur Unterscheidung ein -x angefügt werden, oder eine der URLs könnte auf einen Eintrag verweisen, der von Exchange Server 5.5 aktualisiert oder repliziert wurde, wodurch die URL dann einen GUID enthält. Der normalisierte Betreff wird durch den letzten Teil des Werts von legacyDN bestimmt (z. B. CN=RECIPIENT,CN=TED).
Löschen doppelter Frei-/Gebucht-Nachrichten Outlook kann doppelte Frei-/Gebucht-Nachrichten erstellen. Um das Überschreiben vorhandener Nachrichten zu verhindern, fügt der Exchange-Informationsspeicher ein –X (dabei ist x ein Zähler für die Duplikate) an den normalisierten Betreff an. MadFB löscht Nachrichten mit Betreffzeilen, die nicht in kanonischer Form vorliegen.
MadFB behält die Nachricht mit dem ältesten Datum bei und löscht die anderen Nachrichten. Damit wird eine genaue Replikation sichergestellt, bei der doppelte Einträge immer gelöscht werden. Wenn MadFB z. B. die neueste Nachricht beibehält und die anderen Nachrichten löscht, wird die Konfliktnachricht [X-2] bei der Replikation beibehalten. Die Ursache hierfür ist, dass X an PF1 und X-2 an PF2 zuerst gelöscht und die neueren Versionen von X-2 an PF1 und X an PF2 repliziert werden. Daher werden diese zu den neuesten Einträgen, und der Zyklus wiederholt sich.
Hinweis: MadFB ist identisch mit MSExchangeFBPublish, dem Quellnamen im Ereignisprotokolleintrag, der für das Protokollieren von Ereignissen im Ereignisprotokoll verwendet wird.
Bereinigen von Frei-/Gebucht-DatenEs gibt drei Möglichkeiten, unerwünschte Frei-/Gebucht-Daten zu entfernen. Sie können beim Starten von Outlook einen Befehlszeilenschalter verwenden, Sie können einen serverseitigen Prozess auf dem Server mit Exchange Server durchführen, oder Sie können Einträge manuell mit Outlook Web Access löschen.
Outlook-StartschalterDer Befehlszeilenschalter /cleanfreebusy für das Starten von Outlook wird zum Lösen von Terminplanungsproblemen für Besprechungen verwendet. Dieser Schalter hilft nicht bei allgemeinen Terminproblemen, da er nicht den Frei-/Gebucht-Eintrag aus dem Informationsspeicher für Öffentliche Ordner löscht, sondern die lokale Frei-/Gebucht-Nachricht (LocalFreeBusy), die vom Outlook-Client generiert wurde. Die LocalFreeBusy-Nachricht befindet sich als verborgener Eintrag im Kalenderordner des Benutzers im Postfach auf dem Server. Dieser Eintrag ist ein großes Binärobjekt mit den Frei-/Gebucht-Informationen des Benutzers, mit Informationen über Stellvertreter, die Termine für den Benutzer planen dürfen, und mit Einstellungen für die automatische Bestätigung. Ressourcenpostfächer sind i. d. R. so konfiguriert, dass sie Besprechungsanfragen
521
automatisch bestätigen, wenn kein Konflikt mit vorhandenen Terminen besteht. Der LocalFreeBusy-Eintrag wird im Informationsspeicher für Öffentliche Ordner repliziert, sodass alle Benutzer in der Exchange-Organisation die Frei-/Gebucht-Informationen überprüfen und für die Besprechungsplanung verwenden können.
Wenn Stellvertreter beim Versuch, den Manager-Kalender zu ändern, eine Fehlermeldung erhalten, setzt das Ausführen von /cleanfreebusy, während die Stellvertreter Outlook geschlossen haben, bestimmte Eigenschaften für den Manager-Kalender im Informationsspeicher für Öffentliche Ordner des Managers zurück. Wenn die Stellvertreter Outlook das nächste Mal starten, erhalten Sie neue Frei-/Gebucht-Informationen vom LocalFreeBusy-Eintrag des Managers, wodurch die meisten Fehler der Stellvertreter behoben werden.
Die Ursache dieses Problems bei der Terminplanung durch Stellvertreter ist, dass der Stellvertreterclient aus verschiedenen Gründen die Frei-/Gebucht-Nachricht neu erstellt, wodurch Verweise auf die gelöschte Nachricht entstehen. Wenn der Manager Outlook in diesem Zustand mit /cleanfreebusy startet, stellt der Manager-Client die lokale Frei-/Gebucht-Nachricht wieder her und gibt in den Stammordnern die neue Eintrags-ID an, wodurch jeder Benutzer wieder auf die lokale Frei-/Gebucht-Nachricht zugreifen kann.
Bereinigen mit Outlook Web AccessDie Frei-/Gebucht-Nachrichten befinden sich in der Hierarchie der Öffentlichen Ordner außerhalb der IPM-Unterstruktur in einem Öffentlichen Ordner im Container SCHEDULE+ FREI-/GEBUCHT. Diese Nicht-IPM-Unterstruktur ist ausgeblendet, aber Sie können mit Outlook Web Access auf die Struktur zugreifen und den Frei-/Gebucht-Ordner einer administrativen Gruppe öffnen. Auf diese Weise können Frei-/Gebucht-Einträge manuell gelöscht werden. Wenn Sie z. B. auf die Nicht-IPM-Unterstruktur auf dem Server Server01 zugreifen möchten, verwenden Sie den folgenden URL: http://server01/public/non_ipm_subtree/. Der Container SCHEDULE+ FREI/GEBUCHT wird als normaler Öffentlicher Ordner angezeigt. In diesem Ordner finden Sie die Frei-/Gebucht-Ordner.
Komponenten des Kalender-ConnectorsDa der Kalender-Connector keine E-Mail-Nachrichten zwischen Exchange und Lotus Notes oder Novell GroupWise überträgt, verfügt er im Exchange-Informationsspeicher über kein Connector-Postfach, über keine DLL für die Proxyadressgenerierung und über kein addrType-Objekt in Active Directory. Trotzdem ist der Kalender-Connector ein MAPI-Connector, da er für die Kommunikation mit dem Exchange-Informationsspeicher MAPI und für die Kommunikation mit Active Directory ADSI (Active Directory Service Interfaces) verwendet.
Die folgende Tabelle zeigt wichtige Komponenten des Kalender-Connectors.
522
Komponenten des Kalender-Connectors
Komponente Beschreibung
Connector-Dienst CalCon.exe ist die wichtigste ausführbare Datei des Connector-Diensts für Lotus Notes. Diese lädt verschiedene Komponenten, die als Anbieter bezeichnet werden und die eigentlichen Aufgaben bei der Synchronisierung von Frei-/Gebucht-Informationen ausführen. Alle Dateien befinden sich im Verzeichnis \Programme\Exchsrvr\Bin.
Adminsvc.dll Der Kalender-Connector lädt Adminsvc.dll für Verwaltungsaufgaben, z. B. das regelmäßige Abfragen von Anbietern für Berichte zum Zustand des Connectors und zum Sammeln von Statistiken und Leistungsdaten, die dann mit dem Systemmonitor angezeigt werden können.
Calsync.dll Der Kalender-Connector lädt Calsync.dll beim Start, um Active Directory nach Nicht-Exchange-Empfängern zu durchsuchen, die der Connector für Lotus Notes und der Connector für Novell GroupWise während der Verzeichnissynchronisierung erstellen. Der als Basis für diese Suche vom Kalender-Connector verwendete MAPI-Connector wird im Exchange-System-Manager in der Konfiguration des Kalender-Connectors auf der Registerkarte Allgemein angegeben. Calsync.dll stellt sicher, dass für jeden in Active Directory gefundenen Nicht-Exchange-Empfänger ein Frei-/Gebucht-Datensatz im Systemordner für Frei-/Gebucht-Informationen enthalten ist. Die Frei-/Gebucht-Datensätze sind bei der Initialisierung leer.
523
Komponente Beschreibung
Hinweis: Sie sollten den Kalender-Connector für die Ausführung nach jeder Verzeichnissynchronisierung konfigurieren, damit Calsync.dll für neue Empfängerobjekte sofort Frei/Gebucht-Einträge erstellen kann. Den Zeitplan können Sie im Kalender-Connector auf der Registerkarte Zeitplan konfigurieren.
Mapical.dll Der Kalender-Connector lädt Mapical.dll für die Kommunikation mit dem Exchange-Informationsspeicher. Mapical.dll füllt die Frei-/Gebucht-Datensätze von Nicht-Exchange-Empfängern auf, wenn Exchange-Benutzer Frei-/Gebucht-Informationen abfragen.
Hinweis: Der Kalender-Connector generiert nur dann eine Anforderung an das Nicht-Exchange-Messagingsystem, wenn die aktuellen Informationen nicht im Systemordner für Frei-/Gebucht-Informationen verfügbar sind oder die Zeit für das Aktualisierungsintervall überschritten wurde. Die Anzahl der angeforderten Tage, die Aktualisierungshäufigkeit und die Antwortzeit werden auf der Registerkarte Allgemein des Kalender-Connectors ausgewählt. Wenn die Aktualisierungshäufigkeit auf 0
524
Komponente Beschreibung
festgelegt wurde, wird bei jeder Clientanfrage für Frei-/Gebucht-Informationen über den Kalender-Connector eine Anforderung für aktualisierte Informationen an das andere Messagingsystem gesendet.
Notescal.dll Das Verfahren, mit dem der Kalender-Connector Frei-/Gebucht-Anforderungen generiert und handhabt, ist von dem System abhängig, an das die Anforderung gesendet wird. Wenn der Kalender-Connector Frei-/Gebucht-Informationen mit Lotus Notes synchronisieren muss, verwendet er Notescal.dll, um Anforderungen an Lotus Notes zu generieren und zu übertragen und um auf Frei-/Gebucht-Abfragen von Lotus Notes-Benutzern zu antworten.
Hinweis: Der maximale Zeitraum, für den ein Exchange-Benutzer Frei-/Gebucht-Informationen von Lotus Notes anfordern kann, beträgt 208 Tage.
Gwisecal.dll Wenn der Kalender-Connector Frei-/Gebucht-Informationen mit Novell GroupWise synchronisieren muss, verwendet er Gwisecal.dll, um Anforderungen an Novell GroupWise zu generieren und zu übertragen und um auf Frei-/Gebucht-Abfragen von Novell GroupWise-Benutzern zu antworten.
Hinweis: Der maximale Zeitraum, für den ein Exchange-Benutzer Frei-/Gebucht-Informationen von Novell GroupWise anfordern kann, beträgt
525
Komponente Beschreibung
Exchange-Kalender-Connector-Add-In Das Exchange-Kalender-Connector-Add-In (ExCalCon.exe) ist eine Komponente, die auf dem Lotus Notes- und Domino-Server installiert werden muss, den der Connector für Lotus Notes und der Kalender-Connector als Nicht-Exchange-Bridgeheadserver verwenden. ExCalCon.exe empfängt Frei-/Gebucht-Anforderungen von Lotus Notes über den Schedule Manager von Lotus Notes und leitet diese an die Instanz des Kalender-Connectors weiter, die auf einem Server mit Exchange Server ausgeführt wird.
Registrierungseinstellungen In der Registrierung werden die Einstellungen für den Connector für Lotus Notes in der folgenden Struktur gespeichert: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeCalCon.
msExchConnector-Objekt Im msExchConnector-Objekt für den Kalender-Connector in der Konfigurationsverzeichnispartition von Active Directory werden die meisten Konfigurationseinstellungen für den Connector gespeichert. Die folgenden Attribute gelten speziell für die msExchCalendarConnector-Objektklasse, die von der msExchConnector-Objektklasse und der mailGateway-Objektklasse abgeleitet ist.
Das msExchCalendarConnector-Objekt hat die folgenden für den Kalender-Connector spezifischen Attribute:
msExchCalConQueryWindow Gibt die Zeit an, die der Kalender-Connector auf eine Antwort des anderen Messagingsystems auf eine Frei-/Gebucht-Anforderung wartet. Nach
526
Komponente Beschreibung
Ablauf dieser Zeit gibt der Kalender-Connector die zurzeit im Frei-/Gebucht-Datensatz vorhandenen Informationen an den Exchange-Benutzer zurück.
Wenn die Antworten zu spät kommen, gibt Exchange Server 2003 die vorhandenen Daten an den Outlook-Client zurück. Wenn die neuen Daten empfangen werden, aktualisiert der Kalender-Connector den Frei-/Gebucht-Datensatz des Nicht-Exchange-Benutzers. Die aktualisierten Informationen werden nicht an den Outlook-Client zurückgegeben, und der Benutzer erhält keinen Hinweis darauf, dass die Frei-/Gebucht-Informationen möglicherweise nicht die neuesten Aktualisierungen enthalten oder dass ggf. mit einer späteren Abfrage aktuellere Informationen verfügbar sind.
msExchCalConRefreshInterval Gibt den Zeitrahmen an, in dem der Kalender-Connector die Frei-/Gebucht-Datensätze von Nicht-Exchange-Benutzern als aktuell ansieht. Innerhalb des Werts von msExchCalConRefreshInterval gibt der Kalender-Connector die vorhandenen Daten an den Outlook-Client zurück, ohne eine Frei-/Gebucht-Anforderung an das andere Messagingsystem zu senden.
msExchCalConProviders Gibt die Anbieter an, die der Kalender-Connector für die Verarbeitung lädt, dazu gehören z. B. NOTECAL, GWISECAL, MAPICAL, ADMINSVC und CALSYNC.
527
Komponente Beschreibung
msExchCalConClientWait Gibt an, wie lange der Kalender-Connector auf eine Antwort auf eine Frei-/Gebucht-Anforderung wartet, bevor er diese löscht.
msExchConnectorType Gibt als Connectortyp Kalender an.
msExchCalConTargetSiteDN Gibt den DN (Distinguished Name) des Connectorobjekts, das der Kalender-Connector für die Kommunikation mit dem anderen Messagingsystem verwendet, im Exchange 5.5-Verzeichnisformat an.
Außerdem enthält das msExchCalendarConnector-Objekt die folgenden Attribute in Abhängigkeit von dem Messagingsystem ohne Exchange, mit dem der Kalender-Connector kommuniziert:
msExchNotesNotesServer Gibt den Namen des Lotus Notes- und Domino-Servers (im Notes-Format) an, den der Connector als Nicht-Exchange-Bridgeheadserver verwendet.
msExchNotesNotesINI Gibt den vollständigen Pfad und den Dateinamen der INI-Datei des Lotus Notes-Clients an, mit der sich der Connector am Lotus Notes- und Domino-Server anmeldet.
msExchEncryptedPassword Gibt verschlüsselt das Kennwort des Kontos an, das der Kalender-Connector für die Kommunikation mit dem anderen Messagingsystem Exchange verwendet.
528
Komponente Beschreibung
msExchGWiseAPIGateway Gibt den Namen des Verzeichnisses des Novell GroupWise-API-Gateways an, den der Kalender-Connector für die Kommunikation mit Novell GroupWise verwendet.
Verwaltungs-Snap-In Das Erweiterungs-Snap-In für den Kalender-Connector hat die Bezeichnung Exchange Kalender-Connector. Dieses Snap-In ist in Exadmin.dll implementiert und erweitert den Knoten für den Connector, den Sie im Exchange-System-Manager unter <Organisationsname>/Administrative Groupd/<Name der administrativen Gruppe>/Routing Groups/<Name der Routinggruppe>/Connectors finden.
Frei-/Gebucht-Suchen mit Lotus NotesDie folgende Abbildung zeigt, wie der Kalender-Connector in die Lotus Notes-Messagingumgebung integriert wird.
529
Synchronisieren von Frei-/Gebucht-Informationen mit Lotus Notes
Innerhalb des Kalender-Connectors kommuniziert Notescal.dll mit Lotus Notes und Domino über die Lotus Notes-Client-API, um Anforderungen für Frei-/Gebucht-Informationen von Lotus Notes an den Lotus Notes-Task Schedule Manager zu übertragen. Der Schedule Manager ist ein Task, der auf einem Lotus Domino-Server ausgeführt wird und die Lotus Notes-Datenbank Busytime.nsf verwaltet. Die Datenbank Busytime.nsf enthält die Frei-/Gebucht-Informationen für alle Benutzer auf dem Server und für Ressourcen wie Konferenzräume, die im öffentlichen Adressbuch des Servers enthalten sind.
Hinweis: Der Kalender-Connector kann nur eine Verbindung mit einer einzelnen Lotus Notes-Umgebung herstellen. Das Integrieren verschiedener Lotus Notes-Messagingsysteme in Exchange Server 2003 über den Kalender-Connector wird nicht unterstützt.
530
Frei-/Gebucht-Suchen aus Exchange 2003Der Kalender-Connector führt die folgenden Schritte durch, um aus Exchange Server 2003 Frei-/Gebucht-Informationen zu Lotus Notes-Benutzern zu suchen:
1. Mapical.dll fängt die Frei-/Gebucht-Anforderungen ab und überprüft die vorhandenen Frei-/Gebucht-Datensätze im Systemordner für Frei-/Gebucht-Informationen. Wenn der Datensatz innerhalb des Zeitraums aktualisiert wurde, der in der Konfiguration des Kalender-Connectors unter Höchstalter in Minuten für Frei-/Gebucht-Fremddaten in Exchange, die ohne weitere Abfrage des Fremdkalenders verwendet werden können angegeben wurde, gibt Mapical.dll diese Daten sofort zurück.
Hinweis: Dieses Verfahren funktioniert nur, wenn der Kalender-Connector auf dem Server mit dem Frei-/Gebucht-Ordner ausgeführt wird. Es ist z. B. möglich, den Frei-/Gebucht-Ordner auf andere Server in administrativen Remotegruppen zu replizieren. In diesem Fall erhalten Benutzer, die diese Öffentlichen Ordnerinstanzen abfragen, möglicherweise veraltete Informationen. Exchange Server 2003 gibt nur die zurzeit in den angeforderten Frei-/Gebucht-Nachrichten verfügbaren Informationen zurück. Um dieses Problem zu vermeiden, müssen Sie für jedes Replikat des Frei-/Gebucht-Ordners eine eigene Instanz des Kalender-Connectors installieren.
2. Wenn kein Frei-/Gebucht-Datensatz oder nur ein Datensatz außerhalb des maximalen Zeitraums vorhanden ist, übergibt Mapical.dll die Frei-/Gebucht-Abfrage an Notescal.dll, um den Frei-/Gebucht-Datensatz des Zielbenutzers im Exchange-Ordner für die Frei-/Gebucht-Informationen zu aktualisieren.
3. Notescal.dll empfängt die Frei-/Gebucht-Abfrage von Mapical.dll und leitet sie an den Lotus Notes-Task Schedule Manager weiter.
4. Der Task Schedule Manager ruft die Informationen für lokale Benutzer aus der Datenbank Busytime.nsf ab. Bei Benutzern auf Lotus Domino-Downstreamservern kommuniziert der Schedule Manager mit dem Lotus Notes-Task Kalender-Connector, der ebenfalls auf dem Lotus Domino-Server ausgeführt wird, um die Frei-/Gebucht-Informationen zu suchen.
5. Der Lotus Notes-Task Kalender-Connector bestimmt die Domäne des Zielbenutzers und liest das Feld Calendar Server Name aus dem Domänendokument. Der Kalender-Connector kommuniziert dann mit dem Remotekalenderserver, um die Frei-/Gebucht-Abfrage durchzuführen.
6. Der Lotus Notes-Task Kalender-Connector gibt die Informationen an den Task Schedule Manager zurück.
7. Der Task Schedule Manager gibt die Informationen an Notescal.dll zurück.
531
8. Notescal.dll leitet die Informationen an Mapical.dll weiter, das den Frei-/Gebucht-Datensatz des Lotus Notes-Benutzers im Systemordner aktualisiert.
9. Mapical.dll gibt die Informationen an den Outlook-Benutzer zurück.
Hinweis: Wenn das Nicht-Exchange-System innerhalb eines Zeitraums antwortet, der kleiner als der Wert Maximale Wartezeit auf Antworten von Fremdkalendern in Sekunden in der Konfiguration des Kalender-Connectors ist, werden die Daten in den Frei-/Gebucht-Datensatz des Zielbenutzers im Frei-/Gebucht-Ordner von Exchange geschrieben und an den Client zurückgegeben. Wenn das Nicht-Exchange-System nicht innerhalb des zulässigen Zeitrahmens antwortet (oder wenn der Kalender-Connector nicht ausgeführt wird), gibt Exchange Server 2003 die vorhandenen Daten aus dem Frei-/Gebucht-Datensatz an den Client zurück, ohne zuvor den Frei-/Gebucht-Datensatz des Zielbenutzers zu aktualisieren.
Frei-/Gebucht-Suchen aus Lotus NotesDer Kalender-Connector führt die folgenden Schritte durch, um Frei-/Gebucht-Informationen zu Exchange Server 2003-Benutzern für Lotus Notes zu suchen:
1. Der Lotus Notes-Client leitet die Frei-/Gebucht-Abfrage an den Task Schedule Manager weiter.
2. Der Task Schedule Manager erkennt, dass die Anforderung nicht für einen lokalen Benutzer ist, und leitet sie an den Task Kalender-Connector weiter.
3. Der Task Kalender-Connector liest das Personendokument für den Exchange-Benutzer und ermittelt, dass der Benutzer zu einer Fremddomäne gehört. Der Task Kalender-Connector überprüft das Feld Calendar System im Fremddomänendokument für die Exchange Server 2003-Organisation. Das Feld Calendar System gibt den Namen des Add-In-Programms an, das die Frei-/Gebucht-Suchen auf dem Lotus Domino-Server behandelt. Dies ist in diesem Fall das Exchange-Kalender-Connector-Add-In (ExCalCon.exe).
4. Der Task Kalender-Connector leitet die Frei-/Gebucht-Anforderung an ExCalCon.exe weiter.
5. ExCalCon.exe leitet die Anforderung an die Komponente Notescal.dll weiter, die sie verarbeitet und mit Mapical.dll kommuniziert, um die Frei-/Gebucht-Informationen für den Exchange-Benutzer vom Frei-/Gebucht-Systemordner abzurufen.
6. Notescal.dll leitet die Antwort zurück an ExCalCon.exe, das die Informationen an den Task Kalender-Connector weiterleitet.
7. Der Task Kalender-Connector leitet die Daten an den Schedule Manager weiter.
532
8. Schedule Manager überträgt dann die Frei-/Gebucht-Informationen an den Lotus Notes-Benutzer.
Hinweis: Da Lotus Notes alle Exchange-Benutzer als zu einer Lotus Notes-Fremddomäne zugehörig einstuft, werden alle Anforderungen für Frei-/Gebucht-Informationen aus Exchange von dem Lotus Notes-Task Kalender-Connector empfangen.
Frei-/Gebucht-Suchen mit Novell GroupWiseWie in der folgenden Abbildung gezeigt, kommuniziert Gwisecal.dll mit Novell GroupWise über den Connector für Novell GroupWise und den Novell GroupWise-API-Gateway. Frei-/Gebucht-Anforderungen werden in Novell GroupWise als Systemnachrichten übertragen. Die Architektur des Connectors für Novell GroupWise wurde bereits in diesem Kapitel beschrieben.
533
Synchronisieren von Frei-/Gebucht-Informationen mit Novell GroupWise
Der Kalender-Connector führt die folgenden Schritte durch, um Frei-/Gebucht-Informationen zu Novell GroupWise-Benutzern für Exchange Server 2003 zu suchen:
1. Mapical.dll fängt die Frei-/Gebucht-Anforderungen ab und überprüft die vorhandenen Frei-/Gebucht-Datensätze im Systemordner für Frei-/Gebucht-Informationen. Wenn der Datensatz innerhalb des Zeitraums aktualisiert wurde, der in der Konfiguration des Kalender-Connectors unter Höchstalter in Minuten für Frei-/Gebucht-Fremddaten in Exchange, die ohne weitere Abfrage des Fremdkalenders verwendet werden können angegeben wurde, gibt Mapical.dll diese Daten sofort zurück.
2. Wenn kein Frei-/Gebucht-Datensatz für den Novell GroupWise-Benutzer oder nur ein Datensatz außerhalb des maximalen Zeitraums vorhanden ist, übergibt Mapical.dll die Frei-/Gebucht-Abfrage an Gwisecal.dll, um den Frei-/Gebucht-Datensatz des Zielbenutzers im Exchange-Ordner für die Frei-/Gebucht-Informationen zu aktualisieren.
534
3. Gwisecal.dll übersetzt die Anforderung in eine schlüsselwortbasierte Textdatei vom Typ SEARCH und speichert diese im Verzeichnis \Programme\Exchsrvr\Conndata\GWRouter\Togwise. Der Verfasser der Nachricht vom Typ SEARCH ist die Systemaufsicht. Die Nachricht wird an den Novell GroupWise-Benutzer gesendet, für den der Kalender-Connector die Frei-/Gebucht-Informationen anfordert. Das folgende Beispiel zeigt eine Anforderung vom Typ SEARCH:
WPC-API= 1.2;
MSG-TYPE= Search;
Msg-ID= AAIMIDMI:2003.12.2.21.28:2004.1.31.21.28:2003.12.3.5.28.51;
From=
WPD= CONTOSO_DOM;
WPPO= Exchange Gateway;
WPU= Microsoft System Attendant;
CDBA= CONTOSO_DOM.Exchange Gateway.Microsoft System Attendant; ;
To=
WPD= CONTOSO_DOM;
WPPO= CONTOSO_PO;
WPU= FrankM;
CDBA= CONTOSO_DOM.CONTOSO_PO.FrankM; ;
Begin-Time= 2/12/2003 21:28;
End-Time= 31/1/2004 21:28;
-END-
4. Der Router für Novell GroupWise erhält die Nachricht aus dem Verzeichnis \Togwise und speichert sie im Verzeichnis API_IN des Novell GroupWise-API-Gateways.
5. Der API-Gateway verarbeitet die Nachricht entsprechend dem Schlüsselwort MSG-TYPE und speichert sie im Verzeichnis WPCSIN für den Novell GroupWise-MTA.
6. Der Novell GroupWise-MTA leitet die Nachricht an das Stammpostoffice des GroupWise-Benutzers weiter und übergibt sie an den entsprechenden Post Office Agent (POA) von Novell GroupWise.
7. Der Novell GroupWise-POA verarbeitet die Anforderung und gibt die resultierenden Frei-/Gebucht-Informationen in Form einer Nachricht vom Typ SEARCH an den GroupWise-MTA zurück.
535
8. Der GroupWise-MTA überträgt die Nachricht an das Verzeichnis WPCSOUT im API-Gateway-Verzeichnis, und der API-Gateway überträgt die Nachricht an das Verzeichnis API_OUT.
9. Der Router für Novell GroupWise erhält die Nachricht vom Typ SEARCH aus dem Verzeichnis API_OUT und speichert sie entsprechend dem Schlüsselwort MSG-TYPE im Verzeichnis \Programme\Exchsrvr\Conndata\GWRouter\freebusy. Das folgende Beispiel zeigt eine Antwort auf eine Frei-/Gebucht-Abfrage:
WPC-API= 1.2;
Header-Char= T50;
Msg-Type= SEARCH;
Orig-Msg-ID= AAIMIDMI:2003.12.2.21.28:2004.1.31.21.28:2003.12.3.5.28.51;
To=
CDBA= CONTOSO_DOM.Exchange Gateway.Microsoft System Attendant;
;
Busy-For=
CDBA= CONTOSO_DOM.CONTOSO_PO.FrankM;
Busy-Report=
Start-Time= 11/12/03 17:00;
End-Time= 12/12/03 8:00; ,
Start-Time= 12/12/03 17:00;
End-Time= 15/12/03 8:00; ,
Start-Time= 15/12/03 17:00;
End-Time= 16/12/03 8:00; ,
Start-Time= 16/12/03 17:00;
End-Time= 17/12/03 8:00; ,
Start-Time= 17/12/03 17:00;
End-Time= 18/12/03 8:00; ,
Start-Time= 18/12/03 17:00;
End-Time= 19/12/03 8:00; ,
;
Send-Options= None;
-END-
536
10. Gwisecal.dll ruft die Nachricht ab und übersetzt sie in das Exchange-Format. Anschließend leitet Gwisecal.dll diese Nachricht an Mapical.dll weiter.
11. Mapical.dll aktualisiert den Frei-/Gebucht-Datensatz für den Novell GroupWise-Benutzer im Frei-/Gebucht-Systemordner.
12. Exchange Server 2003 gibt die Frei-/Gebucht-Informationen an den Outlook-Benutzer zurück, der die Anfrage gestellt hatte.
Frei-/Gebucht-Suchen aus Novell GroupWiseDer Kalender-Connector führt die folgenden Schritte durch, um Frei-/Gebucht-Informationen zu Exchange Server 2003-Benutzern für Novell GroupWise zu suchen:
1. Ein Novell GroupWise-Benutzer führt eine Frei-/Gebucht-Suche für einen Exchange-Benutzer durch. Der Novell GroupWise-Client generiert eine Nachricht vom Typ SEARCH, die das Novell GroupWise-System an den API-Gateway überträgt.
2. Der API-Gateway überträgt die SEARCH-Nachricht aus dem Verzeichnis WPCSOUT in das Verzeichnis API_OUT, aus dem sie der Router für Novell GroupWise abruft und entsprechend dem Schlüsselwort MSG-TYPE im Verzeichnis \Programme\Exchsrvr\Conndata\GWRouter\FreeBusy speichert. Die Nachricht wird an den Exchange-Benutzer gesendet, für den der Novell GroupWise-Benutzer die Frei-/Gebucht-Informationen anfordert. Die Struktur der Nachricht entspricht der, die Gwisecal.dll für Abfragen von Exchange Server-Benutzern generiert.
3. Gwisecal.dll erhält die SEARCH-Nachricht aus dem Verzeichnis \FreeBusy, übersetzt sie in das Exchange Server-Format und leitet die Anforderung dann an Mapical.dll weiter.
4. Mapical.dll verarbeitet die Frei-/Gebucht-Abfrage und gibt die angeforderten Informationen an Gwisecal.dll zurück.
5. Gwisecal.dll übersetzt die Anforderung in eine Antwort vom Typ SEARCH und speichert diese im Verzeichnis \Programme\Exchsrvr\Conndata\GWRouter\Togwise. Die Struktur der Nachricht ähnelt der, die vom Novell GroupWise-System als Antwort auf Abfragen von Exchange-Benutzern generiert wird.
6. Der Router für Novell GroupWise erhält die Nachricht aus dem Verzeichnis \Togwise und speichert sie im Verzeichnis API_IN des API-Gateways.
7. Das Novell GroupWise-System leitet die Antwort an den Benutzer weiter, der die Frei-/Gebucht-Abfrage gestellt hatte.
Hinweis: GroupWise-Benutzer müssen die Sichtbarkeitseinstellung auf System oder höher festlegen, um Kalenderinformationen von Exchange empfangen zu können.
537
Prüfen des Vorhandenseins eines Replikats des Frei-/Gebucht-Systemordners für die administrative Gruppe auf einem Server mit Exchange ServerIn diesem Thema wird erklärt, wie ermittelt werden kann, ob ein Server mit Exchange Server über ein Replikat des Frei-/Gebucht-Systemordners für die administrative Gruppe verfügt. Dies ist für die Entscheidung erforderlich, wo ein Kalender-Connector installiert werden soll, weil er nur auf einem Server mit einem Replikat dieses Ordners installiert werden kann.
Bevor Sie beginnenVergewissern Sie sich, ob Sie über die korrekten Berechtigungen verfügen, bevor Sie das Verfahren in diesem Thema durchführen. Der Kalender-Connector benötigt Berechtigungen für das Lesen und Erstellen von Elementen im Frei-/Gebucht-Systemordner. Klicken Sie in den Eigenschaften des Frei-/Gebucht-Ordners für die lokale administrative Gruppe auf die Registerkarte Berechtigungen, und klicken Sie dann auf Clientberechtigungen. Überprüfen Sie im Dialogfeld Clientberechtigungen, ob dem Konto Standard die Rolle Herausgeber zugeordnet ist.
VerfahrenSo prüfen Sie, ob ein Server mit Exchange Server über ein Replikat des Frei-/Gebucht-
Systemordners für die administrative Gruppe verfügt.
1. Klicken Sie im Exchange-System-Manager auf den Container Ordner.
2. Klicken Sie mit der rechten Maustaste auf Öffentliche Ordner.
3. Wählen Sie Systemordner anzeigen aus. Frei-/Gebucht-Ordner werden entsprechend ihrer administrativen Gruppe benannt und befinden sich im Container SCHEDULE+ FREI-/GEBUCHT.
4. Zeigen Sie die Eigenschaften des Systemordners für die lokale administrative Gruppe an, und klicken Sie auf die Registerkarte Replikation. Stellen Sie sicher, dass der Informationsspeicher für Öffentliche Ordner auf dem Server mit Exchange Server, auf dem der Kalender-Connector ausgeführt wird, in der Liste der Informationsspeicher für Öffentliche Ordner enthalten ist.
538
Virtuelle Protokollserver in Exchange Server 2003Microsoft Exchange Server 2003 enthält virtuelle Protokollserver, von denen viele den Clientzugriff ermöglichen. Virtuelle Protokollserver sind bei ihren Operationen und Diensten von IIS (Internet Information Services) und dem Active Directory-Verzeichnisdienst abhängig. In der Standardeinstellung installiert Exchange Server 2003-Setup die folgenden virtuellen Protokollserver:
Virtueller Exchange-Server Dieser standardmäßig aktivierte virtuelle Protokollserver enthält verschiedene virtuelle Verzeichnisse: Exadmin, Exchange, Microsoft-Server-ActiveSync, Microsoft Office Outlook Mobile Access und Öffentlich. Er bietet WebDAV-Zugriff auf das Exchange-Postfach und Daten in Öffentlichen Ordnern in Outlook Web Access und Microsoft Outlook Mobile Access sowie von Exchange ActiveSync-Benutzern.
Virtueller IMAP4-Server Dieser standardmäßig deaktivierte virtuelle Server bietet IMAP4-Clientzugriff auf das Exchange-Postfach und Daten in Öffentlichen Ordnern.
Virtueller NNTP-Server Dieser standardmäßig deaktivierte virtuelle Server bietet NNTP-Clientzugriff auf Daten in Öffentlichen Ordnern von Exchange.
Virtueller POP3-Server Dieser standardmäßig deaktivierte virtuelle Server bietet POP3-Clientzugriff auf Daten im Exchange-Postfach.
Virtueller SMTP-Server Dieser standardmäßig aktivierte virtuelle Server bietet SMTP-Messaging-Dienste.
Exchange Server 2003 installiert und verwaltet die Protokolle POP3 und IMAP4 (Internet Message Access Protocol, Version 4 rev1) für den Clientzugriff, verwendet aber die durch IIS bereitgestellten SMTP- und NNTP-Protokollstapel. SMTP wird ausführlich in SMTP-Transportarchitektur behandelt. Der Schwerpunkt dieses Abschnitts liegt auf den anderen Clientzugriffsprotokollen für das Internet: HTTP, IMAP4, POP3 und NNTP.
Folgende Themen werden in diesem Abschnitt behandelt:
Integration von Exchange 2003 in IIS IIS und Exchange 2003 sind durch Protokollstubs und eine gemeinsam verwendete Speicherwarteschlange eng miteinander verbunden. Die Auswirkungen dieser Integration, sofern sie in Zusammenhang mit der Bereitstellung, Verwaltung und Fehlerbehebung von Messaging-Diensten stehen, werden in diesem Abschnitt beschrieben.
Standardprotokolle für den Internet-Clientzugriff einschließlich HTTP, NNTP, IMAP4 und POP3 Sie benötigen ein Verständnis für die Verwendung von Internetprotokollen durch die virtuellen Protokollserver von Exchange Server 2003 für den Clientzugriff auf Exchange-Daten und -Dienste.
539
Die Architektur von RPC über HTTP Remoteprozeduraufrufe (Remote Procedure Call, RPC) über HTTP ermöglichen Microsoft Office Outlook 2003-Clients das sichere Verbinden mit einem Exchange-Server über das Internet unter Verwendung von Microsoft Exchange-MAPI-Transportdiensten. In diesem Abschnitt werden die Funktionsweise von RPC über HTTP und die Implementierung in einer Organisation beschrieben.
Exchange-Mobilitätsfunktionen Exchange 2003 enthält neue Mobilitätsfunktionen wie Outlook Mobile Access und Exchange Server ActiveSync, die beide als virtuelle Protokollserver implementiert sind. In diesem Abschnitt werden diese Funktionen und die Implementierung in einer Organisation beschrieben.
IIS-IntegrationIn Exchange Server 2003 werden alle Protokolle für den Internetclientzugriff als Teil von IIS ausgeführt. Wenn Sie Exchange Server 2003 installieren, werden die SMTP- und NNTP-Protokollstapel in IIS nicht ersetzt, sondern mit zusätzlichen Befehlsverben und umfangreicheren Routingkomponenten erweitert. Exchange Server 2003 beinhaltet die folgenden Internetprotokollstapel:
POP3 POP3 ist das grundlegendste Protokoll für den Nachrichtenabruf. POP3 kann nur auf den Ordner Posteingang des Benutzers zugreifen. Exchange 2003 unterstützt POP3 für den Zugriff durch POP3-Clients.
IMAP4 IMAP4 wird für den Zugriff auf Postfachinformationen verwendet. IMAP4 ist umfangreicher als POP3, da es grundlegende Onlinefunktionen und Zugriff auf andere Ordner als den Posteingang bietet. Neben dem begrenzten Zugriff auf Benutzerpostfächer bietet die Exchange 2003-Implementierung von IMAP4 folgende Funktionen:
Zugriff auf Öffentliche Ordner
Delegieren des Zugriffs auf das Postfach eines anderen Benutzers
Anonymer Zugriff auf bestimmte IMAP-Kontonamen
SMTP SMTP ist das primäre Messaging-Protokoll für Exchange Server 2003. SMTP wird für das Verschieben von Nachrichten zwischen Servern in derselben Routinggruppe verwendet und ist das bevorzugte Protokoll für das Verschieben von Nachrichten zwischen Routinggruppen. In Exchange Server 2003 sind u. a. folgende Verbesserungen am IIS-SMTP-Stapel vorhanden:
Befehle mit Unterstützung für ein fehlertolerantes Routing
Ein verbessertes Warteschlangenmodul
Ein erweiterter Agent für die Nachrichtenkategorisierung
540
NNTP Die Exchange Server 2003-Implementierung von NNTP bietet die folgenden zusätzlichen Funktionen:
Die Inhaltsindizierung bietet Suchfunktionen für Öffentliche Ordner
Vollständige Newsfeed-Genehmigung, unabhängig von der Speicherauswahl (Dateisystem oder Öffentliche Ordner) auf dem Back-End-Server
MAPI- und NNTP-Clients können Newsgroups lesen und veröffentlichen, die vom Microsoft Exchange-Informationsspeicherdienst unterstützt werden.
WebDAV WebDAV ist eine Erweiterung von HTTP, die eine Weboberfläche für den Microsoft Exchange-Informationsspeicherdienst bietet.
Untersuchen der prozessübergreifenden Kommunikation zwischen IIS und dem Microsoft Exchange-InformationsspeicherdienstBis auf MAPI gehören die Exchange Server 2003-Protokolle für den Clientzugriff nicht zum Microsoft Exchange-Informationsspeicherdienst. Sie werden stattdessen von IIS gehostet.
Das Trennen dieser Protokolle vom Microsoft Exchange-Informationsspeicherdienst erhöht die Zuverlässigkeit, Flexibilität und Skalierbarkeit von Exchange Server 2003. Um dies zu erleichtern, beinhaltet Exchange Server 2003 eine Warteschlangenebene namens Exchange Interprocess Communication (ExIPC), die auch als EPOXY bezeichnet wird, da sie in Epoxy.dll implementiert ist.
Wie in der folgenden Abbildung dargestellt, arbeitet ExIPC mit dem installierbaren Dateisystem von Exchange (Installable File System, ExIFS) zusammen, um Nachrichten zwischen IIS und Exchange Server 2003 zu verschieben.
ExIPC bietet leistungsstarke Funktionen für die prozessübergreifende Kommunikation. Wie LRPCs (Lightweight Remote Procedure Call) verwendet ExIPC freigegebenen Speicher (32 KB zugeordnete Speicherbereiche) auf Grundlage von Umlaufwarteschlangen für freigegebenen Speicher (Shared Memory Circular Queue Model, SMQ) für die Kommunikation zwischen den INETINFO- und STORE-Prozessen und dem DSAccess-Cache. Damit wird sichergestellt, dass der Cache für alle Prozesse verfügbar ist, die DSAccess ausführen. ExIPC enthält den Microsoft Exchange-Informationsspeicherdienst und eine Protokoll-DLL, die eine Bindungsfunktion bietet (schnelle, zuverlässige Kommunikation zwischen IIS und dem Microsoft Exchange-Informationsspeicherdienst), einen gemeinsam genutzten Speicherheap und zwei Warteschlangen basierend auf freigegebenem Speicher.
541
Speicher- und Protokollarchitektur von Exchange Server 2003
Installierbares Dateisystem von ExchangeExIPC arbeitet mit dem installierbaren Dateisystem von Exchange (Exchange Installable File System, ExIFS) zusammen, um Nachrichten zwischen IIS und Exchange zu verschieben. ExIFS bietet über Microsoft Win32-Dateisystem-APIs Zugriff auf den Microsoft Exchange-Informationsspeicherdienst. ExIFS lässt die Streamingdatei für IIS als viele kleine Dateien erscheinen, die als virtuelle Dateien bezeichnet werden. IIS ruft eine Zugriffsnummer für eine virtuelle Datei ab und schreibt eingehende Daten über ExIFS direkt in die Streamingdatei. Entsprechend werden ausgehende Nachrichten direkt über ExIFS aus der Streamingdatei gelesen. Eine Nachricht wird in der Streamingdatei zu einer Liste von Seiten (die Seitenzahlen werden in der EDB-Datei gespeichert), und alle erforderlichen Eigenschaften werden von der STM-Datei in die EDB-Datei übertragen.
542
ExIFS-Architektur
Eine Nachricht wird in der Streamingdatei zu einer Liste von Seiten (die Seitenzahlen werden in der EDB-Datei gespeichert). Alle erforderlichen Eigenschaften werden aus der STM-Datei in die EDB-Datei übertragen.
Diese Abbildung veranschaulicht das Dateistreaming zwischen IIS und ExIFS. ExIFS stellt die Streamingdateien für IIS als kleinere virtuelle Dateien dar. Daten wie Prüfsummen und die Übertragung von Eigenschaftendaten werden zunächst von ExIFS in die Extensible Storage Engine verschoben und dann in den Exchange-Informationsspeicher. IIS und der Exchange-Informationsspeicher speichern außerdem Austauschinformationen wie die Seitenzahlen, auf denen ExIFS eine Nachricht platziert hat, damit die Seitenzahlen in dem Datensatz aufgezeichnet und gespeichert werden, der die Nachricht im Exchange-Informationsspeicher darstellt.
Eingehende NachrichtenWenn eine Nachricht das System erreicht, erstellt IIS eine neue Datei in ExIFS. Die Daten werden auf hierfür reservierten Seiten in die neue Datei geschrieben. ExIFS gibt anschließend die Liste der Seiten an den Exchange-Informationsspeicher zurück. Der Exchange-Informationsspeicher verarbeitet die Seiten und speichert sie in einem Datensatz, der die Nachricht darstellt. Die Extensible Storage Engine übergibt die Daten dann an die reservierten Seiten, indem sie die Informationen in den Transaktionsprotokolldateien der Speichergruppe aufzeichnet. Dabei ändert sich der Status der Seiten von reserviert in übergeben.
Hinweis: Wenn für die Speichergruppe die Umlaufprotokollierung aktiviert ist, schreibt die Extensible Storage Engine keine Daten in die Transaktionsprotokolldateien, die über die Streamingdatei eingehen. In diesem Fall werden die Daten aus der Streamingdatei zuerst in der Streamingdatei gespeichert. Die Daten sind in den Transaktionsprotokollen nur für die Wiederherstellung und die Wiedergabe nach der
543
Wiederherstellung erforderlich. Da die Wiedergabe der Protokolle nur bei aktivierter Umlaufprotokollierung auftritt, sind die Daten aus der Streamingdatei nur dann in den Transaktionsprotokollen hilfreich, wenn die Umlaufprotokollierung deaktiviert ist.
Ausgehende NachrichtenWenn eine Nachricht vom System abgerufen wird, empfängt der Exchange-Informationsspeicherprozess die Liste der Seiten, auf die durch die Nachricht verwiesen wird. Diese Seitenliste wird an IIS weitergeleitet. IIS öffnet anschließend mithilfe der Liste der Seiten eine Datei in ExIFS. Die Nachricht wird schnell und ohne Konvertierung aus dem Exchange-Informationsspeicher in einem Dateistream übertragen.
DateisystemsemantikExIFS leitet Win32-Dateiaufrufe an den Exchange-Informationsspeicher um. Daher können Sie mit der Win32-Dateisystem-API auf Daten in Exchange Server zugreifen. Mit Aufrufen wie FindFileFirst können Sie z. B. auf einen Öffentlichen Ordner zugreifen, um eine Liste von Nachrichten abzurufen. Außerdem können Sie Ihrem Postfach ein Laufwerk zuordnen und normale Befehlszeilenfunktionen für den Zugriff auf Ihren Posteingang verwenden. ExIFS zeigt den Inhalt von Exchange-Datenbanken als einfache Dateien an.
Interaktion von ExIFS mit Microsoft Windows Explorer und dem Exchange-Informationsspeicher
Diese Abbildung zeigt, dass die Interaktion mit dem Speicher über ExWin32.dll erfolgt. ExIFS.sys unterstützt neben der Interaktion mit dem Exchange-Informationsspeicher über ExWin32.dll auch alle Funktionen, die in Zusammenhang mit dem Dateisystem stehen und von kernel32.dll exportiert werden.
ExIPC-BindungsfunktionDie ExIPC-Bindungsfunktion ermöglicht das Erstellen einer beliebigen Anzahl von Warteschlangen zwischen Prozessen wie INETINFO und STORE und das Herstellen von Verbindungen mit diesen. Die Bindungsfunktion umfasst einen zentralen Warteschlangen-
544
Manager, um Warteschlangen und Prozesse zu verfolgen, mit denen ein bestimmter Prozess kommuniziert. Die Funktion wird für das Aufheben von Bindungen und das Bereinigen von Warteschlangen verwendet, wenn in dem anderen Prozess ein Fehler auftritt.
Alle Protokollwarteschlangen sind Umlaufwarteschlangen und haben eine feste Größe. Während der Kommunikation zwischen den Prozessen werden die Daten im gemeinsam genutzten Speicherheap gespeichert, wobei Verweise über eine Datenzugriffsnummer erfolgen. Die Datenzugriffsnummer wird in die Warteschlange eingefügt und aus dieser entfernt. IIS oder der Exchange-Informationsspeicher verweisen dann über die Zugriffsnummer auf einen Teil des gemeinsam genutzten Speichers.
ExIPC-ProtokollstubsJedes Protokoll verfügt in STORE.exe über eine ExIPC-Schnittstelle. Der ExIPC-Protokollstub für POP3 ist z. B. expop.dll. Diese Komponente übergibt Parameter (z. B. einen Zeiger auf eine Nachricht oder Aktion) von STORE.exe an die ExIPC-Schnittstelle (drviis.dll) in INETINFO.exe.
MAPI und RPC über HTTPWenn der Exchange Server-Transportdienst in Microsoft Outlook konfiguriert ist, verwendet Outlook MAPI für die Kommunikation mit dem Exchange-Informationsspeicherdienst. MAPI-Aufrufe basieren immer auf Remoteprozeduraufrufen. Obwohl Remoteprozeduraufrufe in LAN- und WAN-Umgebungen problemlos funktionieren, werden sie i. d. R. aufgrund von Problemen mit der Firewall und anderen Bedenken nicht für die Verwendung über das Internet empfohlen. Bei früheren Versionen von Exchange mussten Outlook-Benutzer, die mit MAPI auf Exchange zugreifen wollten, zuerst VPN-Verbindungen mit dem privaten Netzwerk ihrer Organisation herstellen.
Der RPC-Proxy wird auf einem IIS-Computer ausgeführt. Er akzeptiert RPC-Anforderungen aus dem Internet, stellt effizient Verbindungen über das Internet mit RPC-Serverprogrammen her und führt Remoteprozeduraufrufe durch, ohne dass zuvor eine VPN-Verbindung hergestellt werden muss. Außerdem führt er die Authentifizierungen, Auswertungen und Zugriffsprüfungen für diese Anforderungen aus, ohne an der Firewall mehrere Ports zu öffnen. Dies alles erfolgt über einen zwischengeschalteten Proxy, der als RPC-über-HTTP-Proxy oder als RPC-Proxy bezeichnet wird.
Wenn die Anforderung alle Tests passiert hat, leitet der RPC-Proxy die Anforderung an den RPC-Server weiter, der die eigentliche Verarbeitung vornimmt. Mit RPC über HTTP kommunizieren RPC-Client und -Server nicht direkt miteinander. Stattdessen verwenden sie den RPC-Proxy.
545
RPC über HTTPRPC über HTTP ermöglicht Clientprogrammen das Ausführen von Prozeduren im Internet, die von Serverprogrammen in entfernten Netzwerken bereitgestellt werden. RPC über HTTP leitet seine Aufrufe über einen eingerichteten HTTP-Port weiter. Daher können alle Aufrufe über Netzwerkfirewalls in Client- und Servernetzwerken übermittelt werden. Der RPC-Proxy befindet sich im Netzwerk des RPC-Servers. Er stellt eine Verbindung mit dem RPC-Server her und verwaltet diese. Dabei dient er als Proxy, verteilt Remoteprozeduraufrufe an den RPC-Server und sendet die Serverantworten über das Internet zurück an das Clientprogramm.
RPC über HTTP stellt Anforderungen auf Server- und Clientseite, die in der folgenden Tabelle beschrieben werden:
Anforderungen an die Implementierung von RPC über HTTP
Clientseitige Anforderungen Microsoft Windows XP Professional mit Service Pack 1 oder höher
Hotfix vom Microsoft Knowledge Base-Artikel 331320
Microsoft Office Outlook 2003
Serverseitige Anforderungen Microsoft Windows Server 2003 auf dem Exchange-Server
Exchange Server 2003 auf allen Front-End- und Back-End-Servern
Windows Server 2003 auf globalen Katalogservern
Windows Server 2003 auf RPC-Proxyservern
Wenn das Clientprogramm einen Remoteprozeduraufruf über HTTP sendet, kommuniziert die RPC-Laufzeitbibliothek auf dem Client mit dem RPC-Proxy. In Abhängigkeit davon, ob der RPC-Client HTTP oder HTTPS verwenden soll, wird TCP-Port 80 oder TCP-Port 443 verwendet. Der RPC-Proxy kommuniziert mit dem RPC-Serverprogramm und stellt eine TCP/IP-Verbindung her. Der Client und der RPC-Proxy halten ihre HTTP- oder HTTPS-Verbindung über das Internet aufrecht.
Die Clientverbindung über HTTP oder HTTPS mit dem RPC-Proxy kann die Firewall passieren (entsprechend den Zugriffsberechtigungen), sofern eine Firewall eingerichtet ist. Der Server kann dann den Remoteprozeduraufruf durchführen und für die Antwort an den Client die Verbindung über den RPC-Proxy verwenden.
546
Wenn der Client oder der Server die Verbindung trennt, erkennt der RPC-Proxy dies und beendet die RPC-Sitzung. Solange die Sitzung andauert, hält der RPC-Proxy seine Verbindungen mit Client und Server aufrecht. Er leitet die Remoteprozeduraufrufe vom Client an den Server weiter und sendet die Antworten vom Server an den Client.
Das RPC-Clientprogramm kann seine Remoteprozeduraufrufe über das Internet weiterleiten, indem es eine Bindungszeichenfolge in der folgenden Form erstellt:
[object_uuid@]ncacn_http:rpc_server[endpoint,HttpProxy=proxy_server:http_port,'rpcprox
y'=rpc_proxy:rpc_port]
Dabei gilt Folgendes:
object_uuid gibt einen eindeutigen Bezeichner (Universal Unique Identifier, UUID) für das RPC-Objekt an.
ncacn_http wählt die Protokollfolge für RPC über HTTP aus.
rpc_server ist die Netzwerkadresse des Computers, auf dem der RPC-Serverprozess ausgeführt wird. Die Serveradresse muss in einer Form angegeben werden, die nicht vom Client, sondern vom RPC-Proxycomputer angezeigt und verstanden werden kann. Da der Client keine direkte Verbindung mit dem Server herstellt, löst er nicht den Namen des Servers auf und stellt keine Verbindung mit diesem her. Der RPC-Proxy stellt die Verbindung für den Client her. Daher muss rpc_server ein vom RPC-Proxy erkennbarer Name sein.
endpoint gibt den TCP/IP-Port an, an dem der RPC-Serverprozess auf Remoteprozeduraufrufe wartet.
HttpProxy ist optional und gibt einen HTTP-Proxyserver im Netzwerk des RPC-Clients an, z. B. Microsoft Proxy Server. Wenn ein Proxyserver ausgewählt wurde, wird keine Portnummer angegeben. Der RPC-Stub verwendet standardmäßig Port 80, wenn kein SSL gefordert ist, und Port 443, wenn SSL angegeben wurde.
RPCProxy gibt die Adresse und Portnummer des IIS-Computers an, der als Proxy für den RPC-Server fungiert. Sie müssen diesen nur angeben, wenn der RPC-Serverprozess auf einem anderen Computer als der RPC-Proxy ausgeführt wird. Wenn Sie keine Portnummer angegeben, verwendet der RPC-Clientstub standardmäßig Port 80, wenn nicht SSL angegeben wurde, und Port 443, wenn SSL (HTTPS) angegeben wurde.
Virtuelles RPC-VerzeichnisObwohl RPC über HTTP ein Windows Server 2003-Feature und kein IIS-Feature ist, wird es als ISAPI-Erweiterung (Internet Server Application Programming Interface) implementiert, die auf einem virtuellen Protokollserver ausgeführt wird. Das virtuelle RPC-Verzeichnis wird auf der Standardwebsite erstellt, wenn der RPC-Proxydienst installiert wird. Sie sollten SSL zusammen mit der Standardauthentifizierung verwenden.
547
RPC über HTTP und der Microsoft Exchange-InformationsspeicherdienstObwohl RPC über HTTP als ein virtueller Protokollserver implementiert wird, ist ExIPC nicht an der Kommunikation beteiligt. Outlook-Clients, die RPC über HTTP verwenden, werden als normale MAPI-Clients behandelt und kommunizieren mit dem Microsoft Exchange-Informationsspeicherdienst mithilfe der MAPI-Schnittstelle zum Exchange-Informationsspeicher.
Einzelheiten zu den InternetprotokollenWie bereits beschrieben, unterstützt Exchange 2003 verschiedene standardisierte Internetclientprotokolle wie HTTP, POP3, IMAP4 und NNTP. Diese Protokolle werden in den folgenden Unterabschnitten genauer beschrieben.
HTTPDer Microsoft Exchange-Informationsspeicherdienst umfasst systemeigenen HTTP-Zugriff auf Daten. Auf jedes Objekt im Microsoft Exchange-Informationsspeicherdienst kann über eine URL mit kurzen und leicht verständlichen Namen zugegriffen werden. Da auf jedes Objekt im Microsoft Exchange-Informationsspeicher über eine URL zugegriffen werden kann, können Benutzer auf verschiedene Weise auf Objekte in Postfächern oder Hierarchien Öffentlicher Ordner zugreifen. Die URL für ein Objekt basiert auf seinem Speicherort in der Hierarchie und enthält i. d. R. den Betreff des Elements.
Wenn ein Benutzer eine Nachricht über Microsoft Outlook Web Access öffnet, ruft der IIS-Anforderungsprozessor die Exchange-HTTP-ISAPI-Anwendung auf, die die Informationen in der Anforderung analysiert und Folgendes ermittelt:
Die auszuführende Aktion Exchange-HTTP-ISAPI ermittelt, ob der Benutzer ein Postfach oder einen Ordner öffnet, ob er eine E-Mail-Nachricht liest oder erstellt usw.
Browserinformationen Exchange-HTTP-ISAPI ermittelt den Browsertyp, die Version und Darstellungsinformationen.
Anschließend ermittelt der Server, ob der Benutzer über die Berechtigung für den Zugriff auf das Element verfügt. Wenn der Benutzer über Zugriffsrechte verfügt, werden der Objektstatus (Gelesen, Ungelesen), der Objekttyp (Ordner, Nachricht u. a.) und der Elementtyp (Nachricht, Termin, Kontakt) bestimmt.
Die Exchange-HTTP-ISAPI-Erweiterung ordnet dann das Objektattribut seiner entsprechenden Formulardefinition zu. Wenn für ein bestimmtes Objektattribut keine Formulardefinition vorhanden ist, wird das Standardformular verwendet (das für das Lesen eines E-Mail-Elements). Die Exchange-HTTP-ISAPI-Erweiterung analysiert anschließend das
548
Formular und fragt die Bindung der Daten vom Informationsspeicher ab. Nach dem Erhalt der Daten vom Microsoft Exchange-Informationsspeicherdienst stellt die Exchange-HTTP-ISAPI-Erweiterung die Daten entsprechend dem Browsertyp und der Version in HTML oder XML dar, und der Client zeigt die Nachricht an.
Die folgenden Schritte zeigen diesen Vorgang im Einzelnen:
1. Der Browser sendet eine Anforderung für eine E-Mail-Nachricht.
2. Der Browser sendet eine GET-Anforderung für eine URL, z. B. http://Server/vroot/Benutzer/Ordner/Nachricht.eml. Dieser URL sind keine Abfragezeichenfolgen angefügt, die zuerst verarbeitet werden würden. Deshalb gibt der Server eine Darstellung dieser Ressource basierend auf seiner Nachrichtenklasse und der für diese Nachrichtenklasse konfigurierten Standardaktion zurück.
3. Exchange-ISAPI verarbeitet die Anforderung.
4. Wenn IIS die Anforderung empfängt, leitet es diese an die Exchange-ISAPI-Komponente Davex.dll weiter. Diese Komponente analysiert die Anforderung auf die folgenden Informationen und sendet die Anforderung an den Exchange-Informationsspeicher. Die folgende Tabelle stellt das übergebene Element und seinen Zweck dar.
5. Anschließend bestimmt der Microsoft Exchange-Informationsspeicherdienst den Elementtyp.
6. Der Server überprüft, ob der Benutzer Zugriff auf das Element hat, sowie den Typ des Objekts (Ordner, Nachricht, Aufgabe u. a.), und gibt den Elementtyp und seinen Status (Gelesen, Ungelesen u. a.) an die ISAPI-Anwendung zurück.
7. Exchange-ISAPI wählt das Formular aus.
8. Das ISAPI-Programm übernimmt die Objektattribute und sucht nach einer Formulardefinition in der Formularregistrierung, die mit dem Objekttyp übereinstimmt. Wenn keine übereinstimmende Formulardefinition gefunden wurde, wird ein in Wmtemplates.dll gespeichertes Standardformular verwendet. Wenn die Browsersprache nicht Englisch ist, werden sprachspezifische Zeichenfolgen in anderen Vorlagenbibliotheken im Verzeichnis \Exchsrvr\Res\ gesucht.
9. Der Microsoft Exchange-Informationsspeicherdienst ruft die Daten für das Formular ab.
10. Nachdem eine Formulardefinition gefunden wurde, analysiert das ISAPI-Programm das Formular und ruft den Microsoft Exchange-Informationsspeicherdienst auf, um die Daten abzurufen, auf die das Formular verweist.
11. Exchange-ISAPI stellt das Formular dar.
12. Wenn die Daten vom Microsoft Exchange-Informationsspeicherdienst zurückgegeben werden, wird das Formular im entsprechenden HTML- oder XML-Format dargestellt und an den Client gesendet.
549
Von „Davex.dll“ übergebene Elemente und deren Verwendung
Übergebenes Element Verwendung
HTTP-Header des Felds User-Agent Bestimmen des Browsertyps, der Version, des Betriebssystems und der Darstellung des Inhalts
HTTP-Header Accept-Language Bestimmen der Sprache für die Darstellung des Inhalts
HTTP-Header Translate Bestimmen, ob der Inhalt in einem Browser abgezeigt oder ohne Darstellung an eine WebDAV-Anwendung zurückgegeben werden soll
Abfragezeichenfolge Bestimmen einer ausführenden Aktion
WebDAV und XMLWebDAV (Web Distributed Authoring and Versioning) ist eine Erweiterung des HTTP 1.1-Protokolls (RFC 2518). HTTP und WebDAV ermöglichen eine umfangreiche Zusammenarbeit mit dem Informationsspeicher in Exchange 2003. Die HTTP-Unterstützung von Exchange 2003 ermöglicht das Hinzufügen, Ändern, Kopieren, Verschieben und Suchen von Ordnern und Elementen sowie das Bearbeiten von Attributen eines beliebigen Objekts im Informationsspeicher.
WebDAV verbessert die Leistung und die Anwenderfreundlichkeit gegenüber dem grundlegenden Microsoft Outlook Web Access-Client, indem es die Datenbindung und Darstellung auf Clientseite ausnutzt. Wenn Sie z. B. auf den Spaltenkopf klicken, können Sie den Posteingang auf verschiedene Arten sortieren: nach dem Namen des Absenders, der Betreffzeile oder dem Empfangsdatum. Der Browser speichert die Elemente der Benutzeroberfläche im Cache, so z. B. die Internet Explorer-HTML-Komponenten, die Microsoft JScript-Bibliotheken oder XSL und GIF-Dateien (Graphics Interchange Format). Wenn der Benutzer die Sortierkriterien ändert, kann der Browser die Elemente der Benutzeroberfläche lokal neu formatieren und die Anzeigedaten vom Server abfragen.
Der folgende Vorgang veranschaulicht, wie Clients mithilfe von WebDAV auf Elemente in ihrem Posteingang zugreifen:
Der Client sendet eine GET-HTTP-Anforderung für seinen Posteingang.
IIS empfängt die Anforderung an Port 80 (sofern Sie dies nicht in der Konfiguration ändern) und sendet die Anforderung mit ExIPC für die Verarbeitung an Davex.dll.
Die Anforderung wird mit ExIPC an den OLE DB-Treiber des Exchange-Informationsspeichers Exoledb.dll weitergeleitet.
550
Exoledb.dll stellt die Anforderung in einem Format dar, das der Exchange-Informationsspeicher verarbeiten kann, sendet die Anforderung an den Exchange-Informationsspeicher und ruft dann die Eigenschaften des Posteingangs des Clients vom Exchange-Informationsspeicher ab.
Nach Abruf der Eigenschaften des Posteingangs des Clients leitet Exchange 2003 die Informationen an den Client zurück. Dabei werden dieselben Komponenten verwendet wie für die Verarbeitung der Clientanforderung.
POP3Exchange Server 2003 implementiert einen POP3-Protokollstapel nach RFC 1725,
RFC 1734 und RFC 1939. Exchange 2003 unterstützt die zehn in der folgenden Tabelle aufgeführten POP3-Befehle.
Befehlsverben des POP3-Protokolls
Befehl Beschreibung
List Wird zum Anzeigen der ID und Größe (in Byte) von Nachrichten im Postfach bzw. zum Anzeigen der Nummer und Größe einer bestimmten Nachricht verwendet. Der list-Befehl wird mit der folgenden Syntax verwendet, wobei n die vom list-Befehl zurückgegebene Nachrichtennummer ist: list oder list n.
Uidl Wird zum Zurückgeben einer numerischen Liste aller Nachrichten im Postfach und ihrer zugeordneten eindeutigen IDs bzw. der eindeutigen ID einer bestimmten Nachricht verwendet. Der uidl-Befehl wird mit der folgenden Syntax verwendet, wobei n die vom list-Befehl zurückgegebene Nummer der Nachricht ist, die Sie mit uidl anzeigen möchten: uidl oder uidl n.
551
Befehl Beschreibung
Retr Wird zum Abrufen einer Nachricht vom Server verwendet. Sie können diesen Befehl nicht zum Abrufen einer Nachricht verwenden, die als gelöscht markiert ist. Der retr-Befehl wird mit der folgenden Syntax verwendet, wobei n die vom list-Befehl zurückgegebene Nachrichtennummer ist: retr n.
Stat Gibt die Gesamtzahl der Nachrichten im Postfach und die Gesamtgröße der Nachrichten (in Byte) zurück. Sie können diesen Befehl nicht für das Anzeigen weiterer Informationen über einzelne Nachrichten verwenden. Verwenden Sie zu diesem Zweck den list-Befehl oder den retr-Befehl.
Dele Auswählen einer Nachricht für das Löschen. Wenn Sie eine Nachricht für das Löschen auswählen, wird diese gelöscht, nachdem Sie den quit-Befehl verwendet haben, um den Client vom Server zu trennen. Wenn die Verbindung unerwartet unterbrochen wird, werden die Nachrichten nicht gelöscht. Der delete-Befehl wird mit der folgenden Syntax verwendet, wobei n die vom list-Befehl zurückgegebene Nachrichtennummer ist: dele n.
Rset Wird zum Aufheben der Auswahl aller Nachrichten verwendet, die für das Löschen ausgewählt wurden.
Noop Dieser Befehl wird als „keine Operation“ interpretiert. Obwohl dieser Befehl keine Aktion ausführt, antwortet der Server bei erfolgreichem Ausführen des Befehls mit einer positiven Antwort (OK+). Sie können mit diesem Befehl testen, ob der Server in Betrieb ist und Clientanforderungen empfängt.
552
Befehl Beschreibung
Top Wird zum Anzeigen der Nachrichtenkopfzeile und einer bestimmten Anzahl von Zeilen der Nachricht verwendet. Der Befehl wird mit der folgenden Syntax verwendet, wobei x die Nummer der anzuzeigenden Nachricht und y die Zahl der anzuzeigenden Zeilen aus der Nachricht ist: top xy.
Auth Dieser IMAP-Befehl ist Teil der POP3-Spezifikation und wird in RFC 1734 (Request for Comments) der IETF (Internet Engineering Task Force) beschrieben. Er ermöglicht das Verwenden anderer IMAP4-Autorisierungsverfahren.
Quit Wird zum Beenden der aktuellen POP3-Sitzung und zum Löschen aller Nachrichten verwendet, die für das Löschen ausgewählt wurden.
POP3 ist ein Protokoll für den Lesezugriff. Es enthält nur Nachrichten für das Anfordern, Lesen und Löschen von Nachrichten. Zum Senden von Nachrichten verwenden POP3-Clients das SMTP-Protokoll.
Die folgenden Schritte veranschaulichen die prozessübergreifende Kommunikation von ExIPC beim Zugriff eines Clients wie Microsoft Outlook auf ein Postfach auf dem Exchange-Server mit dem POP3-Protokoll.
Architektur der freigegebenen Speicher von IIS und Exchange Server
553
1. Der Client meldet sich am Server an und übergibt den Befehl für das Überprüfen auf E-Mail-Nachrichten.
2. Auf IIS-Seite wird ein Befehl für das Anfordern von E-Mail-Nachricht 1 erstellt.
3. IIS weist der Anforderung einen Speicher aus dem gemeinsam genutzten Speicherheap zu. Dem Speicherbereich wird eine entsprechende Zugriffsnummer zugewiesen. Anschließend wird die Zugriffsnummer, die als Platzhalter oder Zeiger auf den verwiesenen Teil des Speichers dient, in Richtung des Exchange-Informationsspeichers in die Umlaufwarteschlange des Speichers eingefügt.
4. Auf Seiten des Exchange-Informationsspeichers wartet ExIPC.DLL auf eingehende POP3-Anforderungen. Die DLL-Datei empfängt die Anforderung für die E-Mail-Nachricht und entfernt die Zugriffsnummer aus der Umlaufwarteschlange für den Speicher. Der POP3-Stub des Exchange-Informationsspeichers ändert den Verweis der Zugriffsnummer auf die Daten im gemeinsam genutzten Speicherheap.
5. Wenn beim Exchange-Informationsspeicher keine Fehler oder Probleme mit der Leistung auftreten, wird der Prozess ExIPC abgeschlossen, und die Daten werden erfolgreich von IIS an den Exchange-Informationsspeicher übertragen. Wenn eine Warteschlange voll ist oder die Ausführung des Exchange-Informationsspeichers unterbrochen wurde, wird eine Fehlermeldung zurückgegeben.
6. Die Antwort (die E-Mail-Nachricht) wird auf der Seite des Exchange-Informationsspeichers generiert. Der Exchange-Informationsspeicher weist den erforderlichen Speicher für die Antwort aus dem gemeinsam genutzten Speicherheap zu. Diesem Speicherbereich wird eine entsprechende Zugriffsnummer zugewiesen. Die Zugriffsnummer wird dann in Richtung IIS in die Warteschlange eingefügt.
7. IIS entfernt die Zugriffsnummer aus der Umlaufwarteschlange, erstellt einen Verweis auf den Speicher und stellt eine Bindung zwischen beiden her.
Wenn auf IIS-Seite keine Fehler oder Probleme mit der Leistung auftreten, wird die Antwort vervollständigt, und die Daten werden erfolgreich vom Exchange-Informationsspeicher an IIS übertragen.
IMAP4Exchange 2003 ist mit IMAP4 rev 1 nach RFC 2060, RFC 2088 und RFC 1731 konform. IMAP umfasst über 30 Befehle, über die Nachrichten durchsucht, empfangen und vom Exchange-Server entfernt werden können. IMAP ist sehr gut für die Online- und Offline-Verwendung geeignet. Mit IMAP können Verbindungen mit mehreren Postfächern hergestellt werden (bei entsprechenden Berechtigungen). Außerdem können Öffentliche Ordner für andere Zwecke als E-Mail-Nachrichten wie Newsdienste verwendet werden.
IMAP4 bietet erheblich mehr Funktionen als POP3. IMAP4 ermöglicht Benutzern den Zugriff auf ihre Ordner und nicht nur auf ihren Posteingang. Daher ist es komplexer als POP3.
554
Trotzdem ist es auch ein Protokoll für den Lesezugriff. Wie POP3 verwendet auch IMAP4 SMTP für das Senden von E-Mail-Nachrichten.
Exchange 2003 unterstützt die in der folgenden Tabelle aufgeführten IMAP4-Befehle.
Von Exchange Server 2003 unterstützte IMAP4-Befehle
Befehl Beschreibung
APPEND Fügt das Literalargument als eine neue Nachricht an das Ende des angegebenen Postfachs an. Dieses Argument muss das Format einer RFC-822-Nachricht haben.
AUTHENTICATE Gibt ein Authentifizierungsverfahren für den Server an (z. B. AUTHENTICATE KERBEROS_V5).
CAPABILITY Wird zum Anfordern einer Liste der vom Server unterstützten Funktionen verwendet.
CHECK Wird zum Anfordern eines Prüfpunkts des derzeitig ausgewählten Postfachs verwendet. Ein Prüfpunkt bezieht sich auf implementierungsabhängige Details zum Postfach (z. B. Auflösen des Speicherstatus des Servers für das Postfach mit dem Status auf seinem Datenträger), die nicht bei jedem Befehl ausgeführt werden.
CLOSE Entfernt dauerhaft alle Nachrichten aus dem ausgewählten Postfach, für die das Kennzeichen \Deleted festgelegt wurde, und wechselt vom ausgewählten Zustand in den authentifizierten Zustand zurück.
COPY Wird zum Kopieren der ausgewählten Nachricht(en) an das Ende des Zielpostfachs verwendet. Die Kennzeichnungen und internen Daten der Nachricht(en) werden bei der Kopie beibehalten.
CREATE Wird zum Erstellen eines Postfachs mit dem angegebenen Namen verwendet. Es wird nur OK als Antwort gesendet, wenn ein neues Postfach mit diesem Namen erstellt wird.
555
Befehl Beschreibung
DELETE Entfernt das Postfach mit dem angegebenen Namen dauerhaft. Es wird nur OK als Antwort mit Tags zurückgegeben, wenn das Postfach gelöscht wird.
EXAMINE Ist mit SELECT identisch und gibt dieselbe Ausgabe zurück. Das ausgewählte Postfach wird allerdings als schreibgeschützt gekennzeichnet. Es sind keine dauerhaften Änderungen am Zustand des Postfachs, einschließlich des Zustands auf Benutzerebene, zulässig.
EXPUNGE Entfernt alle Nachrichten aus dem ausgewählten Postfach, für die das Kennzeichen \Deleted festgelegt wurde.
FETCH Ruft die einer Nachricht im Postfach zugeordneten Daten ab.
LIST Gibt eine Untermenge der dem Client zur Verfügung stehenden Namen zurück.
LOGIN Meldet den Client am Server an und führt die unverschlüsselte Authentifizierung für den Benutzer durch.
LOGOUT Informiert den Server darüber, dass der Client die Verbindung trennen möchte.
LSUB Gibt eine Untermenge der Namen zurück, die der Benutzer als Aktiv oder Abonniert gekennzeichnet hat.
NOOP Dieser Befehl wird als „keine Operation“ interpretiert. Obwohl dieser Befehl keine Aktion ausführt, antwortet der Server bei erfolgreichem Ausführen des Befehls mit einer positiven Antwort (OK+). Sie können mit diesem Befehl testen, ob der Server in Betrieb ist und Clientanforderungen empfängt.
RENAME Ändert den Namen des Postfachs. Es wird nur OK als Antwort mit Tags zurückgegeben, wenn das Postfach umbenannt wird.
556
Befehl Beschreibung
SEARCH Durchsucht das Postfach auf Nachrichten, die den angegebenen Suchkriterien entsprechen. Die Suchkriterien setzen sich aus einem oder mehreren Suchschlüsseln zusammen.
SELECT Wählt ein Postfach aus, sodass auf Nachrichten in dem Postfach zugegriffen werden kann.
STATUS Fragt den Status des angegebenen Postfachs ab. Dabei werden weder Änderungen am ausgewählten Postfach vorgenommen, noch hat dies Auswirkungen auf den Status der Nachrichten in dem Postfach.
STORE Ändert die einer Nachricht im Postfach zugeordneten Daten.
SUBSCRIBE Fügt den angegebenen Postfachnamen zur Liste der als Aktiv oder Abonniert gekennzeichneten Postfächer des Server hinzu, die mit dem LSUB-Befehl abgefragt werden können. Dieser Befehl gibt nur OK als Antwort mit Tags zurück, wenn die Abonnierung erfolgreich durchgeführt wurde.
UID Dieser Befehl tritt in zwei Formen auf. In der ersten Form übernimmt er als Argumente die Befehle COPY, FETCH oder STORE mit den zugeordneten Argumenten dieser Befehle. In der zweiten Form übernimmt der UID-Befehl einen SEARCH-Befehl mit den zugehörigen Argumenten.
UNSUBSCRIBE Entfernt den angegebenen Postfachnamen aus der Liste der als Aktiv oder Abonniert gekennzeichneten Postfächer des Servers, die mit dem LSUB-Befehl abgefragt werden können. Dieser Befehl gibt nur OK als Antwort mit Tags zurück, wenn die Aufhebung des Abonnements erfolgreich durchgeführt wurde.
557
NNTPNNTP (Network News Transfer Protocol) ist ein TCP/IP-Protokoll, das auf Textzeichenfolgen basiert, die in zwei Richtungen über 7 Bit-ASCII-TCP-Kanäle gesendet werden. IETF ist für das NNTP-Protokoll verantwortlich, das in RFC 977 definiert ist. NNTP wird häufig als Internet-Newsprotokoll bezeichnet, da es die Regeln für den Transport von Newsbeiträgen zwischen Computern enthält. NNTP wird in diesem Dokument als Client/Server-Protokoll behandelt. Es dient auch für die Übertragung von Newsbeiträgen zwischen Servern.
Der NNTP-Dienst in Windows wurde zum Unterstützen eines alleinstehenden Newsgroupservers konzipiert, der das Erstellen von Gruppendiskussionen vereinfacht. Wenn Exchange 2003 installiert ist, wird der NNTP-Dienst um die Möglichkeit erweitert, mit anderen Newsservern über Newsfeeds zu kommunizieren. Der NNTP-Dienst kann mit externen NNTP-Servern kommunizieren, um den Benutzern beliebte USENET-Gruppen zur Verfügung zu stellen.
Der eigenständige Speicherort für den NNTP-Dienst befindet sich in einem oder mehreren Verzeichnissen des Dateisystems. Bei Exchange Server 2003 kann der NNTP-Dienst auch Newsgroups in Öffentlichen Ordnern einer beliebigen verfügbaren Struktur Öffentlicher Ordner speichern. Der Ordner Internet-Newsgroups ist der Standardspeicherort für Newsgroups. Der NNTP-Dienst verwendet virtuelle Verzeichnisse für Verweise auf diese Speicherorte.
Sie können mehrere Newsserver in einer Struktur mit Masterserver/Untergeordneter Server anordnen. Dies ermöglicht Clients das Herstellen von Verbindungen mit großen Servergruppen bei genauen Ansichten der Newsgroupinhalte. Eine Serverbank oder -gruppe bietet zusätzliche Möglichkeiten der Skalierung für viele Clients und eine Fehlertoleranz, wenn untergeordnete Server nicht mehr verfügbar sind.
Die NNTP-Implementierung von Exchange Server 2003 bietet die folgenden zusätzlichen Funktionen für dieses Protokoll:
Die Inhaltsindizierung bietet Suchfunktionen für Öffentliche Ordner.
Vollständige Newsfeeds werden unabhängig von der Back-End-Speicherung akzeptiert.
MAPI- und NNTP-Clients können in Newsgroups lesen und veröffentlichen, die vom Microsoft Exchange-Informationsspeicher unterstützt werden.
Konfigurationseinstellungen in Active DirectoryObwohl Exchange in IIS integriert ist, werden nach der Installation von Exchange 2003 die virtuellen Protokollserver vom Exchange-System-Manager und nicht vom Internetdienste-Manager verwaltet. Wenn Sie ein Element im Exchange-System-Manager hinzufügen, entfernen oder konfigurieren, werden die Änderungen an der Konfiguration erst im Microsoft Active Directory-Verzeichnisdienst gespeichert und dann mit der im Prozess Systemaufsicht
558
ausgeführten DS2Mb-Funktion (Directory Service/Metabase Synchronization) in die IIS-Metabase auf dem entsprechenden Exchange 2003-Server repliziert.
Hinweis: You can view a semi-graphical representation of Exchange 2003 configuration information stored in Active Directory in Microsoft Knowledge Base article 252370, "Layout of Exchange Configuration in Active Directory."
Konfigurationseinstellungen in der MetabaseDie IIS-Metabase ist eine hierarchische Datenbank, die zum Speichern von Konfigurationswerten für IIS und Exchange 2003 verwendet wird. Die IIS-Metabase ist ein Speicherverfahren und ein API-Satz (Application Programming Interface), der zum Ändern von Konfigurationsparametern verwendet wird.
Der DS2MB-Prozess hat die Funktion, Konfigurationsinformationen von Active Directory zur lokalen IIS-Metabase des Exchange-Servers zu übertragen. Aus Gründen der Leistung und Skalierbarkeit wird diese Konfiguration in der lokalen IIS-Metabase und nicht in der Registrierung gespeichert.
Hinweis: Auf Computern unter Windows 2000 Server befindet sich die IIS-Metabase unter System32\Inetsrv\Metabase.bin. Auf Computern unter Windows Server 2003 finden Sie die IIS-Metabase in metabase.xml. Die Metabase kann mithilfe verschiedener Tools bearbeitet werden Auf Computern unter Windows Server 2003 können Sie das integrierte Tool IISCNFG verwenden. Auf Computern unter Windows 2000 Server wird MetaEdit 2.2 oder höher aus dem IIS-Resource Kit empfohlen. Das IIS 6.0-Resource Kit steht unter auf der Website Internet Information Services (IIS) 6.0 Resource Kit Tools zum Download bereit.
Pfade werden in der Metabase als Schlüssel bezeichnet. Für jeden Schlüssel können Eigenschaften festgelegt werden. Jede Eigenschaft kann über Attribute zur Anpassung der betreffenden Eigenschaft verfügen. Alle Bezeichner, die im Verzeichnisdienstabbild der Unterstruktur enthalten sind (z. B. KeyType) werden auch in der Metabase benötigt. Außerdem wird der relative DN (Relative Distinguished Name) des Objekts im Verzeichnis direkt dem Schlüsselnamen in der Metabase zugeordnet.
Aktualisieren der IIS-Metabase mit DS2MBDS2MB ist ein Unterprozess, der zusammen mit der Systemaufsicht und anschließend alle 15 Minuten gestartet wird. DS2MB kopiert alle Unterstrukturen von Active Directory, ohne die Anordnung der Unterstruktur zu ändern. Dabei handelt es sich um einen Schreibvorgang in einer Richtung von Active Directory zur Metabase. Die Metabase schreibt niemals ins Active Directory. Beim Kopieren werden keine Attribute hinzugefügt oder bearbeitet.
559
Hinweis: Der DS2MB-Prozess überschreibt mithilfe des IIS-Snap-Ins Änderungen an den virtuellen Exchange-Servern und -Verzeichnissen mit den Informationen aus Active Directory.
Die Funktion von SMTP, POP3, IMAP4 und HTTP ist von der Replikation durch DS2MB abhängig. Nicht alle Einstellungen werden aus Active Directory synchronisiert, einige werden während der Installation von Exchange direkt in die Metabase geschrieben.
Bei der Instanziierung führt DS2MB eine Registrierung am Konfigurationsdomänencontroller durch. Der Konfigurationsdomänencontroller informiert DS2MB innerhalb von 15 Sekunden über alle Änderungen an der Exchange-Konfiguration. Sobald die Änderung auf den Konfigurationsdomänencontroller repliziert wurde, muss sie durch DS2MB in der Metabase repliziert werden.
HochwassermarkenHochwassermarken sind Einträge in der Metabase, mit denen DS2MB Änderungen verfolgen kann, die aus Active Directory synchronisiert wurden. Die Einträge für Hochwassermarken werden in der IIS-Metabase als GUIDs eingegeben. Diese GUIDs werden in der Metabase unter dem Knoten [/DS2MB/HighWaterMarks] wie folgt angezeigt:[/DS2MB/HighWaterMarks]KeyType : (STRING) "Ds2mbHighwatermarks"[/DS2MB/HighWaterMarks/{BE583A06-9083-400F-954C-CF4ACCA78B04}][/DS2MB/HighWaterMarks/{028C8F78-8CF0-43D9-9B35-9819D538849F}][/DS2MB/HighWaterMarks/{84ECD394-05BB-4661-BA1D-81D3E32BF804}]
Da DS2MB die Eingabe und Synchronisierung von Hochwassermarken in der Metabase behandelt, ist es i. d. R. nicht erforderlich, diese Informationen anzupassen oder zu verwalten. Es gibt allerdings Situationen, in denen die Auflösung das Löschen der Einträge für die Hochwassermarken aus der Metabase erforderlich macht, um diese zurückzusetzen.
Front-End-ServerarchitekturEin Front-End-Server ist ein Server mit Exchange Server 2003, der nicht als Host für eine Datenbank fungiert (außer wenn er auch als SMTP-Server dient), sondern stattdessen Clientanforderungen für die Verarbeitung an den Back-End-Server weiterleitet. Der Front-End-Server verwendet LDAP (Lightweight Directory Access Protocol) für das Abfragen von Active Directory zur Bestimmung des Back-End-Servers mit dem Postfach des Benutzers. Ein Back-End-Server ist ein Server mit Exchange Server 2003, der mindestens eine Datenbank verwaltet.
Diese Architektur ist nur bei RPC über HTTP-, HTTP/WebDAV-, POP3- und IMAP4-Clients verfügbar. Sie ist nicht für MAPI- oder NNTP-Clients vorgesehen. Die unterstützten Clients
560
stellen eine Verbindung mit einem Front-End-Server her, der als Proxy für Clientbefehle an den Back-End-Server mit dem Exchange-Informationsspeicher des Benutzers dient.
Diese funktionale Trennung zwischen Front-End-Server und Back-End-Server bietet einige Vorteile. Beispiel:
Einheitlicher Namespace Da mehrere Back-End-Server für die Verwaltung zusätzlicher Postfächer konfiguriert werden, sollten alle Server durch einen einheitlichen Namen gekennzeichnet werden. Sie können auf einen Front-End-Server mit einem einzigen Namen verweisen, und dieser fungiert dann als Proxy für Benutzeranforderungen an den entsprechenden Back-End-Server mit dem Benutzerpostfach. Wenn mehrere Front-End-Server für das Verwalten einer großen Anzahl von Anforderungen konfiguriert wurden, wird ein einheitlicher Namespace für diese Server erstellt, indem das DNS (Domain Name System) mit einem Namen konfiguriert wird, der der IP-Adresse auf dem Server zugeordnet ist. Es ist unbedeutend, zu welchem Front-End-Server der Client eine Verbindung herstellt.
Verschieben von SSL Für das Verschlüsseln und Entschlüsseln des Nachrichtenverkehrs werden viele CPU-Zyklen benötigt. Ein Front-End-Server kann die Verschlüsselung übernehmen, wodurch der Back-End-Server zusätzliche Zyklen für das Verwalten der Informationsspeicher für das Postfach und die Öffentlichen Ordner zur Verfügung hat.
Verweis auf Öffentliche Ordner für IMAP4-Clients Viele IMAP4-Clients unterstützen keine Verweise. Mithilfe dieser Architektur kann der Front-End-Server Öffentliche Ordner abrufen, die sich auf einem anderen Server als dem E-Mail-Server des Benutzers befinden.
Serverstandort Sie können die Back-End-Server mit den Datenbanken hinter einer Firewall platzieren, um die Sicherheit zu erhöhen. Sie können die Firewall so konfigurieren, dass nur der Datenverkehr vom Front-End-Server übertragen wird. Zusätzlich können Sie einen Reverse-Proxyserver (z. B. einen ISA-Server) vor dem Front-End-Server platzieren und nur den Front-End-Server veröffentlichen. Es ist nicht erforderlich, die Back-End-Server mit dem Postfach im Internet zu veröffentlichen. Daher können Sie Ihre Firewalls und Reverse-Proxyserver so konfigurieren, dass diese nur den Datenverkehr an den Front-End-Server weiterleiten.
Überlegungen zur Verwendung von Front-End-ServernSie können Exchange Server 2003 Standard Edition oder Exchange Server 2003 Enterprise Edition für die Verwendung als Front-End-Server in einer Front-End-/Back-End-Serverkonfiguration verwenden. Sie sollten bei der Verwendung einer der beiden Editionen als Front-End-Server Folgendes berücksichtigen:
561
Wenn der Front-End-Server SMTP-Mail aus dem Internet annimmt, müssen Sie den Microsoft Exchange-Informationsspeicherdienst starten und mindestens einen Postfachspeicher bereitstellen. In einigen Situationen (besonders beim Generieren von Unzustellbarkeitsberichten) ist für den SMTP-Dienst ein Postfachspeicher für die Konvertierung erforderlich.
Wenn der Postfachspeicher nicht bereitgestellt wird, verbleiben Nachrichten, die konvertiert werden müssen, in der lokalen Zustellwarteschlange. Aus Sicherheitsgründen sollten Sie sicherstellen, dass sich die Benutzerpostfächer nicht im Postfachspeicher eines Front-End-Servers befinden. Wenn es an demselben Standort (Routinggruppe) Server mit Exchange Server 5.5 gibt, sollten Sie den Microsoft Exchange-MTA-Stacks-Dienst für die Ausführung auf dem Front-End-Server konfigurieren. In dieser Konfiguration können die MTAs E-Mail-Nachrichten mithilfe von Remoteprozeduraufrufen binden und übertragen.
Wenn sich auf dem Front-End-Server X.400-Connectors oder EDK-Gateway-Connectors (Exchange Development Kit) befinden, muss auch der MTA-Dienst auf dem Front-End-Server ausgeführt werden. Wenn Sie alle Öffentlichen Ordner und Postfachspeicher löschen, können Sie die Konfiguration nicht mit dem Internetdienste-Manager ändern.
Wenn Sie die Konfiguration mit dem Internetdienste-Manager ändern müssen, z. B. bei Änderungen an der Konfiguration der SSL-Verschlüsselung, sollten Sie unbedingt die in diesem Handbuch beschriebenen Verfahren ausführen, bevor Sie die Speicher entfernen, oder den privaten Informationsspeicher auf dem Front-End-Server beibehalten.
Beim Erstellen eines Front-End-Servers sollte das erste Speichergruppenobjekt im Exchange-System-Manager nicht gelöscht werden. Der Microsoft Exchange-Informationsspeicherdienst und die zugehörigen Dienste sind vom ersten Speichergruppenobjekt abhängig.
Exchange ActiveSync und Exchange 2003Exchange ActiveSync ermöglicht das Synchronisieren von Daten zwischen einem Mobilgerät und Exchange Server 2003. E-Mail-Nachrichten, Kontakte und Kalenderinformationen (PIM-Daten, Personal Information Manager) können ebenfalls synchronisiert werden. Dieses Feature war ursprünglich über Mobile Information Server verfügbar und wurde als Microsoft Server ActiveSync bezeichnet. Es wurde nun in Exchange Server 2003 integriert.
Mit Mobile Information Server wurde auf Geräten unter Microsoft Windows Powered Pocket PC 2002, Microsoft Windows Powered Pocket PC 2002 Phone Edition und Microsoft Windows Powered Smartphone die Server ActiveSync-Clientkomponente installiert und unterstützt.
562
Bei Exchange ActiveSync werden Geräte unter Pocket PC 2002, Pocket PC 2002 Phone Edition und Smartphone weiter unterstützt. Außerdem werden Microsoft Windows Powered Pocket PC 2003-Geräte unterstützt. Pocket PC 2003-Geräte ermöglichen eine höhere Granularität beim Planen der Synchronisierung und unterstützen die Always-Up-To-Date-Funktion, die mit Exchange Server 2003 eingeführt wurde.
Exchange ActiveSync ist in den folgenden Dateien implementiert:
Massync.dll ISAPI-Erweiterungs-DLL für die OMA-Synchronisierung
Masperf.dll Leistungsindikator-DLL für die OMA-Synchronisierung
MasPerf.ini Leistungsindikator-INI für die OMA-Synchronisierung
Masperf.h Leistungsindikator-Header für die OMA-Synchronisierung
Exchange ActiveSync-ProtokollarchitekturDas Sync-Protokoll ist ein Anforderungs- und Antwortprotokoll, das auf einem Kommunikationsmodell für Client und Server basiert. Es beruht auf dem HTTP-Protokoll und verwendet HTTP POST-Anforderungen und -Antworten sowie den HTTP OPTIONS-Befehl. Der HTTP POST-Header gibt einen Protokollbefehl an. Wenn es für den Befehl erforderlich ist, werden die Befehlsdaten im HTTP POST-Nachrichtentext gesendet. Die Daten werden i. d. R. als komprimiertes WbXML (Wireless Binary XML) formatiert, das die eingeschränkte Bandbreite von mobilen Clients effizient ausnutzt.
Der Client initiiert die Kommunikation durch das Veröffentlichen einer Anforderung. Wenn der Server die Anforderung empfängt, analysiert er diese und sendet eine HTTP POST-Antwort, die im Text die angeforderten Daten enthält.
Für das Sync-Protokoll ist eine TCP/IP-Verbindung zwischen dem Client und dem Server erforderlich. Die zugrunde liegenden Netzwerkebenen sind allerdings implementierungsabhängig. Drei allgemeine Transportebenen, die das Protokoll unterstützen, sind GPRS, CDMA 1xRTT und IEEE 802.11. Es ist für das Sync-Protokoll erforderlich, dass Übertragungsfehler durch die Netzwerksoftware behandelt werden und dass die zwischen Client und Server gesendeten Protokollnachrichten vollständig und fehlerfrei sind.
Das Sync-Protokoll soll es jedem mobilen Client ermöglichen, PIM-Daten effizient mit den Daten auf einem Exchange-Server zu synchronisieren. Deshalb verwendet der Client das Sync-Protokoll für die Kommunikation mit der Exchange-Komponente für den Front-End-Server, die die Synchronisierung durch das Abrufen von Daten vom Exchange-Informationsspeicher erreicht.
Die folgende Abbildung zeigt die funktionalen Komponenten des für das Sync-Protokoll verwendeten Kommunikationsmodells zwischen Client und Server.
563
Exchange ActiveSync-Kommunikation zwischen Client und Server
Die folgenden Schritte werden bei allen Befehlen ausgeführt, die der Client an den Server sendet:
1. Der Client erstellt eine Anforderung und sendet diese als HTTPS POST an den Synchronisierungsserver.
2. Der Synchronisierungsserver verarbeitet die Anforderung und kommuniziert mit dem Exchange-Back-End-Server, um auf die PIM-Daten des Benutzers zuzugreifen.
3. Der Synchronisierungsserver erstellt eine Antwort und sendet diese als HTTPS POST an den Client.
4. Der Client verarbeitet die Antwort und aktualisiert ggf. die lokalen PIM-Daten.
Die folgenden Schritte werden ausgeführt, wenn der Client einen Synchronisierungsbefehl sendet:
1. Der Client ermittelt alle Änderungen an den lokalen PIM-Daten seit der letzten Synchronisierung.
2. Der Client erstellt einen Synchronisierungsbefehl mit diesen Änderungen.
3. Er sendet den Befehl als HTTP POST an den Synchronisierungsserver.
4. Der Synchronisierungsserver ermittelt die Änderungen an den Daten auf dem Server seit der letzten Synchronisierung und kommuniziert mit dem Exchange-Back-End-Server, um auf die Benutzerdaten zuzugreifen.
5. Er löst mögliche Konflikte zwischen den Änderungen an den Elementen auf dem Client und dem Server auf.
564
6. Der Synchronisierungsserver erstellt eine Antwort mit den Serveränderungen, die auf den Client repliziert werden sollen.
7. Der Synchronisierungsserver sendet die Antwort als HTTPS POST-Antwort.
8. Der Client verarbeitet die Antwort und aktualisiert die lokalen PIM-Daten.
Versionen des Sync-Protokolls und GeräteunterstützungFür Exchange ActiveSync ist es erforderlich, dass der Client und der Server dieselbe Protokollversion verwenden. Microsoft Mobile Information Server verwendet das ActiveSync-Protokoll v1.0 für Exchange ActiveSync. Exchange Server 2003 verwendet das neue und verbesserte ActiveSync-Protokoll v2.0 für Exchange ActiveSync. Das ActiveSync-Protokoll v1.0 wird für die Abwärtskompatibilität aber weiter unterstützt.
Von Mobile Information Server 2002 und Exchange Server 2003 unterstützte ActiveSync-Protokolle
Server Unterstützte Protokolle
Mobile Information Server 2002 1.0
Exchange Server 2003 1.0 und 2.0
Der Pocket PC 2002-Client verwendet das ActiveSync-Protokoll v1.0 für Exchange ActiveSync. Dieses kann für Mobile Information Server und Exchange Server 2003 mit v1.0 verwendet werden. Der Pocket PC 2003-Client unterstützt die Protokolle v1.0 und v2.0. Das zu verwendende Protokoll kann verhandelt werden.
Tabelle 9.6 Von Pocket PC 2002- und Pocket PC 2003-Geräten unterstützte ActiveSync-Protokolle
Gerät Unterstützte Protokolle
Pocket PC 2002 1.0
Pocket PC 2003 1.0 und 2.0
Somit können Pocket PC 2002- und Pocket PC 2003-Geräte mit Mobile Information Server und Exchange 2003 verwendet werden.
Befehle des Sync-ProtokollsBeim ActiveSync-Protokoll v1.0 umfasst eine typische Synchronisierungssitzung die folgenden Befehle:
565
GetHierarchy Dieser Befehl wird zum Abrufen der gesamten Ordnerhierarchie verwendet.
GetItemEstimate Dieser Befehl wird vom Client für das Schätzen der Anzahl der zu synchronisierenden Elemente verwendet. Der Client übergibt eine Liste der Ordner, für die er eine Schätzung benötigt. Bei dieser Schätzung wird die Anzeige der Fortschrittsleiste auf dem Gerät verwendet.
Sync Dieser Befehl wird zum Initiieren der Synchronisierung verwendet. Im Sync-Befehl sind weitere Befehle eingebettet (z. B. Add und Change).
Das ActiveSync-Protokoll, Version 2.0, unterstützt zwei weitere Befehle: Folder sync und AUTD (Always Up-To-Date):
Folder Sync Dieser Befehl wird anstelle des GetHierarchy-Befehls verwendet. Der FolderSync-Befehl synchronisiert die Hierarchieauflistung so, wie einzelne Ordner synchronisiert werden.
AUTD Dieser Befehl ermöglicht Benutzern das automatische Synchronisieren des Mobilgeräts mit dem Server, wenn dieser neue Element empfängt. Weitere Informationen finden Sie weiter unten in diesem Thema im Abschnitt „Aktuelle Benachrichtigungen“.
Format des Sync-BefehlsProtokollbefehle werden als HTTP POST gesendet. Einige einfache Befehle sind im URI (Unified Resource Identifier) der Clientanforderung enthalten, während bei komplexeren Befehlen die zusätzlichen Informationen zum Befehl im HTTP-Nachrichtentext enthalten sind.
Eine Synchronisierungssitzung besteht häufig aus mehreren Befehlen. In diesem Fall umfasst die Sitzung mehrere Paare von Befehlsanforderungen und Antworten, die zwischen Client und Server gesendet werden.
Eine Anforderung besteht aus drei Teilen:
URI Dieser Teil umfasst die Serveradresse sowie verschiedene Parameter einschließlich des Befehlsnamens.
HTTP-Header Dieser Teil enthält zusätzliche Parameter, die vom Server verwendet und im HTTP-Standardformat gesendet werden.
HTTP-Nachrichtentext Dieser Teil enthält Daten, die für den Befehl erforderlich sind. Das Format ist für die einzelnen Befehle unterschiedlich, und bei einigen Befehlen ist kein Nachrichtentext vorhanden.
URIDas folgende Beispiel zeigt einen typischen URI für eine Synchronisierungsanforderung:POST /Microsoft-Server-ActiveSync?User=johndoe&
566
DeviceId=789123456789012345&DeviceType=PocketPC&Cmd=Sync
Die Parameter, z. B. Cmd, User und DeviceId, werden vom Client mit jeder Anforderung gesendet. Der wichtigste Parameter ist Cmd. Der Cmd-Parameter teilt dem Server die auszuführende Operation mit. In diesem Beispiel teilt das im Cmd-Parameter übergebene Sync-Argument dem Server mit, dass eine Synchronisierungsoperation durchgeführt werden soll. Im HTTP POST-Nachrichtentext sind zusätzliche Daten enthalten.
HTTP-HeaderZusätzlich zum URI sendet der Client auch einige allgemeine Informationen im HTTP-Header. Das folgende Beispiel zeigt den gesamten HTTP POST-Header der Anforderung zusammen mit dem URI:POST Microsoft-Server-ActiveSync?User=johndoe&DeviceId=789123456789012345&DeviceType=PocketPC&Cmd=SyncAccept-Language: en-usMS-ASProtocolVersion: 2.0Content-Type: application/vnd.ms-sync.wbxml
Der Server antwortet mit einigen allgemeinen Informationen im Header. Der folgende Eintrag enthält den HTTP POST-Header der Antwort:HTTP/1.1 200 OKContent-Length: 114Date: Mon, 15 Mar 2004 11:07:44 GMTContent-Type: application/vnd.ms-sync.wbxmlServer: Microsoft-IIS/6.0MicrosoftOfficeWebServer: 5.0_PubX-Powered-By: ASP.NETPragma: no-cacheMS-Server-ActiveSync: 2.0.3273.0
HTTP-NachrichtentextDer Nachrichtentext der Anforderung enthält Daten, die an den Server gesendet werden. Der Typ und das Format der Daten sind vom Befehl abhängig. Das am häufigsten verwendete Format ist XML. Die Details sind wiederum vom Befehl abhängig. Befehle, die E-Mail-Nachrichten senden, verwenden das RFC 822-Format anstelle von XML. Bei einigen Befehlen sind keine zusätzlichen Daten erforderlich. In diesem Fall ist der Nachrichtentext leer.
Der Nachrichtentext der Antwort enthält Daten, die vom Server zurückgegeben werden. Wie beim Nachrichtentext der Anforderung ist das Format vom Befehl abhängig. Normalerweise ist die Antwort im WbXML-Format. Wenn der Nachrichtentext eine E-Mail-Anlage enthält, ist das Format vom Typ der Anlagedatei abhängig. Bei einigen Befehlen wird kein Nachrichtentext verwendet.
567
Protokollunabhängige Multicastdaten auf dem MobilgerätProtokollunabhängige Multicastdaten werden in Auflistungen gespeichert. Es gibt eine Auflistung für Kontakte, eine für den Kalender und eine für jeden E-Mail-Ordner. Das Sync-Protokoll unterstützt das Synchronisieren mehrerer E-Mail-Ordner. Die Clientsoftware speichert für jede Auflistung einen SyncKey. SyncKey enthält 39 bis 48 Zeichen, 38 Zeichen für die GUID (Globally Unique Identifier) und ein bis zehn Zeichen für die sich jeweils erhöhende Nummer. Außerdem speichert der Client eine CollectionId. CollectionId ist eine Zeichenfolge von ungefähr 40 Zeichen für jeden Ordner, die als eindeutige ID für den Ordner dient.
Der Client sendet SyncKey mit jeder Synchronisierungsanforderung an den Server. Jedes synchronisierte Objekt, egal ob Nachricht, Kontakt oder Kalenderelement, verfügt über eine vom Server zugewiesene eindeutige ID. Diese Server-ID ist eine Zeichenfolge von 48 Zeichen, die vom Client gespeichert wird. Die ID wird bei der Synchronisierung für das Ermitteln der auf dem Client und dem Server gespeicherten Objekte verwendet.
Exchange ActiveSync-ProfilDer Synchronisierungsstatus wird auf dem Exchange-Server in einem versteckten Ordner im Postfach des Benutzers gespeichert. Die Synchronisierungsstatus für E-Mail-Nachrichten, Kalenderelemente und Kontakte sowie FolderSync befinden sich im Ordner Microsoft-Server-ActiveSync/PocketPC/GeräteID im NON_IPM_SUBTREE des Postfachs des Benutzers. Der Suchordner mit der Ordnerhierarchie wird ebenfalls an diesem Ort gespeichert.
Aktuelle BenachrichtigungenExchange ActiveSync wird auf dem Gerät so konfiguriert, dass in Intervallen ab 5 Minuten eine Synchronisierung mit dem Server erfolgt. ActiveSync stellt aber keine aktuellen Informationen über das Gerät bereit. Für den Benutzer können bei häufigen Synchronisierungssitzungen zusätzliche Kosten entstehen.
Aktuelle Benachrichtigungen sind eine neue Funktion in Exchange Server 2003, mit der Benutzer automatisch ein Pocket PC 2003- oder ein Microsoft Windows Mobile 2003-Gerät mit dem Server synchronisieren können, wenn neue Elemente auf dem Server empfangen werden. Aktuelle Benachrichtigungen sind eine Funktion von Exchange ActiveSync, das mit Exchange Server 2003 installiert wird.
Wenn eine neue Nachricht eintrifft, wird im Exchange-Konto des Benutzers ein Ereignis generiert. Durch dieses Ereignis wird eine SMS-Benachrichtigung (Short Message Service) an das Gerät des Benutzers gesendet. Das Gerät führt die Synchronisierung im Hintergrund
568
durch. Die Benutzerdaten werden mit den aktuellsten Informationen aktualisiert, ohne dass der Benutzer eingreifen muss.
Die Benachrichtigung wird als SMS-Steuernachricht an das Gerät gesendet. Diese unterscheidet sich von einer herkömmlichen SMS-Benachrichtigung, da sie nicht als SMS-Nachricht im Posteingang angezeigt wird. Der SMS-Router und Exchange ActiveSync auf dem Gerät verarbeiten die Benachrichtigung. Die Benachrichtigung selbst enthält keine vertraulichen Daten.
Die Benachrichtigungen können von Exchange Server 2003 direkt an die SMS-Adresse des Geräts oder über einen vom Exchange-Administrator konfigurierten Aggregator (z. B. einen Firmendienstanbieter) gesendet werden. Damit Nachrichten an die SMS-Adresse des Geräts gesendet werden können, muss der Administrator im Exchange-System-Manager einen SMTP-Netzbetreiber erstellen.
AggregatorenOrganisationen können Gerätebenachrichtigungen über einen Aggregator senden. Der einzige zurzeit verfügbare Aggregator ist MSN Internet Access. Zum Einrichten eines Aggregators muss sich die Organisation unter Verwendung eines Passport-Kontos auf einer sicheren Website anmelden und die Netzbetreiber auswählen, die mit MSN verwendet werden sollen. Die Organisation erhält dann von MSN die Anmeldeinformationen für die sichere Übertragung von Benachrichtigungen.
Anschließend muss der MSN-Netzbetreiber in Active Directory erstellt werden. Dafür wird die spezielle Datei MSNCarrierConfigurator.zip bereitgestellt. Die ZIP-Datei enthält die Dateien CreateMSNCarrier.cmd und CarrierConfig.LDF, die zum Einrichten des MSN-Netzbetreibers verwendet werden.
Nach dem Erstellen des MSN-Netzbetreibers in Active Directory erstellt der Administrator mithilfe der bei der Benutzeranmeldung empfangenen Anmeldeinformationen einen SMTP-Connector für die sichere Übertragung von Benachrichtigungen an MSN. Wenn ein Administrator einen SMTP-Netzbetreiber konfiguriert, um Benachrichtigungen direkt an die SMS-Adresse des Geräts zu senden, wird diese über den SMTP-Gateway des Mobilfunknetzbetreibers an das SMS-Center (SMS-C) des Betreibers übertragen. Die SMTP-Gateways von Netzbetreibern haben häufig lange Nachrichtenverzögerungen, und die Übertragungszeit von SMS-Nachrichten beträgt nicht selten mehr als eine Stunde. Dies hebt die Vorteile von aktuellen Benachrichtigungen teilweise wieder auf, da den Benutzern keine aktuellen Informationen zur Verfügung gestellt werden können.
Es gibt auch Sicherheitsprobleme beim Weiterleiten von Nachrichten über den SMTP-Gateway eines Netzbetreibers. Mit einem Aggregator können Sie über TLS (Transport Layer Security) eine Verbindung mit Microsoft Mobile Dienste herstellen. Dies ermöglicht Firmen das Herstellen von Verbindungen mit einem oder mehreren Netzbetreibern, mit denen Microsoft Mobile Dienste eine Kooperation für aktuellen Benachrichtigungen eingegangen ist.
569
Outlook Mobile Access und Exchange 2003Microsoft Exchange Server 2003 bietet eine mobile Browserlösung mit der Bezeichnung Outlook Mobile Access. Outlook Mobile Access generiert ein HTML-, xHTML- oder cHTML-Markup für die Anzeige auf Mobilgeräten, die in der Liste genehmigter Geräte enthalten sind. WML (Wireless Markup Language) kann ebenfalls generiert werden, aber Microsoft hat WML nicht für alle Geräte- und Gatewaykonfigurationen getestet. Daher wird WML nicht unterstützt. Die meisten Geräte arbeiten aber mit Outlook Mobile Access.
Outlook Mobile Access wird als Standard installiert, aber global deaktiviert, obwohl alle Benutzer für den mobilen Zugriff aktiviert sind. Die Benutzerführung ähnelt der von Microsoft Outlook Web Access. Die Verbindung zu Outlook Mobile Access erfolgt über einen URL, i. d. R. über http://Servername/oma. Im Gegensatz zu Microsoft Outlook Web Access können Sie aber kein bestimmtes Benutzerkonto im URL angeben. Der Grund hierfür ist, dass Outlook Mobile Access bei der Verwaltung des Sitzungszustands eine eindeutige ID zum URL hinzufügt.
Outlook Mobile Access unterstützt die folgenden Funktionen für Messaging und Zusammenarbeit:
E-Mail Lesen, Antworten, Weiterleiten, Löschen, Kennzeichnen und Verfassen von Nachrichten, Navigieren in mehreren Ordnern und Suchen von Absendern oder Empfängern.
Kalender Zusagen und Ablehnen von Besprechungsanfragen, auch unter Vorbehalt, Navigieren im Steuerelement für die Datumsauswahl sowie Verfassen und Bearbeiten von Terminen mit Teilnehmerunterstützung.
Kontakte Anzeigen, Erstellen und Bearbeiten von persönlichen Kontakten, Suchen von Kontakten in der persönlichen und globalen Adressliste (GAL), Speichern von Kontakten aus der GAL in den persönlichen Kontakten sowie E-Mail- und Telefonkontakte.
Aufgaben Anzeigen, Erstellen und Bearbeiten von Aufgaben.
Abhängigkeiten von Outlook Mobile AccessOutlook Mobile Access hat einige Abhängigkeiten. Dazu gehören .NET Framework, IIS, Sitzungsstatusverwaltung und eine geänderte URL-Sitzungs-ID. Das Programm Outlook Mobile Access basiert auf .NET Framework Windows Server 2003 installiert als Standard .NET Framework, während dieses bei Windows 2000 Server hinzugefügt werden muss. Wenn das Framework nicht installiert ist, wird die Installation beim Exchange-Setup vorgenommen. Für Outlook Mobile Access muss als Authentifizierungsmethode die Standardauthentifizierung und als Standarddokument OMA.ASPX verwendet werden. Außerdem muss der Pfad zu den ausführbaren Dateien im virtuellen Verzeichnis von Outlook Mobile Access folgendermaßen konfiguriert sein:
570
aspx,C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\
aspnet_isapi.dll,1,GET,HEAD,POST,DEBUG.
Outlook Mobile Access und .NETOutlook Mobile Access ist die einzige Exchange 2003-Komponente, die .NET Framework verwendet. Sie können die Grundlagen von Outlook Mobile Access nur bei Kenntnis von .NET Framework verstehen. Outlook Mobile Access ermöglicht das Anzeigen des Postfachs mit einem Mobilbrowser. Dieser Abschnitt enthält eine grundlegende Erklärung der Aspekte von .NET Framework und ASP.NET, die für Exchange 2003 Outlook Mobile Access und Mobilgeräte im Allgemeinen wichtig sind.
.NET Framework
.NET Framework hat zwei Hauptkomponenten: Die Common Language Runtime und die .NET Framework-Klassenbibliothek. Die Common Language Runtime bildet die Grundlage von .NET Framework. Sie ist ein Agent, der den Code zur Laufzeit verwaltet. Sie bietet Basisdienste wie die Speicher- und Threadverwaltung und erzwingt gleichzeitig die strikte Typsicherheit sowie andere Aspekte der Codegenauigkeit, die bei Fragen der Sicherheit und Robustheit wichtig sind. Das Konzept der Codeverwaltung ist sogar eines der fundamentalen Prinzipien der Common Language Runtime. Code, der für die Common Language Runtime vorgesehen ist, wird als verwalteter Code bezeichnet, während anderer Code als nicht verwalteter Code bezeichnet wird.
Die Klassenbibliothek ist eine umfangreiche, objektorientierte Auflistung wiederverwendbarer Typen, die zum Entwickeln von herkömmlichen Anwendungen für die Befehlszeile und Anwendungen mit grafischer Benutzeroberfläche (Graphical User Interface, GUI) bis hin zu Anwendungen verwendet werden, die die neuesten Funktionen von ASP.NET-Webformularen und XML-Webdiensten nutzen.
ASP.NETASP.NET ermöglicht Entwicklern die Verwendung von .NET Framework für Webanwendungen. ASP.NET ist mehr als ein Runtime-Host. ASP.NET ist eine vollständige Architektur für das Entwickeln von Websites und über das Internet verteilten Objekten mit verwaltetem Code. Webformulare und XML-Webdienste verwenden IIS und ASP.NET für die Veröffentlichung von Anwendungen. Sie verfügen beide über eine Auflistung von Unterstützungsklassen in .NET Framework.
.NET Framework bietet ebenfalls eine Auflistung von Klassen und Tools zur Unterstützung beim Entwickeln von mobilen Steuerelementen. Mobile Steuerelemente werden zum Entwickeln von Anwendungen für Handgeräte verwendet und sind gerätespezifisch. Sie
571
verringern die Entwicklungszeit und stellen sicher, dass das richtige Markup an das Clientgerät zurückgegeben wird.
ASP.NET Framework 1.1 bietet eine allgemeine Vorlage für eine Benutzeroberfläche mit Objekten, die die grundlegenden Komponenten einer Anzeige darstellen, z. B. Textbezeichnungen und Eingabefelder. Diese allgemeine Darstellung muss dann zur Laufzeit in das gerätespezifische Markup konvertiert werden.
ASP.NET bietet mobile Steuerelemente für Webformulare, die jeweils einzelne Komponenten der Benutzeroberfläche darstellen. Diese Komponenten werden für das Definieren einer Benutzeroberfläche auf einer Webseite verwendet. ASP.NET überträgt den Inhalt in der Markupsprache des entsprechenden Geräts.
Es gibt zwei Hauptprotokolle für Clients, die von den aktuellen Browsern verwendet werden: cHTML und xHTML. ASP.NET stellt automatisch die richtigen Elemente für das angegebene drahtlose Gerät dar.
SitzungsverwaltungWie zu Beginn dieses Abschnitts erwähnt muss für Outlook Mobile Access die Verwaltung für den Sitzungsstatus fehlerfrei arbeiten. Das HTTP-Protokoll ist statusfrei, da es kein Verfahren für das Kennzeichnen oder Verwalten von Sitzungen zwischen einem Webserver und einem Client bietet. Dieses Problem löst ASP durch die Bereitstellung eines Sitzungsobjekts, mit dem Sie einen Benutzer eindeutig kennzeichnen und Informationen zu dessen Interaktionen mit einem Webserver speichern können.
ASP.NET enthält eine aktualisierte und verbesserte Version des Sitzungsobjekts. Dieses Objekt ermöglicht das Ausführen der folgenden Aufgaben:
Kennzeichnen eines Benutzers durch eine eindeutige Sitzungs-ID
Speichern von Informationen zu der Sitzung eines Benutzers
Verwalten eines Sitzungszyklus über Ereignishandlermethoden
Freigeben von Sitzungsdaten nach einem angegebenen Timeout
Outlook Mobile Access verwendet die prozessinterne Standardbehandlung des Sitzungsstatus von ASP.NET und eine geänderte URL-Methode der Sitzungsverwaltung.
Geänderte URL-Sitzungs-IDEin geänderter URL ist ein URL, der eine Sitzungs-ID enthält. Die Sitzungs-ID hat die Form eines Standard-URLs, bei dem zwischen Anwendung und Webseite eine eindeutige ID eingefügt wurde (z. B. http://server/oma/(a5db038hclb4b1g5ukhrsu55)/oma.aspx). Wenn der Webserver die Anforderung empfängt, analysiert er die Sitzungs-ID im geänderten URL. Während der Laufzeit wird die Sitzungs-ID dann wie eine Sitzungs-ID aus einem Cookie
572
verwendet. Wenn der Client keine Cookies unterstützt, werden die geänderten URLs nicht automatisch verwendet.
Hinweis: Es kann zu Problemen führen, wenn Mobilgeräte geänderte URLs nicht als Sitzungs-ID unterstützen. Bei einigen drahtlosen Browsern treten Probleme mit relativen URLs auf, nachdem sie an einen geänderten URL umgeleitet wurden. Dieses Problem tritt auf, da sie erheblich kürzere URLs unterstützen als Desktopbrowser. Für Anwendungen in einer auf vielen Ebenen verschachtelten Hierarchie sind möglicherweise URLs mit einer größeren Länge erforderlich, als die von einigen Browsern unterstützte Länge.
ASP.NET-GeräteaktualisierungenAktualisierungen von Mobilgeräten werden in .NET Framework-Geräteaktualisierungen eingebunden. Outlook Mobile Access leitet diese Basisklassen ab. Geräteaktualisierungen werden unter Vorbehalt halbjährlich geplant. Änderungen, die für die richtige Darstellung auf einem bestimmten Gerät erforderlich sind, sind in web.config im Stamm des Browserverzeichnisses enthalten. web.config wird bei Geräteaktualisierungen ebenfalls aktualisiert. Alle Anpassungen gehen dabei verloren.
Administratoren und Entwickler sollten die Einstellungen in web.config für ein Gerät, das Microsoft nicht getestet hat, keinesfalls ändern. In vielen Fällen treten keine Interoperabilitätsprobleme zwischen dem Mobilgerät und Exchange auf. Dennoch werden derartige Änderungen nicht unterstützt und können das Debuggen von Outlook Mobile Access verhindern.
Architektur von Outlook Mobile AccessFür den Datenzugriff und die Verarbeitung werden im Outlook Mobile Access-Prozess CDOEX, DAV, Microsoft Outlook Web Access-Vorlagen und Systemverzeichnisdienste verwendet. Zum Abrufen der Konfigurationseinstellungen werden Active Directory, die Registrierung, die IIS-Metabase und die Datei web.config gelesen.
Outlook Mobile Access muss die Benutzeranmeldeinformationen als unformatierten Text über die Standardauthentifizierung erhalten. Outlook Mobile Access unterstützt die integrierte Windows-Authentifizierung nicht, und arbeitet auch nicht mit dieser Authentifizierung, wenn das Gerät oder der Browser diese unterstützen.
ASP.NET arbeitet mit IIS, .NET Framework und den zugrunde liegenden Sicherheitsdiensten des Betriebssystems zusammen, um eine Reihe von Authentifizierungs- und Autorisierungsverfahren bereitzustellen.
573
Outlook Mobile Access und Microsoft Outlook Web Access-VorlagenMit WebDAV (Web Distributed Authoring and Versioning) können Sie direkt auf die meisten in Exchange gespeicherten Daten zugreifen. Einige allgemeine Aufgaben, wie beispielsweise Erstellen oder Annehmen einer Besprechungsanfrage oder das Auflösen eines uneindeutigen E-Mail-Empfängers, sind mit WebDAV schwierig zu implementieren. Normalerweise beantwortet Microsoft Outlook Web Access eine Benutzeranforderung einfach mit einer HTML-Seite. Wenn der Client keine Cookies unterstützt, werden zur Laufzeit nicht automatisch geänderte URLs verwendet.
Das Format der Antwortseite können Sie mit Vorlagen festlegen. Mit Outlook Mobile Access wird die Funktionalität von Microsoft Outlook Web Access erweitert. In Outlook Mobile Access steuern Sie die von den Microsoft Outlook Web Access-Funktionen zurückgelieferten Informationen und deren Format mit benutzerdefinierten Vorlagen. Mit diesen Vorlagen geben Sie Daten in einem Format zurück, das dem einer WebDAV-Antwort ähnelt. Dadurch wird das von Funktionen zurückgegebene Datenformat vereinheitlicht, die für den Datenabruf Microsoft Outlook Web Access bzw. WebDAV verwenden.
WebDAV ist die Grundlage der meisten Vorgänge des Exchange-Datenanbieters von Outlook Mobile Access. Mit dem für einen allgemeinen Datenzugriff entworfenen WebDAV-Protokoll wird HTTP auf HTTP 1.1 erweitert. Dadurch können Sie Daten auf dem Server speichern und mit einem HTTP-Client darauf zugreifen. Es gibt folgende grundlegende Vorgänge:
Ordner wechseln
Ordnerelemente auflisten
Ordner nach Elementen durchsuchen
Elementinformationen abrufen
Attribute von Nachrichten, Kontakten und Aufgaben ändern
Verfasste Nachrichten senden
Die Klassen des Exchange-Datenanbieters bieten eine Schnittstelle zum Exchange-Server für die Funktionen, die nicht von Microsoft Outlook Web Access bereitgestellt werden.
Outlook Mobile Access-DatenquellenOutlook Mobile Access ruft Konfigurations- und andere Daten aus verschiedenen Quellen ab, z. B. Active Directory, IIS-Metabase, Windows-Registrierung und Web.config. Um Daten für einen Benutzer mit WebDAV und Microsoft Outlook Web Access-Vorlagen abzurufen, muss Outlook Mobile Access die WebDAV/OWA-URL wie folgt aufbauen. http://<Servername>/<Name des virtuellen Verzeichnisses>/<Postfach>. Dabei wird der Wert für den <Servernamen> aus dem Benutzerobjekt des angemeldeten Benutzers abgerufen. In gesamtstrukturübergreifenden Topologien wird diese Information aus dem deaktivierten
574
Benutzerkonto der Ressourcengesamtstruktur abgerufen. Der <Name des virtuellen Verzeichnisses> wird aus dem Werteintrag ExchangeVDir in der Registrierung abgerufen.
Das Feststellen des richtigen <Postfachs> ist jedoch schwieriger. Der Name des Postfachs eines Benutzers kann nur über die SMTP-Adresse für das Postfach des Benutzers festgestellt werden. Sie können diesen Wert im Benutzerobjekt finden. Dabei gibt es jedoch ein Problem. Das Attribut enthält für den Benutzer möglicherweise mehrere SMTP-Adressen.
Die richtige SMTP-Adresse wird anhand der SMTP-Domäne des fraglichen Postfachs festgelegt. Die SMTP-Domäne für Microsoft Outlook Web Access, Outlook Mobile Access und Exchange ActiveSync wird mit dem Exchange-System-Manager über ein virtuelles Verzeichnis konfiguriert. Dadurch wird das Hosting erleichtert, da dieselben Front-End-Server mehrere virtuelle Outlook Mobile Access-Verzeichnisse haben können und jedes virtuelle Verzeichnis eine eindeutige SMTP-Domäne darstellt. Diese Einstellung wird im Verzeichnis mit einer SMTP-Domäne pro virtuellem Verzeichnis pro Exchange-Server gespeichert.
Wie Exchange ActiveSync und Microsoft Outlook Web Access verfügt auch Outlook Mobile Access nicht über einen Lesezugriff auf dieses Attribut. Die Zugriffsrechte sind sehr eingeschränkt, da dies eine Administratoreinstellung ist. Der DS2MB-Prozess verfügt über einen Lesezugriff. Die Postfachauflösung wird folgendermaßen durchgeführt:
1. Der Exchange-System-Manager schreibt für ein bestimmtes virtuelles Verzeichnis auf einem bestimmten Server einen SMTP-Domänenwert ins Active Directory.
2. Auf diesem Server nimmt DS2MB diese Einstellung auf und repliziert sie in die IIS-Metabase des Computers.
3. Outlook Mobile Access liest die SMTP-Domäne für das virtuelle Verzeichnis, in dem diese ausgeführt werden.
4. Outlook Mobile Access sucht die SMTP-Adressen im Active Directory-Benutzerobjekt (in gesamtstrukturübergreifenden Topologien wird diese Information aus dem deaktivierten Benutzerkonto der Exchange-Ressourcengesamtstruktur gelesen).
5. Outlook Mobile Access wählt die SMTP-Adresse anhand der SMTP-Domäne in der Liste aus.
6. Outlook Mobile Access extrahiert aus der SMTP-Adresse im Format <Postfachname>@<SMTP-Domäne> den <Postfachnamen>.
Die Werte <Servername>, <Name des virtuellen Verzeichnisses> und <Postfach> werden anschließend miteinander verknüpft, um den DAV/OWA-URL zu erstellen, der für den Back-End-Server erforderlich ist.
575
Verzeichniseinstellungen für Outlook Mobile AccessDie Konfigurationseinstellungen aus dem Active Directory werden von Outlook Mobile Access beim Erstellen einer neuen Sitzung gelesen (und zwar ausschließlich beim Erstellen einer neuen Sitzung). In den folgenden zwei Tabellen werden die für die Gesamtstruktur gültigen sowie die benutzerdefinierten Konfigurationseinstellungen für Outlook Mobile Access in Active Directory dargestellt.
Für die Gesamtstruktur gültige Verzeichniseinstellungen für Outlook Mobile Access
Verzeichniseinstellung Beschreibung
Outlook Mobile Access Stammknoten von Outlook Mobile Access unter den Exchange-Active Directory-Einstellungen. Enthält globale Attribute für Outlook Mobile Access sowie Container für weitere Outlook Mobile Access-Einstellungen.
msExchOmaAdminWirelessEnable Verwaltungssteuerung für verfügbare Mobildienste:
Bit 0:OMA Push
Bit 1:OMA Browse
Bit 2:OMA Sync
Bit 30: Browse-with-untested-devices
Bit 31: Push-via-user-specified-SMTP-address
0 = Aktiviert. 1 = Deaktiviert.
Der durch das Exchange Setup-Programm eingestellte Standardwert ist deaktiviert.
msExchOmaExtendedProperties Reserviert für zukünftige Funktions-Erweiterungen (ohne Änderungen am Active Directory-Schema)
576
Benutzerdefinierte Verzeichniseinstellungen für Outlook Mobile Access
Verzeichniseinstellung Beschreibung
msExchOmaAdminExtendedSettings Raum für verwaltungsgesteuerte Einstellungen für einen Benutzer. Beispiel: Zulassen/Sperren des Zugriffs auf Funktionen wie Kalender oder Kontakte in Outlook Mobile Access.
msExchOmaExtendedProperties Reserviert für zukünftige Funktions-Erweiterungen (ohne Änderungen am Active Directory-Schema)
Die Attribute des Benutzerobjekts erben drei ACLs (Access Control Lists) aus dem Benutzerobjektcontainer: Domänen-Admins, Lokales System auf Domänencontrollern und Konten-Operatoren. Jedes Sicherheitsprinzipal verfügt über vollständige Lese-/Schreibberechtigungen für die Benutzereinstellungen. Darüber hinaus sind die zwei in Tabelle 9.8 dargestellten Attribute Teil der Gruppe öffentlicher Eigenschaften, die authentifizierten Benutzern Lesezugriff erteilen. Die Attribute im Outlook Mobile Access-Konfigurationscontainer werden vom Knoten der Organisation geerbt, anschließend wird der Lesezugriff für authentifizierte Benutzer hinzugefügt.
Da diese Verzeichniseinstellungen nur beim Erstellen einer neuen Sitzung gelesen werden, haben Änderungen dieser Einstellungen keine Auswirkung auf aktuell bestehende Sitzungen. Das Deaktivieren eines Benutzers für Outlook Mobile Access unterbricht beispielsweise nicht sofort eine bestehende Sitzung dieses Benutzers. Ein Benutzer bemerkt die Deaktivierung des Zugriffs erst, wenn er das nächste Mal versucht, eine Outlook Mobile Access-Sitzung einzuleiten.
Outlook Mobile Access und DS2MBDS2MB hat Auswirkungen auf alle webbasierenden Anwendungen in Exchange 2003. Dazu gehören auch Outlook Web Access, Outlook Mobile Access und Exchange ActiveSync. Einige Konfigurationswerte von Outlook Mobile Access sind verzeichnisabhängig. Das Löschen des virtuellen Verzeichnisses von Outlook Mobile Access ist jedoch ein übliches Verfahren zur Problembehandlung beim Replizieren von Verzeichnissen zur Metabase.
IIS erhält die richtige Konfiguration von der lokalen Metabase. Zu IIS gehörige Informationen werden in Active Directory gespeichert und durch das DS2MB-Verfahren in einer Richtung aus dem Verzeichnis zur Metabase repliziert. DS2MB wird als Teil der Systemaufsicht auf jedem Computer mit Exchange 2000 oder später ausgeführt. DS2MB erhält Benachrichtigungen zu Änderungen im Verzeichnis und weist die Aufgaben DS2MB zu.
577
Wenn Sie feststellen, dass die lokale Metabase nicht mit dem Verzeichnis synchron ist, können Sie den unten angegebenen Schlüssel der Metabase so manipulieren, dass eine manuelle Aktualisierung des Verzeichnisses ausgeführt wird.LM\DS2MB\HighWaterMarks\{056BE186-E73F-4EBD-A92D-2D985BC97C63}\61472
Die Änderung der Daten für diesen Wert auf 0 (null) oder das Löschen des Schlüssels mit einem anschließenden Neustart der Systemaufsicht führt zu einer vollständigen Replikation der Verzeichnisinformationen auf die Metabase. Beim Starten der Systemaufsicht wird der Schlüssel der Metabase mit dem Standardwert hinzugefügt. Die Metabase kann mithilfe verschiedener Tools bearbeitet werden. Wenn Exchange 2003 unter Windows Server 2003 ausgeführt wird, kann das integrierte Tool IISCNFG verwendet werden. Wenn Exchange unter Windows 2000 ausgeführt wird, kann MetaEdit 2.2 oder später verwendet werden.
Outlook Mobile Access und die Windows-RegistrierungVon Outlook Mobile Access werden fünf Registrierungsschlüssel verwendet. Ein Schlüssel wird für Leistungsindikatoren verwendet, die anderen vier zur Konfiguration. Einer dieser Schlüssel wird gemeinsam mit Exchange ActiveSync verwendet, die drei anderen mit Outlook Web Access. Diese Schlüssel befinden sich unter HKLM\SYSTEM\CurrentControlSet\Services. In der folgenden Tabelle werden die Registrierungsschlüssel beschrieben.
Wichtige Registrierungsschlüssel von Outlook Mobile Access
Schlüssel Wert Beschreibung
MasSync\Parameters\ExchangeVDir
/Exchange oder andere Zeichenfolge, die mit / beginnt
Gibt an, welches virtuelle Verzeichnis von ActiveSync und Outlook Mobile Access für den Zugriff auf Outlook Web Access-Vorlagen und WebDAV auf den Exchange-Back-End-Servern mit Benutzer-Postfächern verwendet werden muss. Wenn dieser Schlüssel nicht vorhanden oder gleich null ist, wird der Standardwert /Exchange verwendet. Andernfalls enthält der Schlüssel den Namen des virtuellen Verzeichnisses mit einem Schrägstrich (/).
578
Schlüssel Wert Beschreibung
MSExchangeWEB\OWA\UseRegionalCharset
1 oder beliebig Wenn dieser Schlüssel auf "1" eingestellt ist, werden von Outlook Web Access und Outlook Mobile Access beim Senden von E-Mail regionale Zeichensätze verwendet. Wenn der Schlüssel nicht vorhanden ist oder auf einen anderen Wert eingestellt ist, wird von Outlook Web Access und Outlook Mobile Access zum Senden von E-Mail UTF-8 verwendet. Der verwendete regionale Zeichensatz wird durch die vom Benutzer eingestellte Clientsprache bestimmt.
MSExchangeWEB\OWA\UseISO8859_15
1 oder beliebig Wenn der Schlüssel auf "1" eingestellt ist, wird der Zeichensatz ISO-8859-15 immer anstelle von ISO-8859-1 verwendet.
MSExchangeWEB\OWA\UseGB18030
1 oder beliebig Wenn der Schlüssel auf "1" eingestellt ist, wird der Zeichensatz GB18030 immer anstelle von GB2312 verwendet.
MSExchangeOMA\Performance
N/A Wird zum Veröffentlichen von Leistungsobjekten und -indikatoren für Outlook Mobile Access verwendet.
Outlook Mobile Access und Web.ConfigIm Abschnitt <browserCaps> der Datei Web.config befinden sich die Outlook Mobile Access-Einstellungen verschiedener Mobilbrowser und verschiedener Versionen von Internet Explorer. Passen Sie diese Einstellungen nicht an, da sie in den Geräteaktualisierungen für .NET Framework enthalten sind.
579
Einige Einstellungen können vom Benutzer konfiguriert werden. Diese Einstellungen werden in der folgenden Tabelle beschrieben.
Einstellungen in „Web.config“ für Outlook Mobile Access
Abschnitt Einstellung Beschreibung
<appSettings> <add key="CredentialsTimeout" value="60"></add>
Legt die Anzahl von Minuten fest, in denen Kerberos-Tickets für DAV und Outlook Web Access-Vorlagen von Outlook Mobile Access zwischengespeichert werden.
<add key="DefaultConnectionLimit" value="500"></add>
Legt die maximale Anzahl gleichzeitiger Verbindungen fest, die von Outlook Mobile Access zu einem einzelnen Back-End-Server geöffnet werden können.
<add key="MaxServicePointIdleTime" value="60000"></add>
Legt die maximale Dauer in Millisekunden fest, die Outlook Mobile Access auf eine Antwort des Back-End-Servers wartet.
<add key="UnsupportedMessage" value="http://<server>/OMADevices"></add>
Wird diese Nachricht festgelegt, wird zusätzlicher Text in nicht unterstützten Warnungen- und Fehlerseiten angezeigt. In der Standardeinstellung ist dieser Schlüssel gleich null.
<system.web> <sessionState mode="InProc" cookieless="true" timeout="20" />
Legt die in Outlook Mobile Access verwendete Konfiguration des Sitzungsstatus fest.
Der Wert des Timeouts legt fest, wie viele Minuten der Sitzungsstatus nach der letzten Anfrage der Sitzung gespeichert bleibt.
580
<mobileControls SessionStateHistorySize="8">
Legt fest, wie viele vorhergehende Seiten der Sitzungsstatus verfolgen muss (dies ermöglicht dem Benutzer die Einstellung der Schaltfläche „Zurück”und das Funktionieren der Verknüpfungen auf den Seiten).
<globalization requestEncoding="utf-8" responseEncoding="utf-8" />
Legt den Standardzeichensatz fest, der in Outlook Mobile Access verwendet wird, um HTTP-Antworten zu senden oder um eingehende Anfragen zu interpretieren, die keinen bestimmten Zeichensatz festlegen.
<browserCAPs> supportsBackNavWithExpiresHeader
Legt fest, ob durch Outlook Mobile Access die Kopfzeilen für alle Anfragen mit dem Ablaufwert 10/08/2000 10:28 zurückgesendet werden. Das Zurücksenden eines vergangenen Zeitpunkts bewirkt das Ungültigwerden des Inhalts.
preferredResponseCharset Legt den Wert des Response.Charset für alle Anfragen fest.
preferredResponseCodePage
Legt Response.ContentEncoding auf die angegebene ganze Zahl fest. Wird gleichzeitig als Response.Charset festgelegt.
581
preferredRequestCodePage Legt Request.ContentEncoding auf die angegebene ganze Zahl fest. Sollte gleichzeitig als Response.Charset festgelegt werden.
supportsOpenwaveUniversalLocalSrc
Bedeutet, dass durch Outlook Mobile Access Zugriffsschlüssel vor Verknüpfungen festgelegt werden.
defaultTextboxMaxlength Legt die erlaubte MaxLength von Zeichenketten in TextBox-Steuerelementen fest. Der P800 z. B. würde diese ohne diese Konfiguration in der Standardeinstellung auf 64 festlegen.
Outlook Mobile Access-ClientanforderungenWenn ein Outlook Mobile Access-Client eine Webanfrage veröffentlicht, findet der folgende Ablauf von Authentifizierungs- und Autorisierungsereignissen statt:
1. Das Netzwerk empfängt die HTTP(S)-Webanfrage. SSL kann dazu verwendet werden, die Serveridentität zu überprüfen. SSL stellt außerdem einen Sicherheitskanal zur Verfügung, mit zwischen Client und Server übermittelte vertrauliche Daten geschützt werden können.
2. IIS authentifiziert den Anrufer durch Standardauthentifizierung. IIS erstellt für den authentifizierten Benutzer ein Windows-Zugriffstoken.
3. IIS autorisiert den Anrufer zum Zugriff auf die angeforderte Ressource. Um Zugriff zu ermöglichen, werden Berechtigungen des NTFS-Dateisystems verwendet, die durch Zugriffssteuerungslisten (ACLs) im Anhang der angeforderten Ressource festgelegt sind.
4. IIS sendet das Windows Server-Zugriffstoken des authentifizierten Anrufers an ASP.NET.
582
Outlook Mobile Access-SicherheitsarchitekturWelche Sicherheitsarchitektur Outlook Mobile Access zugrunde liegt, hängt davon ab, ob Exchange 2003 auf Windows Server 2003 oder Windows 2000 Server ausgeführt wird. Unter Windows Server 2003 wird Outlook Mobile Access als eigenständiger Prozess in einem dafür vorgesehenen Programmpool ausgeführt: ExchangeMobileBrowseApplicationPool. Bei einem ASP.NET-Workervorgang wird Outlook Mobile Access als Netzwerkdienstkonto ausgeführt (W3WP.EXE). Auf einem Computer mit Windows 2000 wird Outlook Mobile Access zusammen mit anderen ASP.NET-Anwendungen dieses Computers ausgeführt. Bei einem ASP.NET-Workervorgang wird Outlook Mobile Access als ASPNET-Konto ausgeführt (ASPNET_WP.EXE).
Die ASP.NET-ISAPI-Erweiterung ASPNET_ISAPI.DLL wird unter Inetinfo.exe ausgeführt. Dies wird durch den Metabase-Eintrag InProcessIsapiApps gesteuert. Durch ASPNET_ISAPI.DLL werden Routinganforderungen an den ASP.NET-Workervorgang gesendet. ASP.NET-Programme werden dann im ASP.NET-Workervorgang ausgeführt, in dem Trennungsgrenzen durch Programmdomänen bereitgestellt werden. Mit IIS 6.0 werden ASP.NET-Programme durch die Konfiguration von Programmpools isoliert, bei denen jedem Pool eine eigene Anwendungsinstanz zugeordnet ist (Outlook Mobile Access wird in den ExchangeMobileBrowseApplication-Pool verschoben).
Architektur des Exchange-InformationsspeicherdienstsDer Microsoft Exchange-Informationsspeicherdienst dient als hauptsächliches Datenspeicherungsrepository für Microsoft Exchange Server 2003 und enthält Daten für Postfachspeicher und für Informationsspeicher für Öffentliche Ordner. Im Microsoft Exchange-Informationsspeicherdienst wird ein Datenbankmodul mit der Bezeichnung ESE (Extensible Storage Engine) verwendet. Es handelt sich dabei um eine transaktionsbasierte Datenbanktechnologie.
In diesem Abschnitt wird die Funktion des Microsoft Exchange-Informationsspeicherdiensts im Exchange Server 2003-Messagingsystem erläutert. Mit dem Microsoft Exchange-Informationsspeicherdienst wird, wie der Name bereits andeutet, der Exchange-Informationsspeicher implementiert. Der Exchange-Informationsspeicher dient als Host für Postfach- und Öffentliche Ordner. Zu den Funktionen des Exchange-Informationsspeichers zählt auch die Replikation von Öffentlichen Ordnern. Dieses Thema wird aufgrund seiner Komplexität in einem gesonderten Abschnitt behandelt.
Folgende Themen werden in diesem Abschnitt behandelt:
Exchange-Speicherarchitektur In Exchange Server 2003 wird eine transaktionsbasierte Speicherarchitektur verwendet, die eine Datenbankdatei, eine Datei
583
mit systemeigenem Inhalt, Transaktionsprotokolle und andere Dateien, z. B. Prüfpunktdateien und reservierte Protokolle, enthält. Kenntnisse über die Verwendung dieser Dateien zum Speichern von Messagingdaten in Exchange Server 2003 sind von großer Bedeutung.
Architektur von Extensible Storage Engine ESE (Extensible Storage Engine) ist eine zentrale Komponente des Exchange-Informationsspeichers. Die Architektur des Exchange-Informationsspeichers kann nur mit guten Kenntnissen der Extensible Storage Engine verstanden werden.
Funktionen des Exchange-Informationsspeichers In der Client-Server-Architektur von Exchange Server 2003 kann ausschließlich über den Microsoft Exchange-Informationsspeicherdienst auf die Messagingdatenbanken zugegriffen werden. Der exklusive Datenbankzugriff bringt eine Reihe von Verantwortlichkeiten mit sich, mit denen Sie zum Verständnis der Funktionsweise des Microsoft Exchange-Informationsspeicherdiensts vertraut sein sollten.
Replikation von Öffentlichen Ordnern Durch die Replikation Öffentlicher Ordner können Sie mehrere Instanzen des gleichen Öffentlichen Ordners auf verschiedenen Exchange-Servern verwalten und die Instanzen synchronisieren. Diese Funktion ermöglicht Benutzern in einer verteilten Exchange-Organisation Zugriff auf eine lokale Kopie eines Öffentlichen Ordners. Mit replizierten Öffentlichen Ordnern kann darüber hinaus die Fehlertoleranz für Arbeitsgruppenlösungen erhöht werden. Dazu werden Kenntnisse über die Funktionsweise einer Replikation der Daten in Öffentlichen Ordnern innerhalb einer Exchange-Organisation durch den Exchange-Informationsspeicher benötigt.
Weitere Informationen zur Verwaltung des Exchange-Informationsspeichers und zur Sicherung und Notfallwiederherstellung finden Sie unter Exchange Server 2003 Administration Guide.
Exchange-SpeicherarchitekturAuf Exchange-Servern werden Daten in zwei Dateien gespeichert: in einer EDB-Datei und einer STM-Datei. Die EDB-Datei und die STM-Datei ergeben zusammen ein Exchange-Informationsspeicherrepository. Im Standardpostfachspeicher auf einem Exchange-Server werden beispielsweise die Dateien Priv1.edb und Priv1.stm verwendet. Im Standardinformationsspeicher für Öffentliche Ordner werden die Dateien Pub1.edb und Pub1.stm verwendet. Die EDB-Datei enthält zahlreiche Tabellen mit Metadaten für alle E-Mail-Nachrichten und andere Objekte im Exchange-Informationsspeicher, sowie Inhalte von MAPI-Nachrichten. Die EDB-Datei ist eine ESE-Datenbank. Da sie vor allem zum Speichern von MAPI-Nachrichten und -Anlagen verwendet wird, wird sie auch als MAPI-Datenbank bezeichnet. In der STM-Datei wird dagegen der systemeigene Internetinhalt gespeichert. Da der Internetinhalt in einem systemeigenen Format geschrieben ist, müssen Nachrichten und
584
andere Objekte nicht in das Exchange-Format umgewandelt werden, wie das in Exchange 5.5 und früheren Versionen der Fall war. Die STM-Datei ist auch eine ESE-Datenbank und wird als Streamingdatenbank bezeichnet. Die EDB- und die STM-Datei werden als Dateienpaar verwendet. Die Datenbanksignatur (eine 32-Bit-Zufallszahl in Kombination mit dem Erstellungszeitpunkt der Datenbank) wird als Kopfzeile in beiden Dateien gespeichert. Das interne Schema für die STM-Seiten wird in der EDB-Datei gespeichert.
Hinweis: Sie können die EDB- und STM-Datenbanken umbenennen und sie in andere Verzeichnisse im Exchange-System-Manager verschieben. Da die EDB- und die STM-Datei zusammen ein vollständiges Exchange-Informationsspeicherrepository bilden, sollten diese Dateien zusammen gespeichert und mit einem gemeinsamen Namen mit unterschiedlichen Erweiterungen (d. h. EDB und STM) versehen werden.
In Exchange Server 2003 werden Änderungen in Speichergruppen mit Transaktionen gesteuert. Diese Transaktionen werden in einem Transaktionsprotokoll aufgezeichnet. Dies entspricht in etwa der Weise, wie Transaktionen in herkömmlichen Datenbanken gespeichert werden. Änderungen werden in Abhängigkeit vom Erfolg der Transaktion ausgeführt oder zurückgesetzt. Bei Fehlfunktionen werden Transaktionsprotokolle (zusammen mit den Datenbankdateien und in einigen Fällen mit der Prüfpunktdatei) zum Wiederherstellen einer Datenbank verwendet. Transaktionen werden mit dem Microsoft Exchange-Informationsspeicherdienst (Store.exe) verwaltet. Alle nicht ausgeführten Einträge im Transaktionsprotokoll gelten als Teil einer aktuellen Exchange-Datenbank, wie in der folgenden Abbildung dargestellt.
Aktuelle Exchange Server 2003-Datenbank
In Exchange Server 2003 sind die folgenden beiden Datenbanktypen verfügbar:
Datenbanken des Privaten Informationsspeichers In diesen Datenbanken werden Postfächer und Nachrichtenwarteschlangen für MAPI-basierte Messagingconnectors gespeichert.
Datenbanken des Öffentlichen Informationsspeichers In diesen Datenbanken werden Hierarchien und Inhalte von Öffentlichen Ordnern gespeichert.
In der folgenden Abbildung ist die interne Architektur des Exchange-Informationsspeichers dargestellt. Mit dem Microsoft Exchange-Informationsspeicherdienst (Store.exe) wird über
585
ESE (Extensible Storage Engine) auf die Datenbankdateien im Dateisystem zugegriffen und über verschiedene Schnittstellen, z. B. MAPIsvr, ExPOP, ExIMAP, ExSMTP und ExOLEDB, der Zugriff auf die Daten ermöglicht. In Clientanwendungen und Anwendungsprogrammierschnittstellen (API), z. B. CDOEX (Collaboration Data Objects für Exchange), können diese Schnittstellen verwendet oder eine Verbindung mit dem Messagingdatenbankmodul (MDB) hergestellt werden.
Exchange-Speicherarchitektur
SpeichergruppenJede Speichergruppe setzt sich aus mehreren Protokoll- und zusätzlichen Dateien (interne temporäre Datenbanken, Prüfpunktdatei und reservierte Protokolle) für alle Datenbanken (EDB-Dateien, STM-Dateien) in der Speichergruppe zusammen. In Exchange Server 2003 werden mehrere Speichergruppen und mehrere Datenbanken in jeder Speichergruppe unterstützt. In Exchange Server 2003 können auf einem Server bis zu vier Speichergruppen und in einer Speichergruppe bis zu fünf Datenbanken unterstützt werden. Aufgrund der Unterstützung mehrerer Datenbanken können Sie verschiedene Postfächer und Öffentliche Ordner auf mehrere kleinere Datenbanken verteilen und dadurch die Datenbankverwaltung vereinfachen. In Exchange 2000 Server und Exchange Server 2003 können bis zu 20 Datenbanken für Postfächer und Öffentliche Ordner auf einem Server verwendet werden.
SpeichergruppenarchitekturWie in der folgenden Abbildung veranschaulicht, werden alle Speichergruppen über den gleichen Store.exe-Prozess verwaltet. Jede Speichergruppe wird durch eine ESE-Instanz dargestellt.
586
Speichergruppenarchitektur
In jeder Speichergruppe stellt jedes EDB- und STM-Datenbankpaar einen Postfachspeicher oder einen Speicher für Öffentliche Ordner dar. Wie in Abbildung 10.3 gezeigt, wird in allen Postfachspeichern und Informationsspeichern für Öffentliche Ordner in einer bestimmten Speichergruppe ein gemeinsamer Satz von Protokoll- und anderen Systemdateien verwendet. Mit diesen Dateien wird die transaktionsorientierte Verarbeitung ermöglicht.
Die Protokoll- und anderen Systemdateien in jeder Speichergruppe haben folgende Funktionen:
<Protokollpräfix>xxx.chk Dies ist die Prüfpunktdatei (z. B. E00.chk), mit der festgelegt wird, welche Transaktionen verarbeitet werden müssen und damit von den Transaktionsprotokolldateien in die Datenbanken verschoben werden. Prüfpunktdateien werden aktualisiert, wenn durch ESE eine bestimmte Transaktion in eine Datenbankdatei geschrieben wird. Durch diese Aktualisierung verweist die Prüfpunktdatei immer auf die letzte Transaktion, die erfolgreich in die Datenbank übertragen wurde. Dadurch wird ein schnelles Wiederherstellungsverfahren bereitgestellt. Prüfpunktdateien sind jedoch für das Ausführen von Transaktionen in Datenbanken nicht erforderlich. Mit ESE können Transaktionsprotokolldateien direkt verarbeitet werden. Darüber hinaus kann festgestellt werden, welche Transaktionen noch nicht übertragen wurden. Dieses Verfahren nimmt erheblich mehr Zeit in Anspruch als die Verwendung von Prüfpunkten.
Hinweis: Durch Extensible Storage Engine wird gewährleistet, dass Transaktionen nicht mehrfach in eine Datenbank geschrieben werden.
Exx.log Hierbei handelt es sich um die aktuelle Transaktionsprotokolldatei für die Speichergruppe. Durch Transaktionsprotokolldateien kann die Datenspeicherung über ESE effizient und mit einer hohen Geschwindigkeit durchgeführt werden. Mit ESE werden neue Transaktionen, z. B. die Übermittlung einer Nachricht, gleichzeitig in einem Cache im Arbeitsspeicher und im Transaktionsprotokoll gespeichert. Die Daten werden sequentiell geschrieben. Neue Daten werden ohne komplexe Datenbankoperationen zu den vorhandenen Daten hinzugefügt. Die Transaktionen werden zu einem späteren
587
Zeitpunkt gruppenweise vom Cache im Arbeitsspeicher in die Datenbanken verschoben, in denen sie dann aktualisiert werden.
In der Standardeinstellung wird für die Standardspeichergruppe mit der Bezeichnung Erste Speichergruppe das Präfix E00 verwendet. Die entsprechende Transaktionsprotokolldatei trägt den Namen E00.log. Die Datei E00.log wird für alle Postfachspeicher und Informationsspeicher für Öffentliche Ordner in der Speichergruppe verwendet. Beim Erstellen von weiteren Speichergruppen wird die Nummerierung der Präfixe mit E01, E02 und E03 fortgesetzt.
<Protokollpräfix>XXXXX.log Dies sind Transaktionsprotokolldateien, in denen kein Speicherplatz für weitere Daten vorhanden ist. In der Standardeinstellung beträgt die Größe von Transaktionsprotokolldateien immer genau 5.242.880 Byte (5 Megabyte). Obwohl es theoretisch möglich ist, die Größe der Protokolldatei zu ändern, wird davon abgeraten. Wenn ein Protokoll die maximale Größe erreicht, wird es umbenannt, damit eine neue leere Transaktionsprotokolldatei erstellt werden kann. Umbenannte Transaktionsprotokolldateien werden als vorherige Protokolldateien bezeichnet. Das Namensformat von vorherigen Protokolldateien lautet <Protokollpräfix>XXXXX.log (z. B. E00XXXXX.log), wobei XXXXX für eine 5-stellige hexadezimale Zahl von 00000 bis FFFFF steht. Die vorherigen Protokolldateien befinden sich in den gleichen Verzeichnissen wie die aktuelle Transaktionsprotokolldatei.
Res1.log und Res2.log Hierbei handelt es sich um reservierte Transaktionsprotokolldateien für eine Speichergruppe. Reservierte Protokolldateien sind ein Notfallrepository für Transaktionen. Sie verfügen über genügend Festplattenspeicherplatz zum Schreiben einer Transaktion vom Arbeitsspeicher auf Festplatte, selbst wenn auf der Festplatte eines Servers keine neuen Transaktionen in einer Protokolldatei mehr gespeichert werden können. Die reservierten Protokolldateien befinden sich im Transaktionsprotokollverzeichnis. Sie werden bei der Initialisierung der Datenbanken automatisch erstellt. Sie können zu keinem späteren Zeitpunkt erstellt werden.
Reservierte Transaktionsprotokolldateien werden mit ESE ausschließlich zum Abschließen eines aktuellen Transaktionsvorgangs verwendet. Anschließend wird eine Fehlerbenachrichtigung an Store.exe gesendet, um die Bereitstellung des Exchange-Informationsspeichers sicher aufzuheben. Das Anwendungsereignisprotokoll enthält einen entsprechenden Eintrag. In diesem Fall sollten Sie vor der erneuten Bereitstellung der Datenbank zusätzlichen freien Festplattenspeicherplatz hinzufügen (z. B. durch Einbauen einer neuen Festplatte).
Tmp.edb Dies ist ein temporärer Arbeitsbereich zum Verarbeiten von Transaktionen. Tmp.edb enthält temporäre Informationen, die beim Aufheben der Bereitstellung aller Informationsspeicher in der Speichergruppe oder beim Beenden des Exchange-Informationsspeicherdiensts gelöscht werden.
588
Hinweis: Tmp.edb ist in Onlinesicherungen nicht vorhanden.
<Dateiname>.edb Hierbei handelt es sich um Datenbankdateien im Rich-Text-Format für einzelne Private oder Öffentliche Informationsspeicher. Die Datenbankdatei im Rich-Text-Format für den Privaten Standardinformationsspeicher trägt den Namen Priv1.edb. Der Dateiname des Öffentlichen Standardinformationsspeichers lautet Pub1.edb.
<Dateiname>.stm Dies sind die Streaming-Internetinhaltdateien für einzelne Datenbanken. Die Streamingdatenbankdatei für den Privaten Standardinformationsspeicher trägt den Namen Priv1.stm. Der Dateiname des Öffentlichen Standardinformationsspeichers lautet Pub1.stm.
Speichergruppenattribute in Active DirectorySie können den Pfad für die Transaktionsprotokolldatei einer Speichergruppe sowie den Namen der Protokolldatei im Exchange-System-Manager festlegen. Klicken Sie mit der rechten Maustaste auf die gewünschte Speichergruppe, wählen Sie Eigenschaften aus, und überprüfen Sie auf der Registerkarte Allgemein die Informationen in den Feldern Pfad des Transaktionsprotokolls und Präfix für Protokolldatei. Über die Schaltfläche Durchsuchen können Sie das Transaktionsprotokoll und die Systemdateien jeweils in einen neuen Speicherort verschieben, z. B. auf ein gesondertes physisches Laufwerk.
Die Konfigurationseinstellungen für eine Speichergruppe sind in Active Directory gespeichert. Wenn Sie das Verzeichnisobjekt für eine Speichergruppe mit der ADSI-Bearbeitung suchen möchten, öffnen Sie die Konfigurationsnamenskontakte, erweitern Sie den Knoten Dienste, dann CN=Microsoft Exchange und anschließend das Objekt der Exchange-Organisation, die administrative Gruppe und den Servercontainer. Darunter befindet sich ein Container mit dem Namen CN=InformationStore, der die Speichergruppen enthält, z. B. CN=First Storage Group. Speichergruppenobjekte haben die Objektklasse msExchStorageGroup. Wenn Sie Ressourcen im Exchange-Informationsspeicher über benutzerdefinierte Skripts verwalten möchten, können Sie über ADSI (Active Directory Service Interfaces) auf msExchStorageGroup-Objekte zugreifen.
Im folgenden Codebeispiel wird der Zugriff auf die Standardspeichergruppe auf dem Server SERVER01 in der Exchange-Organisation Contoso dargestellt. Dabei wird der aktuelle Pfad für die Transaktionsprotokolldateien der Speichergruppe angezeigt.strStorageGroupDN = "CN=First Storage Group," _ & "CN=InformationStore," _ & "CN=SERVER01,CN=Servers," _ & "CN=First Administrative Group," _ & "CN=Administrative Groups," _ & "CN=Contoso,CN=Microsoft Exchange," _ & "CN=Services,CN=Configuration," _ & "DC=Contoso,DC=com"Set oStorageGroup = GetObject("LDAP://" & strStorageGroupDN)MsgBox oStorageGroup.Get("msExchESEParamLogFilePath")
589
Im Folgenden sind wichtige Exchange-Attribute von msExchStorageGroup-Objekten aufgeführt, die in benutzerdefinierten ADSI-Skripts verwendet werden können:
msExchESEParamCircularLog Mit diesem booleschen Kennzeichen wird festgelegt, ob die Umlaufprotokollierung aktiviert oder deaktiviert ist. Der Wert 0 legt fest, dass die Umlaufprotokollierung deaktiviert ist. Der Wert 1 legt fest, dass die Umlaufprotokollierung aktiviert ist.
Durch die Umlaufprotokollierung werden Transaktionen in ESE entfernt, wenn die übergebenen Änderungen in die Datenbankdatei auf Festplatte übertragen wurden. In der Prüfpunktdatei wird angegeben, welche Protokolldateien und Transaktionseinträge erfolgreich an die Datenbank übergeben wurden. Alle vorhandenen vorherigen Protokolle werden gelöscht. Die Transaktionen in der aktuellen Transaktionsprotokolldatei werden als veraltet gekennzeichnet. Vor der Erstellung einer neuen Protokolldatei werden die veralteten Einträge im aktuellen Transaktionsprotokoll möglicherweise von neuen Transaktionen überschrieben.
Hinweis: Durch Löschen von Transaktionen wird bei der Umlaufprotokollierung die Belegung von Festplattenspeicher verringert. Die Umlaufprotokollierung ist jedoch nicht kompatibel mit hochentwickelten fehlertoleranten Konfigurationen und mehreren Onlinesicherungsarten, die auf vorhandenen Transaktionsprotokollen beruhen. Wenn die Umlaufprotokollierung aktiviert ist, können nur vollständige Sicherungen durchgeführt werden. Sicherungen, die auf Transaktionsprotokolldateien basieren, z. B. differenzielle oder inkrementelle Sicherungen, können nicht durchgeführt werden. Bei der Wiederherstellung von Daten können Transaktionsprotokolldateien nicht wiedergegeben werden, daher können Daten außerhalb der neuesten Sicherung nicht wiederhergestellt werden. Wenn Transaktionen jedoch nicht automatisch durch die Umlaufprotokollierung gelöscht werden, können Sie möglicherweise Daten außerhalb der neuesten Sicherung durch Wiedergabe der noch auf einer Festplatte vorhandenen Transaktionen wiederherstellen. In Exchange Server 5.5 ist die Umlaufprotokollierung in der Standardeinstellung aktiviert, in Exchange 2000 Server und Exchange Server 2003 ist sie dagegen in der Standardeinstellung deaktiviert.
msExchESEParamEventSource Mit dieser sprachenunabhängigen Prozessbeschreibungszeichenfolge wird auf den Dienstschlüssel des Microsoft Exchange-Informationsspeichers (MsExchangeIS) in der Registrierung unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services verwiesen.
msExchESEParamLogFilePath Mit diesem Attribut wird der Pfad für die Transaktionsprotokolldateien einer Speichergruppe festgelegt, z. B. C:\Programme\Exchsrvr\mdbdata.
590
msExchESEParamLogFileSize Mit diesem Attribut wird die Größe einer Protokolldatei in Kilobyte (KB) angegeben. Der Standardwert ist 5120. Dieser Wert sollte nie geändert werden.
msExchESEParamSystemPath Mit diesem Attribut wird der Pfad für die Prüfpunktdatei angegeben, z. B. C:\Programme\Exchsrvr\mdbdata, sowie der Pfad für eventuell vorhandene temporäre Datenbanken.
msExchESEParamZeroDatabaseDuringBackup Mit diesem booleschen Kennzeichen wird festgelegt, ob gelöschte Datensätze und Langwerte bei Sicherungsvorgängen mit Nullen überschrieben werden. Mit dem Wert 0 wird angegeben, dass die Datensätze nicht überschrieben werden. Durch den Wert 1 wird festgelegt, dass die Datenbanken mit Nullen überschrieben werden.
msExchESEParamEnableOnlineDefrag Mit diesem booleschen Kennzeichen wird festgelegt, ob die Onlinedefragmentierung von Datenbanken mit dem Microsoft Exchange-Informationsspeicherdienst durchgeführt wird. Durch den Wert 0 wird festgelegt, dass keine Onlinedefragmentierung durchgeführt wird. Mit dem Wert 1 wird die Onlinedefragmentierung in zeitlich festgelegten Wartungszyklen durchgeführt.
Hinweis: Durch die Onlinedefragmentierung wird Speicherplatz in den Datenbanken freigegeben, die Größe der Datenbankdateien verringert sich jedoch nicht. Datenbankinkonsistenzen werden bei jedem Start und Herunterfahren des Servers mit einem so genannten Soft Recovery-Vorgang korrigiert.
msExchESEParamEnableIndexChecking Mit diesem booleschen Kennzeichen wird festgelegt, ob die Betriebssystemversion auf Unicode-Indizes überprüft wird. Mit dem Wert 0 wird angegeben, dass die Indexüberprüfung nicht durchgeführt wird. Durch Angabe des Werts 1 wird die Indexüberprüfung durchgeführt. Über diesen Parameter werden Änderungen im Betriebssystem festgestellt, die durch Aktualisieren auf eine neuere Version oder durch Ausführen eines Service Packs vorgenommen wurden. Mit dem Kennzeichen wird überprüft, ob sich die Unicode-Sortierreihenfolge geändert hat. Bei jeder auf diese Weise am Betriebssystem vorgenommenen Änderung wird automatisch eine neue Indizierung ausgeführt.
msExchESEParamBaseName Mit diesem Attribut wird der Basisname für die Protokolldateien in einer Speichergruppe angegeben. Der Basisname E00 beispielsweise führt zu dem Namen E00.log für die Transaktionsprotokolldatei.
msExchESEParamDbExtensionSize Mit diesem Attribut wird die Größe der Datenbankerweiterung in Seiten angegeben. Der Standardwert ist 2 Megabyte (MB).
msExchESEParamPageTempDBMin Mit diesem Attribut wird die Mindestgröße der temporären Datenbank in Seiten festgelegt. Der Standardwert ist 0.
msExchESEParamCheckpointDepthMax Mit diesem Attribut wird die bevorzugte (nicht hartcodierte) maximale Prüfpunkttiefe in Byte angegeben.
591
Speicherplatzmindestanforderungen für SpeichergruppenJede Speichergruppe belegt ungefähr 50 MB des verfügbaren Speicherplatzes auf der Festplatte. Die oben aufgeführten für die Speichergruppe erforderlichen Dateien belegen mindestens 11 MB des Speicherplatzes auf der Festplatte. Der Mindestspeicherplatz auf der Festplatte für Private und Öffentliche Informationsspeicher beträgt 5 MB bzw. 8 MB. Obwohl der belegte Gesamtspeicherplatz auf der Festplatte ca. 24 MB beträgt, wird zusätzlicher Speicherplatz für die tatsächliche Erstellung der Speichergruppe sowie für Lese- und Schreibvorgänge benötigt.
Beachten Sie beim Verwenden von Speichergruppen die folgenden Punkte:
Auf einem Server, auf dem Exchange Server 2003 ausgeführt wird, können bis zu fünf Speichergruppen vorliegen. Da eine Speichergruppe für Wiederherstellungsvorgänge in der Datenbank reserviert ist, können nur vier Speichergruppen für Datenbanken verwendet werden, auf die Clients zugreifen können. Bei der Erstellung von mehr als vier Speichergruppen wird eine Fehlermeldung ausgegeben.
Sie können in einer Speichergruppe maximal fünf Datenbanken erstellen. Beim Erstellen weiterer Datenbanken wird eine Fehlermeldung ausgegeben.
Datenbanken im Exchange-InformationsspeicherIn Exchange Server wird ESE als integriertes Datenbankmodul zum Festlegen der Struktur der Datenbanken sowie zum Verwalten des Arbeitsspeichers verwendet. Mit dem Datenbankmodul werden die Datenbanken im Arbeitsspeicher zwischengespeichert, indem 4-KB-Datenteile (Seiten) in und aus dem Arbeitsspeicher übertragen werden. Die Seiten werden im Arbeitsspeicher aktualisiert. Anschließend werden die neuen oder aktualisierten Seiten wieder auf Festplatte geschrieben. Bei Systemanforderungen können die Daten vom Datenbankmodul im Arbeitsspeicher gepuffert werden, sodass nicht permanent auf die Festplatte zugegriffen werden muss. Dadurch wird eine größere Systemeffizienz erreicht, da Schreibvorgänge im Arbeitsspeicher ungefähr 200.000 Mal schneller als auf der Festplatte durchgeführt werden. Anforderungen von Benutzern werden über das Datenbankmodul in den Arbeitsspeicher geladen. Die entsprechenden Seiten werden als modifiziert gekennzeichnet. Bei einer modifizierten Seite handelt es sich um eine Seite im Arbeitsspeicher, die Daten enthält. Die modifizierten Seiten werden zu einem späteren Zeitpunkt in die Datenbanken des Microsoft Exchange-Informationsspeicherdiensts auf Festplatte geschrieben.
Obwohl Daten über die Zwischenspeicherung im Arbeitsspeicher am schnellsten und effizientesten verarbeitet werden, bedeutet dies jedoch auch, dass die Informationen auf der Festplatte während der Ausführung von Exchange nie vollständig aktuell sind. Die aktuellste
592
Version der Datenbank befindet sich im Arbeitsspeicher. Da viele Änderungen im Arbeitsspeicher noch nicht auf der Festplatte vorhanden sind, sind Datenbank und Arbeitsspeicher nicht synchronisiert. Bei modifizierten Seiten im Arbeitsspeicher, die nicht übertragen und auf Festplatte geschrieben wurden, werden die Datenbanken als inkonsistent gekennzeichnet. Exchange-Datenbanken werden nur synchronisiert, wenn alle modifizierten Seiten im Arbeitsspeicher auf die Festplatte übertragen wurden. Dies erfolgt beim ordnungsgemäßen Beenden des Microsoft Exchange-Informationsspeicherdiensts. Beim Beenden des Microsoft Exchange-Informationsspeicherdiensts werden alle Seiten auf die Festplatte geschrieben.
MAPI-DatenbankdateiDie MAPI-Datenbankdatei in Exchange Server 2003 enthält Tabellen mit den Metadaten für alle E-Mail-Nachrichten und andere Objekte in der Datenbank sowie den Inhalt der MAPI-Nachrichten. Jeder in Microsoft Office Outlook angezeigte Ordner ist eine einzelne Datenbanktabelle im Exchange-Informationsspeicher. Jede Sortierreihenfolge zum Anzeigen der Ordner wird durch jeweils einen Index in der Tabelle dargestellt. Die Sortierreihenfolgen werden über den Prozess Store.exe verwaltet.
Nachrichten von MAPI-Clients, z. B. Outlook, werden wie in früheren Versionen von Exchange Server in der MAPI-Datenbank gespeichert. Mit auf MAPI basierenden Clients kann dann ohne Konvertierung auf die Nachrichten zugegriffen werden. Beim Lesen einer Nachricht in der Datenbank über einen IP-basierten Client wird die Nachricht jedoch in das erforderliche Format konvertiert.
Die EDB-Datei und die zugehörige STM-Datei bilden eine Einheit. Eine dieser Dateien kann ohne die andere nicht verwendet werden. Beachten Sie also, dass eine Datenbank im Microsoft Exchange Server-Informationsspeicherdienst zwei Dateien enthält, die EDB-Datei und die STM-Datei.
Ein Datensatz in der EDB-Datei enthält eine Spalte (vom Datentyp JET_coltypSLV), die auf eine Liste mit Seiten in der Streamingdatei mit den Rohdaten verweist. Die Speicherplatzverwendung (maximal 4 KB für Seitenzahlen) und die Prüfsummendaten für die Daten in der Streamingdatei werden in der EDB-Datei gespeichert.
StreamingdatenbankdateiIn Exchange Server 5.5 und früheren Versionen werden Nachrichten in MDBEF (Message Database Encapsulated Format) gespeichert. Dies ist das systemeigene Format für Outlook-Clients. Bei der Anforderung einer Nachricht über einen nicht auf MAPI basierten Client wird der Inhalt mit dem Microsoft Exchange-Informationsspeicherdienst von MDBEF in das der Anforderung entsprechende Format konvertiert. Durch die Konvertierung wird Prozessorbandbreite in Anspruch genommen und die Serverleistung verringert.
593
Bei neueren ESE-Versionen können Rohdaten von Internetmessagingclients im systemeigenen Format gespeichert werden. Das Repository für diese Rohdaten wird als Streamingdatenbank oder einfach als Streamingdatei bezeichnet. Die Streamingdatei weist keine zusätzlichen ausgeglichenen Strukturen (B-Strukturen) auf. Stattdessen enthält sie zwei Seiten mit Kopfzeileninformationen mit einer Größe von jeweils 4 KB und anschließend Rohdaten in 4-KB-Seiten. Diese einfache Datenstruktur wurde für BLOBs (Binary Large Objects) entwickelt, bei denen keine Inhaltskonvertierung durchgeführt wird und so sehr schnell empfangen und übertragen werden können.
Weitergabe von EigenschaftenÜber die Weitergabe von Eigenschaften wird der Speicherort von Daten in einer ESE-Datenbank festgelegt. Gründliche Kenntnisse dieses Konzepts sind daher von großer Bedeutung. Mit dem Microsoft Exchange-Informationsspeicherdienst wird die Weitergabe von Eigenschaften für Daten in der STM-Datei in die EDB-Datei unterstützt. Mit der Weitergabe von Eigenschaften können Ordneransichten und Indizes effizient verwaltet werden. Die Eigenschaften einer per Datenstrom in die STM-Datei übertragenen Nachricht, z. B. Sender, Betreff sowie Sende- und Empfangsdatum, werden beispielsweise an die Datensätze weitergegeben, mit denen die Nachricht in der EDB-Datei dargestellt wird.
Beim Senden einer Nachricht an den Microsoft Exchange-Informationsspeicherdienst über einen MAPI-Client, z. B. Microsoft Outlook, wird der Inhalt der Nachricht in der EDB-Datei gespeichert. Wenn die Nachricht über einen nicht auf MAPI basierten Client geöffnet wird, wird der MAPI-Inhalt mit dem Microsoft Exchange-Informationsspeicherdienst sofort in das Internetformat konvertiert. Dabei wird die Konvertierung teilweise durchgeführt und durch Aufrufen von IMAIL, wodurch wiederum RTFHTML aufgerufen wird, abgeschlossen. Keiner der Konvertierungsvorgänge ist dauerhaft, es werden keine Daten aus der EDB-Datei in die STM-Datei verschoben.
Beim Senden einer Nachricht an den Microsoft Exchange-Informationsspeicherdienst über einen Internetclient wird der Inhalt der Nachricht in der STM-Datei gespeichert. Einige Kopfzeilen der Internetnachricht werden in die EDB-Datei kopiert, sodass die Nachricht mit dem Microsoft Exchange-Informationsspeicherdienst gefunden werden kann. Dies wird als Status 0-Konvertierung bezeichnet.
Wenn ein Client eine Eigenschaft abruft, z. B. PR_Subject oder einen der vielen Aliase, werden alle Kopfzeileninformationen der Internetnachricht mit dem Microsoft Exchange-Informationsspeicherdienst an Eigenschaften weitergegeben. Dies wird als Status 1-Konvertierung bezeichnet.
Wenn ein Client Anlageninformationen abruft, wird mit dem Microsoft Exchange-Informationsspeicherdienst eine fast identische Kopie der Internetnachricht (im MAPI-Format) erstellt. Zunächst ist die Nachricht weiterhin in der STM-Datei gespeichert. Viele der für den MAPI-Zugriff erforderlichen Daten befinden sich jedoch in der EDB-Datei. Wenn ein Client die Nachricht so ändert, dass Änderungen an MIME (Multipurpose Internet Mail Extensions)
594
vorgenommen werden, wird die STM-Dateiversion der Nachricht gelöscht und nur die EDB-Datei der Nachricht beibehalten. Dies wird als Status 2-Konvertierung bezeichnet.
Unabhängig von der Übermittlungsart einer Nachricht an den Microsoft Exchange-Informationsspeicherdienst wird die Nachricht zunächst in der STM-Datei gespeichert, wenn Internetinhalt mit Application/ms-tnef in Exchange Server empfangen wird. Anschließend wird die Nachricht jedoch sofort decodiert und in die EDB-Datei verschoben. Dies gilt auch für Nachrichten mit winmail.dat-Anlagen, die mit UUEncode codiert sind. TNEF (Transport Neutral Encapsulation Format) und Winmail.dat sind Kapselungsverfahren für MAPI-Nachrichten zum Beibehalten von MAPI-Eigenschaften bei Übertragungen, die MAPI nicht unterstützen. Aus diesem Grund gilt das allgemeine Prinzip, dass MAPI-Nachrichten in der EDB-Datei und Internetnachrichten in der STM-Datei gespeichert sind. Mit den aktuellen Funktionen wird TNEF vor dem Lesen aller MAPI-Eigenschaften decodiert.
Konfiguration und Verwaltung der Größenbeschränkung von DatenbankenBis zum Service Pack 2 (SP2) von Microsoft Exchange Server 2003 gab es keine Methode, um die Größenbeschränkungen von Datenbanken für Exchange Server 2003 zu konfigurieren. Mit SP2 wurden die folgenden neuen Features hinzugefügt:
In der Standard Edition beträgt jetzt die konfigurierte Standardgrößenbeschränkung für Datenbanken 18 GB. Das sind 2 GB mehr im Vergleich zum vorherigen Grenzwert, wobei der neue Höchstwert 75 GB beträgt.
Für die Enterprise Edition gibt es keine konfigurierte Standardgrößenbeschränkung für Datenbanken und keinen Höchstwert, der durch die Software festgelegt ist.
Beide Versionen von Exchange Server 2003 mit SP2 verfügen über die Möglichkeit, einen Grenzwert, einen Schwellenwert für Warnungen und ein Zeitintervall zwischen Warnmeldungen durch das Festlegen von Registrierungsschlüsseln zu konfigurieren.
Bei der Überprüfung der Datenbankgröße wird jetzt die logische Datenbankgröße verwendet. Leer- oder Tabulatorzeichen in der Datenbank werden im Vergleich zur konfigurierten Größenbeschränkung für Datenbanken nicht mitgezählt. Daher wird bei einer Wiederherstellung, bei der die konfigurierten oder lizenzierten Datenbankgrenzwerte überschritten werden, keine Offlinedefragmentierung benötigt.
Die regelmäßig erfolgenden Überprüfungen der Grenzwerte werden jetzt vom Speichervorgang und nicht von JET gesteuert. Das Standardzeitintervall beträgt 24 Stunden. Dieses Intervall kann über die Registrierung konfiguriert werden.
595
Registrierungseinstellungen Die Registrierungsschlüssel für die Datenbankgrößenbeschränkung werden bei der
Bereitstellung der Datenbank (nicht beim Start des Diensts) und bei jeder Überprüfung der Größenbeschränkung gelesen.
Sie müssen die Registrierungsparameter für jede Datenbank festlegen, für die Änderungen der Größenbeschränkungen vorgesehen sind. Die Registrierungseinträge sollten sich unter jedem Datenbankeintrag in der lokalen Serverregistrierung befinden. Dementsprechend müssen Sie die Registrierungsschlüssel manuell zurücksetzen, falls der Server mithilfe der Installationsoption /disasterecovery erneut erstellt werden muss.
Hinweis: Die fehlerhafte Bearbeitung der Registrierung kann zu ernsthaften Problemen führen, die möglicherweise eine Neuinstallation des Betriebssystems erforderlich machen. Dadurch entstandene Probleme können unter Umständen nicht mehr behoben werden. Sichern Sie vor dem Ändern der Registrierung alle wichtigen Daten.
Alle in diesem Thema besprochenen Registrierungseinstellungen werden am folgenden Speicherort in der Registrierung erstellt:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Servername>\Private-013e2e46-2cd7-4a8e-bfec-0e4652b94b00
Die GUID in diesem Schlüssel (Private-013e2e46-2cd7-4a8e-bfec-0e4652b94b00) stellt ein Beispiel dar und muss dem Wert des objectGUID-Attributs für das Active Directory-Objekt der Datenbank entsprechen.
Hinweis: In der Standardeinstellung sind die in diesem Artikel erwähnten Registrierungseinträge nicht vorhanden. Wenn Sie den Eintrag erstellen, wird der im Code festgelegte Standardwert überschrieben.
Hinweis: Bei allen in diesem Artikel genannten Registrierungswerten handelt es sich um Dezimalwerte und nicht um Hexadezimalwerte.
Mit SP2 sind die folgenden neuen Registrierungseinstellungen verfügbar:
Datenbankgrößenbeschränkung in GB
Warnung für Puffer der Datenbankgröße in Prozent
Startzeit für Überprüfung der Datenbankgröße in Stunden nach Mitternacht
596
Datenbankgrößenbeschränkung in GBDie Einstellung Datenbankgrößenbeschränkung in GB stellt die konfigurierbare maximale Größe einer Datenbank dar, die nicht die maximal lizenzierte Größe der Datenbank überschreiten darf. In der Standard Edition können Sie die Größenbeschränkung für Datenbanken im Bereich von 1 bis 75 GB festlegen. In der Standardeinstellung beträgt der Grenzwert 18 GB. In der Enterprise Edition können Sie die Größenbeschränkung für Datenbanken im Bereich von 1 bis 8.000 GB festlegen. In der Standardeinstellung ist keine Beschränkung festgelegt.
Der folgende Registrierungswert steuert die konfigurierbare Größenbeschränkung für Datenbanken:
Datentyp Name Wert (in GB) Standardwert (in GB)
REG_DWORD Database Size Limit in GB
Standard: 1-75
Enterprise: 1-8000
Standard: 18
Enterprise: 8.000 unbeschränkt
Warnung für Puffer der Datenbankgröße in ProzentDie Einstellung Warnung für Puffer der Datenbankgröße in Prozent stellt einen konfigurierbaren Fehlerschwellenwert dar, bei dem als Warnung ein Ereignisprotokolleintrag ausgegeben wird, wenn die Datenbank völlig oder nahezu ihre Kapazität erreicht hat, und bei dem die Datenbank innerhalb von 24 Stunden nach der Ereignisprotokollierung beendet wird. In der Standardeinstellung werden von Exchange Server 2003 SP2 Ereignisse protokolliert, wenn die Datenbank auf eine Größe angewachsen ist, die im Bereich von bis zu 10% unterhalb der konfigurierten Datenbankgrößenbeschränkung liegt. Dieser Schwellenwert kann konfiguriert werden. Der kleinste Pufferwert beträgt 1 Prozent der konfigurierten Größenbeschränkung.
Der folgende Registrierungswert steuert die Warnung für den Puffer der Datenbankgröße:
Datentyp Name Wert (in %) Standard (in %)
REG_DWORD Database Size Buffer Warning in Percentage
1 - 100 10
597
Startzeit für Überprüfung der Datenbankgröße in Stunden nach MitternachtMithilfe der Einstellung Startzeit für Überprüfung der Datenbankgröße in Stunden nach Mitternacht kann konfiguriert werden, wann das System eine Datenbank dahingehend überprüft, ob die aktuell konfigurierte Größenbeschränkung für die Datenbank überschritten ist. In der Standardeinstellung erfolgt die Überprüfung der Datenbankgröße jeden Tag um 05:00 Uhr morgens. Diese Uhrzeit kann geändert werden. Nach der Änderung wird die neue Aufgabe für die neue Offset-Uhrzeit geplant. Die Überprüfungen im Intervall für die Überprüfung der Datenbankgröße entfallen bis zur neuen Startzeit.
Wenn die Größenbeschränkung überschritten wurde, wird bei der ersten Überprüfung der Datenbankgröße die Datenbank nicht offline geschaltet. Dadurch steht Ihnen die Datenbank mindestens 24 Stunden zur Verfügung, nachdem der in der Standardeinstellung festgelegte Grenzwert überschritten wurde.
Datentyp Name Werte Standard Beschreibung
REG_DWORD Database Size Check Start Time in Hours from Midnight
1 - 24 5 Legt die Uhrzeit für die erste Überprüfung der Datenbankgröße fest, nachdem eine Datenbank bereitgestellt wurde.
Verhalten bei Erreichen der konfigurierten oder lizenzierten DatenbankgrößenbeschränkungBeim Bereitstellen einer Datenbank vergleicht der Speichervorgang die physische Datenbankgröße mit der Konfigurierten Datenbankgrößenbeschränkung in GB. Wenn die physische Größe dem konfigurierten Wert für den Warnung für Puffer der Datenbankgröße in Prozent entspricht oder ihn überschreitet, führt der Speicher eine logische Berechnung der Datenbankgröße aus. Wenn sie kleiner als der Warnpuffer ist, muss der freie Speicherplatz nicht berechnet werden, weil die logische Größe nie die physische Größe überschreiten wird. Im Allgemeinen ist die physische Größe kleiner als der Schwellenwert für Warnungen. Daher wird für die Größenüberprüfung weniger als eine Millisekunde benötigt. Wenn der freie Speicherplatz berechnet werden muss, sind für die Größenüberprüfung möglicherweise einige Sekunden erforderlich, damit die Datenbank analysiert und die logische Größe berechnet wird.
598
Wenn der Wert für den Warnung für Puffer der Datenbankgröße in Prozent erreicht oder überschritten ist, wird im Anwendungsereignisprotokoll ein Fehlerereignis, Ereignis-ID 9688, protokolliert.
Ab Exchange Server 2003 SP2 oder höher werden vom Server bei Erreichen der konfigurierbaren (oder konfigurierten Standard-)Größenbeschränkung für Datenbanken die folgenden Aufgaben ausgeführt:
Wenn bei der ersten Überprüfung nach der Bereitstellung einer Datenbank eine Datenbankgröße über dem Grenzwert festgestellt wird, wird die Datenbank nicht offline geschaltet, sondern im Anwendungsereignisprotokoll ein Fehlerereignis (ID 9689) protokolliert.
Bei der zweiten Überprüfung wird im Anwendungsereignisprotokoll ein Fehlerereignis protokolliert, und die Datenbank wird offline geschaltet.
Nachdem der Administrator die Datenbank bereitgestellt hat, hat er 24 Stunden (oder bis zur nächsten Überprüfung der Datenbankgröße oder bis 05:00 Uhr morgens, falls der Standardwert festgelegt ist) Zeit für Korrekturen.
Lizenzierte DatenbankgrößenbeschränkungDie Exchange Server 2003 Standard Edition ist auf eine einzelne Speichergruppe mit einer einzelnen privaten Informationsspeicherdatenbank und einer einzelnen Datenbank für Öffentliche Ordner beschränkt. Vor SP2 war jede Datenbank auf 16 GB physische Gesamtgröße beschränkt. Mit SP2 vergrößert sich die lizenzierte Größenbeschränkung für Datenbanken für Exchange Server 2003 Standard Edition von 16 GB auf 75 GB. Die konfigurierte Standardgrößenbeschränkung für Datenbanken beträgt 18 GB. Die Optionen für die Speichergruppe von Exchange Server 2003 Enterprise Edition und für den Exchange-Informationsspeicher ändern sich nicht mit der Anwendung von SP2. Der Enterprise Edition wurde jedoch eine konfigurierbare Größenbeschränkung für den Exchange-Informationsspeicher hinzugefügt.
Version Exchange Server 2003
Lizenzierter Grenzwert Standardkonfigurationsgrenzwert
Standard Edition vor SP2 16 GB Nicht zutreffend
Standard Edition mit SP2 75 GB 18 GB
Enterprise Edition vor SP2 8.000 GB (unbegrenzt) Nicht zutreffend
Enterprise Edition mit SP2 8.000 GB (unbegrenzt) 8.000 GB
599
Hinweis: Der aktuelle fest codierte Grenzwert der JET-Datenbank beträgt 8.192 GB bzw. 8 Terabyte (TB).
Überlegungen zur Planung für die Wiederherstellung nach DatenverlustWenn Sie die Größenbeschränkung von Exchange-Datenbanken ändern, empfiehlt es sich, den Sicherungs- und Wiederherstellungsplan für die Exchange-Datenbanken erneut zu überprüfen. Insbesondere wenn Sie den Grenzwert für die Größe von Exchange-Datenbanken erhöhen, müssen Sie die Sicherungs- und Wiederherstellungsverfahren mit den neuen Größenbeschränkungen für die Datenbanken testen, um sicherzustellen, dass Sie Ihre Verträge über den Umfang von Serviceleistungen noch erfüllen können. Wenn z. B. die frühere Größe eines Postfachspeichers 15 GB betrug und Sie den Vertrag über den Umfang von Serviceleistungen erfüllen konnten, indem die Daten in weniger als 8 Stunden wiederhergestellt waren, können Sie dies möglicherweise nicht mehr, wenn die Größe des Postfachspeichers auf 20 GB oder mehr festgelegt wurde.
Weitere Informationen zu Verträgen über den Umfang von Serviceleistungen (Service Level Agreements) finden Sie im Exchange Server 2003 - Handbuch für hohe Verfügbarkeit unter „Erstellen einer Vereinbarung zum Servicelevel“ in „Aufstellen von Zielen zur Verfügbarkeit“.
Weitere Informationen zur Konfiguration von Größenbeschränkungen für Datenbanken finden Sie in der Onlinehilfe zu Exchange Server 2003 SP2 unter „Konfigurieren von Größenbeschränkungen für Datenbanken“.
Architektur von Extensible Storage EngineWie bereits weiter oben in diesem Abschnitt erwähnt, setzt der Exchange-Informationsspeicher auf einer ESE-Datenbank (Extensible Storage Engine) auf. Bei ESE handelt es sich um eine ISAM-Tabellenverwaltung (Indexed Sequential Access Method) für mehrere gleichzeitig angemeldete Benutzer mit vollständigen Funktionen für DML (Data Manipulation Language) und DDL (Data Definition Language). Mit ESE können Datensätze von Anwendungen gespeichert sowie Indizes für verschiedenste Zugriffe auf diese Datensätze erstellt werden.
Derzeit liegen drei Versionen von ESE vor:
ESE97 Das Datenbankmodul in Exchange Server 5.5.
ESENT Das Datenbankmodul für Active Directory und zahlreiche andere Microsoft Windows-Komponenten. Im Gegensatz zu anderen Versionen von ESE (mit 5-MB-Protokolldateien und 4-KB-Seitengrößen) werden bei der ESENT-Implementierung für
600
Active Directory Protokolldateien mit einer Größe von 10 MB und Seiten mit einer Größe von 8 KB verwendet.
ESE98 Das Datenbankmodul in Exchange 2000 Server und Exchange Server 2003.
Hinweis: ESE wurde früher als JET Blue (Joint Engine Technology) bezeichnet. Bei JET Blue handelt es sich nicht um die in Access verwendete JET-Version (die als JET Red bezeichnet wird).
TransaktionenESE ist ein hochentwickeltes transaktionsbasiertes Datenbankmodul. Bei einer Transaktion handelt es sich um eine Folge von Operationen, die als unteilbare Einheit gelten. Entweder sind alle Operationen in einer Transaktion abgeschlossen und dauerhaft gespeichert oder keine einzige Operation wird durchgeführt. Betrachten Sie beispielsweise die Operationen beim Verschieben einer Nachricht vom Ordner Posteingang in den Ordner Gelöschte Objekte. Die Nachricht wird in einem Ordner gelöscht und in einem anderen Ordner eingefügt. Die Ordnereigenschaften werden aktualisiert. Beim Auftreten eines Fehlers sollen nicht versehentlich zwei Kopien der Nachricht, keine Kopie oder Ordnereigenschaftenwerte (z. B. Objektzahl) vorliegen, die mit dem tatsächlichen Inhalt des Ordners nicht übereinstimmen.
Zur Vermeidung dieser Probleme werden durch ESE alle Operationen in einer Transaktion gebündelt. Damit wird sichergestellt, dass alle Operationen erst dauerhaft angewendet werden, wenn die Transaktion an die Datenbankdatei übergeben wurde. Mit Übergabe der Transaktion an die Datenbankdatei werden alle Operationen dauerhaft angewendet.
Bei einem Systemabsturz wird die automatische Wiederherstellung beim Start über ESE verwaltet. Alle nicht übergebenen Transaktionen werden zurückgesetzt. Wenn vor der Übergabe einer Transaktion Fehler in ESE auftreten, wird die gesamte Transaktion zurückgesetzt, als wäre sie nie ausgeführt worden. Wenn nach der Übergabe einer Transaktion Fehler in ESE auftreten, wird die gesamte Transaktion beibehalten. Die Änderungen werden auf den Clients angezeigt.
ACID-TransaktionenZuverlässige Transaktionen werden im Allgemeinen als ACID-Transaktionen bezeichnet. ACID-Transaktionen können anhand der folgenden Eigenschaften identifiziert werden:
Unteilbar Mit diesem Begriff wird angegeben, dass die Änderung des Transaktionsstatus entweder vollständig ausgeführt oder überhaupt nicht ausgeführt wird. Zu den unteilbaren Statusänderungen zählen Änderungen der Datenbank sowie Nachrichten und Vorgänge in Wandlern.
601
Konsistent Mit diesem Begriff wird angegeben, dass eine Transaktion die korrekte Transformation des Status darstellt. Mit den als Gruppe durchgeführten Vorgängen wird keine der dem Status zugeordneten Integritätsanforderungen verletzt. Dazu muss die Transaktion ein fehlerfreies Programm sein.
Isoliert Mit diesem Begriff wird angegeben, dass Transaktionen zwar gleichzeitig ausgeführt werden, sie dabei aber entweder vor oder nach, jedoch nicht vor und nach einer Transaktion ausgeführt werden.
Dauerhaft Mit diesem Begriff wird angegeben, dass nach dem erfolgreichen Abschluss (der Übergabe) einer Transaktion der Status so geändert wird, dass er auch bei Fehlern beibehalten wird.
Der VersionsspeicherESE kann über den Versionsspeicher aktuelle Transaktionen protokollieren und verwalten. Daher können die Themen Isolation und Konsistenz des ACID-Tests als gegeben angesehen werden. Mit dem Versionsspeicher wird eine Liste der an der Datenbank vorgenommenen Änderungen im Arbeitsspeicher verwaltet.
Der Versionsspeicher wird in folgenden Fällen verwendet:
Rollback Wenn eine Transaktion zurückgesetzt werden muss, wird der Versionsspeicher überprüft und eine Liste der ausgeführten Operationen abgerufen. Durch die inverse Ausführung aller Operationen kann die Transaktion zurückgesetzt werden.
Schreibkonflikterkennung Wenn in zwei verschiedenen Sitzungen der gleiche Datensatz geändert werden soll, wird die zweite Änderung im Versionsspeicher erkannt und abgelehnt.
Wiederholbare Lesevorgänge Beim Start einer Transaktion in einer Sitzung wird immer die gleiche Ansicht der Datenbank angezeigt, auch wenn die angezeigten Datensätze in anderen Sitzungen geändert werden. Beim Lesen eines Datensatzes in einer Sitzung wird der Versionsspeicher zum Festlegen der Version des anzuzeigenden Datensatzes verwendet. Wiederholbare Lesevorgänge verfügen über eine Isolationsstufe, in der nach dem Start einer Transaktion über einen Client der Status der Datenbank zum Zeitpunkt des Transaktionsstarts angezeigt wird, unabhängig von den durch andere Clients oder in anderen Sitzungen vorgenommenen Änderungen. Wiederholbare Lesevorgänge werden durch Verwendung des Versionsspeichers implementiert. Mit einer Liste der an der Datenbank vorgenommenen Änderungen im Arbeitsspeicher kann festgelegt werden, welche Ansicht eines Datensatzes in bestimmten Sitzungen jeweils angezeigt wird.
Verzögerung vor der Abbildprotokollierung Hierbei handelt es sich um ein komplexes Optimierungsverfahren, mit dem über ESE weniger Daten als mit anderen vergleichbaren Datenbankmodulen protokolliert werden können.
602
Snapshot-IsolationNach dem Starten einer Transaktion wird von ESE gewährleistet, dass in der Sitzung ein einzelnes konsistentes Abbild der Datenbank zum Zeitpunkt des Starts der entsprechenden Transaktion sowie daran vorgenommene Änderungen angezeigt werden. Da die Daten auch in anderen Sitzungen geändert und die zugehörigen Transaktionen übergeben werden können, werden Änderungen in Transaktionen nicht angezeigt, die vor der Übergabe gestartet wurden. Benutzer können Datensätze nur ändern, wenn die jeweils aktuellste Version angezeigt wird. Andernfalls schlägt die Aktualisierung mit JET_errWriteConflict fehl. Die zeitlich vor der letzten Transaktion liegenden Versionen werden automatisch verworfen.
ESE verfügt über eine Transaktionsisolationsstufe mit der Bezeichnung Snapshot-Isolation. Über die Snapshot-Isolationsstufe können Benutzer in einer übergangsweise konsistenten Ansicht der Datenbank auf die letzte übergebene Zeile zugreifen. Bei der Snapshot-Isolation handelt es sich um einen Steuerungsalgorithmus mit vollständiger Parallelität, der zuerst in A Critique of ANSI SQL Isolation Levels beschrieben wurde. Die Snapshot-Isolation wird mit ESE durch Verwendung von wiederholbaren Lesevorgängen implementiert.
ESE-DatenbankstrukturAlle Daten in der Rich-Text-Datenbankdatei werden in B-Strukturen gespeichert. Das „B“ in B-Struktur steht für „ausgeglichen“ (Englisch: balanced). „Struktur“ bezieht sich auf eine Anordnung, die der einer Ordnerstruktur in einem Dateisystem entspricht, bei der ein Stamm den Objekten (Datenbankseiten) übergeordnet ist, die wiederum anderen Objekten übergeordnet sind. B-Strukturen sind so entworfen, dass schnell auf Daten auf der Festplatte zugegriffen werden kann. Da Lese- und Schreibvorgänge auf einer Festplatte mehr Zeit in Anspruch nehmen als im Arbeitsspeicher, ist eine B-Struktur in 4-KB-Seiten unterteilt, sodass die erforderlichen Daten über ESE mit der Mindestanzahl von E/A-Vorgängen auf der Festplatte abgerufen werden können. Eine ESE-Datenbank kann bis zu 232 Seiten oder 16 Terabyte enthalten. Tatsächlich wird die Datenbankgröße nur durch die Funktionen zum Sichern, Wiederherstellen oder Ausführen anderer Verwaltungsoperationen in der Datenbank (z. B. Offlinedefragmentierung, Datenbankreparaturen) in einer angemessenen Zeit begrenzt.
DatenbankseitenDie Seitengröße in ESE wird in der Anwendung definiert, in der sie verwendet wird. In ESE97 (Exchange Server 5.5) und ESE98 (Exchange 2000 Server und Exchange Server 2003) werden beispielsweise 4-KB-Seiten verwendet, in ESENT (Active Directory) dagegen 8-KB-Seiten. Jede dieser 4-KB- oder 8-KB-Seiten enthält Verweise auf andere Seiten oder auf die tatsächlichen in der B-Struktur gespeicherten Daten. Der Verweis und die Datenseiten sind zusammen in der Datei vorhanden.
Zur Optimierung der Systemleistung werden die Seiten möglichst lange in einem Puffer im Arbeitsspeicher zwischengespeichert, sodass sie nicht auf der Festplatte gespeichert werden
603
müssen. Jede Seite beginnt mit einer Kopfzeile mit einer Größe von 40 Byte, in der folgende Werte aufgeführt sind:
pgnoThis Mit diesem Wert wird die Seitenzahl der Seite angegeben.
DbtimeDirtied Mit diesem Wert wird der Zeitpunkt angegeben, an dem die Seite zuletzt geändert wurde.
pgnoPrev Mit diesem Wert wird die Seitenzahl der angrenzenden linken Seite auf dem Endknoten angegeben.
pgnoNext Mit diesem Wert wird die Seitenzahl der angrenzenden rechten Seite auf dem Endknoten angegeben.
ObjidFDP Mit diesem Wert wird die Objekt-ID einer speziellen Seite in der Datenbank angegeben, die als Vater der Datenbankseite (FDP, Father of the Data Page) bezeichnet wird. Dadurch ist festgelegt, welcher B-Struktur die Seite zugeordnet ist. Die FDP-Seite wird bei der Reparatur verwendet.
cbFree Mit diesem Wert wird die Größe der in der Seite verfügbaren Byte angegeben.
cbUncommittedFree Mit diesem Wert wird die Größe der verfügbaren, nicht übergebenen Byte (freigegebene Byte, die beim Zurücksetzen verwendet werden können) in der Seite angegeben.
ibMicFree Mit diesem Wert wird der Seitenoffset für die nächsten verfügbaren Byte oben in der Seite angegeben.
ECC-PrüfsummeExchange Server 2003 Service Pack 1 (SP1) verfügt über eine neue Funktion, die so genannte ECC-Prüfsumme (Error Correcting Code). Die ECC-Prüfsumme ist ein neues Prüfsummenformat, über das Einzelbit-Fehler in Datenbankseiten (in der EDB-Datei, STM-Datei und den Transaktionsprotokolldateien) korrigiert werden können. In diesem neuen Prüfsummenformat werden 64 Bit verwendet, in älteren Prüfsummenformaten dagegen nur 32 Bit. Der neue Code kann in Datenbanken mit älteren Formaten verwendet werden, ältere ESE-Versionen jedoch nicht in Datenbanken im aktuellen Format. Nach der Aktualisierung des Datenbankmoduls haben alle in die Datenbank geschriebenen Seiten das neue Prüfsummenformat. Bei Seiten, die gelesen und nicht geändert werden, wird das Prüfsummenformat nicht aktualisiert.
Hinweis: Nach der Bereitstellung der neuen Datei ESE.dll wird das Prüfsummenformat aller Seiten in der Datenbank bei jeder Offlinedefragmentierung aktualisiert. Dadurch verlängert sich die Dauer der Defragmentierung einer Datenbank möglicherweise erheblich. Aus diesem Grund wird diese Vorgehensweise nicht empfohlen. Ebenso
604
wird von der Ausführung von esetuil mit dem Parameter /k abgeraten, da hierbei ebenfalls die Prüfsumme aller Seiten in der Datenbank erstellt wird.
Bei Datenbankseiten mit dem älteren Prüfsummenformat wird zuerst eine 4-Byte-Prüfsumme und anschließend eine 4-Byte-Seitenzahl erstellt, mit der überprüft wird, ob die angeforderte Seite tatsächlich von der Festplatte gelesen wurde.
Beim neuen Prüfsummenformat wird die 4-Byte-Seitenzahl durch eine 8-Byte-Seitenzahl ersetzt. Bei der Berechnung der Prüfsumme wird die Seitenzahl als Eingabeparameter verwendet. Wenn die falsche Seite von der Festplatte gelesen wurde, führt dies zu einer Nichtübereinstimmung der Prüfsumme.
Das aktuelle Prüfsummenformat setzt sich aus zwei 32-Bit-Prüfsummen zusammen. Bei der ersten handelt es sich um eine XOR-Prüfsumme, die in fast identischer Weise wie die Prüfsumme im älteren Format berechnet wird. Dabei wird die Seitenzahl als Ausgangswert zur Berechnung der Prüfsumme verwendet. Die zweite 32-Bit-Prüfsumme ist eine ECC-Prüfsumme, mit der die Einzelbit-Fehler in der Seite korrigiert werden können.
Datenbankkonsistenz und -1018-Fehler Beim Lesen einer Seite wird von ESE ein Kennzeichen überprüft. Dadurch wird
festgestellt, ob die Seite das aktuelle Prüfsummenformat aufweist. Anschließend wird die entsprechende Prüfsumme (mit dem aktuellen oder älteren Format) berechnet. Bei einer Nichtübereinstimmung der Prüfsumme mit der Prüfsumme im aktuellen Format versucht ESE, den Fehler zu korrigieren. Wenn der Fehler nicht automatisch behoben werden kann, wird in Exchange eine -1018-Fehlermeldung ausgegeben.
Möglicherweise wird ein -1018-Fehler durch den Exchange-Informationsspeicher erzeugt, wenn im Exchange-Informationsspeicher folgende Vorgänge durchgeführt werden:
Erstellen einer Seite mit der falschen Prüfsumme
Ordnungsgemäßes Erstellen einer Seite, jedoch Anweisung an das Betriebssystem zum Schreiben der Seite in den falschen Speicherort
Wenn ein Systemadministrator einen -1018-Fehler erkennt oder Diagnosehardwaretests auf dem Server ausführt und dabei keine Fehler ausgegeben werden, zieht er möglicherweise den Schluss, dass ein interner Fehler in Exchange Server aufgetreten ist, da die Analyse der Hardware positiv ausgefallen ist.
In vielen Fällen wurden durch weitere Untersuchungen durch Microsoft oder Hardwarehersteller schwerwiegende Fehler in der Hardware, Firmware oder in Gerätetreibern festgestellt, aufgrund derer die Datenbankdatei beschädigt wurde.
Aus verschiedenen Gründen werden in gewöhnlichen Diagnosetests unter Umständen nicht alle möglichen Fehler ermittelt. Probleme in der Firmware oder Treibersoftware werden möglicherweise mit den Funktionen von Diagnoseprogrammen nicht gefunden. Mit Diagnosetests können die langen Laufzeiten oder komplexen Ladevorgänge eventuell nicht
605
entsprechend simuliert werden. Darüber hinaus wird das System durch die Diagnoseüberwachung oder die Debugprotokollierung unter Umständen so geändert, dass die Fehler nicht erneut auftreten.
Durch die Einfachheit und Stabilität der Exchange Server-Mechanismen zum Erstellen von Prüfsummen und Schreiben von Seiten in die Datenbankdatei wird ein -1018-Fehler in aller Regel nicht durch Exchange Server selbst hervorgerufen. Die Prüfsummenüberprüfung und die Erkennung falscher Seiten sind einfach und zuverlässig und wurden seit der ersten Exchange-Version nahezu unverändert beibehalten, mit Ausnahme von geringfügigen Änderungen zur Anpassung an Datenbankseitenformate von einzelnen Datenbankversionen.
Eine Prüfsumme wird für eine auf Festplatte zu schreibende Seite erstellt, nach dem alle anderen Daten sowie die Seitenzahl in die Seite geschrieben wurden. Nach dem Hinzufügen der Prüfsumme zur Seite weist Exchange Server das Microsoft Windows Server-Betriebssystem an, die Seite über standardisierte und veröffentlichte Windows Server-APIs auf Festplatte zu schreiben.
Unter Umständen wird die Prüfsumme für eine Seite richtig erstellt, die Seite jedoch an einen falschen Speicherort auf die Festplatte geschrieben. Dies kann durch einen temporären Speicherfehler hervorgerufen werden, z. B. durch einen „Bit Flip“-Fehler. In Exchange wird beispielsweise eine neue Version von Seite 70 erstellt. Die Seite selbst enthält keine Fehler, die Kopie der Seitenzahl im Festplattencontroller oder im Betriebssystem wurde jedoch willkürlich verändert. Dieses Problem kann auftreten, wenn 70 (binär 1000110) in einer instabilen Speicherzelle in 6 (binär 000110) geändert wurde. Die Prüfsumme der Seite ist weiterhin richtig, der Speicherort der Seite in der Datenbank nun jedoch falsch. In Exchange Server wird ein -1018-Fehler für die Seite ausgegeben, wenn die logische Seitenzahl nicht mit dem physischen Speicherort der Seite übereinstimmt.
Ein anderer (in Exchange Server verursachter) Fehler kann bei der Seitennummerierung auftreten, wenn in Exchange Server die falsche Seitenzahl in die Seite selbst geschrieben wird. Hierdurch treten jedoch andere Fehler, nicht der -1018-Fehler auf. Wenn von Exchange Server 71 in Seite 70 geschrieben und anschließend die Prüfsumme der Seite berechnet wird, wird die Seite nach erfolgreichem Seitenzahlen- sowie Prüfsummentest in Speicherort 71 geschrieben.
In der Regel wird eine Exchange Server-Datenbank durch einen einzelnen ausgegebenen -1018-Fehler nicht beendet, sondern lediglich der -1018-Fehler selbst protokolliert. Die Seite befindet sich unter Umständen in einem Ordner, der selten aufgerufen wird (z. B. der Ordner Gesendet oder Gelöschte Objekte), oder in einer Anlage, die nicht oft geöffnet wird oder gar leer ist.
Obwohl durch einen einzelnen -1018-Fehler wahrscheinlich kein großer Datenverlust entsteht, sollten diese Fehler dennoch berücksichtigt werden, da sie darauf hindeuten, dass Daten im Speichersystem mindestens einmal nicht zuverlässig gespeichert oder wiederhergestellt wurden. Obwohl es sich bei einem -1018-Fehler um ein vorübergehendes Problem handeln kann, das nie wieder auftritt, ist es wahrscheinlicher, dass dieser Fehler eine frühzeitige Warnung für ein Problem ist, das zunehmend schwerwiegender wird. Auch
606
wenn der erste -1018-Fehler bei einer leeren Seite in der Datenbank auftritt, können Sie nicht wissen, welche Seite möglicherweise demnächst beschädigt wird. Wenn eine wichtige globale Tabelle beschädigt ist, kann die Datenbank möglicherweise nicht gestartet und eine Reparatur nur teilweise erfolgreich oder überhaupt nicht durchgeführt werden.
Nach der Protokollierung eines -1018-Fehlers sollten Sie alle Möglichkeiten für drohende Fehler oder einer weiteren Beschädigung in der Datenbank überprüfen, bis die Ursache für den Fehler gefunden und behoben wurde.
DatenbankstrukturausgleichEine der Hauptfunktionen von ESE besteht darin, dass die Datenbankstruktur permanent ausgeglichen wird. Der Vorgang zum Ausgleichen der Struktur wird durchgeführt, wenn alle Seiten geteilt oder zusammengeführt sind. Wie in der folgenden Abbildung dargestellt, stimmt die Anzahl der Knoten im Stamm der Struktur immer mit den Knoten in den Endknoten der Struktur überein. Daher ist die Struktur ausgeglichen.
Ausgeglichene Struktur
Hinweis: Obwohl die Strukturen in einer ESE-Datenbank im Allgemeinen als B-Strukturen bezeichnet werden, handelt es sich in Wirklichkeit um B+-Strukturen. B+-Strukturen weisen die gleichen Merkmale wie B-Strukturen auf, jede Datenseite in einer B+-Struktur verfügt jedoch zusätzlich über Seitenverweise zur vorherigen und nächsten angrenzenden Seite im Endknoten. Obwohl die Aktualisierung dieser Verweise beim Einfügen oder bei Teilungs- bzw. Zusammenführungsvorgängen einen zusätzlichen Aufwand darstellt, kann über die Verweise eine schnellere sequentielle Suche durch die Daten in der B+-Struktur durchgeführt werden.
In ESE handelt es sich bei einer Datenbanktabelle um eine Sammlung von B-Strukturen. Jede Tabelle umfasst eine B-Struktur, die die Daten enthält, obwohl mehrere B-Strukturen für sekundäre Indizes zum Bereitstellen verschiedener Ansichten der Daten vorliegen können. Wenn eine Spalte oder ein Feld in einer Tabelle zu groß werden, um in der B-Struktur
607
gespeichert werden zu können, werden sie auf eine gesonderte B-Struktur aufgeteilt, die so genannte Langwertstruktur.
Die Definition der Tabellen und der zugeordneten B-Strukturen wird in einer anderen B-Struktur gespeichert, dem so genannten Systemkatalog. Der Verlust des Systemkatalogs führt zu schwerwiegenden Problemen. Aus diesem Grund sind in ESE zwei identische Kopien dieser B-Struktur in jeder Datenbank gespeichert, wobei eine auf Seite 4 beginnt und die andere auf Seite 24.
TeilungWenn eine Seite fast gefüllt ist, wird etwa die Hälfte der Daten in eine sekundäre Seite verschoben und in der übergeordneten Seite der sekundären Seite ein zusätzlicher Schlüssel gespeichert. Dieser Vorgang wird nur durchgeführt, wenn die übergeordnete Seite nicht voll ist. In diesem Fall wird die übergeordnete Seite geteilt und der dieser Seite übergeordneten Seite ein Verweis hinzugefügt. Letzten Endes muss möglicherweise jede Verweisseite bis zum Stammblock geteilt werden. Wenn der Stammblock geteilt werden muss, wird eine zusätzliche Seitenebene in die Struktur eingefügt. In einem übertragenen Sinne nimmt die Struktur an Höhe zu.
ZusammenführungWenn eine Seite fast leer ist, wird sie mit einer angrenzenden Seite zusammengeführt. Die Verweise in der übergeordneten Seite werden aktualisiert, und gegebenenfalls wird die Seite wiederum mit einer anderen Seite zusammengeführt. Wenn jede Verweisseite bis zum Stammblock mit einer anderen Seite zusammengeführt werden muss, verringert sich die Höhe der Struktur. Zum Abrufen eines Endknotens (Daten) sucht ESE beginnend beim Stammknoten und dann entsprechend den Seitenverweisen, bis der gewünschte Endknoten abgerufen wird.
AuffächerungDie Baumstruktur einer B-Struktur in ESE kann sehr weit aufgefächert werden. Dies bedeutet, dass in ESE alle Daten in einer 50-GB-Tabelle mit höchstens vier Lesevorgängen auf der Festplatte (drei Verweisseiten und die Datenseite) abgerufen werden können. In ESE werden über 200 Seitenverweise pro 4-KB-Seite gespeichert, sodass Strukturen mit einer sehr geringen Anzahl von übergeordneten und untergeordneten Ebenen (auch als flache Strukturen bezeichnet) verwendet werden können. In ESE wird darüber hinaus ein Schlüssel der aktuellen Struktur gespeichert, sodass diese auf schnelle Weise durchsucht werden kann. In der Abbildung weiter oben ist eine Struktur mit drei über- und untergeordneten Ebenen dargestellt. In einer Struktur mit vier über- und untergeordneten Ebenen können mehrere Gigabyte Daten gespeichert werden.
608
IndizesEine herkömmliche B-Struktur wird nur auf eine bestimmte Weise indiziert. Dazu wird ein Schlüssel verwendet. Die Daten müssen über diesen Schlüssel abgerufen werden. Die Datensätze in der Nachrichtentabelle werden beispielsweise mittels einer eindeutigen ID der Nachricht indiziert, der so genannten MTS-ID (Nachrichtenübertragungsdienst). Benutzer möchten die Daten in den Nachrichtentabellen jedoch möglicherweise in einem benutzerfreundlicheren Format anzeigen.
Die Daten werden über Indizes, oder genauer gesagt über sekundäre Indizes abgerufen. Jeder sekundäre Index ist eine andere B-Struktur, in der der ausgewählte sekundäre Schlüssel dem primären Schlüssel zugeordnet wird. Daher sind B-Strukturen im Verhältnis zu den indizierten Daten relativ klein.
Die Verwendung von sekundären Indizes kann anhand der Vorgänge verstanden werden, die durchgeführt werden, wenn ein Benutzer die Darstellung von Nachrichten in einem Messagingordner ändert. Wenn Sie die Ordneransicht in Outlook so ändern, dass sie nach dem Betreff und nicht nach der Empfangszeit angeordnet ist, wird im Informationsspeicher und in ESE ein neuer sekundärer Index in der Nachrichtenordnertabelle erstellt.
Bei der ersten Änderung der Ansicht eines großen Ordners tritt eine zeitliche Verzögerung auf. Beim Überprüfen des Servers kann eine kleine Spitze in der Festplattenaktivität festgestellt werden. Beim erneuten Wechsel zu dieser Ansicht ist der Index bereits erstellt, und die Reaktion erfolgt viel schneller.
Im Microsoft Exchange-Informationsspeicherdienst werden B-Strukturen für sekundäre Indizes acht Tage gespeichert. Wenn sie nicht verwendet werden, werden sie vom Microsoft Exchange-Informationsspeicherdienst im Hintergrund gelöscht.
LangwerteIn ESE kann sich eine Spalte oder ein Datensatz nicht über mehrere Seiten in der B-Struktur erstrecken. Bei bestimmten Werten (z. B. PR_BODY, der Nachrichtentext einer Nachricht) kann jedoch die 4-KB-Begrenzung einer Seite überschritten werden. Diese werden als Langwerte bezeichnet (LV). In der B-Struktur für Langwerte einer Tabelle werden diese langen Werte gespeichert.
Wenn Daten in eine ESE-Tabelle eingefügt werden und zu groß für die B-Struktur sind, werden sie in 4-KB-Seiten aufgeteilt und in der gesonderten B-Struktur für Langwerte dieser Tabelle gespeichert. Der Datensatz in der B-Struktur für Daten enthält einen Verweis auf den Langwert. Der Verweis wird als Langwert-ID (LID) bezeichnet. Dies bedeutet, dass der Datensatz über einen Verweis auf LID 256 verfügt.
609
DatensatzformatEine Sammlung von B-Strukturen ergibt eine Tabelle. Eine Tabelle besteht wiederum aus einer Reihe von Zeilen. Eine Zeile wird auch als Datensatz bezeichnet. Ein Datensatz setzt sich aus mehreren Spalten zusammen. Die maximale Größe eines Datensatzes und daher die maximale Anzahl der in einem Datensatz angezeigten Spalten wird durch die Größe der Datenbankseite abzüglich der Größe der Kopfzeile festgelegt. ESE-Datenbankseiten haben eine Größe von 4 KB. Daraus ergibt sich eine maximale Datensatzgröße von ca. 4050 Byte (4096 Byte minus Größe der Seitenkopfzeile).
SpaltendatentypenIn jeder Spaltendefinition muss der in der Spalte gespeicherte Datentyp angegeben sein. In ESE werden die in der folgenden Tabelle beschriebenen Datentypen unterstützt.
Spaltendatentypen in ESE (Extensible Storage Engine)
Spaltendatentypen Beschreibung
Bit NULL, 0, oder nicht 0
Unsigned Byte Ganze Zahl ohne Vorzeichen, 1 Byte
Short Ganze Zahl mit Vorzeichen, 2 Byte
Unsigned Short Ganze Zahl ohne Vorzeichen, 2 Byte
Long Ganze Zahl mit Vorzeichen, 4 Byte
Unsigned Long Ganze Zahl ohne Vorzeichen, 4 Byte
LongLong Ganze Zahl mit Vorzeichen, 8 Byte
Currency Ganze Zahl mit Vorzeichen, 8 Byte
IEEE Single Gleitkommazahl, 4 Byte
IEEE Double Gleitkommazahl, 8 Byte
Date Time Datum/Uhrzeit (vollständiges Datum, Uhrzeit mit Dezimalstellen), 8 Byte
GUID Eindeutige ID, 16 Byte
Binary Binäre Zeichenfolge, Länge <= 255
Text ANSI- oder Unicode-Zeichenfolge, Länge <= 255 Byte
Long Binary Binäre Zeichenfolge mit großem Wert, Länge < 2 GB
610
Spaltendatentypen Beschreibung
Long Text ANSI- oder Unicode-Zeichenfolge mit großem Wert, Länge < 2 GB
Die Spaltendatentypen sind in zwei Kategorien unterteilt. Die erste Kategorie enthält feste und variable Spalten. Die zweite Kategorie enthält markierte Spalten. Jede Spalte ist als 16-Byte-FIELD-Struktur definiert, zusätzlich zur Größe des Spaltennamens.
Beim Erstellen einer Tabelle in einer ESE-Datenbank wird diese durch ein Array von FIELD-Strukturen definiert. Mit dem Array werden die einzelnen Spalten in der Tabelle festgelegt. In diesem Array wird jede Spalte durch einen Indexwert dargestellt, der als Spalten-ID bezeichnet wird. Dies entspricht in etwa einem normalen Array, in dem mit einer ID auf Arraymitglieder verwiesen werden kann, z. B. Array[0], Array[1]. Über eine ID kann auf Spalten schnell zugegriffen werden, für eine Suche nach Spaltenname muss jedoch eine lineare Suche im Array der FIELD-Strukturen durchgeführt werden.
Feste und variable SpaltenFeste Spalten weisen eine festgelegte Datenlänge auf. Jeder Datensatz belegt eine festdefinierte Größe an Speicherplatz, selbst wenn kein Wert definiert ist. Die Datentyp-IDs 1 bis 10 können als feste Spalten definiert werden. In jeder Tabelle können bis zu 126 feste Spalten (Spalten-ID 1 bis 127) festgelegt werden.
Variable Spalten können Daten mit einer Größe bis zu 256 Byte enthalten. Ein Offsetarray wird im Datensatz mit dem größten Satz von variablen Spalten gespeichert. Für jede Spalte sind 2 Byte erforderlich. Die Datentyp-IDs 10 und 11 können als variable Spalten definiert werden. In jeder Tabelle können bis zu 127 variable Spalten (Spalten-ID 128 bis 256) festgelegt werden.
Markierte SpaltenIn ESE werden Spalten, die selten oder mehrfach in einem Datensatz auftreten, als markierte Spalten definiert. Eine nicht definierte markierte Spalte belegt keinen zusätzlichen Speicherplatz. Eine markierte Spalte kann im gleichen Datensatz mehrfach vorhanden sein. Wenn eine markierte Spalte in einem sekundären Index vorhanden ist, wird über den Index auf jedes einzelne Vorkommen der Spalte verwiesen.
Markierte Spalten können eine variable und unbegrenzte Datenlänge aufweisen. Die Spalten-ID und die Länge werden mit den Daten gespeichert. Alle Datentypen können als markierte Spalten definiert werden. In jeder Tabelle können bis zu 64.993 markierte Spalten festgelegt werden.
611
Funktionen des InformationsspeichersDie Hauptfunktion des Exchange-Informationsspeichers besteht in der Bereitstellung von Exchange-Datenbanken und der Verwaltung von Transaktionen, sodass andere Dienste und Messagingclients auf Postfächer und Öffentliche Ordner zugreifen können. Der Exchange-Informationsspeicher wird zusätzlich für die Speicherplatzverwaltung (die Verwaltung der physischen Datenbankdateien) und die Pufferverwaltung (die Verwaltung der Speicherverwendung über den Prozess Store.exe) verwendet.
Interaktivität mit anderen Exchange-DienstenFür die Durchführung von Exchange-Standardvorgängen wird der Exchange-Informationsspeicher gemeinsam mit mehreren anderen Diensten verwendet. In der folgenden Tabelle sind die für Exchange-Standardvorgänge wichtigen Dienste aufgeführt. Beachten Sie, dass die auf einem Exchange-Server verfügbaren Dienste von der jeweiligen Konfiguration abhängen.
Wichtige Dienste für Exchange Server 2003-Operationen
Name des Diensts Beschreibung
Distributed Transaction Coordinator Koordination der über mehrere Datenbanken, Nachrichtenwarteschlangen und Dateisysteme verteilten Transaktionen
Ereignisprotokoll Protokollierung der in Exchange Server und anderen Anwendungen ausgegebenen Ereignisinformationen, Warnmeldungen und Fehlermeldungen
IIS-Verwaltungsdienst Verwaltung des virtuellen Exchange-HTTP-Servers im IIS-Snap-In
Microsoft Exchange-Ereignis Überwachung von Ordnern und Auslösen von Ereignissen für Exchange Server 5.5-Anwendungen
Microsoft Exchange IMAP4 Bereitstellung von Exchange IMAP4-Diensten
Microsoft Exchange-Informationsspeicher Verwaltung des Exchange-Informationsspeichers
Microsoft Exchange-MTA-Stacks Bereitstellung von Exchange X.400-Diensten
612
Name des Diensts Beschreibung
Microsoft Exchange POP3 Bereitstellung von Exchange POP3-Diensten
Microsoft Exchange-Routingmodul Verarbeitung der Exchange-Nachrichtenrouting- und Verbindungsstatusinformationen
Microsoft Exchange-Standortreplikationsdienst
Replikation von Exchange-Informationen in der Organisation
Microsoft Exchange-Systemaufsichtsdienst Überwachung von Exchange und Bereitstellung wichtiger Dienste
Network News Transfer Protocol (NNTP) Übertragung von Newsgroup-Nachrichten im Netzwerk
Simple Mail Transfer Protocol (SMTP) Übertragung von E-Mail-Nachrichten im Messagingnetzwerk
WWW-Publishingdienst Bereitstellung von HTTP-Diensten für Exchange Server (Microsoft Outlook Web Access, Microsoft Outlook Mobile Access und Microsoft Exchange ActiveSync) sowie von Internetinformationsdienst (IIS)
SpeicherplatzverwaltungIn einer Datenbankdatei liegen zwei Speicherplatztypen vor: belegter Speicherplatz und verfügbarer Speicherplatz. Jede Tabelle, jeder Index und jede B-Struktur für Langwerte verfügt über jeweils eine Liste mit belegten und verfügbaren Seiten. Der verfügbare Speicherplatz ist eine Liste von Seiten, in denen neue Daten gespeichert werden können. Der verfügbare Speicherplatz ist immer eine Teilmenge des belegten Speicherplatzes.
Belegter Speicherplatz In ESE wird der belegte Speicherplatz in einer Hierarchie mit drei Ebenen verwaltet. Die Ebenen sind der Datenbankstamm, die Tabellen sowie Indizes und Langwerte. Der Datenbankstamm belegt den gesamten Speicherplatz in der Datenbank. Tabellen fordern Speicherplatzblöcke an, die sie dann belegen (die bereits vom Datenbankstamm belegt sind). Strukturen für Indizes und Langwerte fordern Speicherplatz von einer Tabelle an, die wiederum einen Speicherplatzblock im Datenbankstamm belegt. Zur Verringerung der Anforderungen und zur Vermeidung der Fragmentierung des Speicherplatzes werden Anforderungen für mehr Speicherplatz in Blöcken durchgeführt (normalerweise 16 Seiten oder 64 KB).
613
Verfügbarer Speicherplatz Beim verfügbaren Speicherplatz liegen geringfügige Unterschiede vor. Eine Seite kann im Datenbankstamm, auf Tabellenebene oder als Index oder Langwert verfügbar sein. Eine Seite ist jeweils nur auf einer Ebene verfügbar.
DatenbankdefragmentierungBei der Defragmentierung durchläuft ESE die unteren Seiten (die Endknotenseiten) jeder B-Struktur-Datenbank. ESE ermittelt, ob Zeichenfolgen von nebeneinander liegenden Seiten in einer einzelnen Seite zusammengeführt werden können. Dadurch werden Seiten freigegeben, die dann an den verfügbaren Speicherplatz der Tabelle zurückgegeben werden. Ort und Angrenzung von zusammengehörigen Seiten in der Datenbankdatei werden nach Möglichkeit optimiert.
Die Defragmentierung kann auf zwei Arten ausgeführt werden:
Onlinedefragmentierung Wird als Bestandteil der Systemwartung ausgeführt, die in der Standardeinstellung zwischen 01:00 Uhr und 06:00 Uhr durchgeführt wird. Wenn mit ESE keine vollständige Defragmentierung der Datenbank durchgeführt werden kann, wird der Vorgang beim nächsten Wartungsfenster des Exchange-Informationsspeichers an dem Punkt fortgesetzt, an dem er zuvor beendet wurde.
Die Onlinedefragmentierung weist die folgenden Einschränkungen auf:
Freier Speicherplatz in der Datenbankdatei (EDB-Datei) wird nicht an das Dateisystem zurückgegeben. Stattdessen wird nach Abschluss der Onlinedefragmentierung vom Microsoft Exchange-Informationsspeicherdienst ein Ereignis im Anwendungsereignisprotokoll verzeichnet (Ereignis-ID 1221), mit dem der verfügbare freie Speicherplatz in der Datenbank angegeben wird. Der freie Speicherplatz wird bei Bedarf verwendet, bevor sich die physische Datenbankdatei vergrößert.
Der verfügbare Speicherplatz in einer Datenbank liegt in Form einer Liste von Seiten vor, die zum Speichern von neuen Daten verwendet werden können. Der verfügbare Speicherplatz wird als Speicherstruktur bezeichnet. Die Speicherstruktur wird als B-Struktur gespeichert und immer dann durchsucht, wenn ein neuer Datenblock in die Datenbank eingefügt werden soll. Speicherstrukturen werden während einer Onlinedefragmentierung nicht entfernt und bleiben fragmentiert, bis eine Offlinedefragmentierung durchgeführt wird.
Gelöschte Spalten-IDs und Langwert-IDs werden nicht wiederverwertet.
Sekundäre Indizes werden neu angeordnet, jedoch nicht neu erstellt (aufgetretene Indexfehler werden nicht behoben).
Die vertikale Zusammenführung wird in der Datenbankdatei (EDB-Datei) nicht unterstützt (Strukturebenen werden nicht reduziert).
614
Offlinedefragmentierung Ein durch einen Administrator durchgeführter Vorgang, bei dem das Dienstprogramm ESEUTIL für die entsprechenden Datenbanken ausgeführt wird. Eseutil.exe ist ein Befehlszeilenprogramm und befindet sich im Verzeichnis \Programme\Exchsrvr\Bin.
Hinweis: Wenn ein Postfachspeicher oder ein Informationsspeicher für Öffentliche Ordner bereitgestellt wird, während über ESEUTIL.exe die zugehörigen Datenbanken defragmentiert werden, wird der Fehlercode -1032 (JET_errFileAccessDenied) zurückgegeben. Führen Sie vor und nach der Offlinedefragmentierung von Datenbanken eine vollständige Sicherung durch.
PufferverwaltungEin Entwurfsgrundsatz von ESE besteht darin, Festplattenzugriffe zu vermeiden. Dazu wird in ESE eine umfassende Pufferverwaltung verwendet. Über die Pufferverwaltung werden die folgenden beiden Aufgaben ausgeführt:
Festlegung der Speichergröße für den Puffercache. Dies wird über eine interne Funktion zur dynamischen Pufferzuweisung (Dynamic Buffer Allocation, DBA) ausgeführt.
Definition der Seiten, die im Puffercache bleiben. Diese Festlegung wird über einen Algorithmus mit dem Namen LRU-K getroffen.
Dynamic Buffer Allocation (DBA)Dynamic Buffer Allocation (DBA), eine erstmals in Exchange Server 5.5 verwendete Funktion, hat sich zu einem wichtigen Faktor bei der Speicherverwendung im Microsoft Exchange-Informationsspeicherdienst entwickelt. Der Status des Caches wird mit ESE konstant überwacht. Die Systemanforderungen werden überprüft und gegebenenfalls Änderungen an der Cachegröße vorgenommen.
In DBA werden vier Regeln zur Anpassung der Cachegröße angewendet:
Je mehr Arbeitsspeicher zur Verfügung steht, desto schneller wächst die Arbeitsseite des Exchange-Informationsspeichers.
Je mehr Cachespeicherplatz verfügbar ist, desto schneller wird die Arbeitsseite des Exchange-Informationsspeichers reduziert.
Je höher die Speicherplatzauslastung ist, desto schneller wächst die Arbeitsseite des Exchange-Informationsspeichers.
Je höher die verfügbare Speicherplatzauslastung ist, desto schneller wird die Arbeitsseite des Exchange-Informationsspeichers reduziert.
615
Bei DBA wird mit einer patentierten Formel festgelegt, auf welche Weise der Puffercache vergrößert oder verkleinert werden soll.
Der LRU-K-ErsetzungsalgorithmusMit DBA wird die Größe des Puffers verwaltet. Mit der Zeit füllt sich der Puffer mit zwischengespeicherten Datenbankseiten. Um Speicherplatz für weitere Seiten freizugeben, müssen ältere Seiten im Cache entfernt werden. Mit DBA wird ein Verfahren bereitgestellt, mit dem festgelegt wird, welche Seiten im Cache bleiben. In Datenbanksystemen wird in der Regel der LRU-Algorithmus (Least Recently Used) verwendet, der zuerst 1998 von Denning beschrieben wurde (P. J. Denning, Resource Allocation In Multiprocess Computer Systems, Massachusetts Institute of Technology, Cambridge, MA, 1968). Wenn Speicherplatz im Puffer freigegeben werden soll, wird über LRU die Seite im Puffer entfernt, auf die am längsten nicht mehr zugegriffen wurde.
Der LRU-Algorithmus hat jedoch einen Schwachpunkt. Die Festlegung, welche Seite im Arbeitsspeicher entfernt wird, erfolgt nur anhand des Zeitpunkts des letzten Verweises. Insbesondere kann über LRU nicht zwischen Seiten, auf die relativ häufig verwiesen wird, und Seiten unterschieden werden, auf die sehr selten verwiesen wird. Auf eine Seite wurde beispielsweise 100 Mal zugegriffen, während auf die nachfolgende Seite nur einmal zugegriffen wurde. Aufgrund der LRU-Vorgabe wird die Seite entfernt, auf die 100 Mal zugegriffen wurde, unabhängig davon, ob die Seite häufiger verwendet wird als die andere nur einmal aufgerufene Seite.
Zur Optimierung der Festplattenpufferung von Datenbanken wurde 1993 der LRU-K-Algorithmus eingeführt (Elizabeth J. O'Neil, Patrick E. O'Neil, Gerhard Weikum, The LRU-K Page Replacement Algorithm For Database Disk Buffering. SIGMOD Conference 1993). Mit diesem Algorithmus werden konventionelle Pufferungsalgorithmen erweitert, indem zwischen Seiten unterschieden wird, auf die häufig und weniger häufig verwiesen wird. In Exchange Server 2003 wird der LRU-K-Algorithmus verwendet.
Mit dem LRU-K-Algorithmus wird die Anzahl der letzten K-Verweise auf Seiten im Arbeitsspeicher ermittelt (in ESE ist der Standardwert für K auf 2 gesetzt). Anhand dieser statistischen Daten wird die Reihenfolge der Seiten in Bezug auf die zu erwartende künftige Verwendung festgelegt. Mit den statistischen Angaben kann in ESE festgelegt werden, welche Seite im Arbeitsspeicher entfernt wird, um so Platz für neu aufgerufene Seiten freizugeben. Da die statistischen Angaben zu den Seiten, auf die verwiesen wird, permanent erfasst werden, erfolgt mit dem LRU-K-Algorithmus eine Anpassung an die geänderten Zugriffsmuster in Echtzeit. Der Algorithmus ist relativ einfach und erfordert wenig zusätzlichen Aufwand. Für jede Seite werden mindestens die beiden letzten Verweise verwendet, in der Regel die letzten K-Verweise (wobei K größer oder gleich 2 ist), um festzulegen, welche Seite entfernt wird.
616
Replikation von Öffentlichen OrdnernDer Stamm einer Struktur für Öffentliche Ordner, wie er im Exchange-System-Manager angezeigt wird, wird als Hierarchie auf oberster Ebene bezeichnet. In Exchange Server 2003 können mehrere Hierarchien auf oberster Ebene vorliegen. Die Hierarchie auf oberster Ebene für Öffentliche Ordner (auch als MAPI-Hierarchie auf oberster Ebene bezeichnet) ist nur eine von vielen Strukturen für Öffentliche Ordner. Mit der MAPI-Hierarchie auf oberster Ebene in Exchange Server 2003 werden die gleichen Aufgaben ausgeführt, die in früheren Versionen von Exchange ausgeführt wurden. Darüber hinaus werden Exchange 2000- und Exchange 5.5-Strukturen für Öffentliche Ordner repliziert. In Exchange Server 2003 werden zudem zusätzliche Strukturen unterstützt, die im Allgemeinen als Anwendungshierarchien auf oberster Ebene bezeichnet werden. Jeder Hierarchie auf oberster Ebene ist ein Eintrag im Verzeichnis zugeordnet. Der Eintrag enthält einen Rückverweis auf die definierten Namen (DN – Distinguished Name) aller Öffentlichen Informationsspeicher in der Hierarchie auf oberster Ebene. Die MAPI-Hierarchie auf oberster Ebene wird im Verzeichnis unter der ersten administrativen Gruppe in der Exchange-Organisation gesichert.
Auf einem Server kann nur eine Datenbank der Informationsspeicher für Öffentliche Ordner mit einer Hierarchie auf oberster Ebene gespeichert werden. Für Aktiv/Aktiv-Cluster bedeutet dies, dass auf beiden virtuellen Exchange-Servern nur eine Instanz einer Datenbank mit einer Hierarchie auf oberster Ebene vorhanden sein kann, da die beiden virtuellen Exchange-Server auf dem gleichen physischen Knoten ausgeführt werden. In Exchange Server 2003 Service Pack 1 wird nun die Speicherung von mehr als einer Instanz einer Struktur für Öffentliche Ordner in einem Aktiv/Passiv-Cluster unterstützt, da ein physischer Knoten nur als Host für einen virtuellen Exchange-Server verwendet werden kann.
Datenbankstrukturen für Öffentliche OrdnerDie Datenbank für Öffentliche Ordner ist in zwei Strukturen unterteilt: IPM_Subtree und Non-IPM_Subtree. IPM_Subtree enthält Ordner, die für Benutzer und Clients sichtbar sind. Ein in Microsoft Outlook erstellter Ordner ist beispielsweise in IPM_Subtree vorhanden. Ein Ordner in IPM_Subtree kann durchsucht, von Benutzern direkt geöffnet und zum Speichern von Benutzerdaten verwendet werden. Non-IPM_Subtree enthält Ordner, auf die Benutzer nicht direkt zugreifen können. Die Ordner in Non-IPM_Subtree werden auf genau die gleiche Weise repliziert wie die Ordner in IPM_Subtree, sie können jedoch nicht von Benutzern direkt bearbeitet werden.
Non-IPM_Subtree enthält die folgenden Ordner:
Standortordner: Dazu zählen beispielsweise die folgenden Ordner: SCHEDULE+ FREE BUSY, Ereignisregistrierung, MAPI-Formulare und Offlineadressliste.
Einschränkungen: Diese Ordner werden nicht repliziert.
Ansichten: Diese Ordner werden nicht repliziert.
617
Standortordner sind beim Anzeigen der Systemordner im Exchange-System-Manager sichtbar. Standortordner werden auf die gleiche Weise repliziert wie normale Ordner. Die zugehörigen Replikationslisten können auf die gleiche Weise geändert werden wie gewöhnliche Öffentliche Ordner. Der erste Server in einer administrativen Gruppe, auf dem Exchange Server 2003 ausgeführt wird, enthält Kopien von Offlineadresslisten, Frei/Gebucht-Daten und Replikate von anderen Standortordnern. Der Speicherort dieser Ordner (d. h., der Informationsspeicher für Öffentliche Ordner, der diese Ordner enthält) kann im Exchange-System-Manager geändert werden. Jede administrative Gruppe verfügt über einen Standortordnerserver (der erste Server im Standort), der als Attribut für den Verzeichniseintrag der administrativen Gruppe gespeichert ist. Durch diesen Server wird sichergestellt, dass Standortordner vorhanden sind.
ReplikationsüberblickBei der Replikation von Öffentlichen Ordnern handelt es sich um die Übertragung von Daten in Öffentlichen Ordnern zwischen Informationsspeichern für Öffentliche Ordner in der gleichen Hierarchie auf oberster Ebene. Die Übertragung erfolgt über ein E-Mail-basiertes Replikationsmodul. Der Vorgang ist bei MAPI-Hierarchien auf oberster Ebene und Anwendungshierarchien auf oberster Ebene identisch. Die Ordnerhierarchie wird über Hierarchiereplikationsnachrichten und der Inhalt von Ordnern über Inhaltsreplikationsnachrichten zwischen Replikaten einzelner Ordner repliziert. Die Replikation zwischen Informationsspeichern wird zusätzlich durch Abgleichanfragen und Antwortnachrichten sowie durch Statusnachrichten und Statusanforderungsnachrichten synchronisiert.
Hinweis: Ordner werden im Informationsspeicher intern mit einer Ordner-ID (Folder ID, FID) adressiert. Hierbei handelt es sich um eine hexadezimale ID, z. B. 1-2A45. Eine FID ist eine Zeile in der Ordnertabelle im Informationsspeicher für Öffentliche Ordner. Auf Nachrichten wird auf ähnliche Weise über eine Nachrichten-ID (MID – Message ID) verwiesen. Hierbei handelt es sich um eine Zeile in der Tabelle MsgFolder. Hierarchiereplikationsnachrichten sind beispielsweise eine spezielle Art von Inhaltsreplikationsnachrichten für einen Ordner mit der ID 1-1.
Bei der Replikation werden Standardtransporte zum Senden von Replikationsnachrichten an andere Informationsspeicher für Öffentliche Ordner verwendet. Wenn eine Aktualisierung an mehrere Informationsspeicher für Öffentliche Ordner übertragen werden muss, wird nur eine Replikationsnachricht erzeugt, die auf alle Informationsspeicher für Öffentliche Ordner verweist. Das heißt, sie verweist auf die Replikatliste für den Ordner, da in einer Hierarchie nur die Replikatliste im Informationsspeicher für Öffentliche Ordner auf oberster Ebene gespeichert wird. Die Nachricht muss mit dem SMTP-Transportmodul kategorisiert und unterteilt werden, sodass sie anschließend an jeden einzelnen Informationsspeicher für
618
Öffentliche Ordner gesendet werden kann. Weitere Informationen zum Kategorisieren und Verzweigen von Nachrichten finden Sie unter SMTP-Transportarchitektur.
Die Replikation von Öffentlichen Ordnern ist E-Mail-basiert. Bei Replikationsnachrichten handelt es sich um E-Mail-Nachrichten, die zwischen Informationsspeichern für Öffentliche Ordner auf oberster Ebene gesendet werden. Aus diesem Grund muss zwischen den einzelnen Informationsspeichern für Öffentliche Ordner ein Pfad definiert sein. Dadurch wird die Replikation ermöglicht.
Ordner werden durch Senden von E-Mail-Nachrichten zwischen Informationsspeichern für Öffentliche Ordner repliziert. Daher sind für Informationsspeicher für Öffentliche Ordner E-Mail-Adressen erforderlich, die über den Empfängeraktualisierungsdienst hinzugefügt werden.
Packen und EntpackenDer Vorgang, bei dem Replikationsdaten in die Replikationsnachricht eingefügt werden, wird als Packen bezeichnet. Der Vorgang, bei dem die Replikationsdaten in der Replikationsnachricht abgerufen werden, wird als Entpacken bezeichnet. Mehrere Hierarchieaktualisierungen und mehrere Inhaltsaktualisierungen für den gleichen Ordner können jeweils in eine Replikationsnachricht gepackt werden. Dadurch wird der E-Mail-Datenverkehr reduziert, da eine Nachricht mehrere Aktualisierungen enthalten kann (d. h., es liegen weniger Nachrichtenumschläge und -kopfzeilen vor). Hierarchieaktualisierungen und Inhaltsaktualisierungen sowie Inhaltsaktualisierungen für unterschiedliche Ordner können nicht in die gleiche Replikationsnachricht gepackt werden.
ÄnderungsnummernAllen Aktualisierungen (Erstellen, Löschen und Ändern) werden Änderungsnummern zugewiesen. Änderungsnummern werden im Replikationsmodul zum Verfolgen von Aktualisierungen verwendet. Jeder Änderung an einem Ordner ist eine Änderungsnummer zugeordnet. Bei der Replikation von Aktualisierungen auf einem anderen Server werden die Änderungsnummern für die entsprechenden Änderungen in die Aktualisierung eingefügt. Anhand der Änderungsnummern wird dann auf dem empfangenden Server ermittelt, ob es sich um eine neue Änderung handelt. Die Replikationsnachricht enthält auch eine Kopie des vollständigen Satzes mit Änderungsnummern, die im Ordner auf dem sendenden Server vorhanden sind, sodass auf dem empfangenden Server festgestellt werden kann, ob Änderungen fehlen. Ein Satz mit Änderungsnummern wird als CNset (Change Numbers Set – Änderungsnummernsatz) bezeichnet.
619
ReplikationsnachrichtentypenEs liegen die folgenden sechs Replikationsnachrichtentypen vor: Hierarchiereplikationsnachrichten (die Inhaltsreplikation von FID 1-1), Inhaltsreplikationsnachrichten (Inhaltsreplikation zwischen mehreren Ordnerreplikaten), Abgleichanfragenachrichten, Abgleichantwortnachrichten, Statusnachrichten und Statusanforderungsnachrichten. Alle Nachrichtentypen werden in der folgenden Tabelle beschrieben.
Replikationsnachrichtentypen
Nachrichtentyp Beschreibung Verwendung
Hierarchiereplikationsnachricht (0x2)
Eine Hierarchiereplikationsnachricht ist eine Replikationsnachricht zwischen Replikaten eines speziellen Ordners mit der ID 1-1 (FID 1-1).
Repliziert Hierarchieänderungen von einem Informationsspeicher für Öffentliche Ordner in alle anderen Informationsspeicher für Öffentliche Ordner in derselben Hierarchie auf oberster Ebene.
Inhaltsreplikationsnachricht (0x4)
Mit Inhaltsreplikationsnachrichten werden Inhaltsaktualisierungen zwischen Replikaten einzelner Ordner repliziert. Ein Informationsspeicher für Öffentliche Ordner sendet eine Inhaltsreplikation nur an einen anderen Informationsspeicher für Öffentliche Ordner, der Replikate des Ordners enthält.
Repliziert Inhaltsänderungen von einem Replikat in allen anderen Inhaltsreplikaten des Ordners.
620
Nachrichtentyp Beschreibung Verwendung
Abgleichanfragenachricht (0x8)
Beim Abgleichvorgang können Informationsspeicher für Öffentliche Ordner mit fehlenden Replikationsaktualisierungen eine Anforderung zum erneuten Senden der fehlenden Daten senden. Der Abgleichvorgang ist in zwei Phasen unterteilt: Abgleichanfrage und Abgleichantwort. Wenn ein nicht synchronisierter Informationsspeicher für Öffentliche Ordner ermittelt wird, wird eine Abgleichanfrage gesendet, da eine Inkonsistenz im CNSet eines Ordners im Vergleich mit dem CNSet in einer kürzlich empfangenen Replikationsnachricht festgestellt wurde. Dies erfolgt durch eine Replikation oder durch von anderen Informationsspeichern für Öffentliche Ordner gesendete Statusnachrichten.
Mit Abgleichanfragenachrichten werden fehlende Daten (in CNSets) von einem anderen Informationsspeicher für Öffentliche Ordner (Hierarchie und Inhalt) angefordert. Abgleichanfragenachrichten werden nur an andere Inhaltsreplikate des Ordners gesendet (an alle Mitglieder der Hierarchie auf oberster Ebene bei der Hierarchie).
621
Nachrichtentyp Beschreibung Verwendung
Abgleichantwortnachrichten (0x80000002 oder 0x80000004)
Abgleichantworten entsprechen in ihrer Struktur regulären Antworten, werden jedoch als Reaktion auf Abgleichanfragen gesendet und sind nur an den Anforderer adressiert. Sie enthalten die angeforderten Änderungen. Auf eine Anforderung können mehrere Antworten gesendet werden, wenn die angeforderten Daten zu groß für eine Antwort sind. Eine Antwortnachricht kann auch keinerlei Daten enthalten.
In Abgleichantwortnachrichten werden fehlende Daten an den Informationsspeicher für Öffentliche Ordner gesendet, über den fehlende Aktualisierungen (CNSets) angefordert wurden.
622
Nachrichtentyp Beschreibung Verwendung
Statusnachrichten (0x10) Eine Statusnachricht wird als Reaktion auf eine Statusanforderung gesendet. Sie enthält den vollständigen CNSet der Änderungen auf dem entsprechenden Server. Damit werden nicht zwangsläufig alle tatsächlich vorgenommenen Änderungen gesendet, da nicht alle Änderungen in diesem bestimmten Informationsspeicher für Öffentliche Ordner repliziert wurden.
In Versionen vor Exchange 2000 Server wurden Statusnachrichten für alle Ordner im Informationsspeicher für Öffentliche Ordner alle 24 Stunden übertragen. Dies führte zu einer Überlastung des Netzwerks. Daher ist diese Übertragung in regelmäßigen Abständen in Exchange 2000 Server nicht mehr vorhanden.
Sendet die aktuellen CNSets eines Ordners an andere Replikate des Ordners. Wird für Hierarchie- (Replikate von Ordner 1-1) und Inhaltsaktualisierungen (bestimmte Inhaltsreplikate) verwendet.
Statusanforderungsnachricht (0x20)
Sendet den aktuellen CNSet eines Ordners an alle anderen Replikate. Gleichzeitig wird angefordert, dass einige dieser Replikate den entsprechenden CNSet zurückgeben. Die Antwort wird in einer Statusnachricht gesendet. Der angeforderte Server reagiert nicht, wenn der CNSet des anfordernden
Im Exchange-Informationsspeicher wird in folgenden Fällen eine Statusanforderungsnachricht gesendet:
In einem vorhandenen Replikat eines Öffentlichen Ordners fehlen möglicherweise Replikationsnachrichten, oder sie wurden von einer veralteten
623
Nachrichtentyp Beschreibung Verwendung
Servers kein exakter untergeordneter Satz des Satzes auf dem angeforderten Server ist.
Sicherung wiederhergestellt. Von einem Informationsspeicher für Öffentliche Ordner wird eine Statusanforderungsnachricht an einen anderen Informationsspeicher für Öffentliche Ordner gesendet, um zu ermitteln, ob lokale Änderungen fehlen.
Ein neues Replikat eines Öffentlichen Ordners wurde zum Informationsspeicher für Öffentliche Ordner hinzugefügt. Ein neues Replikat eines Ordners erzeugt eine Statusanforderung für den Inhalt.
Ein neuer Informationsspeicher für Öffentliche Ordner wurde erstellt und einer bestimmten Hierarchie für Öffentliche Ordner zugeordnet. Ein neuer Informationsspeicher für Öffentliche Ordner erzeugt eine Statusanforderung für die Hierarchie, da ein neuer Hierarchieordner (FID 1-1) erstellt wurde.
Ein vorhandenes Replikat eines Öffentlichen Ordners
624
Nachrichtentyp Beschreibung Verwendung
wurde im Informationsspeicher für Öffentliche Ordner entfernt. Ein entfernter Öffentlicher Ordner erzeugt ebenfalls eine Statusanforderung, da der Inhalt des Hierarchieordners (FID 1-1) geändert wurde.
ReplikationsvorgangInformationsspeicher für Öffentliche Ordner senden über E-Mail Replikationsnachrichten an andere Informationsspeicher. Aus diesem Grund muss zwischen den einzelnen Informationsspeichern für Öffentliche Ordner ein Pfad definiert sein, damit die Replikationsnachrichten empfangen werden können. Im Prozess Store.exe wird fortlaufend ein Thread ausgeführt, mit dem Replikationsereignisse gesucht werden. Replikationsereignisse treten in bestimmten Zeitintervallen auf. Beim Auftreten eines Ereignisses wird mit dem Replikationsthread ein neuer Thread erzeugt, mit dem die spezielle Replikationsaufgabe ausgeführt wird. In der folgenden Aufstellung werden die Standardzeitintervalle für Replikationsereignisse dargestellt:
Hierarchiereplikationsereignisse treten alle 5 Minuten auf.
Inhaltsreplikationsereignisse treten alle 15 Minuten auf.
Eine Statusnachricht wird 24 Stunden nach der letzten regulären Replikationsübertragung übermittelt.
HierarchiereplikationBei jeder Änderung der Hierarchie wird eine Hierarchiereplikationsnachricht erstellt. Im Folgenden sind verschiedene Hierarchieänderungen aufgeführt:
Erstellen, Löschen oder Umbenennen eines Ordners
Ändern von Ordnerberechtigungen oder -beschreibungen
Ändern des Replikationszeitplans und der Prioritätseinstellungen
Hinzufügen von Inhalt zu oder Entfernen von Inhalt in einem Ordner
Ändern von Replikatlisten
625
Verschieben eines Ordners in der Hierarchie
In Abbildung 10.5 wird der Hierarchiereplikationsvorgang dargestellt.
Hierarchiereplikationsvorgang
In dieser Abbildung werden Server A die Ordner 1, Ordner 2 und Ordner 3 hinzugefügt. Die Hierarchieänderungen auf Server A werden dann auf Server B repliziert, sodass auf Server B die Öffentlichen Ordner in der Hierarchie erkannt werden. Benutzer auf Server B können nun durch die Hierarchie navigieren und einen der Ordner auswählen, der Inhalt der Öffentlichen Ordner ist jedoch nur auf Server A gespeichert. Beim Zugriff auf Ordner 1, Ordner 2 oder Ordner 3 werden Clients von Server B auf Server A weitergeleitet. Server A gibt den Inhalt an den Client zurück, und der Inhalt kann auf dem Client angezeigt werden. Der Weiterleitungsvorgang ist für den Benutzer transparent.
InhaltsreplikationDer Ordnerinhalt wird zwischen den einzelnen Replikaten der Ordner repliziert. Bei einer Änderung des Ordnerinhalts wird die Änderung mit Änderungsnummern protokolliert. Beim Erreichen des Replikationsintervalls werden die Änderungen in allen anderen Informationsspeichern für Öffentliche Ordner repliziert, die Replikate des Ordners enthalten.
In der folgenden Abbildung wird der Inhaltsreplikationsvorgang dargestellt.
Inhaltsreplikationsvorgang
626
In dieser Abbildung wird Objekt 1 in einen Ordner auf Server A weitergeleitet, der über ein Replikat auf Server B verfügt. Der Informationsspeicher für Öffentliche Ordner auf Server A repliziert die Änderung in den Informationsspeicher für Öffentliche Ordner auf Server B. Objekt 2 und 3 werden auf die gleiche Weise weitergeleitet und repliziert.
AbgleichvorgangOrdner bleiben während des gesamten Abgleichvorgangs synchronisiert. Ordner werden nur abgeglichen, wenn Inhalte in den Ordnern fehlen. Daher muss zuerst ermittelt werden, ob eine Aktualisierung in einem Ordner fehlt. Erst dann wird eine Abgleichanfrage gesendet. Dies erfolgt durch Ermitteln einer fehlenden Sequenz in den CNSets von einzelnen Ordnern.
Inhaltsabgleich und Hierarchieabgleich werden auf die gleiche Weise verwendet. Wenn die CNSets für Ordner 1-1 eine Lücke aufweisen, wird ein Hierarchieabgleich gesendet. Bei Lücken in allen anderen Ordnern wird ein Inhaltsabgleich gesendet.
Der Abgleichvorgang kann lange Zeit in Anspruch nehmen, vor allem wenn ein Informationsspeicher für Öffentliche Ordner nicht reagiert sowie die ursprüngliche Replikationsaktualisierung und die nachfolgende Statusnachricht nicht gespeichert wurden. Möglicherweise wird erst erkannt, dass Inhalte fehlen, wenn weitere Replikationsnachrichten empfangen werden.
AbgleicharrayIm Abgleicharray werden ausstehende Abgleichanfragen gespeichert. Wenn in einem Informationsspeicher für Öffentliche Ordner ermittelt wird, dass ein Ordner nicht synchronisiert ist, wird ein Eintrag in das Abgleicharray geschrieben. Dieser Eintrag ist eine ausstehende Anforderung für die fehlenden Daten von einem anderen Replikat des Ordners. Der Eintrag bleibt im Abgleicharray, bis das entsprechende Timeout überschritten ist. Dann wird die Abgleichanfrage gesendet. In der folgenden Tabelle sind die Standardabgleichtimeouts aufgeführt.
Standardabgleichtimeouts
Abgleiche Standortintern Standortübergreifend
Erster Abgleich 6 Stunden 12 Stunden
Erste Abgleichwiederholung 12 Stunden 24 Stunden
Nachfolgende Abgleichwiederholungen
24 Stunden 48 Stunden
Wenn die erste Abgleichanfrage nicht beantwortet wird, werden die nachfolgenden Abgleichanfragen erst nach Ablaufen einer längeren Zeitspanne gesendet. Der Zeitraum wird
627
verlängert, um unnötige Abgleichvorgänge zu vermeiden. Möglicherweise wird die Replikationsnachricht noch übertragen, ist verzögert oder wird an den Zeitplan des Connectors angepasst. Wenn der Abgleichtimeout zu kurz ist, senden die Informationsspeicher für Öffentliche Ordner Abgleichanfragen für Nachrichten, die bereits übertragen werden.
ReplikationsstatusEs gibt zwei Kategorien von Statusnachrichten: Statusanforderungen und Statusnachrichten. Eine Statusanforderungsnachricht wird von einem Informationsspeicher für Öffentliche Ordner an einen anderen Informationsspeicher gesendet, um den aktuellen Status eines bestimmten Ordners im anderen Informationsspeicher für Öffentliche Ordner abzufragen. Eine Statusnachricht wird von einem Informationsspeicher für Öffentliche Ordner an einen anderen gesendet, um den aktuellen Status eines bestimmten Ordners auf dem sendenden Server anzugeben. Wenn in der Statusnachricht angegeben ist, dass im sendenden Informationsspeicher für Öffentliche Ordner aktuellere Informationen über den entsprechenden Ordner vorliegen, wird im empfangenden Informationsspeicher ein Eintrag in das Abgleicharray für die Anforderung eines Abgleichs geschrieben. Wenn gleiche CNSets angezeigt werden (oder der empfangende Server aktuellere Daten aufweist), wird kein weiterer Vorgang durchgeführt.
Statusnachrichten werden von Informationsspeichern für Öffentliche Ordner in den folgenden beiden Fällen gesendet:
Als Reaktion auf eine Statusanforderung: Wenn in einem Informationsspeicher für Öffentliche Ordner eine Statusanforderung von einem anderen Informationsspeicher für Öffentliche Ordner empfangen wurde, wird eine Statusnachricht zurückgegeben. Dies erfolgt bei Änderungen der Replikatliste von Ordnern (z. B. beim Entfernen eines Ordners auf einem Server).
24 Stunden nach der letzten lokalen Änderung eines Ordners: Hierbei handelt es sich um eine erhebliche Änderung im Vergleich mit früheren Versionen von Exchange. Wenn in einem Ordner eine Änderung vorgenommen wurde, wird für diesen Ordner eine Ablaufzeit für Statusnachrichten festgelegt. Bei einer anderen Änderung im gleichen Ordner wird die Ablaufzeit auf 24 Stunden zurückgesetzt.
Nach dem Überschreiten der Ablaufzeit wird für den Ordner eine Statusnachricht ausgegeben. Anschließend wird die Ablaufzeit gelöscht. Für den Ordner werden erst bei einer neuen Änderung wieder Statusnachrichten ausgegeben. Die Ablaufzeit wird dann wieder auf 24 Stunden zurückgesetzt.
ReplikationsstatusthreadDer Thread, mit dem festgelegt wird, ob eine Statusnachricht gesendet wird, wird in der Standardeinstellung um 12:15 Uhr und 00:15 Uhr GMT (Greenwich Mean Time) ausgeführt.
628
Bei der Ausführung wird überprüft, ob der Timeout für Ordner erreicht wurde. Wenn dies der Fall ist, wird eine Statusnachricht gesendet. Daher wird eine Statusnachricht möglicherweise erst nach 36 Stunden erzeugt, wenn keine Änderungen vorgenommen wurden.
Die Zeitsteuerung des Replikationsstatusthreads kann mit den folgenden Registrierungseinstellungen geändert werden:
Replication Send Status Timeout
Replication Send Status Alignment
Replication Send Status Alignment Skew
Aufgrund der reduzierten Anzahl der in Exchange Server 2003 gesendeten Statusnachrichten sollte es nicht erforderlich sein, die Standardwerte zu ändern. Weitere Informationen zu diesen Einstellungen finden Sie im Microsoft Knowledge Base-Artikel 203170, „XADM: Controlling Public Folder Hierarchy Status Messages“.
ReplikationsstatusanforderungenEine Statusanforderung wird gesendet, wenn ein Informationsspeicher für Öffentliche Ordner den Status eines Remoteservers für einen bestimmten Ordner anfordert. Je nach Einzelfall wird durch eine Statusanforderung möglicherweise die Rückgabe einer Statusnachricht ausgelöst.
Eine Statusanforderung wird in den folgenden Fällen erstellt:
Erste Bereitstellung eines neuen Informationsspeichers für Öffentliche Ordner: Bei der ersten Bereitstellung eines Informationsspeichers für Öffentliche Ordner wird eine Hierarchiestatusanforderung für Ordner 1-1 erzeugt. (Diesem Informationsspeicher für Öffentliche Ordner können keine Inhaltsreplikate zugewiesen werden, sodass nur Hierarchieangaben fehlen können.) Dadurch sendet ein anderer Informationsspeicher für Öffentliche Ordner eine Statusnachricht zur Hierarchie, was wiederum dazu führt, dass mehrere Einträge zum Abgleicharray des neuen Servers hinzugefügt werden. Nur kurze Zeit später werden Abgleichanfragen für die fehlenden Änderungen gesendet. Dadurch werden Replikationsnachrichten mit den fehlenden Aktualisierungen von anderen Servern gesendet.
Änderung der Replikatliste eines Ordners: Wenn sich die Replikatliste eines Ordners ändert, wird eine Statusanforderungsnachricht erstellt. Statusanforderungen werden durch Hinzufügen eines neuen Replikats, Löschen eines Replikats oder temporäres Speichern eines Replikats erzeugt.
Wiederherstellung einer Datenbank für Öffentliche Informationsspeicher von einer Sicherung: Wenn sich eine wiederhergestellte Datenbank für unbestimmte Zeit außerhalb der Replikationsschleife befindet, wird eine Statusanforderung für die Hierarchie und alle Inhaltsreplikate in der Hierarchie gesendet. Mit dieser Anforderung werden zwei Vorgänge durchgeführt. Alle anderen Server empfangen die geänderten
629
Änderungsnummerinformationen des Servers. In der neuen wiederhergestellten Datenbank wird eine hohe Anzahl von Aktualisierungen der Änderungsnummerinformationen ausgeführt. Dadurch werden die Abgleicheinträge gefüllt und schließlich die Abgleichanfragen gesendet.
Ändern der ReplikatlisteBeim Ändern der Replikatliste werden Änderungen an der Hierarchie vorgenommen. Da sich die Replikatliste ändert (Ordnerreplikate werden auf einem Server erstellt oder entfernt), werden auch Statusnachrichten und Statusanforderungen gesendet.
Hinzufügen eines ReplikatsBeim Hinzufügen eines neuen Replikats zu einem Ordner werden die folgenden Schritte ausgeführt:
1. Zum Replizieren der Änderung in einer Replikatliste eines Ordners wird eine Hierarchiereplikationsnachricht gesendet.
2. Der als neues Replikat hinzugefügte Server sendet eine Statusanforderungsnachricht an alle anderen Inhaltsreplikatsserver.
3. Da der neu hinzugefügte Server über einen leeren CNSet verfügt, handelt es sich um eine genaue Teilmenge aller CNSets der anderen Inhaltsreplikate, sodass alle mit einer Statusnachricht antworten.
4. Abgleicheinträge werden eingegeben, und Abgleichanfragen werden an die entsprechenden Server gesendet. Die Server reagieren mit Inhaltsnachrichten.
5. Zu einem beliebigen Zeitpunkt nach Schritt 1 können andere Inhaltsreplikate reguläre Inhaltsreplikationsübertragungen an den neuen Replikatsserver senden.
Schritt 1 und 2 werden möglicherweise nicht immer in der gleichen Reihenfolge ausgeführt, sondern hängen davon ab, in welchem Informationsspeicher für Öffentliche Ordner die ursprüngliche Änderung vorgenommen wurde. Wenn der Administrator Änderungen auf einem Server mit Inhaltsreplikaten vornimmt, werden die Schritte in der oben beschriebenen Reihenfolge ausgeführt. Wenn der Administrator Änderungen auf einem Server mit neuen Replikaten vornimmt, werden Schritt 1 und 2 möglicherweise in anderer Reihenfolge ausgeführt.
Löschen eines ReplikatsBeim Entfernen eines Replikats auf einem Server wird der Ordner nicht unmittelbar gelöscht. Der Ordner erhält stattdessen den Status Löschvorgang in Bearbeitung. Wenn ein Ordner den Status Löschvorgang in Bearbeitung aufweist, kann er auf einem Client nicht angezeigt
630
oder verwaltet werden. (Der Ordner wird im Exchange-System-Manager nicht in der Liste der im Informationsspeicher für Öffentliche Ordner enthaltenen Ordner angezeigt.)
Der Status Löschvorgang in Bearbeitung dient dazu, dass andere Replikate die entsprechenden fehlenden Daten replizieren können. Wenn der Ordner mit dem Status Löschvorgang in Bearbeitung Statusnachrichten von allen anderen Replikaten darüber empfängt, dass die Ordner synchronisiert sind, wird das gelöschte Replikat entfernt. Mit diesem Vorgang wird sichergestellt, dass beim Ändern des Replikats eines Ordners von einem Server auf einen anderen Server kein Inhalt verloren geht.
Beim Löschen eines Replikats werden die folgenden Schritte ausgeführt:
1. Der Ordner wird in der Replikatliste entfernt.
2. Eine Hierarchienachricht wird repliziert und gibt die Änderung des Ordnerstatus an (z. B. Aktiv -> Löschvorgang in Bearbeitung).
3. Der Server mit dem Ordner Löschvorgang in Bearbeitung sendet eine Statusanforderung, auf die eine Antwort gesendet werden muss.
4. Ein Server mit einem Replikat antwortet auf die Statusanforderung mit einer Statusnachricht. Wenn in der Statusnachricht angegeben ist, dass die CNSets mindestens so aktuell wie die gelöschten Replikate sind, wird der Vorgang mit Schritt 5 fortgesetzt. Andernfalls werden weiterhin Statusanforderungen gesendet, bis die richtige Antwort empfangen wird.
5. Der Status des gelöschten Ordners wird von Löschvorgang in Bearbeitung in Jetzt löschen geändert, und der Ordner wird gelöscht.
ReplikationsstatustabellenJeder replizierte Ordner (mit der Hierarchie) enthält eine Reihe von Zeilen in der Replikationsstatustabelle mit Replikationsstatusinformationen über jeden Ordner. Jede Zeile im Zeilensatz eines Ordners stellt ein Replikat des Ordners dar. Die Zeile für den lokalen Server enthält neben anderen Daten u. a. die Änderungsnummer der letzten Übertragung, den lokalen CNSet, das Abgleicharray und den Zeitpunkt der nächsten Statusübertragung. Die Zeilen für andere Replikate enthalten die letzten CNSet-Informationen, die der lokale Server von allen anderen Servern empfangen hat (eine Angabe pro Zeile), die durchschnittliche Übertragungszeit für die Replikation von E-Mail-Nachrichten von jedem anderen Server, den letzten Zeitpunkt, an dem eine Abgleichanfrage an jeden anderen Server gesendet wurde, sowie weitere Angaben.
Bei jeder Übertragung einer Replikationsnachricht wird der CNSet aus der Replikationsstatustabelle für das lokale Replikat des Ordners in die Nachricht eingefügt.
Die Replikationsstatustabellen selbst werden nicht repliziert. Die Replikation wird über die CNSets-Daten erstellt. Auf diese Weise wird in den Informationsspeichern für Öffentliche Ordner ermittelt, welche Daten die anderen Replikate eines Ordners enthalten.
631
Hinweis: Hinweis Auf jedem Server werden die Aktualisierungen von anderen Servern über eine Replikations-ID (ReplID) verfolgt. ReplIDs werden lokal berechnet. Aus diesem Grund verfügen Informationsspeicher für Öffentliche Ordner über verschiedene ReplIDs auf mehreren Servern.
Standardzeitplan für ReplikationsereignisseIn der folgenden Tabelle werden einige der häufigsten Standardtimeouts aufgeführt, die Replikationsereignissen zugeordnet sind. Der Hauptthread für Replikationsaufgaben erzeugt zusätzliche Arbeitsthreads zur Verarbeitung von Replikationsaufgaben, wenn diese Standardtimeouts erreicht sind. Wenn keine Replikationsobjekte vorliegen, wird der Thread beendet und keine Replikationsnachricht ausgegeben.
Standardzeiten für Replikationsereignisse
Replikationsereignis Standardtimeout Beschreibung
Replication Expiry 24 Stunden Anzahl der Überprüfungen auf Ablaufen von Ordnern
Replication Send Always 15 Minuten Dies ist der Standardwert Replicate Always. Hiermit wird angegeben, wie oft im Informationsspeicher überprüft wird, ob Inhalt repliziert werden muss. Der Wert kann im Exchange-System-Manager geändert werden.
Replication Send Folder Tree
5 Minuten Hiermit wird angegeben, wie oft im Informationsspeicher für Öffentliche Ordner überprüft wird, ob eine Hierarchiereplikationsnachricht gesendet werden muss.
Replication Send Status Timeout
24 Stunden Hiermit wird angegeben, wie oft im Informationsspeicher für Öffentliche Ordner überprüft wird, ob eine Statusnachricht für einen Ordner gesendet werden muss.
632
Replikationsereignis Standardtimeout Beschreibung
Replication Timeout 5 Minuten Hiermit wird angegeben, wie oft im Informationsspeicher für Öffentliche Ordner überprüft wird, ob das Timeout von Abgleicheinträgen überschritten wurde.
Replication New Replica Backfill Request Delay
15 Minuten Die Verzögerungsdauer vor dem Senden einer Abgleichanfrage für ein neues Ordnerreplikat, wenn die Daten im gleichen Standort verfügbar sind.
Replication Short Backfill Request Delay
6 Stunden Die Verzögerungsdauer vor dem Senden einer Abgleichanfrage, wenn die Daten im gleichen Standort verfügbar sind.
Replication Long Backfill Request Delay
12 Stunden Die Verzögerungsdauer vor dem Senden einer Abgleichanfrage, wenn die Daten nicht im gleichen Standort verfügbar sind.
Replication Short Backfill Request Timeout
12 Stunden Der beim erneuten Senden einer Abgleichanfrage verwendete Timeoutwert, wenn die Daten im gleichen Standort verfügbar sind.
Replication Long Backfill Request Timeout
24 Stunden Der beim erneuten Senden einer Abgleichanfrage verwendete Timeoutwert, wenn die Daten nicht im gleichen Standort verfügbar sind.
633
Replikationsereignis Standardtimeout Beschreibung
Replication Short Backfill Request Timeout Retry
24 Stunden Der beim Senden einer Abgleichanfrage verwendete Timeoutwert, wenn die Daten im gleichen Standort verfügbar sind und es sich um eine Wiederholung einer vorherigen Abgleichanfrage handelt.
Replication Long Backfill Request Timeout Retry
48 Stunden Der beim Senden einer Abgleichanfrage verwendete Timeoutwert, wenn die Daten nicht im gleichen Standort verfügbar sind und es sich um eine Wiederholung einer vorherigen Abgleichanfrage handelt.
StandardreplikationswerteIn der folgenden Tabelle sind einige andere bei der Replikation von Öffentlichen Ordnern verwendete Standardwerte aufgeführt.
Standardreplikationswerte
Beschreibung Wert Beschreibung
Maximale Anzahl der Replikationsordner
20 Maximale Anzahl der in eine Hierarchiereplikationsnachricht einzufügenden Ordner
Maximale Anzahl der gelöschten Replikationsordner
500 Maximale Anzahl der in eine Hierarchiereplikationsnachricht einzufügenden gelöschten Ordner
Maximale Anzahl der Replikationsnachrichten
100 Maximale Anzahl der in eine Inhaltsreplikationsnachricht einzufügenden Nachrichten
634
Beschreibung Wert Beschreibung
Maximale Größe der Replikationsnachrichten
300 KB Maximale Größe der Replikationsnachricht. Der Wert kann im Exchange-System-Manager geändert werden. Die maximale Größe wird möglicherweise von einer einzelnen Replikationsnachricht überschritten. Mit diesem Wert wird die Größe angegeben, bei der die Funktion zum Packen deaktiviert werden sollte. Wenn die maximale Größe durch ein Objekt in einem Objekt überschritten wird, wird es gesondert und vollständig gesendet.
Exchange Server 2003-ClusterarchitekturIn Microsoft Windows Server 2003 ist ein Servercluster eine Anordnung einzelner Computer, die jeweils den Microsoft Windows-Clusterdienst ausführen. Die Computer, die den Servercluster bilden, sind durch ein Netzwerk und ein gemeinsames Datenträgersystem miteinander verbunden. Servercluster haben zwei entscheidende Vorteile. Zum einen werden die Server, die zu einem Cluster gehören, vom Clusterdienst überwacht. Wenn ein Dienst auf dem Server fehlschlägt, stellt der Clusterdienst ihn schnell wieder online, indem ein erneutes Routing über einen anderen Server erfolgt. Dadurch wird die Ausfallzeit eines Systems minimiert. Zum anderen wird die Wartung von Hardware und Software durch Servercluster vereinfacht. Sie können eine reibungslose Aktualisierung vornehmen, indem Sie Clusterressourcen, oft virtuelle Server genannt, auf andere Knoten verschieben und anschließend Hardware- oder Softwareaktualisierungen auf dem ursprünglichen Knoten durchführen. Mit der Bereitstellung von Microsoft Exchange Server 2003 in einem Windows Server 2003-Servercluster können Sie Ausfallzeiten vermeiden und die Systemwartung vereinfachen.
Hinweis: Für die Installation von Exchange 2003 in einem Servercluster mit bis zu acht Knoten müssen Sie Windows Server 2003 Enterprise Edition oder Datacenter Edition und
635
Exchange Server 2003 Enterprise Edition verwenden. Einen Vergleich der Features der Windows Server 2003-Produktfamilie finden Sie unter http://go.microsoft.com/fwlink/?LinkId=33135.
In diesem Abschnitt finden Sie Erläuterungen zur Architektur des Windows-Clusterdiensts und zur Interaktion zwischen Exchange Server 2003 Enterprise Edition und dem Windows-Clusterdienst. Hier finden Sie Informationen zu Aufgaben, die auf Exchange-Servern durchgeführt werden müssen, die in einem Servercluster ausgeführt werden. Folgende Themen werden genauer erläutert:
Architektur des Windows-Clusterdiensts Die allgemeinen Eigenschaften von Clustersystemen, auf denen Windows Server 2003 ausgeführt wird, werden in diesem Abschnitt erläutert. Lösungen mit hoher Verfügbarkeit für Exchange 2003-Postfachserver erfordern Kenntnis über die Architektur des Windows-Clusterdiensts und darüber, wie der Clusterdienst mit Cluster-gestützten Anwendungen wie Exchange 2003 interagiert.
Virtuelle Exchange-Server Ein virtueller Exchange-Server ist eine Instanz von Exchange 2003 Enterprise Edition, die für die Ausführung in einem Servercluster konfiguriert ist. Die Eigenschaften von virtuellen Servern bestimmen, wie Clients mit Exchange 2003 Enterprise Edition in einem Servercluster verbunden werden, unabhängig vom physischen Knoten, auf dem Exchange 2003 ausgeführt wird.
Interaktion zwischen Exchange 2003 Enterprise Edition und dem Clusterdienst Die physischen Knoten eines Clusters und die darauf befindlichen Ressourcen werden vom Windows-Clusterdienst überwacht. Es findet eine kontinuierliche Interaktion zwischen dem Clusterdienst und den verschiedenen Exchange-Clusterressourcen statt, die einen virtuellen Exchange-Server in einem Cluster bilden.
Cluster-spezifische Konfigurationen Obwohl die Ausführung von Exchange 2003 in einem Windows-Servercluster der eigenständigen Ausführung eines Exchange-Servers (also ohne Cluster) sehr ähnelt, gibt es bei Clustern ein paar Besonderheiten zu beachten. Beispielsweise erfordern bestimmte Exchange 2003-Ressourcen, die in einem Cluster ausgeführt werden, spezielle Konfigurationen für die Kommunikation in einem Clusterserver.
Weitere Informationen zur Clustertechnologie von Windows finden Sie in Clustering Technologies.
Architektur von Windows-ClusternMicrosoft Cluster Server (MSCS) in Microsoft Windows NT Server 4.0 Enterprise Edition war die erste von Microsoft herausgegebene Software für Servercluster. Einzelne Server, die einen Cluster bilden, werden als Knoten bezeichnet. Ein Clusterdienst ist eine Sammlung von Komponenten auf jedem Knoten für clusterspezifische Aufgaben. Vom Clusterdienst
636
verwaltete Hardware- und Softwarekomponenten des Clusters werden als Ressourcen bezeichnet. Servercluster stellen den Instrumentationsmechanismus zur Verwaltung von Ressourcen über Ressourcen-DLLs bereit, die Kommunikationsschnittstellen, Verwaltungsvorgänge und Ressourcenabstraktionen definieren (anders gesagt, sie abstrahieren eine Ressource in Clustern von einem bestimmten physischen Knoten, sodass diese von einem Knoten auf einen anderen verschoben werden kann).
Ressourcen sind Elemente in einem Cluster mit folgenden Eigenschaften:
Sie werden online geschaltet (in Betrieb) und offline geschaltet (außer Betrieb).
Sie werden in einem Servercluster verwaltet.
Nur ein Knoten kann die Ressource besitzen.
Eine Ressourcengruppe ist eine Sammlung von Ressourcen, die vom Clusterdienst als einzelne logische Einheit verwaltet wird. Diese logische Einheit wird oft als Failovereinheit bezeichnet, da die gesamte Gruppe als einzelne Einheit zwischen den Knoten verschoben wird. Ressourcen und Clusterelemente werden je nach den der Ressourcengruppe hinzugefügten Ressourcen logisch gruppiert. Wenn der Clusterdienst auf einer Ressourcengruppe einen Vorgang ausführt, betrifft dieser alle einzelnen in der Gruppe enthaltenen Ressourcen. Üblicherweise wird eine Ressourcengruppe erstellt, die die einzelnen Ressourcen enthält, die von dem Programm in Clustern benötigt werden.
Clusterressourcen können physische Hardwaregeräte, z. B. Laufwerke und Netzwerkkarten, sowie logische Elemente, z. B. IP-Adressen, Netzwerknamen und Anwendungskomponenten, enthalten.
Cluster enthalten außerdem gemeinsame Ressourcen, z. B. externe Datenspeicherarrays und private Clusternetzwerke. Auf gemeinsame Ressourcen haben alle Knoten im Cluster Zugriff. Eine gemeinsame Ressource ist die Quorumressource. Sie spielt eine wichtige Rolle bei Vorgängen im Cluster. Auf die Quorumressource müssen alle Knotenvorgänge zugreifen können. Dazu gehören die Bildung und die Änderung eines Clusters sowie das Beitreten zu einem Cluster.
ServerclusterWindows Server 2003 Enterprise Edition stellt zwei Arten der Clustertechnologie für die Verwendung mit Exchange Server 2003 Enterprise Edition bereit. Bei der ersten handelt es sich um die Clusterdienste, die Failoverunterstützung für Back-End-Postfachserver bieten, die eine hohe Verfügbarkeit erfordern. Bei der zweiten handelt es sich um den Netzwerklastenausgleich (NLB, Network Load Balancing), der Servercluster ergänzt, indem er hoch verfügbare, skalierbare Cluster von virtuellen Front-End-Exchange-Protokollservern (z. B. HTTP, IMAP4 und POP3) unterstützt.
Servercluster verwenden ein Modell ohne gemeinsame Nutzung von Ressourcen. Die Arten der Modelle bestimmen, wie die Server in einem Cluster lokale und gemeinsame
637
Clustergeräte und -ressourcen verwalten und verwenden. In solch einem Cluster verfügt jeder Server über seine eigenen lokalen Geräte und verwaltet diese. Als Besitzer gemeinsam verwendeter Geräte des Clusters, z. B. gemeinsamer Datenträgerarrays und Verbindungsmedien, fungiert jeweils nur ein Knoten, der auch für die Verwaltung zuständig ist.
Servercluster verwenden für die Verbindung zu den lokalen Speichergeräten und -medien standardisierte Windows-Treiber. Servercluster unterstützen mehrere Verbindungsmedien für externe gemeinsame Geräte, die für alle Server des Clusters zugänglich sein müssen. Externe Speichergeräte unterstützen PCI-basierte SCSI-Verbindungen, SCSI über Fibre Channel sowie einen SCSI-Bus mit mehreren Initiatoren. Fibre-Verbindungen sind SCSI-Geräte, die statt auf einem SCSI-Bus auf einem Fibre Channel-Bus gehostet werden.
In der folgenden Abbildung sind Komponenten eines Serverclusters mit zwei Knoten dargestellt, der aus Servern besteht, die Windows Server 2003 Enterprise Edition ausführen. Die gemeinsamen Speichergeräte sind durch SCSI oder durch SCSI über Fibre Channel verbunden.
Beispiel für einen Windows-Cluster mit zwei Knoten
ServerclusterarchitekturServercluster sind separate, isolierte Komponentensätze, die eng mit Windows Server 2003 in Verbindung stehen. Nach der Installation des Clusterdiensts sind Änderungen am Betriebssystem möglich. Diese Änderungen umfassen:
Unterstützung für das dynamische Erstellen und Löschen von Netzwerknamen und -adressen.
Änderungen des Dateisystems, um das Schließen offener Dateien während der Aufhebung der Bereitstellung von Laufwerken zu ermöglichen.
638
Änderungen des Speichersubsystems, um die gemeinsame Verwendung von Festplatten und Laufwerken für mehrere Knoten zu ermöglichen.
Abgesehen von diesen und anderen geringfügigen Änderungen unterscheidet sich ein Server, auf dem der Windows-Clusterdienst ausgeführt wird, nicht von einem ohne den Windows-Clusterdienst.
Der Clusterdienst bildet den Kern der Servercluster. Der Clusterdienst besteht aus mehreren funktionalen Einheiten, z. B. Knotenverwaltung, Failover-Manager, Datenbank-Manager, Global Update-Manager, Checkpoint-Manager, Protokoll-Manager, Event Log Replication-Manager und Backup/Restore-Manager.
Komponenten des ClusterdienstsDer Clusterdienst wird in Windows Server 2003 Enterprise Edition ausgeführt. Dabei werden Netzwerktreiber, Gerätetreiber und Ressourceninstrumentationsvorgänge verwendet, die speziell für Servercluster und ihre Komponentenvorgänge entwickelt wurden. Der Clusterdienst enthält die folgenden Komponenten:
Checkpoint-Manager: Diese Komponente speichert Registrierungsschlüssel von Anwendungen in einem auf der Quorumressource gespeicherten Clusterverzeichnis. Damit der Clusterdienst bei einem Ressourcenfehler wiederhergestellt werden kann, werden die Registrierungsschlüssel von Checkpoint-Manager überprüft, wenn eine Ressource online geschaltet wird. Wenn die Ressource offline geschaltet wird, werden die Prüfpunktdaten in die Quorumressource geschrieben. Checkpoint-Manager unterstützt außerdem Ressourcen mit anwendungsspezifischen Registrierungsstrukturen, die auf dem Clusterknoten instanziiert sind, auf dem die Ressource online geschaltet wird. Einer Ressource können eine oder mehrere Registrierungsstrukturen zugeordnet sein. Wenn eine Ressource online ist, werden Änderungen dieser Registrierungsstrukturen von Checkpoint-Manager überwacht. Wenn Änderungen von Checkpoint-Manager erkannt werden, wird der Registrierungsschlüssel auf den der Ressource zugehörigen Knoten übertragen. Anschließend wird die Datei von Checkpoint-Manager auf den der Quorumressource zugehörigen Knoten übertragen. Checkpoint-Manager führt Übertragungen von Stapelverarbeitungen aus, sodass der Clusterdienst auch durch häufige Änderungen der Registrierungsstruktur nicht überlastet wird.
Datenbank-Manager: Der Datenbank-Manager verwaltet Clusterkonfigurationsinformationen zu allen physischen und logischen Einheiten in einem Cluster. Diese Einheiten umfassen den Cluster selbst, die Mitgliedschaft des Clusterknotens, Ressourcengruppen sowie Beschreibungen bestimmter Ressourcen, z. B. Festplatten und IP-Adressen.
Dauerhafte und temporäre in der Konfigurationsdatenbank gespeicherte Informationen verfolgen den aktuellen und den gewünschten Status eines Clusters. Alle Instanzen des Datenbank-Managers, die auf den einzelnen Knoten des Clusters ausgeführt werden,
639
kooperieren für die Wartung konsistenter Konfigurationsinformationen miteinander und stellen so die Übereinstimmung der Kopien der Konfigurationsdatenbank auf allen Knoten sicher.
Der Datenbank-Manager stellt außerdem eine Schnittstelle bereit, die von anderen Clusterkomponenten, z. B. Failover-Manager und Knotenverwaltung, verwendet werden kann. Diese Schnittstelle ähnelt der Registrierungsschnittstelle von Microsoft Win32-APIs. Die Datenbank-Manager-Schnittstelle schreibt jedoch die an den Clustereinheiten vorgenommenen Änderungen sowohl in die Registrierung als auch in die Quorumressource.
Der Datenbank-Manager unterstützt transaktionale Aktualisierungen der Registrierungsdatenbankstruktur und stellt Schnittstellen nur für interne Clusterdienstkomponenten zur Verfügung. Diese transaktionale Unterstützung wird üblicherweise von Failover-Manager und der Knotenverwaltung verwendet, um replizierte Transaktionen zu erhalten. Alle Funktionen des Datenbank-Managers, mit Ausnahme der Funktionen zur transaktionalen Unterstützung, werden den Clients von der Cluster-API zur Verfügung gestellt. Weitere Informationen zur Cluster-API finden Sie auf der MSDN-Website Cluster API.
Hinweis: Die Registrierungsschlüsseldaten von Anwendungen und deren Änderungen werden von Checkpoint-Manager in Quorumprotokolldateien auf der Quorumressource festgehalten.
Ereignisdienst: Der Ereignisdienst fungiert als Schalttafel und sendet Ereignisse zu und von Anwendungen sowie zu den Clusterdienstkomponenten auf den einzelnen Knoten. Die Ereignisprozessorkomponente des Ereignisdiensts hilft Clusterdienstkomponenten dabei, Informationen über wichtige Ereignisse an alle anderen Komponenten weiterzugeben. Die Ereignisprozessorkomponente unterstützt den Ereignismechanismus der Cluster-API. Außerdem werden von ihr verschiedene Dienste ausgeführt, z. B. die Übermittlung von Signalereignissen an clustergestützte Anwendungen sowie die Verwaltung von Clusterobjekten.
Event Log Replication-Manager: Der Event Log Replication-Manager repliziert Ereignisprotokolleinträge von einem Knoten auf alle anderen Knoten des Clusters. In der Standardeinstellung interagiert der Clusterdienst mit dem Windows-Ereignisprotokolldienst des Clusters, um Ereignisprotokolleinträge auf alle Clusterknoten zu replizieren. Wenn der Clusterdienst auf dem Knoten gestartet wird, wird von ihm eine private API im lokalen Ereignisprotokolldienst aufgerufen und eine Verbindung zwischen Ereignisprotokolldienst und Clusterdienst angefordert. Daraufhin wird zwischen Ereignisprotokolldienst und CLUSAPI über lokale Remoteprozeduraufrufe (RPCs – Remote Procedure Calls) eine Verbindung hergestellt. Wenn der Ereignisprotokolldienst ein zu protokollierendes Ereignis empfängt, wird dieses lokal protokolliert und in die bestehende Stapelverarbeitungs-Warteschlange eingereiht. Wenn kein Thread für die Zeitgebung aktiv ist, wird ein solcher zur Ausführung innerhalb der nächsten
640
20 Sekunden geplant. Wenn der Thread für die Zeitgebung ausgelöst wird, wird die Stapelverarbeitungs-Warteschlange verarbeitet, und die Ereignisse werden als einzelner konsolidierter Puffer an die Cluster-API gesendet, die zuvor mit dem Ereignisprotokolldienst verbunden war. Anschließend sendet die Cluster-API das Ereignis an den Clusterdienst.
Sobald der Clusterdienst die Ereignisse des Ereignisprotokolldiensts aus der Stapelverarbeitung empfangen hat, reiht er diese in eine lokale ausgehende Warteschlange ein und kehrt von den Remoteprozeduraufrufen zurück. Diese Warteschlange wird von dem für die Ereignisübertragung zuständigen Thread des Clusterdiensts verarbeitet. Anschließend werden die Ereignisse mittels clusterinterner Remoteprozeduraufrufe an alle aktiven Clusterknoten gesendet. Die Ereignisse werden dann von der API des Servers in eine eingehende Warteschlange eingereiht. Diese Warteschlange wird von einem Thread zum Schreiben von Ereignisprotokollen verarbeitet. Der Thread stellt mittels eines privaten Remoteprozeduraufrufs eine Anfrage zum lokalen Schreiben der Ereignisse an den lokalen Ereignisprotokolldienst.
Der Clusterdienst ruft mithilfe des Lightweight-Remoteprozeduraufrufs (LRPC – Lightweight Remote Procedure Call) die privaten RPC-Schnittstellen des Ereignisprotokolldiensts auf. LRPCs werden vom Ereignisprotokolldienst außerdem dazu verwendet, die Cluster-API aufzurufen, um dann die Aufforderung an den Clusterdienst zu senden, die Ereignisse zu replizieren.
Failover-Manager: Der Failover-Manager ist für die Ressourcenverwaltung zuständig und leitet die entsprechenden Aktionen ein, z. B. Start, Neustart und Failover. Der Failover-Manager beendet und startet Ressourcen, verwaltet die Abhängigkeiten der Ressourcen und leitet Failovers von Ressourcengruppen ein. Zum Durchführen dieser Aktionen empfängt der Failover-Manager-Informationen über Ressourcen und Systemstatus von Ressourcenmonitoren und Clusterknoten.
Außerdem wird vom Failover-Manager entschieden, welche Ressourcengruppen welchen Knoten des Clusters angehören. Wenn die Zuteilung der Ressourcengruppen abgeschlossen ist, geben Knoten, die über eine einzelne Gruppe verfügen, die Steuerung der Ressourcen in dieser Gruppe an die Knotenverwaltung zurück. Wenn ein Fehler bei einer Ressourcengruppe vom zuständigen Knoten nicht behoben werden kann, arbeiten die Failover-Manager aller Knoten zusammen, um der Ressourcengruppe einen Besitzer neu zuzuweisen.
Wenn eine Ressource ausfällt, startet der Failover-Manager diese erneut oder stellt die Ressource zusammen mit deren abhängigen Ressourcen offline. Wenn der Failover-Manager die Ressource offline stellt, wird angezeigt, dass die Zuständigkeit für die Ressource an einen anderen Knoten übertragen wird. Anschließend wird die Ressource, die sich nun in Besitz des neuen Knotens befindet, neu gestartet. Dieser Vorgang wird als Failover bezeichnet und im Abschnitt „Cluster-Failover“ weiter unten in diesem Thema erläutert.
641
Global Update-Manager: Der Global Update-Manager stellt den von Clusterkomponenten verwendeten globalen Aktualisierungsdienst bereit. Der Global Update-Manager wird von internen Clusterkomponenten verwendet, z. B. Failover Manager, Knotenverwaltung und Datenbank-Manager, um Änderungen der Clusterdatenbank über Knoten hinweg zu replizieren. Global Update-Manager-Aktualisierungen werden üblicherweise durch einen Cluster-API-Aufruf eingeleitet. Wenn auf einem Clientknoten eine Global Update-Manager-Aktualisierung eingeleitet wird, wird zuerst eine Anforderung zur globalen Sperre an einen Sperrknoten gesendet. Wenn die Sperre nicht verfügbar ist, wartet der Client auf die Verfügbarkeit.
Sobald die Sperre verfügbar ist, überträgt der Sperrknoten dem Client diese und gibt die Aktualisierung lokal heraus (auf dem Sperrknoten). Anschließend gibt der Client die Aktualisierung an alle anderen ordnungsgemäß ausgeführten Knoten heraus, einschließlich an sich selbst. Wenn eine Aktualisierung auf dem Sperrknoten erfolgreich ausgeführt wird, auf einem anderen Knoten jedoch Fehler auftreten, wird dieser Knoten aus der Mitgliedschaft des aktuellen Clusters entfernt. Wenn Fehler bei der Aktualisierung auf dem Sperrknoten auftreten, gibt dieser den Fehler lediglich an den Client zurück.
Protokoll-Manager: Der Protokoll-Manager speichert Änderungen in Wiederherstellungsprotokollen, die sich auf der Quorumressource befinden. Der Protokoll-Manager stellt in Verbindung mit dem Checkpoint-Manager sicher, dass das Wiederherstellungsprotokoll auf der Quorumressource die aktuellsten Konfigurationsdaten und Änderungsprüfpunkte enthält. Beim Ausfall eines oder mehrerer Clusterknoten können Konfigurationsänderungen immer noch auf den verbleibenden Knoten vorgenommen werden. Während des Stillstands dieser Knoten wird der Protokoll-Manager vom Datenbank-Manager dazu verwendet, Konfigurationsänderungen auf der Quorumressource zu protokollieren.
Wenn die ausgefallenen Knoten wieder funktionieren, wird der Speicherort der Quorumressource aus deren lokalen Cluster-Registrierungsdatenbankstrukturen gelesen. Da die Datenbankstrukturdaten jedoch überholt sein könnten, gibt es Mechanismen, die ungültige, aus einer überholten Clusterkonfigurationsdatenbank ausgelesene Quorumressourcen erkennen. Der Datenbank-Manager sendet anschließend unter Verwendung der Prüfpunktdatei auf der Quorumressource eine Anforderung zum Aktualisieren der lokalen Kopie der Clusterdatenbankstruktur an den Protokoll-Manager. Die Protokolldatei wird dann auf dem Quorumlaufwerk wiedergegeben, beginnend mit der Sequenznummer des Prüfpunktprotokolls. Das Ergebnis ist eine vollständig aktualisierte Clusterdatenbankstruktur. Snapshots der Clusterdatenbankstruktur werden beim Zurücksetzen des Quorumprotokolls sowie einmal alle vier Stunden erstellt.
Membership-Manager: Der Membership-Manager überwacht die Clustermitgliedschaft und den Zustand aller Knoten im Cluster. Der Membership-Manager (auch als „Regroup Engine“ bezeichnet) behält den ständigen Überblick darüber, welche Clusterknoten gerade aktiv oder außer Betrieb sind. Der Kern der Membership-Manager-Komponente ist ein Algorithmus zur Neugruppierung, der immer dann aufgerufen wird, wenn der
642
Nachweis über den Ausfall eines oder mehrerer Knoten vorliegt. Sobald der Algorithums abgeschlossen ist, erhalten alle beteiligten Knoten dieselbe Clustermitgliedschaft.
Knotenverwaltung: Die Knotenverwaltung weist den Knoten je nach Gruppenvorranglisten und Knotenverfügbarkeit den Besitz von Ressourcengruppen zu. Die Knotenverwaltung wird auf jedem Knoten ausgeführt und enthält eine lokale Liste der Knoten, die dem Cluster angehören. In regelmäßigen Abständen werden von der Knotenverwaltung Nachrichten, sogenannte „Heartbeats“, an andere Knoten des Clusters gesendet, um Knotenfehler zu erkennen. Alle Knoten im Cluster müssen über exakt die gleiche Ansicht der Clustermitgliedschaft verfügen.
Wenn ein Clusterknoten einen Kommunikationsfehler mit einem anderen Clusterknoten registriert, wird von ihm eine Gruppennachricht an den gesamten Cluster gesendet. Dieses Ereignis der Neugruppierung veranlasst alle Mitglieder zur Überprüfung ihrer Ansicht der aktuellen Clustermitgliedschaft. Während des Vorgangs der Neugruppierung verhindert der Clusterdienst Schreibvorgänge auf allen gemeinsamen Laufwerken des Clusters, bis sich die Mitgliedschaft stabilisiert. Wenn eine Instanz der Knotenverwaltung auf einem einzelnen Knoten nicht antwortet, wird dieser aus dem Cluster entfernt. Die aktiven Ressourcengruppen des Knotens werden auf einen anderen aktiven Knoten verschoben. Um diese Änderung vornehmen zu können, sucht die Knotenverwaltung nach möglichen Besitzern (Knoten), die über einzelne Ressourcen verfügen können, sowie nach dem Knoten, auf dem eine Ressourcengruppe bevorzugt ausgeführt werden soll. Die Knotenverwaltung wählt dann den Knoten aus und verschiebt die Ressourcengruppe. In einem Cluster mit zwei Knoten werden die Ressourcengruppen von der Knotenverwaltung einfach vom ausgefallenen auf den verbleibenden Knoten verschoben. In einem Cluster, der aus drei oder mehr Knoten besteht, verteilt die Knotenverwaltung die Ressourcengruppen selektiv an die verbleibenden Knoten.
Die Knotenverwaltung fungiert außerdem als Gatekeeper, der die Aufnahme von Knoten in den Cluster ermöglicht sowie Anforderungen zur Aufnahme oder zum Ausschluss eines Knotens verarbeitet.
Ressourcenmonitor: Der Ressourcenmonitor überprüft den Zustand aller Clusterressourcen mittels Rückrufen an die Ressourcen-DLLs. Ressourcenmonitore führen einen separaten Prozess aus und kommunizieren mithilfe von RPCs mit dem Clusterserver. Dies schützt den Clusterdienst vor Fehlern einzelner Clusterressourcen.
Ressourcenmonitore stellen die Kommunikationsschnittstelle zwischen Ressourcen-DLLs und dem Clusterdienst bereit. Wenn der Clusterdienst an Daten aus einer Ressource abrufen muss, empfängt der Ressourcenmonitor die Anforderung und leitet diese an die zuständige Ressourcen-DLL weiter. Wenn wiederum eine Ressourcen-DLL ihren Status melden oder der Clusterdienst über ein Ereignis informiert werden muss, leitet der Ressourcenmonitor die Informationen von der Ressource zum Clusterdienst.
Der Ressourcenmonitorprozess (RESRCMON.EXE) ist dem Clusterdienstprozess (CLUSSVC.EXE) untergeordnet. Der Ressourcenmonitor lädt Ressourcen-DLLs, von denen die Clusterressourcen in ihrem Verarbeitungsraum überwacht werden. Das Laden
643
der Ressourcen-DLLs in einem vom Clusterdienst separaten Prozess dient der Fehlerisolierung. Mehrere Ressourcenmonitore können gleichzeitig instanziiert werden.
Jeder Ressourcenmonitor fungiert als LRPC-Server für den Clusterdienstprozess. Wenn der Clusterdienst einen Aufruf der Cluster-API empfängt, der die Kommunikation mit einer Ressourcen-DLL erfordert, wird die LRPC-Schnittstelle zum Aufrufen des Ressourcenmonitor-RPC verwendet. Zum Empfangen von Antworten des Ressourcenmonitors wird vom Clusterdienst für jeden Ressourcenmonitorprozess ein Benachrichtigungsthread erstellt. Dieser Benachrichtigungsthread ruft einen RPC auf, der sich permanent im Ressourcenmonitor befindet. Der Thread erhält Benachrichtigungen bei deren Erstellung. Er wird nur freigegeben, wenn er manuell durch einen entsprechenden Befehl im Clusterdienst abgebrochen wird oder wenn der Ressourcenmonitor ausfällt.
Der Ressourcenmonitor erhält den konstanten Status nicht alleine aufrecht. Er speichert im Arbeitsspeicher eingeschränkt den Status der Ressourcen, mit den primären Statusinformationen wird er jedoch vom Clusterdienst versorgt. Der Ressourcenmonitor kommuniziert mit den Ressourcen-DLLs mittels genau definierter Einstiegspunkte, die von den DLLs zur Verfügung gestellt werden müssen. Folgende Vorgänge werden vom Ressourcenmonitor eigenständig ausgeführt:
Er ruft Ressourcen-DLLs durch IsAlive- und LooksAlive-Einstiegspunkte auf und überprüft abwechselnd die von Ressourcen-DLLs angezeigten Fehlerereignisse.
Zur Überwachung anstehender Timeouts von Ressourcen-DLLs werden vom Ressourcenmonitor Threads für die Zeitgebung erzeugt, die die Meldung ERROR_IO_PENDING von den Online- oder Offline-Einstiegspunkten der DLLs zurückgeben.
Er erkennt Systemausfälle des Clusterdiensts und beendet die Ressourcen.
Die weiteren Aktionen ergeben sich aus Vorgängen, die vom Clusterdienst über die RPC-Schnittstelle angefordert werden. Eine Erkennung nicht reagierender Vorgänge wird vom Clusterdienst nicht durchgeführt. Er überwacht jedoch Systemausfälle und startet einen Monitor im Fall eines Prozessabsturzes erneut.
Der Clusterdienst und der Ressourcenmonitorsprozess verfügen zusammen über eine von der Auslagerungsdatei unterstützte Sektion im Arbeitsspeicher. Die Zugriffsnummer der Sektion wird dem Ressourcenmonitor bei dessen Startvorgang übertragen. Anschließend dupliziert der Ressourcenmonitor die Zugriffsnummer und speichert die Nummer des Einstiegspunkts und den Ressourcennamen unmittelbar vor dem Aufruf eines Ressourcen-DLL-Einstiegspunkts in seiner Sektion. Wenn der Ressourcenmonitor ausfällt, wird die gemeinsame Sektion vom Clusterdienst gelesen, um die Ressource und den Einstiegspunkt zu identifizieren, die für den Ausfall verantwortlich sind.
Backup/Restore-Manager: Der Backup/Restore-Manager arbeitet mit dem Failover-Manager und dem Datenbank-Manager zusammen, um die Quorumprotokolldatei sowie alle Prüfpunktdateien zu sichern und wiederherzustellen. Für die Sicherung der
644
Datenbank wird vom Clusterdienst die BackupClusterDatabase-API verwendet. Zuerst tritt die BackupClusterDatabase-API mit der Failover-Manager-Ebene in Verbindung. Von der Failover-Manager-Ebene wird die Anforderung an den Knoten weitergeleitet, der zu diesem Zeitpunkt über die Quorumressource verfügt. Dieser Knoten ruft anschließend den Datenbank-Manager auf, der eine Sicherung der Quorumprotokolldatei sowie aller Prüfpunktdateien vornimmt.
Ferner meldet sich der Clusterdienst während des Startvorgangs beim Volumeschattenkopie-Dienst als Sicherungsschreiber an. Wenn ein Sicherungsclient den Volumeschattenkopie-Dienst für die Sicherung des Systemstatus aufruft, wird durch eine Reihe von Einstiegspunktaufrufen auch der Clusterdienst aufgerufen, um eine Sicherung der Clusterdatenbank vorzunehmen. Der Servercode des Clusterdiensts ruft den Failover-Manager zum Durchführen der Sicherung auf. Der Rest des Vorgangs erfolgt über die BackupClusterDatabase-API.
Anhand der RestoreClusterDatabase-API stellt der Clusterdienst die Clusterdatenbank über einen Sicherungspfad wieder her. Diese API kann nur lokal von einem der Clusterknoten aufgerufen werden. Wenn die RestoreClusterDatabase-API aufgerufen wird, beendet sie den Clusterdienst, stellt die Clusterdatenbank mithilfe der Sicherung wieder her, legt einen Registrierungswert fest, der den Sicherungspfad enthält, und startet den Clusterdienst anschließend erneut. Während des Startvorgangs erkennt der Clusterdienst die Anfrage zur Wiederherstellung und stellt daraufhin die Clusterdatenbank vom Sicherungspfad auf der Quorumressource wieder her.
Cluster-FailoverEin Failover kann aufgrund eines unerwarteten Software- oder Hardwarefehlers automatisch erfolgen oder von einem Administrator manuell ausgelöst werden. Algorithmus und Verhalten in beiden Situationen sind fast identisch. Bei einem manuell ausgelösten Failover werden die Ressourcen jedoch in geordneter Weise heruntergefahren. Bei einem nicht geplanten Failover werden dagegen die Ressourcen sehr abrupt beendet (z. B. wird der Strom abgeschaltet, oder es tritt ein Fehler bei einer entscheidenden Hardwarekomponente auf).
Wenn ein Fehler in einem gesamten Knoten eines Clusters auftritt, werden seine Ressourcengruppen auf einen oder mehrere verfügbare Knoten des Clusters übertragen. Ein automatischer Failover ist mit einer geplanten administrativen Neuzuweisung des Besitzes von Ressourcen vergleichbar. Der Vorgang ist jedoch etwas komplizierter, da die geordneten Schritte eines geplanten Herunterfahrens möglicherweise unterbrochen oder gar nicht ausgeführt werden. Daher sind zusätzliche Schritte erforderlich, um den Status des Clusters zum Zeitpunkt des Fehlers zu ermitteln.
Bei einem automatischen Failover im Netzwerk ist es wichtig, die auf dem fehlerhaften Knoten ausgeführten Gruppen zu identifizieren und festzulegen, welche Knoten den Besitz der verschiedenen Ressourcengruppen übernehmen sollen. Alle Knoten des Clusters, die zur Übernahme der Ressourcengruppen geeignet sind, verhandeln über deren Besitz. Die
645
Aushandlung basiert auf Knotenkapazitäten, der aktuellen Auslastung, Anwendungsrückmeldungen, der Knotenvorrangliste oder der Verwendung der Eigenschaft AntiAffinityClassNames, die unter Clusterspezifische Konfigurationen erläutert wird. Nach Abschluss der Aushandlung über die Ressourcengruppe werden die Datenbanken auf allen Clusterknoten aktualisiert. Es wird festgehalten, welcher Knoten über die Ressourcengruppe verfügt.
In Clustern mit mehr als zwei Knoten kann in der Knotenvorrangliste für jede Ressourcengruppe ein bevorzugter Server sowie eine oder mehrere Alternativen festgelegt werden. Dies ermöglicht kaskadierende Failover. Durch das Kaskadieren oder einen Failover zum jeweils nächsten Server auf der Knotenvorrangliste kann eine Ressourcengruppe Fehler auf mehreren Servern überstehen.
Eine Alternative zum automatischen Failover ist der sogenannte N+I-Failover. Bei dieser Methode werden die Knotenvorranglisten für alle Clustergruppen erstellt. In der Knotenvorrangliste werden die stellvertretenden Clusterknoten festgehalten, auf die die Ressourcen beim ersten Failover verschoben werden. Diese Ersatzknoten sind Server im Cluster, die meistens nicht aktiv sind oder deren Arbeitsauslastung es erlaubt, die Last eines fehlerhaften Servers beim Verschieben auf den Ersatzknoten zu übernehmen.
Bei einem kaskadierenden Failover wird davon ausgegangen, dass alle anderen Server des Clusters über zusätzliche Kapazitäten verfügen und einen Teil der Arbeitslast eines fehlerhaften Servers übernehmen können. Bei einem N+I-Failover wird davon ausgegangen, dass die +I-Ersatzserver die primären Empfänger zusätzlicher Kapazitäten sind.
Cluster-FailbackWenn ein Knoten wieder online geschaltet wird, kann der Failover-Manager darüber entscheiden, eine oder mehrere Ressourcengruppen zurück auf den wiederhergestellten Knoten zu verschieben. Dieser Vorgang wird als Failback bezeichnet. Zur Durchführung eines Failbacks auf einen wiederhergestellten oder neu gestarteten Knoten muss in den Eigenschaften einer Ressourcengruppe ein bevorzugter Besitzer definiert sein. Ressourcengruppen, deren bevorzugter Besitzer der wiederhergestellte oder neu gestartete Knoten ist, werden vom aktuellen Besitzerknoten auf diesen Knoten verschoben.
Die Failbackeigenschaften einer Ressourcengruppe können die Zeiten enthalten, zu denen ein Failback erlaubt ist, sowie die Anzahl der zulässigen Versuche für den Failback. Dadurch kann der Failback von Ressourcengruppen während Spitzenauslastungszeiten oder auf Knoten, die nicht ordnungsgemäß wiederhergestellt oder neu gestartet wurden, vom Clusterdienst verhindert werden.
ClusterquorumJeder Cluster verfügt über eine spezielle Ressource, die als Quorumressource bezeichnet wird. Eine Quorumressource kann eine beliebige Ressource mit folgenden Funktionen sein:
646
Bereitstellung eines Mechanismus, um Entscheidungen über Mitgliedschaft und Clusterstatus zu treffen.
Bereitstellung physischen Speichers, um Konfigurationsinformationen festzuhalten.
Ein Quorumprotokoll ist eine Konfigurationsdatenbank für den gesamten Servercluster. Das Quorumprotokoll enthält Clusterkonfigurationsinformationen, z. B. die im Cluster enthaltenen Server, die im Cluster installierten Ressourcen und den Status dieser Ressourcen (z. B. online oder offline).
Das Quorum ist aus den folgenden beiden Gründen in einem Cluster sehr wichtig:
Konsistenz: Ein Cluster besteht aus mehreren physischen Servern, die zusammen als einzelner virtueller Server fungieren. Es ist wichtig, dass jeder der physischen Server einen ständigen Überblick über die Clusterkonfiguration hat. Das Quorum dient als definitives Repository für alle Konfigurationsinformationen über den Cluster. Wenn der Clusterdienst nicht auf das Quorum zugreifen kann, kann er nicht gestartet werden.
Verbindungstrennung: Mit dem Quorum werden Verbindungen getrennt, um zerteilte Clusterszenarios zu vermeiden. Ein zerteiltes Clusterszenario entsteht, wenn alle Netzwerkkommunikationsverbindungen zwischen mindestens zwei Clusterknoten ausfallen. In diesem Fall wird der Cluster möglicherweise in mehrere Teile gespalten, die nicht miteinander kommunizieren können. Das Quorum stellt sicher, dass die Clusterressourcen auf nur einem Knoten online geschaltet werden. Dies geschieht, indem die Partition, auf der sich das Quorum befindet, weiter ausgeführt wird, während die anderen Partitionen aus dem Cluster entfernt werden.
StandardquorumWie in diesem Abschnitt bereits erwähnt, handelt es sich beim Quorum um eine Konfigurationsdatenbank für den Clusterdienst, die in der Quorumprotokolldatei gespeichert wird. Ein Standardquorum verwendet eine Quorumprotokolldatei, die sich auf einem Laufwerk des gemeinsamen Speicherarrays befindet und auf die von allen Mitgliedern des Clusters zugegriffen werden kann.
Alle Mitglieder sind über SCSI oder Fibre Channel mit dem gemeinsamen Speicher verbunden. Der Speicher besteht aus externen Festplatten (normalerweise als RAID konfiguriert) oder einem SAN, in dem die logischen Einheiten des SAN als physische Laufwerke dargestellt werden.
Hinweis: Es ist wichtig, dass sich das Quorum auf einer physischen Laufwerkressource befindet und nicht auf einer Laufwerkpartition, da bei einem Failover die gesamte physische Laufwerkressource verschoben wird. Ferner können Servercluster so konfiguriert werden, dass auf den lokalen Festplatten eines Servers das Quorum gespeichert wird. Diese Art der Implementierung (im Englischen auch „lone wolf
647
cluster“ genannt) wird nur für Test- und Entwicklungszwecke unterstützt. Solche Cluster sollten nicht zur Clusterbildung von Exchange 2003 in einer Produktionsumgebung verwendet werden, da ein Failover mit ihnen nicht möglich ist.
HauptknotensatzquorumAus Sicht eines Serverclusters ist ein Hauptknotensatzquorum (MNS – Majority Node Set) eine einzelne Quorumressource. In der Standardeinstellung werden die Daten auf den lokalen Laufwerken der einzelnen Knoten im Cluster gespeichert. Die MNS-Ressource stellt sicher, dass die Clusterkonfigurationsdaten, die auf ihr enthalten sind, über die verschiedenen Laufwerke hinweg konsistent sind. Bei der in Windows Server 2003 bereitgestellten MNS-Implementierung wird ein Verzeichnis auf den lokalen Laufwerken der einzelnen Knoten verwendet, um die Quorumdaten zu speichern. Wenn sich die Konfiguration des Clusters ändert, wird diese Änderung auf die lokalen Laufwerke aller Knoten übertragen. Die Änderung wird nur wirksam und dauerhaft, wenn sie bei einer Mindestzahl an Knoten implementiert wurde. Diese errechnet sich wie folgt: (Anzahl der Knoten/2) + 1.
Das MNS-Quorum stellt sicher, dass die meisten der Knoten über eine aktuelle Kopie der Daten verfügen. Ressourcen werden vom Clusterdienst nur gestartet und online geschaltet, wenn die Mehrheit der Knoten, die als Teil des Clusters konfiguriert sind, aktiv sind und den Clusterdienst ausführen. Wenn das MNS-Quorum feststellt, dass keine Mehrheit vorhanden ist, wird der Cluster als quorumlos betrachtet, und der Clusterdienst wartet in einer Neustartschleife, bis weitere Knoten beizutreten versuchen. Wenn eine Mehrheit oder ein Quorum der Knoten verfügbar ist, wird der Clusterdienst gestartet, und die Ressourcen werden online geschaltet. Da die aktuelle Konfiguration in den meisten Knoten gespeichert wird, ist im Cluster unabhängig von Knotenfehlern immer garantiert, dass beim Start die neueste Konfiguration verfügbar ist.
Wenn ein Clusterfehler auftritt oder ein zerteiltes Clusterszenario entsteht, werden alle Partitionen, die keine Mehrheit an Knoten enthalten, offline geschaltet. Mit der Ausführung einer Partition, die die Mehrzahl der Knoten enthält, ist somit gewährleistet, dass beliebige Ressourcen sicher gestartet werden können, die nicht auf dieser Partition ausgeführt werden, da diese Partition als einzige im Cluster Ressourcen ausführt.
Wegen der Unterschiede im Verhalten zwischen Quorumclustern mit gemeinsamen Laufwerken und MNS-Quorumclustern sollten Sie bei der Auswahl des Modells vorsichtig vorgehen. Wenn sich beispielsweise nur zwei Knoten in einem Cluster befinden, ist das MNS-Modell nicht zu empfehlen. Hierbei führt der Ausfall eines Knotens zum Ausfall des gesamten Clusters, da eine Mehrzahl an Knoten nicht erreichbar ist.
Hauptknotensatzquoren sind bei Clustern mit Windows Server 2003 Enterprise Edition und Windows Server 2003 Datacenter Edition verfügbar. MNS-Cluster bieten für Exchange-Cluster lediglich den Vorteil, dass ein fest zugewiesenes Laufwerk im gemeinsamen Speicherarray für die Quorumressource überflüssig wird.
648
ClusterressourcenDer Clusterdienst verwaltet mithilfe der Ressourcenmonitore und der Ressourcen-DLLs alle Ressourcenobjekte. Die Schnittstelle des Ressourcenmonitors stellt die Standardkommunikationsschnittstelle bereit, durch die der Clusterdienst Ressourcenverwaltungsbefehle erteilen und Daten über den Ressourcenstatus erhalten kann. Der Ressourcenmonitor erhält aktuelle Befehlsfunktionen und Daten durch Ressourcen-DLLs. Anhand von Ressourcen-DLLs schaltet der Clusterdienst Ressourcen online, verwaltet deren Interaktion mit anderen Ressourcen des Clusters und überwacht deren Zustand.
Für die Ressourcenverwaltung verwendet eine Ressourcen-DLL einige einfache Ressourcenschnittstellen und -eigenschaften. Eine spezielle Ressourcen-DLL wird als privilegierter Code, der unter dem SYSTEM-Konto ausgeführt wird, in den Adressraum des Ressourcenmonitors geladen. Bei dem SYSTEM-Konto (d. h. LocalSystem) handelt es sich um ein Sicherheitsprinzipalkonto, das für das Betriebssystem steht. Der Clusterdienst, unter einem Benutzersicherheitskontext ausgeführt, führt mit dem SYSTEM-Konto Sicherheitsfunktionen innerhalb des Betriebssystems durch.
Wenn die Funktionsfähigkeit von Ressourcen von der Verfügbarkeit anderer Ressourcen abhängig ist, können diese Abhängigkeiten mit der Ressourcen-DLL festgelegt werden. Wenn eine Ressource von anderen Ressourcen abhängig ist, wird diese vom Clusterdienst nur online gestellt, wenn die dafür notwendigen Ressourcen in der richtigen Reihenfolge online gestellt werden konnten.
Die Ressourcen werden auf ähnliche Weise offline gestellt. Ressourcen werden vom Clusterdienst nur offline gestellt, nachdem alle abhängigen Ressourcen offline gestellt wurden. Dadurch werden beim Laden von Ressourcen zirkuläre Abhängigkeiten vermieden.
Mit jeder Ressourcen-DLL kann außerdem der Computertyp und die von der Ressource benötigte Geräteverbindung festgelegt werden. Beispiel: Eine Laufwerkressource darf möglicherweise nur in Besitz eines Knotens sein, der physisch mit einem Laufwerk verbunden ist. Lokale Neustartrichtlinien und gewünschte Aktionen während eines Failovers können ebenfalls in der Ressourcen-DLL festgelegt werden.
ClusterverwaltungCluster werden mithilfe der Clusterverwaltung verwaltet. Bei der Clusterverwaltung handelt es sich um ein grafisches Verwaltungstool, mit dessen Hilfe das Befehlszeilentool Cluster.exe die Wartung, Überwachung und Failoververwaltung durchführen kann. Servercluster stellen außerdem eine Automationsschnittstelle bereit. Diese Schnittstelle kann zur Erstellung benutzerdefinierter Skripttools für die Verwaltung von Clusterressourcen, Knoten und dem Cluster selbst verwendet werden. Anwendungen und Verwaltungstools, z. B. die Clusterverwaltung, haben mithilfe von RPCs Zugriff auf diese Schnittstelle. Dabei kann das Tool auf einem Knoten des Clusters oder auf einem externen Computer ausgeführt werden.
649
Struktur und Ausführung eines ClustersWird der Clusterdienst auf einem Server installiert und ausgeführt, kann der Server Teil eines Clusters sein. Clusterfunktionen verringern die Anzahl der Fehlerquellen und ermöglichen eine hohe Verfügbarkeit der Clusterressourcen. In den folgenden Abschnitten wird das Verhalten eines Knotens während der Erstellung und Ausführung eines Clusters kurz erklärt.
Erstellen eines ClustersServercluster enthalten ein Clusterinstallationsdienstprogramm, mit dem Clustersoftware auf einem Server installiert und ein neuer Cluster erstellt wird. Hierzu wird das Dienstprogramm auf dem Computer ausgeführt, der als erstes Mitglied des Clusters ausgewählt wird. In diesem ersten Schritt wird der Cluster durch Festlegen eines Clusternamens sowie durch Erstellen der Clusterdatenbank und der anfänglichen Clustermitgliedschaftsliste definiert.
Im nächsten Schritt der Erstellung eines Clusters werden gemeinsame Datenspeichergeräte hinzugefügt, die für alle Mitglieder des Clusters verfügbar sind. Dadurch wird der neue Cluster mit einem Knoten und seinen eigenen lokalen Datenspeichergeräten sowie gemeinsamen Clusterressourcen eingerichtet (im Allgemeinen Laufwerkressourcen oder Datenspeicher- und Verbindungsmedienressourcen).
Im letzten Schritt der Erstellung wird das Installationsdienstprogramm auf jedem weiteren Computer ausgeführt, der Mitglied des Clusters werden soll. Sobald dem Cluster ein neuer Knoten hinzugefügt wird, erhält dieser automatisch vom ursprünglichen Mitglied des Clusters eine Kopie der bestehenden Clusterdatenbank. Wenn ein Knoten einem Cluster beitritt oder einen Cluster bildet, aktualisiert der Clusterdienst die Kopie der Konfigurationsdatenbank für diesen Knoten.
Bilden eines ClustersEin Server kann einen Cluster bilden, wenn auf ihm der Clusterdienst ausgeführt wird und kein anderer Knoten im Cluster lokalisiert werden kann. Hierzu muss ein Knoten den exklusiven Besitz der Quorumressource übernehmen können.
Wenn ein Cluster gebildet wird, enthält der erste Knoten im Cluster die Clusterkonfigurationsdatenbank. Sobald ein Knoten dem Cluster beitritt, empfängt und speichert dieser seine eigene lokale Kopie dieser Konfigurationsdatenbank. In der Quorumressource wird die aktuellste Version der Konfigurationsdatenbank in Form von Wiederherstellungsprotokollen gespeichert. Die Protokolle enthalten von den Knoten unabhängige Daten zu Clusterkonfiguration und Status.
Beim Ausführen von Clusterfunktionen verwendet der Clusterdienst die Quorum-Wiederherstellungsprotokolle, um Folgendes sicherzustellen:
Nur ein einziger Satz aktiver Knoten ist berechtigt, einen Cluster zu bilden.
650
Ein Knoten darf nur dann einen Cluster bilden, wenn dieser Knoten die Besitzrechte an der Quorumressource erfolgreich übernehmen kann.
Ein Knoten darf einem vorhandenen Cluster nur beitreten oder in diesem bleiben, wenn der betreffende Knoten mit dem Knoten kommunizieren kann, der über die Besitzrechte an der Quorumressource verfügt.
Wenn ein Cluster gebildet wird, kann sich jeder Knoten des Clusters in einem von drei unterschiedlichen Zuständen befinden. Diese Zustände werden vom Ereignisprozessor festgehalten (weiter unten beschrieben) und vom Ereignisprotokoll-Manager an andere Knoten des Clusters repliziert. Der Clusterdienst kann die folgenden drei Zustände aufweisen:
Offline: Der Knoten ist kein aktives Mitglied des Clusters. Der Knoten und sein Clusterdienst werden möglicherweise ausgeführt.
Online: Der Knoten ist aktives Mitglied des Clusters. Er hält die Clusterdatenbank-Aktualisierungen ein, sendet Daten an den Quorumalgorithmus, behält den Clusternetzwerk- und Speichertakt bei und kann Ressourcengruppen besitzen und ausführen.
Angehalten: Der Knoten ist aktives Mitglied des Clusters. Der Knoten hält die Clusterdatenbank-Aktualisierungen ein, sendet Daten an den Quorumalgorithmus und behält den Clusternetzwerk- und Speichertakt bei, kann jedoch keine Ressourcengruppen akzeptieren. Er kann nur die Ressourcengruppen unterstützen, die sich derzeit in seinem Besitz befinden. In diesem Zustand können Wartungsarbeiten durchgeführt werden. Die Zustände Online und Angehalten werden von der Mehrzahl der Serverclusterkomponenten als gleichwertig angesehen.
Beitreten zu einem ClusterFür den Beitritt zu einem bestehenden Cluster muss ein Server den Clusterdienst ausführen und erfolgreich einen anderen Knoten des Clusters lokalisieren. Nachdem ein anderer Knoten des Clusters gefunden wurde, muss der beitretende Server für die Mitgliedschaft im Cluster authentifiziert werden und eine replizierte Kopie der Clusterkonfigurationsdatenbank empfangen.
Der Beitritt zu einem bestehenden Cluster beginnt, wenn der Dienststeuerungs-Manager von Windows den Clusterdienst auf dem Knoten startet. Während des Startvorgangs konfiguriert der Clusterdienst die lokalen Datengeräte des Knotens und stellt diese bereit. Dabei wird nicht versucht, die gemeinsamen Clusterdatengeräte als Knoten online zu stellen, da diese vom bestehenden Cluster verwendet werden könnten.
Zur Lokalisierung anderer Knoten wird ein Suchvorgang gestartet. Wenn der Knoten ein Mitglied des Clusters erkennt, wird ein Authentifizierungsvorgang gestartet. Das erste Clustermitglied authentifiziert den neuen Knoten und gibt den Status „Erfolgreich“ zurück, wenn die Authentifizierung erfolgreich war. Andernfalls – wenn der beitretende Knoten
651
beispielsweise nicht als Clustermitglied erkannt wird oder sein Kontokennwort ungültig ist – wird der Beitritt zum Cluster verweigert.
Nach erfolgreicher Authentifizierung überprüft der erste Knoten im Cluster, der online ist, die Kopie der Konfigurationsdatenbank des beitretenden Knotens. Wenn diese veraltet ist, sendet der Clusterknoten eine aktuelle Kopie der Datenbank an den beitretenden Server. Nach dem Empfang der replizierten Datenbank kann der beitretende Knoten sie zur Suche nach gemeinsamen Ressourcen verwenden und diese bei Bedarf online stellen.
Verlassen eines ClustersEin Knoten kann einen Cluster verlassen, wenn er heruntergefahren wird oder der Clusterdienst beendet wird. Ein Knoten kann jedoch auch aus einem Cluster ausgeschlossen werden, wenn er Clustervorgänge nicht ausführen kann (z. B. das Senden einer Aktualisierung an die Clusterkonfigurationsdatenbank).
Wenn ein Knoten einen Cluster verlässt, z. B. durch geplantes Herunterfahren, sendet er zur Information hierüber eine ClusterExit-Nachricht an alle anderen Mitglieder des Clusters. Der Knoten wartet nicht auf Antworten, sondern fährt umgehend die Ressourcen herunter und beendet alle Clusterverbindungen. Da die verbleibenden Knoten diese Beendigungsmeldung erhalten, wird eine Neugruppierung zum Wiederherstellen der Clustermitgliedschaft nicht durchgeführt, die bei einem unerwarteten Ausfall eines Knotens oder einer Unterbrechung der Netzwerkkommunikation erfolgt.
AusfallerkennungAusfallerkennung und -vermeidung sind entscheidende Vorteile des Serverclusters. Wenn ein Knoten oder eine Anwendung in einem Cluster ausfällt, können Servercluster darauf reagieren, indem die Anwendung neu gestartet wird oder die Aufgaben des ausgefallenen Systems auf verbleibende Knoten des Clusters verteilt werden. Die Ausfallerkennung und -vermeidung in Serverclustern umfasst bidirektionale Failover, Anwendungsfailover, parallele Wiederherstellung sowie automatisches Failback.
Wenn der Clusterdienst Ausfälle einzelner Ressourcen oder eines gesamten Knotens erkennt, werden Anwendungen, Daten und Dateiressourcen auf verfügbare, funktionierende Server des Clusters dynamisch verschoben bzw. neu gestartet. Dadurch wird eine hohe Verfügbarkeit von Ressourcen wie Datenbanken, Dateifreigaben und Anwendungen für Benutzer und Clientanwendungen erreicht.
Servercluster sind mit zwei verschiedenen Mechanismen zur Ausfallerkennung ausgerüstet:
„Heartbeats“ zum Erkennen von Knotenausfällen: In regelmäßigen Abständen werden zwischen den Knoten des Clusters UDP-Nachrichten (User Datagram Protocol) über das private Clusternetzwerk ausgetauscht. Diese Nachrichten werden als „Heartbeats“ bezeichnet. Mithilfe des Heartbeat-Austauschs können Knoten die
652
Verfügbarkeit anderer Knoten und ihrer Ressourcen überprüfen. Wenn ein Server auf einen Heartbeat-Austausch nicht antwortet, lösen die verbleibenden Server Failovervorgänge aus, z. B. die Zuteilung des Besitzes von Ressourcen und Anwendungen des ausgefallenen Servers. Die Zuteilung erfolgt mithilfe eines Anforderungs-/Abwehr-Protokolls. Dem anscheinend ausgefallenen Knoten wird ein Zeitraum vorgegeben, in dem er auf bestimmte Weise anzeigen soll, ob er ordnungsgemäß funktioniert und mit den verbleibenden Knoten kommunizieren kann. Wenn der Knoten nicht antwortet, wird er aus dem Cluster entfernt.
Ausbleibende Antworten auf Heartbeat-Nachrichten können durch verschiedene Ereignisse verursacht werden, z. B. Computerfehler, Fehler der Netzwerkschnittstelle, Netzwerkfehler oder auch ungewöhnlich hohe Aktivität. Wenn alle Knoten kommunizieren, sendet der Konfigurationsdatenbank-Manager üblicherweise globale Aktualisierungen der Konfigurationsdatenbank an jeden Knoten. Wenn ein Fehler bei einem Heartbeat-Austausch auftritt, speichert der Protokoll-Manager die Änderungen der Konfigurationsdatenbank in der Quorumressource. Dadurch haben die verbleibenden Knoten während des Wiederherstellungsvorgangs Zugriff auf die aktuelle Clusterkonfiguration und die lokalen Knotenregistrierungsdaten.
Der Algorithmus zur Ausfallerkennung ist sehr konservativ ausgelegt. Wenn die Ursache für die ausbleibende Heartbeat-Antwort nur vorübergehend besteht, empfiehlt es sich, eine mögliche Unterbrechung durch einen Failover zu vermeiden. Es kann jedoch nicht ermittelt werden, ob der Knoten in der nächsten Millisekunde antwortet oder ob ein schwerwiegender Fehler aufgetreten ist. Daher wird ein Failover nach Ablauf eines Timeouts ausgelöst.
Ressourcenmonitor und Ressourcen-DLLs zum Erkennen von Ressourcenausfällen: Der Failover-Manager und der Ressourcenmonitor arbeiten zusammen, um Ressourcenausfälle zu erkennen und zu beheben. Die Ressourcenmonitore fragen den Ressourcenstatus regelmäßig mithilfe der Ressourcen-DLLs ab. Das Abrufen umfasst zwei Schritte, eine flüchtige LooksAlive-Abfrage und eine längere und genauere Lebenszyklusabfrage (IsAlive). Wenn der Ressourcenmonitor einen Ressourcenausfall erkennt, benachrichtigt er den Failover-Manager und fährt mit der Überwachung der Ressource fort.
Der Failover-Manager verwaltet die Ressourcen und den Ressourcengruppenstatus. Außerdem führt er bei einem Ressourcenausfall die Wiederherstellung durch und ruft als Antwort auf Benutzeraktionen oder Fehler Ressourcenmonitore auf.
Nachdem ein Ressourcenausfall erkannt wird, führt der Failover-Manager Wiederherstellungsaktionen durch, z. B. den Neustart einer Ressource und der abhängigen Ressourcen oder die Verschiebung der gesamten Ressourcengruppe auf einen anderen Knoten. Die durchgeführte Wiederherstellungsaktion wird neben der Knotenverfügbarkeit von den Ressourcen- und Ressourcengruppeneigenschaften bestimmt.
653
Während des Failovers wird die Ressourcengruppe als Failovereinheit behandelt. Dadurch wird die ordnungsgemäße Wiederherstellung der Ressourcenabhängigkeiten gewährleistet. Wenn eine Ressource nach einem Ausfall wiederhergestellt wird, benachrichtigt der Ressourcenmonitor den Failover-Manager. Der Failover-Manager führt dann automatisch anhand der Konfiguration der Failbackeigenschaften der Ressourcengruppe ein Failback der Ressourcengruppe durch.
Virtuelle Exchange-ServerEin virtueller Exchange-Server ist eine Exchange-Installation in Clustern. Wird Exchange in einem Windows Server 2003-Cluster installiert, wird es als virtueller Exchange-Server konfiguriert, der für Exchange-Clients unsichtbar zwischen Clusterknoten verschoben werden kann.
Wenn Sie Exchange auf einem Clusterknoten installieren, kopiert das Exchange-Setupprogramm die Programmdateien auf das lokale Laufwerk des Clusterknotens. In einem Cluster mit zwei Knoten, z. B. Knoten A und Knoten B, kopiert das Setupprogramm die Exchange-Programmdateien auf die Festplatte von Knoten A. Führen Sie anschließend das Setupprogramm ein zweites Mal aus, um die Exchange-Programmdateien auf der lokalen Festplatte des zweiten Knotens zu installieren.
Sind die Exchange-Programmdateien auf den Festplatten beider Knoten installiert, konfigurieren Sie eine Ressourcengruppe für die Exchange-Ressourcen. Wie bereits erwähnt, ist eine Ressourcengruppe als logischer Container definiert, der Ressourcen für eine Instanz des virtuellen Exchange-Servers enthält. Diese Instanz des virtuellen Exchange-Servers hat viele Ressourcen, über die auch physische Exchange-Server verfügen, z. B.:
Einen Netzwerknamen
Eine IP-Adresse
Speicher (SCSI oder Fibre Channel)
Nachdem Sie ein Minimum der oben stehenden Ressourcen des virtuellen Exchange-Servers erstellt haben, müssen Sie eine Systemaufsicht-Ressource erstellen. Die Systemaufsicht erstellt die zusätzlichen Ressourcen, aus denen ein virtueller Exchange-Server besteht. Diese Ressourcen können offline oder online gestellt werden. Das entspricht dem Beenden des Diensts bzw. dem Starten des Diensts. Sie können außerdem den aktuellen Ressourceninhaber (den Clusterknoten) ändern. Beispielsweise können Sie anstelle von Knoten A Knoten B dafür konfigurieren, diese Ressource zu besitzen und auszuführen.
Die Systemaufsicht-Ressource wird immer manuell erstellt. Andere auf den Exchange-Dienst bezogene Ressourcen werden automatisch erstellt, sobald die Systemaufsicht-Ressource erstellt wurde. Bei Fertigstellung werden die Änderungen in den Microsoft Active Directory®-Verzeichnisdienst geschrieben, und ein Objekt für diesen Exchange-basierten Server wird im Servercontainer Ihrer administrativen Gruppe aufgelistet.
654
Hinweis: In Exchange Server 2003 wurden mehrere sicherheitsbedingte Änderungen vorgenommen. Das Sicherheitsmodell ist somit noch solider als in Exchange 2000 Server. Wenn Sie beispielsweise in einer Clusterumgebung einen virtuellen Exchange Server 2003-Server erstellen, werden die IMAP4- und POP3-Clusterressourcen in der Standardeinstellung nicht automatisch erstellt. Wenn Sie diese Dienste in einem Cluster verwenden möchten, müssen Sie den entsprechenden Dienst auf einem Clusterknoten starten und die Ressource manuell erstellen. Weitere Informationen finden Sie im Microsoft Knowledge Base-Artikel 824127 HOW TO: Create an IMAP4 or a POP3 Cluster Resource on an Exchange Server 2003 Virtual Server .
Ein virtueller Exchange-Server ist eine Zusammenstellung von Exchange-Ressourcen. Jede Ressource verfügt über Eigenschaften, z. B. Ressourcenabhängigkeiten, mögliche Besitzer und Wiederholungswerte. Jede Ressource eines virtuellen Exchange-Servers stellt eine andere Komponente von Exchange dar.
Exchange-Komponenten in einem ClusterKomponenten und virtuelle Server, die in einem Windows Server 2003-Cluster ausgeführt werden, unterstützen die Aktiv/Aktiv- oder Aktiv/Passiv-Funktion oder auch beide. Die für Windows Server 2003-Cluster verfügbaren Exchange-spezifischen Ressourcen sind in der folgenden Tabelle aufgelistet.
Exchange Server 2003-Komponenten in einem Servercluster
Komponente Funktion Anmerkungen
Microsoft Exchange-Systemaufsichtsdienst
Aktiv/Aktiv Mehrere virtuelle Server pro Knoten in Clustern mit höchstens zwei Knoten. Cluster mit mehr als zwei Knoten unterstützen nur Aktiv/Passiv-Systemaufsichtsressourcen.
Microsoft Exchange-Informationsspeicherdienst
Aktiv/Aktiv Maximal vier Speichergruppen pro Knoten.
Message Transfer Agent Aktiv/Passiv Eine Instanz pro Cluster. Immer im Besitz des ersten im Cluster erstellten virtuellen Exchange-Servers.
655
Komponente Funktion Anmerkungen
Routingmodul Aktiv/Aktiv
POP3 Aktiv/Aktiv Mehrere virtuelle Server pro Knoten. Müssen vom Administrator manuell erstellt werden.
IMAP4 Aktiv/Aktiv Mehrere virtuelle Server pro Knoten. Müssen vom Administrator manuell erstellt werden.
SMTP Aktiv/Aktiv Mehrere virtuelle Server pro Knoten.
HTTP Aktiv/Aktiv Mehrere virtuelle Server pro Knoten.
Microsoft Search Aktiv/Aktiv
NNTP Nicht unterstützt IIS-/NNTP-Komponente (Internetinformationsdienst/ Network News Transfer Protocol) wird für die Installation von Exchange benötigt.
Exchange Connector für Novell GroupWise
Nicht unterstützt
Exchange Connector für Lotus Notes
Nicht unterstützt
Microsoft Exchange-Ereignis Nicht unterstützt
Aktiv/Aktiv-ClusterExchange 2003 unterstützt Aktiv/Aktiv-Cluster mit zwei Knoten. In Clustern mit mehr als zwei Knoten muss das Aktiv/Passiv-Clustering verwendet werden. In einem Aktiv/Aktiv-Exchange-Cluster gibt es mehrere virtuelle Exchange-Server, die mit gewissen Einschränkungen zwischen den verschiedenen Knoten des Clusters verschoben und gleichzeitig auf einem Knoten ausgeführt werden können.
In Aktiv/Aktiv-Clustern können Anwendungen und Ressourcen in mehreren Instanzen existieren. Daher können beide Knoten Clients aktiv Dienste zur Verfügung stellen. In
656
Exchange 2003-Aktiv/Aktiv-Clustern entspricht die Anzahl der virtuellen Exchange-Server mindestens der Anzahl der physischen Knoten im Cluster. Aktiv/Aktiv-Exchange-Cluster sind nur in Clustern mit höchstens zwei Knoten möglich. Wenn Sie über mehr als zwei Knoten in Ihrem Cluster verfügen, müssen Sie das Aktiv/Passiv-Clustermodell anwenden.
In den meisten Fällen wird jeder virtuelle Exchange-Server im Cluster auf einem separaten Knoten ausgeführt. Fällt Hardware aus oder wird ein Knoten offline gestellt, erkennt der andere Knoten die Änderung und führt entsprechend der konfigurierten Failover-Richtlinien Aktionen durch. Im Allgemeinen bedeutet das, der verbleibende Knoten übernimmt den Besitz des virtuellen Exchange-Servers, der auf dem ersten Knoten ausgeführt wurde. Wenn in einem Cluster mit zwei Knoten beispielsweise Knoten A offline ist, übernimmt Knoten B den Besitz des virtuellen Exchange-Servers. Knoten B ist dann im Besitz beider gemeinsamer Datenträgersysteme, beider IP-Adressen, beider Netzwerknamen und aller weiteren Exchange-Ressourcen des Clusters. Ist Knoten A wieder online, wird je nach Konfiguration der Failback-Richtlinien ein Failback durchgeführt oder nicht.
Auch wenn Aktiv/Aktiv-Cluster unterstützt werden, sollten Sie aus folgenden Gründen Aktiv/Passiv-Exchange-Cluster verwenden:
Skalierbarkeit In einem Aktiv/Aktiv-Exchange-Cluster kann jeder physische Knoten nicht mehr als 1.900 MAPI-Verbindungen gleichzeitig verwalten oder durchgängig mehr als 40 Prozent der gesamten verfügbaren CPU-Zeit in Anspruch nehmen.
VS-Fragmentierung Aktiv/Aktiv-Cluster sind anfälliger für die Fragmentierung des virtuellen Speichers als Aktiv/Passiv-Cluster und Exchange-Server ohne Cluster. Der Grund dafür liegt in den verschiedenen Instanzen von ESE (Extensible Storage Engine), die im gleichen STORE.EXE-Prozess ausgeführt werden.
Leistung Im Fall eines Failovers in einem Aktiv/Aktiv-Exchange-Cluster verfügt der verbleibende Knoten über mehr als einen virtuellen Exchange-Server. Dadurch wird die Leistung für die Benutzer beider virtueller Exchange-Server so lange beeinträchtigt, bis der ausgefallene Knoten seine Arbeitslast wieder übernimmt.
Weitere Informationen zur Clusterbildung mit Windows Server 2003 und Exchange Server 2003 finden Sie in Using Clustering with Exchange 2003: An Example .
Aktiv/Passiv-ClusterIn einem Aktiv/Passiv-Cluster werden Clients mit einem virtuellen Exchange-Server verbunden, der sich zu dem Zeitpunkt im Besitz eines Knotens des Clusters befindet (z. B. Knoten A). Der Knoten steuert das gemeinsame Datenträgersystem, das die Exchange-Datenbanken enthält. Tritt bei Knoten A ein Hardwarefehler auf oder wird er auf andere Weise offline gestellt, erkennt Knoten B den Fehler und übernimmt den Besitz des virtuellen Exchange-Servers und all seiner verknüpften Ressourcen.
Beim Aktiv/Passiv-Clustermodell werden die Anwendungen als einzelne Instanz im Cluster ausgeführt. Das bedeutet, dass ein Knoten sich üblicherweise im Leerlauf befindet (passiv
657
ist), bis es zu einem Failover kommt. Im Zusammenhang mit Exchange 2003-Clustern bedeutet Aktiv/Passiv-Clustering, dass die Anzahl virtueller Exchange-Server kleiner ist als die der physischen Knoten des Clusters. In der folgenden Abbildung wird ein Beispiel des Aktiv/Passiv-Clustermodells gezeigt.
Aktiv/Passiv-Exchange 2003-Servercluster mit vier Knoten
Das Aktiv/Passiv-Clustermodell ist für Exchange 2003 dringend zu bevorzugen. Aktiv/Passiv-Clusterkonfigurationen sind sehr gut skalierbar und aus verschiedenen Gründen administrativ weniger aufwändig als Aktiv/Aktiv-Cluster:
Aktiv/Aktiv-Cluster sind auf 1.900 gleichzeitige MAPI-Clientverbindungen pro Knoten begrenzt.
Aktiv/Aktiv-Cluster müssen durchgängig überwacht werden, um sicherzustellen, dass der STORE.EXE-Prozess 40 Prozent der gesamten verfügbaren CPU-Zeit auf jedem Knoten nicht überschreitet.
Aktiv/Aktiv-Cluster sind anfälliger für die Fragmentierung des virtuellen Speichers, da mehrere Instanzen von ESE im gleichen STORE.EXE-Prozess ausgeführt werden.
Aktiv/Passiv-Exchange-Cluster müssen unabhängig von ihrer Größe mindestens einen passiven Knoten beinhalten. Außerdem darf auf allen Knoten zu jeder Zeit nur jeweils ein virtueller Exchange-Server ausgeführt werden.
658
RessourcenabhängigkeitenWie in der Abbildung weiter unten gezeigt wird, sind die Exchange-bezogenen Ressourcen direkt von der Systemaufsichtsressource abhängig. Die Systemaufsichtsressource ist wiederum von den physischen Laufwerk- und den Netzwerknamenressourcen abhängig. Die Netzwerknamenressource ist abhängig von der IP-Adressenressource. Umfasst ein virtueller Exchange-Server mehrere physische Laufwerkressourcen, muss die Systemaufsichtsressource in Abhängigkeit aller stehen.
Microsoft Exchange-SystemaufsichtsdienstDie in der folgenden Abbildung gezeigten Abhängigkeiten werden zusammen mit dem Microsoft Exchange-Systemaufsichtsdienst erstellt. Die Systemaufsicht ist die grundlegende Ressource, über die das Erstellen und Löschen aller Ressourcen des virtuellen Exchange-Servers gesteuert wird.
Exchange-Ressourcenabhängigkeiten im virtuellen Exchange-Server
Diese Ressourcen werden zusammen mit der Systemaufsichtsressource erstellt. Um den Server und dessen Objekte aus Active Directory zu löschen, entfernen Sie den virtuellen Exchange-Server mithilfe der Clusterverwaltung. Mit dem „IsAlive“-Aufruf an die Systemaufsicht wird dem Dienststeuerungs-Manager der aktuelle Status der Systemaufsicht übermittelt.
659
Microsoft Exchange-InformationsspeicherdienstMit der Online-Stellung des Microsoft Exchange-Informationsspeicherdiensts wird der Dienst gestartet (STORE.exe), und mit der Bereitstellung der Speichergruppen begonnen. Sobald alle Speichergruppen bereitgestellt sind und der Speicher die bestehenden Transaktionsprotokolle verarbeitet hat, gilt die Ressource als online. Mit dem „IsAlive“-Aufruf an den Microsoft Exchange-Informationsspeicherdienst wird ein RPC an den STORE.exe-Prozess gesendet. Für den Prozess wird mit der Überprüfung lediglich bestätigt, dass sich der Name des virtuellen Servers in der Liste aktiver virtueller Server befindet.
Message Transfer AgentBei der Message Transfer Agent-Ressource (MTA) handelt es sich um eine Aktiv/Passiv-Ressource. Pro Cluster kann nur ein MTA verwendet werden. Der MTA wird auf dem ersten virtuellen Exchange-Server eines Clusters erstellt und kann nicht auf einen anderen virtuellen Exchange-Server verschoben werden. Aus diesem Grund ist der erste virtuelle Exchange-Server, den Sie in einem Cluster erstellen, auch der letzte virtuelle Exchange-Server, der aus dem Cluster entfernt werden kann.
Obwohl der MTA eine Aktiv/Passiv-Ressource ist, werden von ihm alle virtuellen Server des Clusters bedient, während er online ist. Mit dem „IsAlive“-Aufruf an den MTA wird dem Dienststeuerungs-Manager der aktuelle Status des MTA übermittelt.
ProtokolleDer „IsALive“-Aufruf funktioniert bei allen Protokollen auf die gleiche Weise. EXRES.DLL öffnet für das Protokoll einen TCP-Anschluss mithilfe der Bindungen, die von der Metabase des Internetinformationsdiensts (IIS) bereitgestellt werden. Eine Antwort in Form eines Banners wird erwartet. Stimmt der Start des Banners mit dem erwarteten Wert überein, wird die Ressource als online betrachtet. Wird der Banner nicht innerhalb des Timeout zurückgegeben, stellt der Clusterdienst fest, dass der virtuelle Server für das Protokoll nicht verfügbar ist und der „IsAlive“-Aufruf nicht erfolgreich war.
Keines der Protokolle darf dafür konfiguriert sein, alle Verbindungen von allen Servern abzuweisen. Andernfalls weist der virtuelle Protokollserver an ihn gerichtete „IsAlive“-Aufrufe ab. Aus diesem Grund muss jeder virtuelle Protokollserver Verbindungen von seiner eigenen IP-Adresse aus akzeptieren. Für das HTTP-Protokoll sendet EXRES.DLL einen WebDAV-Track-Befehl, um eine Antwort zu erhalten.
Wird ein virtueller Exchange-Server offline gestellt, werden alle Instanzen des virtuellen SMTP-Protokollservers kurz beendet und neu gestartet, um zu gewährleisten, dass der Speichertreiber ordnungsgemäß registriert wurde. Das bedeutet, dass die SMTP-Ressourcen aller virtuellen Exchange-Server auf dem Knoten schnell offline gestellt und neu gestartet
660
werden. Die SMTP-Ressource wird nicht automatisch neu gestartet, wenn die Option Nicht neu starten in den Eigenschaften aktiviert wurde.
Microsoft SearchDie MSSearch-Ressource bietet Inhaltsindizierung für virtuelle Exchange-Server. Der „IsAlive“-Aufruf an den MSSearch-Prozess gibt einen Zeiger auf die Datenstruktur für die zu indizierende Datenbank zurück. Ist der Zeiger gültig, arbeitet die Ressource ordnungsgemäß.
Zum Wiederherstellen der MSSearch-Ressource nach deren Löschung müssen Sie die Informationsspeicherdienst-Ressource von Microsoft Exchange für diesen virtuellen Exchange-Server löschen und neu erstellen. Weitere Informationen finden Sie im Microsoft Knowledge Base-Artikel 830189 „Exchange Server 2003 computer cannot bring the Microsoft Search resource online“.
Interaktion von Exchange-ClusternExchange 2003 ist clustergestützt und stellt seine eigene Clusterressourcen-DLL mit dem Namen EXRES.DLL bereit. Sie dient der Kommunikation und Interaktion mit dem Windows-Clusterdienst. Der Windows-Clusterdienst kommuniziert mittels des Ressourcenmonitors mit EXRES.DLL, und EXRES.DLL kommuniziert mit den Exchange-Komponenten. EXRES.DLL übersetzt die Clustervorgänge in Aktionen für Exchange-bezogene Dienste. EXRES.DLL überwacht außerdem die Beendigung dieser Ressourcen und benachrichtigt den Clusterdienst, wenn der Vorgang fehlschlägt. In Abbildung 11.4 wird die Beziehung zwischen EXRES.DLL und dem Clusterdienst verdeutlicht.
661
Interaktion zwischen ExRes.dll und dem Windows-Clusterdienst
In einem Cluster ist der Clusterdienst für das Starten und Beenden von Exchange-Diensten mittels EXRES.DLL zuständig. Daher sollte ein Administrator einen Dienst nicht über die Befehlszeile, das Snap-In für Windows-Dienste, ein Resource Kit-Tool oder eine Anwendung von Drittanbietern beenden. Wenn Sie einen Dienst außerhalb des Clusters beenden, schlägt der „IsAlive“-Aufruf zu diesem Dienst fehl, und der Clusterdienst versucht, den Dienst neu zu starten. Die Funktion IsAlive gibt den letzten vom Ressourcenzustandüberwachungs-Thread aufgezeichneten Wert zurück. Die Funktion LooksAlive ist auf die gleiche Weise implementiert wie die Funktion IsAlive. Die Funktion LooksAlive wird nicht aufgerufen, da EXRES.DLL Ereigniszugriffsnummern für Ressourcenfehler an den Ressourcenmonitor des Clusters weitergibt, der einen Ressourcenausfall anzeigt. Die Ressourcen werden vom Zustandsüberwachungsthread alle zehn Sekunden überprüft. Diese Ressourcenüberprüfung kann nicht konfiguriert werden. EXCLUADM.DLL stellt die Exchange- und Cluster-spezifischen Assistenten zugeordnete Schnittstelle bereit.
Die Funktionen ExchangeOpen/ExchangeCloseDie Funktionen ExchangeOpen und ExchangeClose werden immer dann aufgerufen, wenn die Exchange-Ressourcen auf den aktuellen Knoten verschoben werden. Innerhalb der Funktionen von ExchangeOpen wird der Arbeitsspeicher für die grundlegenden Informationen der Ressource initialisiert oder zugewiesen. Diese Funktionen verwalten außerdem das Laden und Entladen der DLL-Dateien, die von der Ressourcen-DLL verwendet werden. Dieser Vorgang wird mit Referenzzählern gesteuert.
662
Die Funktionen ExchangeOnline und ExchangeOfflineDie Funktionen ExchangeOnline und ExchangeOffline erstellen neue OnlineWrapperThread- und OfflineWrapperThread-Arbeitsthreads und geben umgehend ERROR_IO_PENDING an den Ressourcenmonitor des Clusters zurück. Wenn der Wrapperthread eine Fehlermeldung an den Ressourcenmonitor zurückgibt, versucht dieser zwei weitere Male, die Ressource neu zu starten. Während dieser Neustartversuche stellt die Funktion ExchangeOnline fest, ob der vorherige Online/Offline-Thread zurückgegeben wird. Wenn der Online/Offline-Thread nicht zurückgegeben wird, wird die Funtion ExchangeOnline neu gestartet.
Wenn für OfflineWrapperThread der Thread ExchangeOffline nicht innerhalb der zeitlichen Begrenzung PendingTimeOut für den Speicher, die Systemaufsicht und die MTA-Ressourcen zurückgegeben wird, beendet der Ressourcenmonitor den entsprechenden Vorgang.
Um Situationen zu vermeiden, in denen RPCs nicht reagieren, erstellen diese beiden Arbeitsthreads den richtigen Online/Offline-Thread. Die Wrapperthreads überwachen den Online/Offline-Thread und verwenden dazu Zeitgeber. Wird der Online/Offline-Thread nicht innerhalb des Werts PendingTimeOut zurückgegeben, der in der Clusterverwaltung angegeben wurde, erklärt der Wrapperthread den Vorgang für nicht erfolgreich und legt den Ressourcenstatus auf „Fehlgeschlagen“ fest. Anschließend gibt er eine Fehlermeldung zurück. Ausnahmen davon bestehen nur bei Aktualisierungsvorgängen oder Vorgängen bei Onlinespeicherressourcen. In diesen beiden Fällen wartet der Wrapperthread auf den Abschluss der Aktualisierung oder darauf, dass eine Speicherressource ohne Timeout online verfügbar ist.
ExchangeOnlineThread und ExchangeOfflineThread stehen folgenden Exchange-Ressourcen zur Verfügung:
Microsoft Exchange-Systemaufsichtsdienst, Microsoft Exchange-Informationsspeicherdienst und Routing: Jede dieser Ressourcen startet ggf. den Dienst und richtet RPCs an alle Dienste mit der Anforderung, den entsprechenden virtuellen Exchange-Server zu starten oder zu beenden.
Protokollressourcen: Protokollressourcen setzen das Befehlsbit in der IIS-Metabase und starten dann ggf. den Dienst. Der entsprechende Dienst nimmt den Befehl entgegen und startet oder beendet den virtuellen Server. Die einzige Ausnahme stellt der virtuelle SMTP-Server dar. In einem solchen Fall muss der gesamte SMTP-Dienst beendet werden, wenn eine virtuelle Serverinstanz offline gestellt wird. Die Funktion IsAlive sucht nach weiteren virtuellen Servern, die auf demselben Computer ausgeführt werden, erkennt, dass der entsprechende SMTP-Dienst beendet wurde, und startet den virtuellen Server neu.
663
ExchangeIsAlive und ExchangeLooksAliveDie Funktion ExchangeOnline gibt eine Ereigniszugriffsnummer an den Ressourcenmonitor zurück, und dieser beendet daraufhin den Aufruf der Funktion ExchangeLooksAlive. Stattdessen ruft der Ressourcenmonitor nun die Funktion ExchangeIsAlive in den Zeitabständen auf, die in der Clusterverwaltung als „Looks Alive“-Abrufintervalle festgelegt wurden. Wenn eine Ressource online gestellt wird, erstellt EXRES.DLL zwei Threads zur Überwachung des Status dieser Ressource. Der erste Thread mit dem Namen ExchangeIsAliveMonitor überprüft alle zehn Sekunden den Status der Ressource durch Aufruf des zweiten Threads mit dem Namen ExchangeCheckIsAliveWrapper. ExchangeCheckIsAliveWrapper führt die eigentliche Lebenszyklusprüfung (IsAlive) durch. Wenn der Thread ExchangeCheckIsAliveWrapper nicht innerhalb der zeitlichen Begrenzung PendingTimeOut zurückgegeben wird oder Fehler bei der Lebenszyklusprüfung auftreten, signalisiert der Thread ExchangeIsAliveMonitor dem Ressourcenmonitor für diese spezielle Ressource ein Fehlerereignis. Die Funktion ExchangeIsAlive gibt den Status der letzten Lebenszyklusprüfung zurück.
ExchangeTerminateDiese Funktion beendet den bestehenden Thread ExchangeIsAliveMonitor. Sie führt außerdem für den Exchange-Speicher, die Systemaufsicht und die MTA-Ressourcen die entsprechende Offlineprozedur durch, um zu gewährleisten, dass die Bereitstellung der Datenbank aufgehoben wurde. Wenn die Offlineprozedur nicht innerhalb der zeitlichen Begrenzung PendingTimeOut erfolgreich abgeschlossen werden kann, beendet EXRES.DLL ebenfalls den entsprechenden Prozess.
Erstellen von RessourcenZuerst erstellt der Benutzer eine Ressource und anschließend einen Aufruf an EXCLUADM.DLL, um Informationen anzufordern. EXCLUADM.DLL erhält die angeforderten Informationen für die Ressource und gibt sie an den Clusterdienst weiter. Der Ressourcenmonitor erstellt einen Aufruf an die Funktion ExchangeResourceControl in EXRES.DLL. Dieser Aufruf enthält die Informationen, die zuvor von EXCLUADM.DLL und Clusctl_Resource_Set_Private_Properties als Steuerungscode empfangen wurden. ExchangeSetPrivateResProperties wird zur Verarbeitung dieses Steuerungscodes verwendet. Zuerst werden die Informationen in der Clusterdatenbank unter dem Registrierungsschlüssel Parameters für diese Ressource gespeichert. Anschließend wird ein Aufruf an EXSETDATA.DLL mit der Aufforderung gesendet, Objekte in Acitve Directory zu erstellen. In einigen Fällen können Probleme auftreten, wenn Änderungen der Konfigurationsinformationen im Exchange-System-Manager vorgenommen, jedoch nicht mit der Clusterdatenbank synchronisiert wurden.
664
Clusterspezifische KonfigurationenIn den folgenden Abschnitten werden Konfigurationsänderungen beschrieben, die vorgenommen werden müssen, damit Vorgänge bestimmter Komponenten unterstützt werden, wenn sie in einem Exchange-Cluster ausgeführt werden. Wenn Exchange in einer Clusterumgebung installiert ist, müssen einige der üblichen Exchange-Aufgaben anders durchgeführt werden als bei einem Exchange-Server, der nicht in einer Clusterumgebung installiert ist.
Exchange-MTAIn der Standardeinstellung wird auf einem Exchange 2003-Server der MTA-Dienst überwacht. In einer Clusterumgebung wird der MTA-Dienst nur auf einem der physikalischen Knoten (Computer) ausgeführt. Im Ergebnis werden bei der Überwachung für alle Knoten ohne ausgeführten MTA-Dienst Fehlermeldungen protokolliert. Dies kann wiederum zu Problemen führen, wenn Exchange 2003 in einem Cluster mit mindestens zwei virtuellen Exchange-Servern installiert ist.
Um zu verhindern, dass bei der Überwachung fälschlicherweise Fehlermeldungen für virtuelle Exchange-Server ohne ausgeführten MTA-Dienst protokolliert werden, deaktivieren Sie die MTA-Überwachung auf dem zweiten virtuellen Exchange-Server (und gegebenenfalls auf allen weiteren virtuellen Exchange-Servern) eines Clusters. Detaillierte Schritte finden Sie unter How to Disable MTA Monitoring on an Exchange Virtual Server.
Hinweis: Die MTA-Überwachung des ersten virtuellen Exchange-Servers eines Clusters muss nicht deaktiviert werden.
IIS-SMTP-ProtokollierungVirtuelle IIS-SMTP-Protokollserver erstellen Protokolldateien und versehen diese mit Einträgen. Diese Dateien werden für die Erfassung statistischer Daten über die Serverauslastung verwendet. In der Standardeinstellung ist die SMTP-Protokollierung nicht aktiviert, da sie die Exchange-Leistung verringert. Bei Aktivierung werden von IIS Protokolldateien auf dem Systemlaufwerk des lokalen Computers erstellt, beispielsweise unter C:\Windows\System32\Logfiles (C steht für den Laufwerkbuchstaben des Systemlaufwerks).
Für die zuverlässige Konfiguration der IIS-SMTP-Protokollierung müssen Sie einen Ordner auf einem freigegebenen Datenträger angeben. Detaillierte Anweisungen finden Sie unter How to Enable SMTP Logging and Log the Files to a Shared Disk.
665
AntiAffinityClassNamesEine der Einschränkungen von Windows 2000-basierten Serverclustern ist, dass es keinen Mechanismus für einen bedingten Failover gibt. Beispielsweise können Sie einen virtuellen Exchange-Server nicht so konfigurieren, dass er im Falle eines bestimmten Fehlers zu einem bestimmten Knoten und bei einem anderen Fehler zu einem anderen Knoten verschoben wird. Sie können einen virtuellen Exchange-Server auch nicht so konfigurieren, dass ein Failover zu einem zweiten Knoten durchgeführt wird, wenn der erste Knoten überlastet ist. Bei Windows Server 2003-Clustern wird diese Einschränkung durch die Einführung der neuen Clustergruppeneigenschaft AntiAffinityClassNames behoben. Der Wert dieser Eigenschaft ist eine beliebige Zeichenkette. Diese Zeichenkette ist jedoch häufig programmspezifisch. Beispielsweise wird von Exchange 2003 der Wert auf Microsoft Exchange Virtual Server gesetzt.
AntiAffinityClassNames werden verwendet, um einen Knoten als möglichen Besitzer für eine Ressourcengruppe in einem Cluster mit mindestens drei Knoten festzulegen. Wenn ein Ressourcenfehler, der die Ressourcengruppe beeinträchtigt, in einem Windows Server 2003-Cluster auftritt, wird der Wert von AntiAffinityClassNames von Failover-Manager überprüft. Schlägt beispielsweise eine Ressource des virtuellen Exchange-Servers fehl, wird vom Failover-Manager des Clusters geprüft, ob für einen der anderen Knoten, die als mögliche Besitzer des virtuellen Exchange-Servers festgelegt sind, in der Ressourcengruppe der Wert von AntiAffinityClassNames auf Microsoft Exchange Virtual Server gesetzt ist. Dieser Wert ist nur bei Knoten gesetzt, die derzeit einen virtuellen Exchange-Server enthalten. Daher ist ein Knoten, bei dem dieser Wert nicht gesetzt ist, das bestmögliche Ziel für die Gruppe mit der fehlerhaften Ressource.
Die folgenden Szenarios zeigen, wie die Eigenschaft AntiAffinityClassNames verwendet werden kann:
Diese Eigenschaft kann in einem Exchange-Servercluster mit N+1 Knoten verwendet werden. In diesem Fall Exchange jede Gruppe, die eine Partition unterstützt, mit einem Exchange-spezifischen Wert in der Eigenschaft AntiAffinityClassNames (demselben Wert für jede Gruppe) einrichten. Wenn ein Fehler auftritt, kann Failover-Manager versuchen, Partitionen durch die Auswahl von Knoten zu trennen, die keine Gruppen mit demselben Wert Exchange Virtual Server in der Eigenschaft AntiAffinityClassNames enthalten.
Diese Eigenschaft kann bei einer Serverkonsolidierung verwendet werden, bei der mehrere Programme voneinander getrennt gehalten werden sollen. In diesem Fall sollten die Gruppen, die die verschiedenen Programme repräsentieren, manuell so geändert werden, dass die Eigenschaft AntiAffinityClassNames denselben Wert hat.
Diese Eigenschaft kann nur mit dem Befehlszeilentool CLUSTER.EXE konfiguriert werden. Im Folgenden finden Sie ein Syntaxbeispiel für das erste obige Szenario:
cluster group "Name of Group" /prop AntiAffinityClassNames="Microsoft Exchange Virtual
Server"
666
Mit diesem Befehl wird folgender Registrierungsschlüssel erstellt:
Speicherort HKLM\Cluster\Groups\<Guid>\
Wert AntiAffinityClassNames
Typ REG_MULTI_SZ
Wert Microsoft Exchange Virtual Server
Nachdem diese Eigenschaft festgelegt wurde, wird für Failover- und Failback-Richtlinien in der Clusterverwaltung die Option Bestmöglich konfiguriert, anstatt bestimmte Knoten in einer Richtlinie anzugeben. Weitere Informationen finden Sie im Microsoft Knowledge Base-Artikel 299631, „Failover Behavior on Clusters of Three or More Nodes“.
Öffentliche MAPI-InformationsspeicherVor Service Pack 1 konnten Exchange 2003-Cluster nur einen öffentlichen MAPI-Informationsspeicher (auch als Öffentliche Ordner-Datenbank bezeichnet) pro Cluster enthalten. Dieser Entwurf vermeidet Probleme, die ggf. bei einem Clusterfailover auf einen anderen Server in einem Aktiv/Aktiv-Cluster auftreten können. Da Exchange 2003 in einer Aktiv/Passiv-Konfiguration ausgeführt werden muss, sobald mehr als zwei Knoten in einem Cluster vorhanden sind, kann es nicht passieren, dass ein einzelner Store.exe-Prozess mehrere öffentliche MAPI-Informationsspeicher derselben obersten Hierarchieebene verarbeiten muss. Daher wurde mit Exchange 2003 Service Pack 1 die zuvor vorhandene Begrenzung für öffentliche MAPI-Informationsspeicher in einem Cluster entfernt. Bei Installationen mit SP1 oder höher kann jeder virtuelle Exchange-Server nur einen öffentlichen MAPI-Informationsspeicher enthalten. Das ist dieselbe Einschränkung wie bei eigenständigen Exchange 2003-Servern.
EseutilWenn Sie das Dienstprogramm Eseutil zum Überprüfen der Datenbankintegrität mit der Option /CC ausführen, müssen Sie Folgendes berücksichtigen. Diese Option wird verwendet, um einen Hard Recovery-Vorgang für einen Exchange-Informationsspeicher durchzuführen. Bei Hard Recovery-Vorgängen werden Transaktionsprotokolldateien und Datenbank-Patchdateien auf eine aus einer Onlinesicherung wiederhergestellte Datenbank angewendet. Weitere Informationen finden Sie im Microsoft Knowledge Base-Artikel 266689, „XADM: The 'ESEUTIL /CC' Command Does Not Work on Cluster Server“.
667
Installieren von AktualisierungenLesen Sie vor der Installation von Aktualisierungen auf einem Exchange-Clusterknoten die README-Datei, die im Service Pack, Hotfix oder in der Aktualisierung enthalten ist. In den meisten Fällen wird zunächst der passive Knoten des Clusters aktualisiert. Die virtuellen Exchange-Server werden dann zum passiven Knoten verschoben, und anschließend wird der andere Knoten aktualisiert. Sie sollten Aktualisierungen nie auf mehreren Knoten gleichzeitig installieren.
How to Disable MTA Monitoring on an Exchange Virtual ServerIn der Standardeinstellung wird auf einem Exchange 2003-Server der MTA-Dienst überwacht. In einer Clusterumgebung wird der MTA-Dienst nur auf einem der physischen Knoten (Computer) ausgeführt. Um zu verhindern, dass bei der Überwachung fälschlicherweise Fehlermeldungen für virtuelle Exchange-Server ohne ausgeführten MTA-Dienst protokolliert werden, deaktivieren Sie die MTA-Überwachung auf dem zweiten virtuellen Exchange-Server (und gegebenenfalls auf allen weiteren virtuellen Exchange-Servern) eines Clusters. Die MTA-Überwachung des ersten virtuellen Exchange-Servers eines Clusters muss nicht deaktiviert werden. In diesem Verfahren wird beschrieben, wie die MTA-Überwachung auf einem virtuellen Exchange-Server deaktiviert wird.
Bevor Sie beginnenPrüfen Sie, bevor Sie mit der Verwaltung des Exchange-Clusters beginnen, ob Sie hinreichend mit den einzelnen Komponenten eines virtuellen Exchange-Servers und den zugehörigen Exchange-Ressourcen vertraut sind. Es empfiehlt sich auch eine eingehende Beschäftigung mit den Funktionen der Clusterverwaltung – dem primären Tool für die Konfiguration und Verwaltung von Clustern.
Hinweis: Bevor Sie die in diesem Kapitel genannten Aufgaben der Clusterverwaltung durchführen, müssen Sie sich mit den in der Onlinehilfe von Microsoft Windows Server™ 2003 Enterprise Edition unter „Checklist: Preparation for installing a cluster“ und mit den unter Windows Server 2003 Technical Reference beschriebenen Clusterkonzepten vertraut machen.
Stellen Sie ferner sicher, dass Sie mit dem Verwenden von Serverclustern (siehe Planning an Exchange Server 2003 Messaging System ) und mit dem Bereitstellen von Exchange 2003 in einem Cluster (siehe Exchange Server 2003 Deployment Guide ) vertraut sind.
668
VerfahrenSo deaktivieren Sie die MTA-Überwachung auf einem virtuellen Exchange-Server
1. Erweitern Sie im Exchange-System-Manager in der Konsolenstruktur die Option Server, klicken Sie mit der rechten Maustaste auf den entsprechenden virtuellen Exchange-Server, und klicken Sie dann auf Eigenschaften.
2. Klicken Sie im Dialogfeld Eigenschaften von <Servername> auf die Registerkarte Überwachung.
3. Wählen Sie auf der Registerkarte Überwachung in der Liste der Dienste den Eintrag Microsoft Exchange-Standarddienste aus, und klicken Sie dann auf Details.
4. Wählen Sie im Dialogfeld Microsoft Exchange-Standarddienste die Option Microsoft Exchange MTA-Stacks aus, und klicken Sie dann auf Entfernen.
5. Klicken Sie zweimal auf OK.
How to Enable SMTP Logging and Log the Files to a Shared DiskWenn Sie statistische Daten zur Serverauslastung erfassen möchten, können Sie die Protokollierung der SMTP-Ressource aktivieren. Durch die Aktivierung der SMTP-Protokollierung wird jedoch die Leistung von Exchange beeinträchtigt. Die Protokollierung sollte aus diesem Grund nur bei einer Problembehandlung oder beim Erfassen von statistischen Daten aktiviert werden. In der Standardeinstellung ist die Protokollierung deaktiviert. In diesem Verfahren wird das Aktivieren der SMTP-Protokollierung und das Verschieben der Protokolldateien auf einen freigegebenen Datenträger veranschaulicht.
Bevor Sie beginnenBei aktivierter Protokollierung erstellt Internet Information Services (IIS) SMTP-Protokolldateien auf dem lokalen Computer (z. B. unter C:\Winnt\System32\Logfiles, wobei Windows Server 2003 oder Windows 2000 unter C installiert ist). Für die zuverlässige Konfiguration der SMTP-Protokollierung in einer Clusterumgebung muss statt des Standardverzeichnisses der Protokolldateien (d. h. auf dem lokalen Computer) ein Ordner auf einem freigegebenen Datenträger angegeben werden.
669
VerfahrenSo aktivieren Sie die SMTP-Protokollierung und verschieben die Protokolldateien auf
einen freigegebenen Datenträger
1. Erweitern Sie im Exchange-System-Manager in der Konsolenstruktur die Option Server, und erweitern Sie dann den Server, auf dem die IIS-Protokollierung für SMTP aktiviert werden soll.
2. Erweitern Sie in der Konsolenstruktur Protokolle und anschließend SMTP.
3. Klicken Sie in der Konsolenstruktur mit der rechten Maustaste auf Virtueller Standardserver für SMTP, und klicken Sie dann auf Eigenschaften.
4. Klicken Sie im Dialogfeld Eigenschaften für Virtueller Standardserver für SMTP auf der Registerkarte Allgemein auf Protokollierung aktivieren, und klicken Sie dann auf Eigenschaften.
5. Ändern Sie im Dialogfeld Erweiterte Protokollierungseigenschaften auf der Registerkarte Allgemeine Eigenschaften unter Protokolldateiverzeichnis das Verzeichnis der SMTP-Protokolldatei in einen Ordner auf einem freigegebenen Datenträger.
6. Klicken Sie zweimal auf OK.
How to Create an HTTP Virtual Server in Exchange System ManagerWenn Sie einen virtuellen Exchange-Server erstellen, wird bei der Erstellung der Systemaufsichtsressource eine virtuelle HTTP-Serverressource erstellt.
In diesem Thema wird erläutert, wie mithilfe des Exchange-System-Managers ein virtueller HTTP-Server erstellt wird.
Bevor Sie beginnenDie folgenden Schritte müssen für jeden virtuellen Exchange-Server im Cluster wiederholt werden.
670
VerfahrenSo erstellen Sie einen virtuellen HTTP-Server im Exchange-System-Manager
1. Öffnen Sie den Exchange-System-Manager.
2. Erweitern Sie in der Konsolenstruktur den Eintrag Server, erweitern Sie den Server, den Sie als Back-End-Server konfigurieren möchten, und erweitern Sie dann Protokolle.
3. Klicken Sie mit der rechten Maustaste auf HTTP, zeigen Sie auf Neu, und klicken Sie anschließend auf Virtueller SMTP-Server.
4. Geben Sie im Eigenschaftendialogfeld im Feld Name den Namen des Front-End-Servers ein.
5. Klicken Sie neben der Liste IP-Adresse auf Erweitert.
6. Wählen Sie im Dialogfeld Erweitert unter Identitäten den Standardeintrag aus, und klicken Sie dann auf Ändern.
7. Wählen Sie im Dialogfeld Identifikation in der Liste IP-Adresse die IP-Adresse dieses virtuellen Exchange-Servers (des Back-End-Servers) aus. Diese IP-Adresse muss mit dem Wert der IP-Adressressource übereinstimmen, die Sie zuvor für den Back-End-Server konfiguriert haben.
Dialogfeld „Identifikation“
8. Geben Sie im Feld Hostname den Hostheader des Front-End-Servers ein. Mit diesem Namen greifen die Clients auf den Front-End-Server zu. Der Hostheader für den virtuellen Exchange-Server muss mit dem Hostheader des Front-End-Servers übereinstimmen.
Hinweis: Clientanforderungen an den Front-End-Server verwenden einen bestimmten Host, beispielsweise http://mail.contoso.com. Auf einem virtuellen Front-
671
End-Server muss der Hostheader mail.contoso.com konfiguriert sein. Der Front-End-Server leitet die Anforderung dann über Proxy an den Back-End-Server, auf dem der Hostheader ebenfalls auf einem virtuellen Server konfiguriert sein muss.
9. Überprüfen Sie, dass der TCP-Port auf 80 festgelegt ist, und klicken Sie dann auf OK.
10. Wenn Sie eine zusätzliche Identität hinzufügen möchten, klicken Sie im Dialogfeld Erweitert auf Hinzufügen, und wiederholen Sie die Schritte 6 bis 8.
Hinweis: Sie sollten in Erwägung ziehen, dem virtuellen Server mehrere Identitäten hinzuzufügen, die alle Methoden auflisten, mit denen ein Benutzer auf den Front-End-Server zugreifen kann. Wenn zum Beispiel ein Front-End-Server sowohl intern als auch extern verwendet wird, ist es unter Umständen angebracht, einen Hostnamen und einen vollqualifizierten Domänennamen aufzuführen, beispielsweise mail für den internen Zugriff und mail.contoso.com für den externen Zugriff.
11. Klicken Sie im Dialogfeld Erweitert zweimal auf OK, um den neuen virtuellen HTTP-Server zu erstellen.
How to Create Virtual Directories for an Exchange Virtual Server in a Windows Server ClusterWenn Sie einen virtuellen Exchange-Server erstellen, wird bei der Erstellung der Systemaufsichtsressource eine virtuelle HTTP-Serverressource erstellt. In diesem Thema wird das Erstellen von virtuellen Verzeichnissen für einen virtuellen Exchange-Server in einem Windows Server-Cluster veranschaulicht.
Bevor Sie ein virtuelles Verzeichnis erstellen können, müssen Sie im Exchange-System-Manager einen virtuellen HTTP-Server erstellen. Ausführliche Anweisungen finden Sie unter How to Create an HTTP Virtual Server in Exchange System Manager. Nachdem Sie einen virtuellen HTTP-Server erstellt haben, müssen Sie dem bzw. den Back-End-Server(n) virtuelle Verzeichnisse hinzufügen, die mit den auf dem Front-End-Server konfigurierten virtuellen Verzeichnissen übereinstimmen. Eine typische Exchange-Installation enthält die virtuellen Verzeichnisse Exchange und Public. Im Exchange-System-Manager werden virtuelle Verzeichnisse von virtuellen HTTP-Servern als untergeordnete Objekte des virtuellen HTTP-Servers angezeigt.
672
Bevor Sie beginnenVergewissern Sie sich, dass für alle virtuellen Verzeichnisse, die auf Postfächer verweisen, die im virtuellen Verzeichnis Eigenschaften ausgewählte SMTP-Domäne mit der SMTP-Domäne der Benutzer übereinstimmt, die auf den Front-End-Server zugreifen. Wenn nicht die richtige Domäne ausgewählt ist, können die Benutzer dieser Domäne nicht diesen virtuellen Server für die Anmeldung verwenden. Die Liste der Domänen wird anhand der Domänen der SMTP-Adressen erstellt, die in den Empfängerrichtlinien der Exchange-Organisation genannt werden. Wenn für eine Domäne mehrere Empfängerrichtlinien vorhanden sind, werden doppelte Einträge angezeigt. In diesem Fall spielt es keine Rolle, welche Domäne Sie auswählen.
VerfahrenSo erstellen Sie virtuelle Verzeichnisse für einen virtuellen Exchange-Server in einem
Windows Server-Cluster
1. Öffnen Sie den Exchange-System-Manager.
2. Erweitern Sie in der Konsolenstruktur den Eintrag Server, erweitern Sie den Server, den Sie als Back-End-Server konfigurieren möchten, erweitern Sie Protokolle, und erweitern Sie dann HTTP.
3. Klicken Sie mit der rechten Maustaste auf <Name des virtuellen HTTP-Servers>, zeigen Sie dann auf Neu, und klicken Sie anschließend auf Virtuelles Verzeichnis.
4. Geben Sie im Dialogfeld Eigenschaften im Feld Name den Namen Exchange ein.
5. Die Option Postfächer für SMTP-Domäne ist unter Exchange-Pfad in der Standardeinstellung aktiviert. Behalten Sie diese Einstellung bei, da die Benutzer das virtuelle Exchange-Verzeichnis verwenden, um auf ihre Exchange-Postfächer zuzugreifen. Klicken Sie auf OK, um das erste virtuelle Verzeichnis zu erstellen.
6. Klicken Sie in der Konsolenstruktur mit der rechten Maustaste wieder auf <Name des virtuellen HTTP-Servers>, zeigen Sie dann auf Neu, und klicken Sie anschließend auf Virtuelles Verzeichnis.
7. Geben Sie im Dialogfeld Eigenschaften im Feld Name den Namen Öffentlich ein.
8. Klicken Sie unter Exchange-Pfad auf Öffentlicher Ordner und dann auf Ändern.
9. Doppelklicken Sie im Dialogfeld Auswahl Öffentlicher Ordner auf Öffentliche Ordner. Nach einigen Sekunden ermittelt Exchange den Servernamen des Öffentlichen Ordners und hängt ihn an den Namen des Containers Öffentliche Ordner an.
Dialogfeld „Auswahl Öffentlicher Ordner“
673
10. Klicken Sie auf OK, um das Dialogfeld Auswahl Öffentlicher Ordner zu schließen.
11. Klicken Sie im Dialogfeld Eigenschaften auf OK.
12. Wenn auf Ihrem Front-End-Server weitere virtuelle Verzeichnisse konfiguriert sind, müssen Sie diese ebenfalls erstellen. Um weitere virtuelle Verzeichnisse zu erstellen, wiederholen Sie die Schritte 5 bis 10 für jedes dieser Verzeichnisse.
Weitere InformationenWeitere Informationen zum Erstellen virtueller Verzeichnisse finden Sie unter „Konfigurieren des virtuellen Verzeichnisses des Servers“ in der Hilfe zu Exchange 2003.
How to Create an HTTP Virtual Server Resource for an Exchange Virtual Server in a Windows Server ClusterDamit der Clusterdienst zur Verwaltung aller virtueller HTTP-Server verwendet werden kann, müssen Sie für jeden virtuellen HTTP-Server eine neue HTTP-Serverresource erstellen. In diesem Thema wird das Erstellen einer virtuellen HTTP-Serverressource für einen virtuellen Exchange-Server in einem Windows-Servercluster veranschaulicht.
674
Bevor Sie beginnenSie müssen die folgenden Schritte für jeden virtuellen Exchange-Server ausführen, dem Sie einen neuen virtuellen HTTP-Server hinzugefügt haben.
VerfahrenSo erstellen Sie eine virtuelle HTTP-Serverressource für einen virtuellen Exchange-
Server in einem Windows Server-Cluster
1. Starten Sie die Clusterverwaltung.
2. Klicken Sie mit der rechten Maustaste auf den virtuellen Exchange-Server, zeigen Sie auf Neu, und klicken Sie dann auf Ressource.
3. Der Assistent Neue Ressource wird gestartet. Geben Sie im Feld Name die Zeichenfolge Exchange HTTP Virtual Server - (<Name des virtuellen Exchange-Servers>) ein, wobei Name des virtuellen Exchange-Servers für den Namen des Front-End-Servers steht.
4. Klicken Sie in der Liste Ressourcentyp auf Microsoft Exchange HTTP-Serverinstanz. Stellen Sie sicher, dass in der Liste Gruppe der Name des virtuellen Exchange-Servers angezeigt wird, und klicken Sie anschließend auf Weiter.
5. Stellen Sie sicher, dass im Dialogfeld Mögliche Besitzer unter Mögliche Besitzer alle Knoten aufgeführt sind, und klicken Sie auf Weiter.
6. Fügen Sie im Dialogfeld Abhängigkeiten dem Feld Ressourcenabhängigkeiten die Ressource Exchange-Systemaufsicht hinzu, und klicken Sie dann auf Weiter.
7. Wählen Sie im Dialogfeld Instanz des virtuellen Servers in der Liste Serverinstanz den neu erstellten virtuellen HTTP-Server für die Ressource aus, und klicken Sie dann auf Fertig stellen.
8. Klicken Sie in der Clusterverwaltung mit der rechten Maustaste auf die soeben erstellten virtuellen HTTP-Serverinstanzen, und klicken Sie dann auf Online schalten.
CopyrightDie in diesem Dokument enthaltenen Informationen entsprechen der zum Zeitpunkt der Veröffentlichung aktuellen Ansicht der Microsoft Corporation bezüglich der behandelten Themen. Da Microsoft auf wechselnde Marktbedingungen reagieren muss, sollte dies nicht als Verpflichtung seitens Microsoft betrachtet werden. Ferner kann Microsoft keine
675
Gewährleistung für die Richtigkeit der dargestellten Informationen nach dem Veröffentlichungsdatum übernehmen.
Dieses White Paper dient nur zu Informationszwecken. MICROSOFT ÜBERNIMMT BEZÜGLICH DER INFORMATIONEN IN DIESEM DOKUMENT KEINE GEWÄHRLEISTUNGEN, SEI SIE AUSDRÜCKLICH, KONKLUDENT ODER GESETZLICH GEREGELT.
Die Benutzer sind verpflichtet, sich an alle anwendbaren Urheberrechtsgesetze zu halten. Ohne die Urheberrechtsgesetze einzuschränken darf ohne ausdrückliche schriftliche Genehmigung der Microsoft Corporation kein Teil dieser Unterlagen für irgendwelche Zwecke vervielfältigt oder übertragen werden, unabhängig davon, auf welche Art und Weise oder mit welchen Mitteln, elektronisch, mechanisch, durch Fotokopie oder Aufzeichnen, dies geschieht.
Es ist möglich, dass Microsoft Rechte an Patenten bzw.angemeldeten Patenten, an Marken, Urheberrechten oder sonstigem geistigen Eigentum besitzt, die sich auf den fachlichen Inhalt dieses Dokuments beziehen. Die Bereitstellung dieses Dokuments erteilt keinerlei Lizenzrechte an diesen Patenten, Marken, Urheberrechten oder anderem geistigen Eigentum, ausgenommen, dies wurde explizit durch einen schriftlich festgehaltenen Lizenzvertrag mit der Microsoft Corporation vereinbart.
Die in den Beispielen verwendeten Namen von Firmen, Organisationen, Produkten, Domänennamen, E-Mail-Adressen, Logos, Personen, Orten und Ereignissen sind frei erfunden, soweit dies nicht anders angegeben ist. Jede Ähnlichkeit mit bestehenden Firmen, Organisationen, Produkten, Domänennamen, E-Mail-Adressen, Logos, Personen, Orten und Ereignissen ist rein zufällig und nicht beabsichtigt.
© 2006 Microsoft Corporation. Alle Rechte vorbehalten.
Microsoft, MS-DOS, Windows, Windows Server, Windows Vista, Active Directory, ActiveSync, ActiveX, Entourage, Excel, FrontPage, Hotmail, JScript, Microsoft Press, MSDN, MSN, Outlook, SharePoint, Visual Basic, Visual C++, Visual Studio, Win32, Windows Mobile, Windows NT und Windows Server System sind eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern..
Alle anderen geschützten Marken gehören dem jeweiligen Eigentümer.
676
