(0) exportieren Drucken
Alle erweitern
Erweitern Minimieren

Grundlegendes zu EXOLEDB-Standardordnern

 

Letztes Änderungsdatum des Themas: 2006-01-11

Von Jason Nelson

In diesem Artikel werden die verschiedenen EXOLEDB-Ordner auf dem Microsoft® Exchange-Server beschrieben, und es wird deren jeweiliger Zweck erläutert.

Bei der Initialisierung der Nachrichtendatenbank (Message Database, MDB) werden in der Phase der Client-Annahme von EXOLEDB unter NON_IPM_SUBTREE mehrere Systemordner erstellt. Einige der Ordner stammen noch aus früheren Versionen, die meisten haben jedoch nützliche Funktionen. Wenn die Ordner gelöscht werden, kann die Funktion des Servers dadurch beeinträchtigt werden. Keiner dieser Ordner sollte repliziert werden. Es werden unter anderem folgende Ordner erstellt:

  • \NON_IPM_SUBTREE\schema-root\
  • \NON_IPM_SUBTREE\schema-root\Default
  • \NON_IPM_SUBTREE\schema-root\Microsoft\
  • \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1
  • \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb
  • \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\controls
  • \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\img
  • \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\views
  • \NON_IPM_SUBTREE\StoreEvents\
  • \NON_IPM_SUBTREE\StoreEvents\GlobalEvents
  • \NON_IPM_SUBTREE\StoreEvents\Internal
  • \NON_IPM_SUBTREE\OWAScratchPad

In allen Fällen gehören die mit der GUID benannten Unterordner zu dem MDB-Objekt mit derselben GUID.

Die zuerst erstellten Ordner sind die Schemaordner.

In der folgenden Liste wird der Schemastamm vorgestellt:

  • \NON_IPM_SUBTREE\schema-root\
    Dieser Ordner wurde in Exchange 2000 Server eingeführt.
  • \NON_IPM_SUBTREE\schema-root\Default
    Dieser Ordner wurde in Exchange 2000 Server Service Pack 1 (SP1) eingeführt.
  • \NON_IPM_SUBTREE\schema-root\Microsoft\
    Dieser Ordner wurde in Exchange 2000 Server SP1 eingeführt.
  • \NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1
    Dieser Ordner wurde in Exchange 2000 Server SP1 eingeführt.

Nachstehend wird ein typischer Schemapfad für eine öffentliche Nachrichtendatenbank wiedergegeben:

  • File://.BackOfficeStorage/<Domäne>/<TLHName>/NON_IPM_SUBTREE/schema-root/microsoft/exchangeV1

Der private Schemapfad der MDB befindet sich unter dem Postfach der Systemaufsicht.

EXOLEDB unterstützt mehrere Schemas bzw. Definitionen für Eigenschaftentypen. Diese Ordner unterstützen die Webspeicher-Entwicklungsplattform von Exchange. Die grundlegende Idee dahinter war, dass Ordnerelemente auf verschiedene Versionen des Schemas verweisen und nebeneinander existieren können. In Exchange 2000 Server befanden sich die Schemadateien im Schemastammordner, und Änderungen am Schema wirkten sich auf alle Elemente aus. Weil dies zu Problemen im Arbeitsbereich der Anwendungsentwicklung führte, in dem jedes Element bearbeitet werden musste, um Eigenschaften nach Bedarf hinzuzufügen oder zu entfernen, entwickelte Microsoft eine Versionsverwaltungsmethode. Unter dem Schemastamm werden Unterordner mit Anwendungs- und Versionselementen erstellt, um praktisch nahtlose Aktualisierungen zu ermöglichen. Die Schemaordner werden von EXOLEDB auf Änderungen überwacht. So ist es möglich, die Einträge weiterzugeben, ein Speicherabbild des Schemacaches zu erstellen und den Cache bei einer Bearbeitung neu zu füllen. Der Ordner "\schemaroot\default" befindet sich an der Stelle, an der normale Ordnerelemente ihr Schema abrufen, und der Schemastammordner ist so gekennzeichnet, dass er auf den Ordner "ExchangeV1" verweist. EXOLEDB füllt die Schemaeinträge über die XML-Dateien, die von der Ereignissenke EXSCHEMA.EXE verarbeitet werden. Die Bindung an die Ereignissenke des Schemas kann nicht gelöscht oder entfernt werden, da diese im Gegensatz zu den meisten Ereignissen über keinen Eintrag im Ordner "EventBindings" verfügt.

In der folgenden Liste werden EXCHWEB, Ansichten, IMG und Steuerelemente vorgestellt:

\NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb

\NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\controls

\NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\img

\NON_IPM_SUBTREE\schema-root\Microsoft\exchangeV1\exchweb\views

Diese in Exchange 2000 Server SP1 eingeführten Elemente wurden in Exchange 2000 Server Service Pack 3 (SP3) nicht gefüllt. Dies gilt auch für Exchange Server 2003.

Damit der lokale Speicher Elemente öffnen kann, die auf Steuerelementfunktionen von Microsoft Outlook® Web Access (OWA) verweisen, müssen sich die Dateien in einem Ordner befinden, der synchronisiert werden kann. Diese Ordner enthielten zuvor Kopien der Webdaten für Outlook Web Access, um gespeicherte LIS-Elemente öffnen zu können. Außerhalb von LIS wurden sie jedoch nie verwendet.

Als Nächstes startet EXOLEDB das System zur Ereignisbindung, mit dem der Ordner "StoreEvents" erstellt wird.

Alle in der nachstehenden Liste beschriebenen Speicherereignisordner sind seit Exchange 2000 Server vorhanden.

  • \NON_IPM_SUBTREE\StoreEvents\
  • \NON_IPM_SUBTREE\StoreEvents\GlobalEvents
  • \NON_IPM_SUBTREE\StoreEvents\Internal

Dies ist der Ordner für die Ereignisbindung, in dem EXOLEDB Informationen zu Ereignissen speichert, die in einer bestimmten Nachrichtendatenbank erstellt werden. Beim Starten muss EXOLEDB die Ereignisse hier auflisten, wodurch lange Startzeiten des Speichers mit vielen Ereignissenken entstehen können. Die Leistung von Exchange Server 2003 wurde in diesem Bereich erheblich verbessert, doch die Zeit zum Bereitstellen einer Nachrichtendatenbank wird weiterhin durch die Anzahl der Zeilen beeinflusst. Für jede Bindung erfolgt eine Überprüfung auf die Klasse, auf eine gültige Ereignismethode (z. B. "onsave" oder "ontimer"), auf eine gültige "clsid" und auf die Senkenparameter. Ereignisse mit einer übereinstimmenden ANY-Klasse können ausschließlich im Unterordner "GlobalEvents" registriert werden.

Nachdem die Schemaordner erstellt wurden und das System zur Ereignisbindung gestartet wurde, startet EXOLEDB das Scratch-Pad für Outlook Web Access (OWA-Scratch-Pad).

Der Ordner "OWAScratchPad" wurde in Exchange 2000 Server SP1 eingeführt und wird folgendermaßen angezeigt:

  • \NON_IPM_SUBTREE\OWAScratchPad

Beiträge müssen irgendwo festgehalten werden, um Anlagen erhalten zu können. Für Anmeldungen am öffentlichen Speicher ist dies das OWA-Scratch-Pad. Weil sich Distributed Authoring and Versioning (DAV) nicht mit MDB-Vorgängen überschneidet, wird in jedem Postfach ein Ort benötigt, an dem jederzeit Beiträge geschrieben werden können, sodass sich Anlagen hinzufügen lassen. Die Beiträge werden in "OWAScratchPad" bereitgestellt, bis alle Anlagen hinzugefügt oder gespeichert wurden. Mit der Größenbeschränkung für das OWA-Scratch-Pad wird die Größe der Anlagen gesteuert, die über Outlook Web Access hinzugefügt werden können. Bei Versuchen zum Bereitstellen größerer Nachrichten sollte die folgende Fehlermeldung angezeigt werden:

  • Dieses Element überschreitet die für diesen Ordner definierte Maximalgröße und kann nicht gespeichert werden. Bitten Sie den Serveradministrator, das Ordnerlimit zu erhöhen.

Die Größe von "OWAScratchPad" wird bei der EXOLEDB-Initialisierung immer auf 1 MB zurückgesetzt, wenn der REG_DWORD-Wert "Message Size Limit" des Registrierungsschlüssels HKLM\System\CurrentControlSet\Services\MSExchangeWeb\OWA nicht festgelegt wurde. Für Microsoft SharePoint® Portal Server ist diese Festlegung erforderlich, da EXOLEDB nicht ermitteln kann, ob der Magma-Modus aktiv ist.

Outlook Web Access-Beiträge im Scratch-Pad werden im Flat-URL-Format durchgeführt, sodass sie direkt auf den Ordner und die Nachricht verweisen. Auf diese Weise werden tiefe Vroots unterstützt, wenn die URL in Kurzform möglicherweise zu lang ist.

Lesen Sie im Folgenden Antworten auf häufig gestellte Fragen.

Zu dieser Frage gibt es zwei Kategorien:

  • Active Directory-Objekte   Wenn ein Speicher gelöscht wurde, gibt es keine Möglichkeit, Active Directory mitzuteilen, dass die Öffentlichen Ordnerobjekte nicht mehr vorhanden sind. Bei der anschließenden Neuerstellung werden die Ordner nicht an die entsprechenden Verzeichnisdienstobjekte angehängt. Stattdessen werden neue Verzeichnisdienstobjekte erstellt.
  • Tatsächliche Ordner   Wenn die Ordner zur Replikation ausgewählt sind und der betreffende Speicher gelöscht wird, werden die Ordner von EXOLEDB beim Starten erneut erstellt. Dann kann durch die Replikation ein Duplikat dieser Ordner erstellt werden. Dadurch entstehen Probleme bei Ereignisbindungen. Das Löschen von Ordnerduplikaten über URLs in Kurzform birgt Risiken, weil beide oft über doppelte URLs in Kurzform verfügen.

Wenn die Anzahl der Systemordner mit derselben Nummer zunimmt, wird eine zufällige Zahl zur Unterscheidung an den Verzeichnisdienstproxy angefügt. Dadurch entstehen Namen wie "controls12345678".

Gelöschte Ordner würden von EXOLEDB automatisch wiederhergestellt. Außerdem verfügen die meisten dieser Ordner über Funktionen, die für den ordnungsgemäßen Betrieb des Servers notwendig sind.

Wenn Schemaordner fehlen, also in der Unterstruktur "ipm" nicht vorhanden sind, kann das Schema neu gefüllt werden, indem der folgende Registrierungsschlüssel auf den REG_DWORD-Wert "0" gesetzt wird:

HKLM\System\CurrentControlSet\MSExchangeIS\Parameters\Schema\<MDBGUID>

EXOLEDB gewährt jedem Benutzer automatisch Lesezugriff auf Schemaordner. Diese Zugriffssteuerungsliste (Access Control List, ACL) könnte geändert werden. Bei einer erneuten Auslösung der Schemaübermittlung würde sie jedoch gelöscht.

Bei Vorgängen zum Replizieren von Systemordnern müssen Ordnerinhalte nicht repliziert werden.

Weitere Informationen finden Sie im folgenden Exchange-Blogeintrag:

 
Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.
Anzeigen:
© 2014 Microsoft