Windows Vista: BDD nutzen

Bei vielen Aufgaben, die sonst manuell ausgeführt werden müssen, bekommt man in dieser Arbeitsumgebung von Assistenten Unterstützung.

Überblick

Auf der Startseite der Workbench wird zunächst ein Überblick über die Funktionen des BDD angeboten. Dort kann man auch auf eine Vielzahl an Dokumenten zugreifen, in denen die Nutzung der Arbeitsumgebung erläutert wird. Allerdings sind bei Weitem nicht alle Tools, die dort aufgeführt werden, direkt in die Workbench eingebunden. Themen wie die User State Migration, also die Übernahme von Benutzerdaten auf ein neues System, oder die Prüfung der Anwendungskompatibilität fehlen hier und müssen gesondert als Teil des BDD eingerichtet und ausgeführt werden. Teilweise sind sie nur unterhalb der Installationsdateien des BDD als Pakete verfügbar, werden aber nicht automatisch mit eingerichtet.

Der Fokus der Workbench liegt klar auf der Verwaltung der Distribution Shares, der Zusammenfassung der Informationen in diesen Freigaben in Builds und deren Bereitstellung für die Verteilung.

Der Bereich Distribution Share

Die eigentliche Nutzung beginnt im Bereich Distribution Share mit vier Unterordnern. Bei Operating Systems finden sich die Betriebssysteme, die für die Verteilung bereitstehen (Bild 1). Sie müssen gegebenenfalls zunächst eingerichtet werden, indem ein Image oder andere Dateien in das Verzeichnis übernommen werden. Darauf wird weiter unten noch eingegangen.

Der zweite Bereich ist Applications. Hier können zusätzliche Anwendungen in Form von Paketen aufgenommen werden. Letztlich entspricht das dem, was im vorangegangenen Artikel zum Thema Daten-Images gesagt wurde, nur dass hier nicht mit Images, sondern mit „normalen“ Softwarepaketen gearbeitet wird.

Bei Packages finden sich wieder .cab-Dateien von Microsoft, mit denen zusätzliche Informationen bereitgestellt werden können. Hier lassen sich also Feature Packs, Language Packs und Updates für das Betriebssystem konfigurieren. Außerdem gibt es noch die Out-of-Box Driver. In diesen Bereich können Treiber, die auf .inf-Dateien basieren, aufgenommen werden.

Konfiguration

Alle Bereiche werden über Assistenten konfiguriert. Man kann also relativ einfach Betriebssysteme, Pakete und andere Daten hinzufügen, um diese anschließend beispielsweise zu einem Build zusammenzufassen.

Dazu wird jeweils der Befehl New aus dem entsprechenden Kontextmenü ausgewählt. Bei den Betriebssystemen stehen drei Optionen zur Verfügung (Bild 2):

• Mit Full set of source files können die Quelldateien von einer Windows-DVD oder einer anderen Quelle übernommen werden. Auf diese Weise kann man also beispielsweise die Standardvarianten von Windows importieren und später für die Verteilung bereitstellen.

• Mit der Option Custom image file kann auf eine WIM-Datei zugegriffen werden. Hier gab es in der aktuellen Beta aber noch Probleme.

• Über die Option Windows Deployment Services images greift man auf die Images zu, die auf einem WDS-Server im Netzwerk liegen. Je nach Option müssen noch zusätzliche Angaben wie der Name des Images oder Servers gemacht werden, von dem der Import erfolgen soll. Anschließend werden die Dateien eingelesen und im Distribution Share bereitgestellt, das ja auf diese Weise verwaltet wird.

Für die Bereitstellung von Anwendungen bietet der Assistent zwei Optionen zur Auswahl an:

• Application with source files richtet eine Anwendung an, bei der die Quelldatei(en) angegeben und in das Distribution Share kopiert werden.

• Application without source files or elsewhere on the network definiert Anwendungen, die entweder keine Quelldateien haben oder sich in einer Freigabe auf dem Netzwerk befinden. In diesem Fall müssen ein Befehl für die Installation und ein Arbeitsverzeichnis für die Durchführung der Installation angegeben werden.

Bei Packages können neue Pakete importiert werden. Hier gibt es keine Besonderheiten zu beachten. Die Pakete müssen als .inf-Datei vorliegen. Dies gilt auch für die Out-of-Box Driver.

Der Bereich Builds

Der nächste Schritt ist die Erstellung von Builds, also zusammenfassenden Versionen für die Verteilung. Jeder Build muss eine eindeutige ID, einen Namen und einen Kommentar haben, wie in Bild 3 gezeigt.

In den folgenden Schritten können die Komponenten ausgewählt werden, die in den Build integriert werden sollen. Dazu zählen das Betriebssystem- Image, Anwendungen, Packages und die Treiber. Falls es keine entsprechenden Komponenten gibt, wird auch keine Auswahl angezeigt.

Daneben müssen spezifische Angaben für die Installation gemacht werden. Dazu gehören folgende Informationen:

• Die Festlegung des Produktschlüssels für die Installation. Es kann in bestimmten Konstellationen auch ohne Produktschlüssel gearbeitet werden.

• Die Definition von Organisation, Name und der Home Page für den Internet Explorer.

• Die Festlegung eines Kennworts für das lokale Konto eines Administrators, soweit dieses nicht während der Einrichtung des Betriebssystems definiert werden soll.

Damit wird das Build erzeugt und kann anschließend genutzt werden. Es können aber auch nachträglich Eigenschaften von Builds angepasst werden (Bild 4) – und hier wird es nun wirklich sehr interessant, weil man eine ganze Menge Einstellungen für die Installation modifizieren kann.

Im Register General finden sich zunächst allgemeine Informationen. Hier können auch die Versionen angepasst werden. Leider gibt es keine automatische Versionierung von Builds, was natürlich wünschenswert wäre, um Veränderungen besser nachvollziehen zu können.

Bei Settings finden sich die Einstellungen, die zu dem Build in den weiteren Dialogfeldern vorgenommen wurden. Im unteren Bereich wird über die Schaltfläche Edit Unattend.xml der System Image Manager zur direkten Bearbeitung der Antwortdatei aufgerufen.

Im Bereich Task Sequence lassen sich schließlich Tasks durchführen, mit denen der gesamte Installationsprozess gesteuert wird (Bild 5). Diese Tasks beginnen bei einer Initialisierung über die Validierung einer möglichen Betriebssysteminstallation, die Sicherung von Daten und die Installation bis hin zu der Phase nach der Installation. Die eigentliche Installation ist also aus Sicht eines Builds nur ein Teilschritt, der in einen größeren Rahmen eingebettet wird.

Alle einzelnen Tasks können über Skripts initialisiert und gesteuert werden. Außerdem kann bei Options auch die Fehlerbehandlung definiert werden, etwa wie bei Fehlern weiter verfahren werden soll. Die Grundstruktur ist bereits vorgegeben, man braucht sie nur noch modifizieren.

Der Bereich Deploy

Der abschließende Bereich ist Deploy. Hier wird festgelegt, wie das Deployment erfolgen soll. Es werden vier grundsätzliche Optionen angeboten:

• Mit Lab or single-server deployment wird definiert, dass die Verteilung auf dem lokalen Server über das vorhandene Distribution Share erfolgt.

• Mit Separate deployment share kann ein anderes System für die Verteilung verwendet werden. Das ist in Umgebungen mit mehreren Servern eine sinnvolle Option.

• Bei Auswahl von Removable media wird das Build so vorbereitet, dass es auf einen Datenträger übernommen werden kann. Die Installation kann dann beispielsweise an anderen Standorten mit schwacher Netzwerkanbindung von diesem Datenträger aus erfolgen.

• Die vierte Option ist SMS 2003 OSD. Damit wird das Build für die Verteilung über die Operating System Deployment-Option des Microsoft Systems Management Server vorbereitet.

Bei der Definition eines Deployments stehen wieder etliche Optionen zur Verfügung. Dazu zählt die Festlegung, ob Benutzer Anwendungen während des Deployments auswählen dürfen, ob ein Image des bisherigen Systems erstellt werden soll und wie mit Administrator-Kennwörtern umgegangen wird. Auch hier ist also wie bei anderen Bereichen des Deployments eine genaue vorherige Planung erforderlich.

Deployment-Einstellungen

Auch bei den Deployments sind zahlreiche Einstellungen möglich. Im Register general finden sich die allgemeinen Festlegungen zu dem Deployment. Dort können auch die unterstützten Plattformen angegeben werden, also die 32- und 64-Bit-Plattformen.

Im Register Rules finden sich die Regeln, die bei der Einrichtung des Deployments definiert wurden. Sie lassen sich, falls gewünscht, hier direkt modifizieren.

Schließlich gibt es noch das Register Windows PE (Bild 6), in dem das Verhalten von Windows PE beim Deployment gesteuert wird.

Im Abschnitt Driver Injectionwerden die Treiber angegeben, die Teil des Deployments sein sollen, auch verschiedene Gruppen von Treibern lassen sich auswählen. Die Treiber sind erforderlich, um eine korrekte Installation auf anderer Hardware durchzuführen, vergrößern aber das Image. Hier ist genau zu überlegen, ob und welche Komponenten eingebunden werden sollen.

Bei Images to Generate geht es dann um die Erstellung der Images. Unterschieden wird generell zwischen dem Ansatz Lite Touch respektive, für den SMS 2003, Zero Touch und Generic. Hier hängt die Auswahl davon ab, welche Form der Installation geplant ist.

Bei Optional Components finden sich aktuell nur ADO (Active Data Objects) und das Windows Recovery Environment. Diese können mit installiert werden, falls das gewünscht ist.

Anpassungen an der Windows PE-Umgebung sind ebenfalls möglich, z.B. eine spezielle Hintergrunddatei, die beispielsweise an das Unternehmen angepasst ist, und ein zusätzliches Verzeichnis, das in die PE-Umgebung aufgenommen werden soll, falls dort bereits zusätzliche Funktionen erforderlich sind.

Fazit

Alles in allem bietet der BDD also viele zusätzliche Funktionen über den Windows System Image Manager hinaus. Benötigt werden beide Werkzeuge – und in der Kombination kann man Deploymentprozesse von Windows Vista doch deutlich einfacher gestalten als bisher.

Einer der folgenden Ausgaben von Expert’s inside Windows NT/2000 wird sich mit dem Zusammenspiel zwischen Images, dem BDD und den WDS (Windows Deployment Services) befassen, das erforderlich ist, um eine vollständige Infrastruktur für die Verteilung des Betriebssystems aufbauen zu können.