10gbase
Goto Top

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

Content-Key: 205980

Url: https://administrator.de/contentid/205980

Printed on: April 25, 2024 at 08:04 o'clock

Member: DerWoWusste
DerWoWusste May 03, 2013 at 07:58:54 (UTC)
Goto Top
Moin.

Deine Screenshots nächstes Mal besser als HTML-Seite, die ist wenigstens übersichtlich, auch wenn man nicht vor höchster Auflösung sitzt face-smile

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.
Member: 10gbase
10gbase May 03, 2013 at 08:10:27 (UTC)
Goto Top
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?
Member: DerWoWusste
DerWoWusste May 03, 2013 at 08:21:34 (UTC)
Goto Top
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.
Member: 10gbase
10gbase May 03, 2013 updated at 09:15:37 (UTC)
Goto Top
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.
Member: DerMarco
DerMarco May 03, 2013 at 09:15:21 (UTC)
Goto Top
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.
Member: 10gbase
10gbase May 03, 2013 at 09:20:15 (UTC)
Goto Top
In der Def. GPO sind schon Eintragungen vorhanden, aber keine, die den Windows Update Bereich aushebeln würden.
Member: DerMarco
DerMarco May 03, 2013 updated at 09:32:18 (UTC)
Goto Top
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.
Member: 10gbase
10gbase May 03, 2013 at 10:30:46 (UTC)
Goto Top
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.
Member: DerWoWusste
DerWoWusste May 03, 2013 at 10:42:41 (UTC)
Goto Top
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.
Member: 10gbase
10gbase May 03, 2013 updated at 11:28:33 (UTC)
Goto Top
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.
Member: Edelweis
Edelweis May 03, 2013 at 12:12:16 (UTC)
Goto Top
Zitat von @10gbase:
Dann:
Forced install timer expired for deadline install

Wenn du auf dem WSUS die Updates mit dem "Stichtag" versehen hast, ist der Neustart normal.
Member: 10gbase
10gbase May 06, 2013 at 07:03:57 (UTC)
Goto Top
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.
Member: 10gbase
10gbase May 06, 2013 updated at 14:15:20 (UTC)
Goto Top
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
Member: Edelweis
Edelweis May 06, 2013 at 15:36:13 (UTC)
Goto Top
Zitat von @10gbase:
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.

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?

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.).
Member: 10gbase
10gbase May 07, 2013 at 12:01:55 (UTC)
Goto Top
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?
Member: Edelweis
Edelweis May 07, 2013 updated at 19:52:38 (UTC)
Goto Top
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?

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.