Azure Stack HCI – Performance Benchmark 6 Node Dell AX-740XD Cluster

Einleitung

Hyperkonvergente Systeme sind immer weiter im Trend und erobern auch die deutschen Rechenzentren. Eher neu ist die HCI Lösung von Microsoft: Azure Stack HCI, die (erst) seit Ende Dezember 2020 auf dem Markt ist. Hierbei handelt es sich um ein eigenes Betriebssystem (auf Basis von Server 2019) welches rein für die Hyper-V Dienste ausgelegt ist und sich funktional von den klassischen Windows-Server Varianten in Zukunft auf die Virtualisierung abheben soll. So gibt es Azure Stack HCI nur als Core-Installation (also ohne GUI) – die Bedienung soll per Windows Admin Center oder rein per Powershell erfolgen. Neu ist auch das Lizenzierungsmodell, wo Microsoft auf eine Gebühr von 10€/Monat pro CPU Kern veranschlagt. Hier möchte man anscheinend ähnlich der Konkurrenz auch am Hypervisor verdienen.

Da die Software relativ neu ist, findet man aktuell leider relativ schwer Benchmarks oder Performancedaten von Systemaufbauten, die nicht rein für Marketingzwecke ausgerichtet sind. Daher habe ich mich entschieden hier einige Ergebnisse als Orientierung zu präsentieren. Getestet wird ein für Azure Stack HCI zertifiziertes System von Dell in Form von AX-740XD Systemen, die nach Best-Practise konfiguriert wurden. Das Betriebssystem der Server war die zum Zeitpunkt aktuellste Azure Stack HCI Version. (Patchstand Mai 2021).

Hardwareaufbau

Als Aufbau dienen 6 Dell AX-740XD Server mit folgender SSD/Fullflash Konfiguration:
Für das OS werden die BOSS Karten verwendet. Als Cache Karten werden je 2 x NVME verwendet. Für den Kapazitäts-Tier werden je 6 x SSD verwendet.

MediaTypeBusTypeUsageModelFriendlyNameKapazitätAnzahl InsgesamtAnzahl  pro Server
SSDSATABoot-DriveSSDSCKKB240G8RDELLBOSS VD223.57 GB122
SSDSASAuto-Select (Capacity)KPM5XRUG3T84TOSHIBA KPM5XRUG3T843.49 TB366
SSDPCIeJournal (Cache)Dell Express Flash NVMe P4610 1.6TB SFFDell Express Flash NVMe P4610 1.6TB SFF1.46 TB122

Herstellerangaben und theoretische max-Werte

Da es kaum Vergleichswerte bei solchen Systemen gibt, ziehen wir als Vergleich die Herstellerangaben heran. So haben wir zumindest einen Richtwert, der uns hilft das System zu validieren. Um nähere Spezifikationen zu den möglichen Schreib/Lesewerten und IOPS zu bekommen, müssen wir uns nun die Modelle etwas genauer anschauen. Die 3,49 TB SSD ist zwar laut Beschreibung von TOSHIBA – hinter dem Namen versteckt sich aber der Hersteller Kioxia und genau folgendes Modell: PM5-R Series. Auf der Herstellerseite finden wir dann auch Angaben zu den theoretischen Werten:

Technische Daten vom Hersteller
Man beachte, dass die Herstellerangaben unter Verwendung von Dual Port 12GB SAS gemessen wurde, was in unserem S2D/Azure Stack HCI Konstrukt nicht der Fall ist und die SSD „lediglich“ über einen SAS Port angeschlossen ist. Daher sind unsere Ergebnisse in der Praxis etwas geringer. Als einzelne SSD eingebunden und Formatiert mit 64k ReFS haben wir mit CrystalDiskMark für die KPM5XRUG3T84 folgende Werte erhalten:

Crystaldisk Benchmark SSD Crystaldisk Benchmark SSD

Für die P4610 von Dell finden wir direkt bei Dell in einem DataSheet die vergleichbaren Daten:

Technische Daten Dell NVME

Netzwerk

Netzwerkseitig sind die Systeme mit 4 x 25GB über 2 Dual Port „Mellanox ConnectX-4 Lx 25GbE SFP28“ Karten mit je einem DELL SF5212F verbunden.
Als Technologie für die Storagereplikation verwenden wir RDMA.

Storageübersicht

Windows Admin Center Storagepool

In Summe haben wir einen Storagepool den wir auf 6 Volumes (1 pro Host) aufteilen. Für alle Volumes verwenden wir einen Three-Way-Mirror, für maximale Performance.

Windows Admin Center Volumes

Testmöglichkeiten

Es gibt 2 verschiedene Testmöglichkeiten um den Cluster auf Herz und Iops zu testen.

VMFleet war früher das gängige Tool und es gibt dazu auch gute Beschreibungen wie von DataOn. Es ist etwas umständlich zu konfigurieren, aber hat es mehrere VM’s erzeugt und in diesen dann diskspd ausgeführt. Dies wäre meiner Ansicht nach zumindest ein Test wo der Realität am nächsten kommt. Laut Microsoft (Azure Stack HCI Support) ist VMFleet allerdings nicht mehr supported was Benchmarks angeht.

Präferierte Variante: StartWorkload.ps1
Hier muss lediglich DiskSpd heruntergeladen werden und keinerlei extra VM’s erzeugt werden. Das Tool verschiebt die ClusterStorage’s und verteilt diese auf die Hosts und startet dann DiskSpd auf jedem Host für sein Cluster-Volume.

Zu Beginn müssen wir erstmal 3 benötigte Tools herunterladen:

watch-cluster.ps1
start-workload.ps1
diskspd.exe

Alle Tools packen wir in einen Ordner, diskspd muss zuvor noch entpackt werden.

Watch-Cluster

In einem Powershellfenster auf dem Host starten wir Watch-Cluster, welches uns die Storagewerte live liefert. Das Tool ist deutlich genauer als z.B. das Windows Admin Center.
Um alle Daten in einem Fenster angezeigt zu bekommen muss man in der Regel die Schriftgröße des Powershellfensters auf 10 oder 11 herabsetzen 🙂

 .\watch-cluster.ps1 -sets *

Start-Workload

Mit Start-Workload können wir nun verschiedene Szenarien durchprobieren. Wenn man diese aufzeichnen möchte, lohnt sich ggf. auch die Aufnahme der Performancecounter .

4K 100% Read with minimal Latency to identify if we have a latency issue

.\Start-Workload.ps1 -DiskSpdpath "C:\Temp\Diskspd.exe"

BenchmarkBenchmark  Benchmark

4K 100% Read (Maximize IOPS), we don’t care too much about Latency:

.\Start-Workload.ps1 -DiskSpdpath "C:\Temp\DiskSpd" -o 32

BenchmarkBenchmark

4K 100% Write  – Expect to have much less IOPS then 100% Read

Die Daten werden bei einem Three-Way-Mirror noch auf 3 weiteren Fault Domains geschrieben, nicht zu vergessen…

.\Start-Workload.ps1 -DiskSpdpath "C:\Temp\DiskSpd" -w 100

BenchmarkBenchmarkBenchmark

128K 100% Read –  Maximize Throughput on Reads

Nun testen wir mit der Blockgröße von 128K und einer Queuetiefe von 32 (Outstanding IO’s). Hier haben wir dann zwar nicht unbedingt viele IO’s jedoch einen sehr hohen Durchsatz.

.\Start-Workload.ps1 -DiskSpdpath "C:\Temp\DiskSpd" -B 128K -o 32

BenchmarkBenchmark Benchmark Benchmark Benchmark

128K 100% Write-  Maximize Throughput on Writes

Gleiches Spiel nur schreibend.

.\Start-Workload.ps1 -DiskSpdpath "C:\Temp\DiskSpd" -B 128K -o 32 -w 100

BenchmarkBenchmark  Benchmark Benchmark Benchmark

Netzwerkauslastung

Kombinierte Auslastung aller 25GbE Ports der beiden Switches (pro Switch):

Benchmark Benchmark

In Summe kommen wir beim Lesen (4k) auf ungefähr 234 Gbit/s über alle Ports gerechnet. Das wären pro Server 39 Gbit/s die dann auf die 4 Karten verteilt werden.

Die Switche & Netzwerkkarten haben wir in Tests nur durch Livemigrationen höher ausgelastet bekommen. Ein guter Test ist eine Blanko VM mit 80% der maximal verfügbaren Ram-Menge des Hosts auszustatten (z.B. 500GB) und dann per Livemigration auf einen anderen Host zu migrieren. Das funktioniert per RDMA ziemlich gut und flott – speziell wenn die SMB Limits korrekt richtig gesetzt sind. In unserem Fall haben sich so VM’s mit 500 GB Arbeitsspeicher in wenigen Sekunden per Livemigration auf einen anderen Host migrieren lassen, was die Netzwerkkarten an ihr Limit bringt 😉

Auffälligkeiten

Bei kleinen Blockgrößen (4K) haben wir es immer geschafft die CPU’s der Hosts auf Vollast (80-100%) zu fahren, was bei 2 Sockel Xeon(R) Gold 6248R Systemen schon ganz ordentlich ist. Die CPU ist in diesem Fall der Flaschenhals – zumal noch kein anderer Workloud (VM’s) auf dem Cluster läuft. Im Realbetrieb ist hier natürlich eine etwas geringere Leistung zu erwarten. Bei den großen 128K Blöcken war die CPU nur zu ca. 20% ausgelastet. Hier haben wir gesehen, dass die SSD’s dann auch an ihre Grenzen gekommen, was sich auch gut an den höheren Latenzen auf SSD Ebene bestätigt hat.

Powershell – Die zugrunde liegende Verbindung wurde geschlossen: Unerwarteter Fehler beim Senden…

Beim Abfragen von Webservices über Powershell kommt es immer wieder mal zu folgender Fehlermeldung:

PS N:\> Invoke-Webrequest -Uri https://tls-v1-2.badssl.com:1012/
Invoke-Webrequest : Die zugrunde liegende Verbindung wurde geschlossen: Unerwarteter Fehler beim Senden..
In Zeile:1 Zeichen:1
+ Invoke-Webrequest -Uri https://tls-v1-2.badssl.com:1012/
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
eption
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

So wirklich schlau wird man aus der Meldung „Die zugrunde liegende Verbindung wurde geschlossen: Unerwarteter Fehler beim Senden..“ jetzt auf den ersten Blick nicht. (In Englisch: The underlying connection was closed: An unexpected error occurred on a send..)
Der Fehler tritt bei Problemen mit der TLS Verschlüsselung auf. Speziell wenn der Client (also die Powershell in diesem Fall) mit einer nicht unterstützten TLS Version beim Server ankommt.
Bei Windows Server 2016, 2012R2 oder älteren Windows Client Betriebssystemen ist die Standard Verschlüsselung TLS 1.1/1.0 welche von vielen Betreibern von Websites mittlerweile wegen der Sicherheit deaktiviert wurde.
Bein Windows Server 2019 und Windows 10 (1909) hatte ich bei Tests mit dem Powershell Invoke-Webrequest standardmäßig TLS 1.2 vorgefunden.

Wie kann man per Powershell die TLS Verschlüsselung ändern?

Über folgende Befehle vor dem Invoke-Webrequest bzw. Invoke-RestMethod kann die TLS Version gesteuert werden.

TLS 1.2

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

TLS 1.1

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls11

TLS 1 ( 1.0 )

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls

Beispiel

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$a = Invoke-Webrequest -Uri https://tls-v1-2.badssl.com:1012/

Dies kann man über folgende URL’s auch direkt testen (Quelle: Stackexchange.com):

This subdomain and port only supports TLSv1.2

https://tls-v1-2.badssl.com:1012/

This subdomain and port only supports TLSv1.1

https://tls-v1-1.badssl.com:1011/

This subdomain and port only supports TLSv1.0

https://tls-v1-0.badssl.com:1010/

Nützliche Links

IISCrypto

Mit dem kostenfreien Tool IISCrypto lässt sich speziell der IIS aber auch die Grundlegenden Systemstandards und TLS Protokolle definieren.

Cipherlist

Unter Cipherlist bekommt man jeweils immer die aktuellen SSL Einstellungen für viele Webserver, wie apache2, nginx, oder auch andere Dienste.

Ähnliche Fehlermeldungen

Auch bei der PowerShell Gallery muss man mittlerweile TLS 1.2 einsetzen. Ansonsten bekommt ihr folgende Fehlermeldung:

Install-Module -Name SqlServer
WARNUNG: Unable to resolve package source 'https://www.powershellgallery.com/api/v2'.
PackageManagement\Install-Package : Für die angegebenen Suchkriterien und den Paketnamen "SqlServer" wurde keine
Übereinstimmung gefunden. Verwenden Sie Get-PSRepository, um alle verfügbaren, registrierten Paketquellen anzuzeigen.
In C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:1772 Zeichen:21
+ ... $null = PackageManagement\Install-Package @PSBoundParameters
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Microsoft.Power....InstallPackage:InstallPackage) [Install-Package], Ex
ception
+ FullyQualifiedErrorId : NoMatchFoundForCriteria,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackage

Philips Fernseher – Ins Service Menü gelangen (55PUS6401/12)

Wer das Service Menü der Philips sucht, kann folgende Tastenkombinationen über die Fernbedienung ausprobieren:

0 + 6 + 2 + 5 + 9 + 6 + Menu/Info/Status
0 + 6 + 2 + 5 + 9 + 7 + Menu/Info/Status
0 + 6 + 1 + 5 + 9 + 6 + Menu
0 + 6 + 1 + 5 + 9 + 7 + Menu
1 + 6 + 2 + 5 + 9 + 6 + Menu/Status
1 + 2 + 3 + 6 + 5 + 4

Die Menüeinträge können mit CURSOR HOCH/RUNTER angesprochen werden. Die Einträge selbst mit CURSOR LINKS/Rechts verändert werden.
Manche Einstellungen können aktiviert und deaktiviert werden, dazu die OK Taste drücken.
Achtung: Nur anfassen, wenn man weiß was man macht! Falsche Einstellungen können das Gerät beschädigen!

Linux – Recursiv Dateien in Unterordnern entpacken und löschen

Entpacken von allen Archiven in ihren eigenen Unterordnern:

find /pfad/Ordner -name '*.rar' -execdir unrar e -o- {} \;

Aufklärung der Parameter für unrar:
e = extract (alternativ x = behält die Verzeichnisstruktur)
-o- = Kein überschreiben von Dateien, wenn diese schon existieren.
Anschließend löschen wir alle Dateien die dem Winrar Dateimuster (.rar; .r01; usw…) entsprechen:

find . -type f -name "*.r??" -exec rm {} \;

Dell Inspiron 3480 – Under the hood

Da die Spezifikationen des Dell Inspiron 3480 nicht 100%ig wiederspiegeln, welche Anschlüsse auf dem Mainboard noch frei sind, habe ich mir erlaubt ein paar Screenshots des aufgeschraubten Gerätes zu zeigen.

Wie man sieht gibt es
1 x M.2 Anschluss
1 x 2,5 HDD Sata Anschluss
sowie
2 x SODIMM Bänke für DDR 4 Speicher

den Akku sowie die Mainboard Batterie lassen sich noch eigenständig tauschen und sind zum Glück nicht verklebt.

Schrauben für den Einbau einer 2,5 Zoll Festplatte liegen sogar am Klebeband befestigt bei.

FATA: Module wireguard not found – Kernel modul fixen

Ich spare mir die Erläuterung was wireguard ist und macht, das gibt es denke ich zur genüge.

Was man wissen sollte ist: Wireguard ist nicht direkt im Linux Kernel enthalten, und basiert auf einer Erweiterung (Modul) dazu.
Das bedeutet, wenn man Wireguard installiert und anschließend Updates des Kernel macht, kann es sein das Wireguard nicht mehr funktioniert. Dann muss nämlich das Kernel-Modul neu (für die neue Kernel Version) kompiliert werden.

Beim Installieren unter Debian 9 kam ich auf folgende Meldung:

Vorbereitung zum Entpacken von .../12-wireguard_0.0.20190905-1_all.deb ...
Entpacken von wireguard (0.0.20190905-1) ...
make (4.1-9.1) wird eingerichtet ...
sudo (1.8.19p1-2.1) wird eingerichtet ...
linux-headers-4.9.0-11-common (4.9.189-3) wird eingerichtet ...
wireguard-tools (0.0.20190905-1) wird eingerichtet ...
linux-compiler-gcc-6-x86 (4.9.189-3) wird eingerichtet ...
dkms (2.3-2) wird eingerichtet ...
linux-kbuild-4.9 (4.9.189-3) wird eingerichtet ...
Trigger für libc-bin (2.24-11+deb9u4) werden verarbeitet ...
libfakeroot:amd64 (1.21-3.1) wird eingerichtet ...
Trigger für systemd (232-25+deb9u11) werden verarbeitet ...
wireguard-dkms (0.0.20190905-1) wird eingerichtet ...
Loading new wireguard-0.0.20190905 DKMS files...
Building for 4.9.0-4-amd64
Module build for kernel 4.9.0-4-amd64 was skipped since the
kernel headers for this kernel does not seem to be installed.
linux-headers-4.9.0-11-amd64 (4.9.189-3) wird eingerichtet ...
fakeroot (1.21-3.1) wird eingerichtet ...
update-alternatives: /usr/bin/fakeroot-sysv wird verwendet, um /usr/bin/fakeroot (fakeroot) im automatischen Modus bereitzustellen
wireguard (0.0.20190905-1) wird eingerichtet ...
Module build for kernel 4.9.0-4-amd64 was skipped since the
kernel headers for this kernel does not seem to be installed.

  Ein Reconfigure des Modules brachte auch keine Besserung:

# dpkg-reconfigure wireguard-dkms
-------- Uninstall Beginning --------
Module: wireguard
Version: 0.0.20190905
Kernel: 4.9.0-11-amd64 (x86_64)
-------------------------------------
Status: Before uninstall, this module version was ACTIVE on this kernel.
wireguard.ko:
- Uninstallation
- Deleting from: /lib/modules/4.9.0-11-amd64/updates/dkms/
- Original module
- No original module was found for this module on this kernel.
- Use the dkms install command to reinstall any previous module version.
depmod.....
DKMS: uninstall completed.
------------------------------
Deleting module version: 0.0.20190905
completely from the DKMS tree.
------------------------------
Done.
Loading new wireguard-0.0.20190905 DKMS files...
Building for 4.9.0-4-amd64
Module build for kernel 4.9.0-4-amd64 was skipped since the
kernel headers for this kernel does not seem to be installed.

  Testen ob das Wireguard Module geladen ist:

modprobe wireguard
modprobe: FATAL: Module wireguard not found in directory /lib/modules/4.9.0-4-amd64

 Ursache: Die notwendigen Pakete zum Kompilieren waren nicht vorhanden.

Lösung: Fehlenden Pakete installieren und ein Reconfigure des wireguard-modules machen.

apt-get install libmnl-dev libelf-dev linux-headers-$(uname -r) build-essential pkg-config
# dpkg-reconfigure wireguard-dkms
------------------------------
Deleting module version: 0.0.20190905
completely from the DKMS tree.
------------------------------
Done.
Loading new wireguard-0.0.20190905 DKMS files...
Building for 4.9.0-11-amd64
Building initial module for 4.9.0-11-amd64

 

Freenas 11 – Fix "Boot failed efi misc device"

In einer frisch angelegten Ubuntu 16.04.4 VM unter der bhyve Virtualisierungsplattform in Freenas hatte ich das Problem, dass die VM nicht korrekt unter UEFI bootete.
Bei jedem Neustart hing die Maschine im EFI und zeigte: „boot failed efi misc device“ an. Wie sich im Freenas Forum herausstellte, ist man nicht der einzige mit dem Problem.
Im Efi selbst kann man dann zwar via „exit“ in in den „Boot Maintenance Manager“ gelangen und unter „Boot File“ auch die grubx64.efi zum Starten auswählen. Allerdings ist das Prozedere beim nächsten Neustart wieder notwendig.
Was ist die Ursache?
Warum auch immer wird der Bootloader unter folgendem Pfad vermutet:

 root@ubuntu:/boot/efi# ls /boot/efi/EFI/BOOT/bootx64.efi
/boot/efi/EFI/BOOT/bootx64.efi

Dies war bei mir nicht der Fall, also musste ich den BOOT Ordner anlegen und kopierte die grubx64.efi als bootx64.efi in das Verzeichnis, sodass es wie folgt aussieht:

mkdir /boot/efi/EFI/BOOT
cp /boot/efi/ubuntu/grubx64.efi /boot/efi/EFI/BOOT/bootx64.efi
root@ubuntu:/boot/efi# tree -L 3 .
.
└── EFI
├── BOOT
│   └── bootx64.efi
└── ubuntu
├── grub.cfg
├── grubx64.efi
├── mmx64.efi
└── shimx64.efi
3 directories, 5 files

Anschließend die VM neustarten um zu prüfen ob alles korrekt funktioniert hat.

HAProxy vor Squid Proxy – Client IP-Adressen weiterleiten

Verwendet man einen Loadbalancer wie z.B. HAProxy um Webzugriffe von Clients auf mehrere Squid Proxy Server zu verteilen, sieht es im access.log des Squid Proxy so aus, als kämen die Zugriffe alle vom HAProxy nicht vom eigentlichen Client. Da das HTTP Forwarding des HAProxy auf Applikationsebene basiert, ist dieses Verhalten korrekt. Wenn man TCP Offloading machen würde, wäre dies wahrscheinlich nicht der Fall.

Um beim HTTP Forwarding dennoch die originale Client-IP im Squid access.log zu sehen, kann man diese über den HTTP Header X-Forwarded-For (Beschreibung) weiterleiten.

In Squid kommen die Requests alle von der IP-Adresse des HAProxy:

1514450659.711  40186 10.0.0.5 TCP_MISS/200 31540 CONNECT images.outbrain.com:443 - HIER_DIRECT/2.19.240.34 -
1514450660.977  40078 10.0.0.5 TCP_MISS/200 3753 CONNECT www.summerhamster.com:443 - HIER_DIRECT/52.27.8.169 -

In HAProxy müssen die folgenden beiden Optionen gesetzt werden. Diese setzen den Header „X-Forwarded-For“ auf die Client IP-Adresse. Dadurch wird die eigentliche Client IP im Header mitgegeben:

option http-server-close
option forwardfor

Der Squid Proxy registriert den veränderten Header, verwirft ihn aber aus Sicherheitsgründen standardmäßig – sofern nicht anderweitig konfiguriert. Also muss in der Konfiguration des Squid der QuellIP des HAProxy vertraut werden. Dies wird dementsprechend über eine acl in der squid.conf angepasst:

acl haproxy src 10.0.0.5
follow_x_forwarded_for allow haproxy

Abschließend den Squid neustarten und den Webzugriff über ein Client testen. Wie man nun im access.log sieht, ist die Client-IP jetzt korrekt weitergeleitet.

1514451557.721      5 10.0.0.10 TCP_MISS/200 910 POST http://ocsp.digicert.com/ - HIER_DIRECT/93.184.220.29 application/ocsp-response
1514451557.749      5 10.0.0.10 TCP_MISS/200 2194 POST http://ocsp2.globalsign.com/gsalphasha2g2 - HIER_DIRECT/104.31.74.124 application/ocsp-response

Exchange 2016 – Enable & Troubleshoot Certificate Based Authentication for OWA/Active Sync

Um die zertifikatsbasierte Authentifizierung des Exchange 2016 zu aktivieren empfehle ich, sich an folgenden Technet-Artikel zu halten. Dieser beschreibt die Konfiguration schritt für schritt.
Der anschließende Test war jedoch wenig erfolgreich und brachte auf den Client Geräten immer den Fehler „Anmeldung fehlgeschlagen“. Die Analyse des IIS Logfiles bestätigte in dem Fall die Fehlermeldung:

2018-01-17 14:14:41 W3SVC1 MSEXCHSRV 10.0.1.212 OPTIONS /Microsoft-Server-ActiveSync/default.eas Cmd=OPTIONS&User=domain%5CUser.Name&DeviceId=SEC15BF1D9F90A8E&DeviceType=SamsungDevice 443 - 10.0.0.213 HTTP/1.1 Android-SAMSUNG-SM-G955F/101.700 - - oma.fqdn.net 403 16 2148204809 184 375 452
2018-02-22 08:24:54 W3SVC3 EXCHANGESRV 10.0.1.212 GET / - 9943 - 10.0.0.5 HTTP/1.1 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/63.0.3239.132+Safari/537.36 - - exchangesrv.fqdn.info:9943 403 16 2148204809 1423 434 4230

Da der Microsoft Exchange Health Manager (+ Recovery) durchgängig Testaufrufe machen, wird das IIS Logfile schnell unübersichtlich gefüllt. Daher hatte ich einfach eine neue Site im IIS Manager erstellt und dort unter einem anderem Port Binding die Authentifizierung via Client Zertifikate getestet. (Unterer Logeintrag) Man kann aber auch den Health Manager Dienst temporär deaktivieren, dass funktioniert auch.
Zurück zur Fehlermeldung, welche im Detail wie folgt aussieht:

403 16 2148204809
  • 403 = HTTP Statuscode (Authentication Failed)
  • 16 = Subfehler (Client certificate is untrusted or invalid.)
  • 2148204809 = Detaillierter Fehlercode (0x800b0109 CERT_E_UNTRUSTEDROOT)

Sucht man nach der Fehlermeldung findet man folgenden Technet-Artikel, der eigentlich auf den IIS 8 bezogen ist. Windows Server verwendet IIS 10 – aber der Artikel trifft auch darauf zu.
Hintergrund: Seit Windows Server 2012 wurden strengere Überprüfungen für die zertifikatsbasierte Authentifizierung eingeführt. Einer dieser Checks prüft ob sich im Zertifikatsspeicher (Trusted Root Certification Authorities) auch wirklich nur sogenannte Root-Zertifikate befinden. Ein Root Zertifikat muss logischerweise immer selbst-signiert sein. Wenn sich dort ein Zertifikat befindet, was von einer anderen Zertifikatstelle ausgestellt wurde, ist dies eigentlich ein „Zwischenzertifikat / Intermediate“ und gehört an einen anderen Zertifikatsspeicherort.
In meinem Fall befand sich das „StartCom Class 3 OV Server CA“ in den Root-CA’s welches den Fehler produzierte. Um den Fehler zu beheben, müssen alle nicht selbst-signierten Zertifikate aus dem Root-CA entfernt bzw. zu den Zwischenzerifikaten verschoben werden.
Um bei der Vielzahl von Zertifikaten nicht alle händisch zu überprüfen kann man dies per Powershell identifizieren:

Get-Childitem cert:\LocalMachine\root -Recurse |
    Where-Object {$_.Issuer -ne $_.Subject}

Um die Zertifikate anschließend in den Speicher für „Intermediate Certification Authorities“ zu verschieben kann man folgenden Befehl nutzen:

Get-Childitem cert:\LocalMachine\root -Recurse |
    Where-Object {$_.Issuer -ne $_.Subject} |
    Move-Item -Destination Cert:\LocalMachine\CA

Anschließend den kompletten Server neustarten. Eventuell reicht auch nur ein Neustart des IIS (W3SVC). Hatte in meinem Fall jedoch nicht ausgereicht.

Winbuilder (Win10PE) hinter Proxy benutzen

Wer sich selbst ein Windows PE erstellen will, kommt um den WindowsBuilder nicht herum. Ein Tool aus der Sammlung, nämlich GetWaikTools (GWT.exe) lädt die Windows Imaging Features (ADK, Dism etc.) herunter und benötigt daher Internetzugriff. Wer hinter einem Proxy sitzt, bekommt hier eine Fehlermeldung und muss den Proxy von Hand konfigurieren.
Das Tool verwendet Curl als Downloader, für den über die Umgebungsvariablen ein Proxy eingerichtet werden kann:

C:\>netsh winhttp set proxy http://1.2.3.4:3128
Aktuelle WinHTTP-Proxyeinstellungen:
    Proxyserver     :  http://1.2.3.4:3128
    Umgehungsliste  :  (keine)

Anschließend funktioniert die Verbindung über den Proxyserver 😉