Überwachen von hoher Verfügbarkeit und Ausfallsicherheit für Standorte
Gilt für: Exchange Server 2010
Letztes Änderungsdatum des Themas: 2010-01-11
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
Innerhalb einer Exchange 2010-Organisation sollten die für den Betrieb relevanten Verfahren, Rollen und Zuständigkeiten formalisiert werden. Es ist wichtig, sich den Zusammenhang zwischen soliden Betriebsmethoden und -verfahren und einer stabilen Infrastruktur zu verdeutlichen. 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 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. Außer 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 werden können.
Sie können die Informationen in diesem Thema verwenden, um die Integrität und den Status von Postfachdatenbankkopien für Datenbankverfügbarkeitsgruppen zu überwachen. Allgemeine Informationen zur Überwachung von Exchange 2010 finden Sie unter Überwachen von Exchange 2010.
Inhalt
Cmdlet "Get-MailboxDatabaseCopyStatus"
Cmdlet "Test-ReplicationHealth"
Crimson-Kanal-Ereignisprotokollierung
Skript "CollectOverMetrics.ps1"
Skript "CollectReplicationMetrics.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 Angehalten, ServiceDown, Fehler, Seeding, SinglePageRestore, LostWrite oder Getrennt 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 Datenbankverfügbarkeitsgruppe 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 Datenbankverfügbarkeitsgruppe 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. |
ActivationSuspended |
Die Aktivierung der Postfachdatenbankkopie wurde manuell von einem Administrator blockiert. |
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.
Nach oben
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 Datenbankverfügbarkeitsgruppe 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 der Integrität und des Status des zugrunde liegenden Clusterdiensts, Quorums und der zugrunde liegenden Netzwerkkomponenten entwickelt. Es kann lokal oder remote für jeden Postfachserver in einer Datenbankverfügbarkeitsgruppe 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 Datenbankverfügbarkeitsgruppe bzw., wenn kein Mitglied der Datenbankverfügbarkeitsgruppe 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 Datenbankverfügbarkeitsgruppe bzw., wenn kein Mitglied der Datenbankverfügbarkeitsgruppe angegeben ist, auf dem lokalen Server erreichbar ist. |
ActiveManager |
Überprüft, ob die auf dem angegebenen Mitglied der Datenbankverfügbarkeitsgruppe (bzw., wenn kein Mitglied der Datenbankverfügbarkeitsgruppe 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 Datenbankverfügbarkeitsgruppe bzw., wenn kein Mitglied der Datenbankverfügbarkeitsgruppe angegeben ist, auf dem lokalen Server erreichbar ist. |
TcpListener |
Überprüft, ob der TCP-Protokollkopielistener ausgeführt wird und auf dem angegebenen Mitglied der Datenbankverfügbarkeitsgruppe bzw., wenn kein Mitglied der Datenbankverfügbarkeitsgruppe angegeben ist, auf dem lokalen Server erreichbar ist. |
DagMembersUp |
Überprüft, ob alle Mitglieder der Datenbankverfügbarkeitsgruppe verfügbar sind, ausgeführt werden und erreichbar sind. |
ClusterNetwork |
Überprüft, ob alle clusterverwalteten Netzwerke auf dem angegebenen Mitglied der Datenbankverfügbarkeitsgruppe (bzw., wenn kein Mitglied der Datenbankverfügbarkeitsgruppe 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 Datenbankverfügbarkeitsgruppe konfigurierte Zeugenserver sowie das Zeugenverzeichnis und die Zeugenfreigabe erreichbar sind. |
DBCopySuspended |
Prüft, ob sich Postfachdatenbankkopien auf dem angegebenen Mitglied der Datenbankverfügbarkeitsgruppe bzw., wenn kein Mitglied der Datenbankverfügbarkeitsgruppe angegeben ist, auf dem lokalen Server im Zustand Angehalten befinden. |
DBCopyFailed |
Prüft, ob sich Postfachdatenbankkopien auf dem angegebenen Mitglied der Datenbankverfügbarkeitsgruppe bzw., wenn kein Mitglied der Datenbankverfügbarkeitsgruppe angegeben ist, auf dem lokalen Server im Zustand Fehler befinden. |
DBInitializing |
Prüft, ob sich Postfachdatenbankkopien auf dem angegebenen Mitglied der Datenbankverfügbarkeitsgruppe bzw., wenn kein Mitglied der Datenbankverfügbarkeitsgruppe angegeben ist, auf dem lokalen Server im Zustand Initialisieren befinden. |
DBDisconnected |
Prüft, ob sich Postfachdatenbankkopien auf dem angegebenen Mitglied der Datenbankverfügbarkeitsgruppe bzw., wenn kein Mitglied der Datenbankverfügbarkeitsgruppe 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 Datenbankverfügbarkeitsgruppe (bzw., wenn kein Mitglied der Datenbankverfügbarkeitsgruppe 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 Datenbankverfügbarkeitsgruppe (bzw., wenn kein Mitglied der Datenbankverfügbarkeitsgruppe 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 der Replikationsintegrität für den Postfachserver "MBX1" verwendet.
Test-ReplicationHealth -Identity MBX1
Nach oben
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:
- Öffnen Sie die Ereignisanzeige.
- Navigieren Sie in der Konsolenstruktur zu Anwendungs- und Dienstprotokolle > Microsoft > Exchange.
- 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 Datenbankverfügbarkeitsgruppe.
Der Kanal MailboxDatabaseFailureItems wird zum Protokollieren von Ereignissen im Zusammenhang mit Fehlern verwendet, die sich auf eine replizierte Postfachdatenbank auswirken.
Nach oben
Skript "CollectOverMetrics.ps1"
Exchange 2010 umfasst ein Skript namens CollectOverMetrics.ps1, das im Ordner Scripts gespeichert ist. Hierbei handelt es sich um ein Workflowskript, das Informationen über verschiedene switchover- und failoverbezogene Statistiken erfasst. Die Verwendung des Skripts CollectOverMetrics.ps1 ist eine passive Form der Überwachung. Das Skript erfasst und analysiert Ereignisse, die bereits aufgezeichnet wurden. Es 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 "CollectOverMetrics.ps1"
| Parameter | Beschreibung |
|---|---|
DatabaseAvailabilityGroup |
Gibt den Namen der Datenbankverfügbarkeitsgruppe an, deren Metriken Sie erfassen möchten. Wird dieser Parameter ausgelassen, wird die Datenbankverfügbarkeitsgruppe verwendet, welcher der lokale Server angehört. |
Database |
Stellt eine Liste von Datenbanken bereit, für die der Bericht generiert werden soll. Platzhalterzeichen werden unterstützt, z. B. |
TemporaryDataPath |
Gibt den Speicherort zum Speichern temporärer Dateien an. Wird dieser Parameter ausgelassen, lautet der Verzeichnisname folgendermaßen: %SystemDrive%\Temp\CollectOverMetrics\<Skript_Startzeit> |
StartTime |
Gibt den Zeitpunkt an, zu dem die Erfassung von Ereignisdaten beginnt. Wird dieser Parameter ausgelassen, lautet der Startzeitpunkt 00:00 Uhr (Mitternacht) des vorherigen Tages. |
EndTime |
Gibt den Zeitpunkt an, zu dem die Erfassung der Ereignisdaten beendet wird. Wird dieser Parameter ausgelassen, werden Ereignisse bis 23:59 Uhr des vorherigen Tages erfasst. |
ReportPath |
Gibt den Ordner an, in dem die Ergebnisse der Ereignisverarbeitung gespeichert werden sollen. Wird dieser Parameter ausgelassen, wird der Ordner Scripts verwendet. |
ReportAlias |
Gibt den E-Mail-Alias an, an den der Bericht gesendet werden soll. |
IncludeAppLogs |
Gibt an, ob Ereignisse im Anwendungsereignisprotokoll ebenfalls erfasst, zusammengeführt und verarbeitet werden sollen. Standardmäßig werden die folgenden Anbieter berücksichtigt: MSExchangeIS, MSExchangeIS-Postfachspeicher und MSExchangeRepl. |
AppLogProviders |
Gibt an, ob bestimmte Ereignisse im Anwendungsereignisprotokoll erfasst werden sollen. Wird dieser Parameter festgelegt, werden die für IncludeAppLogs aufgeführten Anbieter nicht berücksichtigt und müssen explizit über den Parameter AppLogProviders angegeben werden. |
AnalyzeOnly |
Gibt an, dass die Daten bereits erfasst wurden und nur noch verarbeitet werden müssen. |
MergedXmlFile |
Gibt den Namen der XML-Datei an, in der alle erfassten Ereignisprotokolleinträge zusammengeführt werden. |
GenerateHtmlReport |
Gibt an, dass der Bericht zur übersichtlichen Anzeige in einfachem HTML-Tabellenformat ausgegeben werden soll. |
ShowHtmlReport |
Gibt an, dass der in HTML generierte Bericht anschließend in einem Webbrowser angezeigt werden soll. |
DotSourceMode |
Gibt an, dass die Befehle nicht sofort ausgeführt werden müssen, sondern dass diese Datei mit Punktbefehl zur Verwendung der darin definierten Windows-PowerShell-Methoden ausgeführt wird. |
Beispiele für "CollectOverMetrics.ps1"
In den folgenden Beispielen wird das Skript CollectOverMetrics.ps1 verwendet.
In diesem Beispiel werden Metriken für alle Datenbanken erfasst, die "DB*" (mit Platzhalterzeichen) in der Datenbankverfügbarkeitsgruppe "DAG1" entsprechen. Nachdem die Metriken erfasst wurden, wird ein HTML-Bericht generiert und angezeigt.
CollectOverMetrics.ps1 -DatabaseAvailabilityGroup DAG1 -Database:"DB*" -GenerateHTMLReport -ShowHTMLReport
In diesem Beispiel werden Metriken für alle Datenbanken in der Datenbankverfügbarkeitsgruppe "DAG2" erfasst. Nachdem die Metriken erfasst wurden, wird ein HTML-Bericht generiert und angezeigt.
CollectOverMetrics.ps1 -DatabaseAvailabilityGroup DAG2 -GenerateHTMLReport -ShowHTMLReport
Nach oben
Skript "CollectReplicationMetrics.ps1"
Ein anderes in Exchange 2010 enthaltenes Skript für Integritätsmetriken 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. Es 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 Datenbankverfügbarkeitsgruppe an, deren Metriken Sie erfassen möchten. Wird dieser Parameter ausgelassen, wird die Datenbankverfügbarkeitsgruppe 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. |
ReportAlias |
Gibt einen E-Mail-Alias an, an den der Bericht gesendet werden soll. |
TemporaryDataPath |
Gibt den Speicherort zum Speichern temporärer Dateien an. Wird dieser Parameter ausgelassen, lautet der Verzeichnisname folgendermaßen: %SystemDrive%\Temp\CollectReplicationMetrics\<Skript_Startzeit> |
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. |
Frequency |
Gibt die Häufigkeit an, mit der Datenmetriken gesammelt werden. |
Verbose |
Zeigt die Taskausgabe auf dem Bildschirm an, sobald der Task abgeschlossen ist. |
ProcessOnly |
Gibt an, dass die Daten bereits erfasst wurden und nur noch verarbeitet werden müssen. |
Beispiel für "CollectReplicationMetrics.ps1"
Im folgenden Beispiel wird das Skript "CollectReplicationMetrics.ps1" verwendet.
In diesem Beispiel werden Metriken für alle Datenbanken in der Datenbankverfügbarkeitsgruppe "DAG1" erfasst. Die erfassten Daten werden in einem Bericht auf dem Bildschirm angezeigt.
CollectReplicationMetrics.ps1 -DagName DAG1 -Verbose
Nach oben