Jump to content

Windows Update Client und kein Reboot


Direkt zur Lösung Gelöst von Sunny61,
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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

Link zu diesem Kommentar
  • Beste Lösung

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.

 

Link zu diesem Kommentar

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

Link zu diesem Kommentar

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..

Link zu diesem Kommentar

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 ^^

Link zu diesem Kommentar
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.

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...