Seit dem Release von Windows Server 2003 hat Microsoft etliche Feature Packs mit zusätzlichen Funktionen herausgegeben. Eines dieser Packs sind die Automated Deployment Services (ADS), mit denen die Installation von Servern und deren Basiskonfiguration optimiert werden kann.
Server werden oft von Hand installiert. Dieser Ansatz stösst aber in Umgebungen an seine Grenzen, in denen viele Server installiert werden müssen. Ein typisches Beispiel sind Web-Server-Farmen, in denen viele einheitlich konfigurierte Systeme eingesetzt werden. Auch Blade-Konzepte gewinnen mehr und mehr an Gewicht. Aber auch bei Umgebungen, in denen weitgehend einheitliche Server für Zweigstellen vorbereitet werden, ist die Installation und Konfiguration von Hand mühsam und umständlich.
Microsoft hat beispielsweise mit der Unterstützung von sogenannten Headless-Servern, also Servern ohne lokale Konsole, und mit dem Application Center einiges getan, um solchen Nutzungsszenarien besser gerecht werden zu können. Im Gegensatz zu Linux und Unix fehlten aber Mechanismen, um Server effizient in einheitlicher Weise aufsetzen zu können. Diese Lücke sollen die ADS schliessen.
Die ADS sind eine Kombination aus Imaging- und Betriebssystem-Deployment-Technologien sowie Scripting-Funktionen. Die Grundlage bilden einerseits Standard-Komponenten des Betriebssystems wie der Windows Scripting Host (WSH) und die WMI (Windows Management Instrumentation) und andererseits bereits beim Windows Server 2003 enthaltene Funktionen für die Softwareverteilung wie sysprep.exe für die Vorbereitung von Images und die RIS (Remote Installation Services) mit dem darin enthaltenen PXE-Server für deren Verteilung. Die ADS unterscheiden sich aber in vielen Punkten von ihren ursprünglichen Einzelteilen und sind auf die spezifischen Anforderungen des Server-Deployments hin optimiert worden. Am deutlichsten wird das an den vielen Befehlszeilenprogrammen.
Auch in der Architektur werden Unterschiede sichtbar. Die Basis für die ADS bildet ein Windows Server 2003. Verteilt werden kann sowohl der Windows 2000 Server als auch der Windows Server 2003. Die zentrale Steuerung erfolgt über den sogenannten Controller Service, der sowohl über die Befehlszeile als auch mit Scripts oder über eine grafische Oberfläche konfiguriert werden kann. Die Konfigurationsdaten und Logs werden in einer SQL-Server-Datenbank gespeichert, wobei allerdings auch mit der MSDE (Microsoft SQL Server Desktop Edition) gearbeitet werden kann.
Der Controller Service steuert den Network Boot Service. Dieser besteht aus einem PXE-Server (Preboot eXecution Environment). Clients können beim Start solche Server suchen und erhalten von diesen automatisch die Betriebssystem-Images. Zusätzlich werden ein TFTP-Server für die Kommunikation im Deployment-Prozess sowie ein DHCP-Server benötigt. Ausserdem gibt es den Deployment Agent Builder, auf dem die Images basieren. Mit dem Network Boot Service wird eine Vorinstallation des Betriebssystems durchgeführt. Über den sogenannten Image Distribution Server erfolgt im nächsten Schritt die eigentliche Verteilung der Images. In dieser Phase ist bereits die Mini-Version des Windows Server 2003 von der Festplatte gestartet worden. Auf den Systemen wird im Rahmen des Imaging ein Administration Agent installiert, über den darauf die weiteren Konfigurationsschritte wie die Einrichtung von Anwendungen gesteuert werden können. Damit können aber auch im laufenden Betrieb Konfigurationsänderungen erfolgen, auch wenn das nicht die vordringliche Zielsetzung der ADS ist.
Es gibt also einen mehrstufigen Verteilungsprozess, in dem zuerst eine Basisversion des Betriebssystems verteilt wird. In diese können auch spezifische Hardwaretreiber etwa für herstellereigene HALs (Hardware Abstraction Layer) und spezielle Storage-Systeme eingebunden werden. Auf diese Basisversion werden dann die definierten Images gespielt, die anschliessend über Scripts weiter konfiguriert werden können. Der Controller Service behält dabei jederzeit den Überblick über den Status der Server.
Für die ADS müssen entweder eine SQL-Server-Instanz vorhanden sein oder die MSDE eingerichtet werden. Anschliessend kann die eigentliche Systeminstallation beginnen, die über ein Standard-Installationsprogramm durchgeführt wird. Die Administrationswerkzeuge lassen sich auch auf Arbeitsstationen einrichten. Der ADS Administration Agent kann ausserdem manuell auf bereits vorhandenen Servern installiert werden, um auch auf diesen ADS-Jobs – also definierte Konfigurationsprozesse – durchführen zu können. Bei der Installation der Network Boot Services ist darauf zu achten, dass es nicht schon einen PXE-Server im Netzwerksegment gibt, da es sonst zu Konflikten kommt.
Für die Verwaltung gibt es zwei grafische Schnittstellen. Mit der Anwendung ADS Management werden der Status der verschiedenen ADS-Dienste überwacht und die Betriebssystemverteilung konfiguriert. Dort werden auch die Jobs erstellt. Das zweite Programm ist der ADS Sequence Editor, mit dem die Konfigurationsabläufe festgelegt werden. Diese Sequenzen können Scripts, Neustarts, die Partitionierung von Disks oder den Download von Dateien umfassen; sie werden in Jobs eingebunden und an die Zielsysteme übergeben, wo sie von den Agenten ausgeführt werden.
Zusätzlich zu diesen beiden Tools gibt es ein gutes Dutzend Befehlszeilenfunktionen, mit denen sich die ADS ebenfalls konfigurieren lassen. Diese sind vor allem bei einer intensiven Nutzung hilfreich, weil damit Konfigurationsschritte automatisiert werden können.
Der erste Schritt der Konfiguration ist die Einrichtung der Network Boot Services. Der beste Ansatz ist dabei die physische Trennung von Netzwerksegmenten mit Servern, die über die ADS verwaltet werden, und denen mit Clients, die über einen anderen PXE-Dienst wie die RIS oder OS-Deployment-Lösungen von Drittanbietern versorgt werden. Da PXE auf DHCP basiert und dieser Dienst über Broadcasts arbeitet, lassen sich getrennte PXE-Infrastrukturen relativ leicht aufbauen. Falls das nicht möglich sein sollte, lassen sich die zu verwaltenden Geräte auch im ADS Manager explizit konfigurieren, wobei die MAC-Adresse oder die GUID (Globally Unique ID) angeben werden muss.
Anschliessend erfolgt die Konfiguration der Images, in die verschiedene Partitionen aufgenommen werden können, also beispielsweise die System-Partition, Datenpartitionen und vorkonfigurierte OEM-Partitionen. Die Basis für das Imaging bildet ein Server, der als Grundlage dient und entsprechend konfiguriert wurde. Darauf dürfen auch schon Anwendungen installiert werden, soweit diese mit sysprep.exe zusammenarbeiten. Das ist aber nicht immer der Fall – Ausnahmen sind etwa die Zertifikatsdienste und Anti-Viren-Tools. Ausserdem muss auf dem System in jedem Fall der Administration Agent installiert sein, damit dieser mit dem Image verteilt wird und die nachfolgenden Konfigurationsprozesse erfolgen können.
Häufig ist es sinnvoll, mehrere Zielsysteme in Gruppen zusammenzufassen, die dann einheitlich konfiguriert werden. Den Devices oder Gruppen werden Jobs zugeordnet, die mit dem ADS Sequence Editor vorbereiten wurden. Hier lässt sich das ganze Funktionsspektrum des Scripting bei Windows-Systemen nutzen, man kann also auch aktuelle Systeminformationen über WMI ermitteln. Das ist von besonderer Bedeutung, weil damit durch Abfragen Konfigurationsschritte in Abhängigkeit von vorhandener Hard- oder Software durchgeführt werden können.
Sequenzen lassen sich beliebig verschachteln, so dass man sich eine ganze Bibliothek aufbauen kann. Die Sequenzen werden in Jobs umgesetzt, wobei solche in einfacheren Fällen auch direkt Scripts oder ADS-Befehle aufrufen können. Die zugeordneten Jobs werden schliesslich über den ADS Manager gestartet respektive an den Agent übergeben.
Mit den ADS lässt sich problemlos eine zentrale Konfiguration von Windows-Servern durchführen. Auch spätere Konfigurationsjobs lassen sich durch die Agents jederzeit anstossen. Für Umgebungen mit vielen einheitlich konfigurierten Servern sind die ADS deshalb ein unverzichtbarer Mechanismus.
