Verwaltete Verfügbarkeit

Gilt für: Exchange Server 2013 SP1

Die Hauptaufgabe der Administratoren eines Messagingsystems besteht darin, Benutzern eine reibungslose E-Mail-Erfahrung zu ermöglichen. Um die Verfügbarkeit und Zuverlässigkeit Ihrer Microsoft Exchange Server 2013-Organisation sicherzustellen, müssen alle Aspekte des Systems aktiv überwacht werden, und alle erkannten Probleme müssen schnell behoben werden. In früheren Versionen von Exchange wurden wichtige Systemkomponenten in der Regel mithilfe einer externen Anwendung wie Microsoft System Center 2012 Operations Manager überwacht, um Daten zu sammeln und Wiederherstellungsaktionen für Probleme bereitzustellen, die als Ergebnis der Analyse der gesammelten Daten erkannt wurden. Exchange 2010 und frühere Versionen enthielten Integritätsmanifeste und Korrelations-Engines in Form von Management Packs. Mit diesen Komponenten konnte Operations Manager bestimmen, ob eine bestimmte Komponente fehlerfrei oder fehlerhaft war. Darüber hinaus hat Operations Manager auch die in Exchange 2010 integrierte Diagnose-Cmdlet-Infrastruktur verwendet, um synthetische Transaktionen für verschiedene Aspekte des Systems auszuführen.

Exchange 2013 verfolgt einen neuen Ansatz zur Überwachung und Aufrechterhaltung der Endbenutzererfahrung nativ mithilfe eines Features namens Verwaltete Verfügbarkeit , das integrierte Überwachungs- und Wiederherstellungsaktionen bereitstellt.

Die verwaltete Verfügbarkeit, auch als Aktive Überwachung oder lokale aktive Überwachung bezeichnet, ist die Integration integrierter Überwachungs- und Wiederherstellungsaktionen in die Exchange-Hochverfügbarkeitsplattform. Sie ist dafür vorgesehen, vom System erkannte Probleme sofort zu ermitteln und zu beheben. Im Gegensatz zu früheren externen Überwachungslösungen und -techniken für Exchange versucht die verwaltete Verfügbarkeit nicht, die eigentliche Ursache eines Problems zu ermitteln oder zu kommunizieren. Sie konzentriert sich stattdessen auf Wiederherstellungsaspekte, die drei zentrale Benutzerfragen adressieren:

• Verfügbarkeit: Können Benutzer auf den Dienst zugreifen?
• Latenz: Wie ist die Erfahrung für Benutzer?
• Fehler: Können Benutzer erreichen, was sie wollen?

Die Serverrollenkonsolidierung und andere Architekturänderungen in Exchange 2013 erfordern einen neuen Ansatz für die Überwachungsmethoden und das Integritätsmodell, die in früheren Versionen von Exchange verwendet wurden. Die verwaltete Verfügbarkeit ist darauf ausgelegt, diese Änderungen zu beheben, indem eine systemeigene Lösung zur Überwachung und Wiederherstellung der Integrität bereitgestellt wird. Es geht weg von der Überwachung einzelner separater Segmente des Systems, um die End-to-End-Benutzererfahrung zu überwachen und die Endbenutzererfahrung durch wiederherstellungsorientierte Aktionen zu schützen.

Verwaltete Verfügbarkeit ist ein interner Prozess, der auf jedem Exchange 2013-Server ausgeführt wird. Dabei werden in jeder Sekunde Hunderte von Integritätsmetriken abgerufen. Wenn Fehler erkannt werden, können diese meist automatisch behoben werden. Es wird jedoch auch immer Probleme geben, die von der verwalteten Verfügbarkeit nicht direkt gelöst werden können. In diesen Fällen wird das Problem durch Ereignisprotokollierung an einen Administrator weitergeleitet.

Die verwaltete Verfügbarkeit wird in Form von zwei Diensten implementiert:

• Exchange Health Manager Service (MSExchangeHMHost.exe):Dieser Dienst ist ein Controllerprozess, der zum Verwalten von Arbeitsprozessen verwendet wird. Es wird verwendet, um den Arbeitsprozess nach Bedarf zu erstellen, auszuführen und zu starten und zu beenden. Es wird auch verwendet, um den Arbeitsprozess im Falle eines Fehlers wiederherzustellen, um zu verhindern, dass der Arbeitsprozess ein Single Point of Failure ist.

• Exchange Health Manager Worker process (MSExchangeHMWorker.exe): Dieser Dienst ist der Arbeitsprozess, der für die Ausführung von Laufzeitaufgaben innerhalb des verwalteten Verfügbarkeitsframeworks verantwortlich ist.

Bei der verwalteten Verfügbarkeit wird ein beständiger Speicher verwendet, um die zugehörigen Funktionen auszuführen:

• In den XML-Dateien im Ordner "\bin\Monitoring\config" werden Konfigurationseinstellungen für einige der Test- und Überwachungsarbeitsaufgaben gespeichert.
• Active Directory wird zum Speichern globaler Außerkraftsetzungen verwendet.
• Die Windows-Registrierung wird zum Speichern von Laufzeitdaten, wie z. B. Lesezeichen, und lokalen (serverspezifischen) Außerkraftsetzungen verwendet.
• Die Windows-Crimson-Kanal-Ereignisprotokollinfrastruktur wird zum Speichern der Arbeitselementergebnisse verwendet.
• Integritätspostfächer werden für Prüfaktivitäten verwendet. In jeder Postfachdatenbank auf dem Server werden mehrere Integritätspostfächer erstellt.

Wie in der folgenden Abbildung veranschaulicht, umfasst die verwaltete Verfügbarkeit drei zentrale asynchrone Komponenten, die permanent aktiv sind.

Die erste Komponente wird Testmodul genannt. Testmodule sind für die Durchführung von Messungen auf dem Server und für das Sammeln von Daten verantwortlich. Die Ergebnisse dieser Messungen fließen in die zweite Komponente, den Monitor, ein. Der Monitor enthält die gesamte Geschäftslogik, die vom System basierend darauf verwendet wird, was für die gesammelten Daten als fehlerfrei gilt. Ähnlich wie bei einer Mustererkennungs-Engine sucht der Monitor bei allen gesammelten Messungen nach den verschiedenen Mustern und entscheidet dann, ob etwas als fehlerfrei gilt. Schließlich gibt es Responders, die für Wiederherstellungs- und Eskalationsaktionen verantwortlich sind. Wenn etwas fehlerhaft ist, besteht die erste Aktion darin, diese Komponente wiederherzustellen. Dieser Wiederherstellungsaufwand kann mehrstufige Wiederherstellungsaktionen umfassen. Der erste Versuch kann beispielsweise darin bestehen, den Anwendungspool neu zu starten, der zweite kann darin bestehen, den Dienst neu zu starten, der dritte Versuch kann darin bestehen, den Server neu zu starten, und der nachfolgende Versuch kann darin bestehen, den Server offline zu schalten, damit er keinen Datenverkehr mehr akzeptiert. Wenn die Wiederherstellungsaktionen nicht erfolgreich sind, eskaliert das System das Problem über Ereignisprotokollbenachrichtigungen an einen Menschen.

Es existieren drei wesentliche Testtypen: wiederkehrende Tests, Benachrichtigungen und Prüfungen. Wiederkehrende Tests sind synthetische Transaktionen, die vom System zum Testen der umfassenden Benutzerfreundlichkeit ausgeführt werden. Überprüfungen sind die Infrastruktur, die die Sammlung von Leistungsdaten durchführt, einschließlich Benutzerdatenverkehr, und messen die gesammelten Daten anhand von Schwellenwerten, die festgelegt sind, um Spitzen bei Benutzerfehlern zu ermitteln. Diese Messfunktion ermöglicht es der Prüfinfrastruktur, sich bewusst zu werden, wenn Benutzer Probleme haben. Schließlich ermöglicht die Benachrichtigungslogik dem System, sofort auf der Grundlage eines kritischen Ereignisses Maßnahmen zu ergreifen, ohne auf die Ergebnisse der von einem Test gesammelten Daten warten zu müssen. Diese Ausnahmen oder Bedingungen können ohne großen Stichprobensatz erkannt und erkannt werden.

Wiederkehrende Tests werden alle paar Minuten ausgeführt und überprüfen einige Aspekte der Dienstintegrität. In diesen Tests kann über Exchange ActiveSync eine E-Mail an ein Überwachungspostfach gesendet werden, sie können zur Verbindung mit einem RPC-Endpunkt dienen, oder sie können die Konnektivität für Clientzugriffe auf die Mailbox prüfen.

Alle Tests werden beim Starten des Health Manager-Diensts im crimson-Kanal Microsoft.Exchange.ActiveMonitoring\ProbeDefinition definiert. Jede Testdefinition verfügt über viele Eigenschaften, aber die relevantesten Eigenschaften sind:

• Name: Der Name des Tests, der mit einer SampleMask des Monitors des Tests beginnt.
• TypeName: Der Codeobjekttyp des Tests, der die Logik des Tests enthält.
• ServiceName: Der Name des Integritätssatzes, der diesen Test enthält.
• TargetResource: Das Objekt, das der Test überprüft. Dieser Eigenschaftsname wird an den Namen des Tests angefügt, wenn er ausgeführt wird, um ein Testergebnis ResultName zu werden.
• RecurrenceIntervalSeconds: Gibt an, wie oft der Test ausgeführt wird.
• TimeoutSeconds: Gibt an, wie lange der Test wartet, bevor ein Fehler auftritt.

Es gibt Hunderte von wiederkehrenden Tests. Viele dieser Tests sind datenbankbezogen. Wenn also die Anzahl der Datenbanken sich erhöht, gibt es auch immer mehr Tests, Die meisten dieser Tests werden im Code definiert und sind deshalb nicht direkt erkennbar.

Ein wiederkehrender Test wird auf folgender Grundlage durchgeführt: Er wird alle RecurrenceIntervalSeconds neu gestartet und prüft einige Aspekte der Dienstintegrität. Wenn die betreffende Komponente intakt ist, ist der Test bestanden, und es wird ein Informationsereignis mit dem ResultType 3 an den Kanal Microsoft.Exchange.ActiveMonitoring\ProbeResult gesendet. Wenn die Prüfung fehlschlägt oder eine Zeitüberschreitung auftritt, wird ein Fehlerereignis an denselben Kanal gesendet. Ein ResultType von 4 bedeutet, dass die Überprüfung fehlgeschlagen ist, und ein ResultType von 1 bedeutet, dass ein Timeout aufgetreten ist. Viele Tests werden bei einem Timeout erneut ausgeführt, bis zum Wert der MaxRetryAttempts-Eigenschaft .

Hinweis

Der Crimson-Kanal ProbeResult kann mit Hunderten von Tests, die alle paar Minuten laufen, sowie mit der Protokollierung der entsprechenden Ereignisse sehr beschäftigt sein, so dass sich eine deutliche Auswirkung auf die Leistung Ihres Exchange-Servers ergeben kann, wenn Sie in einer Produktumgebung umfassende Abfragen der Ereignisprotokolle durchführen.

Benachrichtigungen sind Tests, die nicht durch das Framework des Integritätsdiensts, sondern durch andere Dienste auf dem Server durchgeführt werden. Diese Dienste führen ihre eigene Überwachung durch und stellen ihre Daten im Framework für verwaltete Verfügbarkeit bereit, indem Sie die Testergebnisse direkt in dieses schreiben. Diese Tests werden im TestDefinition-Kanal nicht angezeigt, da dieser Kanal nur Tests beschreibt, die vom Managed Availability Framework ausgeführt werden. Der Monitor ServerOneCopyMonitor wird z.B. nur durch Testergebnisse ausgelöst, die vom Dienst MSExchangeDAGMgmt geschrieben werden. Dieser Dienst führt seine eigene Überwachung durch, ermittelt, ob ein Problem vorliegt, und protokolliert das Testergebnis. Die meisten Benachrichtigungstests verfügen über die Kapazität, sowohl rote Ereignisse, die auf eine Fehlerhaftigkeit des Monitors hinweisen, als auch grüne Ereignisse anzuzeigen, mit denen der betreffende Monitorfehler behoben wird.

Prüfungen sind Tests, bei denen Ereignisse nur protokolliert werden, wenn der Leistungsindikator einen bestimmten Schwellenwert über- oder unterschreitet. Diese sind ein wirklich spezieller Fall von Benachrichtigungstest, da ein Dienst die Leistungsindikatoren auf dem Server überwacht und Ereignisse in den Kanal ProbeResult protokolliert, wenn der konfigurierte Schwellenwert erreicht wird.

Um den Indikator und den Schwellenwert zu finden, der als fehlerhaft betrachtet wird, können Sie für diese Prüfung auf den Monitor schauen. Monitore vom Typ Microsoft.Office.Datacenter.ActiveMonitoring.OverallConsecutiveSampleValueAboveThresholdMonitor oder Microsoft.Office.Datacenter.ActiveMonitoring.OverallConsecutiveSampleValueBelowThresholdMonitor bedeuten, dass der überwachte Test ein Überprüfungstest ist.

Überwacht die von Tests gesammelten Daten, um zu ermitteln, ob eine Aktion basierend auf einem vordefinierten Regelsatz ausgeführt werden muss. In Abhängigkeit von der Regel oder der Art des Problems kann ein Monitor entweder einen Responder initiieren oder das Problem über einen Ereignisprotokolleintrag an eine Person weiterleiten. Darüber hinaus definieren Monitore, wie lange nach einem Fehler ein Responder ausgeführt wird, und den Workflow der Wiederherstellungsaktion. Monitore können verschiedene Zustände aufweisen. Aus Sicht des Systemstatus verfügen Monitore über zwei Zustände:

• Fehlerfrei: Der Monitor funktioniert ordnungsgemäß, und alle gesammelten Metriken liegen innerhalb der normalen Betriebsparameter.
• Fehlerhaft: Der Monitor ist nicht fehlerfrei und hat entweder die Wiederherstellung über einen Responder initiiert oder einen Administrator durch Eskalation benachrichtigt.

Aus administrativer Sicht weisen Monitore viele weitere Zustände auf, die in der Shell angezeigt werden:

• Heruntergestuft: Wenn sich ein Monitor in einem fehlerhaften Zustand von 0 bis 60 Sekunden befindet, wird er als heruntergestuft betrachtet. Wenn sich der Monitor für mehr als 60 Sekunden im Zustand "Fehlerhaft" befindet, wird er als "Fehlerhaft" betrachtet.
• Deaktiviert: Der Monitor wurde von einem Administrator explizit deaktiviert.
• Nicht verfügbar: Der Microsoft Exchange-Integritätsdienst fragt jeden Monitor in regelmäßigen Abständen nach seinem Status ab. Wenn er auf die Abfrage keine Antwort erhält, ändert sich der Zustand des Monitors in "Nicht verfügbar".
• Reparieren: Ein Administrator legt den Reparaturstatus fest, um dem System anzuzeigen, dass eine Korrekturmaßnahme von einem Menschen ausgeführt wird, wodurch das System und der Mensch zwischen anderen Fehlern unterscheiden können, die gleichzeitig auftreten können, wenn Korrekturmaßnahmen ausgeführt werden (z. B. ein Datenbankkopien-Erneuteinsetzungsvorgang).

Jeder Monitor verfügt über eine SampleMask-Eigenschaft in der Definition. Wenn der Monitor ausgeführt wird, sucht er nach Ereignissen im TestResult-Kanal, die einen ResultName aufweisen, der der SampleMask des Monitors entspricht. Diese Ereignisse können aus wiederkehrenden Tests, Benachrichtigungen oder Prüfungen stammen. Wenn die Schwellenwerte des Monitors erreicht werden, wird Fehlerhaftigkeit festgestellt. Aus der Perspektive des Monitors sind die Testtypen gleich, da sie alle Protokolle in den Kanal ProbeResult schreiben.

Bitte beachten Sie, dass das Fehlschlagen nur eines Tests nicht notwendigerweise bedeutet, dass mit dem Server etwas nicht in Ordnung ist. Die Monitore sind dafür entwickelt worden, echte Probleme, die dringenden behoben werden müssen, korrekt zu identifizieren. Daher weisen viele Monitore Schwellenwerte für mehrere Testfehler auf, bevor sie fehlerhaft werden. Aber dennoch können viele dieser Probleme automatisch durch Antwortsender behoben werden, sodass der Crimson-Kanal Microsoft.Exchange.ManagedAvailability\Monitoring der beste Platz für die Suche nach Problemen ist, die eine manuelle Behebung erfordern. Dieser Kanal enthält den letzten Testfehler.

Wie der Name schon sagt, führen Responder eine Art Antwort auf eine Warnung aus, die von einem Monitor generiert wurde. Responder führen verschiedene Wiederherstellungsaktionen aus, z. B. das Zurücksetzen eines Anwendungs-Workerpools auf den Neustart eines Servers. Es gibt verschiedene Arten von Respondern:

• Responder neu starten: Beendet und startet einen Dienst neu.
• AppPool-Antwortdienst zurücksetzen: Beendet und startet einen Anwendungspool in Internetinformationsdienste (IIS) neu.
• Failover Responder: Initiiert ein Datenbank- oder Serverfailover
• Bugcheck Responder: Initiiert eine Fehlerüberprüfung des Servers, wodurch ein Serverneustart verursacht wird.
• Offline Responder: Nimmt ein Protokoll auf einem Server außer Betrieb (lehnt Clientanforderungen ab)
• Online Responder: Platziert ein Protokoll auf einem Server wieder in die Produktion (akzeptiert Clientanforderungen)
• Eskalierender Responder: Eskaliert das Problem über die Ereignisprotokollierung an einen Administrator

Zusätzlich zu den aufgeführten Respondern verfügen einige Komponenten über eigene, spezialisierte Responder.

Alle Antwortenden enthalten das Drosselungsverhalten, das einen integrierten Sequenzierungsmechanismus zum Steuern von Reaktionsaktionen bereitstellt. Durch dieses Einschränkungsverhalten soll verhindert werden, dass das System aufgrund von Wiederherstellungsaktionen des Responders beschädigt oder beeinträchtigt wird. Alle Responder werden in irgendeiner Weise eingeschränkt. Wenn eine Einschränkung auftritt, kann die Wiederherstellungsaktion des Responders je nach Aktion entweder übersprungen oder verzögert werden. Beispielsweise wird bei einer Einschränkung des Fehlerprüfungs-Responders die Aktion übersprungen und nicht verzögert.

Integritätssätze

Bezüglich der Berichterstellung umfasst die verwaltete Verfügbarkeit zwei Ansichten der Integrität: eine interne und eine externe. Die interne Ansicht verwendet Integritätssätze. Jede Komponente in Exchange 2013 (z. B. Outlook Web App, Exchange ActiveSync, informationsspeicherdienst, Inhaltsindizierung, Transportdienste usw.) wird durch verwaltete Verfügbarkeit mithilfe von Tests, Monitoren und Antworten überwacht. Eine Gruppe von Tests, Monitoren und Antworten für eine bestimmte Komponente wird als Integritätssatz bezeichnet. Ein Integritätssatz ist eine Gruppe von Tests, Monitoren und Antwortern, die bestimmen, ob diese Komponente fehlerfrei ist. Der aktuelle Zustand eines Integritätssatzes (z. B. ob er fehlerfrei oder fehlerhaft ist) wird mithilfe des Zustands der Monitore des Integritätssatzes bestimmt. Wenn alle Monitore eines Integritätssatzes fehlerfrei sind, befindet sich der Integritätssatz in einem fehlerfreien Zustand. Wenn sich ein Monitor nicht in einem fehlerfreien Zustand befindet, wird der Zustand des Integritätssatzes durch den am wenigsten fehlerfreien Monitor bestimmt.

Detaillierte Anweisungen zum Anzeigen des Status der Serverintegrität oder des Integritätssatzes finden Sie unter Manage health sets and server health.

Integritätsgruppen

Die externe Ansicht der verwalteten Verfügbarkeit besteht aus Integritätsgruppen. Integritätsgruppen werden für System Center Operations Manager 2007 R2 und System Center Operations Manager 2012 verfügbar gemacht.

Es gibt vier primäre Integritätsgruppen:

• Kundentouchpunkte: Komponenten, die sich auf Benutzerinteraktionen in Echtzeit auswirken, z. B. Protokolle oder den Informationsspeicher
• Dienstkomponenten: Komponenten ohne direkte Benutzerinteraktionen in Echtzeit, z. B. der Microsoft Exchange-Postfachreplikationsdienst oder der Offlineadressbuchgenerierungsprozess (OABGen)
• Serverkomponenten: Die physischen Ressourcen des Servers, z. B. Speicherplatz, Arbeitsspeicher und Netzwerk
• Abhängigkeitsverfügbarkeit: Die Fähigkeit des Servers, auf erforderliche Abhängigkeiten wie Active Directory, DNS usw. zuzugreifen.

Wenn das Exchange Management Pack installiert ist, dient System Center Operations Manager (SCOM) als Integritätsportal zum Anzeigen von Informationen bezüglich der Exchange-Umgebung. Das SCOM-Dashboard enthält drei Ansichten der Exchange-Serverintegrität:

• Aktive Warnungen: Eskalationsantworter schreiben Ereignisse in das Windows-Ereignisprotokoll, die vom Monitor in SCOM verwendet werden. Diese Ereignisse werden in der Ansicht Aktive Warnungen als Warnungen angezeigt.
• Organisationsintegrität: In dieser Ansicht wird eine Rollupzusammenfassung der Gesamtintegrität der Exchange-Organisation angezeigt. Diese Rollups enthalten Anzeigen der Integrität für einzelne Datenbank-Verfügbarkeitsgruppen und für bestimmte Active Directory-Standorte.
• Serverintegrität: Verwandte Integritätssätze werden in Integritätsgruppen kombiniert und in dieser Ansicht zusammengefasst.

Außerkraftsetzungen

Außerkraftsetzungen ermöglichen es einem Administrator, einige Aspekte der Tests, Monitore und Responder für die verwaltete Verfügbarkeit zu konfigurieren. Mit Außerkraftsetzungen können einige der von der verwalteten Verfügbarkeit verwendeten Schwellenwerte angepasst werden. Zudem können hiermit Notfallaktionen für unerwartete Ereignisse aktiviert werden, die andere Konfigurationseinstellungen als die Standardvorgaben erfordern.

Außerkraftsetzungen können erstellt und auf einen einzelnen Server angewendet werden (dieser Prozess wird als Serverüberschreibung bezeichnet), oder sie können auf eine Gruppe von Servern angewendet werden (dieser Prozess wird als globale Außerkraftsetzung bezeichnet). Konfigurationsdaten für Serveraußerkraftsetzungen werden in der Windows-Registrierung auf dem Server gespeichert, auf dem die Außerkraftsetzung angewendet wird. Konfigurationsdaten für globale Außerkraftsetzungen werden in Active Directory gespeichert.

Außerkraftsetzungen können für eine unendliche oder für eine beschränkte Dauer konfiguriert werden. Zudem können globale Außerkraftsetzungen für die Anwendung auf allen Servern oder nur auf Servern mit einer bestimmten Version von Exchange konfiguriert werden.

Wenn Sie eine Außerkraftsetzung konfigurieren, wird sie nicht sofort wirksam. Der Microsoft Exchange-Integritätsdienst nimmt alle 10 Minuten eine Prüfung auf aktualisierte Konfigurationsdaten vor. Darüber hinaus sind globale Außerkraftsetzungen von der Replikationslatenz von Active Directory abhängig.

Ausführliche Schritte zum Anzeigen oder Konfigurieren von Server- oder globalen Außerkraftsetzungen finden Sie unter Konfigurieren von Außerkraftsetzungen für verwaltete Verfügbarkeit.

Verwaltungsaufgaben und Verwaltungs-Cmdlets

In der Regel haben Administratoren drei wesentliche Betriebsaufgaben bezüglich der verwalteten Verfügbarkeit auszuführen:

• Extrahieren oder Anzeigen der Systemintegrität
• Anzeigen von Integritätssätzen und Details zu Tests, Monitoren und Respondern
• Verwalten von Außerkraftsetzungen

Die beiden primären Verwaltungstools für verwaltete Verfügbarkeit sind das Windows-Ereignisprotokoll und die Shell. Die verwaltete Verfügbarkeit protokolliert eine große Menge von Informationen in den Ereignisprotokollen Exchange ActiveMonitoring und ManagedAvailability crimson channel, z. B.:

• Test-, Monitor- und Responderdefinitionen, die in den jeweiligen Ereignisprotokollen "*Definition" aufgezeichnet werden.
• Test-, Monitor- und Responderergebnisse, die in den jeweiligen Ereignisprotokollen "*Results" aufgezeichnet werden.
• Details zu Responder-Wiederherstellungsaktionen, z. B. wann die Wiederherstellungsaktion gestartet und als abgeschlossen betrachtet wird (erfolgreich oder nicht), die im Ereignisprotokoll "RecoveryActionResults" aufgezeichnet werden.

Für die verwaltete Verfügbarkeit stehen 12 Cmdlets zur Verfügung, die in der folgenden Tabelle beschrieben werden.

Cmdlet	Beschreibung
Get-ServerHealth	Dient zum Abruf unverarbeiteter Serverintegritätsinformationen, z. B. von Integritätssätzen und deren aktuellem Zustand (fehlerfrei oder fehlerhaft), Integritätssatzmonitoren, Serverkomponenten, Zielressourcen für Tests, Zeitstempeln im Zusammenhang mit Start- bzw. Endzeiten von Tests und Monitoren sowie Zustandsübergangszeiten.
Get-HealthReport	Dient zum Abruf einer zusammenfassenden Integritätsansicht mit Integritätssätzen und deren aktuellem Status.
Get-MonitoringItemIdentity	Dient zum Anzeigen der Tests, Monitore und Responder für einen bestimmten Integritätssatz.
Get-MonitoringItemHelp	Dient zum Anzeigen von Beschreibungen einiger Eigenschaften von Tests, Monitoren und Respondern.
Add-ServerMonitoringOverride	Dient zum Erstellen einer lokalen, serverspezifischen Außerkraftsetzung eines Tests, Monitors oder Responders.
Get-ServerMonitoringOverride	Dient zum Anzeigen einer Liste lokaler Außerkraftsetzungen auf dem angegebenen Server.
Remove-ServerMonitoringOverride	Dient zum Entfernen einer lokalen Außerkraftsetzung von einem bestimmten Server.
Add-GlobalMonitoringOverride	Dient zum Erstellen einer globalen Außerkraftsetzung für eine Gruppe von Servern.
Get-GlobalMonitoringOverride	Dient zum Anzeigen einer Liste globaler Außerkraftsetzungen in der Organisation.
Remove-GlobalMonitoringOverride	Dient zum Entfernen einer globalen Außerkraftsetzung.
Set-ServerComponentState	Dient zum Konfigurieren des Status einer oder mehrerer Komponenten.
Get-ServerComponentState	Dient zum Anzeigen des Status einer oder mehrerer Komponenten.