Hallo!

Problem:
Es gelingt uns nicht, einen stabilen sehr großen WSUS Server aufzubauen. Die WID kommt nach einiger Zeit immer wieder ins Timeout.

Hintergrund:
Aus Gründen, die hier nicht diskutieren kann, benötigen wir einen wirklich sehr, sehr großen WSUS-Server. Es sind sehr, sehr viele Produkte, Klassifizierungen und auch mehrere Sprachen angewählt. Wenn der Sync abgeschlossen ist (was nach Ersteinrichtung erst einmal mehrfach scheitert), sind das am Ende > 130.000 Updates mit fast 6 TB auf Platte.

Ich kann nicht diskutieren, OB wir das brauchen, ich muss einen Weg finden, einen WSUS so zu bauen, dass er damit klarkommt.

Was wir schon versucht haben:
Wir haben über PowerShell automatisierte Cleanup-Script, die “superseeded Updates” auch “declined”, (sodass der WSUS-Content Ordner von >5 TB durch das Aufräumen auch wieder auf 2,8 TB gesunken ist). Wir laufen immer wieder in das Problem, dass die WID nicht mehr zu reagieren scheint und die Abfragen an der WSUS Console ins Timeout laufen. Wir haben alle, wirklich alle Tipps zur Frage, wie man die WID neu indexiert und Cleanup macht und so weiter durchgespielt, dennoch gelangen wir immer wieder an die Stelle, an der die WID einfach nicht mehr zu reagieren scheint und die WSUS Konsole nur noch Timeouts meldet.

Neulich haben wir den WSUS neu mit einem SQL-Express statt WID aufgesetzt. Der reagiert im Moment noch, aber die DB nimmt (nachdem wir nur ¼ der eigentlich vorgesehenen Produkte und Klassifizierungen konfiguriert haben) inzwischen schon fast 9 GB. Bei 10 ist bei SQL Express das Lizenz-Limit erreicht.

Frage:
Was tun? Gibt einen Guide für das Setup eines sehr großen WSUS Servers? Bringt der Einsatz eines kostenpflichtigen SQL Servers die erhoffte Besserung, sodass der WSUS auch mit 200.000 oder mehr Updates klarkommt?

Danke im Voraus!

Valentin

Wie Sunny schon geschrieben hat wirst Du mit SQL-Express nicht weit kommen. Beim großen SQL solltest Du vorher den Preis ansehen. Beides ist aber nicht notwendig, denn WID kann dies auch.

Beim WSUS sind 3 Regeln zu beachten. Geduld, Geduld und nochmal Geduld. Was der WSUS gar nicht mag sind ungeduldige Admins die dauernd Knöpfe drücken und den WSUS mit PS-Skripten traktieren. Klingt banal ist aber so.

Bei uns ist es auch so, dass fast alle Produkte im WSUS aktiv sind. Was ca. 30.000 Updates ergibt. Wenn bei Dir 130.000 Updates umd mehr anstehen dann hast Du vermutlich die Treiber in der Klassifizierung aktiv.

Unser Test-WSUS hat die Treiber aktiv und läuft mit ca. 134.000 Updates problemlos mit der WID.

Am besten gehst Du folgendermaßen vor.
+ Wenn möglich lass es nicht zu, dass Clients Kontakt mit dem WSUS aufnehmen.
+ WSUS so konfigurieren, dass Updatedateien nur heruntergeladen werden, wenn Updates genehmigt sind
+ Treiber synchronisieren ohne sie zu genehmigen.
+ Reindexierung WSUS-DB
+ Server Neustart
+ Alle älteren Treiber ablehnen. Das geht aber nicht per Hand, nur per PS-Script.
dann den Rest synchronisieren und nicht benötigte Updates ablehnen.

Vorher über IIS-Manager Warteschlangenlänge auf 8000 und Limit für privaten Speicher auf 0 setzen.

Gib bei jedem Schritt dem WSUS genügend Zeit sich einzupendeln und immer den Server neu starten.

Hallo isibitz,

isibitz schrieb on 31.01.21 um 18:42:08:


Hast du mir einen Hinweis wie das PS Script zum ablehnen von älteren zu machen ist? Bzw. wo finde ich da was dazu?

Danke
Armin

@Armin in etwa so

[reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration") | out-null
if (!$wsus) {
        $wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer();
}

$StartDatum = get-date "01.01.2000"
$EndeDatum = (Get-Date).AddDays(-30)

Get-WsusUpdate -UpdateServer $WSUS  -Approval Unapproved | foreach {
   
    $Classification = $_.Classification
    $GUID = $_.UpdateID
       
    $Title = $_.Update.Title
   
    $Update = $wsus.GetUpdate([guid]”$GUID”)
    $CreationDate = $Update.CreationDate
    If (($CreationDate -ge $StartDatum) -and ($CreationDate -le $EndeDatum) -and ( $Classification -like "Drivers"))  {
       
        $Update  | %{$_.Decline()}
       
    }
}