Windows Server 2019 ignoriert seit Nov. 2022 GPO-Vorgaben und macht Installation/Restart am Tag der WSUS-Freigabe

Windows[English]Heute noch eine Beobachtung eines Administrators im Hinblick auf die Update-Verwaltung per WSUS. Auf einem Windows Server 2019 sind per GPO die Vorgaben so gesetzt, dass Updates automatisch jeden Montag/ Donnerstag um 1 Uhr morgens installiert werden und der Server danach neu gestartet werden soll. Mit den November 2022-Updates hat das aber nicht funktioniert, die Installation samt Neustart erfolgte am Freitag ab 18 Uhr, der Tag, an dem der Administrator die Aktualisierungen am WSUS genehmigt hatte.


Anzeige

Blog-Leser Joachim hat bereits im englischsprachigen Blog in diesem Kommentar auf die Problemstellung hingewiesen, mich dann aber nochmals separat per E-Mail mit weiteren Informationen versorgt. Das Ganze wurde von ihm auch im Spiceworks-Forum unter Windows Server 2019 updated and restarted on the wrong day regardless of GPO eingestellt. Wie bereits in obigem Text erwähnt, handelt es sich um einen Windows Server 2019, dessen GPO-Einstellungen Vorgaben für die Installation von Updates machen. Laut Joachim gilt folgendes:

  • Updates sollen automatisch jeden Montag/Donnerstag um 1 Uhr morgens installiert werden
  • Nach der Update-Installation soll dann automatisch ein Neustart erfolgen, um die Installation abzuschließen

Die Verwaltung der Updates erfolgt per WSUS und Joachim hat drei WSUS-Gruppenrichtlinien gesetzt:

  • a) Eine Richtlinie, die Updates nicht automatisch installiert. Server mit dieser Einstellung haben die Updates nicht installiert und wurden nicht neu gestartet.
  • b) Eine Richtlinie, die Updates automatisch installiert und am Montag neu startet. Dies geschieht, indem der Bereich auf eine AD-Gruppe mit diesen Servern festgelegt wird.
  • c) Eine Richtlinie zur Update-Installation, die wie oben funktioniert, aber am Donnerstag neu startet.

Die Richtlinien b und c funktionierten bis zu den November 2022-Updates wie erwartet. Bei den Updates vom 8. November 2022 ging das aber schief. Mit dem November-2022-Update wurden die 2019er-Server, die jeden Montag/Donnerstag um 1 Uhr morgens automatisch installiert werden sollten, am Freitag (dem Tag, an dem die Updates genehmigt wurden) ab 18 Uhr neu gestartet.

In der Ereignisanzeige hat Joachim den folgenden Eintrag gefunden:

System Eventlog ID 1074
The process C:\Windows\system32\svchost.exe (S0****)
has initiated the restart of computer S0*** on behalf of user
NT AUTHORITY\SYSTEM for the following reason:
Operating System: Service pack (Planned)

Reason Code: 0x80020010
Shutdown Type: restart

Eine Prüfung des AUService mittels des nachfolgenden Power-Shell-Befehls:

New-Object -ComObject "Microsoft.Update.ServiceManager").Services | Select-Object Name, IsDefaultAUService

lieferte folgende Ausgabe:

Name                         IsDefaultAUService
----                         ------------------
DCat Flighting Prod                       False
Windows Store (DCat Prod)                 False
Windows Server Update Service             True
Windows Update                           False

Eine Abfrage mit gpresult /h zeigt, dass nur das richtige GPO auf einen Server angewendet wird, der am Freitag noch neu gestartet wurde. Auf Spiceworks sind noch weitere Details, u.a. der GPO-Vorgaben, aufgelistet. Laut Joachim hat diese Konstellation bis Ende Oktober 2022 wie gewünscht funktioniert, scheiterte aber bei den November 2022-Updates. Seine Frage lautet, ob jemand sonst noch dieses Verhalten beobachten konnte?


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Update, Windows Server abgelegt und mit , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

15 Antworten zu Windows Server 2019 ignoriert seit Nov. 2022 GPO-Vorgaben und macht Installation/Restart am Tag der WSUS-Freigabe

  1. Markus K. sagt:

    Was ich mich erinnern kann, hat es bei uns auch die Server 2019 erwischt, was das allerbeste war, dass Server die nicht einmal in der target group für die man freigegeben hatt die updates auch installiert haben.

    Ich ignoriere solche Verhalten inzwischen, da ich das von clients kenne. Schlimm nur, wenn dabei etwas kaputt wird.
    Bei clients passiert es auch immer wieder einmal dass ein paar direkt zu Microsoft gehen. Schon daran zu sehen, dass manche Geräte 21H1 installiert haben, welches wir am WSUS nie freigegeben hatten. Wo kommt das her, wenn nicht von Microsoft?
    Eigentlich kann man nur staunen, was da immer wieder an Nebeneffekten von Updates auftaucht.

    • Michael sagt:

      Dual Scan muss explizit deaktiviert werden, wenn nicht, dann können Clients sowohl über Microsoft als auch WSUS updates anfragen. Dann klappt's auch.

      • Joachim sagt:

        Dual Scan kann nicht das Problem sein, da Server ohne automatischen Neustart per GPO nicht betroffen waren.
        Auch wurde das Update nicht ohne Freigabe am WSUS eingespielt, sondern das Problem besteht darin, dass nach der Freigabe durch WSUS ein Neustart am selben Tag erfolgt ist, entgegen der GPO Einstellungen.

  2. Cornelia sagt:

    Wir nutzen WSUS nicht. Auf den Kundenservern installieren wir die Updates jeweils ca. 3 Wochen nach Freigabe durch Microsoft – also 1 Woche vor den folgenden Updates. Auf einzelnen Servern (nicht immer den gleichen) kommt es aber gelegentlich vor, dass die bei anderen Servern noch anstehenden Updates bereits 'automatisch' installiert worden sind.
    Im Zusammenhang mit WSUS hätte ich ein derartiges Verhalten zwar nicht erwartet, es überrascht mich aber nicht.

  3. Daniel sagt:

    Wir konnten bei einem 2012 R2 ohne WSUS dasselbe Verhalten beobachten. Obwohl in den Windows-Update Einstellungen nur der manuelle Download und Installation festgelegt war, wurden Updates und Neustart mitten am Tag durchgeführt.

  4. Mark Heitbrink sagt:

    Achtung: Richtlinien Übertnahme, Der Übernahme Prozess löscht und fügt alles wieder neu hinzu. Die Integration erfolgt nicht additiv. Es werden nicht nur die 2, 3 Werte hinzugefügt, die fehlen oder einer gelöscht, Nein! Das Prozess wirft alles weg und übernimmt alles erneut.

    In dem kurzen Moment der GPO Übernahme ist der Rechner Richtlinien frei und die Dienste machen, was sie wollen …
    https://www.gruppenrichtlinien.de/artikel/registrierungsrichtlinien-auch-ohne-aenderung-uebernehmen-niemals

  5. Abrissbirne sagt:

    ich kann nur raten so schnell wie möglich (funktionierendes) Patch-Management einzuführen, je nach Betriebsgröße sind das unter umständen 1-x vollzeit Stellen aber es lohnt sich ;-) bereits nach erstem PatchDay …

    • Joachim sagt:

      Wir haben ein bisher funktionierendes Patch-Management per GPO umgesetzt mit manuellen Test am Freitag, automatischem Test am Montag und dann automatischer Installation am Donnerstag bzw manueller Installation am Donnerstag für System, die manuell gestartet werden müssen.

      Die Frage war aber nicht, welches Patch-Management am besten ist, sondern ob jemand die Restarts erklären kann. Ich würde mich freuen, wenn Sie da konstruktives Feedback hätten.

  6. Jan Vauseweh sagt:

    Danke für den Hinweis, ich kann das beschriebene Verhalten bei uns aber zum Glück nicht bestätigen. Derzeit aktualisieren unser 2019er über WSUS und der jeweils für das System gülte GPO korrekt. Werde aber weiterhin ein wachsames Auge auf das Thema haben.

  7. Hans sagt:

    Kein Server von 2012 bis 2019 hat etwas am WSUS vorbeigemacht mit den November Updates. Nur die TEST Gruppe hat es wie vorgesehen am geplanten Tag Installiert. Die Updates waren also auch für eine bestimmte WSUS Gruppe zum Installieren freigegeben.

  8. Georg Burth sagt:

    Mir sind keine Server aufgefallen, die sich die Updates automatisch gezogen hätten bzw. ohne Aufforderung neu gestartet sind. Alle Server mit installierten Updates wurden explizit zum Update aufgefordert.

  9. Joachim sagt:

    Update: eine weitere Recherche hat ergeben, dass diese automatischen Restarts immer dann passieren, wenn Microsoft ein Update als "Service Pack" markiert. Im Eventlog spiegelt sich ja auch wieder (Operating System: Service pack (Planned)).
    Eine offizielle Quelle habe ich dazu leider nicht gefunden, nur die Beobachtungen von anderen.

    Die Frage ist nun, wie man das erkennt und ob man das beeinflussen kann.

  10. NetworkadminSK sagt:

    Ich muss dieses Verhalten an meinen 2022 Servern leider bestätigen. Beide stehen sowohl per GPO als auch in der SCONF auf manuell. Dennoch haben beide heute Nacht automatisch durchgestartet. Im Eventviewer wird (Operating System: Service pack (Planned)) angegeben. Ich finde dieses Verhalten inakzeptabel, da so die nächtlichen Backups fehlschlagen.

  11. Daniel sagt:

    Hallo zusammen,

    wir sind seit einigen Wochen auch dabei. Gestern wurden erneut einfach ein halbes Dutzend Systeme durchgestartet.

    Auch bei uns der Code 0x80020010 und als Reason "Service pack (Planned)"

    Gibts bei euch schon neue Erkenntnisse?

    Ich bilde mir ein, dass ich das vor einigen Wochen schon mal recherchiert habe und auf eine Info stieß "Wird bei MS mit einem Bug-Ticket bearbeitet". Aber die Info finde ich nicht mehr.

    Viele Grüße

  12. Tobias sagt:

    Hallo zusammen,

    bei uns tritt ein ähnliches Problem aktuell mit einem neu aufgesetzten Server 2022 auf.
    laut gpresult /h wurde die Richtlinie mit der Einstellung 3 -> also automatisches herunterladen, jedoch händisches installieren übernommen.
    Der Server macht jedoch alles automatisch, zusätzlich steht auch unter der Schaltfläche von Windows Updates in den Einstellungen, dass "Updates automatisch heruntergeladen sowie installiert werden"

    Hier scheint jemand auf das gleiche Problem gestoßen zu sein:
    Windows Server 2022 not updating from WSUS

    Gibt es eine Möglichkeit dies zu fixen?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.