Inhaltsverzeichnis
Einleitung
Ich habe am 04.03.2025 einen meiner beiden Domain Controller – den WS-DC2 – ausgetauscht und dabei das Betriebssystem von Windows Server 2019 auf Windows Server 2025 umgestellt. Seitdem hatte ich immer wieder Probleme mit Kerberos. Teilweise funktionierten meine Service-Kennungen nicht mehr und Anwendungen und Dienste hatten Startprobleme.
Am 18.05.2025 häuften sich die Probleme. Mein PRTG-Monitoring meldete mir zahlreiche Server, die nicht mehr auslesbar waren. Nach einer intensiven Suche ist mir aufgefallen, dass diese Systeme ihre Kerberos-Tickets vom WS-DC2 ausgestellt bekommen haben, während mein Monitoring und alle noch erreichbaren Server ihr Ticket vom WS-DC1 erhielten.
Meine temporäre Lösung bestand darin, den WS-DC2 abzuschalten. Ein Neustart sollte dann die Membersysteme mit Kerberos-Tickets vom WS-DC1 ausstatten. Leider sind diese Server aber beim Neustart alle aus der Domäne gefallen und ich hatte einigen Aufwand, das zu beheben. Seitdem nutzte ich problemfrei nur einem DC.
Aber das kann kein Dauerzustand bleiben. Ich brauche 2 funktionale Domain Controller. Die Reparatur eines DCs macht hier wenig Sinn. Zumal ich die Ursache immer noch nicht gefunden habe. Daher werde ich diesen Server aus meinem AD entfernen und einen neuen an seiner Stelle aufbauen.
PS: Bei dieser ganzen Aktion bin ich auf ein schweres Problem gestoßen und das werdet ihr in meiner Dokumentation hier nachlesen können.
Entfernung des defekten Domain Controllers
Neben der Entfernung der defekten VM muss vor allem das Active Directory bereinigt werden. Hierfür melde ich mich als Domain Admin mit Enterprise Admin Rechten auf dem verbliebenen Domain Controller an.
Ich beginne mit einer Kontrolle der Flexible Single Master Operators Rollen (FSMO) und habe Glück: der ausgefallene DC führte keine dieser Funktionen aus. Sonst wären hier noch zusätzliche Arbeiten erforderlich gewesen:
Die Bereinigung starte ich in der Konsole Active Directory Users and Computers. Hier lösche ich das Computer-Konto des defekten DCs:
Der Assistent fragt hier explizit noch einmal nach, ob das gewollt ist und ob wir den Domain Controller wirklich nicht mehr auf dem normalen Weg entfernen können. Da sich die beiden DCs nicht mehr vertrauen, bleibt nur diese Option über:
Damit wird dann auch die Funktion „globaler Katalog“ entfernt:
Und dann ist dieser Teil abgeschlossen:
Weiter geht es in der Konsole „Active Directory Sites and Services“. Hier bleibt die Hülle des gelöschten DCs über. Das erkennt man daran, dass sie nicht erweitert werden kann. Dieses Objekt kann gelöscht werden:
Ebenso muss hier das verwaiste Replikationsobjekt gelöscht werden. An dem *0ADEL:* erkennt man, dass es sich um eine tote Verbindung handelt. Der DC sollte es aber auch demnächst von selber löschen:
Nun kontrolliere ich noch, ob die DNS-Records alle entfernt sind. Da ich das vor einer Woche durch eine Maintenance mit nltest /dsderegdns:ws-dc2.ws.its schon erledigt hatte, finde ich hier keine Records. Wie der Trick mit der Maintenance funktioniert, hatte ich hier schon einmal erklärt: WS IT-Solutions · Blog: Migration eines DC auf Windows Server 2025
Für die GPO-Files wird der DFS-Replikationsdienst verwendet. Auch dieser Dienst muss wissen, dass sein Replikationspartner nicht mehr existiert. Das kontrolliere ich im passenden Eventlog auf dem funktionalen DC und finde den Eintrag:
Nun sollten alle Spuren beseitigt sein.
Aufbau des neuen Domain Controllers
Konfiguration der neuen VM
Hier beginne ich mit dem Umbenennen der Virtual Hard Disk. Vielleicht brauche ich ja noch einmal was daraus…
Dann editiere ich die VM. Ich kopiere mir den Pfad der VHDX in die Zwischenablage und entferne den Eintrag. Das bestätige ich mit „anwenden“, denn so bleibt der Dialog offen:
Nun kann ich direkt mit „hinzufügen“ eine neue VHDX anlegen lassen:
Auf der passenden Seite füge ich den Pfad wieder ein:
Ein paar Eingaben später ist die neue, leere VHDX verbaut. Nun lege ich noch ein neu heruntergeladenes ISO mit Windows Server 2025 ein, denn ich kann nicht ausschließen, dass es Probleme mit meinem GoldenImage gegeben hat. Ich will auf Nummer sicher gehen!
Die Installation des Betriebssystems spare ich mir hier in der Dokumentation, denn das hab ich ja hier schon einmal gezeigt: WS IT-Solutions · Blog: Serie „Migration zu Windows Server 2025“ – Vorbereitungen. Ich lasse eben nur den Teil mit dem sysprep aus.
Grundkonfiguration des neuen Servers
Für den Domain Join bereite ich ein leeres Computerkonto an der richtigen Stelle im Active Directory vor. So erhält der neue Server ab dem ersten Moment nur die Richtlinien (GPO) für Domain Controller:
Dazu kommt gleich noch die Beschreibung:
Nun erhält der Server seine Grundkonfiguration.
- Ich installiere die Rolle DNS und konfiguriere die Weiterleitung auf den anderen DC.
- Nun schmeiße ich die „Microsoft-Bloatware“ ArcSetup und Windows Admin Center raus.
- Dann benenne ich den Server um und starte ihn neu.
- Jetzt erhält er die IP-Konfiguration des bisherigen Servers.
- Der Abschluss ist dann der Domain Join mit Neustart.
Hintergrundinformation zur DNS-Rolle
Warum installiere ich diese Rolle jetzt. Das könnte ich doch auch später erledigen? Es ist recht einfach: Es gab diesen Server mit der dazugehörigen IP bereits. Und etwa die Hälfte meiner Systeme verwendet diese IP als primären DNS-Server. Wenn der Server nur die IP ohne den DNS-Service hätte, dann würden Anfragen ins leere gehen und meine Membersysteme würden den sekundären DNS-Server fragen. Wird aber die Rolle installiert, dann kann der neue „noch-nicht-Domain Controller“ die Anfragen annehmen. Nur kennt er eben noch keine Antworten. Aber das wird er den Clients mitteilen. Diese fragen dann eben nicht mehr den sekundären DNS-Server, denn sie haben ja eine Antwort erhalten. Und das stört massiv die Namensauflösung!
Wie das ausgeht, könnt ihr euch bestimmt vorstellen. Selbst für meinen DNS-Trick ist es dann zu spät, denn der DNS-Server ist bereits aktiv.
Also muss ich zuerst den DNS-Service installieren und die Weiterleitung konfigurieren, bevor ich die IP-Adresse konfiguriere. So minimiere ich die DNS-Problematik. 😉 Hier im Bild sieht man, dass der neue Server den bestehenden WS-DC1 befragen soll, wenn er eine Anfrage von einem Client erhält:
Provisionierung als neuen Domain Controller
Hier führe ich nun die üblichen Arbeitsschritte aus:
- Ich installiere die Rolle für das Active Directory.
- Dabei wird der Post-Deployment-Wizzard für die Konfiguration des Servers zum Domain Controller gestartet. Diese wird mit einem automatischen Neustart beendet.
- Danach kontrolliere ich die AD-Integration bzw. die Replikation.
Diese Schritte habe ich hier ausführlich beschrieben und verzichte daher auf neue Bilder: WS IT-Solutions · Blog: Migration eines DC auf Windows Server 2025
Fehler 0x80070005 bei der Rollen-Installation
Der erste Schritt der Provisionierung läuft aber auf einen Fehler! Nach dem Domain Join habe ich mich als Domain Admin angemeldet und wollte die Rollen für das Active Directory mit dem Server Manager installieren. Aber der hat keinen Zugriff mehr. In der PowerShell erhalte ich ebenfalls einen Fehler 0x80070005. Dieser deutet auf ein Berechtigungsproblem hin…
Ich durchsuche als Einstieg die Eventlogs. In der Übersicht finde ich nur 2 interessante Quellen. Den Rest kann ich mir ohne reinzuschauen schon erklären. Ansonsten empfehle ich, dass ihr die Quellen von oben nach unten durchgeht und deren Details öffnet. Schaut dabei auch auf die Spalte „letzte Stunde“. Ich habe den Server gerade mit dem Domain Join neu gestartet. Der Fehler muss also danach in der aktuellen Stunde passiert sein. Steht da eine 0 drin, dann ist es im ersten Schritt irrelevant. Ich prüfe den blau markierten Eintrag:
Hier fehlen ServicePrincipalNames für WSMAN – das ist die Schnittstelle zum System, die auch vom Server Manager verwendet wird!
Das will ich mir im Active Directory ansehen. Im Bild vergleiche ich meine beiden Computer WS-DC1 und WS-DC2. Und die Einträge fehlen wirklich!
Was für eine Schlamperei von Windows… Egal. Über die Option „hinzufügen“ trage ich beide Werte direkt hier ein:
Danach starte ich den Server neu und prüfe das Ergebnis. Der Fehler besteht aber weiter!
Ich verwerfe den Server und erstelle einen neuen. Selbst ohne Entfernen der Bloatware und ohne GPO kann ich keine Rollen nach einem Domain Join hinzufügen…
Abbruch
Mir reicht es! Windows Server 2025 kann doch nicht von Microsoft ernst gemeint sein! Dieses System hat so viele Macken und Probleme. Und Microsoft kümmert sich irgendwie nicht darum! Im folgenden Bild sehr ihr die Known Issues Liste für Windows Server 2025 vom 19.05.2025. Die beiden Probleme vom April-Update wurden mit dem Mai-Update nicht behoben! Und der geschlossene Case vom Februar wurde erst im April gefixt!
Und die kann ich um meine Liste gerne noch erweitern:
- Mein Windows Server 2025 Domain Controller hat das Vertrauen zu meinem alten DC verloren. So etwas habe ich noch nie gesehen!
- Die Server mit Win-2025 sind in meiner Umgebung deutlich langsamer und ressourcen-hungriger als die vergleichbaren Vorgänger mit Windows Server 2019.
- Meine Group Managed Service Accounts funktionieren nicht mehr richtig.
- In einer PKI lassen sich die Templates nicht mit der Management Konsole hinzufügen.
Damit treffe ich hier eine Entscheidung: Ich breche die Umstellung meiner Infrastruktur auf Windows Server 2025 hiermit ab! Ich will kein Betatester für Microsoft sein. Und den ausgefallenen Domain Controller installiere ich mit Windows Server 2022 neu.
Neuer Versuch für meinen WS-DC2
Für meinen ausgefallenen Domain Controller wiederhole ich die Schritte oben, nur mit einem Windows Server 2022 und ohne das TroubleShooting!
Einen Schritt lege ich aber vorher noch ein: Ich erstelle eine neue GPO mit der Security Baseline aus dem SCT für die Absicherung des neuen Windows Server 2022 Domain Controllers. Diese mappe ich zusammen mit den beiden anderen Richtlinien, die ich auch schon für meine Memberserver verwende, auf die OU der Domain Controller:
Ergebnis: Der neue Domain Controller läuft einwandfrei. Zudem ist er deutlich schneller. Mein Active Directory Service ist wieder redundant.
Zusammenfassung
Der Windows Server 2022 ist im Vergleich zu dem Windows Server 2025 so viel schneller und leichter. So macht das Arbeiten wieder Spass. Und gleichzeitig trauere ich der einstigen Qualität von Windows Server nach. Es wird zwar viel geschimpft und gelästert, aber meine Erfahrung zeigt, dass oft Layer-8-Fehler zu den Windows-Problemen führten – denn auch wir Admins machen viele Fehler. Diese lassen sich durch gute Schulungen und Anleitungen vermeiden und minimieren! Aber wenn die Plattform immer schlechter wird, dann hilft das auch nicht mehr!
Mein Sohn fragte mich vorhin beim Mittagessen, wo ich die Motivation für die Arbeit an meiner eigenen Infrastruktur nach der Vollzeit & Selbstständigkeit noch hernehme. Ich sagte ihm, dass Windows Server mit der richtigen Herangehensweise und Automation nahezu autonom, wartungsfrei und sicher betrieben werden können. Oft bin ich wochenlang nicht auf meinen Servern angemeldet – weil sie eben funktionieren! Und eben das scheint mit Windows Server 2025 eben nicht mehr zu funktionieren!
Wann wird Microsoft endlich wieder begreifen, dass nicht nur Aktionäre, sondern auch Kunden glücklich sein wollen? Und bitte auch die Kunden, die ihre Services und Daten nicht in einer Cloud ablegen wollen!
Stay tuned!