WSUS-Speicherplatz zurückgewinnen: Alte und ersetzte Updates löschen

Abhängig von den Produkten und Klassifi­zierungen, für die man Updates bezieht, kann sich WSUS zu einem Speicher­fresser aus­wachsen. Ein manuelles Auf­räumen ist dann zu auf­wändig, und der Assi­stent für die Server­bereinigung erweist sich als zahnlos. Ein Script von der TechNet-Gallery räumt gründlich auf.

Selbst wenn man nicht viele Produkte abonniert hat und auf bekannte Problem­kandidaten wie Treiber oder Sprach­pakete verzichtet, kann WSUS schnell mehrere hundert GB Speicherplatz ver­schlingen. Ein Auslöser dafür sind meistens automatische Genehmigungen, wobei das Aktivieren der Standardregel oft schon reicht.

Content-Verzeichnis leeren

Wenn die Platte mit Updates vollläuft, dann liegt es nahe, diese zu löschen und den Download neu zu starten. Die damit verbundene Hoffnung, dass dadurch ältere oder bereits ersetzte Updates nicht erneut herunter­geladen werden, erfüllt sich aber nicht. Alle Updates, die zuvor genehmigt wurden, landen wieder auf der Platte.

Falls man die Option, nur genehmigte Updates herunterzuladen deaktiviert hat, dann bekommt man sogar alle Updates.

Der Assi­stent für die Server­bereinigung richtet in diesem Fall nicht viel aus, weil er nur abgelaufene und ersetzte Updates löscht, Letztere erst nach 30 Tagen. Einige Anleitungen empfehlen stattdessen, WSUS zu deinstallieren, die SUSDB-Datenbank und die Updates zu entfernen und ganz neu zu beginnen. Dabei gehen natürlich auch alle Einstellungen und historische Daten verloren.

Will man das vermeiden, dann müsste man alle nicht mehr benötigten Updates ablehnen, bevor man das Verzeichnis wsuscontent leert. Anschließend würden diese nicht mehr heruntergeladen. Bei hunderten oder gar tausenden Updates ist das Ablehnen von Hand zu aufwändig.

Updates per Script ablehnen und löschen

Wesentlich eleganter ist die Lösung, welche der Microsoft-Mitarbeiter Nick Eales mit seinem PowerShell-Script bietet. Es lehnt Updates für alte OS- und IE-Versionen, für Windows auf Itanium oder Sprach­dateien ab und löscht diese dann von der Platte.

Die Filterkriterien finden sich in einer längeren if-Anweisung und sind durch Kommentare dokumentiert. Die eine oder andere Bedingung wird man möglicher­weise nicht übernehmen, beispiels­weise das Ablehnen aller x86-Updates, wenn man noch 32-Bit-Versionen von Windows installiert hat. In diesem Fall kann man die betreffenden Zeilen einfach aus­kommentieren.

Umgekehrt wird man in der Regel die Updates für ARM64 nicht brauchen und kann diese daher zusätzlich zu den Bedingungen des if-Statements aufnehmen. Das gilt zudem für alle anderen Updates, die man nicht benötigt.

Kriterien anpassen

In einigen Punkten bedarf das Script einer Nach­bearbeitung. So klappt die oben beschriebene Ablehnung von x86-Updates nicht, weil der reguläre Ausdruck case-sensitive ist, der LegacyName bei Windows 10 aber ein großes 'X' enthält. Hier sollte man den Operator match durch imatch ersetzen.

Ein ähnliches Problem gibt es bei Language Packs, wo der Such­ausdruck nicht mehr greift. Möchte man diese ablehnen, aber deutsche und englische Sprachpakete behalten, dann sollte man

$_.Title -imatch "language\s" -or

durch

($_.Title -imatch "language" -and $_.Title -notmatch "(DEU|ENG)") -or

ersetzen.

Script starten

Grundsätzlich kann man das PowerShell-Script auch remote ausführen, indem man über die Parameter WSUSServer  und WSUSPort den Namen des Servers und die Port­nummer angibt. Allzu oft brechen aber WSUS-Server, die sehr viele Updates enthalten, die Verbindung ab. Das gilt nicht nur für die WSUS-Konsole, die Unerwarteter Fehler anzeigt und anbietet, den Serverknoten zurückzusetzen.

Daher hat man bessere Chancen auf eine erfolgreiche Ausführung, wenn man das Script direkt am WSUS-Server startet. Dort kann man es einfach über

.\Decline-Updates.ps1

ohne Parameter aufrufen.