Technisches Referenzhandbuch für Exchange Server 2003
Werbung
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]. Contents Technisches Referenzhandbuch für Exchange Server 2003 ................................................. 17 Einführung in das technische Referenzhandbuch für Exchange Server 2003 ....................... 17 Welche Informationen bietet dieses Handbuch? ................................................................. 17 Für wen ist dieses Handbuch gedacht? .............................................................................. 19 Einführende Dokumentationen ............................................................................................ 20 Technische Übersicht über Exchange Server 2003 ............................................................... 20 Exchange Server 2003 als Nachrichtenverarbeitungssystem ................................................ 21 Allgemeine Komponenten eines Nachrichtenverarbeitungssystems .................................. 22 Das Nachrichtenverarbeitungssystem in der Netzwerkinfrastruktur ................................... 23 Verzeichnisintegration ............................................................................................................. 25 Empfängerobjekte im Verzeichnis ....................................................................................... 25 Konfigurationsinformationen im Verzeichnis ....................................................................... 27 Exchange-Klassen und -Attribute in Active Directory .......................................................... 28 Verzeichniszugriffsarchitektur .............................................................................................. 28 Nachrichtentransport ............................................................................................................... 29 Nachrichtenroutingarchitektur .............................................................................................. 29 Nachrichtenrouting mit Routinggruppen .............................................................................. 30 Exchange-Nachrichtenspeicher .............................................................................................. 33 Exchange Server 2003-Datenbanktechnologie ................................................................... 33 Informationsspeicher und Speichergruppen ........................................................................ 34 Benutzeragents in einer Exchange Server 2003-Organisation .............................................. 35 Dienstabhängigkeiten in Exchange Server 2003 .................................................................... 37 Grundlagen zur Architektur der Windows-Dienste .................................................................. 38 Funktionen des Dienststeuerungs-Managers ...................................................................... 39 Exchange-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 .......................................... 80 Bevor Sie beginnen ............................................................................................................. 81 Verfahren ............................................................................................................................. 81 Exchange Server 2003 und Active Directory .......................................................................... 81 Verzeichnisintegration und Exchange Server 2003 ................................................................ 83 Exchange-Klassen und -Attribute in Active Directory .......................................................... 83 Verzeichnisdienstzugriff ....................................................................................................... 86 Lastenausgleich und Failover durch LDAP-Verbindungen.................................................. 89 DSAccess-Topologieerkennung .......................................................................................... 90 Erste Suche und laufende neue Suche ............................................................................... 92 Hartcodierung von DSAccess-Servern ................................................................................ 95 DSAccess-Profile ................................................................................................................. 96 Angeben des Konfigurationsdomänencontrollers ................................................................ 98 Zuweisen von Serverfunktionen durch DSAccess .............................................................. 99 Verzeichniszugriffscache ................................................................................................... 103 Laden von DSAccess ........................................................................................................ 105 Verzeichnisdienstproxy ......................................................................................................... 108 DSProxy-Operationen ........................................................................................................ 109 Verhalten von Exchange Server 2003 vor Service Pack 2 bei Verweisen ........................ 109 Verhalten von Exchange Server 2003 Service Pack 2 bei Verweisen .............................. 112 SMTP-Kategorisierungsmodul .............................................................................................. 117 Nachrichtenkategorisierung und Active Directory ............................................................. 118 Empfängeraktualisierungsdienst und Exchange Server 2003 .............................................. 120 Aktualisieren von Empfängerobjekten ............................................................................... 121 Metabase-Aktualisierungsdienst ........................................................................................... 123 DS2MB-Vorgänge .............................................................................................................. 124 Architektur des Exchange-System-Managers....................................................................... 124 Integration in MMC ................................................................................................................ 125 Exchange Server 2003-Snap-Ins und Snap-In-Erweiterungen ......................................... 132 Erstellen benutzerdefinierter Exchange-Verwaltungskonsolen ......................................... 148 Verwalten von Konfigurationsinformationen in Active Directory ........................................... 150 Herstellen von Bindungen an einen Domänencontroller ................................................... 150 Die Exchange-Organisation in der Konfigurationsverzeichnispartition ............................. 152 Exchange-System-Manager und Berechtigungseinstellungen.......................................... 155 Aktivieren der Registerkarte „Sicherheit“ für Objekte im Exchange-System-Manager ..... 156 Vererbung von Berechtigungen und Exchange-System-Manager .................................... 158 Verwalten von Exchange-Informationsspeicherressourcen.................................................. 163 MAPI-basierte Kommunikation .......................................................................................... 163 Über die IExchangeManageStore-Schnittstelle abgerufene Informationen ...................... 164 Exchange-System-Manager und MAPI-basierte Clients ................................................... 166 DAV-basierte Kommunikation ........................................................................................... 166 DAV-basierte Kommunikation und virtuelle HTTP-Verzeichnisse ..................................... 167 Exchange-System-Manager und das virtuelle Verzeichnis „Exadmin“ ............................. 168 Verbinden mit einem bestimmten Exchange-Server ......................................................... 170 Exchange-System-Manager und die Standardwebsite ..................................................... 171 Virtuelles Verzeichnis „Exadmin“ und SSL-Verschlüsselung ............................................ 172 Anzeigen aller für einen Postfachspeicher oder einen Informationsspeicher für Öffentliche Ordner verfügbaren Informationen .................................................................................... 174 Verfahren ........................................................................................................................... 174 Verbinden mit einem bestimmten Exchange-Server im Exchange-System-Manager .......... 175 Verfahren ........................................................................................................................... 175 Integration in die Windows-Verwaltungsinstrumentation ...................................................... 175 Dienstkonfiguration im Exchange-System-Manager ............................................................. 179 Nachrichtenroutingarchitektur ............................................................................................... 181 Nachrichtenroutingtopologie in Exchange Server 2003 ........................................................ 183 Nachrichtenverarbeitung in Exchange Server 2003 ............................................................. 186 Nachrichtenrouting unter Exchange Server 2003 ................................................................. 196 Nachrichtenrouten und die Verbindungsstatustabelle ....................................................... 196 Initialisieren der Verbindungsstatustabelle ........................................................................ 197 Routingmodul und der Dienst Exchange-Routingmodul ................................................... 198 Überprüfen der Verbindungsstatustabelle ......................................................................... 199 Exchange-Routingpfadauswahl ......................................................................................... 216 Auswahl des Routingpfads ................................................................................................ 219 Dijkstra-Algorithmus des kürzesten Weges ....................................................................... 220 Lastenausgleich bei der Nachrichtenübertragung ............................................................. 224 Lastenausgleich zwischen Routinggruppen ...................................................................... 224 Lastenausgleich zwischen Connectors und externen Systemen ...................................... 227 Erneutes Routing von Nachrichten anhand von Verbindungsstatusinformationen ........... 228 Erneutes Routing von Nachrichten .................................................................................... 229 Erneutes Routing und Adressräume ................................................................................. 230 Connectorwiederherstellung .............................................................................................. 231 Erneutes Routing und Aktivierungszeitpläne ..................................................................... 232 Verbindungsstatusweitergabe ............................................................................................... 232 Verbindungsstatusalgorithmus .......................................................................................... 233 Beispiel für einen LSA ....................................................................................................... 236 Verbindungsstatusänderungen und Verbindungsstatusübermittlung ................................ 241 Ändern des Routinggruppenmasters ................................................................................. 243 Konflikte zwischen Routinggruppenmastern ..................................................................... 243 Abwärtskompatibilität mit Exchange Server 5.5 ................................................................... 244 Erzeugen der GWART ....................................................................................................... 244 Routingprobleme im gemischten Modus ........................................................................... 245 Topologieaktualisierungen ................................................................................................. 245 Unterbrochene Verbindungsstatusübermittlung ................................................................ 246 SMTP-Transportarchitektur ................................................................................................... 248 Entwurf des SMTP-Diensts ................................................................................................... 249 IIS-Integration (Internetinformationsdienste) ..................................................................... 250 Asynchrone Ausführung von Threads ............................................................................... 251 Verarbeiten eingehender SMTP-Verbindungen ................................................................ 251 Beschränken der Anzahl der SMTP-Threads .................................................................... 253 COM-basierte SMTP-Erweiterungen ................................................................................. 255 Ereignisse im SMTP-Transportsubsystem ........................................................................ 255 Ereignisverteiler und Ereignisbenachrichtigungen ............................................................ 257 Verwaltungsschnittstellen .................................................................................................. 259 Konfigurationseinstellungen und Ereignisbindungen ........................................................ 259 Konfigurationsinformationen in Active Directory ................................................................ 260 SMTP-Konfigurationseinstellungen in der Metabasis ........................................................ 265 SMTP-Konfigurationsschlüssel .......................................................................................... 266 Direktes Bearbeiten der Metabasis ................................................................................... 269 Registrierung lokaler Domänen ......................................................................................... 269 Registrierung von Ereignissenken ..................................................................................... 270 Servererweiterungsobjekte ................................................................................................ 273 Aktivieren der Option „Direktes Bearbeiten der Metabasis ermöglichen“ im IIS-Manager ... 274 Bevor Sie beginnen ........................................................................................................... 274 Verfahren ........................................................................................................................... 274 Erweitertes Warteschlangenmodul ....................................................................................... 276 Durch das erweiterte Warteschlangenmodul ausgelöste Ereignisse ................................ 277 Nachrichtenwarteschlangen im erweiterten Warteschlangenmodul ................................. 281 Begrenzen der Anzahl von Nachrichten in Warteschlangen ............................................. 286 SMTP-Transportkomponenten .............................................................................................. 287 Exchange-Kategorisierungsmodul ..................................................................................... 288 Verzweigung von Nachrichten ........................................................................................... 303 Inhaltskonvertierung .......................................................................................................... 304 IMAIL.................................................................................................................................. 305 TNEF.................................................................................................................................. 306 Nachrichtenverarbeitung für Öffentliche Ordner ................................................................ 308 Optimieren der Leistung des Kategorisierungsmoduls ...................................................... 310 Lastenausgleich für globale Kataloge ................................................................................ 313 LDAP-Suchstapel .............................................................................................................. 315 Erneute Kategorisierung von Nachrichten ......................................................................... 316 Alternative Datenströme im Warteschlangenverzeichnis .................................................. 317 Erzwingen der erneuten Kategorisierung .......................................................................... 319 Informationsspeichertreiber des SMTP-Diensts ................................................................... 320 NTFS-Informationsspeichertreiber .................................................................................... 322 Verschieben des Mailrootverzeichnisses .......................................................................... 324 Exchange-Informationsspeichertreiber .............................................................................. 325 Architektur des Exchange-Informationsspeichertreibers ................................................... 326 Installierbares Dateisystem von Exchange ........................................................................ 328 Übertragung ausgehender Nachrichten ............................................................................ 330 Übertragung eingehender Nachrichten ............................................................................. 335 Wiederholte Übertragungsversuche .................................................................................. 337 SMTP-Protokollerweiterungen .............................................................................................. 337 Protokollereigniskategorien ............................................................................................... 343 Exchange-spezifische SMTP-Protokollerweiterungen ...................................................... 344 Weitere Informationen ....................................................................................................... 351 Protokollaufzeichnungen, Ereignisprotokollierung und Nachrichtenverfolgung ................... 351 Protokollaufzeichnungen ................................................................................................... 352 Ereignisprotokollierung ...................................................................................................... 353 Produktsupport-Protokollierung ......................................................................................... 353 Nachrichtenverfolgung ....................................................................................................... 354 Aktivieren der Diagnoseprotokollierung für den SMTP-Dienst im Exchange-System-Manager ........................................................................................................................................... 355 Bevor Sie beginnen ........................................................................................................... 355 Verfahren ........................................................................................................................... 355 Festlegen des Diagnoseprotokolliergrads für MSExchangeTransport-Kategorien auf Produktsupport .................................................................................................................. 356 Bevor Sie beginnen ........................................................................................................... 356 Verfahren ........................................................................................................................... 356 Weitere Informationen ....................................................................................................... 357 Aktivieren der Nachrichtenverfolgung im Exchange-System-Manager ................................ 357 Bevor Sie beginnen ........................................................................................................... 357 Verfahren ........................................................................................................................... 358 Referenz ............................................................................................................................ 358 X.400-Transportarchitektur ................................................................................................... 358 Exchange-MTA in der Exchange Server 2003-Architektur ................................................... 360 Exchange-MTA-Kommunikationspartner........................................................................... 360 Exchange-MTA-Konfigurationseinstellungen in Active Directory ...................................... 364 Interne Exchange-MTA-Architektur ................................................................................... 369 Exchange-MTA-Datenbank ............................................................................................... 373 Ändern des Speicherorts für das MTA-Datenbankverzeichnis.......................................... 376 Gesicherte und ungesicherte Nachrichtenkopien .............................................................. 377 MTA-Datenbank in einem Servercluster ............................................................................ 379 Beschädigte Nachrichten in Gatewaywarteschlangen ...................................................... 379 Reparieren beschädigter MTA-Datenbanken .................................................................... 380 Leeren der MTA-Datenbank .............................................................................................. 381 Wiedergeben von DAT-Dateien ......................................................................................... 381 Überprüfen der Exchange-MTA-Verarbeitung ................................................................... 382 Überprüfen des Exchange-MTA mithilfe des Systemmonitors .......................................... 382 Exchange-MTA-Ereignisprotokollierung ............................................................................ 387 Ereignisprotokollierung im Textformat ............................................................................... 392 Ablaufverfolgungsstufen-Protokollierung ........................................................................... 392 MTACheck-Protokollierung ................................................................................................ 393 Objekt-IDs und Nachrichten-IDs ........................................................................................ 394 Leeren der MTA-Datenbank ................................................................................................. 395 Bevor Sie beginnen ........................................................................................................... 395 Verfahren ........................................................................................................................... 395 Weitere Informationen ....................................................................................................... 396 Wiedergeben von DAT-Dateien nach einer MTA-Datenbankleerung ................................... 396 Bevor Sie beginnen ........................................................................................................... 396 Verfahren ........................................................................................................................... 396 Referenz ............................................................................................................................ 397 Wiedergeben von DAT-Dateien nach einer MTA-Datenbankleerung über eine vollständige Wiedergabe ....................................................................................................................... 397 Bevor Sie beginnen ........................................................................................................... 397 Verfahren ........................................................................................................................... 398 Weitere Informationen ....................................................................................................... 399 Wiedergeben von DAT-Dateien nach einer MTA-Datenbankleerung mittels einer Remotewiedergabe............................................................................................................ 399 Bevor Sie beginnen ........................................................................................................... 399 Verfahren ........................................................................................................................... 400 Weitere Informationen ....................................................................................................... 401 Wiedergeben von DAT-Dateien nach einer MTA-Datenbankleerung mittels inkrementeller Wiedergabe ....................................................................................................................... 401 Bevor Sie beginnen ........................................................................................................... 402 Verfahren ........................................................................................................................... 402 Weitere Informationen ....................................................................................................... 403 MTA-Transportstacks und X.400-Connectors ...................................................................... 404 Nachrichtenübertragungsdienst ......................................................................................... 405 RTS (Reliable Transfer Service) ........................................................................................ 411 ACSE – Association Control Service Element................................................................... 414 Darstellungs- und Sitzungsdienste .................................................................................... 415 MTA-Transportstapel ......................................................................................................... 417 Beispiel für die MTA-Kommunikation ................................................................................ 421 X.400-Connectors .............................................................................................................. 422 Konfigurieren eines X.400-Connectors.............................................................................. 422 Verbindungsanforderungsinformationen ........................................................................... 424 OSI-Adressinformationen für ausgehende und eingehende Übertragungen .................... 425 X.400-Adressen ................................................................................................................. 425 X.400-Adressräume ........................................................................................................... 427 Konformitätsjahr und Nachrichtenteile ............................................................................... 429 Nachrichtenschleifenerkennung ........................................................................................ 431 X.400-Connectorobjecte in Active Directory ...................................................................... 434 Ausführen mehrerer X.400-Connectors............................................................................. 439 Verbinden von Routinggruppen mithilfe von X.400-Connectors ........................................... 441 Lastenausgleich zwischen Routinggruppen ...................................................................... 442 Nachrichtenrouting über Exchange-MTAs......................................................................... 443 SMTP-XAPI-Gateway ........................................................................................................ 443 Exchange-MTA-Nachrichtenübertragung .......................................................................... 445 Verbindungsstatusinformationen und erneutes Routing von Nachrichten ........................ 447 Austauschen von Verbindungsstatusinformationen zwischen Routinggruppen................ 448 Exchange-MTA in einer Organisation im gemischten Modus ............................................... 450 RPC-basierte MTA-Kommunikation .................................................................................. 450 Auswirkungen auf die RPC-Leistung ................................................................................. 452 RPC-Bindback-Fehler ........................................................................................................ 452 Gateway-Adressroutingtabelle .......................................................................................... 453 Nachrichtenschleifen zwischen Exchange Server 5.5- und Exchange Server 2003-Servern ........................................................................................................................................ 454 Architektur von Gateway-Messaging-Connectors ................................................................ 455 EDK-Connectorarchitektur .................................................................................................... 456 Connectorkomponenten .................................................................................................... 458 Nachrichtenübertragung zu und von Exchange Server 2003............................................ 466 Übertragung ausgehender Nachrichten ............................................................................ 467 Übertragung eingehender Nachrichten ............................................................................. 468 MAPI-Profile für MAPI-Connectors .................................................................................... 469 Nachrichtenkonvertierung .................................................................................................. 470 Adressübersetzung ............................................................................................................ 471 Proxyadressen und Einmaladressen ................................................................................. 473 Probleme bei der Adresszuordnung .................................................................................. 473 Nachrichtenkonvertierung .................................................................................................. 474 Verzeichnissynchronisierung ............................................................................................. 476 Verzeichnissynchronisierung aus einem anderen Messagingsystem in eine ExchangeOrganisation ................................................................................................................... 477 Verzeichnissynchronisierung aus einer Exchange-Organisation in ein anderes Messagingsystem ........................................................................................................... 479 Öffnen eines Connector-Postfachs mit „Mdbvu32.exe“ ........................................................ 481 Bevor Sie beginnen ........................................................................................................... 481 Verfahren ........................................................................................................................... 481 Architektur von Connector für Lotus Notes ........................................................................... 482 Nachrichtenübertragung .................................................................................................... 489 Nachrichtenkonvertierung .................................................................................................. 490 Konvertierung des E-Mail-Nachrichtentyps ....................................................................... 493 Zuordnen von E-Mail-Nachrichteneigenschaften .............................................................. 493 Verzeichnissynchronisierung ............................................................................................. 495 Architektur von Connector für Novell GroupWise ................................................................. 497 Nachrichtenübertragung .................................................................................................... 505 Nachrichtenkonvertierung .................................................................................................. 508 Konvertierung des E-Mail-Nachrichtentyps ....................................................................... 510 Konvertierung von E-Mail-Nachrichteneigenschaften ....................................................... 511 Verzeichnissynchronisierung ............................................................................................. 513 Architektur des Kalender-Connectors ................................................................................... 515 Frei-/Gebucht-Informationen.............................................................................................. 515 Veröffentlichen von Frei-/Gebucht-Daten .......................................................................... 516 Frei-/Gebucht-Nachrichten ................................................................................................ 516 Generieren von Frei-/Gebucht-Daten ................................................................................ 517 Veröffentlichen von Frei-/Gebucht-Informationen in Outlook ............................................ 518 Veröffentlichen von Frei-/Gebucht-Informationen in Outlook Web Access und Outlook Mobile Access ................................................................................................................ 520 Suchen von Frei-/Gebucht-Daten ...................................................................................... 520 Veröffentlichungs-Agent für Frei-/Gebucht-Informationen (MadFB) ................................. 521 Bereinigen von Frei-/Gebucht-Daten ................................................................................. 522 Outlook-Startschalter ......................................................................................................... 522 Bereinigen mit Outlook Web Access ................................................................................. 523 Komponenten des Kalender-Connectors .......................................................................... 524 Frei-/Gebucht-Suchen mit Lotus Notes ............................................................................. 529 Frei-/Gebucht-Suchen aus Exchange 2003 ...................................................................... 531 Frei-/Gebucht-Suchen aus Lotus Notes ............................................................................ 532 Frei-/Gebucht-Suchen mit Novell GroupWise ................................................................... 533 Frei-/Gebucht-Suchen aus Novell GroupWise .................................................................. 537 Prüfen des Vorhandenseins eines Replikats des Frei-/Gebucht-Systemordners für die administrative Gruppe auf einem Server mit Exchange Server ........................................ 538 Bevor Sie beginnen ........................................................................................................... 538 Verfahren ........................................................................................................................... 538 Virtuelle Protokollserver in Exchange Server 2003 .............................................................. 539 IIS-Integration ........................................................................................................................ 540 Untersuchen der prozessübergreifenden Kommunikation zwischen IIS und dem Microsoft Exchange-Informationsspeicherdienst ........................................................................... 541 Installierbares Dateisystem von Exchange ........................................................................ 542 Eingehende Nachrichten ................................................................................................... 543 Ausgehende Nachrichten .................................................................................................. 544 Dateisystemsemantik......................................................................................................... 544 ExIPC-Bindungsfunktion .................................................................................................... 544 ExIPC-Protokollstubs ......................................................................................................... 545 MAPI und RPC über HTTP ................................................................................................... 545 RPC über HTTP................................................................................................................. 546 Virtuelles RPC-Verzeichnis................................................................................................ 547 RPC über HTTP und der Microsoft Exchange-Informationsspeicherdienst ...................... 548 Einzelheiten zu den Internetprotokollen ................................................................................ 548 HTTP.................................................................................................................................. 548 WebDAV und XML ............................................................................................................. 550 POP3 ................................................................................................................................. 551 IMAP4 ................................................................................................................................ 554 NNTP ................................................................................................................................. 558 Konfigurationseinstellungen in Active Directory ................................................................ 558 Konfigurationseinstellungen in der Metabase ................................................................... 559 Aktualisieren der IIS-Metabase mit DS2MB ...................................................................... 559 Hochwassermarken ........................................................................................................... 560 Front-End-Serverarchitektur .............................................................................................. 560 Überlegungen zur Verwendung von Front-End-Servern ................................................... 561 Exchange ActiveSync und Exchange 2003 .......................................................................... 562 Exchange ActiveSync-Protokollarchitektur ........................................................................ 563 Versionen des Sync-Protokolls und Geräteunterstützung ................................................. 565 Befehle des Sync-Protokolls .............................................................................................. 565 Format des Sync-Befehls .................................................................................................. 566 URI ..................................................................................................................................... 566 HTTP-Header .................................................................................................................... 567 HTTP-Nachrichtentext ....................................................................................................... 567 Protokollunabhängige Multicastdaten auf dem Mobilgerät ................................................ 568 Exchange ActiveSync-Profil .............................................................................................. 568 Aktuelle Benachrichtigungen ............................................................................................. 568 Aggregatoren ..................................................................................................................... 569 Outlook Mobile Access und Exchange 2003 ........................................................................ 570 Abhängigkeiten von Outlook Mobile Access ..................................................................... 570 Outlook Mobile Access und .NET ...................................................................................... 571 .NET Framework ................................................................................................................ 571 ASP.NET ........................................................................................................................... 571 Sitzungsverwaltung ............................................................................................................ 572 Geänderte URL-Sitzungs-ID .............................................................................................. 572 ASP.NET-Geräteaktualisierungen ..................................................................................... 573 Architektur von Outlook Mobile Access ............................................................................. 573 Outlook Mobile Access und Microsoft Outlook Web Access-Vorlagen ............................. 574 Outlook Mobile Access-Datenquellen ................................................................................ 574 Verzeichniseinstellungen für Outlook Mobile Access ........................................................ 576 Outlook Mobile Access und DS2MB .................................................................................. 577 Outlook Mobile Access und die Windows-Registrierung ................................................... 578 Outlook Mobile Access und Web.Config ........................................................................... 580 Outlook Mobile Access-Clientanforderungen .................................................................... 583 Outlook Mobile Access-Sicherheitsarchitektur .................................................................. 583 Architektur des Exchange-Informationsspeicherdiensts ....................................................... 584 Exchange-Speicherarchitektur .............................................................................................. 585 Speichergruppen ............................................................................................................... 587 Speichergruppenarchitektur .............................................................................................. 587 Speichergruppenattribute in Active Directory .................................................................... 589 Speicherplatzmindestanforderungen für Speichergruppen ............................................... 592 Datenbanken im Exchange-Informationsspeicher ............................................................. 593 MAPI-Datenbankdatei........................................................................................................ 593 Streamingdatenbankdatei .................................................................................................. 594 Weitergabe von Eigenschaften .......................................................................................... 594 Konfiguration und Verwaltung der Größenbeschränkung von Datenbanken ....................... 595 Registrierungseinstellungen .............................................................................................. 596 Datenbankgrößenbeschränkung in GB ............................................................................. 597 Warnung für Puffer der Datenbankgröße in Prozent ......................................................... 598 Startzeit für Überprüfung der Datenbankgröße in Stunden nach Mitternacht ................... 598 Verhalten bei Erreichen der konfigurierten oder lizenzierten Datenbankgrößenbeschränkung .................................................................................... 599 Lizenzierte Datenbankgrößenbeschränkung ..................................................................... 600 Überlegungen zur Planung für die Wiederherstellung nach Datenverlust ........................ 600 Architektur von Extensible Storage Engine .......................................................................... 601 Transaktionen .................................................................................................................... 601 ACID-Transaktionen .......................................................................................................... 602 Der Versionsspeicher ........................................................................................................ 602 Snapshot-Isolation ............................................................................................................. 603 ESE-Datenbankstruktur ..................................................................................................... 604 Datenbankseiten ................................................................................................................ 604 ECC-Prüfsumme................................................................................................................ 605 Datenbankkonsistenz und -1018-Fehler............................................................................ 606 Datenbankstrukturausgleich .............................................................................................. 607 Teilung ............................................................................................................................... 608 Zusammenführung ............................................................................................................. 609 Auffächerung ..................................................................................................................... 609 Indizes................................................................................................................................ 609 Langwerte .......................................................................................................................... 610 Datensatzformat ................................................................................................................ 610 Spaltendatentypen ............................................................................................................. 610 Feste und variable Spalten ................................................................................................ 612 Markierte Spalten ............................................................................................................... 612 Funktionen des Informationsspeichers ................................................................................. 612 Interaktivität mit anderen Exchange-Diensten ................................................................... 612 Speicherplatzverwaltung.................................................................................................... 614 Datenbankdefragmentierung ............................................................................................. 614 Pufferverwaltung ................................................................................................................ 615 Dynamic Buffer Allocation (DBA) ....................................................................................... 616 Der LRU-K-Ersetzungsalgorithmus ................................................................................... 616 Replikation von Öffentlichen Ordnern ................................................................................... 617 Datenbankstrukturen für Öffentliche Ordner...................................................................... 618 Replikationsüberblick ......................................................................................................... 618 Packen und Entpacken ...................................................................................................... 619 Änderungsnummern .......................................................................................................... 620 Replikationsnachrichtentypen ............................................................................................ 620 Replikationsvorgang .......................................................................................................... 626 Hierarchiereplikation .......................................................................................................... 626 Inhaltsreplikation ................................................................................................................ 627 Abgleichvorgang ................................................................................................................ 628 Abgleicharray ..................................................................................................................... 628 Replikationsstatus .............................................................................................................. 629 Replikationsstatusthread ................................................................................................... 629 Replikationsstatusanforderungen ...................................................................................... 630 Ändern der Replikatliste..................................................................................................... 631 Hinzufügen eines Replikats ............................................................................................... 631 Löschen eines Replikats .................................................................................................... 631 Replikationsstatustabellen ................................................................................................. 632 Standardzeitplan für Replikationsereignisse ..................................................................... 633 Standardreplikationswerte ................................................................................................. 635 Exchange Server 2003-Clusterarchitektur ............................................................................ 636 Architektur von Windows-Clustern ........................................................................................ 637 Servercluster ...................................................................................................................... 638 Serverclusterarchitektur ..................................................................................................... 639 Komponenten des Clusterdiensts ...................................................................................... 640 Cluster-Failover ................................................................................................................. 646 Cluster-Failback ................................................................................................................. 647 Clusterquorum ................................................................................................................... 647 Standardquorum ................................................................................................................ 648 Hauptknotensatzquorum.................................................................................................... 649 Clusterressourcen .............................................................................................................. 650 Clusterverwaltung .............................................................................................................. 650 Struktur und Ausführung eines Clusters ............................................................................ 651 Erstellen eines Clusters ..................................................................................................... 651 Bilden eines Clusters ......................................................................................................... 651 Beitreten zu einem Cluster ................................................................................................ 652 Verlassen eines Clusters ................................................................................................... 653 Ausfallerkennung ............................................................................................................... 653 Virtuelle Exchange-Server .................................................................................................... 655 Exchange-Komponenten in einem Cluster ........................................................................ 656 Aktiv/Aktiv-Cluster .............................................................................................................. 657 Aktiv/Passiv-Cluster ........................................................................................................... 658 Ressourcenabhängigkeiten ............................................................................................... 660 Microsoft Exchange-Systemaufsichtsdienst ...................................................................... 660 Microsoft Exchange-Informationsspeicherdienst ............................................................... 661 Message Transfer Agent ................................................................................................... 661 Protokolle ........................................................................................................................... 661 Microsoft Search ................................................................................................................ 662 Interaktion von Exchange-Clustern ....................................................................................... 662 Die Funktionen ExchangeOpen/ExchangeClose .............................................................. 663 Die Funktionen ExchangeOnline und ExchangeOffline .................................................... 664 ExchangeIsAlive und ExchangeLooksAlive....................................................................... 665 ExchangeTerminate ........................................................................................................... 665 Erstellen von Ressourcen .................................................................................................. 665 Clusterspezifische Konfigurationen ....................................................................................... 666 Exchange-MTA .................................................................................................................. 666 IIS-SMTP-Protokollierung .................................................................................................. 666 AntiAffinityClassNames ..................................................................................................... 667 Öffentliche MAPI-Informationsspeicher ............................................................................. 668 Eseutil ................................................................................................................................ 668 Installieren von Aktualisierungen ....................................................................................... 669 How to Disable MTA Monitoring on an Exchange Virtual Server ......................................... 669 Bevor Sie beginnen ........................................................................................................... 669 Verfahren ........................................................................................................................... 670 How to Enable SMTP Logging and Log the Files to a Shared Disk ..................................... 670 Bevor Sie beginnen ........................................................................................................... 670 Verfahren ........................................................................................................................... 671 How to Create an HTTP Virtual Server in Exchange System Manager ............................... 671 Bevor Sie beginnen ........................................................................................................... 671 Verfahren ........................................................................................................................... 672 How to Create Virtual Directories for an Exchange Virtual Server in a Windows Server Cluster ........................................................................................................................................... 673 Bevor Sie beginnen ........................................................................................................... 674 Verfahren ........................................................................................................................... 674 Weitere Informationen ....................................................................................................... 675 How to Create an HTTP Virtual Server Resource for an Exchange Virtual Server in a Windows Server Cluster .................................................................................................... 675 Bevor Sie beginnen ........................................................................................................... 676 Verfahren ........................................................................................................................... 676 Copyright ............................................................................................................................... 676 17 Technisches Referenzhandbuch für Exchange Server 2003 In 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 SMTPTransportarchitektur, zur X.400-Architektur, zur Architektur des ExchangeInformationsspeichers 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 2003 Das technische Referenzhandbuch für Microsoft Exchange Server 2003 wurde für ExchangeFachleute 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 18 Architektur des Exchange-System-Managers, zur Routingarchitektur, zur SMTPTransportarchitektur, zur X.400-Architektur, zur Architektur des ExchangeInformationsspeichers 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 DirectoryVerbindungsfehlern 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 2003Komponenten 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 ExchangeSystem-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? 19 Welche Rolle spielt Exchange Message Transfer Agent (MTA) in der Nachrichtenübertragungsarchitektur? Welche technischen Auswirkungen hat die Bereitstellung eines X.400Messagingbackbone 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. 20 Einführende Dokumentationen Leser, die Exchange Server 2003 noch nicht kennen, sollten zusätzlich zu den ExchangeOnlinebü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 2003 Als 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. 21 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 Nachrichtenverarbeitungssystem Alle 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 22 Eine Schnittstelle für E-Mail-Clients zur Kommunikation mit einem Server in der Messagingumgebung Allgemeine Komponenten eines Nachrichtenverarbeitungssystems In 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 Routingund Ü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 23 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 SMTPTransportmodul beruht, auch wenn sich Sender und Empfänger auf demselben Server befinden. Weitere Informationen zum SMTP-Transportmodul finden Sie unter SMTPTransportarchitektur. 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 ExchangeInformationsspeicherdiensts. 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 Netzwerkinfrastruktur Fü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. 24 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 25 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 ExchangeOrganisation. 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. Verzeichnisintegration Die 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 Verzeichnis Empfä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. 26 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 EMail-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-MailAktivierung 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-MailAdresse 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 EMail-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 EMail-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 27 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 Verzeichnis Exchange Server 2003 speichert die meisten Konfigurationsinformationen für die ExchangeOrganisation in Active Directory. Active Directory enthält ausführliche Informationen über Serverobjekte, Container für administrative und Routinggruppen und alle ExchangeConnectors. 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“ 28 Exchange-Klassen und -Attribute in Active Directory Zusä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. Verzeichniszugriffsarchitektur Die 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 DirectoryDomä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. 29 Ausführliche Informationen zu DSAccess und DSProxy finden Sie unter Exchange Server 2003 und Active Directory. Nachrichtentransport Die 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. Nachrichtenroutingarchitektur In 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 SMTPKomponente 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 SMTPRemotehosts 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. 30 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 Routinggruppen Exchange 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. 31 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. 32 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 ExchangeOrganisation. 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 SMTPServer 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: 33 Exchange Connector für Lotus Notes Exchange Connector für Lotus Notes wird für das Nachrichtenrouting und die Verzeichnissynchronisierung zwischen einer ExchangeOrganisation 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-Nachrichtenspeicher Exchange 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 MIMEFormat (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-Datenbanktechnologie In 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 34 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 Speichergruppen Der 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 35 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-Organisation Benutzer-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: 36 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. 37 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 2003 Microsoft 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 WindowsTerminologie 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 ExchangeInformationsspeicherdienst 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/ServerSystem 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- 38 Manager werden beispielsweise Gerätetreiber je nach Abhängigkeitsstrukturen in einer festgelegten Reihenfolge gestartet, können jedoch nicht beendet werden. WindowsDienste 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 ExchangeServer 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 ExchangeDienste 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 Exchangespezifische 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 WindowsDienste Windows-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 39 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 DienststeuerungsManager 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-Managers SCM, 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 Diensten Der 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 40 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_SZWert DisplayName definiert und befindet sich unter: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<service name>. 41 Sperren und Freigeben der Dienstedatenbank Die 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 Dienste Der 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 ExchangeInformationsspeicherdienst. Starten, Beenden, Anhalten oder Fortsetzen von Diensten Fü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-EndServer, auf dem Exchange Server ausgeführt wird). Wesentliche Dienste dürfen nicht 42 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_SZRegistrierungswert mit dem Namen ObjectName im Registrierungsschlüssel des 43 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. 44 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 werden Während der Ausführung eines Diensts werden Statusbenachrichtigungen an den SCMProzess 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 WindowsDienst 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 45 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 WindowsKonto 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. 46 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 ExchangeComputerkonten der Zugriff auf die erforderlichen Ressourcen in der lokalen Domäne gewährt. Hinweis: Benennen Sie die Exchange Domain Server- oder Exchange Enterprise ServerSicherheitsgruppen nicht um, und verschieben Sie sie nicht. Entfernen Sie aus diesen Gruppen auch keine Computerkonten von vorhandenen ExchangeServern. 47 Überprüfen der Dienstedatenbank Beim Öffnen von HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services im RegistrierungsEditor (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 Beschreibung DependOnGroup 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. 48 Wert Typ Beschreibung DiagnosticsMessageFile REG_SZ Enthält den Namen der Ressourcen-DLL mit den Ereignisbeschreibungszeiche nfolgen 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. 49 Wert Typ Beschreibung ErrorControl 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 als funktionierend bekannten Konfiguration neu gestartet. 50 Wert Typ Beschreibung FailureActions 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. 51 Wert Typ Beschreibung ObjectName 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\Benutzerna me“ 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_DISABL ED ausgegeben wird. Tag REG_DWORD Legt die Reihenfolge des Dienststarts in einer Ladegruppe fest. Tags werden nur bei Treiberdiensten überprüft. 52 Wert Typ Beschreibung Type 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 Exchangespezifischen 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_SZParameter 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 angegeben. Für die Leistungsindikatoren sind weitere Schlüssel vorhanden. Der 53 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. Betriebssystemdienste Exchange 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 RPCEndpunktzuordnung 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. Messagingconnectors für Messagingsysteme, die nicht auf Exchange basieren. Normale 54 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 TCPAnschluss 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 RPCVerbindung 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 TCPAnschlüsse zwischen 1024 und 5000 für die RPC-Verbindung. Bei verschiedenen Diensten, z. B. bei der Systemaufsicht und dem ExchangeInformationsspeicherdienst, können statische Anschlüsse mithilfe von 55 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 PipeZugriff 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 ExchangeStatusinformationen zugegriffen werden kann. Der WMI-Dienst ist zum Starten des Microsoft Exchange-Verwaltungsdiensts erforderlich. 56 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 2003Messagingdatenbanken 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. 57 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 ExchangeSystemereignisbenachrichtigungen. 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. 58 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 HTTPKommunikation 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 POP3Protokollmodule, ü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. 59 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 IISHauptprozess 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 MetabaseAktualisierungsdienst 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- 60 Verwaltungsdienst ist abhängig vom RPC-Dienst und vom Sicherheitskontenverwaltungsdienst. Alle anderen IIS-Dienste sind abhängig vom IISVerwaltungsdienst. 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 SMTPDienst 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 IISVerwaltungsdienst, 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. 61 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 NewsgroupDiskussionen beteiligen. Wenn der NNTP-Dienst auf einem Exchange Server 2003Server 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 NNTPDienst 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 IISVerwaltungsdienst. 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. 62 Hinweis: Da keine anderen Exchange-Dienste vom IMAP4-Dienst abhängig sind, muss der IMAP4-Dienst nicht ausgeführt werden, wenn Benutzer nicht über IMAP4Clients auf ihre Postfächer zugreifen. WWW-Veröffentlichungsdienst Der in Windows Server 2003 integrierte WWWVeröffentlichungsdienst ist ein Konfigurations- und Verarbeitungsverwaltungsdienst im Benutzermodus, über den die IIS-Komponenten verwaltet werden, die HTTPAnforderungen 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. 63 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 64 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 2003 In 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. 65 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. 66 Interne Komponenten der Systemaufsicht und ihre Funktionen Komponente Funktion Beschreibung DSAccess-Komponente Suchen der Domänencontroller im Netzwerk und Bereitstellen von Active DirectoryInformationen 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 ExchangeKomponenten, z. B. den ExchangeInformationsspeicher 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. 67 Komponente Funktion Beschreibung DSProxy-Komponente Bereitstellung von Proxyfunktionen zwischen Legacy-MAPI-Clients und Active Directory Mit der DSProxyKomponente (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. 68 Komponente Funktion Beschreibung Frei-/Gebucht-Komponente Verwalten der Frei-/GebuchtInformationen 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 ExchangeInformationsspeicher aus dem Kalender des Benutzers extrahiert und in einer Nachricht an das Postfach der Systemaufsicht gesendet. Mit der Frei-/GebuchtKomponente (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 ExchangeInformationsspeicherdiensts. Postfach-ManagerKomponente Verwalten von Postfächern Über die Postfach-ManagerKomponente werden die Richtlinien zum Aufbewahren von Nachrichten sowie Postfachkontingente angewendet, die zum Verwalten der Postfachspeichergröße eingesetzt werden können. 69 Komponente Funktion Beschreibung MetabaseAktualisierungsdienst Replizieren der Einstellungen von Active Directory in der IIS-Metabase Der Verzeichnisdienst für den MetabaseAktualisierungsdienst (Ds2mb.dll) ist eine interne Komponente der Systemaufsicht. Mit dem MetabaseAktualisierungsdienst werden Protokolleinstellungen von Active Directory in die IISMetabase repliziert. Dadurch werden die im ExchangeSystem-Manager konfigurierten Internetprotokolleinstellungen auf die Internetprotokollmodule angewendet, z. B. auf den SMTP-Dienst. Weitere Informationen zum MetabaseAktualisierungsdienst finden Sie unter Exchange Server 2003 und Active Directory. 70 Komponente Funktion Beschreibung Offlineadressbuchgenerator Erstellen von Offlineadressbüchern Mit dem Offlineadressbuchgenerator (Oabgen.dll) werden Adresslisten im ExchangeInformationsspeicher 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. 71 Komponente Funktion Beschreibung Empfängeraktualisierungsdie nst Anwenden von Empfängerrichtlinien und Erstellen von Proxyadressen Der Empfängeraktualisierungsdie nst (Abv_dg.dll) ist eine Komponente der Systemaufsicht, mit der alle E-Mail-aktivierten Benutzerobjekte und Empfängerrichtlinien überwacht sowie Empfängerrichtlinien auf EMail-aktivierte Benutzerobjekte angewendet werden. Weitere Informationen zum Empfängeraktualisierungsdie nst finden Sie unter Exchange Server 2003 und Active Directory. 72 Komponente Funktion Beschreibung Servermonitorkomponente Überwachen von Serverressourcen Mit der Systemaufsicht werden Serverressourcen in regelmäßigen Abständen überwacht und Verbindungsstatusinformatio nen mit der WindowsVerwaltungsinstrumentation (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 Verbindungsstatusinformatio nen finden Sie unter Nachrichtenroutingarchitektur . Über die Systemaufsicht werden zudem die Nachrichtenverfolgungsproto kolle verwaltet, wenn die Nachrichtenverfolgung auf einem Server aktiviert wurde. 73 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 ExchangeInformationsspeicherdienst 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 ExchangeInformationsspeicherdienst 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. 74 Architektur des Exchange-Informationsspeichers und unterstützte Messagingclients MAPI-Clients kommunizieren über MAPI-RPCs direkt mit dem ExchangeInformationsspeicherdienst. Internetclients verwenden dagegen die in IIS integrierten Protokollmodule, wie weiter oben in diesem Abschnitt beschrieben. Internetclients und Webanwendungen kommunizieren über IIS-Protokollmodule mit dem ExchangeInformationsspeicher. 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 75 kommuniziert Drviis.dll über EPOXY mit ExSMTP.dll, um den ExchangeInformationsspeicher 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 IISProtokollmodule und Webanwendungen Objekte in Messagingdatenbanken schreiben und lesen können. Für den Zugriff auf die Datenbanken muss der ExIFSDateisystemtreiber 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 MAPIClients, 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 76 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 2003 Zusä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-/GebuchtInformationen 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 KalenderConnectors 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 ExchangeInformationsspeicherdienst. Weitere Informationen zur Architektur des Connectors für Lotus Notes finden Sie unter Architektur von Gateway-Messaging-Connectors. 77 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 GatewayMessaging-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 ExchangeInformationsspeicherdienst. 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 WindowsVerwaltungsinstrumentation (WMI, Windows Management Instrumentation) ExchangeVerwaltungsinformationen 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 78 gespeichert. Der Registrierungsschlüssel lautet HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMGMT. Microsoft Exchange MTA-Stacks-Dienst Mit dem Microsoft Exchange MTA-StacksDienst (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-SystemManagers. 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-APIGateway 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 SMTPTransportsubsystem werden beim Weiterleiten von Nachrichten in der ExchangeOrganisation ü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 79 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. 80 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 2003Dienste auf einem Server In diesem Thema wird das Beenden aller Exchange Server 2003-Dienste auf einem Server erläutert. 81 Bevor Sie beginnen Bevor 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. Verfahren Beenden 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 Directory Die 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: 82 Erweiterung des Active Directory-Schemas Exchange erweitert das Active DirectorySchema 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 DSAccessKomponente 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 SMTPKategorisierungsmodul 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 WWWDienst. Diese Einstellungen werden vom Metabase-Aktualisierungsdienst in die IISMetabase ü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 83 Verzeichnisintegration und Exchange Server 2003 Die 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 Directory Im 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 DirectoryGesamtstruktur muss dieses Schema von Exchange geändert werden, sodass Exchangespezifische Empfänger- und Konfigurationsinformationen von Active Directory gespeichert werden können. Mit dem Prozess ForestPrep im Exchange-Setup wird das Active DirectorySchema erweitert. Sie können diesen Prozess auch explizit über die Befehlszeile 84 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.5Organisation in Active Directory verwendet werden können. Schema2.ldf Enthält Schemaerweiterungen für Internetzugriffsprotokolle, die Verzeichnissynchronisierung und für Konfigurationsobjekte des ExchangeInformationsspeichers. 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. 85 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 ESEParameter (Extensible Storage Engine). Schema6.ldf Enthält Schemaerweiterungen für virtuelle Protokollserver, administrative Gruppen, Messagingconnectors und den ExchangeInformationsspeicher. Schema7.ldf Enthält Schemaerweiterungen für Messagingdatenbanken und den PostfachManager. 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 KalenderConnector, 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. 86 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 DirectoryTools (z. B. Ldifde.exe) zum Reparieren eines beschädigten Active DirectorySchemas 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. Verzeichnisdienstzugriff Exchange 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 DirectoryDomä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 ExchangeKomponenten 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 WindowsVerwaltungsinstrumentation (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 ExchangeKomponenten 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. 87 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 DLLBegleitdateien 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. 88 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. 89 Lastenausgleich und Failover durch LDAPVerbindungen DSAccess 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 LDAPVerbindungen 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 90 werden kann. Die Verwendbarkeitstests für Server werden weiter unten in diesem Abschnitt behandelt. 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-Topologieerkennung Beim Starten von DSAccess wird ein Suchprozess zum Identifizieren der Active DirectoryTopologie 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: 91 1. DSAccess.dll wird beim Starten vom Systemaufsichtsprozess (Mad.exe) instantiiert und initialisiert. 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\MSExchangeDSAc cess Wert TopoCreateTimeoutSecs Typ REG_DWORD Beschreibung Legt den Timeoutwert für die DSAccessInitialisierung in Sekunden fest, z. B. 0x200. Die Standardeinstellung ist 0x3C Sekunden (1 Minute). 92 Hinweis: Wenn Sie den Diagnoseprotokollierungsgrad für alle Kategorien des Diensts MSExchangeDSAccess auf Maximum festlegen, ruft der Exchange-SystemManager automatisch umfassende Informationen über die Initialisierung von DSAccess ab und speichert diese Informationen im Anwendungsereignisprotokoll. Erste Suche und laufende neue Suche Nach 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\MSExchangeDSAc cess Wert LdapKeepAliveSecs 93 Typ REG_DWORD 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 ACLBerechtigungen 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 2003Serverobjekt im Exchange-Konfigurationscontainer enthalten. Synchronisierung DSAccess ermittelt, ob das isSynchronized-Attribut im rootDSEObjekt 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 94 verringert wird, sollten Sie den folgenden Registrierungsschlüssel erstellen. Dadurch sendet DSAccess keine NetLogon-Überprüfungen mehr. Speicherort HKEY_LOCAL_MACHINE\SYSTEM \CurrentControlSet\Services\MSExchangeDSAc cess 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. 95 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. 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-Servern DSAccess 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. 96 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 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-Profile Die 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\Defau lt. 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> 97 Wert DSType Typ REG_SZ Wert 0 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 98 Speicherort MSExchangeDSAccess\Profiles\Default\<Name of GC> Wert PortNumber Typ REG_DWORD Wert 0x00000cc4 (3268) Angeben des Konfigurationsdomänencontrollers Es 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. 99 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, 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 DSAccess In 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äne In 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. 100 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 101 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änentopologie In 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: 102 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. 103 Verzeichniszugriffscache Beim 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 DirectoryInformationen im Cache profitieren. Prozesse, die „DSAccess.dll“ laden Prozess Beschreibung Mad.exe Microsoft Exchange-Systemaufsichtsdienst Store.exe Microsoft ExchangeInformationsspeicherdienst 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 104 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-ToLive) für die Konfigurationsdaten im Cache verwendet. Speicherort MSExchangeDSAccess\Instance0 Wert MaxEntriesConfig Typ REG_DWORD Wert 0 (no limit) 105 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-ToLive) 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 DSAccess Durch 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 106 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=% 107 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 ExchangeSuchlä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 beispielsweise keinen gültigen geladenen Suchfilter dar, da es sich bei 108 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. Verzeichnisdienstproxy Verzeichnisdienstproxy (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 Service Release 2 (SR2) wird der Verweis bei jedem Start von Outlook aktualisiert. 109 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-Operationen DSProxy 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 Verweisen In 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 Verzeichnisanforderungen direkt an den globalen Katalogserver gesendet, auf den verwiesen wurde. 110 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 OutlookClient 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 SP2 Die 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 DirectoryStandorts 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. 111 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 DirectoryStandort 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 OutlookOption 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“ 112 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 Verweisen In 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 Algorithmus Der 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 DirectoryStandort 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 113 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. 114 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- Wird von DSAccess Gesamtanzahl von Standort verwendet? Punkten als Wert für die Einschränkungen UserDomain GC1 Active DirectoryStandort des Client Nein 16+8+4=28 (1, 2, 3) 115 Server Active Directory- Wird von DSAccess Gesamtanzahl von Standort verwendet? Punkten als Wert für die Einschränkungen UserDomain GC2 Active DirectoryStandort des Client Nein Active DirectoryStandort B Nein Active DirectoryStandort B Nein Exchange Domain GC1 Exchange Active DirectoryStandort Ja Exchange Domain GC2 Exchange Active DirectoryStandort Ja Exchange Domain GC3 Active DirectoryStandort A Nein Exchange Domain GC4 Active DirectoryStandort A Nein Exchange Domain GC5 Active DirectoryStandort B Nein Exchange Domain GC6 Active DirectoryStandort B Nein UserDomain GC3 UserDomain GC4 16+8+4=28 (1, 2, 3) 16+8+4=28 (1, 2, 3) 16+8+4=28 (1, 2, 3) 16+8+2+1=27 (1, 2, 4, 5) 16+8+2+1=27 (1, 2, 4, 5) 16+8=24 (1, 2) 16+8=24 (1, 2) 16+8=24 (1, 2) 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 DirectoryStandort des Exchange-Servers verbunden sind. Mit anderen Worten: der ExchangeServer verwendet diese globalen Katalogserver nie für DSAccess- oder DSProxyFunktionen. 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. 116 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 PostfachStammdomä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 SP2 Die Ä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. 117 Auswirkungen des DSProxy-Verhaltens bei Verweisen In 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-Kategorisierungsmodul Das 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 118 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 Directory Bei 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. 119 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: 120 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 SMTPAdressen 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-MailNachricht 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 IISKategorisierungsmodul durch Hinzufügen der folgenden drei Ereignissenken: Register Diese Ereignissenke initialisiert die Komponenten des ExchangeKategorisierungsmoduls, 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 DSAccessCache gespeichert ist. Bei einem positiven Ergebnis dieser Überprüfung wird ein Objekt ICategorizerItemAttributes zurückgegeben. Dadurch wird der VerzeichnisdienstSuchlaufcode 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 2003 Exchange 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 121 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ängerobjekten Die 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. 122 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 ExchangeSystem-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. 123 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-Aktualisierungsdienst Der Metabase-Aktualisierungsdienst, der auch als Verzeichnisdienst/MetabaseSynchronisierungsprozess 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. 124 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änge Die 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-SystemManagers Der 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 2003Organisationen 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. 125 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-SystemManager 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-SystemManager 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 MMC Bei der Installation des Exchange-System-Managers auf einem Server mit Exchange Server 2003 oder auf einem Verwaltungscomputer werden die Exchange-MMCSnap-Ins vom Setupprogramm in der lokalen Registrierung registriert, damit diese Snap-Ins 126 im MMC-Tool zur Verfügung stehen. Die Snap-Ins sind in COM-In-Process-Server-DLLDateien (Component Object Model Dynamic Link Libraries) implementiert. Im Unterschied zu einer eigenständigen Anwendung, die als separater Prozess ausgeführt wird, stellt eine InProcess-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 HKEY_LOCAL_MACHINE\Software\Microsoft\MMC\SnapIns 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. Zur Definition von COMKomponenten 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-11d29F28-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. 127 Registrierungsparameter für MMC-Snap-Ins Übergeordneter Parameter Typ Beschreibung NameString REG_SZ Durch den Wert NameString wird der Anzeigename des Snap-Ins angegeben, der in der MMCBenutzeroberfläche angezeigt wird, wenn einer Konsole ein Snap-In hinzugefügt wird. Beispielsweise wird durch Namestring=Exchan ge-System der Anzeigename für das Exchange-SystemSnap-In definiert. Schlüssel {CLSID} 128 Übergeordneter Parameter Typ Beschreibung 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= {1B600AEB10BA-11d2-9F2800C04FA37610} auf eine bestimmte CLSID. Wenn Sie diese CLSID unter Schlüssel {CLSID} HKEY_CLASSES_ROOT\CL suchen, können Sie erkennen, dass es sich um die CLSID für die Klasse AboutSystemMgr handelt, die ebenfalls in Exadmin.dll implementiert ist. SID 129 Übergeordneter Parameter Typ Beschreibung NameStringIndirect REG_SZ Der Wert für Schlüssel {CLSID} NameStringIndirect definiert einen Ressourcen-DLLNamen sowie eine Zeichenfolgenkennun g und bietet somit eine indirekte Möglichkeit, den Namen des Snap-Ins abzurufen. Beispielsweise wird durch NameStringIndirect =@C:\\Programme\\ Exchsrvr\\bin\\exad min.dll,-12577 der in der Datei Exadmin.dll enthaltene Name des Exchange-SystemSnap-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. 130 Übergeordneter Parameter Typ Beschreibung N/A N/A Durch einen vorhandenen Schlüssel StandAlone wird angegeben, dass es sich um ein eigenständiges SnapIn handelt. Eigenständige SnapIns können im Dialogfeld Snap-In hinzufügen/entferne n zu einer MMCKonsole hinzugefügt werden. Sie können eigenständige SnapIns zu Unterknoten anderer Snap-Ins hinzufügen, indem Sie das eigenständige SnapIn wie ein Erweiterungs-Snap-In behandeln. Schlüssel {CLSID}\ StandAlone Erweiterungs-SnapIns 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 SnapIn hinzugefügt wird, das die Knoten bereitstellt, die dann durch das Erweiterungs-Snap-In erweitert werden können. Beispielsweise wird durch das ExchangeInformationsspeicherErweiterungs-Snap-In das System- 131 Übergeordneter Parameter Typ Beschreibung {CLSID} N/A Knoten beziehen sich auf die Konfigurationsobjekte in der MMCKonsolenstruktur. Im Exchange-SystemManager haben zum Beispiel die einzelnen Serverobjekte im Container Server unter einer administrativen Gruppe einen bestimmten Knotentyp. Knotentypen sind im Schlüssel NodeTypes registriert. Schlüssel {CLSID}\ NodeTypes 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-SnapIns für diese Knotentypen abgerufen werden. Die ErweiterungsSnap-Ins werden dann als verfügbare Erweiterungen für das Snap-In im Dialogfeld Snap-In hinzufügen/entferne n auf der Registerkarte Erweiterungen angezeigt. 132 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-9F2800C04FA37610}) ein erweiterbarer Knotentyp des Exchange-Protokolle-Snap-Ins. KEY_LOCAL_MACHINE\Software\Microsoft\MMC\NodeTypes Ebenso verfügt der Schlüssel \NodeTypes\{F54E0C6b-11FF-11d2-9F28-00C04FA37610} über einen Unterschlüssel Extensions, durch den die CLSID des Exchange-POP3Erweiterungs-Snap-Ins in den Unterschlüsseln ContextMenu und NameSpace aufgelistet werden. Dadurch wird angegeben, dass durch das Exchange-POP3-Erweiterungs-SnapIn 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-InErweiterungen Wie im vorherigen Abschnitt erläutert, wird durch eigenständige Snap-Ins und ErweiterungsSnap-Ins die Benutzeroberfläche des Exchange-System-Managers erstellt. Mit ErweiterungsSnap-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 MMCKonsole 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. 133 Exchange Server 2003-Snap-Ins und Snap-In-Erweiterungen Snap-In Snap-In-Erweiterung In-Process-Server- Beschreibung DLL ExchangeNachrichtenstatus Nicht zutreffend Exadmin.dll Bietet Zugriff auf den Nachrichtenstatus. Dies ist ein eigenständiges SnapIn. Exchange-Protokolle Nicht zutreffend Exadmin.dll Implementiert den Container Protokolle und stellt Unterknoten bereit, die von zusätzlichen Erweiterungs-SnapIns verwendet werden können, um die Benutzeroberfläche im ExchangeSystem-Manager zu erweitern. Das Exchange-SnapIn Protokolle ist ein Erweiterungs-Snap-In des eigenständigen Snap-Ins ExchangeSystem. Dieses Snap-In ist ebenfalls ein ErweiterungsSnap-In für das Erweiterungs-Snap-In Exchange-Server. Exchange-HTTP Exadmin.dll Ermöglicht die Verwaltung des HTTP-Protokolls und virtueller HTTPServer. 134 Snap-In Snap-In-Erweiterung In-Process-Server- Beschreibung DLL Exchange-IMAP4 Imapmgr.dll Ermöglicht die Verwaltung von IMAP4 (Internet Mail Access Protocol, Version 4) und virtueller IMAP4Server. Exchange-NNTP Nntpmgr.dll Ermöglicht die Verwaltung von NNTP (Network News Transfer Protocol) und virtueller NNTPServer. Exchange-POP3 Pop3mgr.dll Ermöglicht die Verwaltung des POP3-Protokolls und virtueller POP3Server. Exchange-SMTP Exps.dll Ermöglicht die Verwaltung von SMTP (Simple Mail Transfer Protocol) und virtueller SMTPServer. Exchange-X.400 Exadmin.dll Ermöglicht die Verwaltung des lokalen MTA (Message Transfer Agent) und der X.400Protokolleinstellunge n. 135 Snap-In Snap-In-Erweiterung In-Process-Server- Beschreibung DLL Exchange-Server Nicht zutreffend Exadmin.dll Ermöglicht die Verwaltung von speicherspezifischen Einstellungen eines Exchange-Servers. Das Snap-In Exchange-Server ist ein ErweiterungsSnap-In des eigenständigen Snap-Ins ExchangeSystem. 136 Snap-In Snap-In-Erweiterung In-Process-Server- Beschreibung DLL Exchange-DXA Exadmin.dll Ermöglicht die Überprüfung von Einstellungen für die Verzeichnissynchroni sierung, 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 20 00 ServerRessourcen mit dem SystemManager von Exchange Server 2003 wird nicht unterstützt. Stellen Sie sicher, dass Sie zum Konfigurieren der Verzeichniss ynchronisieru ng mit Microsoft Mail den SystemManager von Exchange 20 00 verwenden. 137 Snap-In Snap-In-Erweiterung In-Process-Server- Beschreibung DLL ExchangeInformationsspeicher Exadmin.dll Ermöglicht die Verwaltung von Speichergruppen, Postfachspeichern und Informationsspeicher n für Öffentliche Ordner. ExchangeÜberwachung Exadmin.dll Ermöglicht die Überprüfung des Zustands von Exchange-Servern und Messagingconnector s zwischen Routinggruppen. 138 Snap-In Snap-In-Erweiterung In-Process-Server- Beschreibung DLL 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 ErweiterungsSnap-Ins ExchangeHTTP, ExchangeIMAP4, ExchangeNNTP, ExchangePOP3, ExchangeSMTP und Exchange-X.400 zur Optimierung der Benutzeroberfläche im ExchangeSystem-Manager verwendet werden können. ExchangeExadmin.dll Warteschlangenanzei ge Bietet Zugriff auf die Warteschlangenanzei ge im ExchangeSystem-Manager, der Verwaltungsschnittst ellen für SMTP, MTA, X.400 und andere Connectorwarteschla ngen bereitstellt. 139 Snap-In Snap-In-Erweiterung In-Process-Server- Beschreibung DLL Exchange-System Nicht zutreffend Exadmin.dll Das grundlegende MMC-Snap-In des Exchange-SystemManagers. 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. ExchangeAdresslisten Exadmin.dll Ermöglicht die Verwaltung von Adresslisten, einschließlich globaler Adresslisten und Offlineadressbücher. ExchangeAdressvorlagen Exadmin.dll Ermöglicht die Verwaltung von Adressvorlagen. 140 Snap-In Snap-In-Erweiterung In-Process-Server- Beschreibung DLL ExchangeKalenderconnector Exadmin.dll Ermöglicht die Verwaltung von KalenderconnectorInstanzen. Mit dem Kalenderconnector können Frei/GebuchtInformationen zwischen ExchangeBenutzern und Benutzern von Lotus Notes oder Novell GroupWise synchronisiert werden. 141 Snap-In Snap-In-Erweiterung In-Process-Server- Beschreibung DLL 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 20 00 ServerRessourcen mit dem SystemManager von Exchange Server 2003 wird nicht unterstützt. Stellen Sie sicher, dass Sie zum Konfigurieren von Connector für Lotus cc:Mail den SystemManager von Exchange 20 00 verwenden. 142 Snap-In Snap-In-Erweiterung In-Process-Server- Beschreibung DLL Exchange-DXA Exadmin.dll Ermöglicht die Überprüfung von Einstellungen für die Verzeichnissynchroni sierung, wenn Connector für Microsoft Mail auf einem Server mit einer älteren Version von Exchange ausgeführt wird. Hinweis: Die Konfiguration von Exchange 20 00 ServerRessourcen mit dem SystemManager von Exchange Server 2003 wird nicht unterstützt. Stellen Sie sicher, dass Sie zum Konfigurieren der Verzeichniss ynchronisieru ng mit Microsoft Mail den SystemManager von Exchange 20 00 verwenden. 143 Snap-In Snap-In-Erweiterung In-Process-Server- Beschreibung DLL 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. ExchangeInformationsspeicher Exadmin.dll Ermöglicht die Verwaltung von Speichergruppen, Postfachspeichern und Informationsspeicher n für Öffentliche Ordner. Wiederherstellung von ExchangePostfä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. ExchangeNachrichtenstatus 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. 144 Snap-In Snap-In-Erweiterung In-Process-Server- Beschreibung DLL Exchange MSMail Exadmin.dll Ermöglicht die Überprüfung der Konfigurationseinstell ungen von Connector für Microsoft Mail auf Exchange 2000Servern. Hinweis: Die Konfiguration von Exchange 20 00 ServerRessourcen mit dem SystemManager von Exchange Server 2003 wird nicht unterstützt. Stellen Sie sicher, dass Sie zum Konfigurieren von Connector für Microsoft Mail den SystemManager von Exchange 20 00 verwenden. Exchange Notes Connector Exadmin.dll Bietet Zugriff auf die Konfigurationseinstell ungen von Connector für Lotus Notes. 145 Snap-In Snap-In-Erweiterung In-Process-Server- Beschreibung DLL 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 ErweiterungsSnap-Ins ExchangeHTTP, ExchangeIMAP4, ExchangeNNTP, ExchangePOP3, ExchangeSMTP und Exchange-X.400 zur Optimierung der Benutzeroberfläche im ExchangeSystem-Manager verwendet werden können. ExchangeExadmin.dll Warteschlangenanzei ge Bietet Zugriff auf die Warteschlangenanzei ge im ExchangeSystem-Manager, der Verwaltungsschnittst ellen für SMTP, MTA, X.400 und andere Connectorwarteschla ngen bereitstellt. 146 Snap-In Snap-In-Erweiterung In-Process-Server- Beschreibung DLL ExchangeEmpfängerrichtlinien Exadmin.dll Ermöglicht die Verwaltung von Empfängerrichtlinien, mithilfe derer der Empfängeraktualisier ungsdienst Empfängerinformatio nen (z. B. E-MailAdressen) den entsprechenden Benutzerkonten zuordnet. 147 Snap-In Snap-In-Erweiterung In-Process-Server- Beschreibung DLL Exchange Schedule+ Frei-/GebuchtConnector Exadmin.dll Ermöglicht die Überprüfung der Konfigurationseinstell ungen des Schedule+ Frei-/GebuchtConnectors auf Servern, auf denen Exchange 2000 Server ausgeführt wird. Hinweis: Die Konfiguration von Exchange 20 00 ServerRessourcen mit dem SystemManager von Exchange Server 2003 wird nicht unterstützt. Stellen Sie sicher, dass Sie zum Konfigurieren des Schedule+ Frei/GebuchtConnectors den SystemManager von Exchange 20 00 verwenden. 148 Snap-In Snap-In-Erweiterung In-Process-Server- Beschreibung DLL Exchange-Server Exadmin.dll Ermöglicht die Verwaltung von speicherspezifischen Einstellungen eines Exchange-Servers. Erstellen benutzerdefinierter ExchangeVerwaltungskonsolen Zum Erstellen benutzerdefinierter Verwaltungskonsolen auf Grundlage von Exchange-SnapIns können Sie die eigenständigen Snap-Ins Exchange-System oder ExchangeNachrichtenstatus 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 149 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 150 Snap-Ins bereitgestellten Knoten und Funktionen abhängig und funktionieren daher als eigenständige Snap-Ins nicht ordnungsgemäß. Verwalten von Konfigurationsinformationen in Active Directory Wenn 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 2003Organisation 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änencontroller Der 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 151 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:1oder 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 RPCProtokollbindungsreihenfolge 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-ErsterStandortname,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. 152 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 Konfigurationsverzeichnispartition Die 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 ExchangeSystem-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. 153 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-MailAdressen 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- 154 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 ExchangeOrganisationsobjekt 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-SystemManager 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 155 Ö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 Berechtigungseinstellungen Das Berechtigungsmodell von Exchange Server 2003 basiert vollständig auf dem Microsoft Windows-Sicherheitsmodell. Das Berechtigungsmodell orientiert sich am ExchangeOrganisationsobjekt und den administrativen Gruppen in der Konfigurationsverzeichnispartition. Wenn Sie mit der rechten Maustaste auf das Organisationsobjekt oder die administrative Gruppe in der Konsolenstruktur des ExchangeSystem-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 ExchangeAdministrator 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 156 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 Sicherheitseinstellung Exchange- Exchange- en ändern Konfigurationseinstell Konfigurationseinstell ungen verwalten ungen 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-Manager Mit dem Assistenten für die Zuweisung von Verwaltungsberechtigungen können ExchangeAdministratoren 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 ExchangeAdministratorfunktionen zugewiesen werden, anhand eines Attributs des ExchangeOrganisationsobjekts 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. 157 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-SystemManager 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\Ex change\ExAdmin Wertname ShowSecurityPage Datentyp REG_DWORD Wert 1 158 HKEY_CURRENT_USER\Software\Microsoft\Ex change\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-SystemManager angezeigt. Änderungen werden sofort wirksam. Der Exchange-SystemManager 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 ExchangeSystem-Manager Wenn 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. 159 Standardkonten mit Berechtigungen in einer Exchange-Organisation Konto Zugelassen Verweigert ANONYMOUSANMELDUNG Benannte Eigenschaften im Informationsspeicher erstellen Keine Öffentlichen Ordner erstellen Ausführen Inhalt auflisten Objekt auflisten Lesen Berechtigungen lesen Eigenschaften lesen Eigenschaften lesen Objekt auflisten Authentifizierte Benutzer Keine 160 Konto Zugelassen Verweigert Domänen-Admins (Stammdomäne) Lesen Empfangen als Schreiben Senden als 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 Öffentliche Ordner der obersten Ebene erstellen Verwaltungs-ACL für Öffentlichen Ordner ändern Replikatlisten für Öffentliche Ordner ändern Warteschlange für EMail-Versand öffnen Metabase-Eigenschaften lesen Informationsspeicher verwalten Benannte Eigenschaften im Informationsspeicher erstellen Status des Informationsspeichers anzeigen 161 Konto Zugelassen Verweigert Organisations-Admins Empfangen als Senden als Jeder Exchange Domain Servers Vollzugriff Benannte Eigenschaften im Informationsspeicher erstellen Öffentlichen Ordner erstellen Ausführen Inhalt auflisten Objekt auflisten Lesen Berechtigungen lesen Eigenschaften lesen Vollzugriff Keine 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 ExchangeOrganisation, übernommen werden. 162 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 ExchangeSystem-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. 163 Verwalten von ExchangeInformationsspeicherressourcen Active Directory ist nicht der einzige Kommunikationspartner des Exchange-SystemManagers. 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 Kommunikation In der folgenden Abbildung ist der Unterschied zwischen Objekten eines Postfachspeichers und des Informationsspeichers für Öffentliche Ordner in Active Directory und im ExchangeSystem-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. 164 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 Informationen Die 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. 165 Hinweis: Für die MAPI-basierte Kommunikation ist es erforderlich, dass Sie ein ExchangeSystem-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 MAPIProfil 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 MAPITabelle 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 ExchangeInformationsspeicher 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. 166 Exchange-System-Manager und MAPI-basierte Clients Da 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 Kommunikation Zum 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. 167 DAV-basierte Kommunikation und virtuelle HTTP-Verzeichnisse Standardmäß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. 168 In der folgenden Abbildung ist dargestellt, wie der Inhalt eines Öffentlichen Ordners im Exchange-System-Manager angezeigt wird. 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 ExchangeSystem-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 ExchangeInformationsspeicher kommuniziert. 169 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 OrdnerHierarchie 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 170 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-SystemManager, 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-AgentHTTP-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-SystemManager zurück. 4. Anzeigen der Öffentlichen Ordner der obersten Ebene Der Exchange-SystemManager 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 IPMUnterstruktur (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 ExchangeServer Sie 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 171 anwenden, um Probleme im Zusammenhang mit einer Replikation der Hierarchie zu diagnostizieren. Ausführliche Anweisungen zum Verbinden mit einem bestimmten ExchangeServer finden Sie unter Verbinden mit einem bestimmten Exchange-Server im ExchangeSystem-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 Standardwebsite Unabhä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-SystemManager standardmäßig eine Verbindung mit TCP-Anschluss 80 herstellt und den Namen des Exchange-Servers im Hostheaderwert der HTTP-Anforderungen angibt. Wenn Sie in IISManager 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- 172 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 TCPAnschluss 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 SSLVerschlüsselung Die 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. 173 Verbindungsherstellung mit „Exadmin“ über HTTPS Bei der erstmaligen Verbindungsherstellung über HTTPS führt der Exchange-SystemManager 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 SSLspezifische 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 ExchangeSystem-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 174 (FQDN) des lokalen Exchange-Servers als gemeinsamer Name (CN) der Website aufgeführt sein. Außerdem muss der Computer, auf dem der ExchangeSystem-Manager ausgeführt wird, der Zertifizierungsstelle vertrauen, von der das SSL-Zertifikat ausgestellt wurde. Andernfalls weist der Exchange-SystemManager 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 Informationen In 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. Verfahren Anzeigen 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. 175 Verbinden mit einem bestimmten Exchange-Server im Exchange-SystemManager In diesem Thema wird das Verbinden mit einem bestimmten Exchange-Server im ExchangeSystem-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. Verfahren Verbinden 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 WindowsVerwaltungsinstrumentation Der Exchange-System-Manager ist auch eine WMI-Verwaltungsanwendung (WindowsVerwaltungsinstrumentation – 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 CIMObjekt-Manager (Common Information Model) und WMI-Anbietern besteht. 176 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 WMIVerwaltungsanwendung. 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 CIMDatenbank 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 177 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-SystemManager 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 2003Servereigenschaften auf die Registerkarte Verzeichniszugriff klicken. Der WMI-Anbieter ExchangeDsAccessProvider ist im Microsoft ExchangeVerwaltungsdienst (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 ExchangeVerwaltungsdienst 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 MMCTools verwendet werden. In Exchange Server 2003 werden von diesem Snap-In die 178 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 ExchangeVerwaltungsdienst 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 ExchangeNachrichtenstatus 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 ExchangeVerwaltungsdienst in das WMI-Subsystem integriert sind. 179 Exchange-Anbieter im WMI-Subsystem Dienstkonfiguration im Exchange-SystemManager Zur 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 RegistrierungsAPI 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. 180 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. 181 In der Standardkonfiguration von Windows wird nur lokalen Administratoren der Remotezugriff auf die Registrierung gestattet. Um sicherzustellen, dass ExchangeAdministratoren 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-SystemManager 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 ExchangeAdministratoren 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 auf einem ExchangeServer 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. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Services Nachrichtenroutingarchitektur Beim 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 182 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 ExchangeServern 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. 183 Nachrichtenroutingtopologie in Exchange Server 2003 In der folgenden Abbildung ist die Routingtopologie einer Exchange Server 2003Organisation 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 184 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/?LinkI d=26041). Routinggruppenconnectors Ein Routinggruppenconnector ermöglicht die Nachrichtenübertragung zwischen zwei Routinggruppen. Folgende ExchangeConnectors 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. 185 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 SMTPConnector 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 ExchangeServern mit anderen X.400-Systemen oder mit Servern bestimmt, auf denen Exchange Server 5.5 ausgeführt wird und die sich außerhalb einer ExchangeOrganisation 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 186 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 EMail ü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 2003 Die 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- 187 Transportarchitektur von Exchange Server 2003 dargestellt. Ausführliche Informationen zu 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: 188 1. Wie in der folgenden Tabelle erläutert, kann eine Nachricht durch SMTP, Remoteprozeduraufrufe (RPCs) oder die Übertragungsprotokolle X.400 bzw. MAPI empfangen werden. 189 Übertragungsprotokolle für eingehende Nachrichten Übertragungsprotokoll Beschreibung SMTP Exchange 2000- und Exchange Server 2003Server 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 SMTPProtokolldienst 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 2003Server 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 SMTPServers 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. 190 Ü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.5Server an einem Remotestandort verbunden ist. In diesem Fall verwendet der Routinggruppenconnector kein SMTP, sondern wechselt automatisch in den RPCModus, um die Abwärtskompatibilität mit Exchange 5.5 zu gewährleisten. 191 Übertragungsprotokoll Beschreibung X.400 Wenn Sie Nachrichten mit einem X.400Remote-MTA (Message Transfer Agent) austauschen möchten, muss ein X.400Connector 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.400Nachrichten 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.400Architektur finden Sie unter X.400Transportarchitektur. 192 Ü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 ExchangeInformationsspeicher dann über die Übertragung der Nachricht. MAPI-basierte Messagingconnectors verwenden jedoch als Warteschlange für eingehende Nachrichten den Ordner MTS-IN im ExchangeInformationsspeicher. Eingehende Nachrichten werden von MAPI-basierten Messagingconnectors in das ExchangeFormat umgewandelt und anschließend im Ordner MTS-IN gespeichert. In jedem Fall wird die MAPI-Nachricht im ExchangeInformationsspeicher abgelegt. Anschließend wird die Nachricht vom ExchangeInformationsspeichertreiber in die Warteschlange vor der Übermittlung eingereiht. Weitere Informationen zu MAPIbasierte Messagingconnectors finden Sie unter Architektur von Gateway-MessagingConnectors. 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 SMTPVerarbeitungscode (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 EMail-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, 193 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. 194 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.400Connector 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. 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). 195 Hoptyp Beschreibung 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. 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 ExchangeSystem-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. 196 6. Nachrichten in Verbindungswarteschlangen werden im Unterschied zur Exchange-MTAWarteschlange mit dem SMTP-Protokollmodul übertragen. Nachrichten in der ExchangeMTA-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.400Transportarchitektur. Nachrichtenrouting unter Exchange Server 2003 Wenn Nachrichten nicht an lokale Empfänger gerichtet sind, müssen für das erweiterte Warteschlangenmodul vom Routingmodul Informationen zum Host für den nächsten Hop auf dem Übertragungspfad des Ziels sowie zum Typ des nächsten Hops bereitgestellt werden (siehe 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 Verbindungsstatustabelle Jeder Exchange 2003-Server verwaltet im Speicher dynamisch eine eigene, als Verbindungsstatustabelle bezeichnete Routingtabelle, die wie im Folgenden erläutert auf Active Directory und Verbindungsstatusinformationen beruht: Routing-bezogene Active Directory-Informationen Diese Informationen werden in Attributen des Organisationsobjekts, von Routinggruppenobjekten, Connectorobjekten und Serverobjekten gespeichert. Diese Objekte befinden sich in der 197 Konfigurationsverzeichnispartition und definieren die Routingtopologie der gesamten Exchange-Organisation. Hinweis: Administrative Gruppen sind nicht Teil der Routingtopologie in einer ExchangeOrganisation. Verbindungsstatusinformationen Durch diese Informationen wird angegeben, ob ein Connector in der Routingtopologie verfügbar (in Betrieb) oder nicht verfügbar (außer Betrieb) ist. Verbindungsstatusinformationen sind dynamisch und können sich unter Umständen ändern, wenn an einem Connector Übertragungsprobleme auftreten oder Übertragungsprobleme behoben werden. Weitere Informationen zu Verbindungsstatusänderungen sowie zum Verteilen von Verbindungsstatusinformationen in einer Exchange-Organisation finden Sie unter Verbindungsstatusweitergabe. Initialisieren der Verbindungsstatustabelle Nach dem Starten initialisiert jeder Exchange-Server seine Verbindungsstatustabelle anhand der folgenden Informationen aus Active Directory: Organisationsobjekt Die Grenze der Routingtopologie ist die Exchange-Organisation. Die Verbindungsstatustabelle enthält somit keine Informationen über externe Bridgeheadserver oder Messagingconnectors in einem externen Messagingsystem. Aus Sicht des Routingmoduls endet die Routingtopologie am Connector zum externen Messagingsystem. Dementsprechend liest das Routingmodul die im Attribut objectGUID des Exchange-Organisationsobjekts in Active Directory registrierte GUID und kennzeichnet die Verbindungsstatustabelle mit dieser GUID, um die Organisation zu 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. 198 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 ExchangeOrganisation. Es wird davon ausgegangen, dass alle Verbindungen betriebsbereit und zur Nachrichtenübertragung verfügbar sind. Nach der Initialisierung der Verbindungsstatustabelle kommuniziert das Routingmodul mit dem Dienst Microsoft Exchange-Routingmodul auf dem lokalen Server, um dynamische Verbindungsstatusinformationen zu erhalten, die den aktuellen Zustand jedes Connectors angeben. Der Dienst Exchange-Routingmodul stellt über den TCP-Anschluss 691 eine Verbindung mit dem Routinggruppenmaster in der lokalen Routinggruppe her, um diese Informationen abzurufen. Weitere Informationen zu Verbindungsstatusinformationen finden Sie im Abschnitt „Überprüfen der Verbindungsstatustabelle“ weiter unten in diesem Abschnitt. Routingmodul und der Dienst ExchangeRoutingmodul Das Routingmodul im Transportsubsystem und der Dienst Exchange-Routingmodul führen jeweils unterschiedliche Funktionen aus. Der Dienst Exchange-Routingmodul führt kein Nachrichtenrouting durch. Stattdessen kommuniziert der Dienst Exchange-Routingmodul Verbindungsstatusinformationen zwischen Servern in der lokalen Routinggruppe, auf denen Exchange 2000 Server und Exchange Server 2003 ausgeführt wird. Der Dienst ExchangeRoutingmodul 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 SMTPWarteschlangenmodul und Exchange-MTA zum Nachrichtenrouting verwendet wird, wird in der Datei reapi.dll implementiert. Zusätzlicher Programmcode für den Exchange-MTA ist in 199 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 ExchangeRoutingmodul auf allen Servern deaktivieren, auf denen Exchange Server 2003 in einer Organisation ausgeführt wird. Mit dem Code in reapi.dll kann die Verbindungsstatustabelle dennoch auf jedem Server mit Informationen aus Active Directory initialisiert werden, es erfolgen jedoch keine dynamischen Aktualisierungen der Verbindungsstatustabelle mehr. In diesem Fall wird von Exchange Server 2003 ein statisches Nachrichtenrouting ausgeführt. Überprüfen der Verbindungsstatustabelle Bei der Verbindungsstatustabelle handelt es sich um eine kleine, im Arbeitsspeicher abgelegte Datenbank, die nicht auf der Festplatte gespeichert wird. Zum Überprüfen der Einträge, auf deren Grundlage das Routingmodul entsprechende Routingentscheidungen trifft, können Sie das Tool Exchange Server 2003 WinRoute (Winroute.exe) verwenden, das auf der Website Downloads for Exchange Server 2003 heruntergeladen werden kann. 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 herunterzuladen und für alle Exchange 2000- und Exchange Server 2003Server in der Organisation zu verwenden. Das Tool WinRoute stellt eine Verbindung mit dem Verbindungsstatusanschluss (TCPAnschluss 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 200 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-9B8F4403F20CAD0D ( 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 d38082e7c9ecd74dbff32bada89 Die GUID, die im objectGUID-Attribut des ExchangeOrganisationsobjekts in Active Directory registriert ist. 32642 201 Feld Wert Beschreibung MD5-Hashwert d037d6eaf2fa7cd10934aca4333 Ein MD5-Hashwert (Message Digest 5). Hierbei handelt es sich um eine verschlüsselte Signatur, die die Versionsnummer der Verbindungsstatustabelle angibt. Anhand dieser Informationen können Routingmodule feststellen, ob sie über dieselben Verbindungsstatusinformatio nen verfügen. Bei unterschiedlichen Informationen tauschen die Routingmodule OrgInfoPakete aus, um zu ermitteln, welcher Server über die neuesten Informationen verfügt. Das OrgInfo-Paket enthält die Verbindungsstatustabelle mit allen Details und den Zuständen der Routingtopologie. Die Weitergabe der Verbindungsstatusinformatio nen wird weiter unten in diesem Abschnitt behandelt. 90623 Routinggruppen-objectGUID 489416bfa3a4ff459b8f4403f20 cad0d Die GUID, die im objectGUID-Attribut des Routinggruppenobjekts registriert ist, zu dem die Routinginformationen gehören. Diese GUID ist in der Verbindungsstatustabelle als nächstes Element aufgeführt. 202 Feld Wert Beschreibung RoutinggruppenmasterobjectGUID 1650c1fe32aef740be236e1089e Die GUID, die im objectGUID-Attribut des Servers registriert ist, der als Routinggruppenmaster in dieser Routinggruppe registriert ist. 0da6a Der Routinggruppenmaster in jeder Routinggruppe ist für die Verwaltung und Kommunikation der Verbindungsstatusinformatio nen an alle Routinggruppenmitglieder verantwortlich. Es ist jeweils nur ein Routinggruppenmaster je Routinggruppe vorhanden. Weitere Informationen über die Funktion des Routinggruppenmasters finden Sie in weiter unten in diesem Abschnitt. 203 Feld Wert Beschreibung Versionsinformationen 8 0 2 Die Werte 8 0 2 stellen die Haupt-, Neben- und Benutzerversionsnummern der Verbindungsstatusinformatio nen dar. Das Routingmodul verwendet diese Versionsinformationen, um Aktualisierungen der Verbindungsstatusinformatio nen wie folgt zu klassifizieren: c2da71f9b39ec748aaf44119a2b dcb36 Große Aktualisierungen Ände rungen der Routingtopologie, beispielsweise Änderungen der Connectorkonfiguration (d. h. Hinzufügen oder Löschen eines Connectors, Hinzufügen oder Löschen eines Adressraums auf einem Connector oder Festlegen eines neuen Servers als Routinggruppenmaster). Kleine Aktualisierungen Ände rungen der Verfügbarkeit eines virtuellen Servers oder eines Connectors. Beispielsweise kann sich der Status eines Connectors von verfügbar zu nicht verfügbar ändern, wenn der Quellbridgeheadserver des Connectors nicht verfügbar ist. Benutzeraktualisier ungen Änderungen, die 204 Feld Wert Beschreibung Routinggruppenadressen {26}*.489416BF-A3A4-FF45- In diesem Feld werden SMTP-, X.400-, X.500Informationen und Adressinformationen einzelnen RoutinggruppenGUIDs zugeordnet. Das Routingmodul erstellt anhand dieser Informationen einen internen Servercache, der zur Identifizierung der Routinggruppe jedes Servers in der Routingtopologie verwendet wird. Der Servercache ist eine interne Tabelle des Routingmoduls. 9B8F-4403F20CAD0D {4c}c=DE;a= ;p=TailspinToys;o=Exchange; cn=489416BF-A3A4-FF45-9B8F4403F20CAD0D;* {55}/o=TailspinToys/ou=Firs t administrative Group/*/489416BF-A3A4-FF459B8F-4403F20CAD0D Beispiel: SERVER01 verfügt in einer Routinggruppe mit der Bezeichnung Erste Routinggruppe über den FQDN SERVER01.TailspinToys.co m. Entsprechend der RoutinggruppenAdressdefinition erstellt das Routingmodul für SERVER01 folgenden Eintrag im Servercache: SERVER01.TailspinToys.com.4 89416BF-A3A4-FF45-9B8F4403F20CAD0D. Wenn bei einem Routingereignis das erweiterte Warteschlangenmodul den FQDN an das Routingmodul übergibt, sucht das Routingmodul im Servercache den Eintrag für SERVER01.TailspinToys.co m und bestimmt in kürzester Zeit die Zielroutinggruppe. Dasselbe Prinzip gilt auch für X.400- und X.500-Adressen. Die Adressinformationen sind in diesen Fällen jedoch 205 Feld Wert Beschreibung Routinggruppenmitglieder ( Enthält eine Liste aller Server, die zur Routinggruppe gehören, und kennzeichnet deren Status. Beachten Sie jedoch, dass das Routingmodul diese Informationen nicht zum Nachrichtenrouting verwendet. Wie bereits an anderer Stelle in diesem Abschnitt erläutert, verwendet das Routingmodul den Servercache. 1650c1fe32aef740be236e1089e 0da6a YES 1 1b20 {10}0701000000000101 ) Die Mitglieder der Routinggruppe sind in dieser Liste zum Zweck der Systemüberwachung aufgeführt. Sie können diese Informationen im ExchangeSystem-Manager anzeigen, indem Sie den Knoten Tools öffnen und anschließend auf Überwachung und Status sowie Status klicken. Die Serverstatuseinträge in der Liste der Routinggruppenmitglieder enthalten die folgenden Informationen: Server-objectGUID: 1650c1fe32aef740be236 e1089e0da6a Angabe, ob das Mitglied mit dem Routinggruppenmaster verbunden ist. Mit YES wird angezeigt, dass der Server verbunden ist. Serverversionsnummer: 1 Build-Version: 1b20 hex = 6944 Benutzerdaten: {10}0701000000000101 206 Feld Wert Beschreibung Connectors in Routinggruppe ( Beginnend mit der nächsten geöffneten Klammer wird jeder zur Routinggruppe gehörende Connector in einem separaten Eintrag aufgeführt, der die objectGUID des Connectors und die Konfigurationsinformationen enthält, anhand derer das Routingmodul die erforderlichen Entscheidungen bezüglich des Nachrichtenrouting trifft. aa582d35e9621c4ca8ae57aa33d 953a1 ( CONFIG )) Zu den Connectorkonfigurationsinfor mationen in der Verbindungsstatustabelle gehören folgende Felder: Connector-objectGUID aa582d35e9621c4ca8ae57aa33d 953a1 Die GUID, durch die der Connector in der ExchangeOrganisation eindeutig identifiziert wird. 207 Feld Wert Beschreibung Connectortyp {4}SMTP Nach dem Schlüsselwort CONFIG wird durch dieses Feld der Connectortyp identifiziert. Folgende Typen sind möglich: SMTP, X.400, Notes oder Exchange Development Kit (EDK). Die Typen Notes und EDK beziehen sich auf Instanzen eines MAPI-basierten Messagingconnectors, der mit einem anderen Messagingsystem als Exchange verbunden ist. Weitere Informationen über MAPI-basierte Connectors finden Sie unter Architektur von Gateway-MessagingConnectors. Tipp: Die Zahl in geschweiften Klammern ist kein Bezeichner. Durch diese Zahl wird die Länge der Zeichenfolge des Feldwerts im Hexadezimalformat angegeben. Hinweis: Es gibt keinen speziellen Typ für Routinggruppenconn ectors. Routinggruppenconn ectors verwenden zum Übertragen von Nachrichten SMTP. 208 Feld Wert Beschreibung Adresse des Quellbridgeheadservers {} Dieses Feld kann drei verschiedene Werte enthalten: Kein Wert Wenn kein Quellbridgeheadserver angegeben ist, kann jeder Server in der lokalen Routinggruppe diesen Connector zum Übertragen von Nachrichten verwenden. Dies gilt für Routinggruppenconnecto rs, wenn die Option Jeder lokale Server kann E-Mail über diesen Connector senden aktiviert ist. Eine ConnectorGUID Für SMTPConnectors und Routinggruppenconnecto rs können Sie bestimmte lokale Bridgeheadserver angeben. In diesem Fall wird im Feld für die Adresse des Quellbridgeheadservers die Connector-GUID gefolgt von _S zur Kennzeichnung eines Quellbridgeheadservers aufgeführt. Beispiel: {23}_76290a25817c0643a1 a6999e669b1d5f_S Die lokalen Bridgeheadserver werden dann im Bereich der Connectorinformationen im Feld BH aufgeführt. Eine Bridgeheadadresse X. 400-Connectors und MAPI-basierte 209 Feld Wert Beschreibung Adresse des Zielbridgeheadservers {23}_aa582d35e9621c4ca8ae57 Dieses Feld kann wie das Feld für die Adresse des Quellbridgeheadservers drei verschiedene Werte enthalten: aa33d953a1_D Kein Wert X.400Connectors und MAPIbasierten Connectors ist in der Verbindungsstatustabelle kein Zielbridgeheadserver zugeordnet. Diese Connectors verwenden zur Bestimmung des Zielsystems connectorspezifische Informationen, z. B. den Remotehostnamen in der Stackskonfiguration eines X.400-Connectors. Eine ConnectorGUID Für Routinggruppenconnecto rs wird im Feld für die Adresse des Zielbridgeheadservers die Connector-GUID aufgeführt, an die zum Kennzeichnen eines Zielbridgeheadservers die Zeichenfolge _D angehängt wird. In diesem Fall sind die Zielbridgeheadserver dann im Feld TARGBH der Connectorinformationen aufgeführt. Eine Bridgeheadadresse S MTP-Connectors können nur einen Zielhost haben, wenn sie Routinggruppen miteinander verbinden. 210 Feld Wert Beschreibung Legacy-DN {63}/o=TailspinToys/ou=Firs Dies ist der DN des Connectors im Exchange 5.5kompatiblen Verzeichnisformat. Der Wert entspricht dem legacyExchangeDN-Attribut des Connectorobjekts in Active Directory. t administrative Group/cn=Configuration/cn=C onnections/cn=RGC RG A <-> RG B Zeitplan-ID 0 Dieses Feld wird nicht verwendet und ist stets auf den Wert 0 festgelegt. Das erweiterte Warteschlangenmodul und der Exchange-MTA senden eine Abfrage an Active Directory, um den Aktivierungszeitplan eines Connectors zu ermitteln. 211 Feld Wert Beschreibung Einschränkungen 0 0 0 ffffffff ffffffff 0 1 Durch dieses Feld werden der Bereich des Connectors, die Beschränkungen der Nachrichtengröße und andere Einschränkungen wie folgt angegeben: 0 () 0 () 0 () 0 () Der Bereich des Connectors wird durch die erste Ziffer angegeben. Der Wert 0 legt die Organisation als Bereich fest. Durch den Wert 1 wird die Routinggruppe als Bereich angegeben. Hinweis: Routinggruppenconn ectors wird stets die Organisation als Bereich zugeordnet. Connectors zu externen Messagingsystemen können auf die lokalen Routinggruppen beschränkt werden. Durch die nächste Ziffer wird angegeben, ob die ausgelöste Übermittlung konfiguriert ist. Der Wert 0 bedeutet, dass keine ausgelöste Übermittlung konfiguriert wurde. Der Wert 1 bedeutet, dass der Remotehost die Nachrichtenübertragung auslösen muss (z. B. TURN/ETRN). Durch die dritte Ziffer wird der Nachrichtentyp identifiziert (hoch, normal, niedrig, System und systemfremd), der 212 Feld Wert Beschreibung Adressräume ARROWS ( {2}RG 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. {20}83bd0e29fad06d4eb8b00fa ab3265cd5 1 {4}X400 {23}c=DE;a= ;p=TailspinToys;o=Exchange; 1 ) 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 Adressrauminformatione n, die in der nächsten Position folgen. Beispielsweise erfordert ein X.400-Adressraum Adressrauminformatione n in einem gültigen X.400-Format. Ein SMTP-Adressraum enthält hingegen Teile eines SMTPDomänennamens. Für Routinggruppenconnecto rs gilt der Adressraumtyp RG, der für die objectGUID einer Routinggruppe steht. Adressraum Durch den Adressraum wird das Adressmuster angegeben, das vom Routingmodul zur 213 Feld Wert Beschreibung Quellbridgeheadserver BH () Im Feld BH werden die lokalen Bridgeheadserver für den Connector sowie deren Statusinformationen aufgeführt. Bridgeheadserver werden anhand der folgenden drei Angaben identifiziert: BridgeheadserverobjectGUID Die GUID eines virtuellen SMTPServers, der in der Connectorkonfiguration als lokaler Bridgeheadserver angegeben ist. Bridgeheadserverst atus Informationen zur Angabe der Verfügbarkeit des Bridgeheadservers: CONN_AVAIL Der Bridgeheadserver ist verfügbar. VS_NOT_STAR TED Ein virtueller SMTP-Server wurde beendet oder nicht gestartet. CONN_NOT_AV AIL Die Verbindung steht auf dem Bridgeheadserver nicht zur Verfügung. Beispielsweise kann der Quellbridgeheadserv er keine Verbindung zu einem Zielbridgeheadserver herstellen. FQDN des virtuellen 214 Feld Wert Beschreibung Zielbridgeheadserver TARGBH ( 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. 766a192b43bfc3459ee85608d65 a98a9 CONN_AVAIL {19}server01.TailspinToys.c om ) Im nachstehenden Beispiel wird der Remotebridgeheadserver durch folgende Informationen identifiziert: BridgeheadserverobjectGUID 766a192b43 bfc3459ee85608d65a98a9 Bridgeheadserverst atus CONN_AVAIL FQDN des virtuellen Servers {19}server01.T ailspinToys.com 215 Feld Wert Beschreibung Status STATE UP Der Connectorstatus. Dieses Feld kann zwei verschiedene Werte enthalten: STATE UP Gibt an, dass der Connector verfügbar ist. STATE DOWN Gibt an, dass der Connector nicht verfügbar ist. Der Connectorstatus wird vom Status der Quellbridgeheadserver des Connectors abgeleitet. Ein Connector befindet sich nur dann im Zustand STATE UP, wenn mindestens ein Quellbridgeheadserver verfügbar ist (CONN_AVAIL). Wenn kein virtueller Quellbridgeheadserver des Connectors gestartet wurde (VS_NOT_STARTED) oder die Quellbridgeheadserver keine Verbindung herstellen können (CONN_NOT_AVAIL), gilt der Connectorstatus STATE DOWN. Hinweis: Ein Connector wird nur dann als inaktiv (STATE DOWN) gekennzeichnet, wenn kein lokaler Bridgeheadserver für diesen Connector verfügbar ist. Routinggruppenconn ectors, die zur Verwendung der Option Jeder lokale Server kann E-Mail über diesen Connector senden 216 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-Routingpfadauswahl In einer Organisation mit mehreren Routinggruppen können unter Umständen verschiedene Pfade zum gleichen Ziel führen. In der Regel wird die effizienteste (d. h. die kürzeste oder kostengünstigste) Route für die Nachrichtenübertragung verwendet. Sollte die beste Route vorübergehend nicht zur Verfügung stehen, können zusätzliche, als Reserve bereitstehende Routen verwendet werden. Beispielsweise sind in der in der folgenden Abbildung dargestellten Topologie zwischen allen Routinggruppen mehrere Übertragungsrouten vorhanden. 217 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-SpokeAnordnung (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-andSpoke-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. 218 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 RoutinggruppenAdressrä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 219 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 Routingpfads Zur Auswahl der besten Route zum Ziel berechnet das Routingmodul unter Verwendung des Dijkstra-Algorithmus des kürzesten Weges den kürzesten Übertragungsweg durch die Exchange-Organisation von der Quellroutinggruppe zur Zielroutinggruppe. Das Routingmodul bestimmt anschließend den nächsten Hop auf der kürzesten Route, die vom erweiterten Warteschlangenmodul für die Nachrichtenübertragung verwendet werden soll. Die Auswahl des Routingpfads ist ein zweistufiger Vorgang: 1. Das erweiterte Warteschlangenmodul ruft in der IMessageRouter-Schnittstelle des Routingmoduls die GetMessageType-Methode auf. In der GetMessageType-Methode übergibt das erweiterte Warteschlangenmodul die Nachricht in Form eines MailMsgObjekts 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). 220 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 Weges Damit das Routingmodul richtige Routingentscheidungen treffen kann, muss es die kürzeste Route zu allen möglichen Zielen in der Routingtopologie kennen. Das Routingmodul muss die kürzesten Routen aus allen verfügbaren Übertragungsrouten zu allen Zielen in einer 221 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. 222 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 223 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 224 und des Entfernungswerts von Routinggruppe D (1+2). Aus diesem Grund werden der Entfernungswert und die Vorgängerliste von Routinggruppe E nicht aktualisiert. Routinggruppe E ist die letzte Routinggruppe, die noch nicht zur Liste der Routinggruppen hinzugefügt wurde, deren kürzeste Pfade ermittelt wurden. Es sind keine benachbarten Routinggruppen mehr vorhanden. Die Berechnung des kürzesten Pfads ist somit abgeschlossen. Die kürzesten Pfade von Routinggruppe A zu jeder anderen Routinggruppe in der Topologie wurden ermittelt. Lastenausgleich bei der Nachrichtenübertragung Wenn mehrere Pfade mit jeweils gleichen Kostenwerten vorhanden sind, wählt das Routingmodul – wie im vorhergehenden Schritt erläutert – einen Übertragungspfad nach dem Zufallsprinzip aus. Das Routingmodul führt jedoch keinen Lastenausgleich durch. Wie bereits an früherer Stelle erläutert, speichert das Routingmodul die Informationen zum Nachrichtentyp, die auf den kürzesten Pfad verweisen, auf dem eine Nachricht zum Ziel gelangen kann. Daher werden alle Nachrichten eines bestimmten Typs auf demselben Pfad übertragen, selbst wenn ein anderer Pfad mit dem gleichen Kostenwert vorhanden ist (z. B. „Routinggruppe A > Routinggruppe B > Routinggruppe E“ und „Routinggruppe A > Routinggruppe C > Routinggruppe E“). Lastenausgleich zwischen Routinggruppen Echter Lastenausgleich zwischen Routinggruppen kann nur mithilfe eines Routinggruppenconnectors mit mehreren Bridgeheadservern erzielt werden. In der folgenden Tabelle werden die Lastenausgleichskonfigurationen aufgeführt, die zwischen Routinggruppen verwendet werden können. 225 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 Quellund Zielbridgeheadserver für einen einzelnen Routinggruppenconnector zwischen zwei Routinggruppen anzugeben. Auf diese Weise wird der Lastenausgleich und die Redundanz verbessert. 226 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. 227 Lastenausgleich zwischen Connectors und externen Systemen Abhängig vom jeweiligen Szenario kann der Lastenausgleich über mehrere SMTPConnectors 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 SMTPConnectors 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. 228 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 Verbindungsstatusinformationen Wenn Nachrichten von einem Connector nicht übertragen werden können, informiert das erweiterte Warteschlangenmodul das Routingmodul über einen Verbindungsfehler. Dies kann unter Umständen dazu führen, dass das Routingmodul den Connector als nicht verfügbar kennzeichnet und alle in der Warteschlange befindlichen Nachrichten umgeleitet werden. Ein Connector wird vom Routingmodul als nicht verfügbar eingestuft, wenn eine der folgenden Bedingungen zutrifft: Das Routingmodul kann mit mindestens einem Quellbridgeheadserver des Connectors keine Verbindung herstellen, und es besteht keine TCP/IP-Verbindung mit Anschluss 691 zwischen dem Routinggruppenmaster und den Quellbridgeheadservern. Nicht verfügbare Quellbridgeheadserver werden in der Verbindungsstatustabelle durch den Eintrag VS_NOT_STARTED gekennzeichnet. 229 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 Nachrichten Zur Gewährleistung einer effizienten Nachrichtenübertragung informiert das Routingmodul das erweiterte Warteschlangenmodul und den Exchange-MTA sofort über alle Verbindungsstatusänderungen. Damit Nachrichten nicht über unterbrochene Übertragungspfade gesendet werden, müssen alle in der Warteschlange befindlichen Nachrichten umgeleitet werden. Dieser Vorgang wird als erneutes Routing bezeichnet. Beim erneuten Routing löscht das erweiterte Warteschlangenmodul alle zwischengespeicherten Informationen über den nächsten Hop, da diese nicht mehr gültig sind. Alle Nachrichten, die gegenwärtig zur Übertragung anstehen, werden erneut an das Routingmodul übergeben, das den nächsten Hop erneut berechnet. Dies kann eine ressourcenintensive Aufgabe sein. In der folgenden Abbildung wird als Beispiel ein erneuter Routingvorgang veranschaulicht, bei dem der Bridgeheadserver in Routinggruppe E nicht verfügbar ist. Es können derzeit keine Nachrichten an diese Routinggruppe übertragen werden. Bei der Neuberechnung der kürzesten Pfade zu den Empfängern in Routinggruppe E erkennt das Routingmodul, dass kein Pfad verfügbar ist. Connectors, die als nicht verfügbar gekennzeichnet sind, werden vom Routingvorgang ausgeschlossen. Aus diesem Grund ist die Routinggruppe E derzeit isoliert. 230 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äume In Exchange Server 2003 kann (analog zum Lastenausgleich) ein erneutes Routing von Nachrichten nur über Connectors ausgeführt werden, die denselben Adressraum besitzen. Beispielsweise können Sie zwei separate Connectors auf verschiedenen Bridgeheadservern einrichten, wobei beiden Connectors jeweils derselbe Adressraum, jedoch unterschiedliche 231 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. Connectorwiederherstellung Das Routingmodul ermittelt nach einer der folgenden Methoden, ob ein Connector wieder zur Verfügung steht: VS_NOT_STARTED Der Routinggruppenmaster stellt eine Verbindung mit TCP-Anschluss 691 auf dem Quellbridgeheadserver her. Der Quellbridgeheadserver wird mit dem Status CONN_AVAIL gekennzeichnet. Da mindestens ein Quellbridgeheadserver für den Connector verfügbar ist, wechselt der Connectorstatus zu STATE UP. CONN_NOT_AVAIL Bei nicht verfügbaren Connectors erfolgt durch die Quellbridgeheadserver alle 60 Sekunden ein erneuter Versuch zum Herstellen einer Verbindung, selbst wenn keine Nachrichten zur Übertragung anstehen. Nachdem eine Verbindung hergestellt wurde, meldet das erweiterte Warteschlangenmodul oder der Exchange-MTA eine erfolgreich hergestellte ausgehende Verbindung vom Quellbridgeheadserver an das Routingmodul. Das Routingmodul ändert daraufhin den Status des Quellbridgeheadservers in CONN_AVAIL und den Connectorstatus in STATE UP. 232 Erneutes Routing und Aktivierungszeitpläne Bei 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. Verbindungsstatusweitergabe Zur 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 ExchangeServer feststellen kann, ob andere oder redundante Verbindungen verfügbar sind. Nachrichtenschleifen treten nicht mehr auf. 233 Verbindungsstatusalgorithmus Die 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. 234 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 235 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 SMTPBefehl 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 MD5Hashwert 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 OrgInfoPaket 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. 236 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 SMTPVerbindung 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 OrginfoPaket dann an das lokale Routingmodul, das die Übertragung dem Routinggruppenmaster mitteilt. Beispiel für einen LSA In 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. 237 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. 238 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 239 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 MD5Hashwerte und tauschen Verbindungsstatusinformationen aus. 240 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 241 Ü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übermittlung Die 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 ExchangeOrganisation 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 242 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\CurrentControlSe t\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\CurrentControlSe t\Services\RESvc\Parameters\ Wert SuppressStateChanges Typ REG_DWORD Wert Über den Wert 0x1 werden Verbindungsstatusänderungen deaktiviert. 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 243 Routinggruppe oder der Ausfall der Verbindung zwischen einem Mitgliedsserver und dem Routinggruppenmaster. Ändern des Routinggruppenmasters Der 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 Routinggruppenmastern In 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 ATTACHVerbindungsstatusdaten 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. Ein solcher Fall kann auch eintreten, wenn ein alter Routinggruppenmaster die Trennung als Master ablehnt, oder ein Rogue-Routinggruppenmaster weiterhin die ATTACH- 244 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.5 Exchange 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 DijkstraAlgorithmus 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 2003Connectors 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. 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, 245 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.5Verzeichnis. Danach können Exchange 5.5-Server auch Exchange Server 2003-Connectors in ihre Routingentscheidungen einbeziehen. Routingprobleme im gemischten Modus Der Standortreplikationsdienst repliziert auch Informationen der Exchange Server 5.5Connectors 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 PCNetzwerke. 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 2003Benutzern 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. Topologieaktualisierungen Da 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 246 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\CurrentControlSe t\Services\RESvc\Parameters\ Wert ReloadOsInterval Typ REG_DWORD Wert Zeitraum zwischen dem erneuten Laden der Topologieinformationen aus Active Directory in Sekunden. Unterbrochene Verbindungsstatusübermittlung Server, 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 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. 247 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 2003Bridgeheadserver 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: 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. 248 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-Transportarchitektur Das 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 SMTPDienst 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 ExchangeOrganisation 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 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 SMTPTransportkomponenten und den Erweiterungen für Exchange-Ereignissenken ist es wichtig, die Funktionen des erweiterten Warteschlangenmoduls zu verstehen. 249 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 SMTPDienst 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 ExchangeInformationsspeichertreiber, damit der SMTP-Dienst ausgehende Nachrichten vom Exchange-Informationsspeicher erhalten und eingehende Nachrichten an ExchangeEmpfä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. Entwurf des SMTP-Diensts Das 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 250 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. 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- 251 Verwaltungsdienst gesteuert. Ausführlichere Informationen hierzu erhalten Sie unter Dienstabhängigkeiten in Exchange Server 2003. Asynchrone Ausführung von Threads Eine 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-InetinfoProzesses) 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 im Exchange-System-Manager auf der Registerkarte Allgemein unter Virtueller Standardserver für SMTPändern. Verarbeiten eingehender SMTP-Verbindungen Der 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 252 ü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 SMTPServer 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\CurrentControlSe t\Services\InetInfo\Parameters 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- 253 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-Threads In 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 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 IISDienste reservieren. Dies lässt sich über folgende Registrierungsparameter erreichen: Speicherort HKEY_LOCAL_MACHINE\System\CurrentControlSe t\Services\SMTPSVC\Queuing Wert MaxPercentPoolThreads 254 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 InetinfoProzess erhöhen. Speicherort HKEY_LOCAL_MACHINE\System\CurrentControlSe t\Services\SMTPSVC\Queuing Wert AdditionalPoolThreadsPerProc Geben Sie Folgendes ein REG_DWORD Wert Der Standardwert lautet 0x5A (90%). 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\Service s\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. 255 COM-basierte SMTP-Erweiterungen Das 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 EMail-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 ExchangeInformationsspeicher ü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 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-Transportsubsystem Wenn 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 SMTPTransportsubsystem anzeigen. Ereignissenken, wie SMTP-Protokollerweiterungen, Kategorisierungsmodul und Routingmodul, registrieren spezifische Ereignisse im SMTPDienst. 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 256 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 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. 257 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 Ereignisbenachrichtigungen Wenn ein Ereignis eintritt, überprüft ein als Ereignisverteiler fungierender Thread des SMTPDiensts 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 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. 258 Hinweis: Einige SMTP-Ereignisse, z. B. Speicherereignisse, haben keine Ereignisbedingungen. 2. Gegebenenfalls erstellt der Ereignisverteiler mithilfe der Klassen-ID (CLSID) der COMKlasse 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 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 259 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. Verwaltungsschnittstellen Das wichtigste Programm für die Verwaltung von SMTP-Protokolleinstellungen und virtuellen SMTP-Servern auf einem Server mit Exchange Server 2003 ist der Exchange-SystemManager, insbesondere das Exchange SMTP-Snap-In (\Programme\Exchsrvr\bin\SMTPMgr.dll). Dieses Snap-In befindet sich im ExchangeSystem-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 SMTPDiensts und wird durch eine eindeutige Kombination aus einer IP-Adresse und einer TCPPortnummer 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. Konfigurationseinstellungen und Ereignisbindungen Das SMTP-Transportsubsystem von Exchange Server 2003 greift für Konfigurationseinstellungen auf die folgenden drei Repositorys zurück: 260 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 SMTPTransportsubsystem 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 SMTPTransportsubsystem konfigurieren können, werden in Active Directory oder der IISMetabasis 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 SMTPDienst 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. Konfigurationsinformationen in Active Directory Der Exchange-System-Manager speichert Konfigurationsinformationen für virtuelle SMTPServer 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 261 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. msExchServerAutoStart Legt fest, wann der virtuelle Server gestartet werden soll. Wenn der Wert TRUE ist, wird der virtuelle Server beim Starten des Betriebssystems gestartet. 262 Active Directory-Attribut Beschreibung 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 KerberosAuthentifizierung ü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 SMTPServer fest. msExchSmtpOutgoingConnectionTimeout Legt die maximale Zeitspanne fest, nach der inaktive ausgehende Verbindungen beendet werden. msExchSmtpMaxOutgoingConnectionsPerDo Legt die maximale Anzahl ausgehender main 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 SMTPRemotehost aufnimmt. msExchSmtpOutgoingSecurePort Legt die Portnummer für ausgehende Verbindungen fest, über die der virtuelle SMTP-Server Kontakt zu einem SMTPRemotehost aufnimmt, wenn der Übertragungskanal mit TLS (Transport Layer Security) geschützt ist. msExchSmtpMaxHopCount Legt die maximal zulässige Anzahl der Hops für den Nachrichtentransport von diesem virtuellen SMTP-Server zum Zielort fest. 263 Active Directory-Attribut Beschreibung 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 SMTPServer ü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. msExchSmtpRemoteQueueExpirationTimeou Legt die Zeitspanne fest, nach der eine nicht t 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 SMTPServer fest. msExchSmtpSmartHostType Legt den Typ des Smarthost fest. 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. 264 Active Directory-Attribut Beschreibung msExchSmtpInboundCommandSupportOptio ns 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-ReverseLookups (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-MailNachrichten 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-MailNachrichten abgerufen werden. msExchSmtpQueueDirectory Legt das Verzeichnis fest, aus dem E-MailNachrichten in der Warteschlange platziert werden. msExchSmtpRemoteQueueRetries Legt den ersten, zweiten, dritten und alle folgenden Versuche für die Zustellung von Remotemail fest. 265 Active Directory-Attribut Beschreibung 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. msExchBridgeheadedRemoteConnectorsDN BL 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 Metabasis Bei 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 Verwaltungsdatenbankobjekte (ABO – Admin Base Objects) in die Metabasis im Arbeitsspeicher geschrieben (siehe folgende Abbildung). 266 Die Metabasis-Architektur von IIS 6.0 SMTP-Konfigurationsschlüssel Mitglieder 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 SMTPServer entsprechend der Eigenschaft Location für jeden IIsSmtp-Metabasis-Eintrag dargestellt. 267 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" 268 ... 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 ... > 269 <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 MetabasisParameter PickupDirectory dem Active Directory-Attribut msExchSmtpPickupDirectory. Direktes Bearbeiten der Metabasis Das 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änen Unter 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 DirectoryStandorte verweisen. Ein Beispiel für einen solchen Domänenamen ist 705260ab46c4-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 270 können. Sie sollten diese Domäneneinträge nicht ändern oder löschen, um Probleme bei der Verzeichnisreplikation zu vermeiden. Active Directory verwendet den SMTPDienst für die Replikation von Änderungen an Verzeichnissen zwischen Standorten. Registrierung von Ereignissenken Bei 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 271 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. 272 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 RuleQuelleigenschaften. 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. 273 Servererweiterungsobjekte Globale 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: { priority = 8192 274 } Aktivieren der Option „Direktes Bearbeiten der Metabasis ermöglichen“ im IISManager In 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 beginnen Bevor 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 IISMetabase 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 IISMetabase 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. Verfahren So aktivieren Sie die Option „Direktes Bearbeiten der Metabasis ermöglichen“ im IISManager 1. Klicken Sie im IIS-Manager mit der rechten Maustaste auf das Serverobjekt, und klicken 275 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 SMTPKommunikation 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. 276 Ersetzen der Versionsinformationen von Exchange im SMTP-Banner Erweitertes Warteschlangenmodul Das 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 ExchangeWarteschlangenmodul 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. 277 Aqueue.dll und Phatq.dll dienen ähnlichen Funktionen, doch nur Phatq.dll ist mit Exchange Server 2003 kompatibel. Durch das erweiterte Warteschlangenmodul ausgelöste Ereignisse Der 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 ExchangeInformationsspeichertreiber 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 278 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 CDONachrichtenobjektschnittstelle ü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 CDOSchnittstelle 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 279 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 ExchangeKategorisierungsmodul 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 280 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. 281 Nachrichtenwarteschlangen im erweiterten Warteschlangenmodul Das 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 282 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 SMTPTransportkomponenten 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\CurrentControlSe t\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 an Remoteempfänger gilt, dass das erweiterte Warteschlangenmodul in einem Ereignis 283 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-MessagingConnectors erläutert. Das SMTP-Transportsubsystem verwendet den ExchangeInformationsspeichertreiber, 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. 284 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 ExchangeInformationsspeicher. 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 Postfachoder Exchange-Informationsspeicher verschoben wurde, und die dort verbleiben, bis die Verzeichnisreplikation den Speicherort des Postfachs aktualisiert hat. 285 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 BaseArtikeln: Nachrichten mit fehlerhafter Übermittlung 284204, "Benachrichtigungen zum Übermittlungsstatus in Exchange Server und Small Business Server" 256321, "Enhanced Status Codes for Delivery - RFC 1893“ 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. 286 Begrenzen der Anzahl von Nachrichten in Warteschlangen Jede 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\Exch ange\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. 287 SMTP-Transportkomponenten In 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 ExchangeInformationsspeicher) 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\Exch ange\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 288 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 einund 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-Kategorisierungsmodul Das System für die Kategorisierung von Nachrichten in Exchange besteht aus zwei Komponenten, dem zentralen Kategorisierungsmodul und dem Exchange- 289 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 ExchangeKategorisierungsmodul 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 ExchangeKategorisierungsmodul 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. 290 b. Die Kommunikation mit dem Routingmodul ist zum Beispiel dann erforderlich, wenn eine Einmaladresse, die kein SMTP verwendet, in eine SMTP-Adresse gekapselt 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 ExchangeInformationsspeicher 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 ExchangeKategorisierungsmodul überprüft für jeden zu ermittelnden Empfänger, ob er sich im DSAccess-Cache befindet. Wenn dies der Fall ist, gibt das ExchangeKategorisierungsmodul 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 LDAPSuchfunktion des zentralen Kategorisierungsmoduls einen LDAP-kompatiblen Suchfilter 291 für den Benutzer. Dieser basiert in der Regel auf dem proxyAddresses-Attribut und der Eingabeadresse, zum Beispiel: (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 ExchangeKategorisierungsmodul 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 EMail-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 ExchangeKategorisierungsmodul 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 292 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. 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 SMTPAdresse [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 293 dem Code 5.1.4. In der folgenden Tabelle wird der NDR mit dem Code 5.1.4 ausführlich beschrieben. 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 BaseArtikel 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 NichtExchange-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 294 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 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 EMail-Ü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 ExchangeKategorisierungsmodul 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 295 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, legacyExchangeDNEmpfänger gemäß dem legacyExchangeDNAttribut der lokalen Verwaltungsgruppe und X.400-Adressen gemäß der X.400Standortadresse 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 BaseArtikel 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. ExpandItem Das Kategorisierungsmodul löst dieses Ereignis zur Verarbeitung der folgenden Aufgaben aus: 296 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 msExchExpansionServerNameAttribut 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 BaseArtikel 284204, „Delivery status notifications in Exchange Server and in Small Business Server“. 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- 297 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 SMTPDomäne für einen postfachaktivierten Benutzer festgelegt. Das targetAddressAttribut 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 ExchangeBenutzern alternative Benutzer aufweist, die zirkulär aufeinander verweisen. Problembehandlung Überprüfen Sie den alternativen Empfänger des Kontakts. Prüfen und entfernen Sie das targetAddressAttribut von postfachaktivierten Benutzern. Beschreibung Weitere Informationen über NDR-Codes finden Sie im Microsoft Knowledge BaseArtikel 284204, „Delivery status notifications in Exchange Server and in Small Business Server“. 298 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 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-MailJournalkonfiguration, 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 SMTPServer so konfiguriert haben, dass er alle Nachrichten mit nicht ausgewerteten 299 Empfängern an einen alternativen Host weiterleitet, stellt das ExchangeKategorisierungsmodul 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 ExchangeInformationsspeichertreiber 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 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. 300 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 ExchangeKategorisierungsmodul 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. 301 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. 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. 302 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 303 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 Nachrichten Wie 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 304 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 Inhaltskonvertierung Benutzer 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 305 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 MAPINachrichten durchgeführt. IMAIL Die 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 ExchangeInformationsspeichertreibers 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 MAPINachricht. Die eigentliche Nachricht im Exchange-Informationsspeicher wird nicht geändert. Änderungen am wiedergegebenen RFC 822-Inhalt werden nicht dynamisch der MAPINachricht zugeordnet, die zur Erzeugung des RFC 822-Inhalts verwendet wurde. 306 TNEF Exchange 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-MAPIClients 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 IMAP4Client 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 (SummaryTNEF) dar, einem speziellen TNEF-Typ ohne unformatierten Text, der als 8-BitBinä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 MIMEDaten unterstützen. 307 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 SMTPConnector 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 ExchangeOrganisation 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 ExchangeKategorisierungsmodul 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 308 Aufgliederungsserver die Zeit mitteilt, zu der die Nachricht ursprünglich vom ExchangeInformationsspeichertreiber 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 ExchangeInformationsspeichertreibers 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\Exch ange\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. Für die Nachrichtenübermittlung muss das Exchange-Kategorisierungsmodul die Nachricht an einen Informationsspeicher für Öffentliche Ordner übermitteln, dem bekannt ist, wo sich 309 die Replikate des Öffentlichen Ordners befinden. Diese Informationen sind im ExchangeInformationsspeicher im PTagReplicaList-Attribut enthalten. Nur der ExchangeInformationsspeicher 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 ExchangeKategorisierungsmodul das homeMDB-Attribut des Öffentlichen Ordners. Das homeMDBAttribut 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. 310 Optimieren der Leistung des Kategorisierungsmoduls Wie 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\CurrentControlSe t\Services\SMTPSVC\Parameters Wert LdapResultTimeout Typ REG_DWORD Daten für Wert 0x79 311 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 ExchangeKategorisierungsmodul bei Ablauf des Timeouts keine neuen Ergebnisse empfangen hat, können die in der LDAPVerbindung ausstehenden Suchvorgänge nicht ausgeführt werden, und es wird der Statuscode LDAP_SERVER_DOWN zurückgegeben. Das ExchangeKategorisierungsmodul 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\CurrentControlSe t\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\CurrentControlSe t\Services\SMTPSVC\Parameters Wert MaxConnectionRetries 312 Typ REG_DWORD Daten für Wert 0x14 Beschreibung Hiermit wird angegeben, wie oft LDAPVerbindungsversuche 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\CurrentControlSe t\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 LDAPVerbindungsfehler. Der Standardwert beträgt eine Stunde (60 Minuten). 313 Lastenausgleich für globale Kataloge Wenn 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 LDAPSuchvorgä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\CurrentControlSe t\Services\SMTPSVC\Parameters Wert MaxLdapConnections Typ REG_DWORD Daten für Wert 0x8 314 Beschreibung Dies ist die maximale Anzahl von LDAPVerbindungen, 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 LDAPVerbindungen ab und wählt automatisch die erste Verbindung ohne ausstehende Suchvorgänge aus. 315 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-Suchstapel Das 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 ExchangeKategorisierungsmoduls 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\CurrentControlSe t\Services\SMTPSVC\Parameters Wert MaxSearchBlockSize Typ REG_DWORD Daten für Wert 0x14 316 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\CurrentControlSe t\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 Nachrichten Nachrichten 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 Installable File System – installierbares Dateisystem von Exchange) im Exchange- 317 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 SMTPDienst 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 ExchangeInformationsspeichertreiber 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 Warteschlangenverzeichnis Mit 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. 318 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- 319 Empfängerliste ist jedoch nicht für die Verwaltung einer Liste von Empfängern zwecks Nachrichtenübermittlung vorgesehen. Erzwingen der erneuten Kategorisierung Die 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: 320 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\CurrentControlSe t\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 SMTPDiensts 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 SMTPDienst neu starten und den normalen Betrieb wieder aufnehmen. Informationsspeichertreiber des SMTPDiensts Das erweiterte Warteschlangenmodul gibt ein MailMsg-Objekt (ein im Speicher enthaltenes Nachrichtenobjekt, das eine schnelle Verarbeitung ermöglicht) von Ereignissenke zu 321 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 822Inhalt 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, gehen die Änderungen verloren, da der Exchange-Informationsspeicher nur mit einer temporären Kopie der Nachrichten arbeitet. 322 NTFS-Informationsspeichertreiber Der 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-MailNachrichten. 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 \PickupVerzeichnisses 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. 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 323 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] To: [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. \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 324 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 SMTPDienst 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 Mailrootverzeichnisses In Exchange Server 2003 können Sie die Ordner \Badmail und \Queue mit ExchangeSystem-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 ADSIBearbeitung (AdsiEdit.msc) msExchSmtpPickupDirectory für das virtuelle SMTPServerobjekt 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. Hinweis: Alle vom SMTP-Protokollmodul verarbeiteten Nachrichten werden auf Datenträger geschrieben und dann in ein MailMsg-Objekt eingelesen. 325 Exchange-Informationsspeichertreiber Der 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 ExchangeInformationsspeicherdienst 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 ExchangeInformationsspeicher adressiert. In diesem Fall wird die Nachricht durch den ExchangeInformationsspeichertreiber ü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.400Connectors bzw. an ein Nicht-Exchange-Messagingsystem mithilfe eines MAPI-basierten Messagingconnectors. Weitere Informationen zu Exchange-MTA finden Sie unter X.400Transportarchitektur. 326 Nicht-SMTP-Nachrichtenübertragung durch das erweiterte Warteschlangenmodul Architektur des ExchangeInformationsspeichertreibers Es 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 327 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 SMQModell (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 328 Bindungseinrichtung, die es dem Informationsspeichertreiber ermöglicht, eine beliebige Anzahl von Umlaufwarteschlangen zwischen IIS und dem ExchangeInformationsspeicher 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 ExchangeInformationsspeicher über EPOXY und mit der Inetinfo-Schnittstelle von Drviis.dll. Installierbares Dateisystem von Exchange Zur 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 ExchangeInformationsspeicherdiensts. Das installierbare Dateisystem von Exchange besteht aus den folgenden Hauptkomponenten (siehe folgende Abbildung): Exifs.sys Dies ist ein Kernelmodustreiber, mit dem der ExchangeInformationsspeichertreiber 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 329 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 ExchangeInformationsspeichertreiber 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 ExchangeInformationsspeicher 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-fad354ffa867d089-0000001e. Hinweis: Hinweis Die Komponenten im SMTP-Transportsubsystem verwenden zum Öffnen von Dateien im ExIFS ausschließlich erweiterte Attribute. 330 Integration of IIS and the Exchange store Übertragung ausgehender Nachrichten Der 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 331 Nachrichtenordner im 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. 332 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 822Nachrichteninhalt 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 333 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 „ExchangeInformationsspeichertreiber“ 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 822Format. 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 ExchangeInformationsspeicher 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 IMAILMechanismus 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. 334 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 ExchangeInformationsspeichertreiber (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 335 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 ExIFSDatei gehen verloren, wenn die Datei geschlossen wird. Übertragung eingehender Nachrichten Fü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 ExchangeInformationsspeichertreiber 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 ExchangeInformationsspeicher. 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. 336 6. ExSMTP.dll empfängt den Zeiger von der Warteschlange auf der Seite des ExchangeInformationsspeichers. 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 ExchangeInformationsspeicherkernel (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 ExchangeInformationsspeichertreiber 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 337 zum nächsten Hop auf der Route zu ihrem Ziel übertragen werden. Das Kategorisierungsmodul verwendet unter Umständen jedoch den ExchangeInformationsspeicher für Nachrichten, die nicht durch den ExchangeInformationsspeichertreiber übermittelt werden. Das Kategorisierungsmodul muss eventuell Benachrichtigungen über den Übermittlungsstatus erzeugen, die im Exchange-Informationsspeicher erstellt werden. Wiederholte Übertragungsversuche Beachten 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 ExchangeInformationsspeicher bleiben. Die Nachrichten werden nicht in den Ordner \Queue des virtuellen SMTP-Servers kopiert. Diese Nachrichten bleiben auch dann im ExchangeInformationsspeicher, 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-Protokollerweiterungen Das erweiterte Warteschlangenmodul ist nicht der einzige Verteiler von COM-Ereignissen im SMTP-Dienst. Das SMTP-Protokollmodul ist ebenfalls ein wichtiger Verteiler von COMEreignissen, 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 ESMTPBefehle hinzuzufügen oder sogar die Wirkung vorhandener Befehle zu ändern. Exchange Server 2003 verwendet diese Protokollereignisse zur Implementierung Exchangespezifischer 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 338 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 SMTPDienst von Exchange unterstützt. In Exchange Server 2003 unterstützte SMTP-Funktionen SMTP-Serverantwort Beschreibung 8BITMIME Gibt an, dass der lokale virtuelle SMTPServer 8-Bit-MIME-Nachrichten unterstützt. AUTH, AUTH GSSAPI NTLM LOGIN und AUTH=LOGIN Signalisiert, dass der lokale virtuelle SMTPServer 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. 339 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 SMTPServer 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 SMTPHost 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. 340 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 ESMTPBefehle 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 ESMTPSitzungen) 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. RCPT Identifiziert die Empfänger der Nachricht; wird im Formular RCPT TO verwendet. 341 SMTP-Serverantwort Beschreibung 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 SMTPDiensterweiterung 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 EMail-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]> 342 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, XEXPS=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: X-LINK2STATE 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. 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. 343 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 2003Basisversion des SMTP-Diensts ausgeführt. In diesem Fall müssen Sie Exchange Server 2003 und etwaige Service Packs neu installieren. Protokollereigniskategorien Das 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 SMTPAntwort auf einen zuvor gesendeten SMTPBefehl empfängt. 344 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 SMTPProtokollerweiterungen Das Exchange Server 2003-Installationsprogramm registriert Exchange-spezifische SMTPProtokollerweiterungen 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. 345 Protokollerweiterungen für den Befehl XEXCH50 Ereignissenke Protokollereignis Beschreibung Senke des Exchange SMTPProtokolls XEXCH50 für bevorstehende Datenübertragung OnBeforeData Benachrichtigt die XEXCH50Senke über die bevorstehende Übertragung des Protokollbefehls DATA. Die XEXCH50-Senke hat nun die Möglichkeit, den SMTPDienst zu veranlassen, anstelle des Starts einer XEXCH50-Kommunikation einen XEXCH50-Befehl zu senden. Senke des Exchange SMTPProtokolls XEXCH50 für eingehende EHLO-Befehle OnInboundCommand Benachrichtigt die XEXCH50Senke über den Empfang eines EHLO-Befehls. Senke des Exchange SMTPProtokolls XEXCH50 für eingehende XEXCH50Befehle OnInboundCommand Implementiert den XEXCH50Befehl zum Start einer XEXCH50-Kommunikation. Senke des Exchange SMTPProtokolls XEXCH50 für eingehende MAIL-Befehle OnInboundCommand Implementiert den MAILBefehl in einer XEXCH50Kommunikation. Senke des Exchange SMTPProtokolls 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 SMTPProtokolls XEXCH50 für Empfängerinformationen OnPerRecipient Ermöglicht es dem lokalen virtuellen SMTP-Server, die Empfängerinformationen in einer ausgehenden XEXCH50-Kommunikation zu senden. 346 Ereignissenke Protokollereignis Beschreibung Senke des Exchange SMTPProtokolls XEXCH50 für EHLO-Antworten OnServerResponse Ermöglicht es dem lokalen virtuellen SMTP-Server, nach dem Senden eines EHLOBefehls an den Remotehost eine Antwort zu empfangen. Die Antwort vom Remotehost weist möglicherweise darauf hin, dass XEXCH50Kommunikationen 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 SMTPProtokolls XEXCH50 für Antworten OnServerResponse Ermöglicht es dem lokalen virtuellen SMTP-Server, nach dem Senden eines ausgehenden XEXCH50Befehls 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. 347 Ereignissenke Protokollereignis Beschreibung Senke des Exchange SMTPProtokolls 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] m. 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. 348 Protokollerweiterungen für den Befehl X-LINK2STATE Ereignissenke Protokollereignis Beschreibung X-LSA-Senke des Handlers für eingehende EHLOBefehle OnInboundCommand Benachrichtigt die XLINK2STATE-Ereignissenken über den Empfang eines eingehenden EHLO-Befehls. X-LSA-Senke des Handlers für eingehende Befehle OnInboundCommand Benachrichtigt die XLINK2STATE-Ereignissenken über den Empfang eines eingehenden XLINK2STATE-Befehls. X-LSA-Senke OnMessageStart, OnSessionEnd Signalisiert den Start (Befehl MAIL) und das Ende (Befehl QUIT) einer ausgehenden XLINK2STATEKommunikation. Da der virtuelle SMTP-Remoteserver der endgültige Empfänger des übertragenen OrginfoPakets ist, müssen in einem ausgehenden RCPT-Befehl keine Empfänger angegeben werden. Diese Ereignissenke überträgt die Verbindungsstatusinformatio nen. X-LSA-Senke für den Antworthandler OnServerResponse Antwortet auf einen eingehenden XLINK2STATE-Befehl mit Informationen über die Übertragungsweise von Verbindungsstatusinformatio nen. 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 SMTPServer gesendet wurde. 349 Ereignissenke Protokollereignis Beschreibung X-LSA-Senke des Handlers für EHLO-Antworten OnServerResponse Beantwortet einen eingehenden EHLO-Befehl durch Auflisten des XLINK2STATE-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. 350 X-EXPS-Protokollsicherheitserweiterungen Ereignissenke Protokollereignis Beschreibung Exchange SMTPOnInboundCommand Protokollsicherheits-senke für EXPS-EOD Signalisiert das Ende der Datenübertragung (_EOD). Exchange SMTPProtokollsicherheitssenke für EXPS-AUTH OnInboundCommand Signalisiert einen eingehenden AUTH-Befehl. Exchange SMTPProtokollsicherheitssenke für EHLO OnInboundCommand, OnServerResponse Signalisiert einen eingehenden EHLO-Befehl und antwortet auf EHLO durch Auflisten des X-EXPSBefehls in der Serverantwort. Exchange SMTPProtokollsicherheitssenke für MAIL OnInboundCommand, OnServerResponse, OnMessageStart Signalisiert den Start der Datenübertragung. Diese Ereignissenke ist für alle relevanten MAILBefehlsszenarien 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 SMTPProtokollsicherheitssenke für EXPS OnInboundCommand, OnServerResponse, OnMessageStart Signalisiert den Start einer XEXPS-Sitzung. Diese Ereignissenke ist für alle relevanten X-EXPSBefehlsszenarien 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. 351 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 Informationen Vollständige Informationen zu SMTP finden Sie unter SMTP-Server. Protokollaufzeichnungen, Ereignisprotokollierung und Nachrichtenverfolgung Das 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, XLINK2STATE, HELO, XEXCH50, MAIL. 352 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. Protokollaufzeichnungen Wenn 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 SMTPProtokollaktivitä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 SMTPProtokollaktivitäten in einer Klartextdatei mit durch Komma getrennten Werten aufgezeichnet. Hierbei handelt es sich um ein feststehendes, nicht anpassbares ASCIIFormat, 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. 353 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 SMTPProtokollaktivitä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 SMTPKommunikation. Auf diese Weise können Sie durch das Weglassen unerwünschter Felder die Protokollgröße verringern. Die Felder sind durch Leerzeichen getrennt. Ereignisprotokollierung In 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-SystemManager 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 354 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). Nachrichtenverfolgung Mithilfe 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 ExchangeInformationsspeicher 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. 355 Aktivieren der Diagnoseprotokollierung für den SMTP-Dienst im Exchange-SystemManager In 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 beginnen Bevor 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. Verfahren Aktivieren der Diagnoseprotokollierung für den SMTP-Dienst im Exchange-SystemManager 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, NTFSInformationsspeichertreiber, 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. 356 Festlegen des Diagnoseprotokolliergrads für MSExchangeTransport-Kategorien auf Produktsupport In 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 beginnen Bevor 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. Verfahren Festlegen 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\Diagnos tics. 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. 357 3. Starten Sie den SMTP-Dienst 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. Weitere Informationen 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). Aktivieren der Nachrichtenverfolgung im Exchange-System-Manager In diesem Thema wird das Aktivieren der Nachrichtenverfolgung im Exchange-SystemManager 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 ExchangeOrganisation 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 beginnen Bevor 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. 358 Verfahren Nachrichtenverfolgung 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. Referenz Weitere 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-Transportarchitektur Microsoft 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.400Empfehlungen 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 359 ein, bleibt jedoch mit vorangegangenen Versionen kompatibel. Die erste offizielle X.400Empfehlung 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 ExchangeMTAs 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. 360 Exchange-MTA in der Exchange Server 2003-Architektur Der 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 RPCbasierte 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-Kommunikationspartner Der 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. 361 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 ExchangeMTA-Stacks werden auch in der Registrierungsdatenbank des Servers an folgendem Speicherort gespeichert: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeCalCo n. 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 362 dafür, dass durch unsachgemäßes Verwenden des Registrierungs-Editors 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 SMTPDienst. 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 ExchangeInformationsspeicher weiter. Die Kommunikation mit dem ExchangeInformationsspeicher 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. 363 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.400Connectors fungiert oder Verbindungen mit Messagingsystemen von Drittanbietern (z. B. Lotus Notes und Novell GroupWise) herstellt, sollten Sie erwägen, die Transaktionsprotokolle und Datenbankdateien des ExchangeInformationsspeichers 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 MTAAusführungsverzeichnis bezeichnet. Das Datenbankverzeichnis enthält Warteschlangendateien und Nachrichten, die gerade übertragen werden, in Form von 364 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 RemoteX.400-MTA kann es sich um den MTA eines Drittanbieters oder um einen ExchangeMTA 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 Directory Der 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. 365 Im Exchange-System-Manager unterscheidet sich der Speicherort des MTAKonfigurationsobjekts 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. 366 Wichtige Attribute des MTA-Verzeichnisobjekts Verzeichnisattribut Zweck objectClass Identifiziert das Verzeichnisobjekt als MTAObjekt. 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\Curren tControlSet\Services\MSExchangeMTA\Di agnostics. 367 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 RemoteX.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. 368 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. 369 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 MTADatenbankverzeichnis an. msExchResponsibleMTAServerBL Enthält den DN des Servers, der als Host des MTA fungiert. msExchEncryptedPassword Gibt das MTA-Kennwort an, das von RemoteMTAs 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 MTANamen und Kennwörter sicher sind. X.400-MTAs tauschen ihre Namen und Kennwörter beim Herstellen von Verbindungen in Klartext aus. Interne Exchange-MTA-Architektur Die 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 aufbewahrt werden, bis der MTA sie erfolgreich übertragen hat oder bis sie abgelaufen sind 370 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\CurrentControlSe t\Services\ MSExchangeMTA\Parameters Wert Transfer threads Typ REG_DWORD 371 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 SMTPTransportarchitektur. Verarbeiten von Ergebnissen Basierend auf den Ergebnissen von Routing-, Auffächerungs- und Übertragungsvorgängen erstellt der Verteiler auch Berichte. 372 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\CurrentControlSe t\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 SMTPDienst durchlaufen. Wie unter SMTP-Transportarchitektur erläutert, überträgt der SMTP- 373 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. XAPIGateways sind für die Nachrichtenübertragung von und zu den Nachrichtenwarteschlangen im Exchange-Informationsspeicher zuständig. Bei XAPIGateways 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.400Connectors. 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-Datenbank Der 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 DATNachrichtendatei 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 374 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 MTAWarteschlangen 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 MTANachrichtenwarteschlange. Nachrichtenwarteschlangen und DAT-Dateien des Exchange-MTA Die MTA-DAT-Dateien werden in zwei Kategorien unterteilt: 375 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 2003Installationsprogramm kopiert diese Dateien während der Installation in das Verzeichnis \Programme\Exchsrvr\Mtdata. Die mit Exchange Server 2003 gelieferten DATKerndateien 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 MTAArbeitswarteschlange 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 DATDateien 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 376 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 DATDateien 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 MTADatenbankverzeichnis Mit 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\CurrentControlSe t\Services\ MSExchangeMTA\Parameters Wert MTA database path Typ REG_SZ Wert C:\Program Files\Exchsrvr\Mtadata 377 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. FAT16Partitionen 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 ExchangeMTA befinden. Es empfiehlt sich, für das Datenbank- und das Ausführungsverzeichnis unterschiedliche Laufwerke zu verwenden. Gesicherte und ungesicherte Nachrichtenkopien Nachrichten 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 378 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\CurrentControlSe t\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. 379 MTA-Datenbank in einem Servercluster Es 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™ 2003Clusterdiensts 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 Gatewaywarteschlangen Exchange 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-SystemManager 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 ExchangeMTA ü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). 380 Speicherort HKEY_LOCAL_MACHINE\System\CurrentControlSe t\Services \MSExchangeIS\<Servername>\Private<Datenbank-GUID> 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 LANMTAs 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-Datenbanken Wenn 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 MTADatenbank 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 381 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. Leeren der MTA-Datenbank Auf 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 MTADatenbank (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 MicrosoftProduktsupport, um sicherzustellen, dass die Schritte ordnungsgemäß durchgeführt werden. Wenn Sie die Schritte unsachgemäß ausführen, gehen aktuell in der MTANachrichtenwarteschlange gespeicherte E-Mail-Nachrichten u. U. verloren. Wiedergeben von DAT-Dateien Zum 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 382 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 kontinuierlich große Mengen an E-Mail-Nachrichten überträgt und dessen MTAWarteschlangen 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 ExchangeServer 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-Verarbeitung Zum Ü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 ExchangeMTA bezeichnet, der u. U. die Aufmerksamkeit des Administrators erfordert. Überprüfen des Exchange-MTA mithilfe des Systemmonitors Mit dem Leistungsmonitor können einzelne Systemkomponenten untersucht werden. In Windows repräsentiert ein Objekt einen einzelnen Prozess, einen Teil des gemeinsam 383 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 (+)). 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 MTAPool. Freie Kopfzeilen Die Anzahl freier Pufferkopfzeilen im MTAPool. 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. 384 Leistungsindikator Beschreibung 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. 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. 385 Leistungsindikator Beschreibung 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. Ü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. 386 Leistungsindikatoren für einzelne vom MTA hergestellte Verbindungen In der folgenden Tabelle werden die für Leistungsobjekte vom Typ MSExchangeMTAVerbindungen 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. 387 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.400Connector 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 SMTPPostfach (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-Ereignisprotokollierung Der 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-MTAKategorien aufgeführt, die für die Diagnoseprotokollierung aktiviert werden können. Während des normalen Betriebs sollte der Protokolliergrad für alle Exchange-MTAKategorien auf Keine festgelegt werden. Auf dieser Stufe werden nur Fehlerereignisse und wichtige Nachrichten in das Ereignisprotokoll eingetragen. Wählen Sie beim Erhöhen des 388 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 RemoteMTA. 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. 389 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 MTAKonfigurationseinstellungen. 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 MicrosoftProduktsupports dar. 390 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 XAPIAblaufverfolgungen 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. 391 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.1Analysetool 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. 392 Ereignisprotokollierung im Textformat Legen Sie zum Speichern aller MTA-Ereignisprotokollinformationen in EV*.LOG-Dateien im Verzeichnis \Exchsrvr\Mtadata den folgenden Registrierungsparameter fest. Die EV*.LOGDateien 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\Servi ces\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-Protokollierung Je 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 MTAKategorien auf Verfolgungsebene festlegen. Die Protokollierung auf Ablaufverfolgungsstufe ist im Exchange-System-Manager nicht verfügbar, sondern muss mithilfe des RegistrierungsEditors 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. 393 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-Protokollierung Ein 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 BaseArtikel 163323, „XCON: Mtacheck.log“. 394 Objekt-IDs und Nachrichten-IDs Es 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-4AFD85AF-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 NachrichtenID 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. 395 Leeren der MTA-Datenbank In diesem Verfahren wird das Leeren der MTA-Datenbank erläutert, insbesondere das Verschieben von Dateien, um ein leeres Datenbankverzeichnis zu erstellen. Bevor Sie beginnen Bevor 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. Verfahren Leeren 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 MTADatenbankverzeichnis. Ohne die DAT-Kerndateien kann der Dienst Microsoft Exchange-MTA-Stacks nicht starten. 5. Entfernen Sie die Schreibschutzattribute von den kopierten Dateien. Im MTADatenbankverzeichnis dürfen sich keine schreibgeschützten Dateien befinden. 6. Starten Sie den Dienst Microsoft Exchange-MTA-Stacks neu. Wenn der MTA zuvor 396 Probleme mit beschädigten Nachrichten in den DAT-Dateien hatte, kann nun der Betrieb und die Nachrichtenübertragung fortgesetzt werden. Weitere Informationen Nach 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-Datenbankleerung Nach 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 beginnen Bevor 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. Verfahren So 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 397 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 Referenz Allgemeine 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 Wiedergabe In diesem Verfahren wird das Wiedergeben von DAT-Dateien nach einer MTADatenbankleerung ü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 beginnen Bevor 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 MTAWarteschlangen 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 MTAWarteschlangen 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. 398 Verfahren So 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. 399 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 Remotewiedergabe In diesem Verfahren wird das Wiedergeben von DAT-Dateien nach einer MTADatenbankleerung 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-MailNachrichten überträgt und dessen MTA-Warteschlangen nie leer werden. Der Remotewiedergabeserver kann sich in jeder beliebigen Routinggruppe in der ExchangeOrganisation befinden. Bevor Sie beginnen Bevor 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 400 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 DATDateien 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 MTADatenbankverzeichnis. 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. Verfahren Wiedergeben 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 401 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 DATDateien nach einer MTA-Datenbankleerung mittels inkrementeller Wiedergabe. Wiedergeben von DAT-Dateien nach einer MTA-Datenbankleerung mittels inkrementeller Wiedergabe In diesem Verfahren wird das Wiedergeben von DAT-Dateien nach einer MTADatenbankleerung 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 402 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 beginnen Bevor 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. Verfahren So 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 403 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 MTADatenbankverzeichnis. 6. Entfernen Sie die Schreibschutzattribute von den kopierten Dateien. 7. Verschieben Sie einen Teil der wiederzugebenden DAT-Dateien in das MTADatenbankverzeichnis. 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. 404 MTA-Transportstacks und X.400Connectors Der 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/IPModell (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 RPCLaufzeitbibliothek Darstellungs- und Sitzungsdienste enthält. Im Kontext des MTA-Stapels 405 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 TP0Protokollschnittstelle 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 MailGateway 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\MSExchangeMT A\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übertragungsdienst Die 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 406 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. 407 Unterstützte Nachrichtenformate in Exchange Server 2003 Format Inhaltstyp Objekt-ID MDBEF MDBEF (Microsoft Database Encoding Format) 2A864886F7140501 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 Microsoft-definierter Inhaltstyp für Replikationsnachrichten Öffentlicher Ordner Ist nicht X.400-konform, kann nur zwischen Exchange-MTAs in derselben Organisation verwendet werden In der X.400Spezifikation für das Konformitätsjahr 1984 definiert Definiert das Format für IPMs (InterPersonal Messages) In der X.400Spezifikation für das Konformitätsjahr 1988 definiert Erweitert das in X.400-84 definierte Format für IPMs Öffentlicher Ordner-MDBEF P2 P22 2A864886F7140502 56010A00 56010A01 408 Format Inhaltstyp Objekt-ID P772 Nachricht bei den Streitkräften 2B1A00A236000401 Ergänzt das P22Protokoll 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 4406Clients der Version 1.7 und 3 angezeigt. 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 P42 60.864.801.650.201.024A 409 Format Inhaltstyp Objekt-ID CSP Allgemeines Sicherheitsprotokoll (Common Security Protocol) 608648016502010203 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 DMSProgramms als „ACP120“ oder „MSP4“ bezeichnet 410 Format Inhaltstyp Objekt-ID TNEF TNEF (Transport Neutral Encoding Format) 2A864886F7140502 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 SMTPTransportarchitektur. In der folgenden Abbildung ist dargestellt, wie die Protokolle P1 und P2 der Architektur von Exchange Server 2003 zugeordnet sind. Umschlag- und Nachrichtenprotokolle 411 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 ExchangeInformationsspeicher 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. 412 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-TRANSFERAPDUs. 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-TURNGIVE-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-PLEASEElement 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-GIVEElement 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 ARELEASE-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 413 Zuordnung abbrechen, wenn der andere MTA ihn durch Verwendung von X.400Funktionen 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 RTSThreadpool. 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\CurrentControlSe t\Services\ MSExchangeMTA\Parameters Wert RTS threads Typ REG_DWORD Wert 0x1 414 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 Element Bei 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 MTAProzess 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 AASSOCIATE-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. 415 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 Sitzungsdienste Der 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-STARTAnzeige. Wenn die Nachricht lang ist, muss der MTA möglicherweise mehrere P-DATA- 416 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 PMINOR-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\CurrentControlSe t\Services\ MSExchangeMTA\Parameters Wert Kernel threads Typ REG_DWORD Wert 0x1 417 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 2003MTA 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-Transportstapel Damit der Exchange-MTA unter Verwendung der OSI-Transportschicht mit Remote-X.400MTAs kommunizieren kann, müssen Sie in der Netzwerk-, Transport-, Sitzungs- und Darstellungsschicht mehrere OSI-Adressen definieren. Dies wird mithilfe von MTATransportstapeln 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.400Dienst-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 OSIAdressinformationen 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. 418 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 MTATransportstapel installieren: TCP/IP MTA-Transportstapel TCP/IP empfiehlt sich für die X.400Nachrichtenü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. 419 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 IPAdresse. nAddress Gibt den Hostnamen oder die IP-Adresse des lokalen Exchange-MTA an. tSelector Gibt den TSAP in den OSIAdressinformationen des Stapels an. sSelector Gibt den SSAP in den OSIAdressinformationen des Stapels an. pSelector Gibt den PSAP in den OSIAdressinformationen 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. 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-WANTreiber installieren, damit X.400-Connectors über X.25 unterstützt werden. Die X.25Konfiguration ist sehr komplex und kann nur durch Verwendung der Konfigurationshilfsprogramme ausgeführt werden, die im Lieferumfang der EICON-X.25Karte 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 EICONKartenkonfiguration übereinstimmen, die vom X.25-Dienstanbieter festgelegt wurde. Mit dem folgenden LDIFDE-Befehl verwenden können Sie sämtliche X.25Transportstapel, die auf allen Servern einer Exchange-Organisation aus Active Directory konfiguriert wurden, in eine Datei mit dem Namen Stacklist.ldf exportieren: ldifde -f 420 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.25Adapter an. x25FacilitiesDataIncoming Gibt die Einrichtungsbenutzerdaten für den X.25-Adapter an. x25LeasedLinePort Gibt die Anschlussnummer des X.25Anschlusses an. tSelector Gibt den TSAP in den OSIAdressinformationen des Stapels an. sSelector Gibt den SSAP in den OSIAdressinformationen des Stapels an. pSelector Gibt den PSAP in den OSIAdressinformationen 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. 421 Beispiel für die MTA-Kommunikation In 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. Herstellen einer Verbindung zwischen zwei MTAs 422 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\CurrentControlSe t\Services\ MSExchangeMTA\Parameters Wert Transport threads 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 RemoteMTAs über mehrere X.400-Connectors kommuniziert. X.400-Connectors In 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 PCNetzwerke zu X.400. Konfigurieren eines X.400-Connectors Um 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. 423 Die folgende Abbildung zeigt das Eigenschaftendialogfeld für einen Beispiel-X.400Connector. 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.400MTA, 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. 424 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. Überschreiben Auf dieser Registerkarte können Sie die Werte der X.400Standardattribute 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. Verbindungsanforderungsinformationen Jede 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 RemoteMTA 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 425 erhalten. Klicken Sie auf der Registerkarte Allgemein auf Ändern, um den Namen und das Kennwort des Remote-MTA anzugeben. 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.400Netzwerke 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 Übertragungen Konfigurieren Sie in den Connectoreigenschaften auf der Registerkarte Stapel die OSIAdressinformationen, um anzugeben, wie eine Verbindung mit einem Remote-MTA hergestellt werden soll. Am wichtigsten ist es, die Netzwerkadresse des Remote-MTA (IPAdresse, 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 OSIAdressinformationen des Remote-MTA definiert sind. Weitere Informationen zu OSIAdresskonfigurationen finden Sie im Microsoft Knowledge Base-Artikel 152934, „XCON: X.400 Connector Stack Property Page Behavior“. X.400-Adressen Fü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. 426 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 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.400Adresse 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 Generationsbezeichn er Q=SR; CN Allgemeiner Name Common name CN=TED BREMER; X.121 X.121 X.121-Adresse X.121=49309872210 2 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; 427 Beschriftung Bedeutung Attributtyp Beispiel O Organisation Organisation O=EXCHANGE; OU1 Org. Unit. 1 Organisationseinheit 1 OU1=IT; 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=Attributwe rt) DDA:SMTP=Ted@tai lspintoys.com Hinweis: Mit Ausnahme des DDA-Felds wird bei O/R-Namen nicht zwischen Groß- und Kleinschreibung unterschieden. X.400-Adressräume Jeder 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). 428 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.400Connector, der auf dieses System verweist, kein SMTP-Adressraum zugeordnet werden. Im Remotesystem werden Nachrichten sonst nicht erfolgreich übertragen. Einige X.400Systeme 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. 429 Konformitätsjahr und Nachrichtenteile Auf 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 MTAKonformitä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. 430 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 431 im kompatiblen TNEF-Format um. Weitere Informationen über den NNTP-Dienst finden Sie unter SMTP-Transportarchitektur. Nachrichtenschleifenerkennung X.400 definiert ein Konzept von Organisationsgrenzen, die den Umgang mit Ablaufverfolgungsinformationen beeinflussen, die dem P1Nachrichtenü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.400Adressfeldern Land, ADMD und PRMD besteht. 432 Der MTA fügt einer Nachricht zusätzliche Ablaufverfolgungsinformationen hinzu, wenn die Nachricht die Organisation erreicht, z. B. wenn aus dem ExchangeInformationsspeicher 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 MTANamen 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 P1Nachrichtenü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 433 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-SystemManager 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. 434 Hinweis: Wenn Sie auf der Registerkarte Erweitert als Konformitätsjahr für den X.400Connector das Jahr 1984 auswählen, müssen Sie die globale Domänen-ID explizit konfigurieren. X.400-Connectorobjecte in Active Directory Wenn 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 ExchangeOrganisation 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.400Connector 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 RemoteX.400-MTA aufrechterhält. c Gibt den Land-Teil einer manuell definierten globalen Domänen-ID an. 435 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.400Connector 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. 436 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 ExchangeOrganisation 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 IPAdresse. 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: openRetryInterval rFC1006X400Link TCP/IP X.400Connectors x25X400Link X.25 X.400-Connectors Gibt die Wartezeit in Sekunden nach einem Fehler an, bevor das System versucht, eine Verbindung erneut zu öffnen. 437 Attribut Beschreibung pRMD Gibt den PRMD-Teil einer manuell definierten globalen Domänen-ID an. pSelector Gibt den PSAP in den OSIAdressinformationen 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 OSIAdressinformationen des Stapels an. supportedApplicationContext Gibt die Objekt-IDs von Anwendungskontexten an, die eine OSIAnwendung (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. 438 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 OSIAdressinformationen des Stapels an. 439 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-Connectors Die 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\CurrentControlSe t\Services\ MSExchangeMTA\Parameters Namen TCP/IP control blocks TP4 control blocks Eicon X.25 connections Typ REG_DWORD 440 Wert 0x14 (20) Beschreibung Legt die Höchstzahl der für X.400Verbindungen 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/IPX.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\CurrentControlSe t\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 RFC1006Threads (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/IPKontrollblö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 441 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.25Verbindungsparameters 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-Connectors Unter 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.400Connectors 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. 442 Lastenausgleich zwischen Routinggruppen Die 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 443 Routinggruppe überträgt, obwohl es sich beim lokalen Server ebenfalls um einen Bridgeheadserver handelt, der die Nachrichten übertragen könnte. Nachrichtenrouting über Exchange-MTAs In 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-Gateway Aus der Perspektive eines Exchange-MTA arbeitet der SMTP-Dienst ähnlich wie ein MAPIbasierter 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-4A4B4AFD-85AF-06EAB90057AA}). In Active Directory befindet sich im Container Verbindungen direkt unter dem Exchange-Organisationsobjekt ein entsprechendes 444 Connectorobjekt für das XAPI-Gateway. Dieser Container wird im Exchange-SystemManager 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 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. 445 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übertragung Die folgende Abbildung zeigt, wie der SMTP-Dienst und der Exchange-MTA miteinander interagieren. 446 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 447 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 Nachrichten Wenn 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 448 Ä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/RNamen 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 Routinggruppen In 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 ExchangeOrganisation 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 449 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. 450 Exchange-MTA in einer Organisation im gemischten Modus In 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-Kommunikation Für die Kommunikation über RPCs müssen Sie keinen OSI-Transportstack oder X.400Connector 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 ExchangeInformationsspeicher über XAPI, um Nachrichten an den SMTP-Dienst zu übertragen, sowie über MAPI-basierte Connectors, deren Nachrichtenwarteschlangen sich im ExchangeInformationsspeicher 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 LANMTAs, 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\CurrentControlSe t\Services\ MSExchangeMTA\Parameters Wert Min RPC Threads Typ REG_DWORD Wert 0x4 451 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\CurrentControlSe t\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 RPCThreads 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>\Pr ivate-<Datenbank-GUID> die Parameter Gateway In Threads und Gateway Out Threads, wie bereits in diesem Kapitel erläutert. 452 Auswirkungen auf die RPC-Leistung Sie müssen sicherstellen, dass für den Bridgeheadserver keine Probleme mit der RPCKommunikation 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 RPCKommunikationsprobleme 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 ExchangeInformationsspeicher verwendet der MTA RPCs. Die RPC-Kommunikation sollte jedoch während des normalen Serverbetriebs weder Probleme bereiten noch die Serverleistung beeinträchtigen. RPC-Bindback-Fehler Das 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 BindbackVorgang 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 453 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-Adressroutingtabelle Zum 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 Spamund Verbindungsfilterfunktionen in Exchange Server 2003 profitieren können. Für die Abwärtskompabilität erstellt ein Exchange Server 2003-MTA die GatewayAdressroutingtabelle 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 GWARTObjekt 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. 454 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-Servern In 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 P1Umschlag 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. 455 Architektur von Gateway-MessagingConnectors In 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 MAPIConnectors 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. 456 Stattdessen ermöglicht er Benutzern von Exchange Server 2003 und Lotus Notes oder Novell GroupWise Zugriffe in nahezu Echtzeit auf die Frei-/GebuchtKalenderinformationen 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 ExchangeOrganisation 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-Connectorarchitektur Fü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 ExchangeOrganisationen 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 2003Nachrichtenverarbeitung 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 MAPIConnector ausführen muss, um die Übertragung eingehender und ausgehender Nachrichten zu gewährleisten. 457 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 NotesClient-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 NotesClient-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: 458 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 MAPIConnector 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. Connectorkomponenten MAPI-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-SnapIns (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 459 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-MailNachrichten 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 460 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. 461 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-SystemManager 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) 462 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 ExchangeOrganisation>\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. 463 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-SnapIn 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 MAPIConnectors verfügen. 464 Wichtige allgemeine Attribute von msExchConnector-Objekten Attribute Beschreibung Common name Gibt den Namen des Connectorobjekts in Active Directory relativ zu seinem übergeordneten Container an. computerName Verweist auf den Bridgeheadserver, auf dem der MAPI-Connector ausgeführt wird. Dieses Attribut muss genau mit dem NetBIOSNamen (Network Basic Input/Output System) des Bridgeheadservers übereinstimmen, andernfalls werden die Nachrichtenwarteschlangen des Connectors nicht im Snap-In für die Warteschlangenanzeige im ExchangeSystem-Manager angezeigt. deliveryMechanism Gibt den Übermittlungsmechanismus an, der von Exchange Server 2003 für das Weiterleiten von Nachrichten an den MAPIConnector 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. 465 Attribute Beschreibung name Gibt den Namen des Connectorobjekts an. Der Exchange-System-Manager verwendet diesen Namen als Anzeigenamen für das Connectorobjekt. 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. 466 Verwaltungs-Snap-In MAPI-Connectors sollten im Exchange-System-Manager ein MMC-Erweiterungs-Snap-In hinzufügen und registrieren, damit ExchangeAdministratoren über eine benutzerfreundliche Oberfläche das msExchConnector-Objekt des Connectors in Active Directory (und mögliche Registrierungseinstellungen) 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 GroupWiseConnector-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 MTSOUT verfügen. Nachrichtenübertragung zu und von Exchange Server 2003 Prozesse, 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 MAPIConnector platziert eingehende Nachrichten, die er von anderen Messagingsystemen empfangen und konvertiert hat, im Ordner MTS-IN. Der Exchange-MTA wird unter X.400Transportarchitektur 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 467 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. Connector-Warteschlangen im Exchange-Informationsspeicher Übertragung ausgehender Nachrichten Exchange 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. 468 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 SMTPTransportsubsystem, um den MAPI-Zielconnector zu bestimmen. 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 Nachrichten Auf der Exchange-Seite der Nachrichtenübertragung sind für die Übertragung eingehender Nachrichten weniger Schritte als für ausgehende Nachrichten erforderlich. Wenn ein MAPIConnector 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. 469 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. MAPI-Profile für MAPI-Connectors Wie normale MAPI-Clients, z. B. Microsoft Office Outlook®, benötigen auch MAPIConnectors ein MAPI-Profil für den Zugriff auf ihre Connector-Postfächer. In diesem MAPIProfil 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 BaseArtikel 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-15-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. 470 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“. Nachrichtenkonvertierung Wenn 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 MTSIN 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 471 mit den richtigen Adressinformationen in den unterstützten Formaten an das Zielsystem übertragen wird. Nachrichtenübersetzung Bei der Nachrichtenübersetzung konvertiert ein GatewayConnector 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übersetzung MAPI-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 SMTPTransportsubsystem 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 MAPIConnector ü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 SMTPTransportsubsystem 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 MAPIConnector 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. 472 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 Absenderund 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 MTEEmpfä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. Anlageneigenschaften Diese MAPI-Eigenschaften geben den Typ des angefügten Objekts und Möglichkeiten für den Zugriff auf den Inhalt der Anlage an. 473 Proxyadressen und Einmaladressen Die 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 NOTESProxyadresse 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 Adresszuordnung Wenn 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. 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 474 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. Nachrichtenkonvertierung Exchange 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 MAPINachrichtenklasse 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 REPORTNachrichtenklassen, 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. 475 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 MAPIIMessage-Schnittstelle geöffnet werden. Hinweis: Neben der ENVELOPENachrichtenklasse müssen MAPIConnectors für die Nachrichtenkonvertierung auch die Standardnachrichtenklassen, z. B. IPM.NOTE, unterstützen, die im MTE eingeschlossen sind. REPORT.{Nachrichtenklasse}.NDR Der Unzustellbarkeitsbericht. Der MAPIConnector 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. 476 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. Verzeichnissynchronisierung MAPI-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 477 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 ExchangeInformationsspeicher, 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 ExchangeOrganisation Die Verzeichnissynchronisierung aus einem anderen Messagingsystem in eine ExchangeOrganisation umfasst folgende nacheinander ausgeführte Prozesse: 1. Extrahieren der Verzeichnisinformationen des Messagingsystems MAPIConnectors 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 478 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 ExchangeOrganisation. 479 Verzeichnissynchronisierung zwischen einem anderen Messagingsystem und Active Directory Verzeichnissynchronisierung aus einer Exchange-Organisation in ein anderes Messagingsystem Die 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. 480 Hinweis: Das Computerkonto des Exchange Server 2003-Bridgeheadservers mit dem MAPIConnector 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 NotesClient-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 481 Ö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 beginnen Bevor 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. Verfahren So ö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. 482 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 Notes Connector 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 MAPIConnector 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 NotesClient 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 NotesDatenbanken. 483 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). 484 Komponente Beschreibung 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 -nLMENOTES -pCONTROL-SERVICE l"C:\Programme\Exchsrvr\bin" -vLMENOTES 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 ExchangeAdressinformationen an das Lotus Domino-/Notes-Adressbuch. Dxamex.dll Diese Komponente überprüft Active Directory auf Empfängeraktualisierungen. Außerdem überträgt diese Komponente Änderungen in den Lotus Domino-/NotesAdressinformationen 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 485 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 EMail-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 DominoServers. 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 ArchivarBerechtigungen für das Speichern von EMail-Nachrichten und das Durchführen 486 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 Schemadefinitionsund 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 ExchangePostfachattribute. AMAP.TBL im Unterverzeichnis \Dxanotes Definiert die zu synchronisierenden Lotus NotesAttribute. 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 BaseArtikel 180517, „XFOR: Customizing Directory Synchronization Between Exchange and Notes“. 487 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\Current ControlSet\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. 488 Komponente Beschreibung 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-Mailaktivierte Verteilergruppen bei der Verzeichnissynchronisierung an Lotus Notes weitergegeben werden. msExchPartnerLanguage Gibt die Sprache (Codeseite) des Lotus Notesund 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 DominoServers (im Notes-Format) an, der vom Connector als Nicht-ExchangeBridgeheadserver verwendet wird. 489 Komponente Beschreibung Verwaltungs-Snap-In Die Bezeichnung für das Erweiterungs-SnapIn 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übertragung In der folgenden Abbildung wird der Vorgang zum Senden von Nachrichten von Exchange Server 2003 an Lotus Domino veranschaulicht. 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. 490 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. 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 MTSIN. 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. Nachrichtenkonvertierung Exchange Server 2003 und Lotus Domino unterstützen verschiedene Nachrichtentypen wie Besprechungsanfragen, Aufgaben, Aufgabenanforderungen und E-Mail-Nachrichten. 491 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 entsprechenden Nachrichtentyp in der Zieldomäne zugeordnet werden können, werden in EMail-Nachrichten konvertiert. Hinweis: Connector für Lotus Notes ist nicht für das Konvertieren von Nachrichten im HTMLFormat 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 Lotus Domino-Feature Lotus Domino nach Exchange Server 2003 Exchange Server 2003 nach Lotus Domino Ja Ja E-MailE-MailJa Übermittlungsbestätig Übermittlungsbestätig ung ung Ja E-MailLesebestätigung E-MailLesebestätigung Ja Ja Unzustellbarkeitsberi cht Unzustellbarkeitsberi cht Ja Ja Wichtigkeit Wichtigkeit Ja Ja Abstimmungsschaltfl ächen Kein Feature Nein Nein Eingebettetes OLEObjekt Eingebettetes OLEObjekt Ja Ja Eingebettete Dateianlage Eingebettete Dateianlage Ja Ja Nachrichtenablaufdat um Nachrichtenablaufdat um Nein Nein Server 2003-Feature E-Mail-Nachrichten E-Mail-Nachrichten 492 Exchange Lotus Domino-Feature Server 2003-Feature Lotus Domino nach Exchange Server 2003 Exchange Server 2003 nach Lotus Domino Kein Feature Antwort von Nein Nein Web-URL Web-URL Ja Ja Kein Feature URL-Hotspot Nein Nein Besprechungsanfrag en Termine Ja Ja Besprechungsannah me Besprechungsannah me Ja Ja Besprechungsablehn ung Besprechungsablehn ung Ja Ja Besprechungsannah me unter Vorbehalt Besprechungsannah me Wird als angenommen angezeigt Wird als angenommen angezeigt Besprechungsanfrag e gelesen Besprechungsanfrag e gelesen Ja Ja Übermittlung von Besprechungsanfrag en Übermittlung von Besprechungsanfrag en Ja Ja Besprechungsaktuali sierungen Besprechungsaktuali sierungen Werden als neue Besprechungsanfrag en mit dem Wort „Aktualisiert“ in der Zeile Betreff angezeigt Werden als neue Besprechungsanfrag en mit dem Wort „Aktualisiert“ in der Zeile Betreff angezeigt Besprechungsabsage Besprechungsabsage Ja n n Ja Aufgabenanforderung Aufgaben en Aufgabenanforderung en werden als E-MailNachrichten oder Aufgaben angezeigt. Aufgabenanforderung en werden als E-MailNachrichten angezeigt. Ganztägige Besprechungsanfrag en Nein Werden als Besprechungen mit Mitternacht als Anfangs- und Endzeit angezeigt Kein Feature 493 Exchange Lotus Domino-Feature Server 2003-Feature Lotus Domino nach Exchange Server 2003 Exchange Server 2003 nach Lotus Domino Kein Feature Telefonische Nachrichten Werden als E-MailNachrichten 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-Nachrichtentyps E-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. Zuordnen von E-Mail-Nachrichteneigenschaften In Nachrichten eingebettete Objekte, die vom Exchange Server 2003-Client (Outlook) an den Lotus Domino-Client (Lotus Notes) gesendet werden, werden in Anlagen konvertiert. 494 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-MailNachrichten 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-MailEditor 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 Initiale Wird ignoriert Ausgeblendet Wird ignoriert. Der Text ist sichtbar. 495 Lotus Notes Microsoft Outlook Unterstreichung, sofern nicht einfach Wird ignoriert Nicht als OLE-Objekte eingebettete Bitmaps Werden nicht migriert. Die Formatierung geht verloren. Aufzählungszeichen Werden ignoriert. Verzeichnissynchronisierung In 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 NotesMessagingsystem 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 496 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: Load A FULLNAME:Administrator MAILDOMAIN:Exchange COMPANY: DEPARTMENT: FIRSTNAME: LASTNAME:Administrator LOCATION: SHORTNAME:Administrator UNID:DBC07527-91C1F649-8427525F-902428E2 DN:CN=Administrator,CN=Users,DC=contoso,DC=com USNCreated:8194 Initials: Title: Phone: MobilePhn: Fax: Resource: CALDOM:Exchange MAILSRV: 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: Load U DN:admin TA:NOTES:admin@Notes ALIAS:admin NAME:admin 497 FULLNAME:admin FIRSTNAME: Initials: LASTNAME:admin NOTESADDR:admin@Notes UNID:4a12766d-8684ea55-3e551cde-3bac7ae9 COMPANY: DEPARTMENT: TITLE: OFFICE: PHONE: FAX: MOBILEPHN: USNCREATED: EndOfBuffer Architektur von Connector für Novell GroupWise Connector 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. 498 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). 499 Komponente Beschreibung 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" -vLMEGWISE 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. Die folgenden Komponenten sind an der Informationsverarbeitung beteiligt: Dxagwise.dll Diese Komponente überprüft das Novell GroupWiseVerzeichnis 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 GroupWiseAdressinformationen an Active Directory. Lsdxa.exe Hierbei handelt es sich um 500 Komponente Beschreibung 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. 501 Komponente Beschreibung 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 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-APIGateway übertragen werden. Die Dateien für Nachrichtenheader und -text sind schlüsselwortbasierte Textdateien, die vom Novell GroupWise-API-Gateway in Nachrichten im Novell GroupWiseFormat 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_DWORDRegistrierungsparameter Archive konfiguriert werden, der sich an folgendem Speicherort befindet: HKEY_LOCAL_MACHINE\SYSTEM\CurrentC ontrolSet\Services\LMEGWISE\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 502 Komponente Beschreibung Novell GroupWise-API-Gateway Für die Kommunikation mit der Novell GroupWise-Umgebung verwendet Connector für Novell GroupWise das Novell GroupWiseAPI-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 werden. 503 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\Curren tControlSet\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. 504 Komponente Beschreibung 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-Mailaktivierte 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 505 Komponente Beschreibung Verwaltungs-Snap-In Das Erweiterungs-Snap-In für Connector für Novell GroupWise verfügt über die Bezeichnung Exchange GroupWiseConnector. 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. Nachrichtenübertragung In der folgenden Abbildung wird der Vorgang zum Senden von Nachrichten von Exchange Server 2003 an Novell GroupWise veranschaulicht. 506 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. 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 ConnectorInformationsspeicher auf dem Server mit Exchange Server 2003 schreibt. 507 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-APIGateways. 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. Senden von Nachrichten von Novell GroupWise an Exchange Server 2003 508 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. 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. Nachrichtenkonvertierung Novell GroupWise unterstützt verschiedene spezielle Nachrichtentypen wie E-MailNachrichten, 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-MailNachrichten angezeigt werden, Besprechungsanfragen als Termine usw. Nachrichtentypen, die in Exchange Server 2003 nicht unterstützt werden, z. B. telefonische Novell GroupWiseNachrichten, 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 GroupWise-Feature Server 2003-Feature GroupWise nach Exchange Server 2003 Exchange Server 2003 nach GroupWise E-Mail-Nachrichten Nachrichten Ja Ja E-MailLesebestätigung E-MailLesebestätigung Ja Ja Unzustellbarkeitsberi cht Unzustellbarkeitsberi cht Ja Ja 509 Exchange GroupWise-Feature Server 2003-Feature GroupWise nach Exchange Server 2003 Exchange Server 2003 nach GroupWise Wichtigkeit Wichtigkeit Ja Ja (niedrige Priorität kann in GroupWise nicht dargestellt werden) Vertraulichkeit Vertraulichkeit Ja Ja Besprechungsanfrag en Termine Ja Ja Besprechungsannah me Besprechungsannah me Ja Ja Besprechungsablehn ung Besprechungsablehn ung Ja Ja Besprechungsannah me unter Vorbehalt Besprechungsannah me Wird als angenommen angezeigt Wird als angenommen angezeigt Besprechungsanfrag e gelesen Besprechungsanfrag e gelesen Ja Ja Übermittlung von Besprechungsanfrag en Übermittlung von Besprechungsanfrag en Ja Ja Besprechungsaktuali sierungen Besprechungsaktuali sierungen Werden als neue Besprechungsanfrag en mit dem Wort „Aktualisiert“ in der Zeile Betreff angezeigt Werden als neue Besprechungsanfrag en mit dem Wort „Aktualisiert“ in der Zeile Betreff angezeigt Besprechungserinner ungszeiten Besprechungserinner ungszeiten Nein Nein Besprechungsabsage Besprechungsabsage Nein n n Aufgabenanforderung Aufgaben en Ja Aufgabenanforderung Aufgaben werden als en werden als E-MailE-Mail-Nachrichten Nachrichten angezeigt angezeigt. 510 Exchange GroupWise-Feature Server 2003-Feature GroupWise nach Exchange Server 2003 Exchange Server 2003 nach GroupWise Ganztägige Besprechungsanfrag en Besprechungsanfrag en Ja Werden als Besprechungsanfrag en angezeigt. Wenn die Besprechung allerdings mehrere Tage umfasst, wird sie als einzelne Instanz am ersten Tag eingefügt, der Datumsbereich wird im Nachrichtenfeld angezeigt. Nein Telefonische Nachrichten Werden als E-MailNachrichten 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-Nachrichtentyps E-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- 511 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 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-MailNachrichteneigenschaften Der 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. 512 Novell GroupWise Microsoft Outlook 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. 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. 513 Verzeichnissynchronisierung Die 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 GroupWiseAdministratornachrichten (Nachrichtentyp = Admin) mit Novell GroupWise. Weitere Informationen zum Konfigurieren der Verzeichnissynchronisierung finden Sie unter Exchange Server 2003 Interoperability and Migration Guide. Hinweis: Connector für Novell GroupWise erstellt für die Empfänger im Novell GroupWiseMessagingsystem 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: Load A DOMAIN: POSTOFFICE: OBJECT: LASTNAME: FIRSTNAME:Administrator DESCRIP:Administrator ACCOUNTID: TITLE: DEPARTMENT: PHONE: FAX: GWADDR:Exchange.First Administrative Group.Administrator 514 EXCHANGEID: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; 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; 515 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. Architektur des Kalender-Connectors Der 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-/GebuchtInformationen anderer Benutzer abfragen können. Die Anforderungen für den KalenderConnector ä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-Informationen Frei/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. 516 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. 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-Daten Das 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-/GebuchtNachricht im Öffentlichen Ordner gesucht. Frei-/Gebucht-Nachrichten Jede 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. 517 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 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-Daten Es 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. 518 Veröffentlichen von Frei-/GebuchtInformationen in Outlook Outlook 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. 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 519 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. 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 520 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. Veröffentlichen von Frei-/GebuchtInformationen in Outlook Web Access und Outlook Mobile Access Da 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-/GebuchtAktualisierungsnachricht 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-Daten Beim 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- 521 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 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 DAVAbfrage 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 KalenderConnector in derselben administrativen Gruppe wie Connector für Lotus Notes bzw. Connector für Novell GroupWise installiert sein. Sie sollten den KalenderConnector auf demselben Server wie Connector für Lotus Notes oder Connector für Novell GroupWise installieren. Veröffentlichungs-Agent für Frei-/GebuchtInformationen (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 522 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 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-/GebuchtNachrichten 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-Daten Es 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-Startschalter Der Befehlszeilenschalter /cleanfreebusy für das Starten von Outlook wird zum Lösen von Terminplanungsproblemen für Besprechungen verwendet. Dieser Schalter hilft nicht bei 523 allgemeinen Terminproblemen, da er nicht den Frei-/Gebucht-Eintrag aus dem Informationsspeicher für Öffentliche Ordner löscht, sondern die lokale Frei-/GebuchtNachricht (LocalFreeBusy), die vom Outlook-Client generiert wurde. Die LocalFreeBusyNachricht 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-/GebuchtInformationen 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 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 Access Die 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-/GebuchtOrdner. 524 Komponenten des Kalender-Connectors Da 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 MAPIConnector, 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. 525 Komponenten des Kalender-Connectors Komponente Beschreibung 526 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-/GebuchtInformationen 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-ExchangeEmpfä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 MAPIConnector wird im Exchange-SystemManager in der Konfiguration des Kalender-Connectors auf der Registerkarte Allgemein angegeben. Calsync.dll stellt sicher, dass für jeden in Active Directory gefundenen NichtExchange-Empfänger ein Frei-/GebuchtDatensatz im Systemordner für Frei/Gebucht-Informationen enthalten ist. Die Frei-/Gebucht-Datensätze sind bei der Initialisierung leer. Hinweis: Sie sollten den KalenderConnector für die Ausführung nach jeder Verzeichnissynchronisierung konfigurieren, damit Calsync.dll 527 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 KalenderConnectors 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\Curren tControlSet\Services\MSExchangeCalCon. 528 Komponente Beschreibung 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 Ablauf dieser Zeit gibt der KalenderConnector die zurzeit im Frei-/GebuchtDatensatz vorhandenen Informationen an den Exchange-Benutzer zurück. Wenn die Antworten zu spät kommen, gibt Exchange Server 2003 die vorhandenen Daten an den OutlookClient zurück. Wenn die neuen Daten empfangen werden, aktualisiert der Kalender-Connector den Frei-/GebuchtDatensatz des Nicht-ExchangeBenutzers. 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 KalenderConnector die Frei-/Gebucht-Datensätze von Nicht-Exchange-Benutzern als aktuell ansieht. Innerhalb des Werts von 529 Komponente Beschreibung Verwaltungs-Snap-In Das Erweiterungs-Snap-In für den KalenderConnector 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 Notes Die folgende Abbildung zeigt, wie der Kalender-Connector in die Lotus NotesMessagingumgebung integriert wird. 530 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 NotesUmgebung herstellen. Das Integrieren verschiedener Lotus NotesMessagingsysteme in Exchange Server 2003 über den Kalender-Connector wird nicht unterstützt. 531 Frei-/Gebucht-Suchen aus Exchange 2003 Der 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-/GebuchtInformationen 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 KalenderConnector kommuniziert dann mit dem Remotekalenderserver, um die Frei-/GebuchtAbfrage 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. 532 8. Notescal.dll leitet die Informationen an Mapical.dll weiter, das den Frei-/GebuchtDatensatz 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-/GebuchtOrdner 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 Notes Der 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 KalenderConnector ü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. 533 8. Schedule Manager überträgt dann die Frei-/Gebucht-Informationen an den Lotus NotesBenutzer. 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 GroupWise Wie 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. 534 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. 535 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 GroupWiseBenutzer 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 GroupWiseBenutzers 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 GroupWiseMTA zurück. 536 8. Der GroupWise-MTA überträgt die Nachricht an das Verzeichnis WPCSOUT im APIGateway-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- 537 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 GroupWise Der 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 ExchangeBenutzer 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. 538 Prüfen des Vorhandenseins eines Replikats des Frei-/Gebucht-Systemordners für die administrative Gruppe auf einem Server mit Exchange Server In 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 beginnen Vergewissern 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. Verfahren So prüfen Sie, ob ein Server mit Exchange Server über ein Replikat des Frei-/GebuchtSystemordners 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. 539 Virtuelle Protokollserver in Exchange Server 2003 Microsoft 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-ServerActiveSync, 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 SMTPMessaging-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 SMTPTransportarchitektur 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. 540 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-Integration In 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 NNTPProtokollstapel 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 541 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-Informationsspeicherdienst Bis 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 DSAccessCache. 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. 542 Speicher- und Protokollarchitektur von Exchange Server 2003 Installierbares Dateisystem von Exchange ExIPC 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 ExchangeInformationsspeicherdienst. 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. 543 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 ExchangeInformationsspeicher darstellt. Eingehende Nachrichten Wenn 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 544 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 Nachrichten Wenn eine Nachricht vom System abgerufen wird, empfängt der ExchangeInformationsspeicherprozess 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. Dateisystemsemantik ExIFS 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 ExchangeInformationsspeicher 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-Bindungsfunktion Die 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- 545 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-Protokollstubs Jedes Protokoll verfügt in STORE.exe über eine ExIPC-Schnittstelle. Der ExIPCProtokollstub 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 HTTP Wenn der Exchange Server-Transportdienst in Microsoft Outlook konfiguriert ist, verwendet Outlook MAPI für die Kommunikation mit dem Exchange-Informationsspeicherdienst. MAPIAufrufe 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-HTTPProxy 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. 546 RPC über HTTP RPC ü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 BaseArtikel 331320 Microsoft Office Outlook 2003 Serverseitige Anforderungen Microsoft Windows Server 2003 auf dem Exchange-Server Exchange Server 2003 auf allen Front-Endund 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 HTTPSVerbindung ü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. 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 547 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 ncacn_http rpc_server endpoint HttpProxy RPCProxy gibt einen eindeutigen Bezeichner (Universal Unique Identifier, UUID) für das RPC-Objekt an. wählt die Protokollfolge für RPC über HTTP aus. 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. gibt den TCP/IP-Port an, an dem der RPC-Serverprozess auf Remoteprozeduraufrufe wartet. 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. 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-Verzeichnis Obwohl 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. 548 RPC über HTTP und der Microsoft ExchangeInformationsspeicherdienst Obwohl 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 ExchangeInformationsspeicherdienst mithilfe der MAPI-Schnittstelle zum ExchangeInformationsspeicher. Einzelheiten zu den Internetprotokollen Wie bereits beschrieben, unterstützt Exchange 2003 verschiedene standardisierte Internetclientprotokolle wie HTTP, POP3, IMAP4 und NNTP. Diese Protokolle werden in den folgenden Unterabschnitten genauer beschrieben. HTTP Der 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 IISAnforderungsprozessor 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 549 Formular und fragt die Bindung der Daten vom Informationsspeicher ab. Nach dem Erhalt der Daten vom Microsoft Exchange-Informationsspeicherdienst stellt die Exchange-HTTP-ISAPIErweiterung 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. 550 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 XML WebDAV (Web Distributed Authoring and Versioning) ist eine Erweiterung des HTTP 1.1Protokolls (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 ExchangeInformationsspeichers Exoledb.dll weitergeleitet. 551 Exoledb.dll stellt die Anforderung in einem Format dar, das der ExchangeInformationsspeicher verarbeiten kann, sendet die Anforderung an den ExchangeInformationsspeicher 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. POP3 Exchange 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 listBefehl 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. 552 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. 553 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 POP3Spezifikation und wird in RFC 1734 (Request for Comments) der IETF (Internet Engineering Task Force) beschrieben. Er ermöglicht das Verwenden anderer IMAP4Autorisierungsverfahren. Quit Wird zum Beenden der aktuellen POP3Sitzung 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 POP3Clients 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 ExchangeServer mit dem POP3-Protokoll. Architektur der freigegebenen Speicher von IIS und Exchange Server 554 1. Der Client meldet sich am Server an und übergibt den Befehl für das Überprüfen auf EMail-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 ExchangeInformationsspeichers 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. IMAP4 Exchange 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 OfflineVerwendung 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. 555 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. 556 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. 557 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. 558 NNTP NNTP (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 Directory Obwohl Exchange in IIS integriert ist, werden nach der Installation von Exchange 2003 die virtuellen Protokollserver vom Exchange-System-Manager und nicht vom InternetdiensteManager 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 559 ausgeführten DS2Mb-Funktion (Directory Service/Metabase Synchronization) in die IISMetabase 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 Metabase Die 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 DS2MB DS2MB 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. 560 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. Hochwassermarken Hochwassermarken 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-Serverarchitektur Ein 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 FrontEnd-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 561 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-EndServern Sie 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-EndServerkonfiguration verwenden. Sie sollten bei der Verwendung einer der beiden Editionen als Front-End-Server Folgendes berücksichtigen: 562 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-StacksDienst 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-EndServer 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 ExchangeInformationsspeicherdienst und die zugehörigen Dienste sind vom ersten Speichergruppenobjekt abhängig. Exchange ActiveSync und Exchange 2003 Exchange ActiveSync ermöglicht das Synchronisieren von Daten zwischen einem Mobilgerät und Exchange Server 2003. E-Mail-Nachrichten, Kontakte und Kalenderinformationen (PIMDaten, 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. 563 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-DateFunktion, 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-Protokollarchitektur Das 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-EndServer, die die Synchronisierung durch das Abrufen von Daten vom ExchangeInformationsspeicher erreicht. Die folgende Abbildung zeigt die funktionalen Komponenten des für das Sync-Protokoll verwendeten Kommunikationsmodells zwischen Client und Server. 564 Exchange ActiveSync-Kommunikation zwischen Client und Server Die folgenden Schritte werden bei allen Befehlen ausgeführt, die der
