testperson 1.677 Geschrieben 13. November 2020 Melden Teilen Geschrieben 13. November 2020 Hi, mein WSUS bzw. einzelne Windows Update Clients (Windows Server 2012 R2 / 2016 / 2019) und ich haben noch ein Problem: Nach Updates (die einen Reboot benötigen) erfolgt nicht immer ein Reboot. Meine Policies: Automatische Updates konfigurieren (aktiviert): 4 - Autom. Herunterladen und laut Zeitplan installieren Automatischen Neustart nach Updates während der Nutzungszeit deaktivieren (Nicht konfiguriert) Erneut zu einem Neustart für geplante Installationen auffordern (aktiviert): 5 Minuten Keinen automatischen Neustart für geplante Installationen automatischer Updates durchführen, wenn Benutzer angemeldet sind (Deaktiviert) Neustart für geplante Installationen verzögern (aktiviert): 5 Minuten Neustart immer automatisch zur geplanten Zeit durchführen (aktiviert): 15 Minuten Frist angeben, nach der ein automatischer Neustart zur Updateinstallation ausgeführt wird (Nicht konfiguriert) Zeitplan für geplante Installationen neu erstellen (deaktiviert) Habe ich hier irgendwelche Einstellungen gesetzt, welche einen Reboot verhindern oder sich gegenseitig aufheben? Bzw. wie sollte ich WU konfigurieren, dass definitiv nach der Installation gebootet wird, egal ob User angemeldet oder nicht? Vielen Dank und Gruß Jan Zitieren Link zu diesem Kommentar
Beste Lösung Sunny61 806 Geschrieben 13. November 2020 Beste Lösung Melden Teilen Geschrieben 13. November 2020 Mit diesen Einstellungen starten unsere Server, sofern sie Updates installiert haben, nachts um 3 Uhr neu durch: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate] "DisableDualScan"=dword:00000001 "AcceptTrustedPublisherCerts"=dword:00000001 "SetAutoRestartRequiredNotificationDismissal"=dword:00000001 "AutoRestartRequiredNotificationDismissal"=dword:00000002 "SetAutoRestartNotificationConfig"=dword:00000001 "AutoRestartNotificationSchedule"=dword:000000f0 "SetActiveHours"=dword:00000001 "ActiveHoursStart"=dword:00000007 "ActiveHoursEnd"=dword:00000011 "DoNotConnectToWindowsUpdateInternetLocations"=dword:00000001 "SetAutoRestartNotificationDisable"=dword:00000001 "SetAutoRestartDeadline"=dword:00000001 "AutoRestartDeadlinePeriodInDays"=dword:00000002 "SetActiveHoursMaxRange"=dword:00000001 "ActiveHoursMaxRange"=dword:0000000c "SetRestartWarningSchd"=dword:00000001 "ScheduleRestartWarning"=dword:00000008 "ScheduleImminentRestartWarning"=dword:0000003c "WUServer"="http://meinWSUS:8530" "WUStatusServer"="http://meinWSUS:8530" "UpdateServiceUrlAlternate"="http://meinWSUS:8530" [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU] "AutoInstallMinorUpdates"=dword:00000001 "NoAutoUpdate"=dword:00000000 "AUOptions"=dword:00000004 "ScheduledInstallDay"=dword:00000000 "ScheduledInstallTime"=dword:00000003 "DetectionFrequencyEnabled"=dword:00000001 "DetectionFrequency"=dword:00000003 "NoAutoRebootWithLoggedOnUsers"=dword:00000001 "UseWUServer"=dword:00000001 Startet ein Server mal nicht durch, kommt die Keule in Form von rd /s /q %windir%\softwaredistribution zum Einsatz, dann funktioniert das auch wieder. Zitieren Link zu diesem Kommentar
testperson 1.677 Geschrieben 13. November 2020 Autor Melden Teilen Geschrieben 13. November 2020 Hi, danke für den Auszug aus der Registry. Auf die Schnelle sehe ich, dass ihr aber bei angemeldeten Usern nicht neu startet (https://gpsearch.azurewebsites.net/#2799) oder ist das eine der Richtlinien, wo die Beschreibung nicht stimmt: vor 2 Stunden schrieb Sunny61: "NoAutoRebootWithLoggedOnUsers"=dword:00000001 Allerdings kommt da bei einem der Server die heute nicht gebooted sind bei mir gar nichts von in der Registry an, obwohl die Policy dahinter auf "Deaktiviert" steht. In einem "gpresult" sehe ich grade auch keine der "Neustart Settings", obwohl alles andere aus meiner "WSUS Grundkonfig GPO" ankommt. Danke jedenfalls schonmal für einen Schubs in eine neue Richtung. Allerdings frage ich mich grade, ob ich die letzten Tage einfach nur ins Leere gestarrt habe.. Gruß Jan Zitieren Link zu diesem Kommentar
Sunny61 806 Geschrieben 13. November 2020 Melden Teilen Geschrieben 13. November 2020 Auf den Servern gibt es keine angemeldeten User mehr, nach 2 Stunden Leerlauf wird eine Sitzung getrennt und wieder 2 Stunden später eine getrennte Sitzung beendet. Das trifft auch für die RDP-Server zu, auch die werden nachts aktualisiert. Zitieren Link zu diesem Kommentar
testperson 1.677 Geschrieben 13. November 2020 Autor Melden Teilen Geschrieben 13. November 2020 Okay, sollte tatsächlich jemand zu der Zeit arbeiten, würde vorsichtshalber nicht gebooted. Die üblichen Kandidaten, die zum Feierabend "X-en" oder sich bewusst trennen, werden spätestens nach 4 Stunden entsorgt. In der ersten Umgebung habe ich jetzt jedenfalls bei einem "gpupdate" einen abhanden gekommenen WMI Filter(?) auf einer anderen Policy gefunden, der scheinbar die Verarbeitung gestört hat. Nachdem der Filter weg ist und einenm "gpupdate" habe ich auch die passenden Reboot Settings in der Registry. Ich schaue mir mal die weiteren Server an und könnte mir auch da das WMI Problem vorstellen.. Zitieren Link zu diesem Kommentar
Sunny61 806 Geschrieben 13. November 2020 Melden Teilen Geschrieben 13. November 2020 Viel Erfolg! :) Zitieren Link zu diesem Kommentar
testperson 1.677 Geschrieben 13. November 2020 Autor Melden Teilen Geschrieben 13. November 2020 Auf allen Servern die heute nicht gebootet haben, war nur ein Teil der WSUS GPO in der Registry angekommen. Jetzt die spannende Frage, wer an der Stelle genau was mit dem WMI Filter ausdrücken wollte. Und getestet / geprüft wurde das scheinbar auch nicht.. Da es scheinbar aus der Mode ist Leute mit Bambusstöcken oder Kanthölzern zu erziehen, werde ich es wohl (mal wieder) einfach hinnehmen und nach und nach korrigieren. -_- Danke nochmal für deinen Registry Auszug und Schubs in die richtige Richtung. Da war ich wohl etwas vertieft ins Problem und hab "die Basics" ignoriert ^^ Zitieren Link zu diesem Kommentar
Sunny61 806 Geschrieben 13. November 2020 Melden Teilen Geschrieben 13. November 2020 Bitte, gern geschehen. ;) Was für WMI-Filter war denn gesetzt? Zitieren Link zu diesem Kommentar
testperson 1.677 Geschrieben 13. November 2020 Autor Melden Teilen Geschrieben 13. November 2020 vor 2 Stunden schrieb Sunny61: Was für WMI-Filter war denn gesetzt? Im Auswahl Feld war einfach Leere. Bei der Konfiguration auf "<Kein>" wurde die Auswahl nicht gespeichert und ein Löschen der GPO ging auch nicht. Andere WMI Filter wurden in der Liste auch nicht angezeigt. Mein kleines Fix-It Script: $CurDomain = Get-ADDomain -Current LocalComputer $SOMContainer = [adsi]("LDAP://CN=SOM,CN=WMIPolicy,CN=System," + $CurDomain.DistinguishedName) foreach($WMIContainer in $SOMContainer.Children){ if([adsi]($WMIContainer.Path) | where { $_."msWMI-Name" -eq "PDC Domain Controller" }){ $WMICN = ([adsi]($WMIContainer.Path) | where { $_."msWMI-Name" -eq "PDC Domain Controller" }).CN } } $GPO = Get-GPO -Name "<Das betroffene GPO>" Get-ADObject -Identity $GPO.Path | Set-ADObject -Replace @{gPCWQLFilter=$("[" + $CurDomain.DNSRoot + ";" + $WMICN + ";0]")} Ich habe dann einfach im AD Objekt per PowerShell einen vorhandenen WMI Filter (PDC Domain Controller) ans GPO gepackt und danach erstmal den Link entfernt. Selbst ein angucken des AD Object Property "gPCWQLFilter" am GPO hat mir auf die Schnelle keine Erleuchtung gebracht.. Das GPO selber hatte auch keine Einstellungen, die nicht anderweitig schon in unseren "GPO Sets" enthalten sind. Das Erstell-Datum war auch neuer wie die GPO Sets. 1 Zitieren Link zu diesem Kommentar
Sunny61 806 Geschrieben 13. November 2020 Melden Teilen Geschrieben 13. November 2020 Freut mich für dich und vielen Dank für die Rückmeldung und das Script. :) Zitieren Link zu diesem Kommentar
testperson 1.677 Geschrieben 14. November 2020 Autor Melden Teilen Geschrieben 14. November 2020 Jetzt noch die Finale Rückmeldung zu den Umgebungen im "ersten Ring": Alle Server haben durchgebootet. 2 Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.