Der Platzbedarf einer WSUS-Installation steigt im Lauf der Zeit immer weiter an. So ist es nach 1-2 Jahren normal, dass der WSUS-Ordner mehrere 100 GB an Daten enthält. Dies kann natürlich irgendwann zum Problem werden.
Eine wichtige Aufgabe bei jedem WSUS ist es regelmäßig (alle paar Wochen) den “Assistenten für die Serverbereinigung” in den WSUS-Optionen laufen zu lassen. Damit wird die WSUS-Datenbank verkleinert und nicht mehr benötigte heruntergeladene Dateien werden gelöscht. Wenn man das versäumt wird die Laufzeit des Assistenten so hoch, dass er mit einem TimeOut-Fehler abbricht. Hier hilft nur die Schritte des Assistenten einzeln zu starten und das sooft zu wiederholen, bis der Assistent fertig wird. Wenn es gar nicht geht, kann man immer noch versuchen im “Internetinfomationsdienste (IIS)-Manager” in den erweiterten Eigenschaften des AppPool “WsusPool” die Werte für “Private Memory Limit” (Beispiel: Vierfach) und “Queue Length” (Beispiel: 25000) deutlich zu erhöhen.
Es gibt eine ganze Menge Websites auf denen beschrieben wird wie man den WSUS per SQL oder per PowerShell pflegt (diese und diese habe ich gerade eben entdeckt). Dabei muß man aber immer darauf achten ob man die WSUS-Datenbank mit einem SQL-Server (Voll oder Express) betreibt oder ob man die “interne Windows-Datenbank” verwendet. Das macht beim direkten SQL-Zugriff einen großen Unterschied! Zusätzlich passen diese Lösungen oft nur für eine bestimmte WSUS-Version.
Die ganz radikale Lösung ist natürlich komplett von vorne anzufangen, die WSUS-Datenbank neu aufzubauen und die Updates neu herunterzuladen. Dabei darf man auf keinen Fall einfach den WSUS-Ordner und die vorhandene Datenbank löschen wie oft vorgeschlagen wird! Das kann ganz üble Folgen haben wenn man die interne Windows-Datenbank verwendet (z.B. auf einem Domain Controller). Es gibt im TechNet einen offiziellen Blogeintrag in dem der Ablauf eines Neuaufbaus der WSUS-Datenbank beschrieben wird. Ich habe das so schon einmal ohne Probleme durchgeführt.
Beim WSUS ist es wichtig zwischen den in der Benutzeroberfläche angebotenen Updates und den genehmigten, tatsächlich heruntergeladenen Updates zu unterscheiden. Erstere sind nur Datensätze in der WSUS-Datenbank die kaum Platz benötigen. Nur wenn ein Update in WSUS genehmigt (und damit heruntergeladen) wurde, benötigt es spürbar Platz.
Man sollte eigentlich davon ausgehen, dass der “Assistent für die Serverbereinigung” ersetzte und damit nicht mehr benötigte Updates entfernt um Platz zu sparen. Macht er aber nur sehr eingeschränkt, da er von dem superexotischen Fall ausgeht dass ein Client aus irgendwelchen Gründen die neue Version eines Updates nicht verwenden kann und deshalb auf die alte, eigentlich ersetzte Version zugreifen muß. Da dies in der Realität nicht vorkommt, kann man (fast) gefahrlos im WSUS alle ersetzten Updates ablehen und dann den “Assistenten für die Serverbereinigung” laufen lassen. Dieser löscht u.a. alle abgelehnten Updates, was zu einem massiv reduzierten Platzbedarf führt!
Um die ersetzten Updates ablehnen zu können muß man wie in diesem häufig verlinkten Blogeintrag erklärt im WSUS zuerst mit “Any Except Declined/Any” die Updates anzeigen lassen, dann die Spalte “Superseeded” einblenden und danach sortieren und dann die gewählten Updates ablehnen. Vorsicht! Es gibt drei verschiedene Symbole in der Superseeded-Spalte und nur zwei davon kennzeichnen ersetzte Updates!
[Update]: Bei mir hat aber auch die Auswahl von “Any Except Declined/Any” zu einem TimeOut-Fehler geführt. Hier bleibt nur Schritt für Schritt durch die Optionen (“Approved/Failed”, “Approved/Needed” usw.) zu gehen um die Anzahl der anzuzeigenden Updates kleiner zu halten. Dabei in jeder Ansicht wie oben beschrieben die Superseeded-Updates ablehnen und zum Abschluß den Assistenten laufen lassen.