WSUS Package Publisher installieren und konfigurieren

Im Gegensatz zur aktuellen Version (07.04.2013) vom Local Update Publisher läuft der WSUS Package Publisher auf einem Windows Server 2012. Wir benötigen den WSUS Package Publisher http://wsuspackagepublisher.codeplex.com/

Die für dieses HowTo verwendete Version v1.1.1304.12 (15.04.2013) ist nicht zwar mehr die aktuellste, das Prinzip sollte dadurch klar werden. Natürlich gibt es auch eine gute Dokumentation dazu: http://wsuspackagepublisher.codeplex.com/documentation

Das .Net Framework 4.0 muss installiert sein, bei einem W2012 ist das schon dabei. Die restlichen Details entnehmt bitte der Dokumentation des Autors.

Das Paket wird nach dem Download entpackt, es kann sofort die EXE gestartet werden. Eine Installation entfällt. Also sollte man den WSUS Package Publisher vielleicht in einen selbst erstellten Ordner in den %programfiles% ablegen.

Wie man sieht, ist alles vorhanden, sogar eine Dokumentation in Form von zwei PDF-Dateien für die Installation und das Erstellen des Zertifikates sind vorhanden. Mit Doppelklick auf die EXE kann es losgehen. Zuerst müssen die Daten für den zu verwendeten WSUS eingegeben werden.

Servernamen eintragen, den Rest passend ausfüllen und mit OK bestätigen. Im Hauptfenster unten Links noch Connect to Server anklicken. Es gibt leider an dieser Stelle einen Bug, die Verbindung wird hergestellt, aber da das Zertifikat fehlt, steht die Messagebox im Hintergrund und das kleine Fenster muss erst auf die Seite geschoben werden, ansonsten kann der Dialog nicht mit OK geschlossen werden.

Über das Menü Tools wird zuerst das Zertifikat erstellt. Falls jemand eine eigene CA im Einsatz hat, kann man hier das ausgestellte Zertifikat aus der eigenen CA importieren. Für dieses HowTo wird das Zertifikat vom WSUS Package Publisher verwendet. Zuerst über ‚Generate Certificate‘ das Zertifkat erstellen, anschließend im Dateisystem abspeichern. Der Dateiname spielt keine Rolle, wir müssen uns nur merken wo das Zertifikat abgelegt ist, damit wir es später wieder finden, wenn es in das GPO importiert wird.

Das Zertifikat importieren wir sofort in das GPO für den WSUS, dann ist es am richtigen Ort und kann auch gleich über das GPO in den richtigen Zertifikatsspeicher auf den WSUS importiert werden.

An dieser Stelle sei nochmal die Sicherheit erwähnt. Wenn jemand das o.g. Zertifikat besitzt, kann der damit Pakete signieren. Diese Pakete werden grundsätzlich von den Clients/Servern installiert, sie vertrauen ja dem Zertifikat mit dem die Pakete signiert sind. Auch wenn das alles innerhalb eurer Domain abläuft, so sollte man trotzdem das Zertifikat gegen unbefugten Zugriff sichern.

Das Zertifikat muss an zwei Stellen in das GPO importiert werden. Auf dem folgenden Screenshot sind die beiden zu sehen, der Übersetzungsbug aus dem W2008R2 ist auch korrigiert.

Achtung! Um das Zertifikat korrekt an die beiden Stellen hinzufügen zu können, muss man eine GPMC (Group Policy Management Console) von mind. VISTA oder höher verwenden! Die GPMC von W2003 oder XP reicht hier nicht aus! Außerdem ist bei den alten Versionen der GPMC die nächste wichtige neue (erst ab Windows Server 2012/Windows 8) Einstellung noch nicht vorhanden!

Mit Windows 2012 Server/Windows 8 kam eine weitere kleine Neuerung dazu. Wird auf einem Server/Client ein Feature, wie z.B. das .Net Framework 3.5 aktiviert, wird versucht, das Feature beim lokalen WSUS herunterzuladen, wenn ein WSUS bei dem Client/Server in der Registry eingetragen ist. Ist das auf dem WSUS aber nicht in der Form verfügbar, gibt es auf dem Client/Server eine kryptische Fehlermeldung. Um das zu vermeiden kann per GPO eine Alternative vorgegeben werden. Und da alle Clients/Server im Netzwerk das GPO mit den Einstellungen für den WSUS übernehmen, sollte man diese Einstellung gleich in diesem GPO vornehmen.

Es gibt auch einen KB-Artikel zu dem Thema: http://support.microsoft.com/kb/2734782/de

In unserem Fall deaktiviere ich die Einstellung, damit sich die Clients/Server die benötigten Komponenten direkt bei Windows Update nachladen können. Achtung! Dazu muss bei den Clients natürlich auch ein Internetzugang möglich sein. Falls nötig, muss ein passender Proxy konfiguriert sein!

Das GPO ist fertig, jetzt noch die Domaincontroller (falls mehrere vorhanden sind) replizieren lassen, anschließend auf dem WSUS per GPUPDATE (das /force kann man sich sparen) das GPO mit den neuen Einstellungen holen. Gleichzeitig überprüfen ob das Zertifikat auf dem WSUS in den beiden Zertifikatsspeichern vorhanden ist. Denn nur wenn das korrekt erfolgt ist, gibt es keine Fehlermeldung beim Öffnen des WSUS Package Publisher und es können Pakete auch signiert werden. Ohne Zertifikat funktioniert das nicht. Dazu eine leere MMC starten, das SnapIn Zertifikate Hinzufügen, lokales Computerkonto wählen, und Prüfen ob das Zertifikat vorhanden ist.

Zertifikat ist an beiden Stellen vorhanden, jetzt könnte der WSUS Package Publisher gestartet werden. Doch zuerst richten wir den schon angesprochenen Datenbanktrigger ein, damit wir nicht bei jedem Paket, das über den WSUS Package Publisher bereitgestellt wird, das Script zum Updaten der Tabelle tbUpdate ausführen müssen.

Das SSMS (SQL Server-Management Studio) auf dem WSUS starten, zur Instanz des WSUS verbinden und dort anmelden, schon muss die SUSDB zu sehen sein. SUSDB erweitern, Tabelle tbUpdate erweitern, Rechtsklick auf Trigger > neuer Trigger erstellen. Von der Ansicht nicht beindrucken lassen, den vollständigen Inhalt löschen und das nachfolgende Script hineinkopieren.

USE [SUSDB]

GO

/****** Object: Trigger [dbo].[SwitchLocallyPublished] Script Date: 07.04.2013 15:37:05 ******/

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

CREATE TRIGGER [dbo].[SwitchLocallyPublished] ON [dbo].[tbUpdate]

AFTER INSERT

NOT FOR REPLICATION

AS

begin

UPDATE [SUSDB].[dbo].[tbUpdate] SET [IsLocallyPublished] = 0 WHERE [IsLocallyPublished] <> 0

End

Vorsichtshalber das Script in ein Notepad Fenster kopieren, von dort dann heraus- und in das Fenster des SSMS hineinkopieren. Evtl. verborgene Formatierungen von Word gehen damit korrekterweise verloren.

Jetzt auf Ausführen klicken. Wird das Script fehlerfrei ausgeführt, ist es nach einer Aktualisierung bei den Triggern der Tabelle tbUpdate zu sehen.

Das SSMS kann jetzt geschlossen werden. Dafür den WSUS Package Publisher starten. Kommt keine Fehlermeldung, ist das Zertifikat korrekt in den beiden Zertifikatsspeichern angekommen. Wieder unten links zum Server verbinden, schon kann das erste Paket geschnürt werden. Diesmal soll es wieder der Flash Player von Adobe sein, die derzeit aktuelle Version 11.6.602.180 (07.04.2013) wird zur Verfügung gestellt.

Über das Menü Updates oder über einen Rechtsklick im Treeview auf Updates kann ein neues Update erstellt werden.

Im oberen Dialog das MSI auswählen, im Dialog darunter können noch ein zusätzlicher Ordner mit Inhalt oder auch nur einzelne Dateien hinzugefügt werden. Im Gegensatz zum Local Update Publisher ist der Name des Herstellers und der Name der Anwendung bereits ausgefüllt. Im Titel trage ich immer die aktuelle Version ein, das sieht man dann auch später in der WSUS-Konsole. Den Rest kann jeder nach eigenem Ermessen ausfüllen. Im nächsten Fenster können die Regeln festgelegt werden. Damit der Flash Player auch nur Clients angeboten wird, tragen wir hier noch eine neue Regel ein. Bei der Auswahl der Regeln gibt es zwei Einträge für XP, also etwas vorsichtig sein und nach der Auswahl die Version kontrollieren.

Wichtig ist auch der Product Type Workstation. Dann bekommen das Update auch keine Server angeboten. Ob ein Servicepack installiert sein muss, kann jeder für sich selbst entscheiden und passend konfigurieren.

Sieht sauber und aufgeräumt aus, weiter geht’s zum nächsten Fenster. Auch im nächsten Dialog erstellen wir eine zusätzliche Regel auf Clients.

Auf Publish klicken und schon ist der erste Teil erledigt.

Im nächsten Schritt möchten wir das Update in der WSUS-Konsole ‚sehen‘ und dort auch genehmigen. Wenn der Trigger auf der Tabelle tbUpdate korrekt angelegt war, müsste nach dem Erstellen der neuen Ansicht für die Anwendungen in der WSUS-Konsole der Adobe Flash Player sofort erscheinen.

Achtung! Beim WSUS Package Publisher kann man leider noch nicht zwischen den Updates von Microsoft und den Updates, die über den WSUS Package Publisher hinzugefügt worden sind, umschalten. Sobald also der Trigger oder das Update-Query gelaufen sind, sind die Updates/Anwendungen im WSUS Package Publisher nicht mehr zu sehen!

Dazu in der WSUS-Konsole einen Rechtsklick auf Updates machen > neue Updateansicht erstellen auswählen. Die weiteren Schritte könnt ihr aus dem Screenshot entnehmen.

Da es keine Updates sind, sondern eigenständige Anwendungen, heißt bei mir die Ansicht auch Anwendungen.

Noch ein paar Spalten einblenden lassen, schon kann man damit arbeiten. Jetzt nur noch zum Installieren freigeben. Die Clients holen sich die Anwendung beim WSUS und installieren sie gem. den Einstellungen aus dem GPO. Und wir haben auch im WSUS ein ordentliches Reporting. Natürlich vor dem ersten Ausrollen ordentlich testen.

Viel Erfolg beim Ausrollen der Anwendungen!