Probleme mit Windows Updates auf MS Server 2025 Standard (nur kumulative Sicherheitsupdates)

[Adm -MCSE 0]

Beschreibung:

Hallo zusammen,

ich habe ein Problem mit Windows Updates auf mehreren Domain Controllern unter Windows Server 2025 Standard. Vielleicht hat jemand ähnliche Erfahrungen gemacht.

---

Architektur:

• 3 Domänen:
  • a.muster.de
  • b.muster.de
  • c.muster.de
• In jeder Domäne stehen 2 DCs, die von Server 2016 auf Server 2025 migriert wurden.
• AD-Datenbank ist noch nicht auf den neuen Funktionsmodus (2025) angepasst.
• Jeweils ein DC pro Domäne hat Probleme mit Updates.

---

Problem:

• Nur kumulative Sicherheitsupdates schlagen fehl.
• Alle anderen Updates (Feature, .NET, etc.) funktionieren problemlos.
• Updates werden über WSUS verteilt (WSUS wurde per Inplace-Upgrade von 2016 auf 2025 aktualisiert).
• Siehe Screenshot (Update-Fehlercode bitte angeben).

---

Bisherige Maßnahmen:

• Mehrere Neustarts durchgeführt
• sfc /scannow und DISM /RestoreHealth ausgeführt
• WSUS-Client neu registriert (wuauclt /detectnow, wuauclt /reportnow)
• Update-Cache geleert (SoftwareDistribution und Catroot2 Ordner)
• Manuelles Herunterladen und Installieren des kumulativen Updates getestet → ebenfalls Fehler

---

Fragen:

1. Kennt jemand dieses Verhalten speziell bei Server 2025 DCs?
2. Liegt es evtl. an der AD-Funktionsstufe oder an der WSUS-Konfiguration nach dem Upgrade?
3. Gibt es bekannte Bugs oder Workarounds (z. B. manuelles CAB-Deployment, Servicing Stack Update)? 

bearbeitet 11. Dezember von Adm -MCSE
Bild eingefügt

[Gulp 306]

vor 18 Minuten schrieb Adm -MCSE:

 

 

Bisherige Maßnahmen:

• Mehrere Neustarts durchgeführt
• sfc /scannow und DISM /RestoreHealth ausgeführt
• WSUS-Client neu registriert (wuauclt /detectnow, wuauclt /reportnow)
• Update-Cache geleert (SoftwareDistribution und Catroot2 Ordner)
• Manuelles Herunterladen und Installieren des kumulativen Updates getestet → ebenfalls Fehler

 

 

"wuauclt /detectnow" ist seit Windows 10/Server 2019 mindestens teilweise "deprecated" und durch UsoClient ersetzt worden ...

 

usoclient StartScan
usoclient StartDownload - startet den Download
usoclient StartInstall - startet Installation
usoclient RestartDevice - PC Neustart

 

/updatenow dürfte aber noch gehen und die Neuregistrierung geht normalerweise mit wuauclt /resetauthorization ......

 

Mein üblicher Weg wäre:

 

- WindowsUpdate service anhalten

- alles unter C:\Windows\SoftwareDistribution löschen

- WindowsUpdate service starten 

- UsoClient StartScan ausführen

 

Dann auf dem WSUS und in den Logs gucken ....

 

Grüsse

 

Gulp

bearbeitet 11. Dezember von Gulp

[Adm -MCSE 0]

vor 34 Minuten schrieb Adm -MCSE:

Update-Cache geleert (SoftwareDistribution und Catroot2 Ordner)

Dies wurde alles bereist getan!
 
Ich weis das dies ersetzt wurde, und ja detectnow usw. haben trotzdem noch Funktion: Es besteht auch kein Problem mit Updates denke ich, denn alle außer kumulativ werden ja gemacht!

Und es muss ein globales Problem sein, da ich aktuell 4 x 2025 Server habe die sich so benehmen!


Danke

bearbeitet 11. Dezember von Adm -MCSE
Erhöhung detailgrad

[testperson 1.920]

Hi,

 

du hast pro Domäne zwei DCs. Schmeiß in einer Domäne den "defekten" weg und setz den einmal frisch auf bzw. installiere einen neuen als dritten dazu. (Könnte am Ende deutlich schneller sein als "wochenlanges Troubleshooten".)

 

Gruß

Jan

[Adm -MCSE 0]

vor 17 Minuten schrieb testperson:

du hast pro Domäne zwei DCs. Schmeiß in einer Domäne den "defekten" weg und setz den einmal frisch auf bzw. installiere einen neuen als dritten dazu. (Könnte am Ende deutlich schneller sein als "wochenlanges Troubleshooten".)

Ich weiß aber wir haben überall, dann die DNS nachzutragen, in einer Domain ist das easy via Dhcp in den beiden anderen ätzend wegen den Servern und Ihren manuellen Einträgen!

Diese Option würde ich nur im Notfall ziehen! Und es muss ja etwas sein das mehrere 2025 nicht richtig updaten! Und wenn dies schon 4 mal geschah ist die Wahrscheinlichkeit hoch da dies wieder beschied und diesmal dann mit Servern die nicht so "einfach" ersetzten kann!

[Gulp 306]

Was sagt denn das UpdateLog?

 

Grüsse

 

Gulp

[Adm -MCSE 0]

vor einer Stunde schrieb Gulp:

Was sagt denn das UpdateLog?

Ich hänge es mal an!

https://www.file2send.eu/de/download/XxaRiP441fNbiynM81ExF1vpFXrrJxaZDjGu5SE9QU4m87iMn0gWpUNMnAd8LLBX

Also meine Erkenntnis ist:

• CDN‑Dateien nicht abrufen kann (0x80D02002)
• Voraussetzungs‑Metadaten fehlen (0x80248007).
• System‑Proxy und User‑Proxy und meldet „The given proxy cannot be reached“ (irrelevant weil ja vom WSUS konsumiert wird!)

bearbeitet 11. Dezember von Adm -MCSE

[Squire 302]

was hindert dich denn, den neuen DC mit der gleiche bekannten IP zu installieren?

 

Ich würde den defekten demoten, dann aus der Domäne entfernen und herunterfahren, AD Sites & Services bereinigen, neue Kiste installieren, IP des alten verwenden und zum DC machen ...

Ne Sache von 1-2h max. außer, Du hast ne grotten langsame Umgebung 

[Adm -MCSE 0]

vor 11 Minuten schrieb Squire:

was hindert dich denn, den neuen DC mit der gleiche bekannten IP zu installieren?

 

Ich würde den defekten demoten, dann aus der Domäne entfernen und herunterfahren, AD Sites & Services bereinigen, neue Kiste installieren, IP des alten verwenden und zum DC machen ...

Ne Sache von 1-2h max. außer, Du hast ne grotten langsame Umgebung 

Ich muss ehrlich sagen, was mich hier gerade hindert, ist eine gewisse Verzweiflung und die Sorge, dass dieses Problem auf Servern auftritt, die nicht einfach austauschbar sind – wie Exchange-Server oder Systeme für Dokumentenmanagement.

Wenn sich das Problem nicht lösen lässt, wäre eine schnelle Alternative natürlich denkbar. Aber mein Ziel ist es, den Fehler sauber zu beheben. Seit 2005 habe ich noch nie ein derartiges Verhalten bei Windows-Updates gesehen. Probleme gab es immer wieder, ja – aber dass sich Systeme überhaupt nicht mehr mit Sicherheitsupdates versorgen lassen, das ist neu.

Bisher war es zur Not immer möglich, die entsprechenden KB-Pakete herunterzuladen und manuell zu installieren. Genau das möchte ich auch hier sicherstellen. Ich will verstehen, warum die automatische Aktualisierung komplett blockiert, und eine Lösung finden, bevor ich auf manuelle Workarounds zurückgreife. :)

[Squire 302]

Du hast oben geschrieben ... die Server sind migriert worden .. Heißt Inplace Upgrade oder wie ist das zu verstehen.

 

Nebenbei ... MS sagt auch, dass bei solch einem Fehler als Lösung ein Inplace Update (gleiche Version) oder Inplace Upgrade (höhere Version) in Frage kommt.

 

[Gulp 306]

0x80004002 sagt halt, dass irgendwas korrupt ist ....... bei den Client Systemen hatte ich da schonmal Defekte im Store, die man mit wsreset eventuell wegbekam. Wenn ich mich recht entsinne resultierten aber alle Systeme, die nicht direkt mit einem Löschen der SoftwareDistribution Folder und/oder einem erfolgreichen DISM Repair in einer echten Neuinstallation.

 

Ich konnte insofern Indizien finden, dass diese Art von Fehler erst dann vermehrt auftrat als die Service Stack Updates (SSU), die vormals immer einzeln kamen, in die Kumulative Updates (CU) integriert wurden. Ich hatte seinerzeit sogar die SSU aus den CU extrahiert und versucht die einzeln zu installieren, allerdings ohne Erfolg. Muss also irgendeine Race Condition sein, entweder fällt ein SSU auf die Bretter oder SSU und CU kommen sich ins Gehege.

 

Grüsse

 

Gulp

 

 

[Adm -MCSE 0]

vor 14 Stunden schrieb Squire:

Du hast oben geschrieben ... die Server sind migriert worden .. Heißt Inplace Upgrade oder wie ist das zu verstehen.

 

Nebenbei ... MS sagt auch, dass bei solch einem Fehler als Lösung ein Inplace Update (gleiche Version) oder Inplace Upgrade (höhere Version) in Frage kommt.

Guten Morgen,

 

Ich weiß, dass Microsoft In-Place-Upgrades für Domänencontroller unterstützt. Dennoch bin ich eher von der alten Schule und möchte vermeiden, dass Altlasten des vorherigen Betriebssystems übernommen werden. Deshalb setze ich weiterhin auf das bewährte Vorgehen: neuen Server bereitstellen, DC-Promotion durchführen, DNS bereinigen, Rollen übertragen und den alten DC sauber aus der Umgebung entfernen.
Ich schätze sehr, dass Microsoft mit PowerShell viele Schritte beschleunigt hat – zum Beispiel die Rollenübernahme auf einen anderen Server.“

 

LG

vor 9 Stunden schrieb Gulp:

0x80004002 sagt halt, dass irgendwas korrupt ist ....... bei den Client Systemen hatte ich da schonmal Defekte im Store, die man mit wsreset eventuell wegbekam. Wenn ich mich recht entsinne resultierten aber alle Systeme, die nicht direkt mit einem Löschen der SoftwareDistribution Folder und/oder einem erfolgreichen DISM Repair in einer echten Neuinstallation.

 

Ich konnte insofern Indizien finden, dass diese Art von Fehler erst dann vermehrt auftrat als die Service Stack Updates (SSU), die vormals immer einzeln kamen, in die Kumulative Updates (CU) integriert wurden. Ich hatte seinerzeit sogar die SSU aus den CU extrahiert und versucht die einzeln zu installieren, allerdings ohne Erfolg. Muss also irgendeine Race Condition sein, entweder fällt ein SSU auf die Bretter oder SSU und CU kommen sich ins Gehege.

Die Richtung hatte ich auch schon im Blick, was mit hier ein wenig Angst macht das dies nun schon 4 Server betrifft, und jeder weiß das 2025 ja erst ende 2024 rauskam!

[Squire 302]

Ich habe bis heute noch die Finger von 2025 gelassen... Windows 2022 läuft stabil. Bisher habe ich es so gehandhabt, dass die DCs als letzte auf die neuen OS umgestellt wurden. 

Sprich die neuen Server OS erstmal bei Memberservern, dann bei wichtigeren... 

 

MS hat ja gesagt, dass mittlerweile 30% vom Code KI generiert ist... Wir lassen 2025 bis jetzt komplett außen vor... 

[Gulp 306]

Ich hatte das Verhalten auch mit Windows 10 und 11 schon ...... bei mir läuft 2025 soweit ohne Probleme, allerdings auch "nur" als Hyper-V Host ..... Updates usw laufen aber sauber, von daher würde ich das eher in die Richtung " ... den Fall hätte das CU auch abfangen können, wenn die Devs ordentlich getestet hätten ..... "  schieben wollen, Das gründliche Testen kommt jedenfalls meiner Meinung nach bei MS in letzter Zeit viel zu kurz.

 

Grüsse

 

Gulp  

[daabm 1.455]

Am 12.12.2025 um 07:17 schrieb Squire:

Bisher habe ich es so gehandhabt, dass die DCs als letzte auf die neuen OS umgestellt wurden. Sprich die neuen Server OS erstmal bei Memberservern, dann bei wichtigeren... 

 

Hm - für mich sind DCs die unwichtigsten... Stirbt einer, machste halt nen neuen.

Nen DC stateless zu machen ist relativ einfach.  Nen Application Server stateless zu machen kann ein riesen Aufwand werden.