Viele Wege führen zu einem gut Funktionierenden Windows Server Update Services (WSUS) System. Leider führen nicht alle zum Endgültigen Ziel, vieles sind eher Etappen auf dem Weg. Eine dieser Etappen möchte ich euch hier gerne Vorstellen, gelöst mit etwas PowerShell.
Erstmal etwas Theorie, wenn ein Computer beim WSUS Server Anfragt bekommt er nicht nur eine Liste der für ihn Freigegeben Updates, sondern eine Liste der Updates die nicht Abgelehnt wurden und für die der Computer noch keine Rückmeldung gegeben hat. Also auch die nicht Freigegebenen, damit er dem WSUS eine Rückmeldung geben kann, dieses Update brauche ich auch. So weiß der WSUS welche Updates noch benötigt (Needed) sind.
Warum ist das Schlimm? Schlimm ist das falsche Wort, es kann zu Problemen führen. Jeder WSUS Client kann nur eine Bestimmte Anzahl von Updates verarbeiten. Kommen mehr, macht er einen Teil meldet das zurück und versucht es später erneut. Je nachdem welche Produkte, Klassifizierungen und Sprachen auf dem WSUS konfiguriert sind, kann das schon mal schnell in die Hunderttausende gehen. Neue Computer brauchen so unnötig länger um Updates zu empfangen, gerade wenn sie es nur einmal am Tag versuchen. Auch kann das Auf dem WSUS Server zu Problemen führen. Deshalb hat Microsoft beim WSUS Server auf Basis Windows Server 2016 schon einige Änderungen an ein paar Parametern vorgenommen. Lesen Sie dazu auch den Artikel „Probleme mit dem Windows Server Update Service – 0x8024400D„.
Doch was kann man tun? Aufräumen ist die Antwort. Da das von Hand immer etwas dauert und ich eigentlich faul bin, habe ich ein Skript geschrieben. Aber zuerst schauen wir mal was man aufräumen könnte.
Updates die eventuell nicht gebraucht werden
Achtung!
Bevor Sie dieses Skript benutzen, überlegen Sie genau ob Sie sich sicher sind das sie die Updates in Zukunft nicht brauchen werden. Die Einzige Möglichkeit ist die Updates im ansonsten alle zu genehmigen, ob sie benötigt werden oder nicht. Alternativ, den WSUS neu aufsetzten und von vorne.
Wichtig, es werden auch genehmigte Updates entsprechend behandelt, sprich Abgelehnt!
Dieses Skript fällt somit in die Kategorie „Fabian’s Schrottflinten-Skripte„, so der Begriff den Kollegen geprägt haben, für alles was man vorher 3 mal Überlegen sollte und vorher prüft ob die Backups gelaufen sind.
Itanium Updates
Vor langer Zeit gab es von Intel die Itanium Plattform. Für Windows Server 2008 und 2008 R2 gibt es dafür immer noch Updates. Wenn Sie die nicht benötigen kann das 0-6 Updates im Monat sparen.
Microsoft Office
Leider kann ich bei Office die Version auswählen, nicht die Architektur. Wenn Sie also nur die 32-Bit Version von Office einsetzten, können Sie die x64 Update löschen. Aber denken Sie an die Warnung! Besser ist das, wenn sie nur x64 einsetzten und können die x86 Updates löschen.
Beta oder Preview Updates
Testen Sie gerne in der Produktion die Vorschauversionen von Microsoft? In meiner Test vielleicht, aber bei Kunden? Nein.
Sprachpakete
Wer keine Sprachpakete bzw. das Feature „LanguageFeatureOnDemand“ nutzt, der kann einige dutzend Updates sparen.
Treiber im Allgemeinen
Wer Treiber mal bezogen hat und das jetzt wieder ändern möchte und zwar optimalerweise, der findet auch hier eine Lösung.
Treiber im Speziellen
Was ich noch für Kunden implementiert habe, sind das Ablehnen Spezieller Hersteller Treiber. Einige Hersteller geben sich große mühen, die Treiberupdates auch über WSUS bereitzustellen. Das ist sehr lobenswert, kann aber auch störend sein, wenn man keine Produkte des Herstellers einsetzt. Beispiele sind hierfür Microsoft mit ihren Surface Geräten oder die Firma Dell.
OfficeWebApp und SharePoint
Es gibt auch Updates für OfficeWebApps und SharePoint, die über die Office Kanäle verteilt werden. Auch hier sollte man wieder sehr genau überlegen, ob man diese Option nutzten möchte.
Superseeded oder Veraltete Updates
Auch wenn der WSUS Bereinigungsassistent sie angeblich bereinigt, scheint das nicht immer zu Funktionieren. Hiermit schon.
Weitere Funktionen
Das Skript kann auch im Anschluss eine eMail mit den abgelehnten Updates verschicken. Dies ist besonders praktisch, wenn man das Skript über die Aufgabenplanung laufen lassen möchte. Wer es Manuell startet, der bekommt die Liste immer angezeigt, aber Vorsicht: Beim ersten Lauf kann sie größer sein als der Fensterpuffer des PowerShell Fensters. Also am besten schön vorher vergrößern.
Auch gibt es eine Funktion „WhatIf“ hier wird nichts geändert sondern nur eine was wäre Wenn liste generiert. Optimal wenn man das Ergebnis vorher prüfen möchte.
Nach dem Skript
Nach dem Skript empfiehlt sich eine WSUS Datenbank Optimierung, gerade nach dem ersten Lauf. Auch sollte der WSUS Bereinigungsassistent ausgeführt werden. Dieser entfernt dann nicht mehr benötigte Dateien von der Festplatte und schafft wieder etwas Platz.
Woher bekommt man das Skript jetzt? Wie meistens bei meinem Skripten in der Microsoft TechNet Gallery oder bei GitHub.
Download der PowerShell Skripte
Die PowerShell Skripte sind mittlerweile auf GitHub gehostet.
Hinweis zu Programm- und PowerShell Code
Der hier enthaltene Code dient als Beispiel. Ich übernehme keine Garantie, Gewährleistung oder Support für den Code oder Bestandteile. Verwendung des Codes erfolgt auf eigene Gefahr.
Ich empfehle immer sich die Skripte vor der Verwendung genau anzuschauen, was sie wirklich tun.