Wie bereits in meinem Artikel Adobe Reader X (10.0) Deployment mit Gruppenrichtlinien erwähnt, möchte ich Ihnen im heutigen Blogpost eine Methode vorstellen, mit welcher Sie Produktupdates im *.msp Format mit Hilfe eines WSUS-Servers verteilen können. In diesem Format verteilt z.B. Adobe Updates für den allseits bekannten Adobe Reader. Von Seiten Microsofts ist für ein solches Vorgehen der Einsatz des System Centers Configuration Managers 2007 R2 (SCCM) vorgesehen. Dieser ermöglicht es u.a. solche Updates mit Hilfe eines WSUS-Servers an Clients zu verteilen.
Da der SCCM ein sehr komplexes Produkt ist, macht der Einsatz allein zum Verteilen von *.msp Updates keinen Sinn. Für den Fall, dass Sie dieses Produkt ohnehin schon im Einsatz haben, sollten Sie dieses dann auch dafür verwenden.
Vor allem für kleine und mittlere Umgebungen, für welche der Einsatz eines SCCMs schon alleine auf Grund seiner Komplexität schlicht überdimensioniert wäre, wird mit dem im folgenden beschriebene Szenario aus dem WSUS-Server ein mächtiges Deploymentwerkzeug, und das ganze ohne den Einsatz kostenintensiver Zusatzsoftware.
In unserer Umgebung ist der WSUS inzwischen zur zentralen Softwaredeployment-Methode geworden. Jegliche Software, welche nicht über die Group Policy Software Installation (GPSI) installiert werden kann, kann mit Hilfe des hier beschriebenen Vorgehens verteilt werden. Diese stellt eine deutlich bessere und vor allem weniger fehleranfällige Methode als die leider immer noch viel zu oft verwendeten und eigentlich hoffnungslos veralteten Startupskripts dar.
Der WSUS stellt über die WSUS-API prinzipiell die Funktionalität zur Verfügung, selbst Updates zu erstellen, diese zu signieren, in den WSUS zu importieren und diese zu verwalten. Diese Schnittstelle wird auch vom SCCM verwendet. Das Open-Source Projekt Local Update Publisher hat ein Freewaretool geschrieben, um für diese Funktionalitäten eine GUI zur Vefügung zu stellen. Mit dem Local Updates Publisher können neben den hier beschriebenen *.msp Dateien auch *.msi und *.exe Dateien verteilt werden.
An dieser Stelle möchte ich darauf hinweisen, dass es sich hierbei um Drittanbieter Software handelt und aus diese Grund die Verwendung dieses Tools weder vom ESCde noch von Microsoft selbst supported wird! Alle in diesem Artikel beschriebenen Vorgehensweisen erfolgen selbstverständlich auf eigenes Risiko und sollten vor der Implementierung in einer Produktivumgebung ausführlich in einer Testumgebung getestet werden!
In diesem ersten Teil werde ich sämtliche zur initialen Konfiguration des Servers und der Clients notwendigen Schritte beschreiben. Im zweiten Teil werde ich dann die Erstellung und Verteilung eines *.msp-Update Paktes erläutern.
Für dieses Szanario benötigen Sie:
- einen WSUS-Sever
- .Net 3.5 auf dem Rechner, auf dem der Local Updates Publisher installiert wird
- sollte dieser Rechner nicht der WSUS-Server selbst sein, so wird dort die WSUS-Remote Console bennötigt
- eine Zertifizierungsstelle (CA) , in diesem Szenario wird eine Windows CA verwendet
- Den Local Updates Publisher, die aktuelle Version finden Sie bei Sourceforge
Beginnen wir zunächst mit der Installation des Local Updates Publisher, diese ist eigentlich selbsterklärend.
Die Updatepakete, die über einen WSUS verteilt werden, müssen immer digital signiert werden. Im Falle von Updates für Microsoft-Produkte, welche üblicherweise mit dem WSUS verteilt werden, werden diese von Microsoft selbst signiert. Da jeder Windows-Rechner das Root-Zertifikat von Microsoft mitgeliefert bekommt, wird dieser Signatur immer vertraut. Selbsterstellte Pakete müssen auch signiert sein, sonst können Sie nicht mit dem WSUS verteilt werden. Dazu benötigen wir die CA, mit welcher wir uns ein Code-Signing-Zertifikat erstellen. Dieses müssen wir anschließend auf die Clients verteilen damit diese auch der Signatur der selbsterstellten Zertifikate vertrauen.
Beginnen wir also zunächst mit der Ausstellung des WSUS-Zertifikats, hierfür müssen wir zunächst ein neues Template erstellen, da sich aus dem mit dem standardmäßigen Codesigning Template ausgestelltem Zertifikat der Private Key nicht exportieren lässt.
Hierzu öffnen wir die CA-Managementconsole, klicken auf Certificate Templates -> Manage -> Duplicate Template:
Sollten Sie eine reine Server 2008-CA-Infrastruktur einsetzen, so können Sie als Version 2008 wählen, ansonsten genügt auch Version 2003. Im Tab General sollten wir einen aussagekräftigen Template Namen vergeben, ich habe Code Signing WSUS gewählt.
Im Tab Request Handling muss auf jeden Fall das Häkchen bei Allow Private Key to be exported gesetzt werden:
Nun können wir das duplizierte Template mit einen Klick auf OK abspeichern.
Über Rechtsklick -> New -> Certificate Template to Issue veröffentlichen wir dann das soeben erstellte Template:
Die erforderlichen Schrite an der CA haben wir nun abgeschlossen und können mit Hilfe des frisch angefertigten Templates ein entsprechendes Zertifikat anfordern.
Hierzu öffen wir auf einem beliebigen Rechner, in meinem Fall auf dem WSUS-Server die Zertifikats-MMC über Start -> Ausführen -> MMC -> Add/Remove Snap-In -> Certificates -> My user account. Im Ordner Personal->Certificates fordern wir über Rechtsklick -> All Tasks -> Request New Certificate ein Zertifikat auf Basis des soeben erstellten Templates an:
Dieses soeben frisch erstellte Zertifikat exportieren wir nun über Rechtsklick -> All Tasks -> Export. Sehr wichtig ist hierbei, den Private Key mit zu exportieren:
Auch sollten Sie den Private Key mit einem starken Passwort schützen, denn sollte das exportierte Zertifikat in falsche Hände geraten, so könnte damit eventuell Schadcode unbemerkt auf alle vom WSUS bedienten Clients eingeschleust werden.
Nun können wir damit beginnen, den Local Updates Publisher zu konfigurieren, hierzu starten wir diesen als Administrator. Im ersten Fenster müssen wir uns nun auf den Server verbinden und hierzu den Servernamen angeben. Wenn Sie wie ich in diesem Beispiel auf den lokalen Server verbinden wollen, so können Sie das Feld Name einfach freilassen und sich mit Connect auf den Server verbinden, ansonsten müssen Sie dort den Servernamen angeben.
Sobald Sie auf den Servernamen im linken Menü klicken, wird folgende Meldung erscheinen:
An dieser Stelle bestätigen wir mit Yes und fügen nun das vorher erstellte Zertifikat mit Import Certificate ein. Hier wäre es auch möglich, über Create Certificate ein Self-signed Zertifikat zu erstellen, in diesem Falle müssten Sie dann jedoch im Falle eines Serverwechsels ein neues Zertifikat ausstellen und alle Pakete neu signieren. Da in den meisten Fällen ohnehin eine CA zur Verfügung steht, stellt meiner Ansicht nach das von mir beschriebene Szenario die deutlich bessere Alternative da.
Nach dem erfolgreichen Import erfolgt die Meldung, dass das Zertifikat nun auf die Clients verteilt werden soll, dies werden wir nun auch tun. Mit einem Klick auf Tools -> Certificate Infos -> Export Cert exportieren wir das Zertifikat wieder, und speichern es unter eindeutigem Namen ab.
Nun öffnen wir erneut die Zertifikats-MMC, diesmal jedoch für den Local Computer Account. Dort öffnen wir den Ordner Trusted Publishers und importieren das soeben exportierte Client-Zertifikat.
Anschließend öffnen wir die Gruppenrichtlinien-Verwaltung und erstellen eine neue Gruppenrichtlinie. Nun öffnen wir diese über Rechtsklick -> Edit. Mit dieser Gruppenrichtlinie müssen wir zum einen das Zertifikat auf die Clients verteilen, diese Einstellung finden wir unter Computer Configuration -> Policies -> Security Settings -> Public Key Policies -> Trusted Publishers :
Über Rechtsklick -> Import fügen wir nun das vorher exportierte Zertifikat, welches den Private Key nicht enthält, ein.
Die zweite Einstellung, welche wir setzen müssen ist, erlaubt den Clients auch Updates zu installieren, welche nicht von Microsoft selbst signiert sind. Diese Einstellung finden wir unter Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Windows Updates -> Allow signed updates from an intranet Microsoft update service location. Nachdem wir diese Einstellung auf Enabled gesetzt haben, haben wir die Configuration des Local Updates Publishers und der Clients abgeschlossen.
Im zweiten Teil dieses Artikels werde ich die Verteilung eines *.msp-Updates am Beispiel eines Sicherheitsupdates für den Adobe Reader X erläutern.
