16
WSUS Neustartproblem
Hallo,
ich habe immer wieder Probleme mit dem WSUS Server. Genauergesagt bei den PC's, die mitten im Betrieb einen Neustart durchziehen, obwohl das in der GPO verhindert wird.
Es ist eher sporadisch, d.h es tritt nicht auf jedem Rechner und nur manchmal auf. Installationszeit der Updates im Hintergrund ist auf täglich 12h festgesetzt; seltsamerweise werden die Updates schon in der Früh nach dem unmittelbaren hochfahren installiert.
Auch jetzt - nach dem manuellen hinzufügen des IE10 via Windows Update Catalog erbrachte auf 16 Rechnern einen ungeplanten Neustart während des Betriebs.
Was läuft hier falsch?
-> gpresult /R , GPO's werden richtig gezogen.
-> Member ist in der richtigen WSUS Gruppe
Als Einsatz kommt Server 2008 R2 mit WSUS 3.2
Als Rechner kommen Win XP SP3 und Win 7 x64 zum Einsatz.
Die erste GPO wirkt auf die OU mit allen Computerobjekten.
Die zweite auf die obergeordnete OU mit Benutzerobjekten, zur Verhinderung der nervigen Neustarterinnerung.
Anbei zwei Screenshots:
[url=http://abload.de/img/wsusb8ulu.png][img]http://abload.de/thumb/wsusb8ulu.png[/img][/url]
[url=http://abload.de/img/wsus2gtuiw.png][img]http://abload.de/thumb/wsus2gtuiw.png[/img][/url]
MfG 10gbase
ich habe immer wieder Probleme mit dem WSUS Server. Genauergesagt bei den PC's, die mitten im Betrieb einen Neustart durchziehen, obwohl das in der GPO verhindert wird.
Es ist eher sporadisch, d.h es tritt nicht auf jedem Rechner und nur manchmal auf. Installationszeit der Updates im Hintergrund ist auf täglich 12h festgesetzt; seltsamerweise werden die Updates schon in der Früh nach dem unmittelbaren hochfahren installiert.
Auch jetzt - nach dem manuellen hinzufügen des IE10 via Windows Update Catalog erbrachte auf 16 Rechnern einen ungeplanten Neustart während des Betriebs.
Was läuft hier falsch?
-> gpresult /R , GPO's werden richtig gezogen.
-> Member ist in der richtigen WSUS Gruppe
Als Einsatz kommt Server 2008 R2 mit WSUS 3.2
Als Rechner kommen Win XP SP3 und Win 7 x64 zum Einsatz.
Die erste GPO wirkt auf die OU mit allen Computerobjekten.
Die zweite auf die obergeordnete OU mit Benutzerobjekten, zur Verhinderung der nervigen Neustarterinnerung.
Anbei zwei Screenshots:
[url=http://abload.de/img/wsusb8ulu.png][img]http://abload.de/thumb/wsusb8ulu.png[/img][/url]
[url=http://abload.de/img/wsus2gtuiw.png][img]http://abload.de/thumb/wsus2gtuiw.png[/img][/url]
MfG 10gbase
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 205980
Url: https://administrator.de/contentid/205980
Ausgedruckt am: 19.11.2024 um 17:11 Uhr
16 Kommentare
Neuester Kommentar
Moin.
Deine Screenshots nächstes Mal besser als HTML-Seite, die ist wenigstens übersichtlich, auch wenn man nicht vor höchster Auflösung sitzt
Also: wenn der geplante Termin verpasst wird, dann wird sofort beim nächsten Einschalten installiert, das ist normal. So lange Du per Policy setzt, dass bei angemeldeten Nutzern nicht automatisch neugestartet wird, wirst Du keine Probleme haben.
Deine Screenshots nächstes Mal besser als HTML-Seite, die ist wenigstens übersichtlich, auch wenn man nicht vor höchster Auflösung sitzt
Also: wenn der geplante Termin verpasst wird, dann wird sofort beim nächsten Einschalten installiert, das ist normal. So lange Du per Policy setzt, dass bei angemeldeten Nutzern nicht automatisch neugestartet wird, wirst Du keine Probleme haben.
Das seltsame ist eben, dasss die installation an JEDEM Client schon in der Früh passiert (sofern Updates vorhanden sind), auch wenn der vorherige geplante Termin eingehalten wurde.
Die Neustargverhinderung mache ich ja via:
"Keinen automatischen Neustart für geplante Installationen automatischer Updates durchführen, wenn Benutzer angemeldet sind"
Sonst passt ja alles soweit in der Konfig oder?
Die Neustargverhinderung mache ich ja via:
"Keinen automatischen Neustart für geplante Installationen automatischer Updates durchführen, wenn Benutzer angemeldet sind"
Sonst passt ja alles soweit in der Konfig oder?
Ob Deine Einstellungen zu dem passen, was Du willst, kannst nur Du sagen. Prüfe mit rsop.msc am Client, ob diese Einstellungen auch angekommen sind und schau ins Windowsupdate.log (am Client) um zu sehen, warum er neu startet.
Also das rsop.msc ist genial; kannte ich bisher nicht.
In der Windowsupdate.log Datei habe ich desöftren nachgeschaut. Leier werde ich in dem Log nicht schlau.
Kurz vor dem Neustart immer und immer wieder:
Launched new AU client for directive 'Reboot Warning', session id = 0x1
2013-05-02 14:31:26:602 1024 1428 AU Windows Update is disabled by policy for user
2013-05-02 14:31:26:618 1024 fa0 AU AU received handle event
Dann:
Forced install timer expired for deadline install
UpdateDownloadProperties: 0 download(s) are still in progress.
Enforcing reboot for already installed deadline expired update
Found a pending reboot, launching reboot UI
Setting AU scheduled install time to 2013-05-03 10:00:00
Successfully wrote event for AU health state:0
CWERReporter finishing event handling. (00000000)
Danach erneut:
Launched new AU client for directive 'Reboot Warning', session id = 0x1
2013-05-02 14:31:26:602 1024 1428 AU Windows Update is disabled by policy for user
2013-05-02 14:31:26:618 1024 fa0 AU AU received handle event
und schließlich:
Windows Update is disabled by policy for user
AU received handle event
AU invoking RebootSystem (OnRebootNow)
WARNING: SUS Client is rebooting system.
invoking RebootSystem (OnRebootRetry)
Launched new AU client for directive 'Reboot Warning', session id = 0x1
received handle event
Shutdwn user declined update at shutdown
Successfully wrote event for AU health state:0
AU initiates service shutdown
AU: Uninitializing Automatic Updates ###########
CWERReporter finishing event handling. (00000000)
END Service: Service exit [Exit code = 0x240001]
=> NEUSTART***
Ich weiß, dass die geplante Uhrzeit früher mal auf 10 Uhr eingestellt war, später diese auf 12 erhöht. Im Log setzt er die nächste Zeit wieder auf 10. Kommt die GPO dann einfach nicht richtig an? Wobei ich schon in mehreren Logs geschaut habe, das sieht dann auch so aus, nur mit der richtigen Uhrzeit versehen.
In der Windowsupdate.log Datei habe ich desöftren nachgeschaut. Leier werde ich in dem Log nicht schlau.
Kurz vor dem Neustart immer und immer wieder:
Launched new AU client for directive 'Reboot Warning', session id = 0x1
2013-05-02 14:31:26:602 1024 1428 AU Windows Update is disabled by policy for user
2013-05-02 14:31:26:618 1024 fa0 AU AU received handle event
Dann:
Forced install timer expired for deadline install
UpdateDownloadProperties: 0 download(s) are still in progress.
Enforcing reboot for already installed deadline expired update
Found a pending reboot, launching reboot UI
Setting AU scheduled install time to 2013-05-03 10:00:00
Successfully wrote event for AU health state:0
CWERReporter finishing event handling. (00000000)
Danach erneut:
Launched new AU client for directive 'Reboot Warning', session id = 0x1
2013-05-02 14:31:26:602 1024 1428 AU Windows Update is disabled by policy for user
2013-05-02 14:31:26:618 1024 fa0 AU AU received handle event
und schließlich:
Windows Update is disabled by policy for user
AU received handle event
AU invoking RebootSystem (OnRebootNow)
WARNING: SUS Client is rebooting system.
invoking RebootSystem (OnRebootRetry)
Launched new AU client for directive 'Reboot Warning', session id = 0x1
received handle event
Shutdwn user declined update at shutdown
Successfully wrote event for AU health state:0
AU initiates service shutdown
AU: Uninitializing Automatic Updates ###########
CWERReporter finishing event handling. (00000000)
END Service: Service exit [Exit code = 0x240001]
=> NEUSTART***
Ich weiß, dass die geplante Uhrzeit früher mal auf 10 Uhr eingestellt war, später diese auf 12 erhöht. Im Log setzt er die nächste Zeit wieder auf 10. Kommt die GPO dann einfach nicht richtig an? Wobei ich schon in mehreren Logs geschaut habe, das sieht dann auch so aus, nur mit der richtigen Uhrzeit versehen.
Schau mal was in der Default-Domain Policy eingetragen ist. Wenn da schon jemand etwas geändert hat kannst Du GPOs schreiben bis Du umfällst und nichts wird passieren weil die DDPO alle anderen aushebelt.
Ich hab gerade mal bei uns nachgeschaut und die einzigen beiden Eintragungen die wir haben sind in Richtlinie für allgemeine Einstellungen für Aktualisierungsdienste und Clientcomputerrichtlinie für Aktualisierungsdienste.
Ich hab gerade mal bei uns nachgeschaut und die einzigen beiden Eintragungen die wir haben sind in Richtlinie für allgemeine Einstellungen für Aktualisierungsdienste und Clientcomputerrichtlinie für Aktualisierungsdienste.
In der Def. GPO sind schon Eintragungen vorhanden, aber keine, die den Windows Update Bereich aushebeln würden.
Du findest für die Clients in 3 Bereichen Einstellungsmöglichkeiten für den WSUS:
- Windows-Komponenten/Windows Update
- Clientcomputerrichtlinie für Aktualisierungsdienste
- Default Domain Policy
Server dann noch zusätzlich:
- Default Domain Controllers Policy
- Windows Servercomputerrichtlinie für Aktualisierungsdienste
Du kannst jedenfalls an mehreren Orten Einstellungen zum Verhalten bei Installation und Neustart definieren. Schau mal nach ob da irgendwo Unterschiede sind.
Ich hoffe mal das Du nach den Einstellungen auch auf dem DC ein /gpupdate /force durchgeführt hast oder einen Reboot.
- Windows-Komponenten/Windows Update
- Clientcomputerrichtlinie für Aktualisierungsdienste
- Default Domain Policy
Server dann noch zusätzlich:
- Default Domain Controllers Policy
- Windows Servercomputerrichtlinie für Aktualisierungsdienste
Du kannst jedenfalls an mehreren Orten Einstellungen zum Verhalten bei Installation und Neustart definieren. Schau mal nach ob da irgendwo Unterschiede sind.
Ich hoffe mal das Du nach den Einstellungen auch auf dem DC ein /gpupdate /force durchgeführt hast oder einen Reboot.
Was ich noch nicht so ganz verstehe und wo ich finde ist:
Clientcomputerrichtlinie für Aktualisierungsdienste
Windows Servercomputerrichtlinie für Aktualisierungsdienste
Im WSUS gschieht die autom. Zuteilung via GPO, keine manuelle.
In der Default Domain Policy ändere ich nichts.
Auf allen drei DC's wird auch richtig und vollständig repliziert, gerade geprüft.
Clientcomputerrichtlinie für Aktualisierungsdienste
Windows Servercomputerrichtlinie für Aktualisierungsdienste
Im WSUS gschieht die autom. Zuteilung via GPO, keine manuelle.
In der Default Domain Policy ändere ich nichts.
Auf allen drei DC's wird auch richtig und vollständig repliziert, gerade geprüft.
Wozu das Gehühner mit den Policies? Was Du am Client mit rsop.msc entnimmst, gilt. Dort steht auch haarklein, welche Policy das gesetzt hat. Und wenn dort gesetzt ist, dass bei angemeldeten Nutzern nicht neu gestartet wird, dann geschieht das auch nicht. Prüf das.
Ok, dann führ ich das das nächste mal aus und check was so an Richtlinien gezogen werden.
Ich kann nächste Woche mal an einem PC nachschauen.
Vielen Dank schonmal.
Ich kann nächste Woche mal an einem PC nachschauen.
Vielen Dank schonmal.
Wenn du auf dem WSUS die Updates mit dem "Stichtag" versehen hast, ist der Neustart normal.
Also die Stichtag aller Updates werden immer durch meine definierten automatische Genehmigungsregeln gesetzt.
Seltsam ist es eben, weil die Neustartprobleme eher einzeln auftreten und sporadisch.
Seltsam ist es eben, weil die Neustartprobleme eher einzeln auftreten und sporadisch.
Das mit dem Stichtag ist etwas tricky.
jetzt weiß ich auch, wieso er die Updates manchmal sofort anstatt der geplanten Uhrzeit installiert.
Was macht man am besten, wenn man neue Rechner im netz hinzufügt, der Stichtag mehrerer Updates schon lange vorüber ist?
Habe drei Genehmigungsgruppen.
Die eine Gruppe erhält sie sofort, die 2te nach 5 tagen und die dritte nach 10 Tagen.
hatte jetzt den IE10 manuell genehmigt und keinen Stichtag festgelegt. Dennoch starteten die Rechner neu.
Sollte ich die Stichtage möglichst hoch ansetzen? z.B nach Eingang neuer Updates nach 365 Tagen genehmigen? Bin jetzt etwas verwirrt
jetzt weiß ich auch, wieso er die Updates manchmal sofort anstatt der geplanten Uhrzeit installiert.
Was macht man am besten, wenn man neue Rechner im netz hinzufügt, der Stichtag mehrerer Updates schon lange vorüber ist?
Habe drei Genehmigungsgruppen.
Die eine Gruppe erhält sie sofort, die 2te nach 5 tagen und die dritte nach 10 Tagen.
hatte jetzt den IE10 manuell genehmigt und keinen Stichtag festgelegt. Dennoch starteten die Rechner neu.
Sollte ich die Stichtage möglichst hoch ansetzen? z.B nach Eingang neuer Updates nach 365 Tagen genehmigen? Bin jetzt etwas verwirrt
Zitat von @10gbase:
Also die Stichtag aller Updates werden immer durch meine definierten automatische Genehmigungsregeln gesetzt.
Also die Stichtag aller Updates werden immer durch meine definierten automatische Genehmigungsregeln gesetzt.
Ich persönlich halte weder von automatischen Genehmigungsregeln noch von der Stichtagsregel etwas.
Ich genehmige generell nur die Updates, die die Clients anfordern, alles andere bleibt auf "nicht genehmigt" stehen.
Zitat von @10gbase:
Seltsam ist es eben, weil die Neustartprobleme eher einzeln auftreten und sporadisch.
Seltsam ist es eben, weil die Neustartprobleme eher einzeln auftreten und sporadisch.
Könnte durchaus auch mit dem Stichtag zusammenhängen, kann ich aber nicht "nachbauen".
Zitat von @10gbase:
Was macht man am besten, wenn man neue Rechner im netz hinzufügt, der Stichtag mehrerer Updates schon lange vorüber
ist?
Was macht man am besten, wenn man neue Rechner im netz hinzufügt, der Stichtag mehrerer Updates schon lange vorüber
ist?
Wenn neue Clients aufgesetzt werden, bleiben diese so lange bei "mir", bis diese dem WSUS melden, dass sie vollständig gepatcht sind. Gibt es sicher mehrere Möglichkeiten, abhängig davon, welche Voraussetzungen vor Ort vorhanden sind (AD, eigenes Netzsegment, eigene Gruppen, Testumgebung etc.).
Ich persönlich halte weder von automatischen Genehmigungsregeln noch von der Stichtagsregel etwas.
Ich genehmige generell nur die Updates, die die Clients anfordern, alles andere bleibt auf "nicht genehmigt" stehen.
Das macht doch dann wenig Sinn gleich ALLE Updates auf alle Clients zu verteilen. Falls es mal ein Problem gibt sind alle betroffen (s. SP1 unter Win 7 via WSUS-Verteilung)
Hast du es wohl bei der Standardgenehmigungsregel belassen?
Ich genehmige generell nur die Updates, die die Clients anfordern, alles andere bleibt auf "nicht genehmigt" stehen.
Das macht doch dann wenig Sinn gleich ALLE Updates auf alle Clients zu verteilen. Falls es mal ein Problem gibt sind alle betroffen (s. SP1 unter Win 7 via WSUS-Verteilung)
Hast du es wohl bei der Standardgenehmigungsregel belassen?
Zitat von @10gbase:
Das macht doch dann wenig Sinn gleich ALLE Updates auf alle Clients zu verteilen. Falls es mal ein Problem gibt sind alle
betroffen (s. SP1 unter Win 7 via WSUS-Verteilung)
Hast du es wohl bei der Standardgenehmigungsregel belassen?
Das macht doch dann wenig Sinn gleich ALLE Updates auf alle Clients zu verteilen. Falls es mal ein Problem gibt sind alle
betroffen (s. SP1 unter Win 7 via WSUS-Verteilung)
Hast du es wohl bei der Standardgenehmigungsregel belassen?
Nein, Standardgenehmigungen nur für WSUS-Updates. Ich arbeite mit verschiedenen Gruppen auf dem WSUS, eine davon sind die Testclients/ Server. Diese bekommen die Updates nach Anforderung manuell genehmigt. Sollte es keine Probleme geben, werden für die anderen Gruppen (getrennt nach Servern und Clients) die Updates genehmigt. Neu installierte Clients "wandern" z.B. auch erstmal in die Gruppe der Testclients. Nach Abschluß des Patchens werden sie dann in die entsprechenden Produktivgruppen verschoben.
