Im Gegensatz zur aktuellen Version (07.04.2013) des Local Update Publishers funktioniert der WSUS Package Publisher auf einem Windows Server 2012.
Wir benötigen den WSUS Package Publisher. Diesen gibt es in der aktuellen Version 1.1.1304.12 (15.04.2013) für 32-Bit und 64-Bit Systeme. Natürlich gibt es auch eine gute Dokumentation dazu.
Als Voraussetzung muss das .Net Framework 4.0 auf dem System installiert sein. Die restlichen Details entnehmen Sie bitte der Dokumentation des Autors.
Nach dem Download muss lediglich die Zip-Datei entpackt werden. Den Inhalt der Zip-Datei sollte man in einen selbsterstellten Ordner (z. B. „WSUS Package Publisher“) unter %ProgramFiles% ablegen.
Von dort aus kann sofort die EXE sofort gestartet werden. Eine Installationsroutine ist für den WSUS Package Publisher „noch nicht“ vorgesehen.
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 einem 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 eine eigene CA im Einsatz ist, 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 und anschließend im Dateisystem abspeichern. Der Dateiname spielt keine Rolle, sie müssen sich nur merken wo das Zertifikat abgelegt ist, damit sie es später wieder finden, wenn es in das GPO importiert wird.
Das Zertifikat importieren sie 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 er damit Pakete signieren. Diese Pakete werden grundsätzlich von den Clients/Servern installiert: Diese vertrauen dem Zertifikat mit dem die Pakete signiert worden sind. Auch wenn das alles innerhalb der eigenen Domain stattfindet, so sollte man trotzdem das Zertifikat gegen unbefugten Zugriff sichern.
Das Zertifikat muss an zwei Stellen in das GPO importiert werden. Auf der folgenden Abblidung sind die beiden zu sehen (der Übersetzungsbug aus dem Windows Server 2008 R2 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 Windows Server 2003 oder Windows XP reicht hier nicht aus! Außerdem ist bei den alten Versionen der GPMC die nächste wichtige neue Einstellung (erst ab Windows Server 2012/Windows 8) 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. Damit alle Clients/Server im Netzwerk die Policy mit den Einstellungen für den WSUS übernehmen, sollte man diese Einstellung gleich in diesem GPO vornehmen.
Zu diesem Thema gibt es einen KB-Artikel: http://support.microsoft.com/kb/2734782/de
In unserem Fall wird diese Einstellung deaktiviert, dass 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 müssen sich nur noch die Domaincontroller (falls mehrere vorhanden sind) replizieren. 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 sollte der schon angesprochenen Datenbanktrigger eingerichtet werden, damit sie 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 11.6.602.180 von Adobe sein, der zur Verfügung gestellt wird.
Über das Menü Updates oder über einen Rechtsklick im Treeview auf Updates kann ein neues Update erstellt werden.
Im oberen Dialog die MSI-Datei 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 wird der Hersteller und der Name der Anwendung aus der MSI-Datei ausgelesen. Im Titel sollte die Versionsnummer hinzugefügt werden, damit diese auch später in der WSUS-Konsole angezeit wird. Den Rest kann man 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 Windows 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 Service Pack installiert sein muss, kann man für sich selbst entscheiden und passend konfigurieren.
Wenn alles gut aussieht geht’s weiter zum nächsten Fenster.
Auch im nächsten Dialog wird eine zusätzliche Regel für Clients erstellt.
Auf ‚Publish‘ klicken und schon ist der erste Teil erledigt.
Im nächsten Schritt wird das Update in der WSUS-Konsole sichtbar gemacht‚ damit es dort auch genehmigt werden kann. 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 > neue Updateansicht erstellen auswählen.
Die weiteren Schritte können aus der nächsten Abbildung entnommen werden.
Da es keine Updates sind, sondern eigenständige Anwendungen, heißt die Ansicht in diesem Fall auch Anwendungen.
Noch ein paar Spalten einblenden lassen, schon kann man damit arbeiten.
Jetzt nur noch zur Installation freigeben.
Die Clients holen sich die Anwendung beim WSUS und installieren sie gem. den Einstellungen aus dem GPO.
Im WSUS entsteht zum Update ein ordentliches Reporting.
Natürlich vor dem ersten Ausrollen von Applikationen ordentlich testen.
Viel Erfolg beim Ausrollen der Anwendungen!
Winfried Sonntag