Die in jedem Active Directory zur Verfügung stehende und damit kostenlose Technik der Gruppenrichtlinien bietet hier nur eine rudimentäre Lösung an. Die "Group Policy Software Installation" (GPSI) erlaubt nur die Verteilung von MSI-Paketen (Microsoft Installer) und ZAP-Dateien (Zero Administrative Package), die Software bereitstellen können, aber Letztere hat kaum einer verwendet. Zum großen Ärger erhält der Administrator zudem keinerlei Überblick: Kein Monitoring, kein Feedback, keine Inventarisierung und auch keinerlei Information darüber, was passiert ist. Microsoft stellt das MSI-Paket bereit, doch ob der Client die Software mit dem Gruppenrichtliniendienst abgeholt und installiert hat oder nicht, bleibt im Dunkeln. Da ist die Softwareverteilung per Skript zu bevorzugen. Diese kann die fehlenden Informationen zumindest im Rahmen des Skriptes mitloggen und beispielsweise in eine Textdatei schreiben.

Viele Entscheider unterliegen derweil dem Trugschluss, dass sie mit dem Kauf einer Suite zur Softwareverteilung eine "Worry Free"-Lösung erhalten und es keinerlei weiterer Anstrengung bedarf. Dem ist leider nicht so. Softwareverteilung oder auch Deployment generell ist eine vollwertige Jobbeschreibung und keine Nebentätigkeit. Die Herausforderung besteht in der Integration der Software selbst, denn obwohl viele Hersteller ein MSI-Paket mitliefern, verhält es sich je nach Hersteller beim Installieren und Aktualisieren unterschiedlich. Jede Software sowie jedes Update müssen individuell getestet und unter Umständen angepasst werden. Noch spannender wird es bei Legacy Executables (setup.exe), die einmal mit Unattended-Schaltern geliefert werden und ein anderes Mal nicht. Es gibt den berühmten Silent-Schalter "/s", der je nach eingesetztem Installations-Tool sogar case-sensitiv ist. Manchmal muss der Administrator die Software über Reverse-Techniken komplett in ein eigenes neues Setup überführen. Es besteht also ein bunter Strauß an Techniken und damit auch an Lösungen.

Kostenloser WSUS Package Publisher

Eine interessante Alternative in Sachen Softwareverteilung ist der "WSUS Package Publisher 1.3" [1]. Das Tool integriert sich nahtlos in den WSUS-Server von Microsoft und vereint zwei große Vorteile in sich: Die Lizenz ist kostenlos und es setzt auf vorhandene Windows-Bordmittel auf. Generell funktioniert jede Softwareverteilung nach demselben Prinzip: Es gibt eine zentrale Datenablage, ein Repository und es gibt ein Regelwerk, aufgrund dessen Software zugewiesen und verteilt wird. Jeder teilnehmende Computer benötigt einen Agenten oder Dienst, der eine Verbindung zu diesem Verteiler herstellt, das Regelwerk regelmäßig abfragt und dann Software mit administrativen Rechten installiert.

Ebenso benötigt der Dienst eine History und muss erkennen, welche Jobs er schon erledigt hat. Dazu sollte er zentral über Fehler und Erfolge berichten, damit der Administrator eine Übersicht erhält. Eine aktuelle Deployment-Lösung wird die Installation im SYSTEM-Kontext der lokalen Maschine ausführen. Es sollte kein Benutzer mehr erstellt werden müssen, der den Task mit administrativen Rechten ausführt. Der WSUS Package Publisher ermöglicht es, den WSUS-Server als Verteiler zu nutzen und den schon vorhandenen Windows-Update-Dienst als Agenten auf jedem Windows-System.

Der "Windows Server Update Service" (WSUS) ist von Microsoft von Beginn an darauf ausgelegt gewesen, auch Drittanbieter-Software zu verteilen. Microsoft hatte damals den Drittanbietern das Angebot gemacht, dass sie ihre Updates über die Microsoft-Infrastruktur verteilen, anstatt eigene individuelle Update-Dienste zu betreiben. Das haben die Anbieter jedoch dankend abgelehnt und deswegen bringt quasi jede Software einen eigenen Update-Dienst oder -Agenten mit, wenn sie sich installiert. Die Schnittstelle zur Integration der Drittanbieter-Software ist nie geschlossen worden und Microsoft nutzt sie selbst im "System Center Update Publisher" (SCUP), der mit dem "System Center Configuration Manager" (SCCM) kombiniert werden kann.

Installationsfreie Nutzung

Der Download des WSUS Package Publisher erfolgt als ZIP-Datei. Das Tool wird nicht installiert, sondern einfach nur entpackt und ausgeführt. Damit das auch sicher funktioniert, hat Microsoft zwei Security-Barrieren eingebaut: WSUS darf nur Software verteilen, die von Microsoft signiert und mit einem Zertifikat als gültig validiert ist. Ebenso akzeptiert der Client (wuauserv, Windows-Update-Dienst) nur von Microsoft signierte Dateien zur Installation. Ansonsten könnte WSUS als effektive Malware-Schleuder missbraucht werden, wenn er jedwede Dateien verteilen würde, die ihm untergeschoben wurden. Durch diese zwei Stufen der Sicherheit könnte ein WSUS-Server zwar kompromittiert werden, doch der Client selbst ist nicht betroffen, da er die empfangenen, nicht gültig signierten Pakete verweigert. Ein Angreifer müsste also beide Systeme (Verteiler und Ziel) manipulieren.

Damit der WSUS Nicht-Microsoft-Dateien verteilt, benötigt er ein eigenes Zertifikat und diesem müssen die Clients vertrauen. Beim ersten Start des WSUS Package Publisher und der Verbindung zum WSUS-Server meldet die Oberfläche sofort, dass ein Zertifikat benötigt wird, um Software zu integrieren. Dieses wird mit einem Klick auf "OK" selbstständig erzeugt. Natürlich lässt sich auch ein eigenes Zertifikat aus einer AD-integrierten Public Key Infrastructure (PKI) oder ein gekauftes Zertifikat mit der Eigenschaft "Code Signing" einbinden, das für den WSUS-Server ausgestellt ist. Damit werden alle zusätzlichen Produkte und Pakete unterzeichnet, die über den WSUS Package Publisher in WSUS integriert werden.

Clients vorbereiten

Es fehlt noch die Anpassung der Clients. Diese müssen der ausstellenden Zertifizierungsstelle und dem Herausgeber vertrauen. Den öffentlichen Schlüssel des Zertifikats können Sie leicht über die Gruppenrichtlinien an alle Rechner über die "Richtlinien öffentlicher Schlüssel" verteilen. Dort finden Sie die Punkte "Vertrauenswürdige Stammzertifizierungsstellen" und "Vertrauenswürdige Herausgeber". In beiden muss das Zertifikat hinterlegt werden. Bei der "Code Signatur" reicht es allerdings nicht aus, dem Aussteller (Certificate Authority, CA) eines Zertifikats zu vertrauen, wie etwa bei der Server-Authentifizierung. Bei Dateisignaturen, Makros oder Software muss der "End Entity" vertraut werden, also direkt dem Unterzeichner.

Die Logik dahinter ist, dass ein IT-Verantwortlicher nicht jedem Entwickler vertrauen möchte, der sich für 29 Euro ein Zertifikat gekauft hat, nur weil er dem Verkäufer beziehungsweise Aussteller des Zertifikats grundsätzlich vertraut. Im Vordergrund steht das Vertrauen gegenüber dem Unterzeichner. Nun müssen Sie noch eine weitere Richtlinie aktivieren: "Computer Configuration / Administrative Templates / Windows-Komponenten / Windows Update / Signierte Updates aus einem Intranetspeicherort für Microsoft-Updatedienste zulassen". Diese bringt den WSUS-Update-Agent dazu, ein Zertifikat zu akzeptieren, das nicht von Microsoft stammt.

Ab diesen Zeitpunkt verhält sich jedes Softwarepaket, das Sie über den WSUS Package Publisher verwalten, wie ein Windows-Update. Die komplette Infrastruktur mit dem "Background Intelligent Transfer System" (BITS) oder der Übermittlungsoptimierung kommt zum Einsatz. Sie können ein Software-Paket für eine Computergruppe freigeben, es zurückziehen oder zu einem bestimmten Zeitpunkt erzwingen. WSUS unterscheidet nicht in der Funktionalität zwischen eigenen und fremden Updates. Die Drittanbieterpakete können in die WSUS-Datenbank eingetragen werden, dann sind sie nicht nur in der WSUS-Package-Publisher-Oberfläche vorhanden, sondern auch in der WSUS-Konsole mit allen Reporting-Funktionen und Übersichten, die aus WSUS bekannt sind.

Pakete integrieren

Der WSUS Package Publisher kann jede Art von Software in WSUS integrieren, wobei natürlich MSI-Pakete die einfachste Variante darstellen. MSI ist von Microsoft bereits auf ein zentrales Deployment ausgelegt worden. Die Intelligenz, die sonst in "setup.exe" stecken musste, ist im MSI-Client auf dem System verankert. Des Weiteren lassen sich Setup-Executables integrieren und um weitere Commandline-Schalter ergänzen, sofern sie von dem Binary unterstützt werden. Auch Aufrufe von Skripten sind möglich.

Bei einem MSI-Paket werden die Informationen über den Hersteller und das Produkt aus dem Paket ausgelesen, soweit sie der Hersteller bereitgestellt hat. Nachfolgend kommt es nun zu den beiden wichtigsten Fragen im Deployment: Woran erkennt der Rechner, dass die Software schon existiert, und warum kann er die Software installieren? Die Frage, ob ein Produkt schon installiert ist, wird bei einem MSI-Paket automatisch beantwortet, denn jedes MSI-Paket bringt eine GUID mit, die der WSUS Package Publisher abfragt. Hier ist kein weiterer Handgriff notwendig. Bei anderen Produkten kann es aufwendiger werden und die Antwort auf die Frage, ob eine Software schon installiert ist, muss selbst gefunden werden. Der WSUS Package Publisher bietet hier ein ausführliches Regelwerk von Dateiabfragen, Ordnerexistenz, aber auch Registry- und WMI-Abfragen.

Ziele definieren

Die Antwort der Frage nach den Zielrechnern ist schwieriger. Es gibt viele Möglichkeiten – die einfachste besteht darin, dass Sie im WSUS Package Publisher nur per Regeln bestimmen, ob eine Software installierbar ist, und den WSUS-Server samt seiner Gruppen für die Zielauswahl nutzen. Haben Sie in der ersten Frage, anhand derer der Update-Agent erkennt, ob die Software bereits installiert ist, die Dateiversion mit Pfad hinterlegt, kann diese Regel in der zweiten Fragen umgedreht werden und die Logik sagt: Die Software ist installierbar, wenn die Daten NICHT existieren. Hier können weitere Regeln mit "größer gleich" oder "kleiner gleich" das Regelwerk noch granularer herunterbrechen.

Jede integrierte Software muss im WSUS für eine Computergruppe freigegeben werden. Computer können auch bei WSUS Mitglied in mehr als einer Gruppe sein. Wir empfehlen hier die Gruppierung über die WSUS-Konsole anstatt der Definition der Gruppe über die Gruppenrichtlinien. So integrieren wir pro Paket, Software und Version eine eigene Gruppe im WSUS und genehmigen das Update nur auf dieser produktspezifischen Gruppe. Danach müssen nur noch die Computer in die jeweiligen Softwaregruppen organisiert werden. Denkbar sind auch passende Ordnerstrukturen mit Sammlungen für alle Clients und Ähnliches.

Die Drittanbietersoftware verhält sich wie jedes andere Windows Update, sie wird in der Liste des Update-Verlaufs angezeigt und steht hinterher wie gewohnt in der Liste der installierten Programme. Über die WSUS-Package-Publisher-Konsole erhalten Sie zusätzliche Möglichkeiten, um die Software und auch den Client zu konfigurieren, etwa Software auf Paketebene ablehnen oder freigeben. Das Paket kann zudem bei einem Wechsel des Zertifikats neu zertifiziert werden, damit es mit der neuen digitalen Signatur unterschrieben wird. Ebenso entscheiden Sie hier, ob die Software in der WSUS-Konsole als Update auftaucht oder nicht. Der Grund, es nicht erscheinen zu lassen, kann politisch oder technisch begründet sein, je nachdem, welche Person im Unternehmen den WSUS und wer den WSUS Package Publisher betreut.

Die Konsole des WSUS Package Publisher erlaubt ferner den Zugriff auf die Clients über RPC – vorausgesetzt, das Konto, mit dem der WSUS Package Publisher gestartet wird, besitzt administrative Rechte auf dem Ziel. So stoßen Sie aus der Konsole heraus etwa die Suche nach einem Update an und installieren dieses bei Bedarf direkt. Ein Neustart der Maschine ist ebenso möglich wie ein Zugriff auf die Windows-Update-Logdateien, allerdings hier nur auf das alte "WindowsUpdate.log" von Windows 7. Das neue ETW-Format in Windows 10 müssen Sie zunächst am Client über das PowerShell-Cmdlet "Get-WindowsUpdateLog" in das Text-Logfile konvertieren [3].

Jede im WSUS registrierte Maschine erscheint auch in der WSUS-Package-Publisher-Konsole mit allen Informationen darüber, welche Pakte dort aus dem WSUS Package Publisher installiert wurden. Notwendige grundsätzliche Statusinformationen stehen dort ebenfalls zur Verfügung. Die Anzeige kann auf eingeschaltete Systeme reduziert werden, zu erkennen an der grünen IP-Adresse (Status online). Im Infofeld stehen die Namen der Produkte zur Verfügung, die über WSUS verteilt wurden.

Rollout scripten

Eine weitere Stärke des WSUS Package Publisher liegt in den Custom Updates. In diesen definieren Sie skriptähnliche Abläufe, die mehrere Jobs ausführen. Anstatt eine Installation per Skript zu bauen, die etwa vor der Installation bei Bedarf Prozesse beendet und eine Deinstallation durchführt, lässt sich ein solcher Ablauf über die im WSUS Package Publisher integrierte Skriptsprache zusammenklicken. Für Admins stellt dies eine einfach zu nutzende Variante dar, da nicht die komplette Syntax einer Skriptsprache bekannt sein muss oder Befehle erst umständlich zusammengesucht werden müssen.

Die größte Stärke des WSUS Package Publisher liegt aber darin, dass er neben den eigenen Erweiterungen alle Funktionen nutzt, die Microsoft anbietet und die auch andere als hilfreich entdeckt haben. Es gibt die Möglichkeit, Software über einen Katalog automatisch zu integrieren. Dieser Katalog wird vom Hersteller der Software bereitgestellt und beinhaltet sowohl die URLs zum Download der Software als auch das Regelwerk für deren Verteilung. Das Paket muss nur importiert, signiert und freigegeben werden. Adobe hat hier den Reader und Flash Player bereitgestellt, Foxit als PDF-Alternative ist ebenfalls als Katalog zu finden und auch Hardware-nahe Software wie BIOS-Updates von HP oder DELL kann sich über die Herstellerkataloge integrieren.

Suchen Sie im Web einfach mal nach einer Software in Verbindung mit dem Begriff "SCUP Catalog". Des Weiteren findet sich ein Markt an kaufbaren Zusatzkatalogen [2], deren Anbieter sich in den letzten Jahren darum gekümmert haben, bekannte, gebräuchliche Software einzupflegen. Die Kombination, auf der einen Seite für die bekanntesten Drittanbieter fertige Kataloge zu nutzen, damit sich der eigene Arbeitsaufwand reduziert, aber es dennoch individualisierbar durch eigene Entwicklung zu gestalten, bildet ein sehr interessantes Paket. Die Diskussion dreht sich immer um die Zeit und die Kosten. Führen Sie alles selbst durch, dann kostet es nur Zeit, die an anderer Stelle fehlt. Kaufen Sie eine Leistung ein, müssen Sie überlegen, wie viel Zeit diese spart und ob die Funktion vielleicht nicht besser mit einer eigenen IT-Stelle ausgefüllt werden kann.

PowerShell bleibt außen vor

Als Wermutstropfen bleibt, dass dem WSUS Package Publisher einige Auswertungs- und Automatisierungstechniken fehlen. Er ist beispielsweise nicht via PowerShell nutzbar. Auch arbeitet das Tool nicht als "Echtzeit-System", was jedoch dem WSUS geschuldet ist, nicht dem WSUS Package Publisher selbst. WSUS ist nämlich auf das Reporting der Clients angewiesen, das per Default nur alle 22 Stunden stattfindet. Wobei dieses Problem in der Praxis nicht ganz so gravierend ausfällt, denn Live-Daten benötigt nur der Admin, der gerade etwas testet. Im Betrieb ist es meist egal, ob Software sofort oder erst morgen ankommt.

Keine Blöße gibt sich der WSUS Package Publisher aus Sicht des Infrastruktureinflusses, den er erzeugt, denn dieser tendiert gegen null. WSUS und Windows Update sind längst etablierte Techniken. Der WSUS Package Publisher ändert nichts an den bestehenden Mechanismen und Strukturen, sondern erweitert nur deren Möglichkeiten.

WSUS lässt sich derweil über HTTPS betreiben und somit auch Heimarbeitsplätze und VPN-Clients beliefern. Die Angst von Administratoren, ihren WSUS-Server zu publizieren, ist unbegründet, denn die Updates stehen nur den Clients zur Verfügung, die in Gruppen sortiert und über die Konsole kontrolliert sind. Zudem sollten Sie bedenken, dass Windows 10 in der Default-Konfiguration in einem weltweiten P2P-Netzwerk steht, wenn es um Windows-Updates geht. Ab Windows 10 kann der Windows-Update-Dienst nämlich ein Peer-to-Peer-Netzwerk auf AD-Standortebene realisieren. Das Verhalten lässt sich über die Einstellung "DownloadModus" unter "Computerkonfiguration / Administrative Vorlagen / Windows Komponenten / Übermittlungsoptimierung" anpassen. Quality-of-Service-Einstellungen in dem Pfad runden die Konfigurationen ab. Ob also der Client nun Updates in Peer-to-Peer-Manier an alle Rechner in der Welt liefert oder WSUS selbst, ist hier nur ein kleiner Punkt auf der Liste. Es bleibt der Vorteil des WSUS Package Publisher, dass all diese Infrastrukturthemen nicht zusätzlich mit einer weiteren Software-Deployment-Lösung nachgebaut werden.

Altbackene Oberfläche

Das Einzige, was der WSUS Package Publisher sich an Kritik vorwerfen lassen muss, ist dessen Oberfläche, die eher dem funktionalem Anspruch gerecht wird als dem Auge und der Usability. Perfekt gelungen ist dagegen die Lokalisierung des Produkts auf Deutsch und anderen Sprachen. Hier ist die deutsche Community zu loben, in der sich MVPs wie Winfried Sonntag und Norbert Fehlauer sehr intensiv mit dem Produkt in Bezug auf Funktionalität und Sprache engagiert haben. Einige der Funktionen im WSUS Package Publisher waren Wünsche aus der Community und wurden direkt umgesetzt.

Es gibt Support in Form eines Forums und der Webseite, hier ist eine kaufbare Software sicherlich besser aufgestellt. Aber ob für das Tool überhaupt Support nötig ist, steht auf einem anderen Blatt. Die meisten Fehler treten eher im Windows-Update-Bereich auf.

Fazit

Für den Einsatz des WSUS Package Publisher in KMUs können wir eine klare Empfehlung aussprechen. Doch fehlt dem Tool die Möglichkeit des Operating System Deployments. Das unterstützt nämlich WSUS in dieser Form nicht. Hier bietet sich Freeware wie das Microsoft Deployment Toolkit an. Produktsuiten wie Microsoft System Center bieten für größere Umgebungen vielleicht die interessanteren Methoden. Am Ende bleibt das Deployment eine Jobbeschreibung; sie ist immer zeit- und kostenintensiv. Wer seine Werkzeuge mag, der wird sich immer mehr und besser darum kümmern als eine Person, die das nebenbei machen muss.

 (dr)

Aus dem IT-Administrator Magazin Ausgabe 1/2018: Softwareverteilung & Patchmanagement Seite 72-75

Link-Codes

[1] WSUS Package Publisher: https://wsuspackagepublisher.codeplex.com/

[2] Patch-Kataloge: https://patchmypc.net/third-party-patch-management-scup-catalog/

[3] ETW-Format in Text-Logfiles umwandeln: http://go.microsoft.com/fwlink/?LinkId=518345/