In meinem Homelab laufen zwei Domänencontroller als VMs auf zwei verschiedenen Proxmox-Knoten, beide bisher mit Windows Server 2022. Im Oktober habe ich beschlossen, sie per In-Place-Upgrade auf Windows Server 2025 zu heben, statt neue DCs aufzusetzen und die alten herabzustufen. Dieser Artikel ist ein Zwischenstand: Ein DC ist umgestellt, der zweite wartet noch. Nach dem ersten Upgrade war die Replikation rund anderthalb Stunden gestört.
Immer nur ein DC
Für alle Arbeiten an meinen DCs gilt eine Regel: Ich fasse immer nur einen an. Danach prüfe ich mit repadmin /replsummary und dcdiag, ob beide sauber miteinander reden. Erst wenn das grün ist und 24 Stunden ohne Auffälligkeiten vergangen sind, kommt der zweite dran. Bei zwei DCs heißt das: Während der eine im Upgrade steckt, trägt der andere allein Anmeldung, DNS und DHCP. Geht in dieser Zeit auch dieser kaputt, steht das Netz.
Die Reihenfolge der DCs ergibt sich aus den Rollen. Alle fünf FSMO-Rollen liegen auf einem DC, ich nenne ihn hier DC B. Der andere, DC A, ist Global Catalog, DNS- und DHCP-Server, hält aber keine FSMO-Rolle. DC A kommt zuerst. Fällt er aus, fehlt mir die Hälfte der Redundanz, aber keine Rolle.
Vorbereitung: erst aufräumen, dann heben
Ein Upgrade auf einem Server mit offenen Baustellen macht die Fehlersuche unnötig schwer. Deshalb kam vorher einiges dran.
DC A habe ich einen Tag vorher auf den aktuellen Stand von Server 2022 gebracht und danach dcdiag und die Replikation geprüft. DC B steht noch auf einem Patchstand vom Frühjahr 2025 und wird vor seinem Upgrade ebenfalls gepatcht.
Setup braucht freien Platz auf C:. Bei DC A habe ich die Systemplatte von 50 auf 80 GB vergrößert. DC B hat nur 31 GB und wird vorher vergrößert.
Domäne und Gesamtstruktur habe ich vorher auf Windows Server 2016 angehoben. Höher geht erst, wenn alle DCs auf 2025 laufen. Beide DCs schreiben täglich ein System-State-Backup auf eine Freigabe, zusätzlich sichert der Proxmox Backup Server die VMs nachts.
Als Generalprobe habe ich vor dem ersten DC die Zertifizierungsstelle und den Dateiserver auf Server 2025 gehoben. Beide sind wichtig, aber kein DC.
Die Generalprobe hat sich gelohnt. Bei der Zertifizierungsstelle startete der Zertifikatsdienst nach dem Upgrade nicht, weil die Sperrprüfung der Kette beim Start noch nicht klappte. Ich habe ihn von Hand gestartet und auf verzögerten Start gestellt. Beim Dateiserver rollte Setup beim ersten Neustart zurück, der zweite Versuch lief durch. Danach habe ich Platten, Freigaben, Monitoring-Agent und das Sicherungsziel der DCs geprüft. Beides wollte ich lieber an diesen Servern erleben als an einem DC.
Kompatibilitätsscan und Schemaerweiterung
Setup kann vorab prüfen, ob ein Upgrade möglich ist, ohne etwas zu ändern. Den Scan starte ich als geplante Aufgabe unter SYSTEM, weil eine Remote-Sitzung dafür nicht genügt:
setup.exe /auto upgrade /imageindex 4 /quiet /compat scanonly /dynamicupdate disable /eula accept /showoobe noneDer Rückgabewert sagt, wie es aussieht: 0xC1900210 heißt „keine Probleme gefunden“, 0xC1900208 heißt „blockierende Probleme“. Bei DC A meldete der Scan genau einen harten Blocker: Dem Active Directory fehlten die Schemaerweiterungen für Server 2025.
Die kommen mit adprep /forestprep und adprep /domainprep. Das läuft auf dem Schemamaster, also auf DC B, und braucht ein Konto, das sowohl Schema-Admin als auch Organisations-Admin ist. Mein Wartungskonto ist beides nicht, und das ist Absicht. Diesen Schritt habe ich deshalb selbst mit meinem Administratorkonto ausgeführt. Das Schema ging von Version 88 auf 91. Das lässt sich nicht rückgängig machen, außer über eine Wiederherstellung des gesamten Active Directory. Vorher habe ich deshalb geprüft, wie alt die letzte System-State-Sicherung beider DCs ist.
adprep /forestprep
adprep /domainprep
# danach auf beiden DCs prüfen: Schema-Version 91, repadmin /replsummary ohne FehlerDer Rückweg: Snapshot, Backup und ein Widerspruch
Vor dem Upgrade lege ich zwei Dinge an: eine frische Sicherung der VM im Backup-Server und einen Proxmox-Snapshot ohne RAM-Zustand.
vzdump <VMID> --storage <pbs-speicher> --mode snapshot
qm snapshot <VMID> vor-2025-upgrade --vmstate 0
# Rückweg, falls Setup scheitert:
qm rollback <VMID> vor-2025-upgradeMeine eigene Doku widerspricht sich an dieser Stelle. In meinen Grundregeln für DCs steht: keine VM-Snapshots zum Zurückrollen. Der Grund ist der USN-Rollback. Setzt man einen DC auf einen alten Stand zurück, glauben die anderen DCs, sie hätten seine Änderungen schon, und die Replikation läuft ins Leere. Moderne Hypervisoren geben der VM eine Generation-ID mit. Windows erkennt daran ein Zurücksetzen und schützt sich. Beide DC-VMs haben diese ID. Ich verlasse mich trotzdem nicht blind darauf.
Mein Kompromiss: Der Snapshot ist der Rückweg für genau einen Fall, nämlich wenn Setup scheitert und der DC in seinem alten Zustand bleibt oder nicht mehr hochkommt. Dann gleicht er sich nach dem Zurückrollen über den anderen DC ab. Für alles andere, etwa Probleme Tage später, nehme ich die System-State-Sicherung oder das VM-Backup. Und das Schema bleibt in jedem Fall auf 91, denn kein Snapshot eines einzelnen DCs holt das zurück.
Das Upgrade und die Falle danach
Das Upgrade läuft wieder als geplante Aufgabe unter SYSTEM, mit fast demselben Aufruf wie der Scan, nur ohne scanonly und mit /compat ignorewarning. Es dauert ein bis zwei Stunden mit mehreren Neustarts. In dieser Zeit ist DC A nicht erreichbar, und DC B arbeitet allein.
Danach meldete DC A Windows Server 2025 Datacenter, Build 26100.1742. Dienste liefen, das Schema stand auf 91. Und trotzdem stimmte etwas nicht.
Die Replikation zwischen den DCs schlug fehl, mit den Fehlern 1722 und 1908. Der DFS-Dienst war gestoppt, und der DC kündigte sich nicht als Zeitserver an. Die Ursache war unscheinbar: Das Netzwerkprofil stand auf „Privat“ statt auf „Domäne“. Das ist ein bekannter Fehler der Basis-Build von Server 2025 auf Domänencontrollern. Meine Einschätzung: Mit dem falschen Profil greifen andere Firewall-Regeln, und die Partner erreichen den DC nicht mehr vollständig.
Behoben habe ich das in dieser Reihenfolge:
Get-NetAdapter | Restart-NetAdapter
Start-Service Dfs
w32tm /resync
Restart-Service Netlogon
repadmin /syncall /AdeDanach: Replikation ohne Fehler, SYSVOL im Normalzustand, DHCP-Failover wieder „Normal“. dcdiag meldete nur noch Einträge aus dem Systemprotokoll, die vom Neustart stammten. Der Fehler kommt bei jedem Neustart wieder, bis das erste kumulative Update installiert ist. Für DC B heißt das: direkt nach dem Upgrade patchen, nicht erst im nächsten Wartungsfenster.
Eine zweite Falle kannte ich schon vorher: repadmin /syncall und dcdiag aus einer WinRM-Sitzung scheitern mit „Zugriff verweigert“. Das ist das Double-Hop-Problem. Die Sitzung darf sich nicht mit meinen Anmeldedaten beim zweiten DC anmelden. Ich führe diese Befehle deshalb als SYSTEM über den QEMU-Gast-Agenten aus. Dann arbeitet das Computerkonto des DCs:
qm guest exec <VMID> -- cmd /c "repadmin /replsummary & dcdiag /q"Was ich nach dem Upgrade prüfe
| Prüfung | Erwartung |
|---|---|
| Version und Build | Server 2025, Build 26100 |
| Dienste NTDS, DNS, Netlogon, KDC, DFSR, DHCP, W32Time | laufen |
| Netzwerkprofil | Domäne, nicht Privat |
| Freigaben SYSVOL und NETLOGON | vorhanden |
| Schema-Version | 91 |
repadmin /replsummary | 0 Fehler in beide Richtungen |
dcdiag /q | keine Fehler außer Ereignissen vom Neustart |
| DHCP-Failover | Zustand „Normal“ |
Wo ich gerade stehe
DC A läuft auf Server 2025 und repliziert fehlerfrei. Offen ist bei ihm das erste kumulative Update, damit der Profilfehler nach dem nächsten Neustart nicht zurückkommt. Danach beobachte ich ihn 24 Stunden. Erst dann kommt DC B: Systemplatte vergrößern, patchen, Upgrade und sofort danach das kumulative Update. Außerdem stehen noch aus: die Aktivierung mit dem 2025-Schlüssel, das Löschen von Windows.old nach einer Frist von zehn Tagen und das Aufräumen der Snapshots. Ein Snapshot, der wochenlang neben einem DC liegt, ist eher eine Gefahr als ein Rückweg. Wenn beide DCs umgestellt sind, schreibe ich nach, wie das zweite Upgrade gelaufen ist.
Schreibe einen Kommentar