Ich habe mich in letzter Zeit mit MDT (Microsoft Deployment Toolkit) beschäftigt und mir da auch Gedanken zum WSUS gemacht. In meinem Umfeld wird MDT vor allem für die Installation/Wartung von Citrix Workern (Terminalserver und VDI) genutzt. Diese sind sehr oft auch aus dem Internet zugänglich und sollten daher auch auf einem zeitnahen Patch-Stand sein. Nur wie löst man dies am einfachsten?
Ich ging nun von folgenden Voraussetzungen aus:
Der WSUS soll dediziert für MDT genutzt werden mit sparsamen Ressourcenverbrauch
Die eingesetzten Produkte sind bekannt
Die Client melden regelmässig den Patch-Level
Updates werden freigegeben sobald verfügbar und benötigt
Die Tests finden bei der Abnahme der Citrix Worker statt
Die Installation eines WSUS ist im Internet bestens dokumentiert, ansonsten verweise ich auch gerne auf https://www.wsus.de/
Für die Automatisierung des WSUS habe ich bereits eine kleine Serie verfasst mit folgenden Artikeln:
Die Nummern in der Klammern referenzieren auf die entsprechenden Voraussetzungen.
Durch die Kombination der verschiedenen Automatisierungen läuft der WSUS nun soweit autonom und benötigt kaum mehr manuelle Pflege. :-)
Viel Spass beim Nachbauen.
WSUS – Automatisiertes Update Management
So cool WSUS (Windows Server Update Service) auch ist, so hat er sich leider seit dem Erscheinen mit Windows Server 2003 nicht wirklich weiter entwickelt. Im Bereich der Update-Pflege (Freigabe, Ablehnung, etc.) ist mir der WSUS noch immer nicht flexibel genug. Glücklicherweise kann man hier aber mit PowerShell Abhilfe schaffen und dafür habe ich in meinem Lab mehrere Scripte integriert.
Als erstes fangen wir einmal ganz zu Beginn an…
Beim Einrichten des WSUS wird man ja schön durch den Assistenten geführt mit der Frage nach den Produkten, Klassifizierungen, etc. und zu guter Letzt wird in der Regel die erste Synchronisation durchgeführt. Ist diese beendet würde man am liebsten schon die automatischen Freigaben konfigurieren… STOP!
Ersetzte Updates automatisch ablehnen
Leider schafft es Microsoft bis heute nicht, dass bereits ersetzte Updates gar nicht mehr auf alle WSUS in dieser Welt synchronisiert werden. Bei mir sah es zum Beispiel so aus, nachdem ich in meinem Lab die Windows 10 und Office 2016 Updates hinzugefügt hatte:
Hier kommt nun ein erstes Script in meiner Umgebung ins Spiel, welche ich bei Microsoft Learn gefunden habe. Das genannte Script habe ich für mich lediglich noch so modifiziert, dass ein eigener Pfad für die Logdateien genutzt werden kann, anstatt ein Unterordner vom Script-Pfad.
Das Script läuft bei mir als geplanter Task nach der WSUS Synchronisation und lehnt per se ersetzte Updates gleich einmal ab. So verhindere ich, dass die Update-Dateien später überhaupt heruntergeladen werden.
Voraussetzungen und Parameter für den ersten Task: – Servicebenutzer benötigt WSUS Admin Rechte (entsprechende Gruppenmitgliedschaft) – Programm: PowerShell.exe – Parameter: -ExecutionPolicy Bypass <Pfad>\Decline-SupersededUpdates.ps1 -UpdateServer SERVERNAME -Port PORT#
Nachdem dieser Task ausgeführt wurde, sieht die Statistik schon ein erstes Mal aufgeräumter aus:
Nicht benötigte Updates automatisch ablehnen
Nun gibt es aber immer noch viele Updates, welche ich in meiner Umgebung nie benötigen werde. Ich habe mir deshalb ein Script aufgebaut, in welchem ich als erstes Ausschlüsse definiere wie z.B. Prozessortypen, Windows Editionen und Sprachen. Das Script wird ebenfalls in einem geplanten Task ausgeführt, nachdem die ersetzten Updates bereits bereinigt sind:
Voraussetzungen und Parameter für den ersten Task: – Servicebenutzer benötigt WSUS Admin Rechte (entsprechende Gruppenmitgliedschaft) – Programm: PowerShell.exe – Parameter: -ExecutionPolicy Bypass <Script-Pfad>
Vergleicht man nun auch noch diese Statistik, so sieht es schon sehr viel aufgeräumter aus:
Benötigte Updates automatisch freigeben
Nun wollte ich in meiner Lab-Umgebung darauf verzichten mittels automatischer Freigabe einfach Updates freizugeben und herunter zu laden, obwohl ich sie wahrscheinlich nie benötige. Im vorherigen Artikel habe ich beschrieben, wie man die Clients dazu bringt einen regelmässigen Report zu erstellen. Diese Informationen nutze ich im dritten und letzten Script um angeforderte Updates automatisch freizugeben. Damit kann z.B. sichergestellt werden, dass beim nächsten Lauf einer MDT Tasksequenz der frisch aufgesetzte Rechner die aktuellsten Updates installiert hat.
Dieses Script lasse ich ebenfalls als geplanten Task nach den Bereinigungen ausführen:
Voraussetzungen und Parameter für den ersten Task: – Servicebenutzer benötigt WSUS Admin Rechte (entsprechende Gruppenmitgliedschaft) – Programm: PowerShell.exe – Parameter: -ExecutionPolicy Bypass <Script-Pfad>
Hinweis: Dieses Script sollte natürlich NICHT in einer Umgebung eingesetzt werden, in welcher auch sämtliche Windows Updates einer Change- und Test-Prozedur unterstehen.
Viel Spass beim Nachbauen. :-)
WSUS – Clients zum Update Report zwingen
Wahrscheinlich kennt jeder Administrator, welcher auch WSUS im Einsatz hat die Thematik, dass die Clients mit den Reports auf sich warten lassen.
Nach ein wenig Recherche bin ich bei div. Blogs auf Scripts gestossen, welche den WU Client dazu bringen, dem WSUS sofort einen entsprechenden Report zu senden. Genanntes Script habe ich für mich so modifiziert, dass es nicht vom WSUS aus mittels „Invoke“ sondern direkt auf dem Client (Desktop OS wie auch Server OS) ausgeführt wird.
Voraussetzung ist natürlich, dass die entsprechenden GPO Einstellungen für die WSUS Kommunikation eingerichtet und funktionell sind. ;-)
Das unten verfügbare Script kann dann mittels geplantem Task als „SYSTEM“ regelmässig ausgeführt werden, damit der WSUS auch stets den aktuellen Patch-Stand seiner Zielcomputer weiss.
Parameter für den geplanten Task: – Programm: PowerShell.exe – Parameter: -ExecutionPolicy Bypass <Pfad zum Script>
Microsoft schafft es doch immer wieder zu beweisen, dass deren QS die Aufgabe nicht erfüllt.
Nachdem ich die letzten Windows Updates auf dem WSUS Server installiert hatte, kam ich nicht mehr auf den Server.
Was nun?
Nach einigen Recherchen fand ich dann endlich den notwendigen Input im Microsoft Forum, welcher in meinem Fall genützt hat:
CMD als Administrator starten
Unter %ProgramFiles%\Update Services\Tools den Befehl wsusutil.exe postinstall /servicing ausführen
Im Server Manager das Feature HTTP Activation unter .NET Framework 4.5 Feature installieren
WSUS Dienst neu starten
Danach funktionierte bei mir auch der WSUS wieder.
Viel Erfolg!
WSUS – Cleanup automatisieren
Hallo zusammen und ein frohes neues Jahr :-)
Mir ist es schon letztes Jahr oft aufgefallen, dass beim Ausführen vom Server Cleanup Wizard innerhalb des Windows Server Update Service (WSUS) die Konsole in ein Timeout läuft. Ich hatte dies immer wieder auf die doch schon in die Jahre gekommene MMC Konsole geschoben. Dieses Jahr wollte ich endlich einmal die Serverbereinigung mittels Skript automatisieren und hatte da auch die Hoffnung, dass die Problematik nur ein GUI Problem sei, welches man über Skripting umgehen könnte. Leider war dies nicht der Fall und die Lösung kommt weiter unten…
Ich will es nicht verheimlichen, dass ich eigentlich alles zusammen kopiert habe. Jedoch will ich mit diesem Blog mehrere Beiträge zusammenfassen um den kompletten Weg einer automatisierten WSUS Bereinigung aufzuzeigen. Natürlich sind am Schluss alle Quellen genannt ;-)
Skript
Als erstes habe ich eigentlich nur nach den notwendigen PowerShell Befehlen gesucht und ich wurde dann auf wsus.de mit einem kompletten Skript fündig. WSUS-Cleanup-Skript (Skript als Textdatei) / Link zur Quelle: http://www.wsus.de/serverbereinigung2
Das Skript müsst ihr nur noch mit euern Parametern (Servername, Maileinstellungen, Bereinigungsparametern, etc.) anpassen und schon könnt ihr es als Administrator ausführen (UAC lässt grüssen).
Zusammenfassend sind beim geplanten Task folgende Punkte zu beachten:
– ausführen ob Benutzer angemeldet ist oder nicht
– Benutzer des Tasks muss lokaler Administrator sein (Run as Admin)
– Ausgeführt wird PowerShell mit dem Skriptpfad als Argument
Timeout Problem
Bei einer grossen Menge an Updates wird der WSUS in ein Timeout laufen:
Um dem Abhilfe zu schaffen müsst ihr dieses Timeout im IIS anpassen:
IIS > Sites > WSUS Administration / Advanced Settings… / Limits > Connection Time-out (seconds)
Ich habe dieses bei meinem Server nun von 180 auf 3600 Sekunden erhöht und seither läuft die Bereinigung ohne Probleme.
