Symptome:
Diverse Sensoren werden über den Befehl Get-ServerHealth und Get-HealthReport als „Unhealthy“ zurückgegeben.
Ausgabe fehlerhafter Sensoren bzw. Serverkomponenten:
Get-HealthReport „Name des Servers“ | ? {$_.AlertValue -eq „Unhealthy“}
Get-ServerHealth „Name des Servers“ | ? {$_.AlertValue -eq „Unhealthy“}
Get-ServerComponentState „Name des Servers“ | ? {$_.State -ne „Active“}
Zunächst würde ich, wenn der Fehler nur einmal aufgetreten ist, abwarten.
Sollte er dauerhaft bestehen bleiben, wäre die Neuanlage der Healthmailboxen der nächste Schritt. Diese können im Laufe der Zeit korrumpieren und führen ebenfalls zu negativen Sensorenergebnissen. Zur Neuanlage können Sie folgendes Script verwenden: http://microlinc.homeip.net/index.php?lev1=25&lev2=8&lev3=&id=329
Die folgenden Sensoren werden als „Unhealthy“ zurückgegeben:
ECPProxyTestMonitor
EWSProxyTestMonitor
OWACtpMonitor
Möglicher Grund:
Wenn Sie vor den Exchange-Servern einen Loadbalancer betreiben, stellen viele im Backend die Authentifizierung der virtuellen Verzeichnisse ECP und OWA auf Basic-Authentication (Standardauthentifizierung) um. Leider unterstützen die Probes keine Standardauthentifizierung.
- Zur Analyse und Eingrenzung des Fehlers öffnen Sie im Eventlog den Crimson Channel auf dem betroffenden Exchange-Server und öffnen Sie die ProbeResult-Logs:
Anwendungs- und Dienstprotokolle > Microsoft > Exchange > ActiveMonitoring > ProbeResult - Grenzen Sie die Ansicht mittels des Filters auf die fehlerhaften Ereignisse ein.
- Suchen Sie die Ereignisse zu den betreffenden Sensoren
- Klicken Sie dann auf den Reiter „Details“
- Wählen Sie die „XML-Ansicht“
- Wenn der nachfolgende Ausdruck im Abschnitt Error anzeigt wird, handelt es sich um einen Authentifizierungsfehler. Und somit mit hoher Wahrscheinlichkeit um den zu Beginn beschriebenen Fehler.
Der Remoteserver hat einen Fehler zurückgegeben: (401) Nicht autorisiert.
Es gibt hier nun zwei mögliche Lösungen:
- Aktivierung der Windows Authentifizierung zusätzlich zur Standardauthentifizierung
Get-OwaVirtualDirectory -Server „Name des Servers“ | Set-OwaVirtualDirectory -WindowsAuthentication $true - Deaktivierung der Sensoren
siehe https://blogs.technet.microsoft.com/ehlro/2014/02/20/exchange-2013-managed-availability-healthset-troubleshooting/
Letzteres würde ich nicht empfehlen, da Änderungen in den Konfigurationsdateien durch die Installation der kumulativen Updates ggf. überschrieben werden, was einen weiteren Prüf- bzw. Arbeitsschritt beim Updateprozess zur Folge hat.
Die folgenden Sensoren werden als „Unhealthy“ zurückgegeben:
OutlookRpcDeepTestMonitor
OutlookRpcSelfTestMonitor
Möglicher Grund:
Diese Tests prüfen die Proxying-Funktion der CAS-Schicht. Es gibt verschiedene Gründe für die Fehler. Häufig ist es ein Fehler bzgl. des im Binding (:444) der „Exchange Back End“ Site verwendeten Zertifikats. Viele Administratoren wählen hier das für die Umgebung neu erstellte SAN-Zertifikat aus. Supported ist hier lediglich das selbstsignierte bei der Installation erstellte Zertifikat mit dem Anzeigenamen „Microsoft Exchange“. Manchmal liegt es aber auch daran, dass eben diesem Zertifikat aus welchen Gründen auch immer das Vertrauen entzogen wird (obwohl selbiges im Trusted Root Cert-Container liegt).
- Zur Analyse und Eingrenzung des Fehlers öffnen Sie im Eventlog den Crimson Channel auf dem betroffenden Exchange-Server und öffnen Sie die ProbeResult-Logs:
Anwendungs- und Dienstprotokolle > Microsoft > Exchange > ActiveMonitoring > ProbeResult - Grenzen Sie die Ansicht mittels des Filters auf die fehlerhaften Ereignisse ein
- Suchen Sie die Ereignisse zu den betreffenden Sensoren
- Klicken Sie dann auf den Reiter „Details“
- Wählen Sie die „XML-Ansicht“
- Wenn der nachfolgende Ausdruck im Abschnitt Error anzeigt:
Das Objekt mit Nullwert muss einen Wert haben.
und der folgende Ausdruck im Abschnitt ExecutionContext vorhanden ist:
Das Remotezertifikat ist laut Validierungsverfahren ungültig
liegt der Fehler darin begründet, dass der Server dem Zertifikat nicht traut.
Es gibt hier nun eine mögliche Lösung:
- Exportieren und importieren des aktuellen Selfsigned-Zertifikats in den Trusted Root Store
- Öffnen Sie den IIS-Manager
- Klicken Sie mit der rechten Maustaste auf „Exchange Back End“ und wählen Sie dort „Bindungen“
- Markieren Sie die Zeile https 444 und klicken Sie auf „Bearbeiten…“
- Prüfen Sie, ob das Zertifikat „Microsoft Exchange“ ausgewählt ist und klicken Sie auf „Anzeigen…“
- Prüfen Sie in den Zertifikatseigenschaften, ob das Zertifikat noch gültig ist
- Prüfen Sie im Reiter „Details“, ob unter „Alternativer Antragstellername“ der Hostname und der FQDN des Servers eingetragen sind
- Klicken Sie nun auf „In Datei kopieren…“
- Gehen Sie die Schritte des Assistenten durch und wählen Sie bei der Formatauswahl „DER-codiert-binär X.509 (.CER)“
- Öffnen Sie nun die MMC-Konsole als Administrator und wählen Sie unter „Datei“ > „Snap-In
hinzufügen/entfernen…“
- Im neuen Dialogfenster markieren Sie „Zertifikate“, klicken Sie dann auf „Hinzufügen“
- Wählen Sie „Computerkonto“. Dann Lokaler Computer
- Unter dem Konsolenstamm erweitern Sie „Zertifikate (Lokaler Computer)“ > „Vertrauenswürdige Stammzertifizierungsstellen“ > „Zertifikate“
- Klicken Sie mit der rechten Maustaste auf „Zertifikate“, wählen Sie „Alle Aufgaben“ > „Importieren…“
- Wählen Sie das zuvor exportierte Zertifikat und schließen Sie den Import ab
- Testen Sie den Erfolg der Maßnahme indem Sie in der Exchange Management Shell folgende Befehle absetzen:
Test-OutlookConnectivity -ProbeIdentity „OutlookRpcDeepTestProbe“ | fl
Test-OutlookConnectivity -ProbeIdentity „OutlookRpcSelfTestProbe“ | fl
Wenn Result/ResultType beider Tests auf „Succeeded“ lautet, waren die Maßnahmen erfolgreich.
Der folgende Sensor wird als „Unhealthy“ zurückgegeben:
NetworkAdapterRssMonitor
Vermutlich liegt es an den Sprachpaketen, denn bei allen deutsch installierten auf vmware basierten VM-Installation von Exchange erhalte ich stehts den oben angegeben Sensor als Unhealthy zurück, obwohl RSS global sowie NIC-seitig aktiviert ist. Bei englisch sprachigen OS Installationen konnte ich den Fehler noch nicht reproduzieren.
- Zum Aktivieren von RSS verwenden Sie ab Server 2012 R2 folgenden Befehl:
Get-NetAdapterRSS | Set-NetAdapterRSS –Enabled $true
Beachten Sie hier aber bitte immer auch die Vorgaben des Herstellers der Virtualisierungsplattform - Wenn Sie alle Maßnahmen umgesetzt haben und der Fehler weiterhin erscheint, deaktivieren Sie den Monitor wie folgt über die Exchange Management Shell:
Add-GlobalMonitoringOverride -Identity Network\NetworkAdapterRssMonitor -ItemType Monitor -PropertyName Enabled -PropertyValue 0
Bitte beachten Sie, dass die Änderungen erst nach einiger Zeit Wirkung zeigen. Die Probes werden in bestimmten Intervallen ausgeführt. Geben Sie dem HM-Dienst etwas Zeit.
