WSUS 2.0 SP1 - Windows Software Update Service

WSUS 2.0 SP1 - Windows Software Update Service

Verfasser: Winfried Sonntag

Der WSUS 2.0 SP1 kann mit seinem Vorgänger, dem SUS 1.0 nicht mehr verglichen werden. Bitte lesen Sie dazu auch die Softwareanforderungen und die Anforderungen für die Dienste Automatische Updates und dem Intelligenten Hintergrundübertragungsdienst.

Weiterführende Links und White Paper am Ende des Artikels, ein wichtiger schon an dieser Stelle:

WSUS ohne GPO und Domäne: Connect2WSUS.exe
Um einen Client kurzfristig mit Updates zu versorgen war es bisher nötig die entsprechenden Einträge per REG-Datei in die Regsitry zu importieren und um sie anschließend wieder mühsam zu entfernen. Dieses kleine Tool importiert die Einträge, kontrolliert die erforderlichen Dienste, startet sie bei Bedarf und sichert die aktuelle WindowsUpdate.log vorher weg. Sind alle Updates eingespielt, kann ein RunOnce Eintrag erzeugt werden, der alle vorher gemachten Registry Einstellungen nach dem nächsten Neustart wieder rückgängig macht.
Download: Connect2WSUS.exe
Dokumentation: Connect2WSUS.pdf

Als Client OS muß bei W2K mind. das SP3, besser das SP4 installiert sein. Bei XP sollte aus vielen Gründen das SP2 schon längst installiert sein. Seit SP1 kann der aktuelle WSUS auch Updates für VISTA bereitstellen. Der WSUS 2.0 SP1 kann sehr viel mehr Updates/Servicepacks bereitstellen als sein Vorgänger. Auch sind die Updates nicht mehr nur auf das Betriebssystem eingeschränkt. Eine aktuelle Liste gibt’s in einem Screenshot weiter unten.

Der Vorteil vom WSUS im Gegensatz zum SUS ist die Tatsache, daß immer nur die META-Daten für die Updates gedownloadet werden. Die Updates werden erst nach der erteilten Freigabe zur Installation von den MS-Servern gedownloadet. Das Reporting wurde auch deutlich verbessert. Beim WSUS 2.0 SP1 steht eine Website zur Verfügung, die fast keine Wünsche offen läßt.

Der WSUS möchte per Default auf Port 80 installiert werden. Ist im IIS der Port bereits durch eine andere Website belegt (wie beim SBS) wird bei der Installation automatisch der Port 8530 vorgeschlagen.

Die Website vom WSUS kann nach der Installation via http://Servername/WSUSAdmin oder bei Installation auf Port 8530 via http://Servername:8530/WSUSAdmin aufgerufen werden.

Die Installation läuft Assistent gesteuert ab und wird an dieser Stelle nicht dokumentiert.

Es gibt eine kleine Stolperstelle. Wird der WSUS auf einem Memberserver installiert und der Server zu einem späteren Zeitpunkt via dcpromo zu einem Domain Controller hochgestuft, müssen vorher die folgenden Schritte ausgeführt werden:

    1. WSUS deinstallieren
    2. IIS deinstallieren
    3. dcpromo
    4. IIS installieren
    5. WSUS wieder installieren

Bei der Deinstallation vom WSUS wird man gefragt ob die gespeicherten Updates behalten werden sollen, aufgrund der Masse an Updates sollte man an der Stelle die Updates nicht löschen lassen.
In diesem Artikel
http://technet2.microsoft.com/WindowsServer/en/library/4244109a-395a-4ff8-9989-ea55ab0964a31033.mspx?mfr=true
Issue 9: If you install WSUS on a member server and then want to promote the member server to a domain controller, you should first uninstall WSUS

    1. Uninstall WSUS
    2. Promote the Server to a Domain Controller
    3. Reinstall WSUS

ist die Reihenfolge nicht korrekt beschrieben. Hier fehlt die Deinstallation des IIS. Bei einem DC gibt es keine lokale Konten mehr, das als Begründung zu meiner o.g. Empfehlung. Die Begründung liefert Microsoft in diesem Artikel: http://support.microsoft.com/kb/300432/en-us

Das gleiche gilt auch für die andere Richtung, WSUS auf einem DC installiert, der DC wird später via dcpromo zu einem Memberserver herabgestuft.

Hat man die Installation abgeschlossen, die WSUS Admin Seite aufgerufen, sollte als erstes der WSUS mit den MS-Servern synchronisiert werden.

Dies zeigt auch die Aufgabenliste an.

Im Gegensatz zum SUS 1.0 bietet der WSUS 2.0 SP1 sehr viele Möglichkeiten um die Konfiguration an die eigenen Ansprüche anzupassen.

Die Synchronisierung sollte man Täglich automatisch konfigurieren. Am besten natürlich zu einem Zeitpunkt, an dem die Internet Leitung den normalen Arbeitsablauf nicht behindert.

Produkte: Hier lassen sich die Produkte einstellen, für welche man Updates haben bereitstellen möchte. Die beiden nachfolgenden Screenshots zeigen den Stand des WSUS SP1, nach der ersten Synchronisierung kommt da noch einiges dazu.

Wer kein Windows 2000 mehr im Einsatz hat, kann hier schon mal stark filtern.

Klassifizierungen:

Hier kann jeder für sich selbst entscheiden, welche Updates/Servicepacks gedownloadet werden sollen. In den Updaterollups findet man das monatliche Tool zum Entfernen von bösartiger Software wieder.

Entgegen der landläufigen Meinung, ist die Hilfe zum WSUS sehr gut ausgefallen: http://Servers/WSUSAdmin/Help/DE/update_products_and_classifications.htm

Per Default sind die Sicherheitsupdates und die Wichtigen Updates bereits aktiviert.

Nun noch die Updatequelle angeben

Gibt es einen Proxyserver im LAN sollte man hier entsprechenden Daten eingeben.
Sehr wichtig die Auswahl der Sprachen der Updates und den Speicherort. Je nach eingestellten Optionen kann hier schnell ein Datenvolumen bis zu 20 GB gedownloadet werden können. Daher sollte man genügend freien Platz einkalkulieren.

Die SQL-DB des WSUS wächst mit. Aus diesem Grund sollte man auch regelmäßig die Größe der SQL-DB kontrollieren und evtl. alte, nicht mehr benötigte Updates von der Festplatte löschen. Für diesen Zweck gibt es natürlich ein entsprechendes Tool, denn es muss auch die SQL-DB des WSUS aktualisiert werden:

Managing WSUS from the Command Line
http://technet2.microsoft.com/WindowsServer/f/?en/Library/4b87c0d7-6bb2-42fe-b868-8c099b693c881033.mspx

Updatedateien lokal auf diesem Server speichern. Best Praxis ist der 1. Punkt: Nur Updatedateien genehmigter Updates auf diesen Server downloaden.

Auch das ist in der Vergangenheit immer ein Stolperstein gewesen. Der WSUS weiß natürlich nicht, welche Clients in welchen Sprachen sich zum WSUS kontakten, deshalb ist an dieser Stelle Vorsicht geboten, bei der Auswahl der Sprache. Standardmäßig werden ALLE Sprachen gedownloadet! Alternativ kann man den 1. Punkt aktivieren: Nur Updates downloaden, die mit dem Gebietsschema des WSUS übereinstimmen, downloaden.

Nach der ersten Synchronisierung ist erst mal wieder Arbeit angesagt:

Zuerst mal die Synchronisierungseinstellungen überprüfen. Ein Klick auf die Produkte in den Optionen zeigt, was der WSUS jetzt schon alles updaten/patchen kann:

Die Liste ist mittlerweile richtig lang geworden, SQL Server 2000 + 2005 und auch das SP1 für Visual Studio läßt sich mit dem WSUS verteilen.

Jetzt wird es aber erstmal Zeit die GPO für den WSUS zu erstellen. Zu empfehlen sind 2 verschiedene Policy Einstellungen, einmal für die Server und einmal für die Clients. Wer XP Clients und/oder W2K3 Server mit der Policy erreichen möchte, sollte die Policy auf einem XP-Client oder auf einem W2K3 Server erstellen. Für die bessere Übersicht sei auch noch auf die GPMC hingewiesen: http://www.microsoft.com/downloads/details.aspx?FamilyID=0a6d4c24-8cbd-4b35-9272-dd3cbfc81887&DisplayLang=de

Wer einmal damit gearbeitet hat, möchte sie nicht mehr missen.

Bei den Policys gibt’s die Computer- und auch die Userrichtlinien.

Schauen wir zuerst einmal die Computerrichtlinien an:

"2 - Vor Download und Installation benachrichtigen"
"3 - Autom. Downloaden, aber vor Installation benachrichtigen"
"4 - Autom. Downloaden und laut Zeitplan installieren"
"5 - Lokalen Administrator ermöglichen, Einstellung auszuwählen"

Die Option 5 ist nur in den englischen Templates beschrieben: (Danke an Norbert für den Hinweis.)
Allow local administrators to select the configuration mode that Automatic Updates should notify and install updates. With this option, the local administrators will be allowed to use the Automatic Updates control panel to select a configuration option of their choice. For example they can choose their own scheduled installation time. Local administrators will not be allowed to disable Automatic Updates' configuration.

Sollen die Updates per Scheduler installiert werden funktioniert nur die Option 4 so wie sie soll. Das ist die beste Richtlinie für die Clients, immerhin sollen die Updates so bald als möglich installiert werden, da meistens nach dem Erscheinen schon die Exploits erscheinen. Insbesonders der IE ist ja bekannt dafür. Für die Server sollte man wohl eher die Option 3 auswählen, dann kann der Admin gezielt die Updates installieren. Geplanter Installationstag sollte man auch Täglich auswählen, geplante Uhrzeit der Installation muß jeder selbst für sich entscheiden.

Automatische Updates sofort installieren.
Bestimmt, ob Updates, die weder die Windows-Dienste noch Windows neu starten, automatisch installiert werden sollen.
Das muß auch jeder für sich selbst entscheiden ob diese Richtlinie aktiviert wird oder nicht.

Clientseitige Zuordnung.
Bestimmt den Zielgruppennamen, der zum Empfangen von Updates vom Microsoft Updatedienst im Intranet verwendet werden soll.
Hier läßt sich gleich der Gruppenname für den WSUS angeben. Der Name sollte also schon VORHER im WSUS entsprechend angelegt sein. Ebenfalls muß die Option bei der Installation vom WSUS auch mit angegeben werden.

Updates installieren und herunterfahren:
Diese Richtlinieneinstellung ermöglicht Ihnen festzulegen, ob die Option "Updates installieren und herunterfahren" als Standardoption im Dialogfeld "Windows herunterfahren" sein darf.
Ich bin nicht so begeistert von dieser Richtlinie, es kann jederzeit vorkommen, daß ein User einfach den Rechner abschaltet, trotz großem Hinweis. Besser wäre gewesen: Installieren und neustarten.

Erneut zu einem Neustart für geplante Installation auffordern.
Bestimmt den Zeitraum, bevor erneut zu einem Neustart aufgefordert wird.

Internen Pfad für den Microsoft Updatedienst angeben

Hier muß der gleiche Servername angegeben werden, mit dem auch die WSUSAdmin Seite aufgerufen wird. Selbstverständlich kann auch der FQDN angegeben werden.

Keinen Automatischen Neustart für geplante Installationen durchführen:
Legt fest, dass der Computer vom angemeldeten Benutzer manuell neu gestartet werden muss, um die Installation der automatischen Updates fertig zu stellen, anstatt dass der Computer automatisch neu gestartet wird.

Wenn der Status auf "Aktiviert" gesetzt ist, wird der Computer nicht automatisch während einer geplanten Installation neu gestartet, falls zurzeit eine Benutzer angemeldet ist. Stattdessen wird der Benutzer aufgefordert, den Computer neu zu starten.
Achtung: Der User wird zwar darauf hingewiesen und auch mittels Messagebox gefragt, ob er den Rechner neustarten möchte oder nicht. Aktiviert ist aber nur Ja, Neustarten. ;-) Man sollte die User wenn möglich darauf hinweisen, oder die Installation auf einen nicht so kritischen Zeitpunkt verlegen. Da haben so manche schon ein bisschen Arbeit verloren, wenn im richtigen Moment die ENTER-Taste gedrückt wurde.

Neustart für geplante Installationen verzögern:
Bestimmt die Wartezeit vor einem geplanten Neustart.
Wenn der Status auf "Aktiviert" gesetzt ist, wird ein Neustart nach Fertigstellen der Installation entsprechend der angegebenen Minutenanzahl durchgeführt.
Wenn der Status deaktiviert oder nicht konfiguriert ist, beträgt die Standardwartezeit fünf Minuten.

Nicht-Adminstratoren gestatten, Updatebenachrichtigungen zu erhalten.
Falls diese Richtlinie aktiviert ist, erhalten an diesem Computer angemeldete Benutzer, auch wenn sie keine Administratoren sind, Updatebenachrichtigungen.
Damit ist das kleine Symbol im Systray gemeint, mal ehrlich, welcher User achtet da schon drauf? Diese Richtlinie sollte man besser deaktiviert lassen.

Suchhäufigkeit für automatische Updates.
Default ist 22 Stunden, braucht auch nicht geändert zu werden. Die Clients kontakten sich beim ersten booten am Tag sowieso zum WSUS und downloaden evtl. Updates dann auch gleich. Je nach eingestelltem Installationszeitpunkt vergeht also nicht mehr viel Zeit bis die Updates installiert sind und die Gefahr gebannt ist. Neu zur Domain aufgenommene Clients sollte man sowieso nicht ungepatcht auf die Menschheit loslassen.

Zeitplan für geplante Installationen neu erstellen.
Bestimmt die Wartezeit nach dem Systemstart, bevor eine zuvor verpasste geplante Installation ausgeführt wird.
Beispiel: Installationszeitpunkt 03.00 Uhr in der Nacht. Client ist aus. Morgens um 08.00 Uhr schaltet der MA den Client ein und geht erstmal Kaffee holen. Wenn die Updates bereits gedownloadet wurden, und der o.g. Zeitplan auf 1 Min. eingestellt ist, werden die Updates nach 1 Min. installiert und wenn keiner angemeldet ist, startet der Client auch neu durch.

Und jetzt noch einige Userbezogenen Richtlinien:

Zugriff auf alle Windows Update Funktionen entfernen.
Damit werden die systemweiten Einträge auf Windows Update entfernt, z.B. im IE ist via das Menü Extras kein Eintrag zu Windows Update mehr vorhanden. Ebenfalls gibt es keine Benachrichtigung, also kein Symbol im Systray, für angemeldete Administratoren. Dies gilt natürlich nur für User, die auch im Verwaltungsbereich der Richtlinie liegen. Obwohl im Explain nicht explizit genannt, kann diese Richtlinie auch unter W2K erfolgreich eingesetzt werden.

Und noch zwei Einstellungen um den Dialog „Updates installieren und herunterfahren“ zu konfigurieren. Hier muß jeder selbst für sich und seine User entscheiden was er möchte.

Nach dem ersten Synchronisieren ist erst Updates freigeben angesagt. Das ist auch wesentlich komfortabler als beim SUS.

Wenn man weiß, wann die einzelnen Servicepacks für die im Einsatz befindlichen Betriebssysteme veröffentlicht wurden, kann man hier gleich nach dem Datum sortieren, und alles was älter ist, ablehnen. Ein oder mehre Updates markieren geht wie im Explorer mit einzelnen Dateien.

Updates zum installieren freigeben

Erst wenn Updates zum installieren freigegeben werden, bzw. die Genehmigung geändert wird, downloadet der WSUS die Updates. Auch ist es möglich unterschiedliche Genehmigungen für ein und dasselbe Update auf Computergruppen zu erteilen.

Updates auf der WSUSAdmin Seite aufrufen, ein Update selektieren und auf Genehmigung ändern klicken:

Will man jetzt ein Update nur für eine Testgruppe zum installieren aktivieren, einfach rechts neben dem Gruppennamen reinklicken.

Und schon kann man die Genehmigung für das ausgewählte Update nur für diese Gruppe ändern.

Und ja, man kann auch einfach alle neuen Updates für alle Computer zum installieren freigeben. Der Client bekommt auch nur die Updates, die für ihn die richtigen sind. Dann darf man sich auch nicht wundern wenn das Content Verzeichnis anwächst. Das läßt sich natürlich auch ändern, dazu später mehr.

Jetzt können wir uns nur noch zurücklehnen und warten bis die Updates gedownloadet wurden und auf den ersten Clients installiert wurden. Möchte man bei einem Patchday das ganze forcieren, dann hilft ein manuelles Synchronisieren mit dem anschließenden freigeben zum installieren. Wenn die Clients am nächsten Morgen gestartet werden, sind die Updates schon zum download zur Verfügung. Je nach eingestelltem Installationszeitpunkt, werden die Updates noch am selben Tag installiert.

Als Alternative kann man auch auf dem Client das ganz forcieren. Auf der Commandline ein: wuauclt /detectnow mehrmals abgesetzt wirkt Wunder. In Kombination mit der psexec.exe aus den PSTools von MS geht’s sogar vom Server oder von einem administrativen Client aus. http://www.microsoft.com/technet/sysinternals/Networking/PsTools.mspx

Der WSUS 2 kann täglich und/oder wöchentlich den Status als Mail verschicken, der Computer die Updates anfordern. Ebenfalls kann man sich benachrichtigen lassen, wenn neue Updates zur Verfügung stehen. Einfach das Tool (Windows Server Update Services API Samples and Tools ) installieren und im Verzeichnis %ProgramFiles% findet sich ein Ordner Update Services Notifications. Die darin enthaltene USNotifyAdmin.exe läßt uns das ganz leicht konfigurieren:

Achtung! Das Tool verwendet den Empfänger auch als Absender. Der SMTP-Server muß also die Adresse kennen.

WSUSAdmin Seite zum ReadOnly Modus öffnen:
http://www.vbshf.com/vbshf/wsus/wsus_faq.htm#_Toc137608207

Fazit
Mit dem WSUS 2.0 hat Microsoft das updaten/patchen der Systeme dem Administrator um ein vielfaches erleichtert. Im Gegensatz zum SUS gibt es nun ein sehr gutes Reporting, das freigeben vieler Updates ist auch viel einfacher geworden und den Internet Explorer 7 können wir auch schon über den WSUS verteilen. Das ist eine andere Baustelle.

Wichtige und interessante Links zum Thema WSUS:

Startseite WSUS:
http://www.microsoft.com/germany/windowsserver2003/technologien/updateservices/default.mspx

Schrittweise Anleitung für die ersten Schritte mit Microsoft Windows Server Update Services auch White Paper genannt:
http://www.microsoft.com/downloads/details.aspx?FamilyID=3BA03939-A5A9-407B-A4B0-1290BA5182F8&displaylang=de

Windows Server Update Services Downloads
http://www.microsoft.com/windowsserversystem/updateservices/downloads/default.mspx

Managing Windows Server Update Services:
http://technet2.microsoft.com/WindowsServer/f/?en/Library/4b87c0d7-6bb2-42fe-b868-8c099b693c881033.mspx

Blogs zu WSUS
http://msmvps.com/Athif/

Tales from the Script
http://www.microsoft.com/technet/community/columns/scripts/sg0705.mspx

WIKI
www.wsuswiki.com/

FAQ:
http://www.wsus.de/

WinBITS ist eine GUI für den BITS:
http://www.darvin.de/

Deutsche Newsgroup für den WSUS:
microsoft.public.de.update_services

WSUS ohne GPO und Domäne
Um einen Client kurzfristig mit Updates zu versorgen war es bisher nötig die entsprechenden Einträge per REG-Datei in die Regsitry zu importieren und um sie anschließend wieder mühsam zu entfernen. Dieses kleine Tool importiert die Einträge, kontrolliert die erforderlichen Dienste, startet sie bei Bedarf und sichert die aktuelle WindowsUpdate.log vorher weg. Sind alle Updates eingespielt, kann ein RunOnce Eintrag erzeugt werden, der alle vorher gemachten Registry Einstellungen nach dem nächsten Neustart wieder rückgängig macht.
Download: Connect2WSUS.exe
Dokumentation: Connect2WSUS.pdf

Anforderungen für die automatischen Updates
Netzwerkverbindung, Funktionierende DNS-Auflösung und der Dienst Automatische Updates muß auf den Clients gestartet sein und auf Startart „Automatisch“ stehen. Der Intelligente Hintergrundübertragungsdienst muß ebenfalls mindestens auf Manuell eingestellt sein.
HowTo: Zentrale Vergabe lokaler Berechtigungen

(c) 2003 - heute, Mark Heitbrink, weitere Informationen unter WebSite-Info\Copyright