Neuer WSUS Server 2019 - Synchronisierung läuft nicht durch

phatair · 14. November 2023

Hallo zusammen,

ich setze gerade einen neuen WSUS auf einem Server 2019 auf.

"Interne WSUS SQL DB", kein eigener SQL
4 CPUs
6GB RAM
Upstream Server ist Microsoft (https://sws.update.microsoft.com;)
Internet Zugriff für den Server ist auf die Kategorie "Microsoft Windows Updates" eingeschränkt.
- Dies müsste auch passen, da unser alter WSUS auf Server 2012R2 über die gleiche Firewall Regel in das Internet kommt und dort funktioniert der Sync problemlos

Ich habe die Rolle für den WSUS über den Server Manager hinzugefügt und anschließend noch die "Post-Install Tasks" gestartet.

Danach habe ich den Config Wizard durchgeführt.

Nun habe ich das Problem, dass die Synchronisierung nicht läuft. Sie startet und geht relativ schnell auf 10%, dann dauert es Ewigkeiten (mehrere Stunden) bis er Prozent für Prozent weitergeht. Bei 65% war dann immer Schluss (habe über Nacht gewartet).

Die RAM Nutzung vom WSUS Dienst steigt in der Zeit stetig auf über 5GB und der WSUS Dienst zieht so um die 20-30% CPU.

Hat jemand noch eine Idee woran das liegen könnte? Gibt es ein Log in dem ich prüfen kann was bei dem Sync Vorgang passiert oder habe ich irgendwas wichtiges vergessen?

An sich ist so ein WSUS ja jetzt kein Hexenwerk :(

Vielen Dank.

EDIT: Ich habe das Log gefunden - >"C:\Program Files\Update Services\LogFiles\SoftwareDistribution.log"

Hier sehe ich immer wieder folgende Meldung

2023-11-14 08:30:45.066 UTC	Warning	WsusService.3	DBConnection.ExecuteCommandNoResult	SqlException occurred. Number 515 and message Der Wert NULL kann in die RevisionID-Spalte, @BundleAll-Tabelle nicht eingefügt werden. Die Spalte lässt NULL-Werte nicht zu. Fehler bei INSERT.
Error loading information from upd:BundledUpdates/upd:UpdateIdentity for update 69081ABB-2FD4-49A6-8DA1-2F616F1A9B58\201. Some update revisions in bundle information are not already present in the database.
Die Anweisung wurde beendet.
2023-11-14 08:30:48.379 UTC	Info	w3wp.41	ThreadEntry	TimerQueue.FireNextTimers
2023-11-14 08:30:48.379 UTC	Info	w3wp.41	ServerImplementation.UpdateCache	Database change occured; check if we need to update cache.
2023-11-14 08:30:48.379 UTC	Info	w3wp.41	RevisionIdCache.UpdateCategoryAndRevisionIdCache	Fetching the category and revision id change for cache from database
2023-11-14 08:31:16.582 UTC	Change	WsusService.3	DBConnection.OnReceivingInfoMessage	Successfully deployed deployment(Decline) of Windows10.0-KB5010351-arm64.cab UpdateID:6A880902-4DC2-4C69-8977-2904205BFCE9 Revision Number:201 
2023-11-14 08:31:16.598 UTC	Info	w3wp.41	RevisionIdCache.UpdateCategoryCache	Refreshing the category cache
2023-11-14 08:31:16.598 UTC	Info	w3wp.41	RevisionIdCache.UpdateRevisionCache	Refreshing the revision cache
2023-11-14 08:31:16.645 UTC	Warning	WsusService.3	DBConnection.ExecuteCommandNoResult	SqlException occurred. Number 515 and message Der Wert NULL kann in die RevisionID-Spalte, @BundleAll-Tabelle nicht eingefügt werden. Die Spalte lässt NULL-Werte nicht zu. Fehler bei INSERT.
Error loading information from upd:BundledUpdates/upd:UpdateIdentity for update 59152F2C-DBC8-4AE8-B878-8F600A953869\201. Some update revisions in bundle information are not already present in the database.
Die Anweisung wurde beendet.

Da ich nach der langen Wartezeit den Server neu gestartet hatte, scheinen jetzt wohl schon Einträge vorhanden zu sein. Das erklärt zwar nicht, warum von Anfang an der Sync so lange gedauert hat, aber es würde erklären warum es jetzt länger dauert.

bearbeitet 14. November 2023 von phatair

zahni · 14. November 2023

Proxy-Freischaltung habe ich nicht im Kopf. Das findest Du aber in den Logs.

6GB ist zu wenig, besonders wenn Du keinen Remote-SQL benutzt.

Schaue dir mal die Links an:

https://learn.microsoft.com/en-us/troubleshoot/mem/configmgr/update-management/windows-server-update-services-best-practices#disable-recycling-and-configure-memory-limits

https://learn.microsoft.com/en-us/troubleshoot/mem/configmgr/update-management/wsus-maintenance-guide

Bei einem richten SQL-Server oder SQL-Express kannst Du das hier machen:

https://social.technet.microsoft.com/Forums/en-US/2393a40f-cea8-4bfa-ab72-42b8eaebe5a4/overcoming-the-slow-wsus-clean-up

Die interne WSUS-DB würde ich nicht mehr benutzen.

Die Logfiles findest Du hie:

"C:\Program Files\Update Services\LogFiles\"

Generell dauert der initiale Sync wirklich "ewig".

phatair · 14. November 2023

vor 6 Minuten schrieb zahni:

6GB ist zu wenig, besonders wenn Du keinen Remote-SQL benutzt.

Oh ok, da unser alter WSUS unter 2012R2 auch mit 6GB problemlos gelaufen ist, dachte ich das reicht bei 2019 auch locker aus.

Danke für die Links. Schaue ich mir dann noch an.

Die Optimierungen nehmen wir zum Großteil über das WAM Script vor (https://www.ajtek.ca/). Das läuft aber auf dem neuen WSUS noch nicht, da ich erstmal den WSUS zum laufen bringen möchte.

vor 8 Minuten schrieb zahni:

Die interne WSUS-DB würde ich nicht mehr benutzen.

Ok, auch hier hatten wir bisher keinerlei Probleme, aber werde das mal im Hinterkopf behalten. Vielleicht hat sich hier mit Windows Server 2019 und WSUS doch einiges zum schlechteren verändert.

vor 9 Minuten schrieb zahni:

Die Logfiles findest Du hie:

"C:\Program Files\Update Services\LogFiles\"

Danke Dir, hatte ich auch gefunden. Hatte meinen ersten Beitrag gleichzeitig mit deinem Beitrag editiert.

vor 10 Minuten schrieb zahni:

Generell dauert der initiale Sync wirklich "ewig".

Dann lasse ich das jetzt erstmal laufen. Wenn das morgen nicht durch ist, werde ich ihn neu aufsetzen und gleich eine remote SQL DB nehmen.

cj_berlin · 14. November 2023

vor 1 Minute schrieb phatair:

Oh ok, da unser alter WSUS unter 2012R2 auch mit 6GB problemlos gelaufen ist, dachte ich das reicht bei 2019 auch locker aus.

Es geht tatsächlich weniger um die Version des WSUS, sondern darum, was man darüber verteilt. Auch 2012er WSUSe mussten aufgebohrt werden, als man anfing, darüber Windows 10-Funktionsupdates auszurollen.

zahni · 14. November 2023

Und seit dem initialen Sync unter 2012R2 hat MS jede Menge mehr Metadaten-Müll angesammelt. Nur weil es damals ging, muss es heute nicht mehr laufen...

Da räumt leider niemand wirklich auf. Die SQL-Warnings im Log würde ich mal ignorieren.

bearbeitet 14. November 2023 von zahni

Sunny61 · 14. November 2023

vor 26 Minuten schrieb zahni:

Bei einem richten SQL-Server oder SQL-Express kannst Du das hier machen:

https://social.technet.microsoft.com/Forums/en-US/2393a40f-cea8-4bfa-ab72-42b8eaebe5a4/overcoming-the-slow-wsus-clean-up

Falls das mal jemand testen will, kann man auch versuchen mittel SSMS die SUSDB zu sichern, die Sicherung auf einem richtigen SQL restoren, die Änderungen vornehmen, sichern und wieder auf dem Ursprungsserver (WSUS mit WID) zurück sichern.

phatair · 14. November 2023

Danke euch für die schnelle Hilfe.

Der Sync läuft aktuell und ist bei 27%.

Ich warte jetzt mal ab. Durch das genannte WAM Script hatten wir eigentlich einen sehr performanten WSUS. Wenn der initiale Sync durch ist und die Clients sich sauber am neuen WSUS melden und mit Updates versorgt werden, werde ich das Script wieder implementieren.

Dann beobachte ich mal die Performance.

Falls der initiale Sync jetzt gar nicht läuft, dann werde ich gleich auf eine remote SQL DB gehen.

Aber die Produkte und Klassifizierungen die wir mit dem WSUS Synchronisieren sind sehr überschaubar.

Klassifizierungen:

- Sicherheitsupdates

- Updates

- Upgrades

- Wichtige Updates

Produkte:

- Office 2016

- Exchange 2016

- Windows 10 and later Dynamic Update

- Windows 10 Feature on Demand

- Windows 10 LTSB

- Windows 10

- Server 2019

- Server 2016

- MS SQL 2017

- MS SQL Management Studio v18

zahni · 14. November 2023

Kleiner Hinweis: SQL2017 ist EOL, da gib es nur noch Sicherheitsupdates. Und Das Management Studio ist bei v19 angekommen. Windows 10 Feature on Demand würde ich weglassen. Meiner Meinung tut das via WSUS nicht.

Dukel · 14. November 2023

Tipp:

Vergiss die Produkte.

Wähle gerne alle an, aber! genehmige nur die Benötigten. So verpasst du keine Updates und nutzt nur den minimal benötigten Platz.

Kein Autoapprove via WSUS, Mit Script gerne.

phatair · 14. November 2023

vor 1 Minute schrieb Dukel:

Tipp:

Vergiss die Produkte.

Wähle gerne alle an, aber! genehmige nur die Benötigten. So verpasst du keine Updates und nutzt nur den minimal benötigten Platz.

Kein Autoapprove via WSUS, Mit Script gerne.

Danke für den Tipp.

Ich dachte immer, dass schon das alleinige auswählen der Produkte dazu führt, dass man die DB zumüllt. Das die Updates erst runtergeladen werden, wenn Sie genehmigt werden ist mir klar.

Wenn ich dich aber richtig verstehe, führt erst das genehmigen dazu, dass auch die DB "zugemüllt" würde.

Ein Auto approve im WSUS ist nicht konfiguriert.

Sunny61 · 14. November 2023

vor 45 Minuten schrieb phatair:

Ich dachte immer, dass schon das alleinige auswählen der Produkte dazu führt, dass man die DB zumüllt. Das die Updates erst runtergeladen werden, wenn Sie genehmigt werden ist mir klar.

Wenn ich dich aber richtig verstehe, führt erst das genehmigen dazu, dass auch die DB "zugemüllt" würde.

Alles was synchronisiert wird, erzeugt Einträge in der Datenbank. Deshalb lösche ich auch fließig alte Updates, nicht nur ablehnen, sondern auch löschen. Im Dateisystem und in der Datenbank. Dieses Script hilft dabei: https://www.wsus.de/wsus-updates-ablehnen/

Beispiel:

$W10_21H1_counted = $W10_21H1.count
    if ($W10_21H1.count -lt 1)
        {
            $W10_21H1_counted = 0
        }
    if ($TrialRun -eq 0 -and $W10_21H1.count -gt 0)
        {
            $W10_21H1 | ForEach-Object{$_.Decline()}
            $W10_21H1 | ForEach-Object{$_.DeleteUpdate()}
        }

Das lässt sich wunderbar ausbauen und auf die eigenen Bedürfnisse anpassen. Office 64Bit ablehnen wenn man nur Offic 32Bit im Einsatz hat. Itanium ablehnen und löschen. Einfach mal reinschauen. ;)

bearbeitet 14. November 2023 von Sunny61

daabm · 14. November 2023

vor 13 Stunden schrieb phatair:

6GB RAM

🙈🙈🙈

Weingeist · 22. November 2023

Am 14.11.2023 um 09:42 schrieb zahni:

Die interne WSUS-DB würde ich nicht mehr benutzen.

Performance oder Sicherheitsgründe weil sie nicht wirklich Updates erhält?

Die Express-Variante ist schon mit wenigen Clients recht schnell am Anschlag. Ist immer ein Riesentheater mit der DB-Grösse, man bewegt sich quasi immer am Limit wenn man nicht wirklich nur eine OS/Office Version hat. Kam eigentlich davon weg und habe (wieder) interne genommen nachdem ich vorher jahrelang Express genommen habe.

zahni · 22. November 2023

Gerade eben schrieb Weingeist:

Performance oder Sicherheitsgründe weil sie nicht wirklich Updates erhält?

Beides. Der "richtige" SQL-Server ist flotter und man kann das Management-Studio usw. nutzen. 10 GB für sollten Express reichen eigentlich. 1 GB RAM könnte ein Problem sein.

Die Performance-Tweaks weiter oben sind wichtig. Und man sollte natürlich Simple Logging nutzen. Wir sichern die Datenbanken nachts immer komplett.

Wir nutzen SQL Standard.

Dukel · 22. November 2023

Das Management Studio kann man für Integrated DB und Express nutzen.

Für die WSUS DB sollte 1 GB RAM ausreichend sein.

Mit den 10 GB hatte ich auch schon Probleme bei einem Kunden. Es war keine große Umgebung, aber die DB wuchs über 10 GB.

Anmelden

Neuer WSUS Server 2019 - Synchronisierung läuft nicht durch

Empfohlene Beiträge

phatair 39

Link zu diesem Kommentar

zahni 554

Link zu diesem Kommentar

phatair 39

Link zu diesem Kommentar

cj_berlin 1.323

Link zu diesem Kommentar

zahni 554

Link zu diesem Kommentar

Sunny61 806

Link zu diesem Kommentar

phatair 39

Link zu diesem Kommentar

zahni 554

Link zu diesem Kommentar

Dukel 454

Link zu diesem Kommentar

phatair 39

Link zu diesem Kommentar

Sunny61 806

Link zu diesem Kommentar

daabm 1.356

Link zu diesem Kommentar

Weingeist 159

Link zu diesem Kommentar

zahni 554

Link zu diesem Kommentar

Dukel 454

Link zu diesem Kommentar

Schreibe einen Kommentar

Menu

Aktivitäten