Änderungen an der Versionsverwaltung von "Wiederherstellbare Elemente" in Exchange Server 2010 SP2 RU3

Veröffentlichung des Originalartikels: 01.06.2012

Im Laufe der letzten Monate haben wir Berichte über eine übermäßige Vergrößerung des Ordners Wiederherstellbare Elemente erhalten (den viele als Dumpster bezeichnen, obwohl wir diese Bezeichnung nicht mehr verwenden). Hauptsächlich kann es in zwei Szenarien zu dieser übermäßigen Vergrößerung kommen.

1. Wiederherstellung einzelner Elemente und Versionsverwaltung des Beweissicherungsverfahrens
2. Protokollierung der Kalenderversion

Wiederherstellung einzelner Elemente und Beweissicherungsverfahren

Durch die Wiederherstellung einzelner Elemente und das Beweissicherungsverfahren wird die Aufbewahrung von Daten im Postfach aktiviert. Wenn Sie mit diesen Features nicht vertraut sind, finden Sie weitere Informationen hierzu in meinem letzten Blogbeitrag Wiederherstellung einzelner Elemente in Exchange Server 2010.

Zusätzlich zur Aufbewahrung von Daten im Postfach wird sowohl bei der Wiederherstellung einzelner Elemente als auch beim Beweissicherungsverfahren die Versionsverwaltung aktiviert. Im Wesentlichen wird bei der Änderung eines Elements der Vorgang COW (Copy-On-Write, Kopieren beim Schreiben) durchgeführt, um die Originalversion des Elements aufzubewahren. Das Originalelement wird in den Ordner Wiederherstellbare Elemente\Versionen verschoben. Dieser Ordner wird Benutzern nicht offen gelegt.

Da Exchange Server 2010 eine Änderung umfasst, wie Clients eine Verbindung mit Postfachdaten herstellen und darauf zugreifen, findet der COW-Vorgang auf der Ebene der Exchange-Systemobjekte (Exchange System Objects, XSO) des Clientzugriffsservers statt.

Wodurch wird ein COW-Vorgang ausgelöst?

• Bei Meldungen und Blogbeiträgen (IPM.Note* und IPM.Post*) werden Änderungen am Betreff, Text, an Anlagen, Absendern/Empfängern und gesendeten/empfangenen Daten von COW erfasst.
• Bei anderen Elementtypen, mit Ausnahme der Verschiebungen zwischen Ordnern und Änderungen des Status gelesen/ungelesen, werden alle Änderungen an Elementen von COW erfasst.
• Entwürfe werden von COW nicht erfasst, um unnötige Kopien beim automatischen Speichern zu vermeiden.

Wie kann es zu einer übermäßigen Vergrößerung des Ordners "Wiederherstellbare Elemente" kommen?

COW-Verhalten kann eine übermäßige Vergrößerung zur Folge haben. Wir stellten fest, dass es im folgenden Szenario bei Verwendung von Microsoft Outlook zu übermäßigen COW-Vorgängen kommt:

1. Sie erstellen einen Kalendertermin.
2. Sie fügen dem Termin ein Office-Dokument an und speichern.
3. Sie beschließen dann, den Termin zu öffnen, um eine Änderung am Office-Dokument vorzunehmen. Sie öffnen das Dokument.
4. Im Hintergrund beginnt Outlook mit der automatischen Speicherung des geöffneten Termins und des entsprechenden geöffneten Dokuments (standardmäßig finden automatische Speicherungen in Outlook alle 3 Minuten statt).
5. Durch jede automatische Speicherung wird ein COW-Vorgang ausgelöst. Da bei der automatischen Speicherung jedoch sowohl das Office-Dokument als auch der Termin gespeichert werden, finden zwei COW-Ereignisse statt. Bei jeder zusätzlichen Anlage wird auch eine weitere COW-Version erstellt.

Ja, das tut richtig weh!

Da Anlagen Teil der Nachricht sind, ist es nicht sinnvoll, dass für jede Anlage eine Kopie erstellt wird. Wenn Sie ein Element speichern, das über eine Anlage verfügt, wird im Wesentlichen Folgendes in Outlook ausgeführt:

1. CreateAttachment
2. SaveAttachment
3. SaveMessage

Der COW-Vorgang wurde sowohl bei SaveAttachment als auch SaveMessage ausgeführt. Bei einem Blick in den Code stellten wir fest, dass bei einem Aufruf von SaveAttachment letztlich die Flush-Methode (ein Mittel des Clients zur Synchronisierung des Status mit dem Server) für die Nachricht, der sie zugeordnet ist, nach dem Speichern der Anlage aufgerufen wurde. Dieser Aufruf von Flush gab dem COW-Code das Signal zu handeln.

Nach weiterer Analyse stellten wir fest, dass die COW-Logik bei jedem Flush-Aufruf ausgelöst wurde. Diese Erkenntnis ist von hoher Bedeutung, da Flush-Aufrufe in vielen Szenarien initiiert werden können, und stellt vermutlich die Ursache für Tausende von COW-Ereignissen dar, die die Kunden in ihren Umgebungen feststellen konnten.

Mit Exchange Server 2010 SP2 RU3 und höher ist COW nun in der Lage, zwischen Leerungs- und Speichervorgängen (Flush und Save) zu unterscheiden und wird nun nur bei einem Speichervorgang (Save) ausgelöst.

Protokollierung der Kalenderversion

Die Protokollierung der Kalenderversion ist der Vorgang, bei dem Kalenderänderungen in einem Postfach mittels COW gespeichert werden. Die Protokollierung der Kalenderversion wurde in Exchange Server 2010 zur Problembehandlung und Beseitigung von Problemen mit der Zuverlässigkeit des Kalenders eingeführt.

Die Protokollierung der Kalenderversion ist so konzipiert, dass bei jeder Änderung eines Kalenderelements ein Protokoll erstellt wird. Diese Protokolle stellen einen Verlauf der Besprechung dar. Mithilfe des Get-CalendarDiagnosticLog-Cmdlets können Sie den Verlauf überprüfen und die Clients ermitteln, die destruktiv reagieren. Die Protokollierung der Kalenderversion wird außerdem vom Kalenderreparatur-Assistenten verwendet, der die Protokolle nutzt, um den Verlauf eines bestimmten Kalenderelements für die Erkennung von Inkonsistenzen zu ermitteln.

Die Protokollierung der Kalenderversion ist in Postfächern in Exchange Server 2010 standardmäßig aktiviert. Sie können dieses Feature in einem Postfach über die CalendarVersionStoreDisabled-Eigenschaft deaktivieren. Der Eigenschaftsname lautet CalendarVersionStoreDisabled, der Standardwert $false bedeutet also, dass die Protokollierung der Kalenderversion standardmäßig aktiviert ist.  Abhängig von der Postfachkonfiguration wird ein anderer Prozess für die Speicherung von Kopien der Kalenderelemente ausgeführt:

1. Wenn das Postfach nicht für die Wiederherstellung einzelner Elemente und das Beweissicherungsverfahren aktiviert ist, werden gekürzte Versionen der Kalenderelemente im Stamm des Ordners der wiederherstellbaren Elemente für die Dauer von 120 Tagen aufbewahrt. Die gekürzten Versionen (Text und Anlagen, die nicht auf der ersten Ebene oder nicht eingebettet sind, werden entfernt) werden mithilfe von COW erstellt.
2. Wenn das Postfach für die Wiederherstellung einzelner Elemente und das Beweissicherungsverfahren aktiviert ist, werden vollständige Kopien der Kalenderelemente in den Ordnern Wiederherstellbare Elemente\Löschungen oder Wiederherstellbare Elemente\Versionen aufbewahrt. Wenn eine endgültige Löschung des Kalenderelements in den Ordnern Wiederherstellbare Elemente\Löschungen oder Wiederherstellbare Elemente\Versionen ausgeführt wird, wird eine gekürzte Version mithilfe der COW-Infrastruktur erstellt. Diese gekürzte Version wird im Stamm des Ordners Wiederherstellbare Elemente abgelegt und 120 Tage lang aufbewahrt. Es wird nur dann keine gekürzte Version erstellt, wenn das Element in den Ordnern Wiederherstellbare Elemente\Löschungen oder Wiederherstellbare Elemente\Versionen älter als 134 Tage (120 + 14) ist. Dieser Fall kann eintreten, wenn Sie die Aufbewahrungsfrist ändern, wenn der Postfachordner-Assistent nicht ausgeführt oder das Beweissicherungsverfahren deaktiviert wurde usw.

Aufgrund des oben erwähnten Problems im Zusammenhang mit der fehlenden Unterscheidung der COW-Logik zwischen Leerungs- und Speichervorgängen konnte durch die Protokollierung der Kalenderversion ein hoher Prozentsatz des Kontingents des Ordners "Wiederherstellbare Elemente" aufgebraucht werden (zur Erinnerung: der Warnungsschwellenwert beträgt 20 GB. und die harte Kontingentgrenze beträgt 30 GB).

Obwohl mit SP2 RU3 die COW-Probleme beseitigt waren, haben wir aufgrund von Bedenken, dass durch die Protokollierung der Kalenderversion das Kontingent des Ordners Wiederherstellbare Elemente aufgebraucht werden könnte, in SP2 RU2 die Architektur so geändert, dass die Protokollierung der Kalenderversion die Größe des Ordners Wiederherstellbare Elemente berücksichtigt, ehe ein COW-Vorgang ausgeführt wird.

Wenn die Größe des Ordners RecoverableItemsWarningQuota übersteigt, wird die Protokollierung der Kalenderversion für das Postfach deaktiviert. Der verwendete RecoverableItemsWarningQuota-Wert ist von den Einstellungen des Postfachs abhängig:

1. Wenn der Wert von UseDatabaseQuotaDefaults für das Postfach auf $true festgelegt ist, wird RecoverableItemsWarningQuotader Postfachdatenbank verwendet.
2. Wenn der Wert von UseDatabaseQuotaDefaults für das Postfach auf $false festgelegt ist, wird RecoverableItemsWarningQuota des Postfachs verwendet.

Wenn die Protokollierung der Kalenderversion deaktiviert wird, wird das folgende Ereignis im Anwendungsereignisprotokoll auf den Clientzugriffsserver generiert:

Ereignis-ID: 5003
Quelle: MSExchange Mid-Tier Storage
Aufgabenkategorie: CopyOnWrite
Ebene: Information
Beschreibung: Warnungsschwellenwert für Benutzerpostfach <legacyExchangeDN> wurde überschritten. Die Kalenderprotokollierung des Postfachs wurde deaktiviert.

Aber damit nicht genug! Ich möchte hier zu diesem frühen Zeitpunkt in der Entwicklung noch nicht ins Detail gehen, doch arbeiten wir an der weiteren Verbesserung der Protokollierung der Kalenderversion, um die Auswirkungen dieses Features in einer Bereitstellung zu minimieren. Sobald weitere Neuerungen bereitstehen, werdet Ihr hier in diesem Blog darüber informiert.

Ross Smith IV
Principal Program Manager
Exchange Customer Experience

Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter Holy COW! Changes to Recoverable Items versioning in Exchange 2010 SP2 RU3