Dieser Blogpost stellt die Fortsetzung zum ersten Teil des Artikels Deployment von MSP-Updates über WSUS dar. In diesem zweiten Teil werde ich wie bereits angekündigt die Erstellung eines Updatepakets für den Adobe Reader X erläutern.
Dazu müssen wir uns dieses Paket zunächst herunterladen, momentan handelt es sich die Version 10.01. Wie bereits im Artikel Adobe Reader X (10.0) Deployment mit Gruppenrichtlinien mehrfach erwähnt, lassen sich derartige Downloads am einfachsten auf dem öffentlichen FTP-Server von Adobe finden. Hinter dem etwas kryptischen Namen AdbeRdrUpd1001_Tier1.msp verbirgt sich die MUI-Version des Updates, also die Version, die für alle Sprachen geeignet ist.
Nun können wir den Local Updates Publisher starten, wie immer als Administrator. Über Tools -> Create Update starten wir den Wizard zur Update-Erstellung und geben den Pfad zur *.msp-Datei an:
Nach einem Mausklick auf Next erscheint die nächste Seite, hier müssen zumindest die Felder, welche mit einem roten Sternchen markiert sind, ausgefüllt werden. Die übrigen Felder können gut zu Dokumentationszwecken genutzt werden:
Nach zwei weiteren Klicks auf Next gelangen wir auf die Seite Installable Rules, hier können sehr granular nach einer Vielzahl von Parametern Bedingungen formuliert werden, unter welchen das Update installiert werden soll. Hier bietet es sich an eine Regel zu erstellen, welche überprüft ob der Adobe Reader in der Version 10 überhaupt installiert ist. Um dies zu bewerkstelligen können wir z.B. folgenden Registrykey verwenden: HKLM\SOFTWARE\Wow6432Node\Adobe\Acrobat Reader\10.0 . Damit erstellen wir folgende Regel:
Wenn gewünscht können hier sehr komplexe Bedingungen erstellt werden, insbesondere mit WMI-Abfragen ist praktisch jedes Szenario denkbar. Vor allem in Hinblick auf die Zukunftssicherheit können hier je nach Anforderungen sehr komplexe Regeln vonnöten sein. Dies würde jedoch den Umfang dieses Artikels sprengen, weshalb ich hierauf nicht weiter eingehen werde.
Auf den nächsten beiden Seiten erhalten wir noch die Möglichkeit, den Quelltext des Paktes manuell zu bearbeiten. Nach einem Klick auf Finish wird das Paket erstellt und signiert:
Um das Paket nun für bestimmte Computergruppen freizugeben, müssen wir auch den Local Updates Publisher verwenden. Die Updates werden zwar direkt in den WSUS-Server importiert, auch die Approvals werden wie für alle von Microsoft stammenden Updates in der SUS-DB abgespeichert, jedoch ist die Verwaltung der selbsterstellten Updates über die WSUS-Konsole nicht möglich, da diese die Updates nicht in der GUI anzeigt. Die Steuerung der selbsterstellten Pakete ist nur über die WSUS-API möglich, welche auch vom Local Updates Publisher verwendet wird. Um also das selbsterstellte Paket zu approven navigieren wir im Local Updates Publisher zum eben erstellten Paket und öffnen über Rechtsklick-> Approve das entsprechende Menü:
Nun können wir, wie von der WSUS-Konsole gewohnt die Approvals für das Paket setzen:
Hiermit haben wir nun alle zur Paketerstellung notwendigen Schritte abgeschlossen. Beim nächsten Update-Check auf den entsprechenden Clients sollte nun das selbsterstellte Updatepaket zur Installation angeboten werden:
Mit diesem Blogeintrag wollte ich Ihnen einige grundlegende Schritte zur Erstellung von eigenen Updatepaketen aufzeigen. Der Local Updates Publisher stellt eine Vielzahl an Konfigurationsmöglichkeiten zur Verfügung, wie bereits erwähnt ist auch die Verteilung von *.msi und *.exe-Dateien möglich. Weiterführende Informationen zu diesem Tool bietet das Forum der Entwickler auf Sourceforge sowie deren Wiki.