The ExchangeHealthChecker has been around for some time, but many people still seem to be unaware of this useful script. However, it is worth running the script from time to time to prevent problems. The ExchangeHealthChecker analyzes the Exchange configuration and lists the most common configuration problems. The script therefore makes troubleshooting much easier. For example, the ExchangeHealthChecker lists expired certificates, such as an expired OAuth certificate, which is used in the Installation of the July 2021 security updates caused problems. However, the script also lists configuration problems that you may not always have recognized as such (although the recommended 128GB RAM for Exchange 2019 can be ignored in many environments). Nevertheless, I consider the ExchangeHealthChecker to be a very useful script and I have now gotten into the habit of running the script once before installing the Exchange CUs.
The ExchangeHealthChecker can be downloaded here:
Before running the ExchangeHealthChecker, you should make sure that you are always using the latest version. As already mentioned, I download the latest version before installing the Exchange CUs and then run it once. It is important that ExchangeHealthChecker is executed in the "elevated Exchange Shell" (Run as Administrator). Calling the script without any other parameters checks the local Exchange server:
The results are output directly in the shell, but a log is also written in XML and TXT format so that the results can also be further processed by other scripts.
The ExchangeHealthChecker script itself also has the option of preparing the results as an HTML file. To obtain an HTML report, the script can be called after the first run with the -BuildHtmlServersReport parameter:
This creates an easy-to-read report, here is an (abbreviated) example:
The HealthChecker HTML report therefore summarizes configuration problems and open vulnerabilities, and often includes a link to the solution to the problem.
Hallo Frank,
super Artikel, vielen Dank.
Ich habe leider das Problem das das script nicht durchläuft weil es den Server nicht ermitteln kann.
Der Befehl get-exchangeserver gibt nichts zurück und so bricht das script ab.
Seltsamerweise wird auch in der EPS kein Name zurück gegeben.
Was mache ich falsch, oder kennt jemand das Problem auch?
Grüße
Det
Hier mal zum Copy-Pasten für die PowerShell:
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn;
Invoke-WebRequest „https://github.com/microsoft/CSS-Exchange/releases/latest/download/HealthChecker.ps1“ -OutFile „C:\HealthChecker.ps1“ ; cd \
.\HealthChecker.ps1 ; C:\HealthChecker.ps1 -BuildHtmlServersReport
msrc.microsoft. com/update-guide/en-us/vulnerability/CVE-2021-1730
Ist im Artikel gut beschrieben, wie es geht.
das hat bei mir nicht gut funktioniert
nach anpassung der config waren keinerlei anhänge über OWA mehr abrufbar
hatte keinen fehler in meiner config gefunden
Exchange 2019 CU10
Also ich habe das per A-Record Eintrag in unserer owa/exchange domain gemacht. Wir benutzen aber split-dns. Ich bin da ziemlich genau nach der Anleitung vorgegangen, die hier im Forum verlinkt wurde. Nachdem die DNS Einträge sowohl intern als auch extern gesetzt wurden war das Zertifikat dran.
Natürlich müssen die ganzen Domains und Aliase auch im Zertifikat drinstehen. Allerdings machen wir OWA nicht per Reverse Proxy sondern nur per VPN.
Und das heißt ja nicht, dass kein Fehler da ist. Allerdings ohne Infos zu „deiner Konfiguration“ lässt sich wirklich nichts sagen.
Hallo Frank,
könntest du vielleicht auf das Thema Download Domains etwas näher eingehen?
Ich finde dazu keine guten Informationen geschweige denn ein HowTo. :)
LG
Peter
Ich würde mich auch sehr freuen
https://www.nobbysweb.de/blog/index.php?entry/59-sicherheitsanfälligkeit-in-microsoft-exchange-server-bezüglich-spoofing-cve-2021/
Vielleicht so? Oder was fehlt?
Hat das jemand mit der autodiscovery domain ausprobiert?
Ja, das hat jemand mit der autodiscover Domain ausprobiert. Funktioniert.
Wenn ich den Einwurf zum autodiscover-Eintrag richtig verstehe, müsste es ja mit den drei Befehlen
Set-OwaVirtualDirectory -Identity „owa (default Web site)“ -ExternalDownloadHostName „autodiscover.example.tld“
Set-OwaVirtualDirectory -Identity „owa (default Web site)“ -InternalDownloadHostName „autodiscover.example.tld“
Set-OrganizationConfig -EnableDownloadDomains $true
+ Reboot erledigt sein, oder übersehe ich da etwas?
Nein es ist wirklich so „schnell“ erledigt, wenn man nur die autodiscoverdomain zur Verfügung hat.
Hallo Frank,
gut dass du hier Aufmerksamkeit auf das Script lenkst, es ist wirklich sehr hilfreich und hat mir auch schon mal aus der Patsche geholfen. Als kleine Ergänzung: Das Script hat seit einiger Zeit einen Auto-Updater drin, heißt wenn der Exchange bzw. die Exchange Shell abgehend ins Internet kommt lädt das Script beim starten automatisch die aktuellste Version runter und gibt das auch als Info raus. Somit spart man sich das händische prüfen/runterladen der aktuellsten Version.
Mfg
Daniel
Hallo Frank,
könntest du vielleicht auf das Thema Download Domains in einem Artikel näher eingehen?
Ich finde dazu keine guten Informationen geschweige denn ein HowTo. :)
VG!
Gero
Was meinst du mit Download Domains?
Wüsstest du, wenn du das erwähnte skript ausgeführt hättest. ;)
Link für den anfragenden Gero weiter unten bei den Kommentaren. Wer Verbesserungsvorschläge hat, einfach Bescheid geben?