Automatische WSUS Serverbereinigung mit Tasks und Skripten
Die Windows Updates Services (aktuelle Version 3.0 SP2) kennt jeder versierte Serveradministrator. Als zentraler Server lädt er entsprechend der Konfiguration alle Microsoft Updates herunter und verteilt diese innerhalb der eigenen Organisation. Dazu benötigt der WSUS eine eigene Datenbank, entweder ein SQL Server 2005 Express Edition (frei zum Download verfügbar) oder – sofern vorhanden – einen vollwertigen SQL Server. Viel wichtiger aber ist Speicherplatz, denn der WSUS muss ja alle Updates für die Rechner der Organisation vorhalten.
Den WSUS setzen wir in vielen Kundenumgebungen ein, beim Small Business Server wird er automatisch installiert, in anderen Umgebungen bringt er bereits bei wenigen Server- und Client-Rechnern viele Vorteile. Allerdings hat auch der WSUS einen Nachteil – er verlangt nach einer regelmäßigen Wartung. Dies kann manuell geschehen, indem in der Konsole der Update Services unter [Optionen] der Assistent für die Serverbereinigungaufgerufen wird.
Grundsätzlich eine gute Sache, aber ich bin ein Freund von möglichst integrierter Automatisierung. Auch das ist beim WSUS möglich. Bei WSUS.DE gibt es ein auf PowerShell basierendes Skript mit dem sich die Serverbereinigung direkt starten läßt.
Allerdings gibt das Skript nur Speicherplatz von nicht mehr benötigten Updates auf der Festplatte frei, die Datenbank SUSDB bleibt davon leider unberührt. Aus diesem Grund habe ich versucht das Skript von WSUS.DE zu optimieren und hier mein Ergebnis vorstellen:
Anleitung
Zuerst bitte die folgenden Skripte WSUS-CleanUp.zip herunterladen und in ein Verzeichnis entpacken. Dort finden sich dann folgende Dateien:
WSUS-Serverbereinigung.cmd
WSUS-Serverbereinigung.ps1
WsusDBMaintenance.sql
Das PowerShell Skript (WSUS-Serverbereinigung.ps1) stammt – wie oben erwähnt – von WSUS.DE, ich habe lediglich den Port-Parameter als Übergabewert in das zentrale Skript (WSUS-Serverbereinigung.cmd) verlagert. Das SQL Skript habe ich mir aus dem Script Center von Technet heruntergeladen und nicht verändert.
Vor der ersten Ausführung muss im zentralen Skript (WSUS-Serverbereinigung.cmd) einige wichtige Einstellungen getroffen werden:
PATH=<Pfad zu den Skripten>
WSUS-SERVER=<Servername>
PORT-NUMBER=<Portnummer>
DATABASECONNECT=np:\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query
SQLCMD=”%ProgramFiles(x86)%\Microsoft SQL Server\90\Tools\
Binn\sqlcmd.exe”
Die Werte PATHund WSUS-SERVER bedürfen keiner weiteren Erklärung. Bei PORT-NUMBER muss der Port des WSUS im IIS angegeben werden (auf einem Small Business Server ist das im Standard der Port 8530, nutzt der WSUS die Standardwebseite eines IIS dann lautet der Port 80). Nutzt der WSUS eine SQL Server Express Datenbank kann die Einstellung für DATABASECONNECT belassen werden (Named Pipes), sonst ist der SQL Servername einzutragen. Der Pfad für den Aufruf des SQL Servertools sqlcmd.exe ist von dem Betriebssystem abhängig: bei 32 Bit lautet die Variable %ProgramFiles% bei 64 Bit %ProgramFiles(x86)% - natürlich abhängig von der Version des SQL Servers.
Ich empfehle – so habe ich es auf unseren Systemen umgesetzt – das zentrale Skript WSUS-Serverbereinigung.cmd als Programmaufruf für einen neuen geplanten Task (bei 2003, Aufgabenplanung bei 2008) zu nutzen, welcher wöchentlich 1 mal (der Samstag Vormittag hat sich als Optimum herausgestellt) gestartet werden sollte. In Produktivumgebungen sollte selbstverständlich vor der ersten Ausführung eine Sicherung der SUSDB durchgeführt werden.
Was geschieht nun aber nach dem Aufruf des zentralen Skriptes? Zu Beginn wird eine Protokolldatei WSUS-CleanUp.log im selben Verzeichnis erstellt, in dem alle Aktionen eingetragen werden. Danach bewirkt der Aufruf von PowerShell mit dem Befehl Set-ExecutionPolicy Remotesigned, dass PowerShell Skripte ausgeführt werden dürfen. Genau das geschieht in der nächsten Zeile, in der das PowerShell-Skript von WSUS.DE mit den Parametern WSUS-Server und Port aufgerufen wird. Nach der Bereinigung der WSUS-Dateien wird das SQL Skript von Technet gestartet, welches die SUSDB reindiziert und reorganisiert. Die darauf folgenden Zeilen verkleinern im Anschluss die Datenbank sowie die Datenbankdateien.
Je nach dem wie lange keine Serverbereinigung des WSUS durchgeführt wurde (außerdem wie viele Clients vom WSUS versorgt werden sowie die Leistung des Servers), kann es passieren, dass allein das PowerShell-Skript bis zu 36 Stunden(!) läuft. Deshalb als Task einplanen und laufen lassen – bei einem erneuten Aufruf dauert die gesamte Skriptverarbeitung ca. 30 Minuten. Wem das immer noch zu viel ist, kann natürlich alle Aufrufe des SQLCMD Tools auskommentieren oder löschen.
Wie immer, für Verbesserungsvorschläge, Kritik oder Fragen bin ich immer offen und freue mich über jederzeit über einen Kommentar.

Moin,
die Scripte http://bit.ly/mh9232
liegen da nicht mehr, sind also nicht mehr download-bar.
Gruss
Hallo Paul,
habe es eben getestet, der Download funktioniert bei mir ohne Probleme?
Gruß,
Bent
huch jetzt gehts wieder einwandfrei.
:-)
Hallo Bent,
vielen Dank für deine Skripte und deinen Blogeintrag!
Ich habe mir die Skripte via http://bit.ly/mh9232
heruntergeladen.
Hast du auf lange Zeit gesehen irgendwelche Probleme oder Inkonsistenzen in deinen WSUS-DBs bekommen ?
Viele Grüße
Michael
Hallo Michael,
vielen Dank für Dein positives Feedback.
Zu Deiner Frage kann ich Dir von mehreren Kundensystemen berichten, bei denen ich das Skript bereits seit etwa 10 Monaten ohne einen Fehler (bzw. Probleme) wöchentlich einmal laufen lasse.
Gruß,
Bent
Heute drauf gestoßen. Danke für die Skripte!
[...] Automatische WSUS Serverbereinigung mit Tasks und Skripten – Link [...]
Hallo Bent,
wir haben hier ein hybrides Netz aus 2003 und 2008 mit einem 2008er DC.
Ich hätte noch eine freie 2003er Server Lizenz. Ist die auf 2003 laufende WSUS Version ausreichend oder würdest Du die Anschaffung einer 2008er Lizenz empfehlen?
Hallo Jürgen,
für den Einsatz eines WSUS-Servers ist das Betriebssystem (2003 oder 2008) völlig egal. Du brauchst also keine extra OS-Lizenz zu erwerben, da die WSUS-Version (aktuell 3.0 SP2) auf allen Plattformen gleich ist.
Viel Erfolg beim Aufsetzen!
Gruß,
Bent
Sehr guter Artikel – aber was mache ich, wenn ich die “Windows Internal Database” verwende, dort gibt es keine sqlcmd.exe?!?
Hallo Mister X,
ich verweise einfach mal auf einen weiteren Artikel von mir: http://bit.ly/yMmuUQ
Das sollte Dir weiterhelfen.
Gruß,
Bent
Hallo Bent,
Als erstes… genialer Blog!
Jezt meine Frage… macht die WSUS DB Maintenance auch bei der Verwendung der internal DB Sinn…?
Ist da das Verhalten gleich, wie bei SQL…?
Gruss
Mike
Hallo Mike,
entschuldige die späte Antwort, aber besser spät als nie. Ja, die Verwendung des Maintenance Skriptes macht auch bei der Windows Internal Database Sinn. Die Funktionalität ist die Gleiche. (Letztendlich ist das eine etwas abgespeckte SQL Server Version.)
Gruß,
Bent