Day-Two-Betrieb: Drei Windows-Domänencontroller härten (und eine Uhr, die niemandem Rechenschaft schuldete)

🌐 Auch auf: English · Français · Español

Im letzten Beitrag wurden aus drei HP-Kisten eine Windows-Server-2025-Domäne: AD, DNS, DHCP-Failover, Gruppenrichtlinien, BitLocker, Storage Spaces. Das war Tag eins: alles installiert, alles grün, alles „funktioniert“.

In diesem Beitrag geht es um Tag zwei, also den Teil, in dem du aufhörst, die grünen Häkchen zu bewundern, und anfängst, unbequeme Fragen zu stellen. Wie spät ist es, und wer sagt das? Welche Dienste laufen, die keiner bestellt hat? Was passiert, wenn ein Server morgen einfach nicht mehr bootet? Spoiler: Eine dieser Fragen hatte eine sehr lustige Antwort.

Gleiches Setup wie zuvor: Ich entscheide, und mein KI-Co-Admin (Claude, der PowerShell über WinRM steuert) macht die Bestandsaufnahme, führt die Änderungen aus und prüft nach jedem Schritt das Ergebnis. Erst lesen, dann ändern, dann prüfen. Absichtlich langweilig.

🔍 Schritt null: Bestandsaufnahme vor Meinungen

Bevor irgendetwas angefasst wird, ein reiner Lesedurchlauf über alle drei DCs: OS-Build, RAM, Energiesparplan, installierte Rollen, laufende Dienste, SMB-Konfiguration, LSA-Schutz, LDAP-Signierung, Zeitquelle, Defender, Ereignisprotokollgrößen, DNS-Reihenfolge der Netzwerkkarte, Auslagerungsdatei, Datenträger, Firewall-Profile. Dazu die Domäne selbst: Kennwortrichtlinie, Funktionsebene, LAPS-Schema, DNS-Aufräumvorgang, GPO-Liste.

Kleine Anekdote: Die erste Version dieses Inventurskripts lieferte überhaupt nichts. Kein Fehler, keine Ausgabe, nur Stille. WinRM (über pywinrm) verschickt PowerShell als Base64-codierte UTF-16-Kommandozeile, und Windows begrenzt Kommandozeilen auf 8191 Zeichen. Aus einem 3,5-KB-Skript werden auf der Leitung ~9,5 KB, und es verschwindet einfach… spurlos. In drei Teile zerlegt, und plötzlich haben die Server eine Menge zu erzählen.

🕰️ Die Uhr, die niemandem Rechenschaft schuldete

Mein Lieblingsfund des Tages:

PS> w32tm /query /source
Free-running System Clock

Das war auf HP1, dem PDC-Emulator, also genau dem Domänencontroller, dessen einzige Aufgabe in der Zeithierarchie es ist, die Referenzuhr der Domäne zu sein. Jedes Domänenmitglied synchronisiert sich mit einem DC, jeder DC mit dem PDC… und der PDC synchronisierte sich mit seinem eigenen Quarzkristall und guten Absichten. Die gesamte Domäne hielt eine perfekt einheitliche, perfekt unverankerte Zeit.

Warum das wichtig ist: Kerberos toleriert standardmäßig 5 Minuten Zeitabweichung. Driftet die Uhr weiter, schlagen Anmeldungen mit Fehlern fehl, die nach allem aussehen, außer nach „deine Uhr geht falsch“. Die Lösung sind drei Zeilen, nur auf dem PDC:

w32tm /config /manualpeerlist:"ptbtime1.ptb.de,0x8 ptbtime2.ptb.de,0x8 ptbtime3.ptb.de,0x8" `
      /syncfromflags:manual /reliable:yes /update
Restart-Service w32time
w32tm /resync /rediscover

Die PTB ist das nationale Metrologieinstitut Deutschlands, die Domäne holt sich ihre Zeit jetzt also von den Leuten, die hierzulande buchstäblich die Sekunde definieren. HP1 meldet Stratum 2, die anderen beiden DCs folgen HP1. Hierarchie wiederhergestellt. Die iLOs bekamen später dieselbe Behandlung: Sie hatten überhaupt kein NTP, und zwei von ihnen glaubten, sie lebten in „Eastern Europe (DST disabled)“.

🌐 DNS-Client-Reihenfolge: Warum HP2 in Panik geriet, als HP1 neu startete

Erinnerst du dich an die Notiz vom letzten Mal, dass HP2 etwa sieben Minuten lang Anmeldungen abgelehnt hat, während HP1 neu startete? Die Bestandsaufnahme hat es erklärt: Auf der Netzwerkkarte von HP2 war genau ein DNS-Server eingetragen, HP1. Kein HP1, kein DNS, keine SRV-Records, kein auffindbarer DC, kein Kerberos. HP1 selbst zeigte nur auf 127.0.0.1.

Die Best-Practice-Reihenfolge für die eigene Netzwerkkarte eines DCs lautet: zuerst ein Partner-DC, dann ein weiterer Partner, Loopback zuletzt. Partner zuerst, damit ein frisch gebooteter DC nicht auf seinen eigenen, noch nicht gestarteten DNS-Dienst wartet. Loopback zuletzt, damit er immer noch auflöst, wenn alle anderen down sind. HP3 hatte das schon, und jetzt haben es alle drei.

🗺️ AD-Standorte: „Default-First-Site-Name“ umbenennen

Jede Gesamtstruktur beginnt mit einem Standort namens Default-First-Site-Name und ohne Subnetze. Bei drei DCs in einem Rack ist ein Standort genau richtig. Die Replikation innerhalb eines Standorts nutzt Änderungsbenachrichtigungen (~15 Sekunden), und weitere Standorte würden alles nur langsamer machen.

Trotzdem zwei kleine Änderungen: Der Standort wurde in Homelab umbenannt (umbenennen, niemals löschen und neu anlegen; AD verfolgt ihn über die GUID, und Netlogon registriert die _sites-SRV-Records von selbst neu), und 192.168.10.0/24 wurde ihm zugeordnet. Jeder Client kann seine IP jetzt einem Standort zuordnen, was Netlogon-5807-Ereignisse für unbekannte Subnetze vermeidet. Wie du unten sehen wirst, hängt das auch damit zusammen, wie Windows Update nach WSUS funktioniert.

🖨️ Dienste, die niemand bestellt hat

Windows Server mit Desktopdarstellung bringt erstaunlich viele Dienste mit, die auf einem Laptop Sinn ergeben und auf einem Domänencontroller im Rack keinen. Auf allen dreien deaktiviert:

• Druckwarteschlange: der große Brocken. PrintNightmare und der „Printer Bug“, mit dem ein Angreifer einen DC dazu bringen kann, sich irgendwo zu authentifizieren. Microsoft selbst empfiehlt, sie auf DCs zu deaktivieren. Niemand druckt von einem Domänencontroller. Niemand.
• Audio (Audiosrv, AudioEndpointBuilder): Meine DCs singen nicht.
• Geolocation (lfsvc): Sie wissen auch so genau, wo sie sind. Im Rack.
• Funkverwaltung (RmSvc), Pushbenachrichtigungen (WpnService), Telemetrie (DiagTrack), Veröffentlichung für die Netzwerkerkennung (FDResPub, fdPHost).

Ehrlicher Hinweis: Das macht die Server nicht messbar schneller. HP1 hat 64 GB RAM, davon 60 GB frei, ein paar untätige Dienste sind also kein Flaschenhals. Es geht um Angriffsfläche und weniger Rauschen, nicht um einen Turbo-Knopf. Wer dir „40 Dienste deaktivieren für 30 % mehr Leistung“ auf einem modernen Server verkauft, verkauft dir ein Placebo.

🔐 Härtung, die unspektakuläre Liste

• Kennwort- & Sperrrichtlinie: Die Mindestlänge lag bei 7 (ein Standardwert direkt aus 2003). Jetzt 12, und Kontosperrung nach 10 Fehlversuchen für 15 Minuten, wo es vorher nie eine gab. Stolperfalle: Die Sicherheitsvorlage der Default Domain Policy und das Domänenobjekt müssen übereinstimmen. Änderst du nur das Domänenobjekt, setzt der PDC es bei der nächsten Richtlinienaktualisierung stillschweigend zurück.
• Windows LAPS: Schema erweitert, der Client-OU erlaubt, ihre eigenen Kennwortattribute zu schreiben, GPO verknüpft. Jeder Client bekommt jetzt sein eigenes zufälliges, 16-stelliges lokales Admin-Kennwort, das alle 30 Tage rotiert und verschlüsselt im AD gespeichert wird, lesbar nur für Domänen-Admins. Das ist inzwischen in Windows eingebaut, ohne separates MSI wie beim alten LAPS.
• LDAP: Channel Binding erzwungen. Der volle „Signierung erforderlich“-Schalter ist der nächste Schritt, nachdem die Logs auf unsignierte Binds geprüft wurden (es gab keine).
• LSA-Schutz (RunAsPPL): LSASS läuft als geschützter Prozess, was das klassische Abgreifen von Anmeldedaten à la Mimikatz deutlich erschwert. Auf allen dreien gesetzt und dann mit einem rollierenden Neustart aktiviert, ein DC nach dem anderen und nie parallel (Lektion vom letzten Mal). Auf die langweilige Art geprüft: Nach jedem Boot protokolliert Wininit das Ereignis 12, „LSASS.exe was started as a protected process with level: 4“. Der Neustart des Dateiservers wartete, bis ich die Notizdatenbank geschlossen hatte, die ich auf seiner Freigabe offen hatte. Eine Kiste unter den eigenen geöffneten Dateien neu zu starten, ist eine ganz besondere Art von Eigentor.
• Ereignisprotokolle: Das Directory-Service-Protokoll hatte 1 MB. Ein Megabyte. Das reicht ungefähr für „was seit dem Mittagessen passiert ist“. Jetzt Security 1 GB, Directory Service 256 MB, System/Application je 128 MB. Speicherplatz ist billig, und Forensik ohne Logs ist nicht möglich.
• DNS-Aufräumvorgang: aktiviert mit 7+7 Tagen Alterung. Ohne ihn behält jeder DHCP-Client, der sich je registriert hat, seinen A-Record für immer, und nach einem Jahr ist dein DNS ein Museum.
• WinRM für Clients: Eine GPO aktiviert WinRM auf der Client-OU, mit Firewall nur offen fürs Heimnetz (192.168.10.0/24), ohne Basic-Auth und ohne unverschlüsselten Verkehr. Das ist die Voraussetzung, um die Arbeitsplätze aus der Ferne zu verwalten, auch mit Windows Admin Center, das auf die Admin-Workstation kommt (auf einem DC wird es nicht unterstützt).

🪦 WSUS ist tot. Wer lädt jetzt die Updates herunter?

2024 hat Microsoft WSUS für veraltet erklärt. Es ist in Server 2025 noch enthalten und wird noch unterstützt, bekommt aber keine neuen Funktionen, und die Richtung ist klar. Mein Setup ist bereits auf schlichtes Windows Update + Gruppenrichtlinien umgestiegen: Rückstellungstage für Clients, feste Wartungsfenster für Server, ein DC wird samstags als Kanarienvogel gepatcht.

Aber WSUS hatte zwei Aufgaben, und Genehmigungsregeln decken nur eine davon ab. Die andere war Bandbreite: jedes Update einmal aus dem Internet laden und dann an tausend Clients übers LAN verteilen. Was ersetzt das?

Übermittlungsoptimierung (Delivery Optimization). Sie ist in Windows eingebaut und im Grunde BitTorrent für Patches (mit weniger Piraterie und mehr Kerberos). Ein Update wird in Stücke zerlegt. Der erste Client holt die Stücke vom CDN von Microsoft. Jeder weitere Client fragt zuerst seine Peers: „Hat jemand in meinem Netz schon Stück 17?“ Wenn ja, kommt es übers LAN, wenn nicht, aus dem Internet. Je mehr Clients ein Netz hat, desto mehr vom Download bleibt lokal. 1000 Clients bedeuten nicht mehr 1000× den Download über deine Internetleitung.

Die Stellschrauben, auf die es ankommt:

• DODownloadMode = 1 (LAN): Peers im selben NAT/Netz. Das nutzt meine Client-GPO.
• DODownloadMode = 2 (Gruppe) mit DOGroupIdSource = 1 (AD-Standort): Clients teilen nur mit Peers im selben AD-Standort. So zieht eine Zweigstelle keine Stücke über das langsame WAN aus der Zentrale. Deshalb sind saubere Standorte und Subnetze plötzlich wieder wichtig, und deshalb war die Standortumbenennung oben nicht rein kosmetisch.
• Microsoft Connected Cache: die erwachsene Variante für große Umgebungen. Ein lokaler Cache-Knoten pro Standort, der Inhalte einmal holt und alle versorgt, der geistige Nachfolger von WSUS’ „einmal herunterladen“, ohne die WSUS-Datenbank und ihre Pflege und Fütterung.

Was du tatsächlich verlierst: das manuelle Freigeben einzelner Updates. Das steckt jetzt in Richtlinien (Rückstellungen, Ringe, Fristen) oder, im Unternehmen, in Intune/Windows Autopatch. Für ein Homelab mit zwei Clients ist das alles herrlich übertrieben. Die beiden Laptops teilen sich ein paar hundert MB im Monat. Aber es ist schön, den Mechanismus zu kennen.

💾 Windows Server-Sicherung: wie sie wirklich funktioniert

Drei DCs replizieren sich gegenseitig, das AD selbst ist also redundant. Aber Replikation ist kein Backup: Eine gelöschte OU repliziert genauso schnell wie eine angelegte. (Der AD-Papierkorb vom letzten Mal deckt den Fall „Ups, gelöscht“ ab. Er deckt nicht „der Server bootet nicht“ ab.) Deshalb machen HP1 und HP2 jetzt jede Nacht eine Windows Server-Sicherung auf ihre zweite, bisher leere 2-TB-SSD.

Unter der Haube:

• Zuerst VSS. Der Volumeschattenkopie-Dienst friert einen konsistenten Snapshot der Volumes ein. Die AD-Datenbank (ntds.dit) hat einen VSS-Writer, die Kopie ist also transaktional sauber, auch während der DC weiterarbeitet. Keine Downtime, kein Wartungsmodus.
• Blockweise Kopie in VHDX. Der Snapshot wird Block für Block in VHDX-Dateien auf dem Zielvolume kopiert. Nach dem ersten Vollbackup kopieren spätere Läufe nur noch geänderte Blöcke, was den nächtlichen Job schnell macht.
• Versionen über Schattenkopien auf dem Ziel. Ältere Versionen werden als Schattenkopien auf dem Sicherungsvolume selbst aufbewahrt. Wird der Platz knapp, fallen die ältesten automatisch weg. Kein Aufbewahrungsskript nötig.
• Was drin ist: Bare Metal Recovery (C:, die EFI-Partition, die Wiederherstellungspartition) plus System State (AD-Datenbank, SYSVOL, Registry, Startdateien, die COM+- und Zertifikatsspeicher). Die DHCP-Datenbank liegt unter C:\Windows\System32\dhcp, ist also auch dabei.

Die drei Wiederherstellungsszenarien:

1. Einzelne Dateien: wbadmin get versions, dann einzelne Dateien oder Ordner aus einer beliebigen Version wiederherstellen, während der Server läuft.
2. AD-Objekte verbockt: in den Verzeichnisdienst-Wiederherstellungsmodus booten, System State wiederherstellen (nicht autoritativ: Der DC holt dann per Replikation auf) oder bestimmte Objekte mit ntdsutil als autoritativ markieren, damit sie sich gegen die anderen DCs durchsetzen.
3. Server tot, Platte tot, OS tot: vom Windows-Server-ISO booten → Computerreparaturoptionen → Systemimage-Wiederherstellung, auf die Sicherungsplatte zeigen, und es baut die Partitionen neu auf und stellt C: 1:1 wieder her. Für einen DC ist das eine nicht autoritative Wiederherstellung: Er kommt mit dem Stand der letzten Nacht zurück und repliziert dann alles Neuere von seinen Partnern. Das muss innerhalb der Tombstone-Lebensdauer (180 Tage) passieren, was mit einem nächtlichen Job nie ein Problem ist.

Der ehrliche Haken: Das Backup liegt in derselben Kiste. Das deckt eine tote OS-Platte ab, ein verpfuschtes Update, ein beschädigtes AD. Stirbt das Mainboard, kann die SSD in ein Ersatzgerät umziehen. Aber Feuer, Diebstahl oder Ransomware, die jedes Volume verschlüsselt, würden das Backup mitnehmen. Dafür gibt es Kopien auf einer anderen Maschine (siehe nächster Abschnitt). Und für einen DC gibt es immer Plan B: Mit zwei gesunden Partnern ist Neuinstallieren und erneutes Heraufstufen oft schneller als jede Wiederherstellung.

📦 Backups, Teil zwei: das Familienarchiv aus der Kiste holen

Die DCs lassen sich jederzeit aus ihren Partnern neu aufbauen. Die 1,5 TB Familienarchiv auf dem Parity-Pool von HP3 nicht. Parity schützt vor einer toten SSD, nicht vor einem gelöschten Ordner, Ransomware oder einem Pool, der beschließt, einen schlechten Tag zu haben. Also holt die Linux-Backup-Kiste, die schon meine Nextcloud-Instanzen sichert, jetzt auch die NAS-Freigaben ab.

• Ein eigenes Nur-Lese-Konto. svc-nas-backup bekommt Lesen auf den drei SMB-Freigaben und NTFS-Rechte zum Lesen und Ausführen, sonst nichts: kein Admin, keine Sicherungs-Operatoren. (Sicherungs-Operatoren auf einem DC können ntds.dit lesen, sprich: die ganze Domäne.) Sein zufälliges 32-stelliges Kennwort liegt in einer Anmeldedatei auf der Linux-Kiste, die nur root lesen darf.
• Nur-Lese-CIFS-Automounts. Die Freigaben werden per fstab mit x-systemd.automount als ro eingehängt. Ein Schreibtest von der Backup-Kiste scheitert mit „read-only file system“, und genau darum geht es: Ein kompromittierter Backup-Host kann die Quelle nicht verschlüsseln.
• rdiff-backup, ein Repository pro Benutzer. Der aktuelle Stand liegt als normale Dateien vor, ältere Versionen als Reverse-Diffs, 30 Tage Historie. Das Skript weigert sich, eine Freigabe zu sichern, die nicht erreichbar oder leer ist. Sonst würde ein Netzwerk-Schluckauf als „Benutzer hat alles gelöscht“ verbucht.

Der erste Lauf dauerte etwa sechs Stunden, und die Zahlen waren eine Lektion darüber, was wirklich Zeit kostet. Meine 1,2 TB (ein paar tausend große Archive) liefen gleichmäßig mit ~108 MB/s durch und waren nach drei Stunden fertig. Die 236 GB eines anderen Familienmitglieds, verteilt auf 189.000 Dateien, brauchten fast genauso lange. Für rdiff-backup zählt die Anzahl der Dateien viel mehr als die Datenmenge. Der zweite Lauf dauerte 73 Sekunden.

Und ja, ich habe hinterher die Dateianzahl verglichen. Sie stimmte nicht. Nach einem leichten Moment der Panik: PowerShells Get-ChildItem überspringt versteckte Dateien, wenn du nicht -Force anhängst. Mit -Force und abzüglich des ausgeschlossenen Mülls (Thumbs.db, .DS_Store, Office-Sperrdateien) stimmten die Zahlen auf die Datei genau. Vertrauen ist gut, -Force ist besser.

🔐 BitLocker auf den Servern: für den Tag, an dem die Platten das Haus verlassen

Mein Bedrohungsmodell ist hier bescheiden: eine Platte, die stirbt und als Garantiefall zurückgeht, oder ein Server, den ich in fünf Jahren verkaufe. Niemand soll davon eine AD-Datenbank oder ein Familienfoto lesen können. Also BitLocker mit nur TPM: keine PIN, weil Server unbeaufsichtigt booten müssen.

• Wiederherstellungsschlüssel im AD, und außerhalb davon. Eine GPO auf der OU Domain Controllers macht die Sicherung des Wiederherstellungsschlüssels im AD verpflichtend. Windows verweigert die Verschlüsselung, wenn das fehlschlägt. Die Schlüssel werden unter dem Computerobjekt gespeichert und auf jeden DC repliziert: Die Schlüssel von HP3 tauchten innerhalb einer Minute auf HP1 auf. Aber wenn alle drei DCs gleichzeitig am Wiederherstellungsbildschirm hängen (etwa nach einem BIOS-Update auf allen), liegt der Schlüssel im AD, und das AD läuft nicht. Deshalb gibt es auch eine Kopie im Passwortmanager.
• Der Wiederherstellungsbildschirm ist Pre-Boot, die iLO-Remotekonsole funktioniert dafür also auch ohne Advanced-Lizenz. Vor Firmware-Updates vermeidet Suspend-BitLocker -RebootCount 1 die Abfrage komplett.
• Datenvolumes entsperren sich automatisch, und auf dem großen Pool wird nur der belegte Platz verschlüsselt. Sonst würde es auf Parity Tage dauern.

Zwei überraschende Wendungen. Erstens meldete das TPM von HP1 „owned“, aber nicht „ready for storage“, ohne bereitgestellten SRK. Wahrscheinlich gehört es noch einer früheren Installation. Initialize-Tpm antwortete mit ClearRequired=True, es muss also gelöscht werden. Ich habe das bewusst nicht als ausstehende BIOS-Einstellung per Redfish eingereiht: Es würde beim nächsten unbeaufsichtigten Windows-Update-Neustart um 3 Uhr nachts zuschlagen, und die Physical-Presence-Abfrage würde den DC an einer Konsole warten lassen, auf die niemand schaut. Das wird von Hand erledigt, mit offener iLO-Konsole.

Zweitens das Timing. HP1 und HP2 wurden für den LSA-Schutz Minuten bevor das BitLocker-Feature installiert war neu gestartet. Get-WindowsFeature meldet fröhlich „Installed“, aber manage-bde.exe und das PowerShell-Modul tauchen erst nach dem nächsten Neustart auf. HP3 startete zufällig einen Tag später für Patches neu und wurde sofort verschlüsselt; die anderen beiden folgen nach ihrem nächsten Neustart.

🔌 iLO: direkt die Hardware fragen

Alle drei Kisten (zwei ProLiant DL20 Gen10 Plus, ein MicroServer Gen10 Plus v2) haben iLO 5, und iLO 5 spricht Redfish, eine REST-API über HTTPS. Statt sich also durch drei Weboberflächen zu klicken, las ein einziges Python-Skript BIOS-Einstellungen, Firmware-Bestand, Temperaturen, Lüfter und das Integrated Management Log von allen dreien aus.

• Energie: überall schon optimal. Workload-Profil General Power Efficient Compute, Power Regulator Dynamic Power Savings, C6-Package-States. Die Lüfter drehen im Leerlauf mit 6–8 %. Nichts zu tunen, und „Static High Performance“ würde nur Strom in Wärme verwandeln, für eine Last, die das nie braucht.
• Firmware: aktuell (System-ROM von 2026, iLO 5 v3.21).
• Leistungsmesser: zeigt 0 W. Diese Einstiegsmodelle haben keine Netzteile mit Strommessung. Na ja.
• IML: hauptsächlich „link down“-Ereignisse, die zu Verkabelung und Switch-Neustarts passen. Ein DL20 protokollierte vor zwei Monaten einen einzelnen uncorrectable PCIe error, der nie wiederkam. Er bleibt auf der Beobachtungsliste.
• Aufräumarbeiten: Zeitzone korrigiert, NTP auf die DCs gerichtet, einheitliche -ilo-Hostnamen und A-Records für die iLOs in der AD-Zone, damit Dokumentation und Realität dieselben Namen verwenden.

🗜️ Deduplizierung: gemessen, dann abgelehnt

Der ReFS-Parity-Pool von HP3 enthält rund 1,5 TB Familienarchiv, und Server 2025 hat glänzende neue ReFS-Deduplizierung + Komprimierung eingebaut. Verlockend! Also vor dem Aktivieren erst mal: die Daten anschauen.

• 77 % sind .rar, gefolgt von JPEG, ZIP und MP4. Alles schon komprimiert. Komprimierte Daten zu komprimieren, bringt einen Rundungsfehler.
• Echte Duplikate (gleicher Name, gleiche Größe, ohne mehrteilige Archive): ~72 GB, etwa 5 %. Hauptsächlich Kopien alter Laptops in Kopien alter Laptops. Kennen wir alle.

72 GB Ersparnis gegen nächtliche Optimierungsjobs auf einem Pool, dessen Parity-Schreibvorgänge ohnehin der langsame Pfad sind, plus ein Chunk-Store, der auf Single-Parity-Speicher zum Single Point of „ein defekter Block trifft jetzt viele Dateien“ wird. Mit 2,2 TB frei lautet die Antwort Nein. Dedup glänzt bei VM-Disks, VDI und Backup-Zielen, nicht bei einem Haufen RAR-Archive. Die doppelten Ordner von Hand aufzuräumen, ist billiger als jedes Feature.

🎯 Fazit

Tag eins bringt die Dinge zum Laufen. Tag zwei macht sie vertrauenswürdig: eine echte Zeitquelle, DNS, das einen Neustart übersteht, weniger Dienste, ein längeres Gedächtnis, Kennwörter, die sich selbst rotieren, und ein Backup, das du wirklich durchdacht hast, bevor du es brauchst. Nichts davon ist glamourös, und fast nichts davon taucht als grünes Häkchen auf. Und der gruseligste Fund war kein fehlender Patch. Es war eine Domäne, deren Zeitgefühl von einem unbeaufsichtigten Quarzkristall kam.

Als Nächstes: das TPM-Löschen auf HP1 und BitLocker auf den ersten beiden DCs, und endlich das Erzwingen der LDAP-Signierung. Das ist eine einzige Sicherheitsoption in der Default Domain Controllers Policy, und sie überschreibt stillschweigend den Registry-Wert, den ich zuerst gesetzt hatte. Und dann vielleicht, vielleicht, mal wieder etwas YAML. Ich fange an, es zu vermissen. Ein bisschen.

📚 Mehr aus dieser Reihe: Windows Server 2025 im Homelab (auf Englisch)

• 🐧➡️🪟 From Penguin to Windows: Why I’m Running Windows Server 2025 in My Homelab (Again)
• Enough YAML for Now: Three Servers, Windows Server 2025, and a Crash Course on the Dark Side
• My Own Little Certificate Authority: AD CS, Auto-Enrollment and Goodbye to "Your Connection Is Not Private"