Überwachen von hoher Verfügbarkeit und Ausfallsicherheit für Standorte

 

Gilt für: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Letztes Änderungsdatum des Themas: 2015-03-09

Die wichtigsten Ziele im Rahmen der täglichen Verwaltung sind, dass Ihre Server zuverlässig arbeiten und dass sich Ihre Datenbankkopien in einem fehlerfreien Zustand befinden. Damit die Verfügbarkeit und Zuverlässigkeit Ihrer Microsoft Exchange Server 2010-Organisation sichergestellt ist, müssen Sie die Hardware, das Windows-Betriebssystem und die Exchange 2010-Dienste aktiv überwachen. Durch eine proaktive Überwachung zusammen mit vorbeugender Wartung können Sie mögliche Fehler feststellen, bevor ein ernsthaftes Problem den Betrieb Ihrer Exchange-Organisation beeinträchtigt.

Zur Überwachung Ihrer Exchange-Organisation gehört die regelmäßige Überprüfung auf Probleme mit Diensten oder Daten. Außerdem umfasst die Überwachung in der Regel auch ein Benachrichtigungssystem, das Sie warnt, wenn Probleme auftreten. In Windows Server 2008 und Exchange 2010 sind mehrere Tools und Dienste enthalten, mit denen Sie einen reibungslosen Betrieb Ihrer Exchange-Organisation sicherstellen können. Im Folgenden werden die wichtigsten Vorteile der täglichen Überwachung vorgestellt:

• Erfüllen der Anforderungen Ihrer SLAs (Service Level Agreements, Vereinbarungen zum Servicelevel)

• Sicherstellen des erfolgreichen Abschlusses bestimmter Verwaltungsaufgaben, z. B. der täglichen Sicherungsvorgänge

• Ermitteln und Lösen von Problemen, die beispielsweise den Messagingdienst oder die Datenverfügbarkeit beeinträchtigen

In einer Exchange 2010-Organisation sollten die Verfahren, Rollen und Verantwortlichkeiten formalisiert sein, die den Betrieb beeinflussen. Es ist wichtig, die Verbindung zwischen soliden Betriebsmethoden und -verfahren und einer stabilen Infrastruktur zu verstehen. Gut dokumentierte, durchdachte Betriebsprozesse und -verfahren stellen sicher, dass alle Komponenten in der Umgebung einer Organisation mit Exchange effizient und effektiv verwaltet werden.

Exchange 2010 umfasst mehrere integrierte Tools, Skripts und Funktionen, die im Rahmen einer regelmäßigen proaktiven Überwachung verwendet werden können, wenn Exchange für hohe Verfügbarkeit oder Ausfallsicherheit für Standorte konfiguriert ist. Die primären Überwachungs-Cmdlets für hohe Verfügbarkeit und Ausfallsicherheit für Standorte sind Get-MailboxDatabaseCopyStatus und Test-ReplicationHealth. Zusätzlich zu den Cmdlets, mit denen Überwachungsfunktionen durchgeführt und Statusberichte erstellt werden können, bietet Exchange 2010 außerdem einen neuen Ereignisprotokolldatenstrom, der die Crimson-Kanalfunktionen in Windows Server sowie integrierte Skripts verwendet, mit denen Daten aus diesen Ereigniskanälen erfasst und analysiert werden können.

Sie können die Informationen in diesem Thema verwenden, um den Status von Postfachdatenbankkopien für Database Availability Groups (DAG) zu überwachen.

Inhalt

Cmdlet "Get-MailboxDatabaseCopyStatus"

Cmdlet "Test-ReplicationHealth"

Crimson-Kanal-Ereignisprotokollierung

Skript "CollectOverMetrics.ps1"

Skript "CollectReplicationMetrics.ps1"

Das Skript "CheckDatabaseRedundancy.ps1"

Cmdlet "Get-MailboxDatabaseCopyStatus"

Mithilfe des Cmdlets Get-MailboxDatabaseCopyStatus können Sie Statusinformationen zu Postfachdatenbankkopien anzeigen. Dieses Cmdlet ermöglicht Ihnen die Anzeige von Informationen über alle Kopien einer bestimmten Datenbank, über eine bestimmte Kopie einer Datenbank auf einem bestimmten Server oder über alle Datenbankkopien auf einem Server. In der folgenden Tabelle werden mögliche Werte für den Kopiestatus einer Postfachdatenbankkopie beschrieben.

Status der Datenbankkopie

Status der Datenbankkopie	Beschreibung
Fehler	Die Postfachdatenbankkopie weist einen Fehlerzustand auf, da sie nicht angehalten wurde und keine Protokolldateien kopieren oder wiedergeben kann. Während sie sich im Fehlerzustand befindet und nicht angehalten wurde, überprüft das System in regelmäßigen Abständen, ob das Problem, das den fehlerhaften Kopierstatus verursacht hat, behoben wurde. Sobald das System ermittelt, dass das Problem gelöst wurde und keine weiteren Probleme vorliegen, wird der Kopierstatus automatisch in Fehlerfrei geändert.
Seeding	Für die Postfachdatenbankkopie, den Inhaltsindex für die Postfachdatenbankkopie oder für beides wird ein Seeding durchgeführt. Bei erfolgreichem Abschluss des Seedingvorgangs sollte der Kopierstatus sich in Initialisieren ändern.
SeedingSource	Die Postfachdatenbankkopie wird als Quelle für einen Seedingvorgang für die Datenbankkopie verwendet.
Angehalten	Die Postfachdatenbankkopie befindet sich in angehaltenem Zustand, weil ein Administrator die Datenbankkopie manuell durch Ausführen des Cmdlets Suspend-MailboxDatabaseCopy angehalten hat.
Fehlerfrei	Die Postfachdatenbankkopie kann Protokolldateien erfolgreich kopieren und wiedergeben oder hat alle verfügbaren Protokolldateien erfolgreich kopiert und wiedergegeben.
ServiceDown	Der Microsoft Exchange-Replikationsdienst steht nicht zur Verfügung oder wird nicht auf dem Server ausgeführt, der die Postfachdatenbankkopie hostet.
Initialisieren	Die Postfachdatenbankkopie befindet sich im Initialisierungszustand, wenn eine Datenbankkopie erstellt wurde, wenn der Microsoft Exchange-Replikationsdienst gestartet wird oder gerade gestartet wurde sowie während der Übergänge aus den Zuständen Suspended, ServiceDown, Failed, Seeding, SinglePageRestore, LostWrite oder Disconnected in einen anderen Zustand. In diesem Zustand überprüft das System, ob die Datenbank und der Protokolldatenstrom sich in einem konsistenten Zustand befinden. In den meisten Fällen verbleibt der Kopierstatus für etwa 15 Sekunden im Initialisierungszustand. Im Allgemeinen sollte dieser Zustand nicht länger als 30 Sekunden andauern.
Erneute Synchronisierung	Die Postfachdatenbankkopie und die zugehörigen Protokolldateien werden mit der aktiven Kopie der Datenbank verglichen, um Unterschiede zwischen beiden Kopien festzustellen. Der Kopierstatus verbleibt in diesem Zustand, bis Unterschiede ermittelt und gelöst wurden.
Eingebunden	Die aktive Kopie ist online und nimmt Clientverbindungen an. Nur die aktive Kopie der Postfachdatenbank kann den Kopierstatus Eingebunden aufweisen.
Einbindung aufgehoben	Die aktive Kopie ist offline und nimmt keine Clientverbindungen an. Nur die aktive Kopie der Postfachdatenbank kann den Kopierstatus Einbindung aufgehoben aufweisen.
Wird eingebunden	Die aktive Kopie wird online geschaltet und nimmt noch keine Clientverbindungen an. Nur die aktive Kopie der Postfachdatenbank kann den Kopierstatus Wird eingebunden aufweisen.
Einbindung wird aufgehoben	Die aktive Kopie wird offline geschaltet, und Clientverbindungen werden beendet. Nur die aktive Kopie der Postfachdatenbank kann den Kopierstatus Einbindung wird aufgehoben aufweisen.
DisconnectedAndHealthy	Die Postfachdatenbankkopie ist nicht länger mit der aktiven Datenbankkopie verbunden. Sie war in fehlerfreiem Zustand, als die Verbindung verloren ging. Dieser Zustand stellt die Datenbankkopie im Hinblick auf ihre Verbindung mit der Quelldatenbankkopie dar. Er kann bei Netzwerkfehlern der DAG zwischen der Quellkopie und der Zieldatenbankkopie gemeldet werden.
DisconnectedAndResynchronizing	Die Postfachdatenbankkopie ist nicht länger mit der aktiven Datenbankkopie verbunden. Sie befand sich im Zustand Erneute Synchronisierung, als die Verbindung verloren ging. Dieser Zustand stellt die Datenbankkopie im Hinblick auf ihre Verbindung mit der Quelldatenbankkopie dar. Er kann bei Netzwerkfehlern der DAG zwischen der Quellkopie und der Zieldatenbankkopie gemeldet werden.
FailedAndSuspended	Die Zustände Fehler und Angehalten wurden vom System gleichzeitig festgelegt, weil ein Fehler ermittelt wurde und die Lösung des Fehlers explizit einen Administratoreingriff erfordert. Ein Beispiel hierfür ist, wenn das System einen nicht behebbaren Unterschied zwischen der aktiven Postfachdatenbank und einer Datenbankkopie ermittelt. Im Gegensatz zum Zustand Fehler prüft das System nicht regelmäßig, ob das Problem behoben wurde, und führt keine automatische Wiederherstellung durch. Stattdessen muss ein Administrator eingreifen, um die zugrunde liegende Ursache des Fehlers zu beheben, bevor die Datenbankkopie in einen fehlerfreien Zustand übergehen kann.
SinglePageRestore	Dieser Zustand zeigt an, dass in der Postfachdatenbankkopie ein Wiederherstellungsvorgang für eine einzelne Seite stattfindet.

Das Cmdlet Get-MailboxDatabaseCopyStatus umfasst außerdem einen Parameter namens ConnectionStatus, der Einzelheiten zu den verwendeten Replikationsnetzwerken zurückgibt. Wenn Sie diesen Parameter verwenden, werden zwei zusätzliche Felder, IncomingLogCopyingNetwork und SeedingNetwork, in der Ausgabe des Tasks ausgefüllt.

Beispiele für "Get-MailboxDatabaseCopyStatus"

In den folgenden Beispielen wird das Cmdlet Get-MailboxDatabaseCopyStatus verwendet. In jedem Beispiel wird das Ergebnis an das Cmdlet Format-List ausgegeben, um die Ausgabe im Listenformat anzuzeigen.

In diesem Beispiel werden Statusinformationen für alle Kopien der Datenbank "DB2" zurückgegeben.

Get-MailboxDatabaseCopyStatus -Identity DB2 | Format-List

In diesem Beispiel wird der Status aller Datenbankkopien auf dem Postfachserver "MBX2" zurückgegeben.

Get-MailboxDatabaseCopyStatus -Server MBX2 | Format-List

In diesem Beispiel wird der Status aller Datenbankkopien auf dem lokalen Postfachserver zurückgegeben.

Get-MailboxDatabaseCopyStatus -Local | Format-List

In diesem Beispiel werden Netzwerkinformationen zum Status, zum Protokollversand und zum Seeding für die Datenbank "DB3" auf dem Postfachserver "MBX1" zurückgegeben.

Get-MailboxDatabaseCopyStatus -Identity DB3\MBX1 -ConnectionStatus | Format-List

Weitere Informationen zur Verwendung des Cmdlets Get-MailboxDatabaseCopyStatus finden Sie unter Get-MailboxDatabaseCopyStatus.

Cmdlet "Get-MailboxDatabaseCopyStatus"

Cmdlet "Test-ReplicationHealth"

Mithilfe des Cmdlets Test-ReplicationHealth können Sie fortlaufend Informationen über den Replikationsstatus von Postfachdatenbankkopien anzeigen. Dieses Cmdlet kann eingesetzt werden, um alle Aspekte von Replikation und Wiedergabestatus zu überprüfen und sich so einen vollständigen Überblick über einen bestimmten Postfachserver in einer DAG zu verschaffen.

Das Cmdlet Test-ReplicationHealth wurde für die proaktive Überwachung der fortlaufenden Replikation und der fortlaufenden Replikationspipeline, der Verfügbarkeit von Active Manager sowie des Status des zugrunde liegenden Clusterdiensts, Quorums und der zugrunde liegenden Netzwerkkomponenten entwickelt. Es kann lokal oder remote für jeden Postfachserver in einer DAG ausgeführt werden. Das Cmdlet Test-ReplicationHealth führt die in der folgenden Tabelle aufgeführten Tests durch.

Tests des Cmdlets "Test-ReplicationHealth"

Testname	Beschreibung
ClusterService	Überprüft, ob der Clusterdienst ausgeführt wird und auf dem angegebenen Mitglied der DAG bzw., wenn kein Mitglied der DAG angegeben ist, auf dem lokalen Server erreichbar ist.
ReplayService	Überprüft, ob der Microsoft Exchange-Replikationsdienst ausgeführt wird und auf dem angegebenen Mitglied der DAG bzw., wenn kein Mitglied der DAG angegeben ist, auf dem lokalen Server erreichbar ist.
ActiveManager	Überprüft, ob die auf dem angegebenen Mitglied der DAG (bzw., wenn kein Mitglied der DAG angegeben ist, auf dem lokalen Server) ausgeführte Instanz von Active Manager in einer gültigen Rolle vorliegt (primär, sekundär oder eigenständig).
TasksRpcListener	Überprüft, ob der Tasks-RPC-Server (Remote Procedure Call) ausgeführt wird und auf dem angegebenen Mitglied der DAG bzw., wenn kein Mitglied der DAG angegeben ist, auf dem lokalen Server erreichbar ist.
TcpListener	Überprüft, ob der TCP-Protokollkopielistener ausgeführt wird und auf dem angegebenen Mitglied der DAG bzw., wenn kein Mitglied der DAG angegeben ist, auf dem lokalen Server erreichbar ist.
DagMembersUp	Überprüft, ob alle Mitglieder der DAG verfügbar sind, ausgeführt werden und erreichbar sind.
ClusterNetwork	Überprüft, ob alle clusterverwalteten Netzwerke auf dem angegebenen Mitglied der DAG (bzw., wenn kein Mitglied der DAG angegeben ist, auf dem lokalen Server) verfügbar sind.
QuorumGroup	Überprüft, ob die Standardclustergruppe (Quorumgruppe) sich in einem fehlerfreien Onlinezustand befindet.
FileShareQuorum	Überprüft, ob der für die DAG konfigurierte Zeugenserver sowie das Zeugenverzeichnis und die Zeugenfreigabe erreichbar sind.
DBCopySuspended	Prüft, ob sich Postfachdatenbankkopien auf dem angegebenen Mitglied der DAG bzw., wenn kein Mitglied der DAG angegeben ist, auf dem lokalen Server im Zustand Angehalten befinden.
DBCopyFailed	Prüft, ob sich Postfachdatenbankkopien auf dem angegebenen Mitglied der DAG bzw., wenn kein Mitglied der DAG angegeben ist, auf dem lokalen Server im Zustand Fehler befinden.
DBInitializing	Prüft, ob sich Postfachdatenbankkopien auf dem angegebenen Mitglied der DAG bzw., wenn kein Mitglied der DAG angegeben ist, auf dem lokalen Server im Zustand Initialisieren befinden.
DBDisconnected	Prüft, ob sich Postfachdatenbankkopien auf dem angegebenen Mitglied der DAG bzw., wenn kein Mitglied der DAG angegeben ist, auf dem lokalen Server im Zustand Getrennt befinden.
DBLogCopyKeepingUp	Überprüft, ob Protokollkopiervorgang und Inspektion durch die passiven Kopien von Datenbanken auf dem angegebenen Mitglied der DAG (bzw., wenn kein Mitglied der DAG angegeben ist, auf dem lokalen Server) mit der Aktivität zur Protokollgenerierung auf der aktiven Kopie Schritt halten können.
DBLogReplayKeepingUp	Überprüft, ob die Wiedergabeaktivität für die passiven Kopien von Datenbanken auf dem angegebenen Mitglied der DAG (bzw., wenn kein Mitglied der DAG angegeben ist, auf dem lokalen Server) mit der Aktivität zur Protokollkopie und -inspektion Schritt halten kann.

Beispiel für "Test-ReplicationHealth"

In diesem Beispiel wird das Cmdlet Test-ReplicationHealth zum Testen des Replikationsstatus für den Postfachserver "MBX1" verwendet.

Test-ReplicationHealth -Identity MBX1

Cmdlet "Get-MailboxDatabaseCopyStatus"

Crimson-Kanal-Ereignisprotokollierung

Windows Server 2008 verfügt über zwei Kategorien von Ereignisprotokollen: Windows-Protokolle sowie Anwendungs- und Dienstprotokolle. Die Kategorie der Windows-Protokolle umfasst die Ereignisprotokolle, die in früheren Versionen von Windows verfügbar waren: Anwendungs-, Sicherheits- und Systemereignisprotokolle. Darüber hinaus gibt es zwei neue Protokolle: Das Setupprotokoll und das ForwardedEvents-Protokoll. In Windows-Protokollen werden Ereignisse aus älteren Anwendungen sowie Ereignisse gespeichert, die für das gesamte System gelten.

Bei Anwendungs- und Dienstprotokollen handelt es sich um eine neue Kategorie von Ereignisprotokollen. Anstelle von Ereignissen, die systemweite Auswirkungen haben können, werden in diesen Protokollen Ereignisse aus einer einzigen Anwendung oder Komponente gespeichert. Diese neue Kategorie von Ereignisprotokollen wird als Crimson-Kanal einer Anwendung bezeichnet.

Die Kategorie der Anwendungs- und Dienstprotokolle enthält vier Unterkategorien: Administrator-, Betriebs-, analytische und Debugprotokolle. Ereignisse in Administratorprotokollen sind vor allem relevant, wenn Sie die Einträge des Ereignisprotokolls zur Problembehandlung verwenden. Ereignisse im Administratorprotokoll enthalten Anweisungen, wie Sie auf die Ereignisse reagieren sollen. Ereignisse im Betriebsprotokoll sind ebenso hilfreich, erfordern jedoch mehr Interpretation. Administrator- und Debugprotokolle sind weniger benutzerfreundlich. In analytischen Protokollen, die standardmäßig ausgeblendet und deaktiviert sind, werden Ereignisse zur Nachverfolgung eines Problems gespeichert. Häufig wird eine hohe Anzahl von Ereignissen protokolliert. Debugprotokolle werden von Entwicklern beim Debuggen von Anwendungen verwendet.

Exchange 2010 protokolliert Ereignisse in Crimson-Kanälen im Anwendungs- und Dienstprotokollbereich. Sie können diese Kanäle folgendermaßen anzeigen:

1. Öffnen Sie die Ereignisanzeige.

2. Navigieren Sie in der Konsolenstruktur zu Anwendungs- und Dienstprotokolle > Microsoft > Exchange.

3. Wählen Sie unter Exchange einen Crimson-Kanal aus: HighAvailability oder MailboxDatabaseFailureItems.

Der Kanal HighAvailability enthält Ereignisse im Zusammenhang mit dem Starten und Herunterfahren des Microsoft Exchange-Replikationsdiensts sowie mit den verschiedenen Komponenten, die innerhalb des Microsoft Exchange-Replikationsdiensts ausgeführt werden: Active Manager, die Drittanbieter-API zur synchronen Replikation, der Tasks-RPC-Server, TCP-Listener und VSS-Writer (Volume Shadow Copy Service, Volumeschattenkopie-Dienst). Der Kanal HighAvailability wird auch von Active Manager zum Protokollieren von Ereignissen im Zusammenhang mit der Active Manager-Rollenüberwachung sowie von Datenbankaktionsereignissen wie dem Vorgang zur Datenbankeinbindung und zum Abschneiden von Protokollen verwendet. Außerdem dient er zum Aufzeichnen von Ereignissen im Hinblick auf den zugrunde liegenden Cluster der DAG.

Der Kanal MailboxDatabaseFailureItems wird zum Protokollieren von Ereignissen im Zusammenhang mit Fehlern verwendet, die sich auf eine replizierte Postfachdatenbank auswirken.

Cmdlet "Get-MailboxDatabaseCopyStatus"

Skript "CollectOverMetrics.ps1"

Exchange 2010 umfasst ein Skript namens CollectOverMetrics.ps1, das im Ordner Scripts gespeichert ist. CollectOverMetrics.ps1 liest Ereignisprotokolle von DAG-Mitgliedern, um Informationen zu Datenbankvorgängen (z. B. Datenbankeinbindungen, -verschiebungen und -failover) über einen bestimmten Zeitraum zu erfassen. Für jeden Vorgang zeichnet das Skript folgende Informationen auf:

• Identität der Datenbank

• Anfangs- und Endzeitpunkt des Vorgangs

• Server, auf denen die Datenbank am Anfang und am Ende des Vorgangs eingebunden war

• Grund des Vorgangs

• Den Erfolg bzw. Misserfolg des Vorgangs (in diesem Fall mit den Fehlerdetails)

Das Skript schreibt diese Informationen in CSV-Dateien (pro Zeile ein Vorgang). Für jede DAG wird eine gesonderte CSV-Datei geschrieben.

Das Skript unterstützt Parameter, mit denen Sie das Verhalten und die Ausgabe des Skripts anpassen können. Mithilfe des Parameters Database oder ReportFilter kann z. B. das Ergebnis auf eine angegebene Untermenge beschränkt werden. Nur die Vorgänge, die diesen Filtern entsprechen, werden in den HTML-Zusammenfassungsbericht einbezogen. Die verfügbaren Parameter sind in der folgenden Tabelle aufgeführt:

Parameter des Skripts "CollectOverMetrics.ps1"

Parameter	Beschreibung
DatabaseAvailabilityGroup	Gibt den Namen der DAG an, deren Metriken Sie erfassen möchten. Wird dieser Parameter ausgelassen, wird die DAG verwendet, welcher der lokale Server angehört. Platzhalterzeichen dienen beim Erstellen von Berichten zum Erfassen von Informationen aus mehreren DAGs.
Database	Stellt eine Liste von Datenbanken bereit, für die der Bericht generiert werden soll. Platzhalterzeichen werden unterstützt, z. B. -Database:"DB1","DB2" oder -Database:"DB*".
StartTime	Gibt die Dauer des Zeitraums an, für den der Bericht erstellt werden soll. Das Skript erfasst nur die in diesem Zeitraum protokollierten Ereignisse. Demzufolge erfasst das Skript ggf. nur Teildatensätze zu Vorgängen (z. B. nur das Ende eines Vorgangs zum Anfangszeitpunkt des Zeitraums oder umgekehrt). Wenn weder StartTime noch EndTime angegeben wird, ist der Standardzeitraum des Skripts die letzten 24 Stunden. Wenn nur ein Parameter angegeben wird, ist der Zeitraum 24 Stunden, der zum angegebenen Zeitpunkt entweder beginnt oder endet.
EndTime	Gibt die Dauer des Zeitraums an, für den der Bericht erstellt werden soll. Das Skript erfasst nur die in diesem Zeitraum protokollierten Ereignisse. Demzufolge erfasst das Skript ggf. nur Teildatensätze zu Vorgängen (z. B. nur das Ende eines Vorgangs zum Anfangszeitpunkt des Zeitraums oder umgekehrt). Wenn weder StartTime noch EndTime angegeben wird, erfasst das Skript standardmäßig die letzten 24 Stunden. Wenn nur ein Parameter angegeben wird, ist der Zeitraum 24 Stunden, der zum angegebenen Zeitpunkt entweder beginnt oder endet.
ReportPath	Gibt den Ordner an, in dem die Ergebnisse der Ereignisverarbeitung gespeichert werden sollen. Wird dieser Parameter ausgelassen, wird der Ordner Scripts verwendet. Falls angegeben, verwendet das Skript eine Liste mit vom Skript generierten CSV-Dateien als Quelldaten zum Erstellen eines HTML-Zusammenfassungsberichts. Der Bericht entspricht demjenigen, der mit der Option -GenerateHtmlReport erstellt wird. Die Dateien können mehrere Database Availability Groups übergreifend zu vielen verschiedenen Zeitpunkten und sogar mit überlappenden Zeiträumen erstellen werden. Das Skript sorgt dafür, dass alle Daten zusammengeführt werden.
GenerateHtmlReport	Gibt an, dass das Skript alle aufgezeichneten Daten erfasst, die Daten nach Vorgangstyp gruppiert und anschließend eine HTML-Datei mit Statistiken zu jeder dieser Gruppen generiert. Der Bericht enthält die Gesamtanzahl von Vorgängen in jeder Gruppe, die Anzahl der nicht erfolgreichen Vorgänge und Statistiken zum Erfassungszeitraum innerhalb jeder Gruppe. Der Bericht enthält außerdem eine Aufgliederung der Typen von Fehlern, die zu misslungenen Vorgängen geführt haben.
ShowHtmlReport	Gibt an, dass der in HTML generierte Bericht anschließend in einem Webbrowser angezeigt werden soll.
SummariseCSVFiles	Gibt an, dass das Skript die Daten aus vorhandenen CSV-Dateien liest, die zuvor mithilfe des Skripts generiert wurden. Diese Daten dienen anschließend zum Generieren eines Zusammenfassungsberichts ähnlich demjenigen, der mit dem Parameter GenerateHtmlReport erstellt wird.
ActionType	Gibt die Arten der Vorgangsaktionen an, die das Skript erfassen soll. Die Werte für diesen Parameter sind Move, Mount, Dismount und Remount. Der Wert Move bezieht sich auf denjenigen Zeitpunkt, an dem die Datenbank ihren aktiven Server ändert (entweder aufgrund von Verschiebungen oder Failover). Die Werte Mount, Dismount und Remount beziehen sich auf Zeitpunkte, an denen die Datenbank ihren eingebundenen Status ändert, ohne auf einen anderen Computer verschoben zu werden.
ActionTrigger	Gibt die Verwaltungsvorgänge an, die vom Skript erfasst werden sollen. Die Werte für diesen Parameter sind Admin und Automatic. Automatische Aktionen werden vom System automatisch ausgeführt (z. B. ein Failover, wenn ein Server offline geschaltet wird). Verwaltungsaktionen (Admin) werden von einem Administrator entweder über die Exchange-Verwaltungsshell oder die Exchange-Verwaltungskonsole ausgeführt.
RawOutput	Gibt an, dass das Skript die Ergebnisse, die normalerweise in CSV-Dateien geschrieben würden, direkt in den Ausgabedatenstrom schreibt (wie beim Vorgang Write-Output). Diese Informationen können an andere Befehle weitergeleitet werden.
IncludedExtendedEvents	Gibt an, dass das Skript die Ereignisse erfassen soll, die Diagnosedetails zu den Zeiträumen liefern, die für das Einbinden von Datenbanken aufgewendet wurden. Dies kann eine sehr zeitaufwendige Phase sein, wenn das Ereignisprotokoll Anwendung auf den Servern sehr groß ist.
MergeCSVFiles	Gibt an, dass das Skript alle CSV-Dateien mit Daten zu jedem Vorgang verwendet und diese in einer einzelnen CSV-Datei zusammenführt.
ReportFilter	Gibt an, dass mithilfe der Felder in den CSV-Dateien ein Filter auf die Vorgänge angewendet werden soll. Dieser Parameter verwendet dasselbe Format wie ein Where-Vorgang, bei dem jedes Element auf $_ festgelegt ist und ein boolescher Wert zurückgegeben wird. Beispiel: {$_DatabaseName -notlike "Mailbox Database*"} dient zum Ausschließen der Standarddatenbanken aus dem Bericht.

Beispiele für "CollectOverMetrics.ps1"

In diesem Beispiel werden Metriken für alle Datenbanken erfasst, die "DB*" (mit Platzhalterzeichen) in einer DAG namens "DAG1" entsprechen. Nachdem die Metriken erfasst wurden, wird ein HTML-Bericht generiert und angezeigt.

CollectOverMetrics.ps1 -DatabaseAvailabilityGroup DAG1 -Database:"DB*" -GenerateHTMLReport -ShowHTMLReport

Die folgenden Beispiele veranschaulichen Möglichkeiten zum Filtern des HTML-Zusammenfassungsberichts. Im ersten wird der Parameter Database genutzt, der eine Liste mit Datenbanken verwendet. Der Zusammenfassungsbericht enthält anschließend nur Daten zu diesen Datenbanken. In den folgenden beiden Beispielen wird der Parameter ReportFilter verwendet. Im letzten Beispiel werden alle Standarddatenbanken herausgefiltert.

CollectOverMetrics -SummariseCsvFiles (dir *.csv) -Database MailboxDatabase123,MailboxDatabase456
CollectOverMetrics -SummariseCsvFiles (dir *.csv) -ReportFilter { $_.DatabaseName -notlike "Mailbox Database*" }
CollectOverMetrics -SummariseCsvFiles (dir *.csv) -ReportFilter { ($_.ActiveOnStart -like "ServerXYZ*") -and ($_.ActiveOnEnd -notlike "ServerXYZ*") }

Cmdlet "Get-MailboxDatabaseCopyStatus"

Skript "CollectReplicationMetrics.ps1"

Ein anderes in Exchange 2010 enthaltenes Skript für Statusmetriken ist CollectReplicationMetrics.ps1. Bei diesem Skript handelt es sich um eine aktive Form der Überwachung, da es Metriken in Echtzeit erfasst, während das Skript ausgeführt wird. CollectReplicationMetrics.ps1 erfasst Daten von Leistungsindikatoren im Zusammenhang mit der Datenbankreplikation. Das Skript erfasst Leistungsindikatordaten mehrerer Postfachserver, schreibt die Daten der einzelnen Server in eine CSV-Datei und kann anschließend verschiedene Statistiken anhand dieser Daten erstellen (z. B. den Zeitraum, den jede Kopie im Status "Fehler" oder "Angehalten" verbracht hat, die Durchschnittslänge der Kopie- oder Wiedergabewarteschlange oder die Dauer, in der Kopien sich außerhalb ihrer Failoverkriterien befunden haben).

Sie können entweder die Server einzeln oder ganze DAGs angeben. Sie können das Skript entweder ausführen, um die Daten zu erfassen und anschließend den Bericht zu erstellen, oder Sie können es ausführen, um nur Daten zu erfassen oder um nur einen Bericht zu Daten zu erstellen, die bereits erfasst wurden. Sie können die Häufigkeit angeben, mit der Daten erfasst werden sollen, und die Gesamtdauer der Datenerfassung bestimmen.

Die von jedem Server erfassten Daten werden in eine Datei mit dem Namen CounterData.<Servername>.<Zeitstempel>.csv geschrieben. Der Zusammenfassungsbericht wird in eine Datei mit dem Namen HaReplPerfReport.<Name der DAG>.<Zeitstempel>.csv oder HaReplPerfReport.<Zeitstempel>.csv geschrieben, wenn das Skript nicht mit dem Parameter DagName ausgeführt wurde.

Das Skript startet PowerShell-Aufträge zum Erfassen der Daten von jedem Server. Diese Aufträge werden für den gesamten Zeitraum ausgeführt, in dem Daten erfasst werden sollen. Wenn Sie eine große Anzahl von Servern angeben, kann dieser Prozess sehr viel Arbeitsspeicher belegen. Die letzte Phase des Prozesses, in denen die Daten zu einem Zusammenfassungsbericht verarbeitet werden, kann bei großen Datenmengen auch relativ zeitaufwendig sein. Es ist möglich, die Erfassungsphase auf einem Computer auszuführen und die Daten anschließend zur Verarbeitung auf einen anderen Computer zu kopieren.

Das Skript CollectReplicationMetrics.ps1 unterstützt Parameter, mit denen Sie das Verhalten und die Ausgabe des Skripts anpassen können. Die verfügbaren Parameter sind in der folgenden Tabelle aufgeführt:

Parameter des Skripts "CollectReplicationMetrics.ps1"

Parameter	Beschreibung
DagName	Gibt den Namen der DAG an, deren Metriken Sie erfassen möchten. Wird dieser Parameter ausgelassen, wird die DAG verwendet, welcher der lokale Server angehört.
DatabaseNames	Stellt eine Liste von Datenbanken bereit, für die der Bericht generiert werden soll. Platzhalterzeichen werden unterstützt, z. B. -DatabaseNames:"DB*" oder -DatabaseNames:"DB1","DB2".
ReportPath	Gibt den Ordner an, in dem die Ergebnisse der Ereignisverarbeitung gespeichert werden sollen. Wird dieser Parameter ausgelassen, wird der Ordner Scripts verwendet.
Duration	Gibt die Zeitspanne an, für die der Erfassungsvorgang ausgeführt werden soll. Typische Werte sind ein bis drei Stunden. Längere Zeiträume sollten nur bei längeren Intervallen zwischen jeder Erfassung verwendet werden. Möglich ist auch eine Folge kürzerer Aufträge, die als geplante Aufgaben ausgeführt werden.
Frequency	Gibt die Häufigkeit an, mit der Datenmetriken erfasst werden. Typische Werte sind 30 Sekunden, eine Minute oder fünf Minuten. Unter normalen Umständen werden bei kürzeren Intervallen als diesen keine wesentlichen Unterschiede zwischen den einzelnen Erfassungen deutlich.
Servers	Gibt die Identität der Server an, von denen Statistiken erfasst werden sollen. Sie können einen beliebigen Wert angeben, einschließlich Platzhalterzeichen und GUIDs.
SummariseFiles	Gibt eine Liste mit CSV-Dateien zum Generieren eines Zusammenfassungsberichts an. Diese Dateien heißen CounterData.<Leistungsindikatordaten>* und werden vom Skript CollectReplicationMetrics.ps1 erstellt.
Mode	Gibt die Verarbeitungsphasen an, die das Skript ausführt. Folgende Werte können verwendet werden: CollectAndReport   Dies ist der Standardwert. Dieser Wert bedeutet, dass das Skript Daten von den Servern erfassen und anschließend so verarbeiten soll, dass ein Zusammenfassungsbericht generiert wird. CollectOnly   Dieser Wert bedeutet, dass das Skript nur die Daten erfassen und keinen Bericht erstellen soll. ProcessOnly   Dieser Wert bedeutet, dass das Skript Daten aus verschiedenen CSV-Dateien importieren und anschließend so verarbeiten soll, dass ein Zusammenfassungsbericht generiert wird. Der Parameter SummariseFiles dient dazu, dem Skript die Liste mit den zu verarbeitenden Dateien bereitzustellen.
MoveFilestoArchive	Gibt an, dass das Skript die Dateien nach der Verarbeitung in einen komprimierten Ordner verschieben soll.
LoadExchangeSnapin	Gibt an, dass das Skript die Exchange-Verwaltungsshellbefehle laden soll. Dieser Parameter ist nützlich, wenn das Skript außerhalb der Exchange-Verwaltungsshell ausgeführt werden muss, z. B. in einer geplanten Aufgabe.

Beispiel für "CollectReplicationMetrics.ps1"

Im folgenden Beispiel werden Daten über eine Stunde von allen Servern in der DAG namens "DAG1" in einminütigen Abständen in einem Zusammenfassungsbericht erfasst. Darüber hinaus wird der Parameter ReportPath angegeben, der bewirkt, dass das Skript alle Dateien im aktuellen Verzeichnis ablegt.

CollectReplicationMetrics.ps1 -DagName DAG1 -Duration "01:00:00" -Frequency "00:01:00" -ReportPath

Im folgenden Beispiel werden Daten aus allen mit "CounterData*" übereinstimmenden Dateien gelesen und in einem Zusammenfassungsbericht ausgegeben.

CollectReplicationMetrics.ps1 -SummariseFiles (dir CounterData*) -Mode ProcessOnly -ReportPath

Cmdlet "Get-MailboxDatabaseCopyStatus"

Das Skript "CheckDatabaseRedundancy.ps1"

Wie sein Name schon sagt, besteht der Zweck des Skripts CheckDatabaseRedundancy.ps1 im Überwachen der Redundanz replizierter Postfachdatenbanken, indem überprüft wird, ob mindestens zwei konfigurierte und fehlerfreie aktuelle Kopien vorhanden sind, und im Benachrichtigen, wenn nur eine fehlerfreie Kopie einer replizierten Datenbank vorhanden ist. In diesem Fall werden zum Bestimmen von Redundanz sowohl aktive als auch passive Kopien gezählt.

Wenn die Postfachserverrolle installiert ist, wird das Skript CheckDatabaseRedundancy.ps1 automatisch von Exchange zur Ausführung als geplante Aufgabe Database One Copy Alert konfiguriert. Die geplante Aufgabe Database One Copy Alert wird standardmäßig alle 60 Minuten ausgeführt. Sie können dieses Verhalten und die Einstellungen für die geplante Aufgabe über den Windows-Taskplaner ändern. Das Skript überprüft zunächst die DAG-Mitgliedschaft. Wenn der Postfachserver kein DAG-Mitglied ist, wird das Skript sofort beendet.

Das Skript kann auch interaktiv über den Skriptordner ausgeführt werden. Beim interaktiven Ausführen des Skripts müssen Sie entweder den Namen einer Datenbank oder den Namen eines DAG-Mitglieds angeben. Mit dem Parameter MailboxDatabaseName geben Sie eine Datenbank und mit dem Parameter MailboxServerName das Mitglied einer DAG an. Bei interaktiver Ausführung in der Konsole führt das Skript die Redundanzprüfung nur einmal aus und gibt den aktuellen Status (rot oder grün) auf dem Bildschirm aus.

Im Gegensatz zu anderen Skripts und Cmdlets kann CheckDatabaseRedundancy.ps1 auch im Überwachungsmodus ausgeführt werden und Ergebnisse generieren, indem der Parameter MonitoringContext hinzugefügt wird. Die von Exchange geplante Aufgabe führt das Skript im Überwachungsmodus aus. Dieser Modus ermöglicht das Aufrufen des Skripts in einer Überwachungslösung wie Microsoft System Center Operations Manager (SCOM). Im Überwachungsmodus generiert das Skript rote und grüne Benachrichtigungsereignisse im Ereignisprotokoll Anwendung des lokalen Servers. Eine rote Benachrichtigung (Ereignis-ID 4113) wird generiert, wenn die Datenbank während der einstündigen Ausführung des Skripts länger als insgesamt 20 Minuten einen „roten“ Status hatte. Eine grüne Benachrichtigung (Ereignis-ID 4114) wird ausgelöst, wenn die Datenbank 10 Minuten hintereinander einen „grünen“ Status hatte. Sobald ein rotes Benachrichtigungsereignis generiert wurde, wird es standardmäßig alle 15 Minuten gemeldet.

Darüber hinaus bietet das Skript einige andere nützliche Optionen. Sie können beispielsweise den Parameter ShowDetailedErrors hinzufügen, um mehr Details zu den auftretenden Fehlern zu erfahren. Und Sie können den Parameter Verbose hinzufügen, um ausführlichere Problembehandlungsinformationen zu erhalten. Das Skript bietet auch den Parameter SendSummaryMailTos, der nach Abschluss der Skriptausführung das Senden eines Zusammenfassungsbericht per E-Mail an eine Empfängerliste mit angegebenen E-Mail-Adressen ermöglicht. Dies ermöglicht Administratoren das rasche Untersuchen der stündlichen Berichte, um zu prüfen, ob Redundanzprobleme aufgetreten sind. Bei Verwenden der E-Mail-Funktion müssen Sie den Parameter SummaryMailFrom angeben, wenn Sie den Parameter SendSummaryMailTos verwenden.

Microsoft empfiehlt die regelmäßige Ausführung dieses Skripts im Rahmen der normalen Betriebsüberwachung, entweder über die automatisierte geplante Aufgabe oder über ein Überwachungssystem wie SCOM. Um zu gewährleisten, dass keine längeren Zeiträume mit gefährdeter Datenbankredundanz auftreten, führen Sie das Skript alle 60 Minuten aus. Das Skript enthält den Parameter TerminateAfterDurationSecs, der bei Festlegung auf "-1" oder "0" während der Ausführung des Skripts verwendet werden kann, um das Skript unbegrenzt lange auszuführen.

Wenn Sie keine Überwachungslösung wie SCOM ausführen, sollten Sie die Automatisierung und Planung der Skriptausführung durch die automatisch erstellte geplante Aufgabe ermöglichen.

In der Windows Server 2008 SP2-Aufgabenplanung gibt es bekannte Fehler, die für einen Absturz der Aufgabenplanung sorgen können, wenn Sie eine Aufgabe mit langer Ausführungsdauer planen. In Windows Server 2008 R2 sind diese Probleme nicht bekannt. Führen Sie das Skript deshalb nach Möglichkeit in Windows Server 2008 R2 aus. Wenn Sie das Skript in Windows Server 2008 R2 nicht ausführen können und es in Windows Server 2008 SP2 ausführen, werden zwei Modifikationen empfohlen. Führen Sie erstens das Skript nicht mit der vordefinierten Ausführungsdauer von 60 Minuten, sondern unter Angabe der folgenden Parameter alle fünf Minuten aus:

CheckDatabaseRedundancy.ps1 -MonitoringContext -SleepDurationBetweenIterationsSecs:0 -TerminateAfterDurationSecs:1 -SuppressGreenEventForSecs:0 -ReportRedEventAfterDurationSecs:0 -ReportRedEventIntervalSecs:0 -ShowDetailedErrors

Verwenden Sie zweitens nach Möglichkeit SCOM zum Definieren des Ausführungsverhaltens (lösen Sie z. B. eine Benachrichtigung aus, wenn innerhalb eines 20-minütigen Zeitraums drei rote Benachrichtigungsereignisse protokolliert werden. Ändern Sie den aktuellen Status in Grün, wenn ein grünes Benachrichtigungsereignis protokolliert wird).

Wenn die geplante Aufgabe Database One Copy Alert geändert oder entfernt wird, können Sie über den folgenden Befehl einen Löschvorgang ausführen und eine neue geplante Aufgabe erstellen.

schtasks /create /TN "Check Database Redundancy" /TR "Powershell.exe -NonInteractive -WindowStyle Hidden -command 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; 'C:\Program Files\Microsoft\Exchange Server\V14\Scripts\CheckDatabaseRedundancy.ps1 -MonitoringContext -ShowDetailedErrors -SummaryMailFrom:'SMTPFromAddress@contoso.com' -SendSummaryMailTos:@('SMTPToAddress@contoso.com') -ErrorAction:Continue" /RU SYSTEM /SC HOURLY

Ersetzen Sie die Parameter im obigen Skript durch die gewünschten Skriptparameter. Im Skript sind zudem weitere Parameter für das Skript beschrieben.

Bei Verwenden des Befehlszeilentools schtasks zum Erstellen einer geplanten Aufgabe ist die Option /TR auf 261 Zeichen begrenzt. Im vorherigen Beispiel wird dieser Grenzwert überschritten. Wenn die verwendeten Parameter und Pfade bewirken, dass die Option /TR 261 Zeichen überschreitet, müssen Sie im Menü Option Verwaltung im Applet Aufgabenplanung die geplante Aufgabe manuell erstellen. Alternativ können Sie die folgende XML kopieren und in Editor einfügen, sie entsprechend bearbeiten, als XML-Datei speichern und mithilfe des Applets Aufgabenplanung importieren.

<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2" xmlns="https://schemas.microsoft.com/windows/2004/02/mit/task">
  <RegistrationInfo>
    <Date>2010-05-11T15:55:47</Date>
    <Author>administrator</Author>
  </RegistrationInfo>
  <Triggers>
    <TimeTrigger>
      <Repetition>
        <Interval>PT1H</Interval>
        <StopAtDurationEnd>false</StopAtDurationEnd>
      </Repetition>
      <StartBoundary>2010-05-11T15:55:00</StartBoundary>
      <Enabled>true</Enabled>
    </TimeTrigger>
  </Triggers>
  <Principals>
    <Principal id="Author">
      <UserId>SYSTEM</UserId>
      <RunLevel>HighestAvailable</RunLevel>
    </Principal>
  </Principals>
  <Settings>
    <IdleSettings>
      <Duration>PT10M</Duration>
      <WaitTimeout>PT1H</WaitTimeout>
      <StopOnIdleEnd>true</StopOnIdleEnd>
      <RestartOnIdle>false</RestartOnIdle>
    </IdleSettings>
    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
    <DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries>
    <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
    <AllowHardTerminate>true</AllowHardTerminate>
    <StartWhenAvailable>false</StartWhenAvailable>
    <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
    <AllowStartOnDemand>true</AllowStartOnDemand>
    <Enabled>true</Enabled>
    <Hidden>false</Hidden>
    <RunOnlyIfIdle>false</RunOnlyIfIdle>
    <WakeToRun>false</WakeToRun>
    <ExecutionTimeLimit>PT72H</ExecutionTimeLimit>
    <Priority>7</Priority>
  </Settings>
  <Actions Context="Author">
    <Exec>
      <Command>Powershell.exe</Command>
      <Arguments>-NonInteractive -WindowStyle Hidden -command 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; C:\Operations\CheckDatabaseRedundancy.ps1 -MonitoringContext -ShowDetailedErrors -SummaryMailFrom:'SMTPFromAddress@contoso.com' -SendSummaryMailTos:@('SMTPToAddress@contoso.com') -ErrorAction:Continue</Arguments>
    </Exec>
  </Actions>
</Task>

Cmdlet "Get-MailboxDatabaseCopyStatus"

 © 2010 Microsoft Corporation. Alle Rechte vorbehalten.