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
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 in 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 Konsolenstammen 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:
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.
Über den Autor
Thomas Windscheif arbeitet bei excITe Consulting und ist langjähriger Berater im Bereich IT-Infrastruktur und Groupware. Sowohl Kleinunternehmen z. B. im Handwerk als auch der größere fertigende Mittelstand gehören zu seinem Projektumfeld. Im Wesentlichen gehören die Planung von Infrastruktur-Migrationen, Cloud-Lösungen (Microsoft 365), Groupware-Umgebungen (z. B. Exchange) und deren Umsetzung zu seinen Aufgaben. Insbesondere im Umfeld hybrider Identitätsumgebungen mit Entra Connect und den Möglichkeiten zur Härtung der IT-Landschaft konnte er in vielen Projekten Erfahrungen sammeln. Neues begeistert ihn aber ebenso und so unterstützt Thomas Windscheif auch bei themenfremden IT-Systemen, überall da wo er helfen kann.
Sein Ziel: Die Mehrwerte der heutigen IT-Lösungen für einfacheres und modernes Arbeiten beim Kunden einbringen.
Login
Sie haben ein ungelöstes Problem in Ihrer Exchange Server/Microsoft-Infrastruktur oder unter Microsoft 365? Treten Sie gerne mit mir in Kontakt.
Sowohl bei einfachen Umgebungen, als auch bei komplexen Multisite/Cloud-Topologien
unterstütze ich Sie -auch kurzfristig- sehr gerne.
- E-Rechnung Viewer via Gruppenrichtlinie installieren -
Das Jahr neigt sich dem Ende und ab dem 01.01.2025 müssen Unternehmen E-Rechnungen empfangen können. Hierzu gehört auch das XML-basierte X-Rechnungsformat. In seiner Reinform eher unleserlich für den Anwender. Daher gibt es Viewer welche auf Basis der KoSIT-Visualisierung funktionieren.