Postfächer in einer Datenbank werden in einer Umgebung mit System Center Operations Manager unter Quarantäne gestellt

Veröffentlichung des Originalartikels: 28.06.2012

Update 03.07.2012: Der Abschnitt "Problemumgehung" wurde mit weiteren Einzelheiten ergänzt.

Wir wollten Sie auf ein Problem aufmerksam machen, das wir in letzter Zeit in CSS beobachtet haben: Viele Postfächer in der gleichen Postfachdatenbank werden scheinbar ohne Grund unter Quarantäne gestellt. Wenn Sie das Anwendungsprotokoll untersuchen, sehen Sie zahlreiche 10018-Ereignisse mit folgenden Angaben:

Protokollname: Anwendung
Quelle: MSExchangeIS
Ereignis-ID: 10018
Aufgabenkategorie: Allgemein
Ebene: Fehler
Beschreibung:
Das Postfach des Benutzers <guid>: /o=Contoso /ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserMailbox wurde isoliert. Der Zugriff auf dieses Postfach wird in den nächsten sechs Stunden auf administrative Anmeldungen beschränkt.

Darüber hinaus wird für jedes Postfach, das von der Problembehandlung für den Datenbankspeicherplatz unter Quarantäne gestellt wurde, das folgende Ereignis 5410 im Ereignisprotokoll Microsoft-Exchange-Troubleshooters/Operational angezeigt:

Protokollname: Microsoft-Exchange-Troubleshooters/Operational
Quelle: Datenbankspeicherplatz
Ereignis-ID: 5410
Ebene: Warnung
Schlüsselwörter: Klassisch
Beschreibung:
Bei der Problembehandlung für den Datenbankspeicherplatz wurde das Postfach <guid> in der Datenbank <DBName> isoliert.

Der Schlüssel ist hier der letzte Satz: "Bei der Problembehandlung für den Datenbankspeicherplatz ...". In Umgebungen, in denen System Center Operations Manager bereitgestellt wurde, ist standardmäßig ein Monitor aktiv, der die Umgebung auf freien Speicherplatz für Datenbank- und Protokollvolumes überprüft. Dieser Monitor verwendet das PowerShell-Skript Troubleshoot-DatabaseSpace.ps1, das standardmäßig mit Exchange 2010 ausgeliefert wird. Wenn Sie mehr über das Skript Troubleshoot-DatabaseSpace.ps1 erfahren möchten, lesen Sie den folgenden TechNet-Artikel:

Verwalten des Datenbankprotokollwachstums über das Skript "Troubleshoot-DatabaseSpace.ps1" in der Shell
https://technet.microsoft.com/en-us/library/ff477617.aspx

Das System Center-Team hat kürzlich Service Pack 2 für das Exchange Management Pack herausgegeben. Damit wurde unter anderem ein Timeoutwert für die Ausführung des Skripts angepasst. Vor dem Service Pack war der Timeoutwert 300 Sekunden, und der Monitor war so konfiguriert, dass er alle 5 Minuten gestartet wurde. Die Folge: In vielen großen Organisationen war die Zeitüberschreitung bei dem Skript buchstäblich garantiert, sodass die Ausführung des Skripts nie abgeschlossen werden konnte. Nach dem Installieren des Upgrades ist der neue Timeoutwert nun 1.200 Sekunden. Darüber hinaus wird der Monitor jetzt einmal pro Stunde statt alle 5 Minuten ausgeführt. Der Effekt dieser Veränderung ist, dass die Problembehandlung Code, den sie vor dem Update auf SP2 nicht ausgeführt hat, jetzt zuverlässig ausführt. Dadurch hat die Problembehandlung einen Fehler im perfmon-Zähler des Informationsspeichers gefunden, anhand dessen sie die Leistung der Protokollgenerierung für die Datenbank ermittelt (der perfmon-Wert kann 1,0E+19 Bytes pro Stunde übersteigen). Wenn die geschätzte Protokollgenerierungsleistung pro Stunde die Kapazität des verbleibenden freien Speicherplatzes im Datenbank- oder Protokollvolume übersteigt, beginnt die Problembehandlung mit der Isolierung von Postfächern, damit die Protokollgenerierung nicht den ganzen freien Speicherplatz aufbraucht und das Abkoppeln der Datenbank verursacht. Die Problembehandlung gerät offensichtlich in diesen Zustand, wenn der perfmon-Zähler einen "Phantasiewert" hat (der perfmon-Zähler wird einmal pro Minute aktualisiert und sollte nicht länger als eine Minute einen Phantasiewert haben) ... Das passiert also nicht oft, tritt aber mit einiger Wahrscheinlichkeit hin und wieder ein.

Was bedeutet das für Sie?

Nun, wie auch im TechNet-Artikel beschrieben, besteht die Hauptfunktion des Skripts darin, die Protokollgenerierungsleistung zu verfolgen und die Umgebung auf freien Speicherplatz für die Datenbank- und Protokollvolkumes zu überprüfen. Wird das Skript ausgeführt, ermittelt es anhand eines perfmon-Speicherzählers die Leistung der Protokollgenerierung. Es berechnet dann, ob der Speicherplatz auf dem Datenträger bei der aktuellen Rate innerhalb des durch den Schwellenwert definierten Zeitraums aufgebraucht wird (standardmäßig 12 Stunden) – falls ja, beginnt es optional mit der Isolierung von Postfächern (bis zu 150 auf einmal). Ebenfalls optional isoliert das Skript dann Postfächer, wenn der Prozentsatz des freien Speicherplatzes einen angegebenen Wert unterschreitet. Der verwendete Standardwert für den Prozentsatz des freien Speicherplatzes ist 25 %. Damit Postfächer unter Quarantäne gestellt werden, wenn eine dieser beiden Bedingungen zutrifft, muss der –Quarantine-Parameter an das Skript übergeben werden.

Der von SCOM 2007 und höher verwendete Monitor verwendet den Quarantine-Parameter standardmäßig, und es gibt keine Option, dies zu ändern, da das Management Pack versiegelt ist. Das bedeutet Folgendes: Wenn der freie Speicherplatz für das Datenbank- oder Protokollvolume für eine Datenbank 25 % unterschreitet UND die Protokollgenerierungsrate ergibt, dass der verbleibende Speicherplatz innerhalb der nächsten 12 Stunden aufgebraucht wird, werden die Benutzer, die das System am meisten nutzen, isoliert. Wenn sich in einer Datenbank viele Postfächer befinden, kann das bedeuten, dass innerhalb kurzer Zeit viele Postfächer unter Quarantäne gestellt werden.

Was können Sie tun?

Natürlich ist die Isolierung zahlreicher Postfächer ein unerwünschtes Verhalten, denn es verursacht Ausfälle bei den betreffenden Benutzern – obwohl es immer noch besser ist, als wenn die ganze Datenbank wegen Speicherplatzmangels abgekoppelt wird (dadurch würden ja bei allen Benutzern dieser Datenbank Ausfälle entstehen). Sie können isolierte Postfächer manuell wieder freigeben, indem Sie die GUID des betreffenden Postfachs aus der Registrierung entfernen . Das ist aber keine optimale Lösung, denn es kann sein, dass die gleichen Postfächer bei der nächsten Ausführung des Monitors wieder unter Quarantäne gestellt werden.

Isolierte Postfächer werden an folgender Stelle identifiziert:

Hkey_Local_Machine\SYSTEM\CurrentControlSet\Services\MSexchangeIS\Servername\Private-<D Bguid>\Quarantined Mailboxes\ {Postfach-GUID}

Sie sollen wissen, dass uns diese Situation bewusst ist und wir an einer Lösung arbeiten. Solange wir noch an der bestmöglichen Lösung tüfteln, möchten wir Ihnen eine Problemumgehung ans Herz legen, mit der Sie verhindern können, dass Postfächer isoliert werden. Inzwischen haben wir, damit dieses Problem nicht bei noch mehr Kunden auftritt, das Exchange 2010 SP2 Management Pack vorübergehend aus dem Download Center entfernt.

Problemumgehung

Erstellen Sie eine Außerkraftsetzung, um die Monitore zu deaktivieren, die die Umgebung auf freien Speicherplatz untersuchen. Dadurch wird unterbunden, dass die Datei Troubleshoot-DatabaseSpace.ps1 überhaupt ausgeführt wird.

Eine bewährte Methode beim Erstellen von Außerkraftsetzungen ist es, diese in ein neues Management Pack speziell für Anpassungen in System Center Operations Manager zu platzieren. Dadurch können Sie Außerkraftsetzungen und andere benutzerdefinierte Einstellungen schnell und einfach verwalten. Wenn Sie dafür noch kein Management Pack haben, können Sie mithilfe der folgenden Schritte eines erstellen:

1. Klicken Sie in der Betriebskonsole auf die Schaltfläche Verwaltung. Klicken Sie im Bereich Verwaltung mit der rechten Maustaste auf Management Packs, und klicken Sie dann auf Management Pack erstellen. Der Assistent Management Pack erstellen wird angezeigt.
2. Geben Sie auf der Seite Allgemeine Eigenschaften im Feld Name einen Namen für das Management Pack ein, im Feld Version die korrekte Versionsnummer und im Feld Beschreibung eine kurze Beschreibung. Klicken Sie auf Weiter und dann auf Erstellen.

Nachdem Sie ein Management Pack für die Außerkraftsetzungen benannt haben, erstellen Sie die Außerkraftsetzungen für die vier folgenden Monitore:

Gehen Sie in System Center Operations Manager zum Modul Konfiguration und dann unter Management Pack-Objekte zu Monitore. Sie können die Monitore deaktivieren, indem Sie eine Außerkraftsetzung definieren und dann festlegen, dass der Monitor für alle Objekte der Klasse Database Copy DB Logical Disk Space deaktiviert wird (wie unten abgebildet):

Aktivieren Sie das Kontrollkästchen neben Aktiviert, und ändern Sie dann den Außerkraftsetzungswert, indem Sie False auswählen:

Wählen Sie im gleichen Dialogfeld unter Eigenschaften das für Anpassungen vorgesehene Management Pack aus.

Wenn bei Ihnen das Problem mit der Isolierung von Postfächern auftritt, besteht unserer Ansicht nach derzeit die einzige mögliche Problemumgehung darin, die Monitore zu deaktivieren. Uns ist bekannt, dass dadurch Administratoren u. U. keine Warnmeldungen erhalten, wenn nur noch wenig Speicherplatz frei ist, aber bis ein Fix veröffentlicht wird, ist dies wohl die bestmögliche Option, um zu verhindern, dass Postfächer unter Quarantäne gestellt werden.

Hinweis: Wenn nur noch wenig Speicherplatz für Datenbanken frei ist, erhält der Administrator dennoch eine Warnmeldung, wenn das Laufwerk für das Transaktionsprotokoll mit dem für die Datenbank koexistiert, denn dieses wird von einer ganz anderen Regel generiert, die rein auf perfmon basiert.

Ben Winzenz, Kevin Carker

Dies ist ein übersetzter Blogbeitrag. Den Originalartikel finden Sie unter Mailboxes on a database are Quarantined in an environment with System Center Operations Manager