Jump to content

Neuer WSUS Server 2019 - Synchronisierung läuft nicht durch


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

Empfohlene Beiträge

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

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

 

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

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

Link zu diesem Kommentar
vor 26 Minuten schrieb zahni:

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.

Link zu diesem Kommentar

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

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

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

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

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