Verwalten von Exchange 2000 Server- Teil 3

Verwalten von Exchange 2000 Server - Teil 3
(Engl. Originaltitel: Managing Exchange 2000 - Part 3)
Von Tony Redmond
Dieser Artikel ist der Ausgabe vom Februar 2001 des Windows 2000 Magazine entnommen.
Erweiterte Programmiermöglichkeiten
In "Managing Exchange 2000, Part 1" (englischsprachig) vom Februar 2001 und "Managing Exchange 2000,
Part 3" (englischsprachig) vom März 2001 habe ich untersucht, wie Microsoft Exchange 2000 Server Microsoft
Management Console (MMC) nutzt, wie Exchange 2000 Server mit Windows 2000 Active Directory interagiert
und wie Exchange 2000 Server Überwachungs- und Statusinformationen abruft und bereitstellt. Diese gesamte
Funktionalität hängt von verschiedenen Programmierschnittstellen ab. In der Vergangenheit hat Microsoft die
Details solcher Schnittstellen in der Regel nicht veröffentlicht und den Benutzern den Einsatz beliebiger
Verwaltungstools überlassen, die vom Unternehmen bereitgestellt wurden. Nun hat Microsoft
Exchange 2000 Server basierend auf verschiedenen dokumentierten Schnittstellen entwickelt. Wenn Ihnen die zu
Exchange 2000 Server gehörenden Standardverwaltungskonsolen nicht gefallen, können Sie Programme
erstellen, mit denen Sie Exchange 2000 Server Ihren Wünschen gemäß verwalten können. Obgleich diese
Funktionalität bei kleinen Systemen nicht wichtig sein mag, werden große Unternehmen diese zusätzliche
Flexibilität begrüßen, die eine bessere Integration von Exchange Server in ihre administrativen Frameworks
ermöglicht.
Im letzten Artikel dieser Reihe werden zwei wichtige Schnittstellen detailliert beschrieben: Windows
Management Instrumentation (WMI) und Collaboration Data Objects for Exchange Management (CDOEXM).
Darüber hinaus werfe ich einen schnellen Blick auf die Daten im Systemprotokoll und darauf, wie
Administratoren und Systemverwaltungsprodukte diese Daten verwenden können.
Vorsprung durch neue Schnittstellen
Das Administrationsprogramm von Exchange Server 5.5 unterstützt eine sehr begrenzte Anzahl von
Befehlszeilen-Schnittstellen, mit deren Hilfe Verzeichnisinformationen im- und exportiert werden können. Mit
Directory API (DAPI) und Messaging API (MAPI) können Sie Objekte im Exchange Server-Verzeichnis
programmgesteuert bearbeiten. Entwickler können das Microsoft Exchange Development Kit (EDK) verwenden,
um Connectors zu Faxsystemen und Messagingsystemen, wie z. B. Lotus Notes, zu erstellen. Diese
leistungsstarken Schnittstellen sind effektiv, haben jedoch eine steile Lernkurve.
Exchange 2000 Server stellt Schnittstellen zur Unterstützung von Programmiersprachen (z. B. Visual Basic) und
Skriptsprachen (z. B. VBScript) sowie des webbrowserbasierten Zugriffs auf Verwaltungsdaten bereit. Diese
Schnittstellen umfassen verschiedene auf COM basierende Verwaltungsobjekte, die mit dem WMI-Modell
zusammenarbeiten, und eine neue Gruppe von Schnittstellen, die als CDOEXM bezeichnet werden und die
Programmierung von Verwaltungsaufgaben vereinfachen.
Active Directory Service Interfaces (ADSI), OLE DB und WMI stellen die Grundlagen der
Exchange 2000 Server-Verwaltungsarchitektur bereit. ADSI ermöglicht den Zugriff auf Active Directory, damit
Exchange 2000 Server mit Benutzern, Kontakten, Gruppen und anderen Objekten in Active Directory
interagieren kann. OLE DB stellt einen Pfad in den Informationsspeicher bereit. WMI stellt verschiedene
Schnittstellen mit anderen Anwendungen und grundlegende Systemkomponenten, wie z. B. Hardwaregeräte,
bereit.
Die Verbindung der Bezeichnung CDOEXM mit CDO (Collaboration Data Objects) ist beabsichtigt. Vor
Exchange 2000 Server vereinfachte CDO das Programmieren von Objekten, wie Exchange Server-Postfächer
und -Nachrichten. In Exchange 2000 Server können Programmierer komplexe Verwaltungsobjekte mithilfe von
CDOEXM bearbeiten, um z. B. Speicherorte von Postfächern und ihre Eigenschaften zu verwalten. Der
Nutzeffekt ist, dass Programmierer benutzerdefinierte oder kommerzielle Produkte entwickeln können, um
Exchange 2000 Server zu verwalten oder Exchange 2000 Server in vorhandene Verwaltungstool zu integrieren.
Die Entscheidung über eine Verwendung dieser Features liegt bei Ihnen. Einerseits ist die Verwaltung in
Exchange 2000 Server wesentlich komplexer als in Exchange Server 5.5. Andererseits kann die neue
Verwaltungsarchitektur so einfach sein, wie Sie es wünschen. Wenn Sie nur einen Server verwalten, der als Host
einer kleinen Benutzergruppe dient, müssen Sie sich wahrscheinlich nie mit WMI oder CDOEXM beschäftigen.
Der wichtige Punkt ist, dass Sie nun über die Flexibilität verfügen, um Server Ihren Anforderungen entsprechend
– und nicht gemäß den Vorgaben von Microsoft – verwalten zu können.
Windows 2000-Zertifizierungsstandards
Bevor Anbieter ihre Produkte mit dem Windows 2000-Logo versehen können, müssen diese bestimmten
Microsoft-Standards entsprechen. Das Produkt muss Windows Installer für den Installationsvorgang, MMC für
die Verwaltung und WMI-Standardschnittstellen für die Anzeige der Verwaltungsdaten verwenden.
Als Microsoft-Produkt erfüllt Exchange 2000 Server selbstverständlich diese Anforderungen. In Teil 1 und 2
habe ich behandelt, wie Exchange 2000 Server die ersten beiden Anforderungen erfüllt. Das Produkt verwendet
einen neuen auf COM basierenden Windows Installer-Installationsvorgang und für Verwaltungsaufgaben
verschiedene MMC-Snap-Ins.
Um die dritte Anforderung zu erfüllen, veröffentlicht Exchange 2000 Server Verwaltungsdaten über WMI und
stellt eine programmierbare Schnittstelle (CDOEXM) bereit. Darüber hinaus stellt Exchange 2000 Server
aktualisierte Versionen zuvor freigegebener Exchange Server-Überwachungstools sowie eine überarbeitete
Version der Funktion Nachrichtenstatus bereit.
Zusammenstellen der Daten
Die Einführung neuer Verwaltungsdaten-Schnittstellen in Exchange 2000 Server bedeutet nicht, dass Sie
Produkte von Drittanbietern ersetzen sollen, mit denen Sie in Ihrer Exchange Server 5.5-Umgebung arbeiten.
Suchen Sie stattdessen nach aktuellen Versionen, die WMI und CDOEXM nutzen. Exchange Server war stets
ein Zielprodukt für Überwachungsanwendungen von Drittanbietern, wie z. B. AppManager von NetIQ oder
PATROL von BMC Software. In den meisten Fällen müssen diese Produkte Daten aus mehreren Quellen
sammeln (so z. B. den Leistungsindikatoren des Systemmonitors und dem Systemprotokoll), die unformatierten
Daten in einem Repository wie einer Microsoft SQL Server Datenbank speichern und anschließend
systemeigene Tools verwenden, um die Daten zu analysieren.
Die Ereignisprotokolle stellen eine ergiebige Informationsquelle für diese Verwaltungstools dar. (Abbildung 1
zeigt z. B. die Ereignis-ID 1221, die das Ergebnis eines Defragmentierungsdurchgangs durch einen
Postfachspeicher meldet. Diese Informationen sind bei der Überwachung des Wachstums von
Speicherdatenbanken von Postfächern sinnvoll. Im Abschnitt "Im Stau" finden Sie Vorschläge zum
reibungslosen Erstellen dieser Protokolle.) Neben Analysedaten enthalten die Ereignisprotokolle auch
Informationen zu schwerwiegenden Fehlern, wie dem berüchtigten Datenbankfehler 1018. (Dieses Warnsignal
für Exchange Server-Administratoren gibt an, dass ein gravierendes Problem zwischen einer Datenbank und dem
Datenträger-Subsystem besteht, das zur Datenbank gehört.)
Abbildung 1: Ereignisprotokolldaten
Die Systemüberwachung ist in Exchange 2000 Server besonders wichtig, da CDOEXM einen einfacheren
Zugriff auf Verwaltungsinformationen ermöglicht, die auch als Grundlage für eine weitere Kategorie von Tools
dienen können. Sie können die Leistung eines Servers basierend auf Daten analysieren, die vom Server bei
laufendem Betrieb extrahiert werden. Konfigurationsdaten in der Registrierung und Active Directory sind
ebenfalls wertvoll für die Analyse, insbesondere bei Unternehmensbereitstellungen. Der Inhalt der Registrierung
ist schwer zu erfassen. Nur ausgewählte Microsoft-Mitarbeiter kennen die wahre Bedeutung vieler
Einstellungen. Außerdem führen bestimmte Softwareprodukte Änderungen in die Registrierung ein, wenn Sie
diese installieren, um ein bestimmtes Problem auf dem Computer mit Exchange Server zu beheben. Auch wenn
zwei Server identisch zu sein scheinen, kann ein vollständiger Konfigurationsvergleich entscheidende
Unterschiede anzeigen. Produkte, wie z. B. Ecora Application Server (das auch Exchange Server 5.5 unterstützt),
demonstrieren den Wert einer vollständigen Dokumentation aller Einstellungen, die Sie auf einen Server
anwenden. (Eine Besprechung dieses Produkts von Rodney S. Landrum finden Sie unter "Ecora Application
Server" (englischsprachig.) CDOEXM vereinfacht die Dokumentation von Serverkonfigurationen, obgleich der
Inhalt verschiedener Bereiche der Registrierung für den Großteil der Benutzer ein großes, dunkles Geheimnis
bleibt.
Im Stau
Microsoft Exchange 2000 Server ist hinsichtlich der Datenmenge, die in die Ereignisprotokolle, insbesondere
das Anwendungsprotokoll, geschrieben werden, ein ausführlich dokumentierendes Produkt. Das gilt besonders,
wenn die Diagnoseprotokollierung oberhalb des Mindestgrads aktiviert wird. Die Standardgröße des
Anwendungsprotokolls ist 512 KB, was für ein vernünftig dimensioniertes Exchange Server-System zu klein ist.
Bei dieser Größe kann das Protokoll sich zu schnell anfüllen und überlaufen, wodurch wichtige Ereignisse
unerkannt bleiben. Um dies zu vermeiden, sollten Sie das Anwendungsprotokoll auf 4 MB (auf Server mit bis zu
500 Postfächern) oder mehr (auf Servern, die als Host von mehr als 500 Postfächern dienen) vergrößern.
Bearbeiten Sie das Dialogfeld Eigenschaften des Protokolls, um die Größe eines Ereignisprotokolls zu ändern.
Zusammensetzen der Einzelteile: WMI
WMI ist die Microsoft-Implementierung der WBEM-Architektur (Web-Based Enterprise Management) gemäß
der Definition der Distributed Management Task Force (DMTF), einem Gremium der IT-Industrie, das sich der
Definition plattformübergreifender Verwaltungsstandards widmet. (Informationen zu WBEM und DMTF finden
Sie unter http://www.dmtf.org [englischsprachig]) Der Zweck von WBEM ist das Bereitstellen einer Methode
für einen einheitlichen Zugriff auf Verwaltungsinformationen verschiedener Servertypen (z. B. Systemstatus,
Arbeitsspeicherverwendung, eine Liste installierter und ausgeführter Anwendungen, verbundene Clients).
Das Ziel von WMI ist das Bereitstellen einer umfassenden Verwaltungsinfrastruktur, damit nicht für jede
Anwendung eigene Verwaltungsagents erforderlich sind. Die Verwaltungsinfrastruktur ermöglicht eine systemund anwendungsweite Überwachung und Steuerung mithilfe von Verwaltungsdienstprogrammen, die
Dateneingaben von WMI-Anbietern empfangen. Um WMI Verwaltungsinformationen bereitzustellen,
implementieren Anwendungen in ihrem Code WMI-Aufrufe und werden bei der Installation auf einem Server
als WMI-Anbieter registriert. Die Anbieter richten ein konsistentes Schema und eine konsistente API ein, auf die
Anwendungen über Standardabfragen, -methoden und -ereignisse zugreifen können. Die auf COM basierende
WMI-API erteilt Anwendungen (z. B. MMC oder Webbrowsern) Zugriff auf ein Repository mit
Verwaltungsinformationen, das CIM-Repository (Common Information Model), das dann die Anwendungen auf
die entsprechenden Daten verweist. Das CIM ist ein Schema, das verwaltbare Objekte definiert, einschließlich
Anwendungsobjekten (wie z. B. Exchange Server-Objekte) und Hardwaregeräten (wie z. B. Festplatten). WMI
erweitert das WBEM-Modell durch Folgendes:



Eine Gruppe von Erweiterungen, die Win32-Schema genannt werden und die WMI zu CIM hinzufügt.
Das Win32-Schema beschreibt Objekte, die relevant für Windows-Anwendungen sind (z. B. Dienste).
Einen Windows 2000-Dienst (den WMI-Dienst winmgmt.exe), der das CIM-Repository verwaltet. Der
Dienst antwortet auf Abfragen von Anwendungen, die Daten aus dem Repository oder einem WMIAnbieter lesen möchten.
Eine auf COM basierende API (WMI-API) und Komponenten, die Anwendungen das Schreiben von
Code für den Zugriff auf das CIM-Repository und die WMI-Dienste ermöglichen.
Exchange 2000 Server verwendet WMI, um zahlreiche Aspekte eines Servers zu untersuchen, einschließlich der
Größe des freien Speicherplatzes auf der Festplatte. Abbildung 2 veranschaulicht die WMI-Architektur, in deren
Zentrum sich die WMI-API befindet. Diese arbeitet mit dem CIM-Objekt-Manager und dem CIM-Repository
zusammen, um auf die bei einem Server registrierten WMI-Anbieter zuzugreifen.
Abbildung 2: WMI-Architektur
Der Vorteil einer konsistenten Schnittstelle zum Abrufen und Anzeigen von Verwaltungsdaten aus mehreren
Quellen ist offensichtlich. Die Anforderung an Anwendungen ist das Schreiben von WMI-Anbietern, damit
sowohl Anwendungen von Microsoft und Drittanbietern als auch installationsspezifische Routinen die WMISchnittstelle sinnvoll nutzen können (damit Sie z. B. ein Skript schreiben können, das zum Verwalten von
Postfächern über eine speziell entworfene Webschnittstelle mehrere WMI-Anbieter verwenden kann).
WMI-Anbieter
Windows 2000 enthält eine Gruppe von WMI-Anbietern, die dem Betriebssystem und Anwendungen wie
Exchange 2000 Server den Zugriff auf benötigte Verwaltungsdatenquellen ermöglichen. Zu den Anbietern
gehören die folgenden:







Der Anbieter Directory Services ermöglicht den Zugriff auf Active Directory.
Der Anbieter Event Log ermöglicht den Zugriff auf Daten in den Ereignisprotokollen.
Der Anbieter Performance Monitor ermöglicht den Zugriff auf die Leistungsdaten verwalteter
Objekte.
Der Anbieter Registry ermöglicht den Zugriff auf Registrierungseinträge.
Der Anbieter Security ermöglicht den Zugriff auf Sicherheitseinstellungen für Dateien, Ordner und
Dateifreigaben.
Der Anbieter Win32 ermöglicht den Zugriff auf grundlegende Windows 2000-Dienste.
Der Anbieter Windows Driver Model (WDM) ermöglicht den Zugriff auf HardwareGerätinformationen.
Diese Anbieter arbeiten mit Daten, die von bestimmten Anwendungen erzeugt werden. Darüber hinaus enthält
Windows 2000 den Anbieter View, der Informationen zahlreicher Anbieter zu einem Zugriffspunkt für
Verwaltungsdaten zusammenfasst.
Windows 2000 beschränkt den Zugriff auf WMI-Daten auf Windows 2000-Administratoren. Wenn Sie
versuchen, mit einem nicht berechtigten Konto auf Informationen zuzugreifen, wird im Anwendungsprotokoll
folgendes Ereignis aufgezeichnet:
Ereignis-ID 1000 Quelle Perflib
Beschreibung:
Der Zugriff von TRedmond auf die Systemleistungsdaten von
F:\WINNT\System32\WBEMWinMgmt.exe aus wurde verweigert.
Abbildung 2 zeigt häufig verwendete Windows 2000-WMI-Anbieter, wie z. B. die Anbieter Event Log und
Registry sowie die drei Exchange 2000 Server-WMI-Anbieter:



ExchangeQueue - Exchange 2000 Server verwendet diesen Anbieter, um Informationen zum Protokoll
aufzulisten, das eine Warteschlange bedient (z. B. SMTP), um die Nachrichten in einer Warteschlange
aufzuzählen, um Datum und Uhrzeit der nächsten geplanten Verbindung anzuzeigen und um die Größe
der Warteschlange in Byte anzugeben.
ExchangeRoutingTable - Exchange 2000 Server verwendet diesen Anbieter, um (in einer
Routingtabelle) Informationen zum Status des lokalen Servers mit Exchange 2000 Server und zu allen
Connectors zu veröffentlichen, die auf dem lokalen Server ausgeführt werden. Exchange 2000 Server
verwendet diesen Anbieter auch, um (aus der Routingtabelle) Informationen zum Status anderer Server
mit Exchange 2000 Server und anderer Connectors in der Organisation abzurufen.
ExchangeCluster - Exchange 2000 Server verwendet diesen Anbieter nur in einer Clusterumgebung, um
die Mitglieder, Ressourcen und den aktuellen Status einer Clustergruppe anzuzeigen.
Innerhalb der drei Anbieter spezifiziert Exchange 2000 Server fünf neue WMI-Klassen:





ExchangeLink - Diese Klasse stellt Informationen zum Status der Verbindung und zu den
entsprechenden Eigenschaften bereit. Die Eigenschaften umfassen den Wiederholungszähler, die Größe
der Warteschlange, die für jede Verbindung bereitsteht, und den aktuellen Status der Verbindung (Nicht
verfügbar oder Aktiv). Das SMTP-Routingmodul verwendet diese Informationen, um das
Verbindungsstatusrouting zu ermitteln.
ExchangeQueue - Diese Klasse stellt detaillierte Informationen zum Inhalt von
Nachrichtenwarteschlangen bereit, wie z. B. das von der Warteschlange verwendete Protokoll (z. B.
X.400 oder SMTP) und der Name der Verbindung, zu der die Warteschlange gehört. Ein Programm
kann die einzelnen Nachrichten in der Warteschlange aufzählen. Der Exchange-System-Manager kann
z. B. diese Funktion verwenden, um die Nachrichten in einer Warteschlange zu zählen.
ExchangeConnectorState - Diese Klasse stellt Informationen zum Connectorstatus bereit. Die
wichtigste Information ist, ob der Connector ausgeführt wird. Wie Tabelle 1 jedoch zeigt, kann die
Klasse auch andere Informationen abrufen, wie den DN (Distinguished Name ) von Active Directory
des Connectors. Programme, wie der Exchange System-Manager, können mithilfe des DNs
Connectoreigenschaften aus dem Exchange Server-Konfigurationscontainer abrufen.
ExchangeServerState - Diese Klasse stellt Informationen zum Serverstatus bereit (z. B. Arbeitsspeicher,
Festplatte, Systemstatus, auf dem Computer ausgeführte Dienste). Der Überwachungsabschnitt des
Exchange System-Managers nutzt diese Klasse intensiv, um Server zu überwachen.
ExchangeClusterResource - Diese Klasse stellt (nur in Clusterumgebungen) Informationen zum Status
einer gegebenen Clusterressource und den Namen des virtuellen Exchange-Servers bereit, der diese
Ressource verwendet.
Der WMI-Namespace unter \root\cimv2\applications\exchange definiert fünf Klassen.
Verwaltungsanwendungen greifen auf Exchange 2000 Server-Daten über die Klassen anstatt über die Anbieter
zu. Jede Klasse bezieht sich auf einen bestimmten Teil von Exchange 2000 Server und verwendet dieselben
Standard-APIs, die auch von Exchange 2000 Server verwendet werden. Der Anbieter ExchangeRoutingTable
wird beispielsweise die API Routing überlagernd ausgeführt und erstellt die Klassen ExchangeServerState und
ExchangeConnectorState. (Exchange 2000 Server verwendet die API Routing, um zu steuern, wie das neue
auf SMTP basierende Routingmodul Nachrichten verarbeitet.) Der Anbieter ExchangeQueue wird die API
Queue überlagernd ausgeführt, die sich sowohl über den Message Transfer Agent (MTA) als auch das SMTPRoutingmodul erstreckt und die Klassen ExchangeLink und ExchangeQueue erstellt. (Nachdem das SMTPRoutingmodul die effektivste Route einer Nachricht bestimmt hat, wird die Nachricht in einer Warteschlange
abgelegt. Die API Queue stellt Exchange 2000 Server eine Schnittstelle zu solchen Warteschlangen bereit.) Der
Anbieter ExchangeCluster wird die API Cluster überlagernd ausgeführt und erstellt die Klasse
ExchangeClusterResource. (Wie Sie sich vorstellen können, ist diese Schnittstelle nur verfügbar, wenn
Exchange 2000 Server in einem Windows 2000-Cluster ausgeführt wird.)
Als Beispiel der in den Exchange 2000 Server-WMI-Klassen verfügbaren Daten werden in Tabelle 1 die
Eigenschaften der Klasse ExchangeConnectorState aufgelistet. Beachten Sie, wie nachvollziehbar diese
Eigenschaften sind. Sie können mühelos jede Eigenschaft den von dieser bereitgestellten Informationen
zuordnen. Der Exchange System-Manager zeigt diese Informationen an, wenn Sie den Status aller bekannten
Connectors anzeigen.
WSH und ähnliche Tools verwenden die Klassen, um Vorgänge zu automatisieren. Der folgende Codeausschnitt
gibt z. B. eine Liste aller Computer mit Exchange Server in der Auflistung, die dem lokalen System bekannt
sind, sowie die Exchange Server-Version auf jedem Computer zurück. Der Code stellt eine Verbindung zum
lokalen Computer mit Exchange Server her, gibt den Exchange Server-Teil des WMI-Namespaces an und
verwendet anschließend die Klasse ExchangeServerState, um die Informationen zu melden.
Const ComputerName = "LocalHost"
Const WMINameSpace = "root/cimv2/
applications/exchange"
Const WMIInstance = "Exchange
ServerState"
Set ExchangeList = GetObject
("winmgts:{impersonationLevel=
impersonate}!//" & - Computer
Name & "/" & - WMINameSpace)
.InstancesOf (WMIInstance)
For each ExchangeServer in
ExchangeList Wscript.Echo
"Name: " & ExchangeServer.Name
Wscript.Echo "Version: " &
ExchangeServer.Version
Next
Das Exchange 2000-Software Development Kit (SDK) (englischsprachig) stellt detaillierte Informationen zu den
Anbietern und Klassen bereit und beschreibt, wie Ihre Programme diese nutzen können.
Die Siegerkombination: CDOEXM
Gemeinsam mit ADSI, OLE DB, ADO und CDO vervollständigt CDOEXM die Zusammenstellung von
Schnittstellen, die benötigt werden, wenn ein vollständig programmierbarer Zugriff auf Exchange 2000 ServerDatenstrukturen gewünscht wird. Diese Schnittstellen führen die folgenden Funktionen aus:





ADSI - Mithilfe dieser Schnittstelle werden Active Directory-Objekte, einschließlich Konten und
Gruppen, bearbeitet.
CDO - Mithilfe dieser Schnittstelle werden komplexe Exchange Server-Objekte, wie z. B. Nachrichten
und Anlagen, bearbeitet.
OLE DB - Diese Schnittstelle wird zur Navigation innerhalb des Exchange ServerInformationsspeichers mithilfe von Sprachen wie C++ verwendet.
ADO - Diese Schnittstelle wird zur Navigation innerhalb des Exchange Server-Informationsspeichers
mithilfe von Automatisierungssprachen verwendet.
CDOEXM- Mithilfe dieser Schnittstelle werden komplexe Exchange Server-Objekte, wie z. B.
Postfächer und öffentliche Informationsspeicher, bearbeitet.
Keine Schnittstelle deckt allein alle Aspekte von Exchange Server ab. Alle Schnittstellen arbeiten zusammen.
Sie müssen jedoch wahrscheinlich Aufrufe mehrerer Schnittstellen kombinieren, um die meisten Aufgaben
ausführen zu können. Um z. B. einen neuen Benutzer zu erstellen und diesem ein Postfach zuzuweisen, müssen
Sie zuerst mithilfe von ADSI ein neues Objekt erstellen, um anschließend mit CDOEXM das Postfach
einzurichten. Wahrscheinlich wird Ihnen auffallen, dass das CDO-Objekt CDO.Person sowie die ADSI-Objekte
ADSUser, ADSContact und ADSGroup die wichtigsten Bausteine des Codes sind, der sich auf
Exchange Server-Benutzervorgänge bezieht.
CDOEXM ermöglicht auch den programmierbaren Zugriff auf Postfächer, Öffentliche Ordner (einschließlich
Hierarchien auf oberster Ebene), Server und Speichergruppen. Das Konzept dieser Funktionalität ist, dass Sie
Verwaltungstools erstellen können, wenn Sie die von Microsoft bereitgestellten Dienstprogramme nicht nutzen
möchten. Unabhängige Softwareanbieter werden voraussichtlich diese Schnittstelle verwenden, um
Erweiterungen zu programmieren. CDOEXM legt z. B. das Objekt ExchangeServer offen, mit dessen Hilfe Sie
die Eigenschaften eines ausgewählten Servers abfragen können. In Tabelle 1 werden diese Eigenschaften
aufgelistet.
Tabelle 1 Eigenschaften des Objekts "ExchangeServer"
Eigenschaft
Funktion
Name*
Name des Exchange Server-Systems
ExchangeVersion*
Exchange Server-Version (einschließlich Service Pack), die auf
dem Server ausgeführt wird
StorageGroups*
Liste mit URLs, die auf aktive Speichergruppen auf dem Server
zeigen
MessageTrackingEnabled
Flag, das angibt, ob das Nachrichtentracking auf dem Server
aktiviert ist
SubjectLoggingEnabled
Flag, das angibt, ob die Protokollierung und Anzeige des
Nachrichtenbetreffs für das Nachrichtentracking aktiviert sind
DaysBeforeLogFileRemoval
Anzahl von Tagen, die der Server
Nachrichtentrackingprotokolle aufbewahrt
ServerType
Flag, das angibt, ob der Computer als Front-End- oder BackEnd-Computer mit Exchange Server konfiguriert ist (0 = FrontEnd, 1 = Back-End)
DirectoryServer*
Flag, das angibt, ob das System ein von Exchange Server
verwendeter Domänencontroller ist
GetInterface*
Angegebene Schnittstelle zum Objekt
DataSource*
IDataSource-Schnittstelle zum Objekt
Fields*
Objektsammlung Fields des Objekts
*Schreibgeschützt, obgleich einige diese Eigenschaften schreibgeschützt sind (z. B. Fields), da sie eine
Möglichkeit des Zugriffs auf weitere Informationen bieten.
Wenig überraschend ist, dass ExchangeServer das überschaubarste der CDOEXM-Objekte ist. Dieses Objekt
dient als Ausgangspunkt für viele weitere Vorgänge. Mit dem Objekt ExchangeServer.StorageGroups können
Sie z. B. eine Liste der Speichergruppen abrufen. Sie können anschließend diese Liste als Eingabe in das Objekt
StorageGroups verwenden, das eine Gruppe von Eigenschaften anzeigt, mit denen Sie Einstellungen wie die
Umlaufprotokollierung oder den Pfad ändern können, den eine Speichergruppe für den Zugriff auf die
Transaktionsprotokolle verwendet. Beachten Sie, dass Code, der diese Schnittstellen verwendet, auf einem
Produktionsserver verheerende Schäden anrichten kann, weshalb Sie den Code vor der Verwendung sorgfältig
testen müssen. Sie können wohl nicht mit viel Nachsicht der Benutzer rechnen, wenn der von Ihnen
geschriebene Code deren Arbeit blockiert.
Die Möglichkeiten der Kombination von CDOEXM, WMI, ADO, CDO und anderen Komponenten zum
Erstellen von Verwaltungs- und Berichterstellungs-Dienstprogrammen für Exchange 2000 Server müssten
detaillierter behandelt werden, als dies in diesem Artikel möglich ist. (Im Abschnitt „Weitere Informationen“
finden Sie mehrere Quellen mit Informationen zur Verwendung der neuen Programmierschnittstellen.) Ich
empfehle, so viel Dokumentation und Beispielcode wie möglich zusammenzustellen, eine ausgiebige Lektüre
der Dokumentation und das Experimentieren (Schreiben und Debuggen) mit Code auf Testservern, bevor Sie
den Wechsel auf einen Produktionsserver wagen, es sei denn, Sie leben gern gefährlich.
Weitere Informationen
Weitere Informationen zu den in diesem Artikel beschriebenen Programmierschnittstellen und -methoden finden
Sie in der MSDN-Onlinebibliothek (Microsoft Developer Network) unter
http://msdn.microsoft.com/library/default.asp. Dort finden Sie Verknüpfungen zu den Themen „Technical
Articles“, „Database and Messaging Services“, „Web Storage System“ und „Microsoft Exchange Server“
(jeweils englischsprachig). Insbesondere empfehle ich den Artikel „Building Management Components for
Microsoft Exchange 2000 Server“ von Barry Steinglass unter
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmes2k/html/e2k_cmpts.asp
(englischsprachig). Neben der MSDN-Bibliothek empfehle ich die Whitepaper von Alain Lissoir unter
http://activeanswers.compaq.com/aa_downloads/6/100/225/1/42365.pdf (englischsprachig). Hier finden Sie
Codebeispiele für die Erstellung von Skripts zur Ausführung gängiger Systemverwaltungsvorgänge.
Nehmen Sie sich Zeit
Da Microsoft nun entsprechend dokumentierte Schnittstellen bereitstellt, ist das Überwachen und Verwalten von
Exchange Server so einfach wie nie zuvor. Erwarten Sie nicht, sofort mit dem Schreiben von Programmen
beginnen zu können, die Exchange 2000 Server-WMI-Anbieter und CDOEXM verwenden. Nehmen Sie sich
zuvor Zeit, um die Standardverwaltungstools eingehend zu untersuchen. Für die meisten Administratoren sind
die umfassenden Fortschritte bei der Unterstützung standardmäßiger Verwaltungsdaten-Schnittstellen
interessant, jedoch eher unbedeutend. Denn schließlich schreiben nur wenige Mitglieder der Exchange ServerCommunity Code. Die anderen warten mit Interesse auf deren Leistungen, um davon zu profitieren. Sie müssen
lediglich wissen, dass diese Schnittstellen vorhanden sind und welche Aufgaben sie erfüllen, sei es nur, um
sicherzustellen, dass Ihre Dienstprogramme von Drittanbietern diese Schnittstellen unterstützen.
Informationen zum Autor
Tony Redmond ist mitwirkender Redakteur von Windows 2000 Magazine, leitender technischer Redakteur des
Exchange Administrator-Newsletters, Vice President und Chief Technology Officer bei Compaq Global Services
und Autor von Microsoft Exchange Server 2000: Planning, Design, and Implementation (Digital Press). Senden
Sie eine E-Mail-Nachricht an [email protected], um Antworten auf Ihre Fragen zu Exchange zu
erhalten.
Der vorliegende Artikel erscheint mit freundlicher Genehmigung von Windows 2000 Magazine. Klicken Sie
hier, um Windows 2000 Magazin bzw. hier, um die englischsprachige Ausgabe zu abonnieren.
Das Team der Microsoft Corporation hofft, dass die Informationen in diesem Dokument für Sie von Nutzen sind.
Die Verwendung der in diesem Dokument enthaltenen Informationen erfolgt jedoch auf eigene Gefahr. Alle
Informationen werden wie besehen bereitgestellt, ohne jede Gewährleistung, sei sie ausdrücklich oder
konkludent, für die Richtigkeit, die Vollständigkeit, die Eignung für einen bestimmten Zweck, den
Eigentumsvorbehalt oder die Nichtverletzung von Rechten Dritter, und keine der in diesem Dokument genannten
Fremdherstellerprodukte oder Informationen von Dritten wurden/werden von der Microsoft Corporation verfasst,
empfohlen oder unterstützt, und Microsoft Corporation übernimmt keine Garantie dafür. Die
Microsoft Corporation kann nicht für Schäden haftbar gemacht werden, die aus der Verwendung dieser
Informationen entstehen, ungeachtet dessen, ob es sich um direkte oder indirekte, spezielle, zufällig entstandene
oder Folgeschäden handelt, selbst dann nicht, wenn Microsoft Corporation auf die mögliche Entstehung solcher
Schäden hingewiesen wurde. Alle Preise für im vorliegenden Dokument genannte Produkte können jederzeit
ohne vorherige Ankündigung geändert werden.