Microsoft hat seit dem Release des Windows Servers 2003 etliche Feature-Packs mit zusätzlichen Funktionen veröffentlicht. Eines davon sind die Automated Deployment Services (ADS), mit denen sich die Installation einer größeren Zahl von Windows-Servern wesentlich vereinfachen lässt.
Die treibende Kraft hinter der Entwicklung der ADS (Automated Deployment Services) dürfte bei
Microsoft die Konkurrenz vor allem aus dem Linux-Umfeld gewesen sein. Dort gibt es mit Tools wie
ssh, rdist oder rsh – um nur einige zu nennen – ein beachtliches Portfolio an Lösungen für die
Fernadministration und die automatisierte Konfiguration von Servern.
In Umgebungen, in denen viele Server eingesetzt werden, sind solche Tools unverzichtbar.
Microsoft zielt beispielsweise mit der Webedition des Windows Servers 2003 und einer spezieller
Lizenzierung auf den Markt der Webserver-Farmen. Fast jeder größere Provider in diesem Bereich
bietet auch Windows-basierende Server an. Die Konzepte der Blade-Server und der
Servervirtualisierung führen ebenfalls zu Umgebungen mit vielen Servern. Blade-Server setzen
darauf, mit vielen relativ kleinen Systemen in einem dicht gepackten System zu arbeiten, während
die Virtualisierung eher den Betrieb sehr vieler kleinerer virtueller Maschinen auf einer
leistungsfähigen Hardware zur Folge hat.
Allen diesen Umgebungen ist jedoch gemein, dass sie zu sehr vielen einzelnen physischen oder
virtuellen Systemen führen, die es zu installieren und administrieren gilt. Die Werkzeuge für die
automatisierte Betriebssysteminstallation, die Microsoft bisher im Portfolio hatte, zielen jedoch
auf Clients und nicht auf die spezifischen Anforderungen in Serverumgebungen. Diese Lücke schließen
die ADS, die versuchen, Scripting- und Imaging-Funktionen in optimaler Weise zu kombinieren, um in
relativ kurzer Zeit neue Server aufsetzen zu können. Dabei spielen sowohl die Anpassbarkeit des
Prozesses als auch die Kontrolle darüber eine wichtige Rolle.
Das Konzept der ADS erschließt sich am besten, wenn man die verschiedenen Stufen der
Systemkonfiguration betrachtet. Microsoft unterscheidet drei Phasen. In der "Hardware Configuration
Stage" wird die Systemhardware so konfiguriert, dass sich das Betriebssystem überhaupt erst
installieren lässt. Die Anforderungen sind dabei größer als bei den Clients, da bei der
Serverkonfiguration oft herstellerspezifische Komponenten wie die Treiber für RAID-Controller
einzurichten sind.
Die zweite Stufe ist die "Pre-OS Stage", also die Phase der Systeminstallation, in der das
System soweit konfiguriert wird, dass es geladen werden kann. Dort lassen sich bereits viele
Anpassungen durchführen. Da der Administrator jedoch nicht alle erforderlichen Modifikationen schon
in dieser Phase ausführen kann, gibt es als dritte Phase die "Full-OS Stage", also die
Konfiguration nach der Installation des Betriebssystems. In dieser Phase können weitere
Konfigurationsanpassungen erfolgen. Wichtig: Diese Phase hat kein definiertes Ende. Es ist also
auch möglich, die ADS auch für Änderungen der Systemkonfiguration im laufenden Betrieb zu
nutzen.
Die verschiedenen Aktivitäten sind als Jobs definiert. Die ADS steuern die Ausführung dieser
Jobs. Dadurch ist der Status der Konfiguration für die mit den ADS verwalteten Server jederzeit
erkennbar.
Die Kernkomponenten der ADS finden sich auch bei anderen Windows-Systemen. Es gibt einen
PXE-Server (Preboot Execution Environment), über den sich beim Systemstart Betriebssystem-Images
anfordern lassen. PXE wird mittlerweile von praktisch allen Netzwerkadaptern unterstützt.
Für die Verbreitung der Images gibt es spezielle Tools, deren Basis die Funktionen des RIS
(Remote Installation Services) sind, die es schon seit dem Windows Server 2000 gibt und die für das
Client-Deployment gedacht sind. Bei den ADS sind sie jedoch erweitert und heißen Volume Imaging
Tools. Für die Vorbereitung der Systeme auf das Imaging gibt es außerdem noch Sysprep, das sich in
unveränderter Form nutzen lässt.
Das Scripting erfolgt über die Standardskriptfunktionen, also den WSH (Windows Scripting Host).
Die Funktionen der ADS sind über eine WMI-Schnittstelle erreichbar. Damit ist WMI (Windows
Management Instrumentation) auch für das Scripting nutzbar. Über diese Schnittstelle arbeiten drei
Gruppen von Werkzeugen:
Die grafischen Schnittstellen (siehe weiter unten),
die Befehlszeilenfunktionen, die sehr viele Aktivitäten steuern können und
selbst entwickelte Skripts und Anwendungen, die beispielsweise in VBScript
realisiert sind.
Außerdem ist für PXE ein DHCP-Server nötig. Dieser ist nicht Teil der ADS, Microsoft liefert ihn
jedoch mit dem Windows Server 2003.
Die meisten der genannten Komponenten gehören zum so genannten Controller Service der ADS. Dies
ist die Kernkomponente der ADS, die sich wiederum in zwei funktionale Blöcke gliedert. Der Network
Boot Service (NBS) ist für die Startphase von Systemen im Netzwerk zuständig. Er sorgt für die
PXE-Funktionalität, arbeitet mit DHCP zusammen und enthält darüber hinaus noch einen TFTP-Server,
über den Virtual Floppies und die so genannten Deployment Agents verteilt werden. Der NBS ist also
für die ersten beiden Phasen der Systeminstallation zuständig. Die eigentliche Verteilung der
Images steuert der Image Distribution Service.
Diese Komponente ist damit für die dritte Phase im ADS-Prozess verantwortlich. Neben dem
Betriebssystem-Image wird auch der Administration Agent auf die Zielsysteme verteilt. Mit diesem
kommunizieren die ADS später und veranlassen die Änderungen der Konfiguration. Der Image
Distribution Service verwendet eine Microsoft-SQL-Server-Datenbank, um Jobs und andere
Informationen zu verwalten. Bei den ADS ist es zudem möglich, mit der MSDE (Microsoft SQL Server
Desktop Engine) zu arbeiten.
Die Betriebssysteminstallation und -konfiguration mit den ADS verläuft in mehreren Schritten.
Zunächst ist ein Basisbetriebssystem zu konfigurieren, das als Grundlage für die Images dient.
Dieses System bereitet der Administrator mit sysprep.exe für das Imaging vor. Die Skripts von
sysprep.exe müssen dafür gegebenenfalls noch modifiziert werden. Die Imaging-Tools der ADS bereiten
dann das Image für die Nutzung vor und stellen es bereit.
Damit ist es aber noch nicht getan. Soweit herstellerspezifische Treiber nötig sind, muss das
System Virtual Floppies erstellen, also virtuelle Disketten, die in das Image eingebunden und beim
Deployment mit ausgeführt werden. Bei diesen virtuellen Disketten handelt es sich jeweils um
einzelne Dateien. Ein weiterer vorbereitender Schritt ist die Definition von Jobs für das
Deployment. In diesen Jobs ist festgelegt, wie die Systeminstallation erfolgt. Außerdem kann der
Adminstrator darin spezifische Parameter wie den Rechnernamen und Kennwörter festlegen.
Falls es erforderlich ist, mehrere Server parallel zu installieren, kann der Administrator mit
Multicasts arbeiten. In diesem Fall muss er Deployment-Sequenzen konfigurieren, die mehrere Geräte
mit den jeweils erforderlichen Parametern enthalten. Außerdem müssen die Jobs konfiguriert sein,
die in der Full-OS Stage ablaufen und das System abschließend konfigurieren sollen. Dazu gehört
beispielsweise die Installation zusätzlicher Software, etwa die eines Datenbankservers.
Die Systeme müssen nun über PXE booten, um auf den ADS-Server zugreifen zu können. Dabei ist
sicherzustellen, dass es zu keinen Konflikten mit anderen im Netzwerk vorhandenen PXE-Servern
kommt, die zum Beispiel für die RIS und damit für die Client-Installation eingesetzt werden. Dies
lässt sich am besten über getrennte Netzwerksegmente steuern. Das System bootet nach der
Konfiguration vom Image, und die Konfiguration geschieht abschließend entsprechend der definierten
Jobs.
Der Administration Agent bleibt jedoch auf dem System und kann weiterhin Jobs starten. Die ADS
sind – auch wenn das laut Microsoft nicht das primäre Ziel war – damit nicht nur ein Werkzeug für
die automatisierte Betriebssysteminstallation, sondern auch für die laufende Wartung und
Konfigurationsanpassung von Servern. Letzteres ist vor allem in Serverfarmen wichtig, wenn Jobs in
identischer Weise auf sehr vielen Servern laufen sollen.
Das Feature-Pack muss zunächst von der Microsoft-Website geladen werden. Es findet sich unter
www.microsoft.com/windowsserver2003/downloads/featurepacks/ default.mspx. Die Installation
ist relativ einfach. Die MSDE ist vor der Installation der eigentlichen ADS einzurichten, soweit
das System nicht mit einer vorhandenen SQL-Server-Instanz arbeitet.
Anschließend kann der Administrator die ADS über ein Standardinstallationsprogramm auf einem
Server einrichten. Zusätzlich ist er in der Lage, den Administration Agent auch auf bereits
eingerichteten Servern zu konfigurieren. Diese Systeme lassen sich anschließend auch mit den ADS
verwalten, also neue Jobs dort ausführen.
Die Komponenten kann der Administrator bei der Installation gezielt auswählen, falls er mit
mehreren Servern arbeiten und nur Teilfunktionen auf einzelnen Systemen ablegen will. Außerdem kann
er die administrativen Werkzeuge auf Arbeitsstationen einrichten, um die ADS von dort aus zu
verwalten. Im Rahmen der ADS-Installation ist es zudem erforderlich, auch die Datenbank zu
konfigurieren.
Das wichtigste Verwaltungsprogramm für die ADS ist ADS Management. Diese Konsole liefert
Informationen zum Status der ADS-Dienste. Auch diese Systeme lassen sich konfigurieren. Außerdem
verwaltet der Administrator dort die Job-Templates, also Vorlagen, auf denen die Jobs basieren. Das
zweite grafische Verwaltungsprogramm ist der ADS Sequence Editor. Mit diesem kann der Administrator
Abläufe für die Konfiguration von Zielsystemen definieren. Diese Sequenzen gehen an die Agents auf
den von den ADS verwalteten Systemen über. In den Sequenzen können einerseits spezielle Anweisungen
beispielsweise für das Imaging oder die Partitionierung genutzt werden, andererseits lassen sich
auch Skripts einbinden. Zusätzlich zu diesen beiden Schnittstellen gibt es eine ganze Reihe an
Befehlszeilen-Tools. Bevor man mit den ADS arbeiten kann, sind einige vorbereitende Schritte
erforderlich. Falls sich die PXE-Infrastruktur der ADS nicht von denen der RIS trennen lässt,
müssen die von den ADS verwalteten Geräte explizit über die MAC-Adresse oder die GUID festgelegt
werden. Diese Festlegung von Devices ist in jedem Fall erforderlich, da sie auch später benötigt
wird.
Anschließend gilt es, die Images vorzubereiten. Dabei ist vor allem zu prüfen, inwieweit die
Anwendungen von Sysprep.exe unterstützt werden. Einige Komponenten wie die Zertifikatsdienste oder
Antiviren-Tools lassen sich nur nachträglich installieren. Allerdings ist es nicht immer möglich,
solche Anwendungen eindeutig zu identifizieren, da die Microsoft-Dokumentation dazu eher knapp
gehalten ist. Microsoft verweist zwar auf das Windows-Logo. Es gibt jedoch auch ADS-Komponenten,
die nicht zu sysprep.exe kompatibel sind, sodass diese Kennzeichnung schlicht falsch ist. Daher
sind gründliche Tests der Images und ihres Deployments erforderlich, bevor man eine größere Zahl
von Servern mithilfe der ADS einrichtet.
Der nächste Schritt ist die Konfiguration von Sets. In solchen sind mehrere Devices
zusammengefasst, die der Administrator zuvor definieren muss. Sets können geschachtelt sein, sodass
sie hierarchische Strukturen von Servern abbilden können. Jobs lassen sich auf allen Ebenen
zuordnen. Sets sind also Gruppen von Systemen, die eine einheitliche Konfiguration aufweisen.
In einem nächsten Schritt erstellt der Administrator die Sequenzen und Skripts und fasst diese
in Jobs zusammen. Sequenzen werden mithilfe des Editors erzeugt und können Skripts, Systembefehle
und ADS-Befehle umfassen. Außerdem können auch Sequenzen geschachtelt auftreten, sodass sich
relativ leicht Bibliotheken aufbauen lassen, die zur Erzeugung von Sequenzen dienen. Die Jobs
basieren wiederum auf Vorlagen. In den Vorlagen lassen sich Sequenzen, Skripts und ADS-Befehle
nutzen, sodass in einfacheren Anwendungen keine vorherige Erstellung von Sequenzen erforderlich
ist. Die Jobs sind Sets zugeordnet und stehen danach zur Ausführung bereit. Per Konsole kann der
Administrator sowohl den Status der laufenden Jobs als auch den der ausgeführten Aufträge
ermitteln.
Mit diesen Funktionen sind die ADS ein attraktives Werkzeug, um das Server-Deployment und die
anschließende Konfiguration in Windows-Umgebungen zu standardisieren und zu automatisieren.
Allerdings darf man den Einarbeitungsaufwand nicht unterschätzen.