Ich stelle mal eine Beobachtung hier im Blog ein, die mir jetzt von drei Administratoren berichtet wurde. Unter Windows 11 24H2 und 25H2 funktionieren Gruppenrichtlinie, die den Neustart nach einer Update-Installation steuern sollen, nicht mehr. Windows Update löst nach der Update-Installation automatisch eine Neustart aus.
Worum geht es beim Problem?
In verwalteten Unternehmensumgebungen wollen Administratoren vorgeben, wann Windows nach der Installation eines Updates neu starten darf. Dieses Verhalten lässt sich per Gruppenrichtlinie vorgeben, was unter Windows 10 bisher auch funktioniert hat. Unter Windows 11 24H2 und 25H2 scheint das kumulative Update KB5068861 aber die GPOs außer Kraft zu sehen.
Leserbeobachtung #1: Automatischer Neustart des Clients
Blog-Leser User557 hat sich zum 19. November 2025 mit diesem Kommentar gemeldet und schildert seine unschöne Beobachtung. Zum 19. November 2025 wurde im Unternehmensumfeld das kumulative Update KB5068861 (für Windows 11 24H2-25H2 sowie für Windows Server 2025) installiert.
Im Anschluss trat in der Umgebung mit Windows 11 Enterprise ein merkwürdiges Verhalten auf, dass der Leser auf das obige Update zurückführt. Nach der Installation dieses Updates wurde auf vielen Geräten automatisch ein Neustart durchgeführt, ohne dass die üblichen Gruppenrichtlinien zum Schutz davor gegriffen haben. Besonders kritisch:
- Die betroffenen Geräte zeigten vorher keine Ankündigung oder Wiederherstellungs-Dialoge.
- Ein Benutzer war sogar aktiv am betreffenden Windows 11 24H2/25H2 Enterprise-Client angemeldet.
Eigentlich hätte dieser Neustart nie erfolgen dürfen, das die IT im Unternehmensumfeld unter anderem die folgenden Gruppenrichtlinie gesetzt hat:
- "Kein automatischer Neustart für geplante Installationen, wenn Benutzer angemeldet sind" ist aktiviert
- "Automatische Neustarts während der Nutzungszeit deaktivieren (07:00 – 16:00 Uhr)" ist aktiviert
- Updates werden per WSUS gesteuert, keine automatische Genehmigung von Funktionsupdates
Der Leser fragte, ob jemand aus der Blog-Leserschaft ähnliche Erfahrungen mit dem Update KB5068861 in Windows 11 24H2 gemacht hat? Vor allem wäre die Frage, ob das Verhalten des Zwangsneustart der Windows 11-Clients reproduzierbar ist?
Weiterhin wollte der Leser wissen, ob es bekannte Workarounds oder zusätzliche Richtlinien gibt, um dieses Verhalten künftig zu unterbinden? Der Leser fragt, ob es möglich sei, dass das Windows 11 24H2-Update trotz WSUS versehentlich durchgelassen wurde? Hier fällt mir spontan das Stichwort "Dual Scan" in Bezug auf Updates ein. Andy hat das beispielsweise im Beitrag Windows Update und WSUS: Probleme durch Dual Scan dokumentiert, und hier im Blog gibt es auch Treffer (siehe Falle: Windows-Clients installieren Updates am WSUS vorbei).
Leserbeobachtung #2: Automatischer Neustart des Clients
Zum 18. November 2025 hat sich Blog-Leser HessischerBub bei mir direkt per E-Mail gemeldet und schrieb unter dem Betreff "Seit Migration von Windows 10 22H2 auf Windows 11 24H2/25H2 Neustart nach Update mit WSUS": Falls das Thema Windows 11 & WSUS mal thematisiert werden sollte, folgende Beobachtung.
In der Firma des Lesers werden die Updates für die Windows 11-Clients über WSUS verteilt. Aber es gibt Probleme mit der unerwünschten Neustart-Aufforderung nach der Installation. Laut Blog-Leser hat die Steuerung der Update-Installation unter Windows 10 bisher funktioniert. Dort gab es, wie beabsichtigt und per Gruppenrichtlinie konfiguriert, keine Aufforderung für den Neustart des Clients.
Das sei jetzt nach der Migration auf Windows 11 24H2/25H2 nicht mehr der Fall, schrieb der Leser. Die Updates werden um 9:00 Uhr installiert und dann kommt folgender Hinweis:
"Wir haben ein Updates für Sie, Ihre Organisation verwaltet die Updateeinstellungen […] Wir werden um xx:xx einen Neustart durchführen."
Vom Nutzer des Windows 11-Clients lässt sich "Ein anderes Mal" anklicken. Aber die Meldung dann kommt erneut. Ignoriert der Benutzer die Meldung, weil dieser gerade nicht vor dem PC sitzt, wird der Neustart durchgeführt.
Leserbeobachtung #3: GPOs greifen nicht
Ergänzung: Bereits zum 14.11.2019 hat sich Florian per E-Mail gemeldet und schrieb mir unter dem Betreff "GPOs zu Windows-Neustarts unter Windows 11 funktionieren nur noch eingeschränkt – Erfahrung":
Ich schreibe Ihnen, da ich gerne Ihre Artikel verfolge und diese immer aufschlussreich sind und in Ihrem Blog eine gute Expertise herrscht.
Daher komme ich nun mit einer allgemeinen Frage auf Sie zu, vielleicht haben Sie dazu schon Erfahrungen oder etwas durch Hören/Sagen mitbekommen.
Zum Problem: Im IT-Umfeld, in dem der Leser tätig ist, werden die Update-Einstellungen für Windows per GPO geregelt. Die IT gibt über Gruppenrichtlinien (GPOs) die Installationszeitpunkte vor und verwaltet das Ganze über WSUS. Bisher funktionieren diese GPOs unter Windows 10 22H2 Enterprise ohne Probleme, unter Windows 11 2024, schreibt der Leser. Unter LTSC Enterprise klappt das allerdings nicht mehr, ist die neue Erfahrung.
Der Leser schrieb: "Hier werden nach der geplanten Installation der Updates bei den Nutzern einfach Neustartvorschläge innerhalb von 15 Minuten vorgeschlagen und wenn man dies nicht abbricht auch durchgeführt." Das sei zwar das Standardverhalten von Windows.
Allerdings hat die IT dafür extra die GPO "No auto-restart with logged on users for scheduled automatic updates installations" auf "Enabled" gestellt. Unter Windows 10 werde dementsprechend auch kein automatischer Neustart durchgeführt, unter Windows 11 leider doch, schreibt der Leser.
Dies sei für das IT-Umfeld des Leser allerdings nicht tragbar, da teilweise Messungen oder Berechnungen über Nacht laufen und daher keine Neustarts durchgeführt werden sollen. Die geplanten Installationszeitpunkte möchte die IT allerdings auch nicht aussetzen, da die Nutzer sonst zum großen Teil niemals selber Updates installieren. Der Leser hat mir noch folgende kurze Übersicht der gesetzten GPOs mitgeschickt
„Legacy Policies":
„Manage End User Experience":
Der Leser schrieb dazu noch: Ich weiß, dass der Teil mit "No auto-restart…" sich unter den Legacy Policies befindet, aber dass dieses Verhalten nun so umgestellt worden ist, erschließt sich mir nicht ganz. Er fragt: "Haben Sie einen Tipp oder wissen wie andere Unternehmen damit umgehen?"
Eine Fundstelle im Internet
Der Blog-Leser HessischerBub hat mir dann noch mitgeteilt, dass er im Internet unter Microsoft Q&A auf den Post Zwangsneustart mit 15-Minuten-Timer nach Windows Updates vom 3. September 2025 gestoßen ist. Dort wird sinngemäß das gleiche Problem wie in den beiden obigen Lesermeldungen angesprochen.
- Der Nutzer soll über den Abschluß der Installation von Windows-Updates (z.B. zum monatlichen Patchday) und einen notwendigen Neustart informiert werden, den Zeitpunkt des Neustarts aber selbst bestimmen können. Keinesfalls soll der Rechner automatisch neu starten, so lange ein User an seinem Rechner angemeldet ist, ohne dass der User den Neustart aktiv initiiert.
- Das Problem: Innerhalb der AD-Domäne dieses Thread-Starters starten die Rechner nach der Installation von Windows Updates am Patchday automatisch neu, ohne dass sich der Neustart verhindern oder verzögern lässt. Hierbei erhält der Nutzer nur eine blaue Systemmeldung mit der Zeitangabe des bevorstehenden Neustarts und den Optionen "Close" und "Restart", eine Option "Postpone" o.ä. fehlt
Der Thread-Ersteller beschreibt seine Einstellungen, die er in Windows 11 gesetzt hat, um diese automatischen Neustarts zu verhindern, die aber wirkungslos sind.
Hinweis des Blog-Lesers zu den GPOs
Blog-Leser HessischerBub schrieb mir zu dem obigen Eintrag im Internet, dass er zwar nicht genau die selben Einstellungen habe. Die Konstellation lief aber mit Windows 10 bisher einwandfrei. Einziger Unterschied seit die Vorgabe "Specify source service for specific classes of Windows Updates" sei erforderlich, damit die Freigaben am WSUS beachtet werden. Da sei vorher "Do not allow update deferral policies to cause scans against Windows Update" ausreichend gewesen, damit die Freigaben in WSUS beachtet wurden und Windows Update manuell aufgerufen werden konnte, um mal außer der Reihe Updates direkt über Microsoft Update aufzurufen.
Der Blog-Leser hat mir dann noch folgende Konfigurierungen der benutzten Gruppenrichtlinien durchgegeben:
Windows Components/Windows Update/Legacy Policies
Do not allow update deferral policies to cause scans against Windows Update=Aktiviert
No auto-restart with logged on users for scheduled automatic updates installations=Aktiviert.
Windows Components/Windows Update/Manage end user experience
Configure Automatic Updates=Aktiviert
4 – Auto download and schedule the install
Scheduled install time: 09:00
Turn off auto-restart for updates during active hours=Aktiviert
7:00 – 15:00 Uhr
Windows Components/Windows Update/Manage updates offered from Windows Server Update Service
Automatic Updates detection frequency=Aktiviert
3h
Specify intranet Microsoft update service location=Aktiviert
Den internen WSUS eingetragen.
Specify source service for specific classes of Windows Updates=Aktiviert
Alles auf Windows Server Update Services gesetzt.
Die Frage an die Leserschaft ist, ob es ähnliche Beobachtungen gibt und ob den obigen Betroffenen ein Fehler unterlaufen ist?
Ähnliche Artikel:
Microsoft Security Update Summary (11. November 2025)
Patchday: Windows 10/11 Updates (11. November 2025)
Patchday: Windows Server-Updates (11. November 2025)
Windows 10 22H2: Out-of-Band-Update KB5071959 (11. Novmber 2025)
Windows 11 23H2-25H2: Preview Updates (28. Oktober 2025)
Windows 11 24H2/25H2: Localhost-Probleme nach Oktober 2025-Update KB5066835
Windows 11 24H2-25H2/Server 2025: Microsoft fixt Problem mit IIS/localhost
Windows 11 24H2/25H2: Task-Manager wird nach Okt. 2025-Update nicht beendet
Windows 11: Folder Auto-Discovery bremst Explorer – Optionen zum Abschalten
Windows 11 24H2-25H2: Zähe Startmenü-Suche; Preview KB5067036 bremst Suche auf File-Server
Windows Nov. 2025-Patchday-Nachlese – diese Probleme sind aufgetaucht
MVP: 2013 – 2016
Automatischer Neustart der Clients? Lächerlich! Auch die Server starten automatisch neu. Das setze ich inzwischen sogar bewusst ein, wenn ich nicht auf Neustart-Fenster warten will.
Tipp für alle, die (noch) an "dies das unerwünschte Dings kann ich aber in der Registry abschalten" oder ".. per GPO abschalten" glauben, früher oder später wird man euch jede einzelne Möglichkeit der Kontrolle nehmen, schön langsam und salamischeibchenweise, man denke da nur an den Frosch, der im langsam immer heisser werdenden Wasser sitzt.
Wieviele Mitarbeiter hat dein Unternehmen? Einen?
…Gschichten ausm Paulanergarten…
Ich weiß ja nicht, wen Du jetzt meinst @Martin Feuerstein oder mich als Artikelautor (ich bin Single Man Show ohne WSUS, GPO und doppelten Boden, dafür aber mit Windows 10 IoT 2019 Enterprise LTSC- und Linux-Clients).
Von Susan Bradley (AskWoody) habe ich auf X die Antwort auf meinen Tweet gehört, dass sie die Neustart-Verzögerung auch nicht mag, weil die Clients ohne Neustart "in einen komischen Zwischenstatus geraten".
Da sitzt schon noch ein WSUS vor – Updates gibts nur wenn ich sie freigebe.
Updates anstoßen muss ich noch selbst, soweit greift die Policy noch. Nur den Neustart dürfen die Server nachts alleine ausführen.
Das Verhalten ist seit Windows 11, "erste Generation" bekannt. Die GPO "no auto restart with logged on users" greift nicht mehr. Aber wenn niemand mit MIcrosoft Support in den Ring steigt, dann ändern die das auch nicht – sie selbst benutzen diese GPO nicht, da sie längst keinen WSUS mehr benutzen sondern Updates anders verteilen. Deren Entwickler merken nicht mehr viel, das sollte aufgefallen sein.
Leider hatten wir auch dieses Problem…
Wir machen das per MECM und jeder kann das Update stundenweise vor sich her schieben, aber wenn der Benutzer das nicht wegschiebt, also spätestens Abends, passiert es. Wir haben im Laufe des Jahres das Update-Verhalten schrittweise verschärft, weil viele User das einfach übergangen haben und die Kisten ewig nicht uptodate waren. Gestern hatte ich allerdings einen Test-PC mit 25H2, der aber trotzdem einen Reboot gemacht hat. Hab dem aber keine Bedeutung beigemessen, ich beobachte mal…
Kann ich bestätigen das Verhalten ist seit ein paar Wochen so. Sehr nervig
Ebenfalls.
Moin,
wo ich so drüber nachdenke, kam am Client ein Popup, ob jetzt neustarten oder später.
Habe ich aber nicht weiter Aufmerksamkeit gewittmet, weil ich gerade gearbeitet habe 😆
MfG,
Blackii
Letztes monatliche Update habe ich über Kommandozeile deinstalliert und mein Rechner in der Firma eingeschaltet gelassen. Kann per VPN und RDP testen. Update wird schon angezeigt. Installiert sollte es dann Morgen um 3:00 Uhr werden, wenn ich friedlich schlafe. :-) Morgen dann mal sehen, ob der Satz "test test test" in der Eingabeaufforderung noch zu sehen ist.
Heute alle Richtlinien aus dem Legacy-Zweig entfernt.
Mit "Automatische Updates konfigurieren", "4 – Autom. Herunterladen und laut Zeitplan installieren" hatte ich mit aktivierter "Während automatischer Wartung installieren" bei Konfigurierte Updaterichtlinien (Clientrechner in Einstellungen zu finden) den Wert 5 angezeigt bekommen???? Deaktiviere ich "Während automatischer Wartung installieren" ist Wert 4 zu sehen der sich mit dem Wert deckt den ich in der Richtlinie gewählt habe.
Für "Während automatischer Wartung installieren" muss man manuelle Wartungspläne erstellen oder wird dann installiert wenn aus einem Grund einer der Standardwartungspläne ausgeführt wird? Ich frage wegen:
Wenn ich jetzt als Geplante Installationszeit=3:00 Uhr eintrage, installieren die Rechner dann überhaupt irgendwann wenn die um diese Zeit nicht angeschaltet sind?
Automatischen Neustart nach Updates während der Nutzungszeit deaktivieren=Aktiv, Nutzungszeit 6:00 – 23:00 Uhr
Suchhäufigkeit für automatische Updates=3h (jetzt zur Überprüfung so gesetzt, dann sehe ich das Update(s) zum installieren angezeigt werden.
Lokale Registry:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"WUServer"="http://wsus03.domaenenname.loc:8530"
"WUStatusServer"="http://wsus03.domaenenname.loc:8530"
"UpdateServiceUrlAlternate"=""
"SetProxyBehaviorForUpdateDetection"=dword:00000000
"SetPolicyDrivenUpdateSourceForFeatureUpdates"=dword:00000001
"SetPolicyDrivenUpdateSourceForQualityUpdates"=dword:00000001
"SetPolicyDrivenUpdateSourceForDriverUpdates"=dword:00000001
"SetPolicyDrivenUpdateSourceForOtherUpdates"=dword:00000001
"SetActiveHours"=dword:00000001
"ActiveHoursStart"=dword:00000006
"ActiveHoursEnd"=dword:00000017
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]
"UseWUServer"=dword:00000001
"DetectionFrequencyEnabled"=dword:00000001
"DetectionFrequency"=dword:00000003
"UseUpdateClassPolicySource"=dword:00000001
"NoAutoUpdate"=dword:00000000
"AUOptions"=dword:00000004
"ScheduledInstallDay"=dword:00000000
"ScheduledInstallTime"=dword:00000003
"AllowMUUpdateService"=dword:00000001
Nicht das durch die Migration Einträge fest drin stehen die mit neuen ADMX-Dateien in PolicyDefinition nicht mehr angezeigt werden und dann drin verbleiben.
Warum verbinden sich deine Clients über eine unsichere Verbindung mit dem WSUS?
Du solltest das auf SSL umstellen.
Die Adresse lautet dann:
"https://wsus03.domaenenname.loc:8531"
Auch in internen Netzwerken sollte man möglichst verschlüsselte Verbindungen nutzen.
was soll da passieren über http intern?
Setzt Du bei SMB auch Verschlüsselung ein?
Natürlich wird smb verschlüsselt.
Und WSUS über http kann innerhalb von Sekunden übernommen werden.
Wurde uns durch einen Pentester vor kurzem sehr eindrucksvoll demonstriert.
15 Sekunden von login bis local admin
"Kann man doch einstellen"
wtf … und da soll nochmal wer sagen Linux wär umständlich.
Merkt irgendwer noch was?
Windows als Konzept hat m.E. zunehmend fertig.
Ich wünsch viel Spass zukünftig Windows AI-Agenten zu konfigurieren.
Kann das ganze phänomen ebenfalls bestätigen. Haben bei uns auch die gängigen GPOs gesetzt. (Updates via WSUS) Hat bisher auch (meistens) gut funktioniert.
Nur dieses mal waren es auffällig viele Rechner die "netterweise" unsere User zum neustart zwangen. Uns ist allerdings aufgefallen, dass dies vorallem Kollegen betraf wo der PC gesperrt war. (In unserem Fall über die Mittagspause)
Wirklich sehr nervig das ganze….
Ist leider bei alle mein Kunden wo WSUS im Einsatz passiert. Win11 24H2/25H2.
Ist sehr störend für Leute die nicht gespeicherte Dokumente haben, und den PC allein lassen…
Ich werde jetzt die wichtige PC Updates nicht mehr am Dienstag Abend un 21h freischalten, sondern am Mittwoch um 14h um das Frustrationlevel zu senken !
Die Policy "No auto-restart with logged on users" sollte aber bitte bald wieder funktionieren !
Mega das du darüber schreibst! Ich dachte schon was ist hier los… Seit dem Cumulative Oktober starten unsere Clients einfach neu. Bin die GPOs rauf und runter gerattert. Gibt ja auch nicht viele. Die Konfiguration hat sich nicht geändert. Ich habe nun die automatische Installation im Hintergrund deaktiviert und es folgt lediglich eine Installations-Aufforderung. Beschwere mich eher selten über Windows Updates, da diese bei uns seit Jahren keine Probleme verursachen. Die Shutdown-macht-Reboot-Problematik in den Patchnotes gelesen zu haben war klasse. Dafür aber jetzt Forced-Reboots… Danke für nichts. Wir nutzen WSUS, die GPO "no restart when user logged on" und die Nutzungszeit auf 05:00-21:00 Uhr. Wird komplett ignoriert.
Da wünsche ich mir das Verhalten von Windows 7 zurück:
Updates werden installiert, wenn der Benutzer den Rechner herunterfährt.
So hat man keine unerwünschten Neustarts während der Arbeitszeit.
Das ist absolut kontraproduktiv. Denn die PCs laufen heutzutage durch und werden höchstens mal gesperrt oder in den Ruhezustand geschickt. Mit deiner Forderung würden die Kisten monatelang keine Updates bekommen.
Das ist aber aus Umwelt- und Kostengründen kontraproduktiv.
Da verbrauchen die PCs mit Nichtstun unnötig Strom!
Das wäre der erste Ansatz, um in einem Unternehmen Kosten zu sparen.
Bei uns werden die PCs zu Feierabend immer heruntergefahren.
Und damit alle Daten auch zuverlässig in der täglichen Datensicherung landen, gibt es ein striktes Verbot, Daten auf den PCs zu speichern.
Die müssen zwingend auf einem Server gespeichert werden.
Auf den PCs selbst ist nur das Betriebssystem und die Anwendungen, sonst nichts.
Das hat noch einen Vorteil:
Man kommt mit verhältnismäßig kleinen SSDs in den PCs aus.
Auch das spart Geld.
Das Userverzeichnis ist übrigens im AD auf ein Serverlaufwerk umgebogen. D.H., die Leute können im Userverzeichnis Dateien ablegen, diese liegen aber nicht auf dem PC, sondern auf dem Server.
An Umwelt und Stromverbrauch denkt wohl schon lange keiner mehr seit der stromfressende "KI" Wahnsinn am Start ist.
Würde man an Umwelt/Stromverbrauch denken, würd man wohl am ehesten Apple mit seinen M-CPUs nehmen.
Gerät mit eingelöteter SSD laufen in meinen Verständnis nicht unter "Umweltbewußt" :-D
Da ist nichts nachhaltig.
Und es gibt mittlerweile im Tiny Segement viele Geräte, die im normalen Büroalltag genau so wenig Energie verbrauchen wie die Apple Geräte. Dafür kann ich dort Speicher und SSD austauschen, zur Wartung einfach und schnell öffnen und sogar noch mit PCIe bzw. einem NVMe Steckplatz erweitern.
Umwelt-technisch gesehen schlagen diese Geräte Apple bei weitem. (Und ich darf mir mein Betriebssystem selbst aussuchen…)
"Das ist aber aus Umwelt- und Kostengründen kontraproduktiv.
Da verbrauchen die PCs mit Nichtstun unnötig Strom!
Das wäre der erste Ansatz, um in einem Unternehmen Kosten zu sparen."
Was ein wertvoller Hinweis…
Die Theorie ist klar, aber wie genau willst du das überwachen? Wir müssen gerade sogar die Energiespar-Richtlinien per GPO vorgeben, weil einzelne Nutzer aus Bequemlichkeit verhindern, dass das Gerät in Pausen in Standby geht. Von den "Dauer-Standby"-Nutzern ganz abgesehen, deren Rechner ohne Zwang keine Neustarts sieht.
Das wäre vermutlich einfach lösbar:
2 Kernel: dann kann Windows einfach im laufenden Betrieb den andern Patchen, und dann im laufenden Betrieb umschalten.
So wies jetzt läuft ists hochgradig nervige Gängelei – die Woche diverse Kollegen die nach der Mittagspause ihre Arbeit verloren haben, weil die Kisten ungefragt neustarteten.
Wie verhält es sich denn mit DSC anstatt GPO?
ich finde es interessant, dass dieser artikel auf google news zu sehen ist.
über windows update auswüchse und gpo's die falsch bzw. anders reagieren, darf man sich seit w10 nicht mehr aufregen, ist gewollt damit systeme (endlich) up to date sind, wer hat schon eine produktion 😉
was zuverlässig hilft: fw std block out, allow rule für wu, diese per script zu gewünschten zeiten aktivieren und update forcieren. Gegenscript für deaktivierung. Klappt über alle Versionen hinweg. stress vorbei.
Mit 25H2 kam gestern nur ein Neustart Popup, sind aber auch schon länger weg von WSUS ;)
bisher keine Änderungen, Updates werden installiert (WSUS), User kann den Neustart verschieben. Alles per GPO, sollte also noch funktionieren
Mir fällt das Verhalten auf, seit wir Windows 11 einsetzen (haben Anfangs Jahr mit 24H2 gestartet). Allerdings scheint es so, dass das nur auftritt, wenn die Updateinstallation manuell angestossen wird. Jedenfalls hat mir bisher kein User sowas gemeldet, und die machen idR die Updates nicht manuell sondern Windows macht das irgendwann. Aber auch bei uns greifen die Policies nicht mehr 100%ig. Hab zb. auch eine Nutzungszeit eintragen müssen (war mit Win10 nicht nötig), so scheint zumindest die automatische Installation nicht ganz so zu nerven wie wenn manuell getätigt.
Was ich nicht verstehe, warum lässt sich der neustart um max. 15 min verschieben und nicht länger. Ist mir auch schon passiert dass ich dann nicht mehr am PC sass und der halt einfach neu gestartet hat.
Wobei dieses Verhalten scheinbar nicht bei jedem Update auftritt. Jedenfalls bis September meinte ich, das alle 2-3 Monate beobachtet zu haben. Oktober und November Update pushten aber nun beide einen Neustart, wobei ja der November bei uns noch nicht grossflächig verteilt wurde aufgrund der Such-Problematik auf Netzlaufwerken.
Microsoft ignoriert immer mehr GPOs, bzw. erklärt plötzlich einstellungen als "Legacy" . Nichts funktioniert in Bezug auf Updates dann mehr so, wie man es nach den GPO Texten erwartet. Früher konnte man sich auf die DUal Scan Sache verlassen, jetzt auch nicht mehr. Man muss aber auch bedenken, Microsoft hat den WSUS als deprecated erklärt.
Ich empfehle die Umstellung auf ein anderes Patch Management Tool
Kann ich zustimmen. Seit der deprecated Ankündigung seitens Microsoft geht es auch mit WSUS und GPOs dahingehend Berg ab. Also eigentlich nur ein weiterer Schritt irgendwie Intune und M365 durchzudrücken, weil da geht ja noch alles….
Oder Drittanbieter Patchmanagement ;-)
Gibt auch einige.
Genau das Problem haben wir seit diesem Monat weil letzten Monat alle auf Windows 11 umgestellt wurde. GPOs sind alle korrekt und funktionierten auch mit Windows 10. Windows 11 ignoriert den WSUS aktuell sogar komplett, es ist nicht nur ein Neustart sondern alle Updates werden online geholt egal ob im WSUS freigegeben oder nicht und anschliessend installiert mit erzwungenem Neustart.
Server sind aktuell keine betroffen, aber wir haben auch aus diversen Gründen keine 2025 im Einsatz. Ich denke 2025 wird das selber Verhalten haben.
Dank nochmals an Microsoft für solch coole Features, Windows 11 ist perfekt und definitiv besser als ein funktionierendes Windows 10.
(Ich hoffe da kommt mal jemand persönlich vor Ort für eine Lizenzprüfung, dann sehen wir dann wer am längeren Hebel sitzt)
Du hast wahrscheinlich "Do not allow update deferral policies zu cause scans agains Windows Update" für Windows 10 aktiviert. Das hilft bei den neueren Buils von Windows 11 (oder sogar schon immer bei Windows 11) nicht mehr.
Specify source service classes of Windows Updates
Unterstützt: >= Windows 2022, Windows 10 Version 2004 laut Beschreibung
Ich denke mal, eine eigene GPO pro Betriebssystem und wahrscheinlich bald auch pro Feature-Updat(also eine pro Jahr) hilft den Überblick zu bewahren und man läuft nicht Gefahr das nach jeder Änderung was anderes nicht mehr funktioniert.
Da gibt es folgenden Artikel dazu:
https://techcommunity.microsoft.com/blog/windows-itpro-blog/why-you-shouldn%E2%80%99t-set-these-25-windows-policies/3066178
Fazit du sollt keinesfalls legacy Windows Update settings mit den neuen mischen… das macht komisches :).
Hoppla, hatte das heute auch. Dabei sollte die Workstation die Updates gar nicht von alleine installieren. Hängt am WSUS. Die ist schon mindestens seit Februar in Betrieb und bisher hat es auch genau so funktioniert. Hmpf!
Dieses Verhalten können wir unserer Umgebung leidvoll Bestätigen. Es trifft vor allem die Geräte die aus verschiedenen Gründen nachts eingeschaltet sind.
Dieser Zwangsreboot trotz aktiver Useranmeldung führt dann auch zu Fehlern bei offenen Anwendungen die nicht genügend Zeit haben zu schließen.
Beispiel ist VMware Workstation und aktiver virtueller Maschinen.
Einen Workaround zum Herunterladen und Installieren von Updates via WSUS ohne Zwangsreboot haben wir leider noch nicht gefunden.