Microsoft Server Update Services (WSUS)

Update 3148812 killt WSUS
https://blogs.technet.microsoft.com/wsus/2016/04/22/what-you-need-to-know-about-kb3148812-part-two/

Beachten Sie auch die Seite Update und Patchmanagement und das dort beschrieben "c't Update"-Projekt 

WSUS 3.0SP2 kann erst mit einem Update auch Windows 8 und Windows Server 2012 bedienen
2734608 An Update für Windows Server Update Services 3.0 Service Pack 2 is available
http://blogs.technet.com/b/sus/archive/2012/09/04/an-update-for-windows-server-update-services-3-0-service-pack-2-is-available-kb2734608.aspx
http://blogs.technet.com/b/sus/archive/2012/09/05/additional-note-on-kb-2734608-regarding-wsu-windows-8-and-windows-server-2012.aspx

Es ist mitten im Sommer 2005, also Microsoft den lange erwarteten Nachfolger von SUS und anderen Update Strategien endlich als finale Version heraus gebracht hat. Es hat ganz schön lange gedauert, bis nach SUS und SUS SP1 nach über 2 Jahren und vielem Hin und Her endlich WSUS Einzug hält. Ich habe etwas das Gezerre zwischen Entwicklern, Marketing und Rechtabteilung mitbekommen, weil die Entwickler gerne mehr Funktionen eingebaut hätten, aber das Marketing noch Luft für SMS angemahnt hat, während die Anwälte natürlich besorgt waren, dass "eine Updatelösung von Microsoft" wieder den Verfechtern einer Zwangsteilung des Konzerns zugearbeitet hätte. Sicher auch ein Grund für die Verzögerungen. Gleich vorneweg:

Jede Firma sollte WSUS einsetzen, es sei denn sie haben eine bessere Patchverteilung und Inventarisierung, wie z.B.: SMS etc. Die Unterstützung der alten Version "Software Update Services" (SUS) entfällt ab dem 06. Dezember 2006 (siehe  http://www.Microsoft.com/windowsserversystem/Updateservices/evaluation/faqs.mspx)

WSUS 3.0 SP2 (Released 25.8 2009)
http://www.microsoft.com/downloads/details.aspx?FamilyID=A206AE20-2695-436C-9578-3403A7D46E40&displaylang=en
Support für Windows 7

WSUS 3.0 Management Pack für MOM 2005 http://go.microsoft.com/?linkid=6814354

Für die Verteilung von Vista und Windows 2008 ist ein Blick auf das AIK interessant
Automated Installation Kit (AIK) für Windows Vista SP1 and Windows Server 2008
http://www.microsoft.com/downloads/details.aspx?FamilyID=94BB6E34-D890-4932-81A5-5B50C657DE08&displaylang=en

Unterstützung durch Net at Work:
Wenn Sie WSUS nicht korrekt konfigurieren, werden mehrere Gigabyte Daten (DE und EN) herunter geladen. Das kostet Internetbandbreite und vielleicht verärgert es nur ihr Anwender. Tipp: Die Patches vom WSUS-Server ihres Dienstleisters übernehmen. Net at Work bietet diesen Service seinen Kunden und Partnern an. Wir bringen die WSUS-update z.B. auf einer Wechselfestplatte mit und installieren ihnen WSUS in kürzester Zeit.

WSUS kostet nichts, wenn Sie die passenden Windows Clients CALs haben und kann im Gegensatz zu SUS und anderen Ansätzen in der ersten Auslieferung die folgenden Microsoft Produkte zentral aktualisieren:

  • Windows 2000 Workstation, Server
  • Windows XP
  • Windows 2003 (auch 64bit)
  • Exchange 2000 und Exchange 2003
  • Office XP (2002) und 2003
  • SQL-Server

Der umfang erstreckt sich aber nicht nur über Hotfix und Security Updates, sondern auch Treiber, Tools, Servicepacks und andere Komponenten sind aktualisierbar. Da das Prinzip modular ist, ist zu erwarten, dass auch weitere Produkte von Microsoft über WSUS zukünftig aktualisiert werden können.

Da WSUS zudem kostenfrei und ziemlich einfach zu installieren ist, wird es sicher in vielen Firmen zum Einsatz kommen. Diese Seite ist auch für mich immer wieder als Gedankenstütze für die Installation hilfreich und wird laufend gepflegt.

Wie funktioniert WSUS?

Schon seit längerem können Sie den Dienst "Windows Update" auf ihrem PC, welcher über die Systemsteuerung "Automatische Update" oder vom Administrator über Gruppenrichtlinien gesteuert werden kann.

Die Aufgabe des Windows Update Clients

Der "Windows Update Dienst" auf jedem Endgerät kann schon seit Windows 2000 folgende Aktionen ausführen.

  • Prüfung und Statusmeldung auf Updates
    Der WSUS-Client lädt regelmäßig eine XML-Datei mit der Liste der vom Administrator für seine Gruppe zur Erkennung oder Installation freigegebenen Updates, prüft diese und meldet das Ergebnis an den Server zurück.
  • Auf ausstehende Updates hinweisen
    Der WSUS Client kann den Anwender vor dem Download auf ausstehende Patches hinweisen. Der Administrator kann über eine Gruppenrichtlinie aber auch den automatischen Download ohne vorherige Rückfrage vorschreiben.
  • Die Updates herunterladen
    Der WSUS-Client installiert die Updates nach vorheriger Rückfrage oder auch ohne Rückfrage; je nach Einstellung der Gruppenrichtlinie
  • Bei Bedarf "Neustart"
    Der WSUS-Client startet den PC nach der neu gestartet. Diese Funktion kann auch in der Abmelden/Herunterfahren Prozedur erfolgen.

Diese Funktion ist sowohl beim Einsatz eines SUS-Servers als  auch direkt beim Zugriff über das Internet auf windowsupdate.Microsoft.com gegeben. Die Einstellung, wie sich der Client verhält, können Sie auf Einzelplatz-PCs mit der Systemsteuerung einstellen.

In Firmennetzwerk kommen natürlich eher Gruppenrichtlinien zum Einsatz, so dass alle PCs gleich konfiguriert sind und die Einstellungen wie im Bild sichtbar nicht durch den Anwender zu ändern sind.

Vorteile durch WSUS

Im Firmennetzwerk ist es aber notwendig, dass ein eigener Dienst die Anfragen der Clients anfordert. Dies bringt handfeste Vorteile, für die Sie außer einem Server und etwas Zeit nichts weiter investieren müssen. Der WSUS-Server selbst kostet nichts

  • Zentraler einmaliger Download
    Der Server lädt Updates einmalig herunter. Ihre Endanwender müssen nicht mehr jeder für sich die Updates herunterladen und installieren.
  • Zentrale Freigabe von Patches
    Sie als Administrator geben Patches für die Erkennung und Installation in ihrem Netzwerk frei. Diese Freigabe können Sie für bestimmte Updates und Computergruppen auch automatisch erfolgen lassen.
  • Reporting
    WSUS generiert auf Wunsch einen Bericht über die Computer und die fehlenden bzw installierten Updates und welche Systeme sich schon lange nicht mehr verbunden haben.
  • Setzen einer Deadline
    Wenn ein Patch auf einem Endgerät nur nach Rückfrage durch den Anwender installiert ist, so können Sie eine Deadline setzen, nach der das Update auf jeden Fall installiert wird.

Steuerung durch den Administrator

Dabei kann der Administrator folgendes steuern

  • Zeitpunkt des Download der XML-Dateien
    Der Download der Patchdefinitionen kann manuell oder zu einer bestimmten Zeit am Tag erfolgen.
  • Download der Update von Microsoft per BITS
    Wenn gleich nicht sonderlich bequem, so kann über die Steuerung des BITS-Dienstes die maximale Bandbreite und Zeitbereiche definiert werden, so dass der Patchdownload die Internetanbindung nicht sofort komplett belegt. Wobei ein Patch immer dann in die Downloadwarteschlange aufgenommen wird, wenn der Administrator diesen zur Installation freigibt.
  • Freigabe von Patches je Computergruppe
    Die Gruppen sind keine Gruppen im Active Directory, sondern reine WSUS-Gruppen, in welche die Computer per Hand oder Gruppenrichtlinien aufgenommen werden können.
  • Installationsverhalten auf dem Client
    Wie bisher kann nur über Gruppenrichtlinien das Installationsverhalten der Clients gesteuert werden. Meist werden die Client automatisch installiert und die Server und bestimmte Clients nach Rückfrage des Benutzers oder Administrators.

Dabei gibt es aber eine klare Trennung zwischen Client und Server. Der WSUS-Server kann Patches maximal zur Erkennung oder zum Download bereitstellen. Über die Installation entscheidet allein die Einstellung der Gruppenrichtlinie.

Was nicht möglich ist !

  • kein Push
    Selbst wenn sie einen Patch herunter geladen haben, so können Sie die Installation nicht erzwingen, sondern müssen warten, bis der PC das nächste mal den WSUS-Server anfragt. Allerdings können Sie diese Zeitintervalle auf bis zu eine Stunde reduzieren. Technisch kann der Windows Update Client aus der Ferne natürlich angestoßen werden. Allerdings fehlt eben die GuI dafür.
    Über einen Trick ist es möglich, bei einem Patch eine Deadline zu definieren. Ist diese Deadline in der Vergangenheit, wird der Patch beim nächsten Check durch den Client installiert. Das ist zwar nicht "sofort" aber doch sehr zeitnah, wenn z.B. die Clients alle Stunde nachschauen.
  • keine Zeitsteuerung
    Ist ein Paket zum Installieren freigegeben und der Client installiert automatisch, dann kann das bedeuten, dass sehr viele PCs gleichzeitig laden und installieren. Eine Steuerung a la "maximal xx PCs gleichzeitig das Servicepack laden" ist nicht möglich. Das geht dann erst wieder mit einer größeren Lösung
  • keine Bandbreitensteuerung
    Bis auf die Kontrolle von BITS können Sie daher auch nicht steuern, wie viel Bandbreite durch die Update belegt werden darf. Ich sage nur 100 PCs und das Windows XP Servicepack 2 per WSUS auf einmal verteilen....
  • keine eigenen Updates
    Da haben Sie eine wunderbare Infrastruktur aber die Einbindung eigener Patches und Pakete ist leider nicht möglich. Hierzu müssen Sie weiterhin Gruppenrichtlinien oder kommerzielle Programme verwenden. Selbst wenn es Microsoft Updates sind, die heute noch nicht von WSUS verteilt werden.

Es gibt noch genug Raum zu kommerziellen Patchlösungen und Programmen zur Softwareverteilung.

Meine persönliche Best Practice

Jeder muss natürlich einen eigenen "Patchplan" für seine System entwickeln, aber aus meiner Sicht haben sich folgende Einstellungen bewährt:

Diese Kurzanleitung bewirkt, dass alle erforderlichen Updates für Server bereitgestellt gestellt und auf Clients installiert werden. Wenn Sie

  • DNS Alias anlegen
    Es kann ja sein, dass der WSUS-Server einmal auf einen anderen Server verlagert wird. Daher lege ich immer einen WSUS-Alias an., den ich dann sehr lange nutzen kann.
  • Servereinstellung - Options - Computer Options:
    Ich nutze "Client Targeting",  d.h. die Zuordnung von Systemen zu WSUS-Gruppen über Gruppenrichtlinien.

    Damit dies natürlich funktioniert, müssen die Gruppen in WSUS unter "Computers - Create Group" noch angelegt werden.
    WSUSDEFAULT: Hier landen alle Systeme, die keine besondere Gruppen zugeordnet werden
    WSUSSERVER: Eigene Gruppe für Server ohne automatische Installation von Updates
  • Servereinstellung: - Options - Automatic Approval options:
    Updates automatisch zum Ermitteln und Installieren freigeben
    Folgende Einstellungen im WSUS finde ich geeignet:

    So werden alle Updates automatisch zur Erkennung zur Installation freigegeben. Wenn Sie mögen, können Sie die Freigabe natürlich nach den beiden soeben angelegten Gruppen unterschiedlich einstellen.
  • Gruppenrichtlinien "WSUS Default"
    Diese GPO auf der Domäne wirkt auf alle auf Systeme und konfiguriert den WSUS-Dienst um, damit alle den WSUS-Server statt Windows Update nutzen. Zudem sorgt er für den automatischen Download, die automatische Installation der Updates und die Zuordnung des Clients zur Gruppe "WSUSDEFAuLT". Ich verzichte aber auf einen Neustart sondern lass dies den Benutzer machen bzw. nutze die Tatsache aus, dass die meisten PCs ja abends herunter gefahren werden.
  • Gruppenrichtlinien "WSUS Server"
    Diese GPO ändert nun die Einstellungen der "WSUS Default"-Richtlinie, so dass Server in die Gruppe WSUSSERVER zugeordnet werden und die verfügbaren und erforderlichen Updates automatisch herunterladen aber nicht installieren. Damit kann der Admin beim nächsten Anmelden sofort installieren und eventuell neu starten.

    Alle Server sollten dazu in einer eigenen OU sein, so dass die GPO auf diese Ou gebunden werden kann. Alternativ könnte man auch über eine Sicherheitsgruppe die Anwendung steuern. Beachten Sie aber, dass ein neues System auch diese Richtlinie erhält, da es ansonsten  über die Default Richtlinie am nächsten morgen 07:00 automatisch Updates erhält. Ob die Richtlinie angewendet wird, sehen Sie am besten im WSUS-Server. Hier muss der neue Server in der "passenden" Gruppe erscheinen.
  • Überwachung auf neue/fehlende Patches
    Der WSUS-Server lädt ja alle Updates herunter und installiert diese auf Clients. Daher sollten Sie aber ab und an einfach den Staus "Computers needing Updates" anschauen, ob hier alle Systeme vorhanden sind und speziell welche Server eventuell von Hand installiert und gestartet werden müssen.

Mit diesen Einstellungen sollte erreicht werden, dass Clients automatisch aktuell bleiben und Server sowohl auf der Konsole als auch im WSUS auf fehlende Updates hinweisen.

Für die Überwachung gibt es im WSUS-Resource Kit einige nette Hilfsprogramme um eine Mail zu erhalten, wenn udpates fehlen.

Was passiert wann ?

Folgende kleine Tabelle soll ihnen zeigen, unter welchen Konstellationen was passiert:

Patch bei Microsoft Einstellung in WSUS Einstellung auf dem Client Sichtbarkeit auf dem Client Ergebnis

Kein neuer Patch

egal

egal

keine Störung

nichts zu tun

neuer Patch

nicht ermitteln

egal

keine Störung

Info wird auf WSUS herunter geladen.

Ermitteln

egal

keine Meldung an User

Durch die Ermittlung prüfen alle Clients den Patch und melden das Ergebnis an den WSUS. Der Administrator kann dann sehen, ob der Patch wirklich benötigt wird

Installieren

vor Download und Installation fragen

Nachfrage zu Download eines neuem Patch

Nachfrage zur Installation

Anwender kann den Zeitpunkt des Download und der Installation selbst bestimmen.

Autodownload
vor Installation fragen

Nachfrage zur Installation.

Anwender kann den Zeitpunkt der Installation selbst bestimmen.

AutoDownload und AutoInstall aber kein Neustart

Download und Installation im Hintergrund unsichtbar

Keine Rückfrage

Als Administrator vertrauen Sie darauf, dass der PC vom Anwender z.B. jeden Abend herunter gefahren wird und damit die Installation abgeschlossen wird. Dies ist bei Notebooks und Dank "Hibernate" und "Suspend" allerdings keine Garantie. Im WSUS-Report ist aber zu erkennen, welche Endgeräte noch einen Reboot benötigen.

Vollautomatik

Download und Installation im Hintergrund unsichtbar.

Ist ein Neustart erforderlich, dann wird informiert und kurz darauf gestartet !

 Patches werden komplett durchinstalliert inklusive Neustart des PCs. Diese Einstellung ist daher für Server eher ungeeignet.

Der Neustart passiert automatisch, wenn niemand angemeldet ist.

Angemeldete Administratoren werden regelmäßig mit einer Aufforderung konfrontiert., die irgendwann auch den hartnäckigsten Anwender nervt, so dass er den Neustart durchführt.

Nicht Administratoren werden gewarnt, aber können den Neustart NICHT verzögern

Installieren mit Ablaufdatum

?

?

Diese Einstellung erreicht, dass Clients den Patch nach Ablauf der Frist installieren.

Informationen zu den Spalten:

  • Patch bei Microsoft
    Die Tabelle geht nicht auf die Sonderfälle ein, dass ein Patch zurückgezogen oder aktualisiert wurde.
  • Einstellungen in WSUS
    Sie können im WSUS bestimmen, ob neue Patches nicht ermittelt (default) oder sogar automatisch ermittelt bzw. sogar zur Installation bereitgestellt werden. Zudem ist hier eine Filterung auf Gruppen möglich. Dies sind aber keine Active Directory Gruppen sondern WSUS Gruppen.
  • Einstellung auf dem Client
    Die Tabelle gilt nur, wenn Sie auf dem Client natürlich per Gruppenrichtlinien zumindest den WSUS-Server eingerichtet haben. Diese Spalte ist wichtig, da bei einer Einführung von WSUS viele verunsicherte Anwender die Hotline kontaktieren werden oder genervt sein können.
  • Sichtbarkeit auf dem Client
    Die Meldungen erhalten in der Regel nur Administratoren. Dies kann aber per Gruppenrichtlinie geändert werden, so dass normaler Anwender auch die WSUS-Meldungen sehen können. Das sollten Sie tun, wenn die Benutzer keine Administratoren sind und Sie die Update nicht automatisch installieren lassen.

Wichtig:
Auch wenn Sie ein Patch auf dem WSUS-Server auf "Installieren" stellen, dann bedeutet das nur eine "Bereitstellung". Welcher Client den Patch wie installiert ist eine Frage der Gruppenrichtlinien auf dem Client.

WSUS-update
Es gibt Update, die die Funktion von WSUS selbst verbessern. Diese werden per Default automatisch zur Installation bereit gestellt. Dies kann zu einer ersten Meldung unerwarteten Meldung beim Anwender führen.

Installation, Konfiguration und Betrieb

Die Installation des WSUS-Servers ist eine einfach und geradlinig. Sie benötigen Als Voraussetzung einen Windows 2000 oder 2003 Server, auf dem der IIS und ASP.NET installiert ist. das 120 Megabyte-Paket von Microsoft enthält gleich eine MSDE-Laufzeitversion, die ebenfalls als eigene Instanz installiert wird. Bei der Installation werden Sie im wesentlichen nach den Pfaden zur Ablage der Updates und der SQL-Datenbank sowie die Webseite gefragt, in die sich WSUS integriert oder die von WSUS eingerichtet wird.

Die komplette Bedienung des WSUS-Server erfolgt über Webbrowser und kann von jedem PC aus erfolgen. Die nächsten Schritte sind:

  • Gruppe der WSUS-Administratoren pflegen
    Das Setup legt dazu eine Sicherheitsgruppe "WSUS-Administratoren" an, in die Sie die Administratoren aufnehmen können.
  • Einrichten der Internet Verbindung
    WSUS versucht direkt die Microsoft Update Server zu erreichen. Sie können diese Zugriffe in der Firewall ohne Authentifizierung zulassen oder in WSUS einen Proxy-Server samt Benutzerdaten pflegen
  • Download der Patchliste
    Als erstes sollte die Liste der aktuellen Patches herunter geladen werden. Dies erlaubt eine Kontrolle der Internetverbindung und ist für die weitere Konfiguration von Vorteil, um Produkte entsprechend zu deaktivieren oder zu aktivieren
  • Konfiguration des umfangs, Sprache und Einstellungen der Freigabeautomatik
    Im nächsten Schritt sollten Sie nun steuern, welche Updates Sie überhaupt angezeigt bekommen und zur Installation freigeben wollen. Üblicherweise reichen hier die deutschen und englischen Sprachversionen, wenn Sie in Deutschland arbeiten. Die Expressvarianten sollten Sie nur nutzen, wenn Sie genau deren Funktion verstanden haben. Zwar reduziert dies den Datenverkehr im LAN aber dafür lädt WSUS von Microsoft in etwa die dreifache Datenmenge herunter.
  • Optional: Einspielen eines Backups
    Wenn ihr WSUS-Server nicht mit Microsoft oder einem anderen WSUS-Server kommunizieren kann, dann können Sie von einem anderen WSUS-Server die Daten auch kopieren und über einen Datenträger einspielen. Das kann ihnen auch mehrere Gigabyte Downloads ersparen.

Lesen Sie am Ende, wie sie die WSUS-Datendateien eines anderen Servers per DVD oder Wechselfestplatte übernehmen

  • Freigabe zur Erkennung oder Installation
    Erst dann können Sie die verschiedenen Patches betrachten und freigeben. Es ist auf jeden Fall sinnvoll, die von Microsoft verteilten Patches zur Erkennung einzurichten. Damit prüfen alle Clients, ob der jeweilige Patch erforderlich ist und zeigen dies im Reporting später auch an. Zumindest das Update auf den aktuellen Windows Update Client sollten Sie gleich zur Installation einrichten, damit diese Komponente möglichst aktuell ist.
  • Einrichten der Computergruppen und Gruppenrichtlinien
    Damit die Clients den neuen WSUS-Server auch nutzen müssen Sie über eine oder mehrere Gruppenrichtlinien angewiesen werden, den Server zu nutzen und je nach Bedarf sogar direkt installieren. Wenn Sie Computergruppen über Gruppenrichtlinien vorgeben, müssen Sie die Gruppen trotzdem im WSUS-Server einrichten.

"Normale Anwender" werden vom WSUS-Client nicht benachrichtigt, wenn Patches zum Download oder zur Installation bereit liegen. Wenn ihre Benutzer daher "nur" Anwender sind, dann sollten Sie die Richtlinie so einstellen, dass die Patches zumindest automatisch herunter geladen und installiert werden oder Sie ändern die Einstellung so, dass auch "nicht Administratoren" die Informationen bekommen.
Den Zwang zum Neustart können Sie selbst bestimmen

Nun kommt die lange Zeit des Wartens, da Gruppenrichtlinien nicht sofort aktiv werden. Zum einen müssen die Richtlinien erst im Active Directory repliziert und dann von den Client auch angewendet werden. Den Erfolg der Richtlinien erkennen Sie daran, dass sich die Clients am WSUS-Server melden.

  • Kontrolle der Ergebnisse
    Nach einiger Zeit sehen Sie alle Clients und die von diesen Clients benötigten Patches.
  • Freigabe der Patches zur Installation
    Diese Updates können Sie nun bei Bedarf zur Installation freigeben. Der WSUS-Server lädt diese dann erst herunter und beim nächsten Zyklus können die Clients das Update direkt installieren oder beim Benutzer nachfragen.

Diese Schritte sind demnach auch die Haupttätigkeiten des Administrators in der Folgezeit.

WSUS Daten übernehmen

Wenn Sie einen WSUS-Server installieren, dann werden normalerweise die konfigurierten Updates von Microsoft herunter geladen und auf dem lokalen Server zwischengespeichert. Dies sind bei mir im Juni 2006 mittlerweile 16 GByte, die sich im Verzeichnis WSUSContent angesammelt haben.

Wenn ich natürlich nun zu einem Kunden fahre und WSUS installieren soll, dann möchte der Kunde nicht unbedingt diese Datenmenge über sein Internet herunterladen und ich möchte nicht warten, bis die Updates auch lokal vorhanden sind. Aber auch die umzug eines WSUS-Servers auf einen neuen Server oder eine neue Festplatte ist ein Schritt, bei dem die Daten mitgenommen werden sollten. Es gibt hier mehrere Optionen.

  • WSUS als Slave installieren
    Wenn Sie einen neuen Server installieren, dann können Sie diesen "hinter" ihrem aktuellen WSUS-Server als Slave installieren. Er holt sich dann von diesem Server die gesamten Updates und nach dem Abschluss können Sie ihn wieder als "Standalone" umstellen.
    Diese Verfahren ist auch denkbar, wenn der WSUS-Master z.B.: auf einem Notebook oder eine VM "mitgebracht" wird.
  • Daten auf neue Platte mit gleichem Buchstaben übernehmen
    Wenn der Server der gleiche bleiben soll und nur die Festplatte zu "klein" ist, dann können Sie mehrere Optionen von Windows nutzen, um die Festplatte zu vergrößern. Sie könnten z.B. einfach mit dynamischen Datenträgern die bestehende Partition vergrößern oder auf eine weitere Festplatte ausdehnen (Datenträgersatz). Wenn dies nicht gewünscht ist, könnten Sie die bestehende Partition auf eine neue Platte "spiegeln", dann aufbrechen und die neue Platte vergrößern.
    Das Program WSUSUTIL kennt aber auch eine Option "MoveContent" mit der die Konfiguration und die Daten migriert werden.
  • WSUS Daten kopieren
    Der einfachste Weg ist aber immer noch der COPY. Die kopieren einfach die gesamten Patches über eine Transfermedium (DVD, USB-Disk, LAN etc.) auf den Zielserver und müssen nur noch die Daten in die Datenbank einspielen.

Der letzte Weg ist aus meiner Sicht der einfachste. Die Schritte dazu sind kurz erklärt:

  • Schritt 1: Information der Update exportieren
    Gehen Sie in das WSUSContent Verzeichnis und starten sie folgendes Programm, um die Patchinformation in einer CAB-Datei zu exportieren
"%ProgramFiles%\update services\tools\wsusutil.exe" export .\wsus.cab .\wsusexport.log"
  • Schritt 2: Content und Export kopieren
    kopieren Sie dann einfach das gesamte WSUSContent-Verzeichnis (samt der erstellten CAB-Datei ) z.B.: auf eine Wechselplatte, DVD o.ä.
  • Schritt 3: Installation WSUS
    Auf dem Zielserver können Sie nun ganz einfach den WSUS-Server installieren
     oder direkt zum neuen Zielserver in den bereits installierten WSUS-Server.
  • Schritt 4: Importieren der Datenbank
    Auf dem Zielsystem müssen Sie nun nur noch die CAB-Datei wieder in den SQL-Server mit folgender Kommandozeile importieren
"%ProgramFiles%\update services\tools\wsusutil.exe" import .\wsus.cab .\wsusimport.log

Der Import kann je nach System auch einige Stunden dauern !!!
Ein guter Hinweis zum Fortschritt ist die Größe der SQL-Datenbankdatei.

Unterstützung durch Net at Work:
Wenn Sie einen WSUS-Server installieren und die Updates nicht herunterladen wollen, können Sie meine Kollegen oder mich gerne anfordern. Wir bringen dann gerne die Patches (DE/EN) mit und installieren ihnen den WSUS-Server.

WSUS Details

Der WSUS-Server selbst ist eigentlich eine sehr einfache Anwendung und besteht aus folgenden Komponenten:

  • SQL-Datenbank
    Dreh und Angelpunkt für die Konfiguration und die Liste der Patches ist eine SQL-Datenbank, die entweder auf einem SQL-Server auf dem gleichen Server oder in der ansonsten mit installierten WMSDE liegt.
  • Dateistruktur
    Alle Patches werden als Dateien in einer Verzeichnisstruktur abgelegt. Leider wird dabei keine Struktur analog zu den Produkten und Sprachen angelegt, sondern die Updates landen mit einer GUID als Namen in einer Verzeichnisstruktur mit 256 Unterverzeichnissen. Vermutlich nutzt Microsoft den ähnlichen Code intern und kann so die Verzeichnisse über Mount Points auf mehrere Festplatten verteilen.
  • ASP.NET Verwaltungswebseite
    Sie Verwalten WSUS allein mit dem Browser. Es gibt keine Windows Gui.
  • "update Services"- Dienst
    Dieser Dienst ist für den Download der Patches von Microsoft, die Ablage in der Dateistruktur und Datenbank und die Kommunikation mit der Verwaltungswebseite zuständig.
  • IIS und BITS zur Kommunikation
    Alle Clients übertragen die Dateien per HTTP vom IIS, welcher die Dateistruktur erreichbar macht. Der BITS-Dienst übernimmt dabei die gesicherte Übertragung im Hintergrund.
  • Windows Update Client
    Dieser Prozess auf dem Arbeitsplatz erhält seine Konfiguration über Gruppenrichtlinien und nimmt regelmäßig Kontakt zum WSUS-Server auf, um die aktuell verfügbaren Patches zu evaluieren und bei Bedarf auch zu installieren. Zudem meldet er das Ergebnis der Auswertung an den WSUS-Server zurück.

Was mir bei WSUS fehlt bzw. meine Wunschliste

Nicht ist perfekt und auch wenn WSUS ein großer Fortschritt gegenüber SUS etc. ist, so gibt es einige Punkte, die ich mir noch gewünscht hätte:

  • Keine Benachrichtigung !
    Als Administrator müssen Sie sich entweder bei Microsoft einschreiben, damit Sie per Mail über neue Patches informiert werden, oder Sie schauen täglich im WSUS-Server nach, welche Aufgaben anstehen. Allerdings schreiben Clients und Server in das Eventlog entsprechende Hinweise. Insofern können Sie mit einem Management Pack für MOM2005 oder ein Script für den Server diese Überwachung und Benachrichtigung an Sie nachrüsten.
  • Kein Offline Version
    Wäre es nicht genial, wenn ich als Administrator einfach für einen PC eine DVD brennen kann, die ich dem Außendienst zur Installation zusende ?. Schade dass genau das immer noch nicht möglich ist.
  • Namen der Patches
    Die Patches landen in einer Verzeichnisstruktur und erhalten GUIDs als Namen. Schade, das das es noch mal erschwert, den WSUS-Server als Quelle für manuelle Installationen zu nutzen. Zwar hat jeder Patch auch eine GUID, die auch angezeigt wird, aber eine dazu gehörige Datei gibt es leider nicht.
  • GuI: Patches pro PC hat keine Infos über Downloadstatus
    Natürlich lade ich nicht alle Patches herunter, aber wenn ein Client ermittelt, dass ein Patch fehlt, dann wäre es schon nett auf einen Blick zu sehen, ob dieser denn schon zur Installation bereitgestellt und herunter geladen ist. Bislang muss der Administrator dazu auf den Patch klicken und auf der Karteikarte Status die Information suchen.
  • GuI: veraltete Patches und neuere sind nicht klar zu trennen
    Wenn ich auf einen ziemlich alten PC schaue, dann kommt es oft vor, dass z.B.:  5 "Cumulative Security Updates für IE6) als fehlend aufgelistet werden. Das ist irgendwie unlogisch bzw. erschwert es dem Administrator den wirklich letzten in der Liste zu finden und zu aktivieren
  • kein Preload
    Warum sollte WSUS noch mal die Service Packs und Patches herunter laden, die ich doch schon habe?. Leider gibt es keine Importfunktion. Allein für die Sprachen Deutsch und Englisch werden über 4 GB wieder herunter geladen. Zum Glück kann ein Administrator aber die kompletten Patches eines anderen WSUS-Servers relativ einfach auch über eine DVD oder ein Backup kopieren. Dazu ist nur die Dateistruktur zu übernehmen und auf dem Quellserver mit WSUSuTIL die Datenbankinformation zu exportieren und auf dem Ziel zu importieren (Details siehe WSUS Deployment Guide)
    Es wäre besonders interessant, z.B.: im Rahmen von Zeitschriften CDs oder TechNet Abonnement ein Art "WSUS-Preloadpackage" zu verteilen, das bei der Erstinstallation den Download von mehreren Gigabyte erspart.
  • BITS-Performance
    Die Dateien werden mit BITS übertragen. Zwar nutzt BITS nur die "freie" Bandbreite aber misst dazu das lokale Netzwerkinterface. Auf einem Server, der mit 100MBit angebunden ist, kann BITS nicht erkennen, dass die WAN-Verbindung "nur" 2 MBit hat. Also doch wieder QoS auf die Microsoft Downloadseiten auf der Firewall einstellen ? Zum Glück kann man BITS 2.0 per Gruppenrichtlinien eine Maximalbandbreite zuweisen. Umgekehrt hat mein WSUS-Server aber grade mal mit 4-6kbit geladen, obwohl mein DSL-Anschluss mehr hergegeben hat.
  • BITS und Firewall
    BITS lädt per HTTP oder FTP die Dateien herunter. Leider kann über WSUS kein Benutzername oder Kennwort oder die Daten eines Proxyservers eingetragen werden. In der Dokumentation steht lapidar, dass bestimmte URLs in der Firewall ohne Authentifizierung freizugeben sind. Das ist insofern kein Problem, wenn nur der WSUS-Server den Zugriff erhält, aber viele Firmen nutzen die Proxy-Authentifizierung auch zur Abrechnung der Transfervolumen. Und das wäre es schon schöner, wenn der WSUS-Server mit einem eigenen Dienstkonto erkennbar wäre.
  • BITS Kontrolle
    Zudem ist es anscheinend überhaupt nicht möglich, die Downloadzeiten von BITS zu steuern oder BITS für den WSUS für einige Zeit anzuhalten. Vermutlich bleibt auch das an der Firewall hängen, die bestimmte Ziele eben zu gewissen Zeiten zu blockieren.

Alles in allem sehr interessante Funktionen, wenn gleich noch genug Platz zu SMS und anderen Patchlösungen ist.

Überwachung des WSUS Client

In Ermangelung eines bestehenden MOM Management Packs für WSUS habe ich ein eigenes Management Pack für den WSUS-Client erstellt.

Dieses MP kann nur Systeme überwachen, die auch von MOM Agenten überwacht werden. Es überwacht die Einträge vom "Automatischen Update Dienst". Es überwacht nicht den WSUS-Server !

naw-wsus.akm

Die Überwachung erfolgt auf die Meldungen im SYSTEM-Eventlog des WSUS Clients.

Eventlog: SYSTEM
Ereignisquelle: Windows Update Agent
Ereigniskategorie: Installation
Ereigniskennung Beschreibung

16

Kann keine Verbindung zum WSUS Server aufbauen

17

Es sind Updates verfügbar. Administrator muss aktiv werden

18

Updates wurden herunter geladen und sind Installationsbereich
Event kommt mehrfach vor und die letzte Meldung enthält Liste der ausstehenden Updates

19

Installation von Updates erfolgreich. kein Neustart erforderlich

20

Fehler bei der Installation von Updates

21

Installation von Updates erfolgreich - manueller Neustart erforderlich
Leider kommt nach dem Neustart kein weiterer Erfolgsevent

22

Installation von Updates erfolgreich - Automatischer Neustart
Leider kommt nach dem Neustart kein weiterer Erfolgsevent

27

Update Dienst wurde angehalten

Entsprechend der Meldungen werden durch das AKM Events und Alerts generiert. Dies funktioniert nur mit Systemen, die natürlich mittels MOM überwacht werden und der "Windows Update Agent" muss bereits installiert und konfiguriert sein. Leider habe ich noch keinen eigenen View für WSUS definiert.

Zudem können Sie ein Detailprotokoll anlegen

  • 902093 How to read the Windowsupdate.log file

Weitere Links zu MOM und Erweiterungen durch die MSXFAQ finden Sie z.B. auf:

  • MOM2005
  • QStatusMOM
    Überwachung der Warteschlangen anhand des Verweilzeit der ältesten Mail
  • CheckRUS mit MOM
    Überwachung der Funktion des RUS anhand der aktuellen und der von RUS zuletzt bearbeiteten USN
  • CheckADC
    Überwachung der Verbindungsvereinbarungen auf ihre Funktion anhand der bearbeiteten USN

WSUS Client Datenbank

Der WSUS-Client nutzt eine EDB-Datenbank, welche per Default im Verzeichnis "SoftwareDistribution\datastore" liegt. Diese Datei kann man mit dem Programm ESENTuTL.EXE auch defragmentieren.

net stop wuauserv  [ use this if you restarted the Au service ]
esentutl /g %windir%\softwaredistribution\datastore\datastore.edb
net start wuauserv  [use this is you stopped the Au service above ]
exit

Manchmal hilft das auch, wenn WUAu dafür sorgt, dass SVCHOST auf 100% Last ist. Wenn nichts mehr geht und die 100% last sich auch nach Stunden nicht löst, dann "kann" es funktionieren, das Verzeichnis "SoftwareDistribution" komplett zu löschen. Allerdings kann man ohne die Datenbank natürlich auch keine Hotfixes oder Updates einzeln deinstallieren.

WSUS ohne GPO und Domäne

WSUS funktioniert auch ohne Active Directory oder Domäne. Allerdings kann man dann nicht so schön einfach per Gruppenrichtlinien die Einstellungen anpassen, sondern muss diese von Hand eintragen. Dies kann aber auch über eine REG-Datei erfolgen, die Sie auf dem Client importieren können.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Windowsupdate]
"WUserver"="http://wsus:8530"
"WUStatusServer"="http://wsus:8530"
"TargetGroupEnabled"=dword:00000001
"TargetGroup"="Clients"

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Windowsupdate\Au]
"NoAUShutdownOption"=dword:00000000
"NoAutoupdate"=dword:00000000
"AuOptions"=dword:00000003
"ScheduledInstallDay"=dword:00000000
"ScheduledInstallTime"=dword:00000003
"useWUServer"=dword:00000001
"DetectionFrequencyEnabled"=dword:00000001
"DetectionFrequency"=dword:00000001

Passen Sie die Datei ihren Anforderungen entsprechend an und importieren Sie diese über andere Wege. Der Import kann aber nicht durch einen normalen Benutzer erfolgen, da dieser nicht die ausreichenden Berechtigungen hat. Sie können die Einstellungen jedoch z.B. aus der Ferne ausführen, wenn der PC aktiv ist. Besonders interessant sind hier die folgenden Schlüssel in diesem Registry-Zweig.

HKEY_LOCAL_MACHINE\ Software\Policies\Microsoft\Windows\Windowsupdate\Au
  • NoAutoupdate
    0 - Aktiviert automatische Updates (Default)
    1 - Deaktiviert automatische Updates
  • AuOptions
    1 - Autoupdate ist deaktiv (nicht erlaubt in Richtlinien)
    2 - Vor dem Download und vor der Installation benachrichtigen
    3 - Automatisch herunterladen und vor der Installation nachfragen
    4 - Automatisch herunterladen und entsprechend dem Zeitplan installieren
    5 - wie 4 aber Benutzer können Updates konfigurieren
  • Value: ScheduledInstallDay
    0 - jeden Tag installieren
    1 to 7 - Nur am gewählten Daten installieren   1=Sonntag ..7ยด= Samstag
  • Value: ScheduledInstallTime
    0 to 23 - Install time of day in 24-hour format

Automatisches Update beschleunigen

Der Windows Update Client wird zwar über die Richtlinien gesteuert, aber parallel dazu muss der Client natürlich auch hinterlegen, wann die letzten Update geprüft und installiert wurden um die nächsten Aktionen zu planen. Normalerweise legen Sie einen Installationszeitpunkt fest, an oder nach dem die nächste Installation stattfindet. Manchmal möchten Sie aber Updates schnell verteilen. Das macht der Client nach der Installation natürlich auch schnell selbst aber wenn alles installiert ist und erst dann ein neuer Patch anliegt, wird eben bis ein Tag gewartet, bis diese installiert werden. Auch ein "Push" als solches findet nicht statt. Aber mit dem Wissen, wo der Client die Daten hinterlegt, kann man auch etwas nachhelfen. Die relevanten Informationen liegen an folgender Stelle:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Windowsupdate\Auto Update]
"NextDetectionTime"="2006-01-11 10:06:06"
"ScheduledInstallDate"="2006-01-12 06:00:00"

In diesen beiden Werten stehen die Zeiten der nächsten Erkennung als auch der Zeitpunkt der nächsten geplanten Installation (wenn eine automatische Installation konfiguriert ist. Und das ist auch der Hebel, um Updates dann doch zu beschleunigen:

Der Windows Update Client prüft anscheinend beim Start, ob der Zeitpunkt von "ScheduledInstallDate" schon vorbei ist, weil dann die Installation starten muss. Der Trick ist, diese Zeit weit genug in die Vergangenheit zu legen und dann den Dienst neu zu starten um indirekt eine sofortige Installation zu erreichen.

So können Sie z.B. folgendes einfaches VBScript mit einer Gruppenrichtlinie für Computer beim Hochfahren ausführen lassen. (Zeilenumbruch beachten"

' Remove WSUS Key to force Update/install after reboot

Set WSHShell = WScript.CreateObject("WScript.Shell")
wshShell.LogEvent 4, "ForceWSUS start succesfully
WshShell.RegWrite "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Windowsupdate\Auto Update\ScheduledInstallDate" , "2006-01-11 06:00:00" , "REG_SZ"

wshShell.LogEvent 4, "ForceWSUS Done
wscript.quit

Wenn der Windows Update Dienst dann startet, nimmt er an, dass die letzte Installation schon lange zurückliegt und er nach dem Neustart des PCs gleich mit der Installation startet.

Ich kann nicht garantieren, dass dieser Trick immer funktioniert. Eventuell muss der Dienst "Automatische Updates" nach dem Import noch einmal gestartet (net stop wuauserv und net start wuauserv) werden.

Wenn Sie jedoch erweiterte Anforderungen an Patchmanagement stellen, werden Sie kommerzielle Lösungen vorziehen.

WSUS und Self Update

WSUS nutzt den lokal installierten IIS, um den Clients einen Zugriff zu erlauben. Bei der Installation werden Sie gefragt, ob WSUS die Standardwebseite auf Port 80 oder eine eigene Webseite nutzen soll. Zwar ist die erste Option vorgeschlagen, aber viele Administratoren möchten WSUS gerne als eigene Webseite betreiben. WSUS arbeitet dann mit dem Port 8530. Allerdings benötigt der WSUS-Server selbst immer noch die Funktion "Self update". Und diese funktioniert nur, wenn der Zugriff auf "Localhost" einen Webserver erreicht, auf dem das virtuelle Verzeichnis "Self Update" vorhanden ist.

Es gibt aber nun mehrere Gründe, die das verhindern. So könnte ein anderer Webserver auf Port 80 arbeiten, oder Sie haben den IIS umgestellt, dass die eigentliche Standardwebseite auf einem anderen Port arbeitet und Sie port80 für eigene Zwecke verwenden können. Es gibt zwei mögliche Lösungen:

  • Selfupdate in die entsprechende Webseite einbauen
    Kopieren Sie die Konfiguration des virtuellen Verzeichnisses in die Webseite, die aktuell auf 127.0.0.1:80 arbeitet. Dies geht nicht, wenn es sich um einen anderen Webserver handelt.

Oliver Münchow hat mir hier geschrieben, dass es nicht immer ein IIS sein muss, auf dem "Selfupdate" bereit gestellt wird. Wenn Sie z.B. die WSUS-Seite mit dem IIS auf Port 8530 laufen lassen (Wegen ASP erforderlich) aber auf Port 80 z.B. ein Apache seinen Dienst als Firmenwebseite tut, dann können Sie auch im Apache dieses "Selfupdate" veröffentlichen.

<VirtualHost *>
ServerName wsus.meine-firma.de
DocumentRoot "C:/Programme/update Services/Selfupdate"
CustomLog logs/windowsupdate_access.log combined ErrorLog logs/windowsupdate_error.log </VirtualHost>

Alias /selfupdate "C:/Programme/update Services/Selfupdate"
Alias /Selfupdate "C:/Programme/update Services/Selfupdate"
Alias /clientwebservice "C:/Programme/update Services/WebServices/ClientWebService"
Alias /ClientWebService "C:/Programme/update Services/WebServices/ClientWebService"

  • Standardwebseite auf Localhost beschränken
    Es ist problemlos möglich, dass Sie die Standardwebseite wie gewohnt auf Port 80 arbeiten lassen. Damit aber nun eine andere Webseite oder ein anderer Webserver auf Port 80 arbeiten kann, beschränken Sie die Standardwebseite einfach auf 127.0.0.1. Damit ist diese von niemandem erreichbar, außer dem Server selbst.

Für WSUS sind beide Alternativen in Ordnung und nach einem Neustart des "update Service" sollten Sie in der Webseite dann auch nicht mehr die Warnung sehen, dass Selfupdate nicht funktioniert.

Kontrolle auf dem Client

Aber auch auf dem Desktop kann man mit dem neuen Windows Update Client aktiv werden. Dazu dienst das Programm "wuauclt.exe", welches im System32-Verzeichnis gespeichert wird. Es kann direkt mit Kommandozeilen aufgerufen werden:

  • Prüfung nach Updates sofort ausführen
    Folgende Kommandozeile auf dem Client startet eine sofortige Prüfung. Sofort ist aber etwas relativ, denn der Prozess kann durchaus einige Zeit dauern, bis im WSUS-Server der Client dann auch auftaucht:
wuauclt.exe /detectnow
  1. Update mit neuer GUID
    Diese erweiterte Kommandozeile auf dem Client startet nicht nur eine sofortige Prüfung, sondern generiert auch eine neue GUID für den Client. Dies ist sinnvoll, wenn Sie einen Client "klonen". WSUS orientiert sich nicht an der SID oder dem Namen des Computers, sondern hat eine eigenen Schlüssel. Wenn der Client daher vorher schon im WSUS bekannt war, dann wird er nun ein zweites mal erscheinen. Der alte Eintrag wird aber immer weiter veralten und kann manuell oder automatisch gelöscht werden.
wuauclt.exe /resetauthorization /detectnow

Weitere Details finden Sie auch auf folgenden Seiten

Ein häufiger Fehler kann auch sein, dass der User IUSR_Servername deaktiviert ist. Dieser ist aber erforderlich, damit der Zugriff per "Anonymous" funktioniert.

Zusetzt gibt es natürlich auch auf dem Client noch COM-Objekte, die zur Auswertung heran gezogen werden können:

Ein Beispiel könnte wie folgt aussehen:

Set Updatesession = CreateObject("Microsoft.update.Session","PCNAME")
Set Updatesearcher = Updatesession.CreateUpdatesearcher()
WScript.Echo "Searching für Software Updates..." & vbCRLF
Set searchResult = Updatesearcher.Search("IsInstalled = 0 and IsHidden = 0")
WScript.Echo "Pending Updates:" & searchResult.Updates.Count

Noch schöner ist aber die PowerShell-Version, da man hier schon per Kommandozeile einfach "schauen" kann, was passiert:

$Session = New-Object -ComObject Microsoft.update.Session
$Searcher = $Session.CreateUpdatesearcher()
$Searcher.GetTotalHistoryCount()
$list = $Searcher.Search("IsInstalled = 0 and IsHidden = 0")
write-host "Pending Updates " $list.Updates.count

Bestimmte Daten wie z.B. wann das letzte Mal nach Updates gesucht oder Updates installiert wurden, konnte ich bislang nicht per API ermitteln. Die Daten stehen aber in der Registrierung

Oder als Textform

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Windowsupdate\Auto Update\Results\Detect
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Windowsupdate\Auto Update\Results\Download
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Windowsupdate\Auto Update\Results\Install

Per PowerShell kann der Wert recht einfach ausgelesen werden

Get-ItemProperty -Path Registry::"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Windowsupdate\Auto Update\Results\Install" | format-list

Die Zeiten sind in UTC gespeichert.

WSUS Tools und Script

Viele Dinge, die wünschenswert sind, sind aber nicht über die GuI erreichbar, sondern über Skripte. Microsoft liefert dazu WSUS-Tools (http://www.Microsoft.com/windowsserversystem/Updateservices/techinfo/default.mspx), welche einige VBScripte enthalten besonders interessant sind hierbei:

  • ADImporter
    Importiert alle Computerkonten einer Domäne oder Ou in WSUS. Damit können Sie dann auch sehen,  welche Clients es noch in ihrem AD gibt, die aber nicht mit WSUS in Kontakt treten,.
  • CleanStaleComputers
    Das Gegenstück löscht Computer, die sich eine bestimmte Zeit nicht mehr beim WSUS-Server gemeldet haben.
  • ComputersNeedingReboot
    Listet alle Computer, die Updates installiert haben und seit dem noch nicht neu gestartet wurden. Das ist besonders interessant, wenn Notebooks oder Server nicht häufig neu gestartet werden.
  • ComputerStatusToXML
    Dieses Script ersetzt zwar keine Inventory Software aber zeigt doch das ein oder andere in einer XML-Datei auf.

Interessant ist sicherlich, dass die meisten Tools in Visual Basic.NET geschrieben sind und als Sourcecode direkt vorliegen.

Die Tools enthalten noch weitere Skripte und sind eine gute Basis für eigene Entwicklungen mit VBScript und anderen Programmiersprachen.

Zudem gibt es auf http://www.Microsoft.com/windowsserversystem/Updateservices/downloads/default.mspx Server und Client Debug Tools, die z.B. auch einen Weg enthalten, überflüssige Patches zu entfernen

WsusDebugTool /Tool:PurgeunneededFiles

Passend dazu gibt es mit WSUSuTIL einen Befehl, um Patches auch aus der Datenbank zu entfernen

WSUSutil deleteunneededrevisions

Voraussetzung hierfür ist aber, dass die Webseite vorher gestoppt wird und die überflüssigen Patches auch "Abgelehnt" werden.

Die Priorität zum Download von Update kann man mittels OSQL durchführen.

net stop WSusService
"C:\Programme\update Services\tools\osql\osql.exe" -S SRV01\WSUS -E -b -n -Q "USE SUSDB Update tbConfigurationC set BitsDownloadPriorityForeground=1"
net start WSusService

Schade, das viele Funktionen von WSUS daher nicht von der GuI direkt zu erreichen sind. Die beiden folgenden Befehle "sollen" angeblich das gleich bewirken aber bislang konnte ich das nicht bestätigen. Der OSQL-Weg funktioniert bei mir

WsusDebugTool /Tool:SetForegoundDownload
WsusDebugTool /Tool:ResetForegoundDownload

Die Anzeige der aktuellen Einstellungen können Sie ebenfalls per OSQL erhalten:

C:\Programme\update Services\Tools\osql\osql.exe" -S %COMPuTERNAME%\WSUS -E -b -n -Q "use susdb select BitsDownloadPriorityForeground from tbConfigurationC

BitsDownloadPriorityForeground
------------------------------
0
(1 row affected)

Wobei 0 für eine niedrige (Hintergrund) und 1 für eine hohe (Vordergrund) Priorität steht.

Update Services Notification

Auf ein ganz besonderes Programm in diesem "update Services API Samples and Tools" möchte ich noch hinweisen. Es heißt "update Services Notifications" und erlaubt die Installation eines Dienstes, welcher an eine SMTP-Adresse StatusBerichte und Informationen über neue Updates sendet.

Sie installieren einfach das Programm über das Setup und starten dann den Link im Startmenü. Heraus kommt ein Dienst, welcher automatisch gestartet wird und bei neuen Updates und zu den konfigurierten Zeiten entsprechende Reports versendet. Es bietet sich natürlich an, hier generische Adressen von öffentlichen Ordnern oder Verteiler zu nutzen.

Das Programm nutzt die Komponente "web.mail.smtpmail", welche ihrerseits auf CDOSYS aufsetzt. (http://msdn.Microsoft.com/library/default.asp?URL=/library/en-us/randz/protocol/cdosys.asp).

Drücken Sie daher einfach mal auf den Test Button. Wen ein Fehler kommt, dann sehen Sie dort sehr gut die Ursache:

Vielleicht vermissen Sie ein Feld zur Eingabe der "Absenderadresse" der Mail. Da der Source-Code ja offen ist, reicht ein Blick dort hinein um festzustellen, dass das Programm die Zieladresse als Absenderadresse verwendet. Dies ist wichtig, da Exchange ja gerne Adressen ablehnt, die es nicht gibt oder ein Versand an eine externe Adresse verweigert, wenn der Absender nicht intern ist. (Relayschutz). Da hat ein Entwickler wohl nicht ganz zu Ende gedacht. Eine Änderung im Source ist aber einfach möglich.

Die Reports sehen dann wie folgt aus:

  • Bericht über die erfolgte Synchronisation und damit neu verfügbaren Patches
  • Bericht über den aktuellen Status

    Man sieht hier schön, dass auf den meisten Servern aktuell noch Patches fehlen. Man sieht aber nicht, welche und wie viele dies sind. Diese Information steckt in der XML-Anlage.

Conformity Report per Web

Ein Problem von WSUS ist, dass eine Person entweder WSUS Admin ist oder keinen Zugriff erhält. Eine unterteilung in "Nur Anzeigen" gibt es erst einmal nicht. Aber auch hier ist Hilfe in Aussicht, da das Update Services API Samples and Tools"-Paket auch ein Programm zur Erstellung eines Konformitätsberichts enthält. Das Programm liest einfach die Daten aus der Datenbank und erstellt eine einzelne HTML-Seite mit einer Übersicht aller Server und der Anzahl der Patches.

Es ist nun ein leichtes eben dieses Programm z.B.: mit dem Windows Taskplaner immer mal wieder zu starten und die HTML-Datei auf einem Verzeichnis abzulegen und über den IIS freizugeben. So könnten Sie folgenden Batch z.B.: alle Stunden per AT-Befehl starten:

start /wait "C:\Program Files\update Services\Tools\ComplianceReport.exe"
start /wait "C:\Program Files\update Services\Tools\ComputersNeedingReboot.exe"
move "C:\Program Files\update Services\Tools\*.html" "C:\Program Files\update Services\wwwreport"

Der Batch kann problemlos als "SYSTEM" gestartet werden. Dann müssen Sie nur noch das Verzeichnis ":\Program Files\update Services\wwwreport" per NTFS-Berechtigungen sichern und im IIS freigeben:

Damit kann dann auch ein Operator, der nicht direkt am WSUS administrieren darf, einen Überblick über die Systeme erhalten.

Die Ausgaben der beiden Beispielprogramme von Microsoft sind leider nicht ganz korrekt, da Sie nur die fehlenden Patches zählen ohne Rücksicht auf das Alter des Eintrags oder ob der PC überhaupt schon etwas gemeldet hat. Zudem sind die Einträge weder alphabetisch noch nach Gruppen sortiert.

WSUS über ReverseProxy veröffentlichen

In der Regel wird eine Firma den WSUS-Server intern betreiben und damit direkt für Clients erreichbar machen. Die Lizenzbedingungen verbieten, dass Sie einen WSUS ins "Internet" hängen oder gar erreichbar machen. Das wollen Sie aber hoffentlich auch nicht, da der WSUS keine Authentifizierung macht und sich dann JEDER einfach an dem WSUS melden kann und sich hinterlässt. Wenn Sie also morgen nicht 1 Mio "PCs" in ihrer WSUS-Datenbank finden wollen, dann lassen Sie das besser

Aber es kann durchaus eine Option sein, den WSUS nicht direkt von den Clients erreichbar zu machen, sondern hinter einem Proxy zu verbergen, welcher z.B. die Downloads der Updates cachen kann oder den Zugriff auf den WSUS (IP-Restrictions/URL Filtering) absichert.

Dazu sollten Sie aber wissen, dass der WSUS nicht nur "angesprochen" wird, sondern auch eine XML-Datei mit den Updates erstellt. Diese XML-Datei enthält auch die URLs, wo die Updates zu beziehen sind. Und hierzu nutzt der WSUS den Hostname, der im HTTP-Request enthalten ist.

Wer also per Reverse Proxy die Anfragen von den Clients annimmt und an den WSUS als eigenständigen "Request" mit z.B. dem echten Hostnamen des WSUS-Servers oder gar der IP-Adresse weiter gibt, wird auf den Clients erleben, dass diese dann ihren Reverse Proxy umgehen wollen, um die Updates zu ziehen.

Es ist also wichtig, dass der Reverseproxy nicht nur die HTTP-Anfrage weitergibt, sondern den Hostnamen auch in den Request mit übernimmt.

Wer z.B.: den ISA/TMG einsetzt, muss diesen Namen in der Veröffentlichung eintragen bzw die Checkbox setzen, dass der originale Header gesendet wird:

Wer hingegen einen Apache mit MOD_PROXY einsetzt, muss dazu die Option "ProxyPreserveHost" aktivieren.

Alle neuen Clients bekommen dann die neue Patchliste mit den "richtigen" URLs zum Download. Allerdings kann es erforderlich sein, das Sie den Cache auf dem Client einmalig leeren, denn der Windows Update Client speichert sich lokal die Daten in "C:\Windows\SoftwareDistribution". Dieses Verzeichnis können Sie einfach löschen, wenn Sie vorher den Windows Update-Dienst stoppen und danach wieder starten.

Weitere Links