[English]Ich stelle mal ein Problem im Blog ein, welches mich über einen Leser erreicht hat. Es geht um den WSUS (Windows Services Update Server), der auch zur Update-Verwaltung von Windows Server 2025 verwendet werden soll. Ein Administrator hat mich kontaktiert, weil der WSUS keine Updates für Windows Server 2025 erkennt. Das Problem kann auch Windows 11-Clients betreffen.
Microsoft entwickelt den WSUS zwar nicht weiter, wie ich im Blog-Beitrag Microsoft beendet WSUS-Weiterentwicklung berichtete. Auf die Frage eines Lesers im Diskussionsbereich, "welche Lösung nutzt ihr um Windows Updates zu verteilen, wenn der WSUS sich verabschiedet" gab es eine Antwort von Bernie. Dieser wies darauf hin, dass der WSUS zwar von Microsoft aktuell nicht mehr weiterentwickelt wird. Aber in Windows Server 2025 (Supportende 14.11.2034) ist die WSUS-Serverrolle aber weiterhin vorhanden (siehe). Der WSUS sollte also mit Windows Server 2025 zur Update-Verwaltung harmonieren. So viel als Vorspann.
WSUS klemmt mit Windows Server 2025 Updates
Ein Blog-Leser, der als Administrator bei einem mir bekannten Unternehmen tätig ist, hat sich gerade per E-Mail gemeldet, weil er in Probleme mit dem WSUS gelaufen ist.
- Der Blog-Leser betreibt einen Windows Server 2022 (Build 20348.4052), der laut seiner Aussage mit dem aktuellstem SSU und CU läuft und auf dem die WSUS-Rolle installiert ist.
- Alle im Netzwerk befindlichen Windows Server 2025 werden vom WSUS korrekt erkannt und als "Windows Server 2025 Standard" gelistet.
- Die entsprechenden Updates wurden vom Leser für "Microsoft Server Operating System Version 24H2" freigegeben.
- Trotzdem werden die neuen Updates auf den Windows Server 2025-Instanzen nicht gefunden.
Der Leser hat bereits überprüft, dass die Windows Server 2025-Instanzen im WSUS erscheinen und die Freigaben korrekt gesetzt sind. Das kann als Ursache, dass die Instanzen die Updates nicht erhalten, also wohl ausgeschlossen werden.
Anzeige
Windows Server 2025 Update Registry-Einträge
Bei der Analyse der Windows Server 2025-Instanzen hat der Leser festgestellt, dass Windows Server 2025 neue Registry-Einträge in Bezug auf Update-Steuerung (z. B. DeferFeatureUpdate, siehe obiger Screenshot) benutzt. Diese Einträge wurden erfolglos in der Registrierung 0 gesetzt.
Windows Server 2022 Update Registry-Einträge
Windows Server 2022 und Windows Server 2019 funktionieren einwandfrei und erhalten die Updates vom WSUS. Der Leser schrieb: "Langsam bin ich unsicher, ob es sich hierbei um ein generelles Problem handelt oder ob ich einen Schritt übersehe. Haben Sie hierzu Erfahrung oder ist ein derartiges Verhalten bei Windows Server 2025 bereits bekannt?"
Mir ist diesbezüglich noch nichts gemeldet worden. Kann jemand damit was anfangen? Einzelfall oder größeres Problem?
Registry-Einträge verursachen Konflikt
Nachtrag: Das Schwarmwissen der Leserschaft hat mal wieder zur Auflösung geführt. Falls jemand von diesem Problem betroffen ist, den Kommentar von Willi K. lesen. Dann den von Klaus2 hier verlinkten Beitrag SCCM Co-management – Dual Scan and Scan Source Demystified aufrufen und die Ausführungen im Abschnitt "Co-management not configured for a device" berücksichtigen.
Co-management not configured for a device; Quelle
Das Problem kann neben Windows Server 2025 wohl auch Windows 11 24H2 betreffen, wie Klaus2 in seinem Kommentar anmerkt. Danke an die Leser für die Beiträge, die dem Betroffenen aus der Patche geholfen haben.
Anzeige
MVP: 2013 – 2016
Was steht den im Log des WSUS-Severs, das ist normalerweise sehr ausführlich und geschwätzig…
Kann ich nicht bestätigen.
Bei uns kamen die Updates über WSUS für Server 2019/2022/2025 ganz normal an.
Nur der Servicestack für 2016 hatte einen Schluckauf, war aber am nächsten Tag korrigiert.
Der WSUS selbst läuft bei uns allerdings unter 2025.
das sind aber nicht zufällig ARM Server?
Mir ist grad erst aufgefallen (da wir kein ARM nutzen) das diesen Monat das Kumulative Patch für 2022 (21H1) und 2025 (24H2) auf ARM fehlt, auch das .Net 2022 für ARM nur .Net 2025 (24H2) für ARM ist vorhanden. Für x64 sind alle da.
Ich kann nur bestätigen, dass wir das selbe Phänomen bei unseren 4 Windows Server 2025-Instanzen feststellen.
Danke für das Feedback.
@All: Bitte beachten – es geht nach meinem Verständnis nicht darum, dass die Patches nicht am WSUS angezeigt werden. Vielmehr werden die am WSUS freigegeben, kommen aber nie bei den Windows Server 2025-Instanzen an – so, als wäre ein Update-Defer (Verzögerung der Update-Installation) wirksam.
Bei einer kurzen Suche eben bin ich noch auf den reddit.com-Thread Server 2025 not working with WSUS policies? von April 2025 gestoßen. Ist zwar ein anderer Fall – aber dort gibt es Probleme mit dem Reboot nach einer Update-Installation, wo GPOs nicht greifen. So richtig koscher scheint mir das alles noch nicht zu sein.
Und es gibt den reddit.com-Post Windows Server 2025 Update Woes [WSUS], der auch über Schwierigkeiten bei der Update-Installation berichtet.
11.09.2025, bei uns alles in Ordnung
Keine Probleme mit den 09-2025 patches SRV 2019/2025 hier bei etlichen Kunden via WSUS. Deutsche und Englische OS.
An sich EOL wie MDT Microsoft Deployment Kit (Für OS Deployment) nur brauchen es noch tausende von MS Kunden aktiv und das wird sich so schnell nicht ändern.
Was wichtig zum Thema WSUS in Bezug auf die steigende Anzahl fehlerhafte Patche die letzten 12 Monate (Vorher über 10 Jahre ruhiger….):
* Fehlerhafte Patche, die via WSUS-Server verteilt werden, lassen sich im Notfall meist direkt via/über den WSUS-Server deinstallieren.
• Fehlerhafte Patche, die via M365 Autopatch verteilt werden, lassen sich NICHT über das M365-Portal deinstallieren. Man muss diese über PowerShell oder manuell auf den Clients entfernen. Das Problem dabei ist, die PowerShell-Skripte, die dies erledigen, so schnell wie möglich laufen zu lassen. Will man es forcieren, müsste man den INTUNE-MDM-Dienst hart neu starten. Wartet man einfach, bis das PowerShell-Skript via M365 ausgeführt wird, dauert es 15 Minuten oder im schlimmsten Fall 24 Stunden. Das heißt, wenn jemand etwas falsch verteilt, sitzt man in der ***.
• Falls mit einem Patch komplett etwas nicht funktioniert (50 % der MS-Kunden sind betroffen), dann wird MS dies zentral über alle Tenants beheben. Was dann passiert, ist, dass sie dies abarbeiten müssen, was 48 Stunden oder länger dauert.
Das ist einer der Major Gründe wieso Firmen noch via WSUS patchen
Alle third party Produkte via PatchmyPC, NinjaONE bauen schlussendlich auf dem Windows Update Catalog auf…. (Nicht anderes als das was WSUS auch braucht..)
keine Probleme hier…Updates werden angezeigt und nach Freigabe auch aufgespielt.
Ich empfehle alle, die immer noch auf ein abgesetztes Produkt (WSUS) setzen, was noch nie *gut* war, sich für eine andere Lösung umzusehen.
Ich persönlich und dienstlich kann action1 absolute empfehlen, auch für den EU (DSVGO) geeignet. Hat dies nicht nur Updates / Patching sondern Schwachstellen Management, Software Verteilung, Remote Zugriff mit anboard.
200 Endgeräte (Server, Clients, Windows oder Mac OS und bald auch Linux) sind kostenfrei, ohne jegliche Einschränkungen in den Funktionen.
Nein, ich bin nicht gesponsert oder arbeite für action1, dies ist meine persönliche Meinung.
Führt im obigen Fall aber nicht zur Lösung – sondern wäre mittelfristig zu überlegen.
Liest sich ganz gut, gerade das mit de 200 Clients.
Bis zu dem Wort Cloud.
Ich soll also einem fremdem System, über das ich keine Kontrolle habe, die sicherheitskritische Verwaltung meiner Rechner übertragen? Noch dazu, dass die Firma in den USA zu verorten ist, wenn ich nicht ganz falsch liege.
Könnte man das Ding als eigene Instanz inhouse laufen lassen, wär das mit den USA zu verschmerzen.
Aber so verwaltet ein Ding zentral ausm Internet ewig viele Endpunkte. An dieser zentralen Stelle einmal ein 'frisiertes' Update eingespeist – Jackpot.
Da quäl ich mich lieber noch bissel mit WSUS.
Genau, zumal wir diverse interne Server haben die keinerlei Internetzugriff haben, auch nicht zu MS. Die sprechen nur intern mit dem WSUS.
Das sehe ich auch als kernproblem an, wenn das ein reiner clouddienst ist. Wenn die morgen weg sind fängst auch wieder bei null an.
Das wäre für alle kleinen firmen und dienstleister ein geschenk und von wenigen grossen firmen must auch erst einmal leben können, gibt genug konkurenz in diesem bereicht.
Vor allen müssen die von 200 freien clients auch etwas haben und das können ja nur daten sein.
Sicherheitsproblem mit RMM – lieber nicht. Hatten wir schon, aber sind schnell wieder hiervon abgekommen. WSUS läuft soweit gut.
In den Screenshots fehlen RegKeys und der Subkey AU muss ebenfalls betrachtet werden.
Nach langem Rumprobieren haben wir einerseits den WSUS durchgespielt, viele alte Settings rausgeworfen und dann bei uns das Problem auf ein relativ neues Setting einschränken können: Das Setting "Quelldienst für bestimmte Klassen von Windows-Updates angeben" unter "Vom Windows Server Update Service angebotene Updates verwalten" muss bei allen Update Typen auf "Windows Server Update Services" stehen. Dann werden 4 RegKeys "SetPolicyDrivenUpdateSourceFor*" angelegt und auf 1 gesetzt. Außerdem wird im Unterschlüssel AU noch der Key "UseWUServer" und "UseUpdateClassPolicySource" auf 1 gesetzt.
Es empfiehlt sich unserer Erfahrung nach, den kompletten Schlüssel WindowsUpdate einmal zu löschen und mit gpupdate /force erneut abzurufen. Force deshalb, da der Client (zumindest bei uns) davon ausgeht, dass er schon die aktuelle Version der GPO angewandt hat und daher nochmal einen Schubser in die richtige Richtung braucht.
Bitte keine Belehrungen, dass /force unnötig sein sollte blabla, ich habe die Diskussion schon oft genug geführt und es gibt definitiv den Fall, dass ein System der Meinung ist, die neueste Version der GPO bereits zu haben und daher Änderungen nicht anwendet und vor allem keine neuen RegKeys erzeugt. Da hilft dann auch kein Neustart oder Löschen der AD Tickets.
@Günter Born falls dazu Rückfragen oder der Bedarf nach einem Austausch entstehen, darfst Du mich natürlich gerne kontaktieren
@Willi K.: Erst einmal herzlichen Danke für dein Feedback. Ich selbst habe ja Null Ahnung, davon aber verdammt viel ;-).
Ich schicke dem Betroffenen noch eine Mail, er soll sich die Geschichte anschauen. Wenn es Diskussionsbedarf gibt, sollten die Protagonisten bevorzugt hier im Blog kommentieren. Ich spiele nur im äußersten Notfall Relais. Hintergrund: Ich investiere die Zeit in solche Beiträge, um der Leserschaft zu helfen bzw. um das Schwarmwissen zu kanalisieren. Dann profitieren Alle – und das gilt auch für Kommentare, die dann von allen gelesen werden können und nicht als Wissen bei Born & Co. isoliert besteht.
Ja, genau. Wir kennen das Problem von Windows 11 24H2, da ist das genauso. Die GPO bzw. entsprechenden Registry-Keys müssen gesetzt sein. Gute Informationen (aber auf Englisch) gibt es auf dieser Seite unter dem Punkt "Co-management not configured for a device":
https://patchmypc.com/blog/sccm-co-management-dual-scan
Hallo Willi K.,
vielen Dank für deine Antwort ich habe es genau so gemacht, wie Du es mir geschrieben hast.
Tatsächlich hat es mit der Antwort/Lösung von @Klaus2 geholfen.
Die Lösung war die Antwort von @Klaus2 und @Willi K.
Vielen Dank!
@Günter Born verstehe ich absolut, der Blog ist so sicherlich schon ausreichend Arbeit, es verlangt daher hoffentlich niemand, dass du dann auch noch nebenberuflich Relais spielst
@Enis-Aziz Ö. ich nehme an du meinst das Dual Scan Setting aus dem von Klaus verlinkten Blog? In der Theorie sollte es ohne den Key gehen und die Policy Sources ausreichen (steht irgendwo weiter unten auch genau so drin, habe ich gerade beim Überfliegen gesehen). Beim Ausprobieren hatten wir Dual Scan anfangs auch noch deaktiviert, irgendwann aber wieder aus der GPO rausgeworfen und es lief und läuft auch so (auch nach erneuter Bereinigung der WU Registry). So viel zur Theorie, in der Theopraxis spricht m.E. nichts dagegen, Dual Scan trotzdem sicherheitshalber zu deaktivieren.
Und in Umgebungen, in denen ein Proxy genutzt werden kann/soll, sollte auch noch die Checkbox, dass ein Fallback auf den Userproxy stattfinden darf, gesetzt werden.
Bzgl. Relais hätte ich kein Problem – nur geht das, was dann ausgetauscht wird, der Leserschaft verloren. Und darum geht es, die Beiträge sollen Admins im Fall der Fälle weiter helfen. Letztendlich betreibe ich den Blog für die Leserschaft – ich setze weder Windows Server noch WSUS noch MS 365 etc. ein, sondern werde mit Linux, W10 Enterprise LTSC und LibreOffice sowie WordPress bis ans Ende meiner Tage (als IT-Blogger) glücklich ;-)
Enis-Aziz Ö. hat mir folgendes per Mail mitgeteilt:
Das Problem ist für den Leser also behoben.
Hier keine Probleme. WSUS auf Windows Server 2025 mit vielen VMs ebenfalls Windows Server 2025, alles ohne Probleme. Ab und zu klemmt mal eine Maschine beim Update, aber alles andere problemlos!
Wir haben hier einen Server Core 2019 auf dem WSUS läuft und 2 Server 2025 die problemlos ihre Updates bekommen.
Vielleicht liegt es daran, dass wir nur das minimum Set an settings haben (heiße 9 Werte)?
Zumindest hatten wir nie ein Problem.
Auch Windows 11 24H2 war nie ein Thema.
Man muss allerdings penibel darauf aufpassen ja bloß keine "windows update for business" settings zu konfigurieren, denn sonst wars das mit WSUS.
Auch hier gibt es keinerlei Probleme mit Win11 24H2.
Keine Probleme von WS2016 – WS2025 in VM und Hardware über unseren WSUS (alles onprem), WSUS selbst ist noch WS2019y
Nach etwas Reddit-Recherche und Testen hat bei uns geholfen, zusätzlich die Richtlinie "Specify source service for specific classes of Windows Updates" unter "Computer Configuration\Administrative Templates\Windows Components\Windows Update\Manage updates offered from Windows Server Update Service\" für jede Kategorie auf "Windows Server Update Services" zu setzen.
(https://learn.microsoft.com/en-us/windows/deployment/update/wufb-wsus). Aus meiner Sicht eigentlich unnötig, aber die Updates wurden dann gleich in der Konsole angeboten und nach der Freigabe werden sie jetzt auch korrekt auf wen 2025er-Servern installiert.
Nachdem die Source-Konfiguration durchgeführt wurde, muss die DisableDualScan-Einstellung zwingend raus, da die Update-Funktionalität unter Windows 11 ansonsten nicht zuverlässig funktioniert.
Was genau bedeutet denn nicht zuverlässig funktioniert? Hier ist beides aktiv und die Updates funktionieren bisher sehr zuverlässig.
Wir hatten bei einigen Clients eine von zwei Problemarten. Im ersten Fall hat der Client gemeldet, er ist aktuell und benötigt neue Updates nicht und im zweiten Fall wurde der Update-Bedarf im WSUS korrekt angezeigt, die Rechner haben sich die Updates jedoch auch nach mehreren Tagen nicht geholt. Seitdem die Dual-Scan-Einstellung entfernt wurde, traten die Probleme nicht mehr auf.
Microsoft rät auch offiziell von der Einstellung ab. …The policy Do not allow update deferral policies to cause scans against Windows Update, also known as Dual Scan, is no longer supported on Windows 11 and on Windows 10 it's replaced by the new Windows scan source policy and isn't recommended for use…
Interessant. Dann werde ich das mal beherzigen und die Einstellungen abändern. Mich wundert es nur, dass es mit dieser nicht mehr unterstützten Konfiguration hier keinerlei Probleme gab. Der nächste Patchday wird es zeigen :)
Ich habe jetzt mal die ersten Testrechner gepatcht. Prinzipiell holen die 24H2 sich Updates, außer das .NET-Update (KB5064401). Das fordern sie nicht an, dafür zeigen sie beim .NET für die 23H2 (KB5064403) an, es sei installiert. Auch einige 23H2 Clients melden KB5064403 als Installiert, obwohl es für sie noch gar nicht freigegeben ist. Sehr seltsam.
Habe heute gelesen:
KB5065789 optionales Update Sept 2025:
Wartung Behoben: Dieses Update behebt ein Problem, das Windows Update für Kunden, die Windows Server Update Services (WSUS) verwenden, gestört hat.
Hm. Ob das Problem damit behoben wurde?