Verwaltete Verfügbarkeit

Die Hauptaufgabe der Administratoren eines Messagingsystems besteht darin, Benutzern eine reibungslose E-Mail-Erfahrung zu ermöglichen. In Ihrer Exchange Server Organisation müssen alle Aspekte des Systems aktiv überwacht werden, und alle erkannten Probleme müssen schnell behoben werden. Hierfür bietet ein Feature mit dem Namen Verwaltete Verfügbarkeit integrierte Überwachungs- und Wiederherstellungsaktionen, die die Benutzerfreundlichkeit aufrecht erhalten.

Verwaltete Verfügbarkeit

Die verwaltete Verfügbarkeit, auch als aktive Überwachung oder lokale aktive Überwachung bezeichnet, ist die Integration von integrierten Ü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: Sind Benutzer in der Lage, die gewünschten Aufgaben auszuführen?

Die verwaltete Verfügbarkeit liefert eine systemeigene Überwachungs- und Wiederherstellungslösung und geht von der Überwachung einzelner, separater Systemkomponenten über zu einer umfassenden Überwachung der Benutzerfreundlichkeit und schützt diese mithilfe wiederherstellungsorientierten Aktionen.

Verwaltete Verfügbarkeit ist ein interner Prozess, der auf jedem Exchange 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 eskaliert die verwaltete Verfügbarkeit das Problem mit der Ereignisprotokollierung an einen Administrator.

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

  • Exchange Health Manager Service (MSExchangeHMHost.exe): Dies 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 wiederherzustellen, falls dieser Prozess fehlschlägt, um zu verhindern, dass der Arbeitsprozess ein einzelner Fehlerpunkt ist.

  • Exchange Health Manager-Arbeitsprozess (MSExchangeHMWorker.exe): Dies 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.

Komponenten der verwalteten Verfügbarkeit

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

Komponenten der verwalteten Verfügbarkeit

Die Komponenten der verwalteten Verfügbarkeit in Exchange Server.

Testmodule

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.

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. Dadurch kann die Prüfinfrastruktur ermitteln, wann bei den Benutzern Probleme auftreten. Mithilfe der Benachrichtigungslogik kann das System schließlich auf Grundlage eines kritischen Ereignisses Sofortmaßnahmen ergreifen, ohne auf die Ergebnisse der über den Test erfassten Daten warten zu müssen. Hierbei handelt es sich in der Regel um Ausnahmen oder Bedingungen, die ohne große Stichprobe ermittelt und erkannt werden können.

Wiederkehrende Tests werden alle paar Minuten durchgeführt und dienen zur Bewertung einzelner 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 Systemstart des Health Manager-Diensts in Microsoft definiert. Exchange. ActiveMonitoring\ProbeDefinition-Kanal. Jede Prüfpunktdefinition verfügt über viele Eigenschaften, aber die relevantesten Eigenschaften sind:

  • Name Der Name des Prüfpunkts, der mit einer SampleMask des Prüfpunktmonitors beginnt.

  • TypeName Der Codeobjekttyp des Tests, der die Testlogik enthält.

  • ServiceName Der Name des Integritätssatzes, der den Test enthält.

  • TargetResource Das Objekt, das durch den Test überprüft wird. Dies wird an den Namen des Prüfpunkts angefügt, wenn er ausgeführt wird, um zu einem Ergebnisnamen des Prüfpunkts zu werden.

  • RecurrenceIntervalSeconds Häufigkeit, in der der Test ausgeführt wird.

  • TimeoutSeconds Zeit, die der Test wartet, bevor er als fehlgeschlagen gilt.

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 erneut ausgeführt, wenn ein Timeout auftritt, 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. Sie können diese Tests im Kanal ProbeDefinition nicht sehen, da dieser Kanal nur die Tests beschreibt, die vom Framework für verwaltete Verfügbarkeit 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. Überwacht den Typ "Microsoft.Office". Datacenter.ActiveMonitoring.OverallConsecutiveSampleValueAboveThresholdMonitor oder Microsoft.Office. Datacenter.ActiveMonitoring.OverallConsecutiveSampleValueBelowThresholdMonitor bedeutet, dass die Überwachungsuntersuchung ein Prüfpunkt ist.

Überwachen

Die Ergebnisse der von Testmodulen erfassten Messungen fließen in die zweite Komponente ein, den Monitor. Der Monitor umfasst die vollständige, vom System verwendete Geschäftslogik von gesammelten Daten. Ähnlich wie bei einem Modul zur Mustererkennung achtet der Monitor auf die zahlreichen verschiedenen Muster aller gesammelten Messungen. Anschließend wird entschieden, ob eine Komponente als fehlerfrei betrachtet wird.

Monitore fragen die von Daten ab, um zu ermitteln, ob auf Basis eines vordefinierten Regelsatzes Maßnahmen ergriffen werden müssen. 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 legen Monitore fest, wie viel Zeit nach einem Fehler ein Responder ausgeführt wird, und der 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 erfassten Metriken liegen innerhalb der normalen Betriebsparameter.

  • Fehlerhaft: Der Monitor ist nicht fehlerfrei und hat entweder die Wiederherstellung über einen Responder initiiert oder einen Administrator über die Eskalation benachrichtigt.

Aus administrativer Sicht weisen Monitore zusätzliche Zustände auf, die in der Exchange Verwaltungsshell angezeigt werden:

  • Degraded: When a monitor is in a unhealthy state from 0 through 60 seconds, it's considered Degraded. 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 Exchange-Integritätsdienst fragt in regelmäßigen Abständen jeden Monitor nach seinem Status ab. Wenn er auf die Abfrage keine Antwort erhält, ändert sich der Zustand des Monitors in "Nicht verfügbar".

  • Reparatur: Ein Administrator legt den Reparaturzustand so fest, dass dem System angezeigt wird, dass korrekturmaßnahmen von einem Menschen ausgeführt werden, wodurch das System und Menschen zwischen anderen Fehlern unterscheiden können, die zur gleichen Zeit auftreten können, in der Korrekturmaßnahmen ausgeführt werden (z. B. bei einem erneuten Datenbankkopie-Vorgang).

Jeder Monitor enthält eine SampleMask-Eigenschaft in seiner Definition. Während der Ausführung des Monitors wird nach Ereignissen im ProbeResult-Kanal gesucht, deren ResultName dem 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.

Es ist zu beachten, dass ein einzelner Testfehler nicht notwendigerweise darauf hinweist, dass etwas mit dem Server nicht stimmt. Es ist das Design von Monitoren, um zu erkennen, ob ein echtes Problem behoben werden muss. Aus diesem Grund haben viele Monitore Schwellenwerte für mehrere Testfehlschläge, bevor Fehlerhaftigkeit festgestellt wird. 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. Dazu gehört auch der letzte Testfehler.

Responder

Abschließend gibt es noch Responder, die für Wiederherstellungs- und Eskalationsaktionen verantwortlich sind. Wie der Name besagt, führen Responder eine bestimmte Art von Reaktion auf eine von einem Monitor generierte Warnung aus. Wenn eine Komponente fehlerhaft ist, besteht die erste Aktion in dem Versuch, diese Komponente wiederherzustellen. Dies kann mehrstufige Wiederherstellungsaktionen umfassen. Der erste Versuch kann z. B. darin bestehen, dass der Anwendungspool neu gestartet wird, während der zweite Versuch den Neustart des Diensts und der dritte Versuch den Neustart des Servers umfasst. Ein nachfolgender Versuch könnte darin bestehen, den Server offline zu nehmen, damit kein Datenverkehr mehr angenommen wird. Wenn die Wiederherstellungsaktionen keinen Erfolg zeigen, eskaliert das System das Problem per Ereignisprotokollbenachrichtigung an einen Benutzer.

Die Antwortenden führen verschiedene Wiederherstellungsaktionen aus, z. B. das Zurücksetzen eines Anwendungsarbeitspools oder das Neustarten eines Servers. Es gibt verschiedene Arten von Respondern:

  • Neustart-Responder Beendet einen Dienst und startet ihn neu.

  • Anwendungspool-Neustart-Responder Beendet einen Anwendungspool in den Internetinformationsdiensten (IIS) und startet ihn neu.

  • Failover-Responder Initiiert ein Datenbank- oder Serverfailover.

  • Fehlerprüfungs-Responder Initiiert eine Fehlerprüfung des Servers und verursacht dadurch einen Neustart des Servers.

  • Offline-Responder Setzt ein Protokoll auf einem Server außer Betrieb (weist Clientanforderungen zurück).

  • Online-Responder Versetzt ein Protokoll auf einem Server wieder in den Produktionsmodus (akzeptiert Clientanforderungen)

  • Eskalations-Responder Eskaliert das Problem durch Ereignisprotokollierung an einen Administrator

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

Alle Responder enthalten Drosselungsverhalten, das einen integrierten Sequenzierungsmechanismus zum Steuern von Responderaktionen 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 Server (z. B. Outlook im Web, Exchange ActiveSync, der Information Store-Dienst, inhaltsindizierung, Transportdienste usw.) wird durch verwaltete Verfügbarkeit mit Prüftasten, Monitoren und Respondern überwacht. Eine Gruppe von Sonden, Monitoren und Respondern für eine bestimmte Komponente wird als Integritätssatz bezeichnet. Ein Integritätssatz ist eine Gruppe von Tests, Monitoren und Respondern, die ermitteln, ob diese Komponente fehlerfrei ist. Der aktuelle Status 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 seinen 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 sind für System Center Operations Manager 2012 R2 verfügbar.

Es gibt vier primäre Integritätsgruppen:

  • Kontaktpunkte für Kunden Komponenten, die sich auf Echtzeit-Benutzerinteraktionen auswirken, wie Protokolle oder der Informationsspeicher.

  • Dienstkomponenten Komponenten ohne direkte Echtzeit-Benutzerinteraktionen, wie z. B. der Microsoft Exchange-Postfachreplikationsdienst oder der Offlineadressbuch-Generierungsprozess (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 Eskalations-Responder schreiben Ereignisse in das Windows-Ereignisprotokoll, die vom Monitor in SCOM verwendet werden. Diese werden als Warnungen in der Ansicht "Aktive Warnungen" angezeigt.

  • Organisationsintegrität In dieser Ansicht wird eine Rollupzusammenfassung der Gesamtintegrität der Exchange Unternehmensintegrität angezeigt. Diese Rollups enthalten Anzeigen der Integrität für einzelne Datenbank-Verfügbarkeitsgruppen und für bestimmte Active Directory-Standorte.

  • Serverintegrität In dieser Ansicht werden verwandte Integritätssätze zu Integritätsgruppen kombiniert und 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 auf einem einzelnen Server erstellt und angewendet werden (dies wird als Serveraußerkraftsetzung bezeichnet), oder sie können auf eine Gruppe von Servern angewendet werden (dies 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 verwalteter Verfügbarkeit.

Verwaltungsaufgaben und Verwaltungs-Cmdlets

Es gibt drei primäre operative Aufgaben, die Administratoren in der Regel im Hinblick auf die verwaltete Verfügbarkeit ausfü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 wichtigsten Verwaltungstools für die verwaltete Verfügbarkeit sind das Windows-Ereignisprotokoll und die Exchange-Verwaltungsshell. Die verwaltete Verfügbarkeit protokolliert eine große Menge an Informationen in den Ereignisprotokollen Exchange ActiveMonitoring- und ManagedAvailability-Ereignisprotokolle, 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 den Wiederherstellungsaktionen des Antwortenden, einschließlich des Zeitpunkts, zu dem die Wiederherstellungsaktion gestartet wird, und die als abgeschlossen betrachtet werden (ob erfolgreich oder nicht), die im RecoveryActionResults-Ereignisprotokoll protokolliert 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.