Windows Server 2016 und WSUS - Updates installieren unplanmässig

[bigthe 5]

Hallo Zusammen,

 

ich habe mal eine Frage zu folgendem Sachverhalt.

 

Mittels WSUS 2019 und mehreren GPOs lasse ich zu unterschiedlichen Tagen und Uhrzeiten, automatisch Updates installieren.

Es sind unterschiedliche OS Varianten von Windows Server 2016-2022 im Einsatz. Bei den 19 und 22 Varianten klappt alles reibungslos wie konfiguriert.

 

Bei den 2016er die installieren jeden Montag obwohl konfiguriert ist jeden 4. Montag. Interessant ist auch das nicht alle 2016er Server automatisch neu starten, nachdem sie das Update erhalten haben.

 

Ich habe hier mal ein Beispiel hinzugefügt.  Man sieht das die GPO richtig beim Server ankommt. Dennoch wurde am 15.07 auf den 2016er Server das Update am 15.07 installiert obwohl die erst hätte am 22.07. passieren sollen.

 

Kennt jemand das Problem? Was wäre hierfür die Lösung?

 

LG

 

  

[Nobbyaushb 1.440]

2016 war schon immer Grütze - löse die durch 2022 ab

Hört sich vielleicht d**f an, ist aber meine Empfehlung

[bigthe 5]

vor 10 Minuten schrieb Nobbyaushb:

2016 war schon immer Grütze - löse die durch 2022 ab

Hört sich vielleicht d**f an, ist aber meine Empfehlung

 

hahahah, ja da hast du wohl recht, heute schaffe ich das nicht mehr ca. 45 Server abzulösen.

 

Hast du noch eine andere Idee dazu?

 

LG 

[Nobbyaushb 1.440]

vor 16 Minuten schrieb bigthe:

hahahah, ja da hast du wohl recht, heute schaffe ich das nicht mehr ca. 45 Server abzulösen.

Wenigstens mit Humor genommen - naja, 45 Stück macht man ja nicht mal eben...

 

vor 16 Minuten schrieb bigthe:

Hast du noch eine andere Idee dazu?

Leider nicht wirklich - Logs prüfen

Ich weiß, ist mühsam, vielleicht noch Evgenij @cj_berlin oder Sunny @Sunny61 eine Idee

[bigthe 5]

Die Windows 2016er haben die Option mit den unterschiedlichen Wochen nicht und somit  wird dann jeden Montag die Updates installiert?

Diese Option kam erst mit 2019.

Aber das ist nur eine Vermutung eigentlich haben wir ja das aktuelle Policy Set auf dem Domänencontroller.

 

Updates wurden planmässig zu der konfigurierten Uhrzeit installiert nur eben zum falschen Montag. 

 

vor 9 Minuten schrieb Nobbyaushb:

Wenigstens mit Humor genommen - naja, 45 Stück macht man ja nicht mal eben...

 

Leider nicht wirklich - Logs prüfen

Ich weiß, ist mühsam, vielleicht noch Evgenij @cj_berlin oder Sunny @Sunny61 eine Idee

 

Wie stehts du zu inplace Upgrade? Das wollte ich sowieso mal Fragen. Grundsätzlich rät ja jeder davon ab aber warum gibt es dann diese Option?

[NorbertFe 1.968]

vor einer Stunde schrieb bigthe:

Grundsätzlich rät ja jeder davon ab aber warum gibt es dann diese Option?

Weil sich nicht jeder grundsätzlich dran halten will. Insgesamt bin ich auch nicht grundsätzlich gegen inplace upgrades, solange man sich bewusst ist, was das Ergebnis ist bzw. Man einen fallback braucht.

[Nobbyaushb 1.440]

vor 1 Stunde schrieb bigthe:

Wie stehts du zu inplace Upgrade? Das wollte ich sowieso mal Fragen. Grundsätzlich rät ja jeder davon ab aber warum gibt es dann diese Option?

Habe diverse solcher Systeme durch inplace angehoben

Bei einigen lief es dann doch auf einen neuen Server hinaus, aber 8 von 10 waren in Ordnung

Wenn das alles VM´s sind kann man ja quasi zack zurück

Oder die betreffenden Server nach und nach in der Testumgebung hochziehen, dann lerns man die Fallstricke

 

M2Cents

[Sunny61 804]

vor 16 Stunden schrieb bigthe:

Updates wurden planmässig zu der konfigurierten Uhrzeit installiert nur eben zum falschen Montag.

Schau dir meine Lösung an:

 

Ein VB-Script das von einer Batch zu einem geplanten Zeitpunkt aufgerufen werden kann. Natürlich müssen die Updates zu diesem Zeitpunkt auch für die Gruppe der Server freigegeben sein, aber grundsätzlich funktioniert das ganz wunderbar.

Hier noch der Inhalt der Batch:

 

REM Softwaredistribution leeren, zuerst Dienst WUAUSERV beenden, SoftwareDistribution leeren, Dienst wieder starten

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -Command Stop-Service "WUAUSERV" -Force 
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -Command while ((Get-Service "WUAUSERV").Status -ne 'Stopped'){Sleep 1}

timeout /T 5 /nobreak
rd /s /q %windir%\softwaredistribution
timeout /T 5 /nobreak
net start wuauserv
timeout /T 5 /nobreak

REM Updates am WSUS antriggern
wuauclt /resetauthorization /detectnow

REM Sicherheitshalber 5 Sekunden warten
timeout /T 5 /nobreak

REM Updates am WSUS antriggern
wuauclt /reportnow

REM Sicherheitshalber 5 Sekunden warten
timeout /T 5 /nobreak


REM Das eigentliche Script starten
c:\windows\system32\cscript.exe /nologo C:\_Install\WU\WUA_SearchDownloadInstall.vbs<c:\_Install\WU\input.txt

Die Batch über einen geplanten Task aufrufen, am besten mit SYSTEM-Rechten, dann funktioniert das genau zum gewünschten Zeitpunkt. Wichtig ist z.B. das /resetauthorization /detectnow, damit wird der WSUS angetriggert und der Client erneuert/refresht seine Gruppenmitgliedschaft. Natürlich könnte man auch in der SQL DB vom WSUS den Server in die richtige Gruppe verschieben und danach erst das Sript laufen lassen. Anschließend wieder retour.

[cj_berlin 1.281]

Genau so habe ich es auch immer gelöst, nur halt rein mit PowerShell. Oder es gab SCCM, und dann konnte man es darüber steuern.

[bigthe 5]

vor 16 Minuten schrieb Sunny61:

Schau dir meine Lösung an:

Hallo Sunny,

 

danke für diese Lösung!

 

Ich muss kurz etwas ausholen...

Ich bin neu in diesem Unternehmen. Vorher wurde jeden Monat manuell gepacht von den Kollegen. Dann habe ich vor mehr als 2 Monaten das ganze wie beschrieben automatisiert.

Letzten Monat lief das perfekt durch ohne Probleme, klar hat man immer wieder unter den 2016er Einzelfälle.

 

Die Server zu WSUS Console neu hinzugefügt hatte ich schon mehrfach auf diese Art:

1. Stop-Service -Name BITS, wuauserv -Force # Wenn Dienst nicht stoppen will takskill ausführen

2. Remove-ItemProperty -Name AccountDomainSid, PingID, SusClientId, SusClientIDValidation -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\ -ErrorAction SilentlyContinue

3. Remove-Item "$env:SystemRoot\SoftwareDistribution\" -Recurse -Force -ErrorAction SilentlyContinue

4. Start-Service -Name BITS, wuauserv

5. wuauclt /resetauthorization /detectnow

6. (New-Object -ComObject Microsoft.Update.AutoUpdate).DetectNow()

 

Heute habe ich nochmals mir Zeit genommen und bin alle 2016 Server durchgegangen. Es ist etwas merkwürdig. Ca. 80% haben das Update erhalten am Montag aber keine Neustart (einige davon auch zu einer unplanmässigen Zeit). 10% Haben Updates erhalten und einen Neustart (interessant ist dabei auch das unser Monitoring nicht angeschlagen hat!). 10% haben weder Update noch einen Neustart durchgeführt.

 

In der WSUS Console werden mir die 2016er zu 90% fehlerhaft angezeigt. Also im WSUS wird angegeben das diese Server kein Update benötigen, auf dem Server wird aber ein Update benötigt.

 

Ich habe schon einige WSUSs gemacht aber sowas noch nicht erlebt. Ist das Sabotage? Das Verhalten des Systems kommt mir unwillkürlich vor.

 

LG

Robin 

 

vor 29 Minuten schrieb cj_berlin:

Genau so habe ich es auch immer gelöst, nur halt rein mit PowerShell

Hallo,

 

könntest du mir bitte diese PS Skript zur Verfügung stellen? Mit VBS kenne ich mich überhaupt nicht aus. 

 

LG

bearbeitet 18. Juli von bigthe

[Sunny61 804]

vor 42 Minuten schrieb bigthe:

Die Server zu WSUS Console neu hinzugefügt hatte ich schon mehrfach auf diese Art:

Weshalb muss man das so oft machen? Das läuft doch mittels GPO ganz von allein, maximal einmal manuell in die passende Gruppe aufnehmen, fertig.

 

vor 42 Minuten schrieb bigthe:

Heute habe ich nochmals mir Zeit genommen und bin alle 2016 Server durchgegangen. Es ist etwas merkwürdig. Ca. 80% haben das Update erhalten am Montag aber keine Neustart (einige davon auch zu einer unplanmässigen Zeit). 10% Haben Updates erhalten und einen Neustart (interessant ist dabei auch das unser Monitoring nicht angeschlagen hat!). 10% haben weder Update noch einen Neustart durchgeführt.

Sehr dubios, wir haben zur Zeit ~160 W2016 im Einsatz, ein paar W2022. Aber nie hatte ich solche Probleme mit der Installation von Updates. Evtl. liegts ja am GPO, zeig doch mal die Einstellungen komplett, Namen/Bezeichnungen kannst Du ja anonymisieren. Das einzige was manchmal vorkommt ist, dass ein Server keinen Reboot ausführen, obwohl es im GPO so konfiguriert ist. Manchmal weil noch jemand angemeldet ist (das ist dann auch korrekt), manchmal weiß man das nicht. Das betrifft allerdings nur 5-10 Server pro Patchday maximal. Einen Unterschied zwischen 2016 und 2022 kann ich an der Stelle nicht festellen.

 

EDIT: Welche Updates werden denn als fehlerhaft auf dem WSUS angeziegt? .Net CUs oder Windows CUs?

 

vor 42 Minuten schrieb bigthe:

Ich habe schon einige WSUSs gemacht aber sowas noch nicht erlebt. Ist das Sabotage? Das Verhalten des Systems kommt mir unwillkürlich vor.

Der WSUS kann überhaupt nichts dafür, das liegt NUR an den Servern/Clients.

 

BTW: Das von mir zitierte VB-Script liegt ist bei jeder Windows Server Installation dabei, die kann man sich an der Stelle ausleihen und ein klein wenig anpassen. ;)

bearbeitet 18. Juli von Sunny61

[bigthe 5]

vor 6 Minuten schrieb Sunny61:

Weshalb muss man das so oft machen? Das läuft doch mittels GPO ganz von allein, maximal manuell in die passende Gruppe aufnehmen, fertig.

Hallo Sunny,

 

ich weiss es auch nicht. es gibt 2 2016er Server die ich egal wie nicht in die Console bekomme. Der Vorgesetzte meinte auch mal das etwas an den 2016er Template sein könnte, ist sich aber nicht sicher.

 

vor 8 Minuten schrieb Sunny61:

Sehr dubios

 

Absolut. Ich kann diese Verhalten auch nicht nachvollziehen, zumal es den Monat davor absolut Fehlerfrei lief.

 

vor 9 Minuten schrieb Sunny61:

Der WSUS kann überhaupt nichts dafür, das liegt NUR an den Servern/Clients.

 

Ok verstehe. Da muss ich dort ansetzen.

 

vor 10 Minuten schrieb Sunny61:

GPO, zeig doch mal die Einstellungen komplett

 

[Sunny61 804]

 

vor 4 Stunden schrieb bigthe:

ich weiss es auch nicht. es gibt 2 2016er Server die ich egal wie nicht in die Console bekomme. Der Vorgesetzte meinte auch mal das etwas an den 2016er Template sein könnte, ist sich aber nicht sicher.

Hmm, es könnte natürlich sein, dass das Template nicht mit SYSPREP bearbeitet wurde, dann hast Du u.U. eine SUSClientID drin, die es schon öfter gibt. Der Server kommt dann nicht als neuer Client in die Konsole, sondern ist schon mit einem anderen Namen da und aktualisiert nur den Statusbericht. Falls das so ist, sieht man das in der Konsole nur an der Uhrzeit an der sich der Server zuletzt gemeldet bzw. einen Bericht abgeliefert hat.

 

Als Alternative kannst Du die SUSClientID (aus dem Template) auch in der SQL Serverdatenbank des WSUS suchen. In der Tabelle tbComputerTarget im Feld ComputerID findest Du sie, merk dir die dazugehörige TargetID. Dort dann den Datensatz löschen und auf der Maschine diesen Zweig in der Registry löschen: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate Wirklich den TEil komplett löschen, nicht nur Teile. In der Tabelle tbComputerTargetDetail  suchst Du dann die TargetID und löscht auch diesen Datensatz. Zusätzlich auch noch in der Registry überprüfen ob auch wirklich alles richtig drin steht, nicht dass es noch irgendeine alte GPO irgendwo gibt mit einem falschen Servernamen. Starte auch GPEDIT.MSC und überprüfe den Teil in Windows Update manuell. Hatte ich auch schon dass hier ein Server drin stand, den es nicht mehr gab.  HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate %windir%\softwaredistribution noch löschen und den Server neu starten.

 

Nach dem Neustart in einer Admin Commandline nur wuauclt /resetauthorization /detectnow mehrmals laufen lassen und zum Schluß noch ein wuauclt /reportnow. Wenn die Gruppe Phase1 existiert, dann sollte der Server nach 5-10 Minuten in der Gruppe auftauchen.

 

BTW: Wenn die SUSDB auf dem WSUS in der Windows Internal Database installiert ist, kommst Du mit Hilfe eines SQL Server Management Studios recht einfach rein. SSMS undbedingt als Admin starten und diesen Verbindungsstring verwenden:

\\.\pipe\Microsoft##WID\tsql\query

Windows-Authentifizierung verwenden.

 

Download vom SSMS: https://learn.microsoft.com/de-de/sql/ssms/download-sql-server-management-studio-ssms?view=sql-server-ver15#available-languages

 

EDIT: Das hier solltest Du auch noch auf Disabled setzen: https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policies.WindowsUpdate::DisableDualScan&Language=de-de

bearbeitet 18. Juli von Sunny61

[bigthe 5]

vor einer Stunde schrieb Sunny61:

Hmm, es könnte natürlich sein, dass das Template nicht mit SYSPREP bearbeitet wurde

Das hatte ich ebenfalls vermutet. Auf meine Nachfrage bei Kollegen und Vorgesetzten gab es dazu nur Schulterzucken bzw. die Aussage das das in einer Domänenumgebung sowas nicht möglich wäre weil es dann noch diverse andere Probleme geben würde.

Mit meinem Skript oben hatte ich das auf eigentlich jedem 2016er ausgeführt.

 

Das Template wird nicht weiter verwendet aktuell haben wir ein 2022er Template im Einsatz.

 

vor einer Stunde schrieb Sunny61:

Als Alternative kannst Du die SUSClientID (aus dem Template) auch in der SQL Serverdatenbank des WSUS suchen

Das ist ein richtig guter Tipp! Das werde ich direkt mal versuchen. Danke.

 

 

vor 1 Stunde schrieb Sunny61:

EDIT: Das hier solltest Du auch noch auf Disabled setzen

Wenn du das empfiehlst werde ich das natürlich sofort umsetzen :). Solche Tipps sind Gold wert für mich.

 

Dennoch verstehe ich nicht wie manche 2016er Server automatisch ein Update installiert haben. Auch verstehe ich nicht wie es sein kann das nur teilweise das passiert ist und nicht bei allen in der Phase 1 zb. Oder das nur manche Server den reboot gefahren haben und das dies nicht im Monitoring aufgetaucht ist. Das ist irgendwie merkwürdig.

 

[Sunny61 804]

vor 34 Minuten schrieb bigthe:

Das hatte ich ebenfalls vermutet. Auf meine Nachfrage bei Kollegen und Vorgesetzten gab es dazu nur Schulterzucken bzw. die Aussage das das in einer Domänenumgebung sowas nicht möglich wäre weil es dann noch diverse andere Probleme geben würde.

Doch, SYSPREP ist in der Domäne möglich.

vor 34 Minuten schrieb bigthe:

Mit meinem Skript oben hatte ich das auf eigentlich jedem 2016er ausgeführt.

Fast sehr gut gewesen, nur lösche ich bei sowas den kompletten Registry Zweig, das wird sowieso alles neu erstellt, also weg damit.

 

vor 34 Minuten schrieb bigthe:

Dennoch verstehe ich nicht wie manche 2016er Server automatisch ein Update installiert haben. Auch verstehe ich nicht wie es sein kann das nur teilweise das passiert ist und nicht bei allen in der Phase 1 zb. Oder das nur manche Server den reboot gefahren haben und das dies nicht im Monitoring aufgetaucht ist. Das ist irgendwie merkwürdig.

Glaub ich dir, ich kontrolliere das in der WSUS-Konsole, da sieht man sofort wer noch einen Reboot möchte und wer in Ordnung ist. ;)

 

Schau auch über GPEDIT.MSC in den lokalen Richtlinien nach, manchmal findet man was. ;)

 

EDIT: Alternativ kann man sich auch mit Ansible beschäftigen. ;)

bearbeitet 18. Juli von Sunny61