🌐 Auch auf: English · Français · Español
Zeit für ein Geständnis. Nach dem Kriegstagebuch der Nextcloud-Migration, einer zweistelligen Zahl an Playbook-Läufen, einem nftables-Regelwerk, das fröhlich die eigenen Tabellen von K3s geleert hat, und mehr YAML, als ein Mensch in einer einzigen Woche lesen sollte, stand mir Nextcloud, Ansible und alles mit dem Wort „Migration“ offiziell bis hier.
Also habe ich gemacht, was jeder vernünftige Linux-Nerd tut, wenn er von Linux ausgebrannt ist: Ich bin auf die andere Seite gewechselt. Drei Server, drei frische Installationen von Windows Server 2025 und ein paar Abende mit Active Directory, DNS, DHCP, Gruppenrichtlinien, Storage Spaces und BitLocker. Kein YAML. Nur jede Menge Get- und Set-.
Damit das klar ist: Das hier ist keine Bekehrungsgeschichte. Ich fahre jetzt zweigleisig. Linux bleibt, wo es ist, und erledigt weiter die schwere Arbeit, während ich privat die Microsoft-Seite richtig lernen will, und zwar speziell den Server. Nicht „so lange auf Weiter klicken, bis es läuft“. Sondern verstehen, was ein Domänencontroller beim Booten tut, warum DHCP-Failover so aussieht, wie es aussieht, und was eine Gruppenrichtlinie eigentlich in die Registry schreibt. Das Homelab ist das Klassenzimmer.
Oder weniger förmlich: Ich will einfach eine Weile mit einer echten Windows-Infrastruktur spielen. Domäne, Richtlinien, Dateidienste, Patching, Verschlüsselung, Virtualisierung, das volle Paket, mit genug Maschinen, dass es sich wie eine kleine Firma verhält und nicht wie eine einzelne Test-VM, die ich nach einer Stunde wieder lösche.
🖥️ Die Aufstellung
Drei HP-Kisten, alle mit iLO, alle inzwischen mit Windows Server 2025, alle zu Domänencontrollern in derselben Gesamtstruktur heraufgestuft:
- HP1: Domänencontroller, PDC-Emulator, DNS, DHCP
- HP2: Domänencontroller, DNS, DHCP (Failover-Partner von HP1)
- HP3: Domänencontroller, DNS, dazu drei SSDs in einem Storage-Spaces-Pool, und der künftige zentrale Dateiserver im Haus
Die Domäne heißt muench.home.arpa. home.arpa ist die Zone, die RFC 8375 genau dafür reserviert: Heimnetze. Kein falsches .local mehr, das sich mit mDNS prügelt, und keine öffentliche Domain registrieren, nur um ein Lab zu benennen.
Drei DCs für einen Haushalt sind objektiv übertrieben. Genau darum geht es. Mit dreien kann ich einen abschalten, neu starten oder kaputt machen und trotzdem zusehen, wie die anderen beiden weitermachen. Wie sich herausstellte, durfte ich genau das beobachten (mehr dazu unten).
Und ja, die alten Gewohnheiten sind mitgekommen. Ich klicke mich nicht auf drei Maschinen durch den Server-Manager. Alles läuft remote über WinRM von meiner Linux-Jumpbox aus, mit pywinrm. Alte Gewohnheiten sterben langsam, aber immerhin sprechen sie jetzt PowerShell.
Erster Stolperstein der Reise: WinRM schickt das Skript als Base64 über die Kommandozeile, und Windows begrenzt eine Kommandozeile auf 8191 Zeichen. Alles, was länger ist, schlägt nicht fehl. Es passiert einfach still und leise nichts. Der Workaround: Skripte in kleinen Häppchen hochladen, auf dem Ziel einen SHA256 prüfen, dann ausführen. Sehr Windows, sehr lehrreich.
Zweiter Stolperstein: Ich habe den OpenSSH-Server als manuellen Fallback eingeschaltet, und Port 22 lief von außen in einen Timeout, obwohl der Dienst lief und die Firewall-Regel „aktiviert“ sagte. Die automatisch angelegte Regel galt nur für das Profil Privat. Ein Server in der Domäne läuft aber im Profil Domäne. Ein Set-NetFirewallRule -Profile Domain,Private später ging es.
🤖 Mein Co-Admin ist eine KI (und nein, das ist kein „Vibe-Admin“)
Ganz offen zu dieser WinRM-Pipeline: Ich bin nicht der Einzige, der sie benutzt. Wenn ich nicht weiterkomme, verbindet sich Claude (die KI von Anthropic, die als Claude Code auf der Linux-Jumpbox läuft) über genau diese WinRM-Schnittstelle mit den Servern und hilft bei der Konfiguration. Claude liest den aktuellen Zustand, schlägt Änderungen vor, erklärt sie, setzt sie um, nachdem ich Ja gesagt habe, und prüft danach das Ergebnis.
Wie das in der Praxis funktioniert, denn Magie ist keine im Spiel: Claude läuft in einem Terminal auf der Linux-Kiste und kann dort Shell-Befehle ausführen. Für schnelle Einzeiler ruft es die Server direkt über pywinrm auf. Für alles Größere sieht der Ablauf so aus:
1. write a PowerShell script locally (check_hp2.ps1, gpo_bitlocker.ps1, …)
2. open a WinRM session to the server (HTTP 5985, NTLM, message-encrypted)
3. upload the script in ~1200-char base64 chunks → C:\Temp\
4. compare SHA256 locally vs. on the server → abort if they differ
5. execute it, collect stdout + errors (unwrapping PowerShell's CLIXML error stream)
6. read the output, decide the next step → back to 1Der gestückelte Upload und die Prüfsumme gibt es wegen der 8191-Zeichen-Grenze aus dem Stolperstein oben: Ein Skript, das unterwegs abgeschnitten wird, ist schlimmer als eins, das gar nicht ankommt. Die Skripte sind ganz normale .ps1-Dateien, ich kann also jedes einzelne vor oder nach der Ausführung lesen. Das ist auch der schöne Nebeneffekt: Am Ende einer Sitzung bleibt ein Stapel lesbares PowerShell übrig, der genau zeigt, was gemacht wurde, und daraus kann ich lernen.
Den Begriff Vibe Coding hast du wahrscheinlich schon gehört. Andrej Karpathy hat ihn Anfang 2025 geprägt, für eine Art zu programmieren, bei der du in normaler Sprache beschreibst, was du willst, die KI den Code schreiben lässt und mehr oder weniger alles übernimmst, was dabei herauskommt, ohne genau hinzuschauen. Es geht um Code, und der „Vibe“-Teil ist genau das Nicht-Prüfen.
Was ich hier mache, ist die Admin-Version der ersten Hälfte, aber ganz bewusst nicht der zweiten. Eine KI ungeprüfte Befehle auf die eigenen Domänencontroller abfeuern zu lassen, wäre „Vibe-Admin“, und das ist ein hervorragender Weg, die eigene Backup-Strategie aus nächster Nähe kennenzulernen. Deshalb gelten diese Grundregeln:
- Erst lesen, dann ändern. Jede Aufgabe beginnt mit einer reinen Bestandsaufnahme dessen, was tatsächlich konfiguriert ist, nicht dessen, was wir für konfiguriert halten.
- Ich entscheide, die KI führt aus. Änderungen passieren, nachdem ich zugestimmt habe, und bei allem Destruktiven gibt es vorher eine ausdrückliche Rückfrage.
- Von der anderen Seite prüfen. Eine GPO ist nicht fertig, wenn
New-GPOzurückkommt. Sie ist fertig, wenn der Registry-Wert auf dem Zielrechner auftaucht. DHCP-Failover ist erst repariert, wenn beide Partner die neue Einstellung melden. - Das Warum erklären. Ich will Windows Server lernen, nicht auslagern. Also stelle ich viele „Warum ist das so?“-Fragen, und einige der besten Teile dieses Beitrags sind aus diesen Antworten entstanden.
Ein echtes Beispiel aus der Sitzung, in der ich diesen Beitrag geschrieben habe: Wir wollten in der DHCP-Failover-Beziehung die automatische Übernahme aktivieren. Das Cmdlet auf HP1 antwortete trotz Domänen-Admin-Rechten mit einem schlichten PermissionDenied. Claude hat das Muster erkannt: der klassische Double Hop. Ich war remote an HP1 angemeldet, das Cmdlet muss gleichzeitig die Einstellung auf HP2 ändern, und HP1 darf meine Anmeldedaten nicht an eine dritte Maschine weiterreichen. Die Lösung war ein einmaliger geplanter Task, der lokal auf HP1 mit einer richtigen Anmeldung läuft und danach wieder gelöscht wird. Anschließend haben wir die Einstellung auf beiden Partnern geprüft. Dafür hätte ich eine Stunde gegoogelt. Stattdessen gab es eine Zehn-Minuten-Lektion darüber, wie Credential Delegation unter Windows funktioniert.
Ein Ersatz fürs Verstehen ist das nicht. Die KI ist schnell und weiß viel, macht aber auch Fehler, und auf dieser Reise hat sie eine PowerShell-Variable überschrieben, weil sie vergessen hatte, dass Variablennamen dort nicht zwischen Groß- und Kleinschreibung unterscheiden. Es ist eher wie Pair Programming mit einem Kollegen, der jeden jemals geschriebenen Microsoft-Learn-Artikel gelesen hat, nie genug von Fragen bekommt und dessen Arbeit du trotzdem reviewst.
🌐 DNS: der Teil, ohne den AD nicht leben kann
Active Directory ist im Kern ein sehr eigenwilliger DNS-Konsument. Clients finden ihre Domänencontroller über SRV-Einträge (_ldap._tcp.dc._msdcs...), wenn also DNS falsch ist, ist alles falsch, meist auf verwirrende Weise. Es gilt das uralte Sysadmin-Haiku: Es ist nicht DNS. / Es kann nicht DNS sein. / Es war DNS.
Alle drei DCs betreiben AD-integriertes DNS, die Zonen replizieren also mit dem Verzeichnis selbst statt über Zonentransfers. Alle drei sind außerdem globale Kataloge, und DHCP verteilt alle drei als DNS-Server, sodass jeder einzelne verschwinden kann, ohne dass die Clients es merken:
PS> Get-DhcpServerv4OptionValue -ScopeId $scope -OptionId 6
OptionId Name Type Value
-------- ---- ---- -----
6 DNS Servers IPv4Address {…, …, …}Drei Einträge. Die Reihenfolge der Resolver ist ohnehin Sache des Clients, aber immerhin kennt jeder Client alle drei Türen.
📦 Die FritzBox wird degradiert
Bisher hat meine FritzBox gemacht, was jeder Consumer-Router macht: DHCP und DNS fürs ganze Haus. Mit Active Directory funktioniert das nicht. Domänenmitglieder müssen die Domänencontroller als DNS-Server verwenden, denn nur die DCs kennen die SRV-Einträge, die einem Client sagen, wo seine Domäne wohnt. Den Router als DNS zu verteilen, ist die klassische AD-Fehlkonfiguration: Der Domänenbeitritt scheitert, GPOs greifen still und leise nicht, und Anmeldungen dauern ohne erkennbaren Grund fünf Minuten.
Also ist der DHCP-Server in der FritzBox abgeschaltet, DHCP läuft jetzt als Rolle auf den Windows-Servern (siehe unten) und verteilt die drei DCs als DNS-Server, nicht die FritzBox.
Arbeitslos ist die FritzBox trotzdem nicht. Sie bleibt das Standard-Gateway, der gesamte Internetverkehr verlässt das Haus also weiterhin über sie. Und die DCs leiten jede DNS-Anfrage, für die sie nicht zuständig sind, also alles außerhalb von muench.home.arpa, an die FritzBox weiter, die dann draußen in der Welt nachfragt. Eine saubere Arbeitsteilung: Windows kennt das Haus, die FritzBox kennt das Internet.
client ──DHCP────► HP1 / HP2 address, gateway = FritzBox, DNS = the 3 DCs
client ──DNS─────► any DC ──┬─ *.muench.home.arpa → answers itself
└─ everything else → forwards to FritzBox → internet
client ──traffic─► FritzBox (default gateway) ──────────────────────────► internetDie FritzBox wurde von „schmeißt den Laden“ zu „bewacht die Haustür“ degradiert. Sie hat es überraschend gut weggesteckt.
📡 DHCP-Failover: die Überraschung mit den Paaren
Mein Plan war einfach: drei Server, drei DHCP-Knoten, alle in einem glücklichen Failover-Verbund.
Windows hatte andere Pläne. DHCP-Failover funktioniert strikt paarweise. Eine Failover-Beziehung hat genau zwei Partner, und ein Bereich kann nur zu einer Beziehung gehören. Es gibt keinen Dreiermodus, kein Quorum, kein Mesh. Windows-DHCP lebt streng monogam. Also wurde die dritte DHCP-Rolle wieder deinstalliert, und HP1 und HP2 teilen sich den Bereich jetzt im Lastenausgleichsmodus: Sie teilen den Adresspool 50/50 auf und synchronisieren die Leases untereinander.
PS> Get-DhcpServerv4Failover | Select Name, Mode, State
Name Mode State
---- ---- -----
hp1-…-hp2 LoadBalance NormalDer Pool selbst ist bewusst langweilig: ein /24, und der dynamische Bereich reicht von .70 bis .245. Das sind 176 Adressen für Laptops, Handys, Fernseher und was sonst noch zur Tür hereinspaziert. Alles unterhalb von .70 ist statisch konfiguriert und bleibt außerhalb des Pools: der Router, die Server, ihre iLO-Schnittstellen und die übrige Infrastruktur, die sich nie bewegen soll. Das obere Ende bleibt als Reserve frei.
PS> Get-DhcpServerv4Scope | Select ScopeId, StartRange, EndRange, LeaseDuration
ScopeId StartRange EndRange LeaseDuration
------- ---------- -------- -------------
192.168.10.0 192.168.10.70 192.168.10.245 8.00:00:00
Option 3 Router
Option 6 DNS Servers (all three DCs)
Option 15 DNS Domain Name muench.home.arpaEin paar Details, die man kennen sollte:
- 8 Tage Lease-Dauer. In einem Haushalt, in dem jeden Tag dieselben Geräte wiederkommen, bedeuten lange Leases weniger Geplapper. Sie bedeuten aber auch, dass ein DHCP-Ausfall tagelang statt minutenlang unbemerkt bleibt.
- 50/50-Lastenausgleich. Beide Server antworten, und jeder ist für die Hälfte der Clients zuständig (entschieden über einen Hash der MAC-Adresse). Fällt ein Partner weg, bedient der andere weiterhin alle und verlängert auch die Clients seines Partners, in Schritten, die durch die MCLT begrenzt sind. Nach 60 Minuten ohne Kontakt wechselt er automatisch in
PartnerDownund übernimmt den gesamten Pool. (Dieser automatische Wechsel war standardmäßig aus, und ich habe ihn erst beim Schreiben dieses Beitrags eingeschaltet.) - MCLT von einer Stunde. Die Maximum Client Lead Time begrenzt, wie weit ein Server eine Lease über das hinaus verlängern darf, was sein Partner davon weiß. Das ist der Sicherheitsabstand, der verhindert, dass zwei Server dieselbe Adresse vergeben, nachdem sie den Kontakt verloren haben.
- Dynamische DNS-Updates. Clients registrieren sich selbst in den AD-Zonen, damit ist jeder Laptop per Name erreichbar, und DHCP löscht den Eintrag, wenn die Lease abläuft.
- Autorisierung im AD. Ein Windows-DHCP-Server vergibt erst Leases, wenn er im Active Directory autorisiert ist. Ein wilder DHCP-Server, den irgendein wohlmeinender Mensch einsteckt, bleibt stumm, solange es ein Windows-Server ist.
Zum Zeitpunkt des Schreibens liegt die Auslastung des Pools bei sagenhaften 3 %. Kapazitätsplanung auf Enterprise-Niveau.
Noch eine kleine Lektion: Ich wollte alle statisch konfigurierten Geräte unterhalb des dynamischen Bereichs als „Doku-Reservierungen“ direkt in der DHCP-Konsole festhalten. Pustekuchen. Add-DhcpServerv4Reservation akzeptiert nur Adressen innerhalb des Bereichs. DHCP ist keine CMDB, und das lässt es dich auch wissen.
🔐 Secure Boot, oder: wie ein DC auf seine Freunde wartet
Alle drei Maschinen wurden mit UEFI/GPT und einem TPM 2.0 an Bord installiert, aber Secure Boot war in der Firmware noch aus. Also war heute BIOS-Rundgang angesagt: ein Server nach dem anderen, Schalter umlegen, neu starten, prüfen.
„Einer nach dem anderen“ wurde zu einer kleinen Lektion für sich. HP2 kam wieder hoch, während HP1 noch mitten im Neustart steckte, und etwa sieben Minuten lang antwortete HP2 auf Ping, hatte alle Ports offen … und lehnte jede einzelne Anmeldung mit HTTP 401 ab. Licht an, aber keiner zu Hause.
Kaputt war nichts. Ein frisch gebooteter Domänencontroller will eine erste Synchronisierung mit seinen Replikationspartnern abschließen, bevor er seine Rolle als DC voll übernimmt. Einer dieser Partner starrte noch auf einen POST-Bildschirm, also wartete HP2 höflich auf einen Timeout. Sobald HP1 zurück war, wurde alles wieder grün: Replikation ohne Fehler, DHCP-Failover von CommunicationInterrupted zurück auf Normal.
Lektion notiert: Starte deine Domänencontroller nicht parallel neu. Was direkt zum nächsten Thema führt.
🪦 WSUS: im Kopf installiert, in der Realität abgekündigt
Für jeden Windows-Admin eines gewissen Alters heißt „Patch-Management“ WSUS. Es stand auf meiner Liste: auf HP2 installieren, den Katalog synchronisieren, Updates freigeben, sich wie ein echtes Unternehmen fühlen und zusehen, wie die SUSDB wächst wie ein Sauerteig, um den niemand gebeten hat.
Dann habe ich das Kleingedruckte gelesen. 2024 hat Microsoft WSUS offiziell auf die Liste der abgekündigten Features gesetzt. Es wird mit Server 2025 noch ausgeliefert und funktioniert weiter, bekommt aber keine neuen Funktionen mehr, und die gesamte Entwicklung fließt in die Cloud-Seite: Windows Autopatch, Intune und Azure Update Manager. Ein Produkt in dem Jahr zu lernen, in dem es für den Ruhestand vorgemerkt wird, fühlte sich an, als würde ich für eine Prüfung lernen, die schon abgesagt ist. (Außerdem ist WSUS mit seiner Datenbank und IIS auf einem Domänencontroller nicht gerade Best Practice.)
Also kommen die Updates direkt von Microsoft, und die Gruppenrichtlinie steuert, wann. Womit wir beim eigentlichen Star dieses Beitrags wären.
📜 Gruppenrichtlinien: das YAML der Windows-Welt
Wenn Ansible bedeutet „beschreib den Sollzustand und lass ein Werkzeug ihn durchsetzen“, dann sind Gruppenrichtlinien dieselbe Idee, seit 2000 ins Betriebssystem eingebaut. Ausgeliefert werden sie außerdem von den Domänencontrollern selbst und alle 90 Minuten erneut angewendet, ganz ohne Playbook-Lauf. Ich gebe zu, ich bin ein bisschen beeindruckt. Erzähl das bitte nicht meinen Ansible-Rollen.
Das hier ist jetzt in der Domäne aktiv, alles per PowerShell angelegt (New-GPO, Set-GPRegistryValue, New-GPLink) und danach überprüft, indem ich die tatsächlichen Registry-Werte auf den Zielrechnern zurückgelesen habe:
1. Verbundene Netzlaufwerke. HP3 hat pro Benutzer einen Ordner und eine SMB-Freigabe (\\HP3\user1, \\HP3\user2, …). Jeder Benutzer besitzt seinen eigenen Ordner mit Vollzugriff sowohl in den NTFS- als auch in den Freigabeberechtigungen, dazu zugriffsbasierte Aufzählung, sodass du die Ordner, die du nicht öffnen darfst, nicht einmal siehst. Die Benutzerkonten liegen in einer eigenen OU, und eine einzige GPO verbindet die Laufwerksbuchstaben. Gruppenrichtlinien-Einstellungen mit Zielgruppenadressierung auf Elementebene entscheiden, wer was bekommt: user1 (das bin ich, der Admin im Haus) bekommt alle Laufwerke, user2 nur das eigene. Die Pfade verwenden den Servernamen statt der IP, damit die Authentifizierung über Kerberos läuft, statt auf NTLM zurückzufallen.
2. Windows Update für die Clients. Mein Desktop und mein Laptop laufen selten über Nacht, „um 3 Uhr installieren“ bringt bei ihnen also nichts. Stattdessen:
- Qualitätsupdates um 3 Tage verzögert, damit der Rest des Internets die kaputten Patches zuerst findet
- Feature-Version festgenagelt, also kein Überraschungs-Upgrade auf das nächste Windows-11-Release
- Fristen von 3 Tagen (Qualität) und 7 Tagen (Feature), plus 2 Tage Kulanz, danach wird neu gestartet, ob es mir passt oder nicht. Windows Update war schon immer ein „ob es dir passt oder nicht“-Produkt; jetzt suche wenigstens ich das Datum aus
- Aktive Stunden 07:00–23:00
- „Updates installieren und herunterfahren“ im Ein/Aus-Menü, damit das Herunterfahren am Abend die Arbeit erledigt
- Übermittlungsoptimierung auf das LAN beschränkt, damit Updates nur einmal fürs ganze Haus heruntergeladen werden
3. Windows Update für die Server: gestaffelt. Eine Basis-GPO auf der OU Domain Controllers (automatisch herunterladen, nach Zeitplan installieren), dazu pro Server eine kleine Zeitplan-GPO mit Sicherheitsfilterung, sodass jede für genau eine Maschine gilt:
HP3 Saturday 03:00 ← the canary
HP1 Sunday 03:00
HP2 Sunday 05:00HP3 ist der Kanarienvogel im Patch-Bergwerk: Er bekommt die Updates einen Tag vor den anderen. Wenn ein kumulatives Update etwas kaputt macht, merke ich das am Samstag und habe noch einen Tag, um den Rest aufzuhalten. Und HP1 und HP2 starten nie gleichzeitig neu. Warum das wichtig ist, steht im vorigen Abschnitt.
Kleine Nebenfalle bei der Sicherheitsfilterung: Wenn du „Authentifizierte Benutzer“ aus dem Filter entfernst, braucht die Gruppe trotzdem noch Lesen auf der GPO, sonst kann sie niemand mehr lesen (schöne Grüße von MS16-072). Der Computer selbst bekommt Übernehmen, und Authentifizierte Benutzer behalten Lesen.
4. Dunkler Modus, und tschüss Spotlight. Rein kosmetisch und genau mein Geschmack: Jeder Benutzer im Haus bekommt den dunklen Modus für Windows und Apps, dazu einen schlicht schwarzen Desktop. Kein Windows-Blickpunkt (Spotlight), und keine wechselnden „Wusstest du, dass dieser Berg in Norwegen steht?“-Fotos mit einem Hotspot, der dich einlädt, mehr zu erfahren. Spotlight ist im Grunde ein Bildschirmschoner mit Marketingabteilung.
Der Haken war hier die Edition. Die offizielle Richtlinie „Turn off all Windows spotlight features“ funktioniert nur unter Windows Enterprise und Education. Meine Clients laufen mit Windows 11 Pro, wo die Richtlinie schlicht ignoriert wird. Der Workaround sind die Gruppenrichtlinien-Einstellungen (Preferences): Statt einer offiziellen Richtlinie schreibt die GPO genau die Registry-Werte, die auch die Einstellungen-App selbst setzen würde:
HKCU\…\Themes\Personalize AppsUseLightTheme = 0 # dark apps
HKCU\…\Themes\Personalize SystemUsesLightTheme = 0 # dark taskbar/start
HKCU\…\Explorer\Wallpapers BackgroundType = 1 # solid color, kills Spotlight
HKCU\Control Panel\Colors Background = "0 0 0" # black
HKCU\Control Panel\Desktop Wallpaper = ""Die Aktion steht auf Aktualisieren, ein Benutzer kann den Hintergrund also ändern, aber die nächste Richtlinienaktualisierung stellt ihn wieder auf Schwarz. Obendrauf setzt die GPO die offizielle Richtlinie „Turn off Spotlight collection on Desktop“, als Gürtel und Hosenträger für den Tag, an dem eine Maschine auf Enterprise aufgerüstet wird. Die Änderungen greifen bei der nächsten Anmeldung.
5. BitLocker. Das verdient einen eigenen Abschnitt.
🔒 BitLocker: Wovor schützt es eigentlich?
Bevor ich irgendetwas einschalte, wollte ich ein klares Bedrohungsmodell, denn „Verschlüsselung = sicher“ ist zu einfach.
BitLocker schützt ruhende Daten. Sein Job ist der gestohlene Laptop, die aus einem Server gezogene Platte oder die SSD, die auf Garantie zurückgeht. Was es nicht tut: ein laufendes, entsperrtes System schützen. Malware, ein kompromittiertes Konto oder ein schwaches Passwort sehen alles im Klartext, genau wie vorher.
Dann kommt die Frage, wie der Schlüssel entsperrt wird:
- Nur TPM: Das TPM gibt den Schlüssel frei, wenn die Bootkette unverändert ist. Das ist bequem und schützt die ausgebaute Platte. Aber die ganze Maschine bootet von allein bis zum Anmeldebildschirm, wird also die komplette Maschine gestohlen, ist das einzige Hindernis für den Dieb die Windows-Anmeldung.
- TPM + PIN: zusätzlich eine PIN, bevor Windows überhaupt startet. Das gestohlene Gerät ist jetzt nur noch ein Ziegelstein mit verschlüsselter Platte, oder ein sehr teurer Briefbeschwerer mit Lüfter. Weniger bequem, aber für einen Laptop, der mit mir unterwegs ist, die richtige Wahl.
Das Lustige daran: Ich hatte BitLocker auf meinem Laptop schon am Vortag eingeschaltet, nur mit TPM und ohne PIN. Gute Nachricht: Die PIN lässt sich nachträglich hinzufügen. Sie ist nur eine zusätzliche Schlüsselschutzvorrichtung, und nichts wird neu verschlüsselt:
manage-bde -protectors -add C: -TPMAndPINDer Haken: Windows erlaubt eine Pre-Boot-PIN nur, wenn eine Richtlinie das zulässt. Also, Überraschung, noch eine GPO. In der Domäne gibt es jetzt zwei BitLocker-Richtlinien:
- Alle Clients: BitLocker wird auf dem Betriebssystemlaufwerk automatisch aktiviert, und der Wiederherstellungsschlüssel wird im Active Directory gesichert. Keine Schlüssel mehr in einer Textdatei auf irgendeiner Freigabe oder auf einem Klebezettel unter der Tastatur. Wir haben das alle schon gesehen. Manche von uns haben es selbst geschrieben.
- Der Laptop: TPM + PIN ist beim Start Pflicht, über eine eigene GPO mit Sicherheitsfilterung auf genau diese Maschine.
Mit den GPOs an Ort und Stelle sind die nächsten Schritte gpupdate /force, die PIN-Schutzvorrichtung hinzufügen und dann prüfen, ob der Wiederherstellungsschlüssel wirklich im Computerobjekt im AD auftaucht. Ein Backup, das du nie geprüft hast, ist eine Hoffnung, kein Backup.
Als Nächstes kommen die Server dran, angefangen mit HP3. Als künftiger zentraler Dateiserver bekommt er auch das Storage-Spaces-Volume verschlüsselt, und die Schlüssel landen im AD. Für einen Server, der unbeaufsichtigt wieder hochkommen muss, ist „nur TPM“ die pragmatische Wahl, denn niemand will um 3 Uhr nachts nach einem Patch-Neustart eine PIN ins iLO tippen.
💾 Storage Spaces: RAID 5 nach Microsoft-Art
HP3 hat drei 2-TB-SATA-SSDs für Daten bekommen (das Betriebssystem liegt auf einer separaten SSD). Unter Linux hätte ich zu mdadm oder OpenZFS RAIDZ1 gegriffen. Unter Windows ist das Gegenstück Storage Spaces: ein Pool aus den physischen Platten, darauf ein virtueller Datenträger mit Parität als Resilienz (einfache Parität bei drei Platten, also im Geiste RAID 5), formatiert mit ReFS:
PS> New-StoragePool -FriendlyName BackupPool -PhysicalDisks $disks ...
PS> New-VirtualDisk -StoragePoolFriendlyName BackupPool -ResiliencySettingName Parity ...
PS> Format-Volume -FileSystem ReFS ...
D:\ ReFS ~3.6 TB usableDann wurde natürlich gebencht, mit DiskSpd, Microsofts eigenem Storage-Lastgenerator und so etwas wie seiner Antwort auf fio. Wieder einmal über den Weg KI-über-WinRM. Die Methode:
- Werkzeug besorgen: Installiert wird nichts. Der Server lädt selbst die offizielle
DiskSpd.zipaus Microsofts GitHub-Releases nachC:\Temp, entpackt sie und nimmt dasamd64-Binary. Es ist eine einzelne portable.exe. - Testdatei: eine 20-GB-Datei direkt auf dem Paritäts-Volume
D:. - Vier klassische Profile: sequenziell mit 1-MB-Blöcken (ein Thread, Queue Depth 8) und zufällig mit 4-KB-Blöcken (vier Threads, jeweils Queue Depth 32), jeweils einmal lesend und einmal schreibend.
- Faire Bedingungen: 5 Sekunden Aufwärmen, 30 Sekunden Messung,
-Sh, um sowohl den Windows-Dateicache als auch den Schreibcache der Laufwerke zu umgehen (sonst benchst du den RAM),-Lfür Latenz-Perzentile. - Aufräumen: Danach werden Werkzeug und Testdatei wieder gelöscht, und auf dem Server bleibt nur ein freies Volume übrig.
# sequential write, 1 MB blocks
diskspd.exe -b1M -d30 -W5 -o8 -t1 -si -w100 -Sh -L D:\disktest.dat
# random read, 4 KB blocks, 4 threads x QD32
diskspd.exe -b4K -d30 -W5 -o32 -t4 -r -w0 -Sh -L D:\disktest.datEin kleines Hilfsskript auf der Linux-Seite führt jedes Profil über WinRM aus und zieht aus DiskSpds sehr gesprächigem Bericht nur die total:-Zeile und das 99. Perzentil heraus. Und natürlich hat mich der erste Benchmark angelogen, genau wie dd auf der ZFS-Kiste:
Sequential read (1 MB) 20997 MiB/s ← three SATA SSDs. Sure.
Random read (4 KB) 739327 IOPSZwanzig Gigabyte pro Sekunde von drei SATA-Laufwerken mit einem gemeinsamen Schnittstellenlimit von etwa 1,6 GB/s. Der Übeltäter: DiskSpds Schalter -c legt die Testdatei bei jedem Lauf neu an, und ReFS weiß, dass Bereiche, die nie beschrieben wurden, nur Nullen enthalten. Also beantwortet es diese Lesezugriffe aus den Metadaten, ohne je eine Platte anzufassen. Ein sehr schneller Benchmark von absolut nichts. Schrödingers SSD: rasend schnell, solange niemand auf die Daten schaut.
Die Datei einmal mit echten Daten füllen, dann ohne -c messen, und die Realität zeigt sich:
Profile Throughput IOPS avg latency 99th pct
Sequential read (1 MB) 1169 MiB/s 1169 6.8 ms 24 ms
Random read (4 KB, 4x32) 633 MiB/s 162,109 0.55 ms 7.3 ms
Sequential write (1 MB) 88 MiB/s* 88 90.6 ms 427 ms
Random write (4 KB, 4x32) 1.8 MiB/s 461 276 ms 1095 ms
* up to 163 MiB/s in a separate 60-second runLesen ist super. Schreiben ist … Parität. Jeder kleine Schreibzugriff wird zu einem Read-Modify-Write aus Daten plus Parität, und ohne SSD/NVMe-Write-Back-Cache-Stufe ist Parität bei Storage Spaces dabei notorisch langsam. Die Latenzspalte erzählt dieselbe Geschichte: Jeder hundertste kleine Schreibzugriff wartet mehr als eine Sekunde. Genug Zeit, um die eigenen Lebensentscheidungen zu überdenken. Für einen Dateiserver und ein Backup-Ziel, wo Daten einmal geschrieben und oft gelesen werden, ist das in Ordnung. Für alles mit vielen kleinen zufälligen Schreibzugriffen ist es ein No-Go.
Update (6. Oktober 2026): Die Parität war nur die halbe Geschichte. Die HPE-Firmware hatte beim Booten den Schreibcache aller drei SSDs abgeschaltet, und DiskSpds -Sh hat genau diesen Zustand gemessen, der zufällig auch der Alltagszustand des Servers war. Mit eingeschaltetem Cache lief eine Wiederherstellung auf dieselben Platten (inzwischen unter Linux) etwa dreimal so schnell. Die ganze Geschichte (auf Englisch): Two Things My SSDs Were Missing: TRIM After BitLocker, and a Write Cache My HPE Server Quietly Switched Off.
(Der Fairness halber: Der Lauf überschnitt sich mit einem großen Kopierauftrag auf dasselbe Volume, eine saubere Nachmessung steht also noch auf meiner Liste. Das Muster ist aber eindeutig.)
🧪 Als Nächstes: ein Hypervisor und eigene Zertifikate
„Alles mit vielen kleinen zufälligen Schreibzugriffen“ ist natürlich eine höfliche Umschreibung für virtuelle Maschinen. Und genau damit will ich als Nächstes spielen: Hyper-V. Windows Server 2025 bringt es ohnehin mit, und ich will sehen, wie es sich im Vergleich zur Proxmox-Welt anfühlt, die ich kenne: Livemigration zwischen Hosts, Prüfpunkte, virtuelle Switches und verschachtelte Virtualisierung für ein Testlab im Lab.
Der Benchmark oben hat eine Designfrage schon beantwortet, bevor ich überhaupt angefangen habe. VM-Disks kommen nicht auf den Paritäts-Pool. Mit ~460 IOPS beim zufälligen Schreiben würde eine Windows-VM ihr Leben damit verbringen, auf einen sich drehenden Kreis zu starren. Der Ladekringel als Lebensstil. Ein ordentliches Hypervisor-Setup braucht also ein anderes Storage-Layout: Spiegelung statt Parität, oder lokale NVMe. Das ist Stoff für den nächsten Beitrag.
Der zweite Punkt auf der Liste: eigene Zertifikate ausstellen. Windows Server bringt seine eigene PKI mit, die Active-Directory-Zertifikatdienste. Auf der Linux-Seite kümmern sich cert-manager und Let’s Encrypt um alles, was zum Internet zeigt. Intern gibt es aber einen ganzen Zoo, den niemand jemals öffentlich signieren wird: iLO-Weboberflächen, RDP, LDAPS auf den Domänencontrollern und die Admin-Seiten diverser Geräte. Jedes davon begrüßt mich derzeit mit einer Zertifikatswarnung, die ich mir angewöhnt habe wegzuklicken. Genau den Reflex will man nicht haben.
Der Plan ist eine kleine interne CA, deren Stammzertifikat (natürlich) per Gruppenrichtlinie an jedes Domänenmitglied verteilt wird. Mit Zertifikatvorlagen und automatischer Registrierung fordern Maschinen ihre eigenen Zertifikate an und erneuern sie, wie cert-manager, nur in der Microsoft-Edition. Das Lehrbuch-Design ist eine Offline-Root-CA mit einer ausstellenden CA darunter. Ob ein Homelab wirklich zwei Ebenen braucht oder ob das der Moment ist, in dem Lernen zu Cosplay wird, wird sich zeigen.
🎯 Fazit
Vor einer Woche hätte ich dir gesagt, Windows-Administration sei Durchklicken durch Assistenten. Wie sich herausstellt, ist sie mit PowerShell und WinRM überraschend gut skriptbar, und Gruppenrichtlinien sind im Grunde Konfigurationsmanagement, um das herum ein Betriebssystem gebaut wurde.
Die Lektionen unterwegs waren dieselben wie unter Linux: das Kleingedruckte lesen (DHCP-Failover ist paarweise, WSUS ist abgekündigt), dem ersten Benchmark nicht trauen (ReFS und seine Nullen) und nicht alles auf einmal neu starten (Domänencontroller sind gesellige Wesen).
Also zweigleisig. Linux betreibt weiter die Produktivsachen, und Windows Server darf der Spielplatz sein, auf dem ich lerne. Und ehrlich? Nach einer Woche YAML fühlte sich Get-ADReplicationPartnerMetadata wie Urlaub an. 🏖️
PS: Wenn du mich jetzt entschuldigst, ich muss der Familie erklären, warum ihr Desktop-Hintergrund plötzlich schwarz ist. „Das ist eine Richtlinie“ hat als Erklärung zu Hause noch kein einziges Mal funktioniert.
