Linux fürs Windows-Deployment

Man muss kein Securityspezialist sein, um zu merken, dass sich die Release-Zyklen der meisten Programme und Betriebssysteme verkürzen. Neue Versionen schließen Sicherheitslücken, beheben funktionale Fehler oder bauen zusätzliche Funktionen ein. Wer Admin eines Pools von Desktoprechnern ist, hat also Gründe genug, die ihm anvertrauten PCs softwaremäßig frisch zu halten.

Bei Linux-Maschinen ist das recht einfach, da alle Distributionen für PCs eine durchgängige Paketverwaltung besitzen. Windows und Applikationen für dieses Betriebssystem ist dieses Konzept jedoch fremd. Zwar bieten viele Programme automatische Online-Updates an, doch zum einen haben normale Benutzer keine Installationsrechte, zum anderen benötigt es viel Bandbreite, wenn alle Clients gleichzeitig das neue Office-Update aus Amerika herunterladen.

Auch die Konfiguration der Clients ist nicht unproblematisch: Die meisten Programme überfordern normale Anwender mit ihrer Fülle von Einstellungen schnell. Die Vorgaben sind für den Unternehmenseinsatz selten geeignet, sodass der Administrator gut daran tut, seinen Nutzern eine möglichst passende Einstellung vorzugeben. Erscheinungsbild, firmenweite Vorlagen, gemeinsame Verzeichnisse und vorkonfigurierte Konten verbessern den Komfort. Auch Sicherheitsrichtlinien lassen sich auf diesem Weg umsetzen, beispielsweise zentral definierte Zertifikate, das Benutzen von Proxyservern und das Sperren einzelner Funktionen.

SBC oder Deployment

Alle Ziele, also zentral gesteuerte Software-Installation, Patchmanagement und zentrale Konfiguration, lassen sich prinzipiell mit Server-based Computing, sprich dem Einsatz eines Terminalservers, erreichen [1]. Wer diesen Paradigmenwechsel scheut und zudem seinen Serverpark dafür nicht hochrüsten kann oder will, lässt alles wie gehabt und legt sich nur eine zentrale Softwareverteilung (Deployment-Lösung) zu.

Damit hat der Administrator ein mächtiges Werkzeug an der Hand und kann per Knopfdruck Software installieren oder updaten und alle Geräte identisch einrichten. Schulungszentren, die eine dedizierte Arbeitsumgebung für alle Teilnehmer brauchen, Universitäten, die Ausfallzeiten durch mutwillig beschädigte Installationen minimieren wollen, Testlabore, die konkrete Szenarien exakt nachstellen, und Firmen, die viele Rechner verwalten, sparen dadurch Zeit und Geld.

Zweistufige Installation

Dieser Artikel nimmt an, dass Windows als Clientsystem zum Einsatz kommt, weil das in vielen Firmen der Fall und zudem die schwierigere Aufgabe ist. Das Deployment eines Clients erfolgt in zwei Stufen. Zunächst stößt der Admin eine Netzwerk-Installation von Windows mit allen Treibern und Einstellungen an. Auf dem Basissystem ist zudem die Clientkomponente der Softwareverteilung integriert, welche die Installation aller weiteren Anwendungen erledigt. Dabei vergleicht der Dienst eine lokale Datenbank mit der des Servers und ermittelt, was zu installieren oder entfernen ist.

Um zu verhindern, dass sich Benutzer währenddessen anmelden und ein Neustart ihre Sitzung unterbricht, passieren alle Installationen noch während des Windows-Starts, erst danach zeigt sich das Anmeldefenster. In der Praxis hat es sich bewährt, die Verteilung nachts oder am Wochenende per Wake-on-LAN durchzuführen, damit sie den Arbeitsalltag nicht stört.

Jedes Programm muss in Form eines so genannten Installationspakets vorliegen. Es enthält Informationen darüber, mit welchen Parametern das Setup aufzurufen ist. Der eigentliche Vorgang läuft in einem automatischen Modus ab, der so genannten Silent- oder auch Unattended-Installation, bei der der Benutzer keine Eingaben tätigt.

Genau hier liegt das Problem, denn anders als Linux kennt Windows leider kein eindeutiges Paketformat. Zwar gibt es mit den MSI-Dateien für den Windows Installer einen Quasi-Standard, doch längst nicht jedes Programm beachtet ihn. Während unter Linux die nicht interaktive Installation Standard ist, gerät sie bei Windows zur Seltenheit.