Die DesktopdateienAnpassen der Windows-Bereitstellungsdienste

Wes Miller

Inhalt

Ersetzen des Vorhandenen
Betrachtung des Stapels
Netzwerkstartprogramm
WDS PXE-Anbieter
TFTP-Daemon
Startkonfigurationsdatenspeicher
Windows PE
Transportserver
Benutzerdefinierter Multicast
Zusammenfassung

Drei Monate lang habe ich mich mit den Windows-Bereitstellungsdiensten (Windows Deployment Services, WDS) beschäftigt. Dabei ging es um ihren Ursprung, gefolgt von einem Überblick, gefolgt von einer näheren Betrachtung einiger Themen für Fortgeschrittene wie WDSUtil und Multicasting. In diesem letzten Artikel der Reihe werden wir uns damit befassen, wo und wie Sie WDS anpassen und konfigurieren können, um die Anforderungen Ihrer Organisation zu erfüllen. Die meisten Microsoft-Tools sind für eine gewisse Konfigurierbarkeit ausgelegt. Aber erst wenn es um den tatsächlichen Einsatz geht, werden Sie feststellen, ob die Tools Ihren Anforderungen entsprechen oder ob sie für die Arbeit in Ihren Szenarios optimiert werden müssen, was wahrscheinlich häufiger der Fall ist.

Ersetzen des Vorhandenen

Eine Frage wurde mir von Lesern in letzter Zeit häufig gestellt: „Ich verfüge über x (eine vorhandene Bereitstellungstechnologie). Wird WDS bei mir funktionieren, und sind die Features mit denen von x vergleichbar?“ Aufgrund der veralteten automatisierten Bereitstellungsdienste (Automated Deployment Services, ADS) ist Folgendes von besonderem Interesse: „Wie kann ich eine hochvolumige, schnelle Bereitstellung oder erneute Bereitstellung von Servern durchführen? Erledigt WDS das für mich?“

Obwohl WDS nicht als gleichwertiger Ersatz für ADS geschaffen wurde und einige Hauptkomponenten fehlen, sodass WDS nicht als wirklicher Ersatz betrachtet werden kann, können Sie WDS mit ein wenig Arbeit so anpassen, dass ADS dadurch ersetzt werden kann. Wenn ein Aspekt von WDS für Sie in der vorliegenden Form nicht funktioniert, werden Sie feststellen, dass sich viele Komponenten mit einem unterschiedlichen Grad an Komplexität und technischem Aufwand ersetzen lassen. Im Folgenden wird die Bereitstellung über WDS erläutert. Es werden die Teile untersucht, die Sie möglicherweise anpassen möchten, und Sie erfahren, wie Sie dies tun können.

Betrachtung des Stapels

Abbildung 1 zeigt die Komponenten im WDS-Bereitstellungsprozess. Alle diese Schritte können bis zu einem gewissen Grad angepasst werden. Ich haben die einzelnen Schritte farblich gekennzeichnet, wodurch meiner Meinung nach die Komplexität (und damit die erforderliche Erfahrung im Entwickeln) für das Ersetzen oder Anpassen dargestellt wird. Je dunkler der blaue Farbton ist, desto schwieriger ist das Anpassen des jeweiligen Schritts.

Abbildung 1 Komplexität der Anpassung von WDS

Wie schwierig das Anpassen der einzelnen Schritte tatsächlich ist, hängt selbstverständlich sowohl von den Fähigkeiten Ihres Team (Entwicklung oder Skripting) als auch von Ihrem Verständnis von WDS, Windows Imaging-Format (WIM), Active Directory oder anderen Technologien ab, die Sie integrieren möchten, wie z. B. SQL oder ADSI. Wir wollen alle diese Schritte untersuchen und überlegen, wie sie angepasst werden könnten und welche Methoden Sie dazu verwenden würden.

Netzwerkstartprogramm

Ein benutzerdefiniertes Netzwerkstartprogramm (Network Boot Program, NBP) zum Ersetzen des bei WDS bereitgestellten müssen Sie wahrscheinlich nicht erstellen, aber die Möglichkeit dazu besteht. WDS enthält NBPs zur Verwendung mit kopflosen Systemen (gewöhnlich Server) oder Systemen, bei denen Sie zur Eingabe von F12 und so weiter auffordern können oder nicht. Diese NBPs können entweder mithilfe von WDSUtil in Active Directory vorbereitet werden, oder Sie können Startrom.com durch das NBP ersetzen, das Sie für alle Systeme verwenden möchten, die nicht vorbereitet sind (wenn beispielsweise alle Ihre Systeme kopflos sind oder wenn Sie nie zur Eingabe von F12 auffordern möchten).

Leider gibt es nicht viel Dokumentation zum Erstellen Ihres eigenen NBP (einige Informationen finden Sie unter msdn.microsoft.com/library/bb870970.aspx). Ein NBP ist eine sehr kleine, ausführbare 16-Bit-Datei mit starken Einschränkungen, für die ganz bestimmte Programmierfähigkeiten erforderlich sind. Ich empfehle gewöhnlich die Verwendung der vorhandenen NBPs, es sei denn, Sie versuchen, eine ganz bestimmte Anforderung zu erfüllen und verfügen über ein Entwicklungsteam mit den entsprechenden Fähigkeiten.

WDS PXE-Anbieter

Im Hinblick auf die Remoteinstallationsdienste (Remote Installation Services, RIS) hörten wir von Kunden oft, dass sie lieber einen anderen Datenspeicher als Active Directory für Clientsysteminformationen verwenden würden. Am häufigsten wurde SQL Server genannt. Bei WDS enthält der Entwurf eine austauschbare Infrastruktur für PXE-Anbieter (Pre-Boot eXecution Environment). Dies bedeutet, dass Sie bei der Entwicklungsarbeit einen anderen Sicherungsspeicher neben Active Directory für PXE-Informationen verwenden können.

WDS verfügt über einen eigenen Anbieter, der Active Directory verwendet. System Center Configuration Manager (SCCM) ist jetzt auch mit WDS verknüpft und implementiert einen eigenen Anbieter. Dokumentationen zum Schreiben eines eigenen Anbieters sind kaum vorhanden, und es gibt nicht viel Beispielcode (obwohl das Windows SDK etwas Dokumentation und einige Beispiele bietet). Diese Aufgabe erfordert also einiges. Wenn Sie für diesen Aspekt des Startvorgangs keine sehr spezifischen Anforderungen haben, empfehle ich auch hier wieder, keinen benutzerdefinierten PXE-Anbieter zu schreiben.

TFTP-Daemon

Manchmal haben Kunden in ihren eigenen Trivial File Transfer-Protokoll-Daemon (TFTPD) investiert, bevor es WDS gab. Da PXE-Server nicht gut zusammenarbeiten, bedeutet dies oft, sich für nur einen zu entscheiden.

Meiner Erfahrung nach bedeutet dies zumeist, einen vorhandenen, in der Regel Linux-basierten TFTPD zu verwenden und ihn dazu zu bringen, andere Betriebssysteme zu starten. Mit den ursprünglich verwendeten Infrastruktur-RIS war dies nicht möglich. Aber als der RAMDisk-Start zum Standard wurde, war dies möglich, und es ist mithilfe der WDS-basierten Startabbilder noch immer möglich.

Eines gilt es dabei zu bedenken: Es ist, was Microsoft betrifft, ein technisch nicht unterstützter Bereich, der sicherlich Probleme verursachen kann, die schwierig zu diagnostizieren sind. Außerdem könnte die Leistung nicht so gut sein, zumal der TFTPD in WDS verbessert wurde. Im Idealfall empfehle ich die Verwendung des vorhandenen WDS TFTPD. Versuchen Sie auch, PXE-Timeouts, Pre-Staging und/oder Netzwerkränder zu verwenden, um zu definieren, welche Clients über welchen PXE-Server starten, statt zu versuchen, einen vorhandenen Server anzupassen.

Startkonfigurationsdatenspeicher

Mit RIS war es nie möglich, auf der Startebene anzugeben, was gestartet werden sollte. Sie mussten immer den OS Chooser verwenden und eine Option auswählen (egal, ob es sich um das Setup, Windows PE (Windows Preinstallation Environment) oder etwas ganz anderes handelte). Da WDS ein vollständiges Ladeprogramm für den Netzwerkstart verwendet, wird auch die Anpassung des BCD-Speichers (Boot Configuration Data, Startkonfigurationsdaten), der für Clients bereitgestellt wird, unterstützt. Die Standard-BCD für jede Architektur befinden sich unter RemoteInstall\Boot\<arch>\Default.bcd, wobei <arch> die jeweilige Architektur des Systems ist, das gestartet wird.

Sie können diese BCD für jeden Client anpassen, und der Client verwendet sie zum Starten. Sie könnten beispielsweise einen BCD-Eintrag zum Starten des Setup einrichten, einen anderen zum Ausführen von Windows Recovery Environment (WinRE) und einen weiteren zum Ausführen eines Speichertests. Oder Sie könnten einen vollautomatisierten Setupeintrag als Standard und einen manuellen (oder eine benutzerdefinierte Setupfunktionalität) als vom Benutzer auswählbare Option verwenden. (Weitere Informationen finden Sie in dem Artikel „Bearbeiten des BCD-Speichers mittels Bcdedit“ unter go.microsoft.com/fwlink/?LinkId=115267.)

Der größte Teil der Arbeit von WDS findet natürlich in Windows PE statt. Das Optimieren von Windows PE zum Erfüllen Ihrer Anforderungen kann daher ein Schwerpunkt für ein benutzerdefiniertes Verfahren sein. WDS bietet als Standard eine standardmäßige Vorlage für das Setup, die die vollständige Setupfunktionalität umfasst. Bisweilen funktioniert dies aufgrund der Ihrer Bereitstellungsanforderungen nicht. In diesem Fall können Sie Ihr eigenes Windows PE-Startabbild erstellen. Beginnen wir ganz am Anfang.

Neben der Verwendung der BCD zum Anzeigen, welches Abbild verwendet werden soll, können Sie auch das Abbild angeben, indem Sie das Computerkontoobjekt (Machine Account Object, MAO) für einen Computer in Active Directory anpassen. In RIS speicherte ein bestimmtes MAO-Attribut jedes Element (welche Startrom- und Unattend-Datei (SIF) verwendet werden sollte). Bei WDS sind diese als Name/Wert-Paare unter dem Eintrag „netBootMirrorDataFile“ gespeichert. Das von einem bestimmten Computer zu verwendende Startabbild und die Unattend-Datei sind in diesem Eintrag gespeichert. Die Form der Einträge ist eine durch Semikolons getrennte Liste von Name/Wert-Paaren. Die Einträge zum Ändern des Startabbilds und der Unattend-Datei sind BootImage bzw. UnattendFilePath.

Selbstverständlich könnten Sie die vorhandene Setupfunktionalität ganz entfernen und Ihre eigene erstellen. Vielleicht benötigen Sie mehr Konfigurierbarkeit, mehr Automatisierung oder einen von SQL Server automatisierten Build. Vielleicht möchten Sie es wie anfänglich einige Kunden bei RIS und Windows PE machen und Ihr eigenes Front-End für das Setup erstellen. Bei den Hauptaufgaben, die unabhängig von der Setupfunktionalität durchzuführen sind, handelt es sich um folgende:

• Ausfindigmachen aller computer- oder benutzerspezifischen Informationen. Diese Informationen sind beispielsweise über Benutzereingaben oder SQL Server oder eine Textdatei erhältlich.
• Kopieren und Anwenden eines Setupabbilds auf das Clientsystem. Diese Aufgabe kann durch die direkte Verwendung des Setup durchgeführt werden, wobei ImageX zum Anwenden eines Abbilds aus einer Netzwerkfreigabe oder über Multicast verwendet wird (kopieren Sie einfach das Abbild, und wenden Sie es über ImageX an).
• Stellen Sie eine Unattend-Datei bereit (in Abhängigkeit von der verwendeten Windows-Version beispielsweise Unattend.xml oder sysprep.inf), um das Setup abzuschließen.
• Automatisieren Sie alle Migrationsschritte, die nach dem Setup durchgeführt werden sollen (oder alle Schritte zum Anwenden von Rollen im Fall von Windows Server 2008).

ADS hat das Konzept von Tasksequenzen initiiert, das das Zuweisen wiederholbarer Schritte zu einem oder mehreren Computern ermöglicht. Da ADS nicht zur Verwendung mit Windows XP entworfen wurde bzw. unterstützt wird, konnte es nicht zum Bereitstellen des Betriebssystems verwendet werden. Aber bei ADS-Tasksequenzen handelt es sich im Grunde nur um strukturierte Skripts, und Sie können dieselben Schritte mithilfe eines benutzerdefinierten Installationsvorgangs durchführen.

Ich bin bereits seit einiger Zeit Fan von Microsoft SQL Server (seit der Veröffentlichung von SQL Server 6.5), sodass ich eine solche Struktur instinktiv mithilfe von SQL erstelle. Selbstverständlich müssen Sie dazu Ihrem Windows PE-Build die SQL-Funktionalität hinzufügen. Darüber hinaus könnten Sie Ihre eigene grafische Benutzeroberfläche (eine HTML-Anwendung (HTA) oder eine kompilierte ausführbare Datei) schreiben oder Windows Script Host (WSH) verwenden, um eine minimalistische Setupfunktionalität nur über die Befehlszeile zu ermöglichen. HTA oder WSH müssten Windows PE ebenfalls hinzugefügt werden, damit sie verwendet werden können.

Die Komplexität beim Entwerfen Ihrer eigenen Setupfunktionalität hängt ganz von Ihren Fähigkeiten und Ihrer Vorstellungskraft ab. Ich habe recht elegante Systeme gesehen, die nur mithilfe von SQL und WSH oder HTA definiert wurden – Fähigkeiten, die sich relativ leicht erlernen lassen. Es ist jedoch sehr wichtig, an die Einschränkungen zu denken, die ich in früheren Artikeln erwähnt habe:

• Windows PE verfügt über kein WOW-Subsystem (Windows on Windows), sodass für jede Architektur, die Sie unterstützen möchten, jeweils eine Kompilierung durchgeführt werden muss.
• Sie können Visual Basic 6.0 nicht verwenden, wenn die Bereitstellung über x64 oder IA64 Windows PE erfolgen muss.
• Sie können Visual Studio 2005 oder 2008 verwenden, um Anwendungen zu erstellen, aber Sie müssen eine nicht verwaltete Visual C++-Anwendung erstellen, da unter Windows PE kein Microsoft .NET Framework (egal, um welche Version es sich handelt) unterstützt wird.
• Ohne .NET Framework kann auch Windows PowerShell nicht für die Automatisierung verwendet werden.

Sie können natürlich auch ein Drittanbieterdienstprogramm zum Erstellen von Abbildern über WDS verwenden, wenn Sie bereit sind, Ihre eigene Setupfunktionalität zu schreiben. Obwohl ich der Meinung bin, dass das WIM-Format und ImageX für die meisten Bereitstellungsszenarios ausreichen, könnte es bestimmte Anforderungen geben, die Ihr vorhandenes Abbilderstellungstool für Sie erfüllt.

Ebenso ist für bestimmte Szenarios eine benutzerdefinierte Partitionierung erforderlich. Möglicherweise stellen Sie Windows Vista mit BitLocker bereit, oder Sie erstellen Windows XP-Systeme und speichern Profildaten auf einem zweiten Volume, oder vielleicht stellen Sie ein Windows Server-System bereit und möchten ein separates Volume auf demselben Datenträger für die Protokollierung erstellen. Für alle diese Szenarios ist die Automatisierung von DiskPart erforderlich, die wie in früheren Versionen durch das Hinzufügen eines Skripts (in beliebigem Dateiformat) zu DiskPart erfolgt, das die Befehle enthält, die ausgeführt werden sollen, und mit „exit“ endet, um DiskPart zu beenden.

Das Erstellen einer eigenen Setupfunktionalität ist keine einfache Aufgabe, da Sie im Grunde die Setupdatei neu erstellen (oder zumindest ihre Funktionalität spiegeln), und dabei muss einiges entworfen und erstellt werden. Aber im Prinzip geht es darum, wie viel Funktionalität Sie standardmäßig in Ihren Build aufnehmen möchten und worin er erstellt wird (HTA oder WSH oder eine kompilierte Programmiersprache).

Transportserver

Wenn Sie nicht den größten Teil der standardmäßig im Lieferumfang enthaltenen Funktionen von WDS (wie z. B. Active Directory) verwenden oder Ihre eigene vollständige benutzerdefinierte Lösung erstellen, könnte der Transportserver Ihre Anforderungen erfüllen, ohne unerwünschte Anforderungen zu enthalten. Die Tabelle in Abbildung 2 (entnommen aus dem Artikel „Verwenden des Transportservers“ unter go.microsoft.com/fwlink/?LinkID=115298) zeigt, was als Teil der WDS-Transportserverrolle enthalten ist.

Abbildung 2 Bereitstellungsserver und Transportserver

Wenn ich sage, dass das Implementieren des Transportservers kompliziert ist, meine ich damit nicht, dass die Rolle an sich schwierig ist. Sie lässt sich problemlos bereitstellen (siehe Abbildung 3). Es ist die benutzerdefinierte Setupimplementierung um den Transportserver herum, die aufwändig ist. Bei effektiver Verwendung der Transportserverrolle wird der größte Teil der Benutzerfreundlichkeit entfernt, die in WDS als Rolle integriert ist.

Abbildung 3 Transportserver kann für benutzerdefinierte Bereitstellungsszenarios nützlich sein (zum Vergrößern auf das Bild klicken)

Benutzerdefinierter Multicast

Egal, ob Sie die Transportserverrolle verwenden oder nicht (aber besonders dann, wenn sie verwendet wird), gibt es ein gutes Argument für die Verwendung von Multicast, wenn Sie mehrere Systeme bereitstellen. ADS verfügte über ein sehr leistungsfähiges Multicastfeature, das Sie mithilfe von WDS mit Multicast duplizieren können. WDS verfügt selbst über Multicast, aber wenn Sie Ihre eigene benutzerdefinierte Lösung erstellen, können Sie Multicast mithilfe von WDSMCast nutzen, wie ich im letzten Monat erwähnt habe (siehe Abbildung 4). Wie Sie wissen, müssen Sie die bereitzustellenden Abbilddateien übertragen und dann anwenden. Gewöhnlich bedeutet dies, dass Sie ausreichenden lokalen Speicherplatz für das zu speichernde und dann anzuwendende Abbild benötigen.

Abbildung 4 Ausführen von WDSMCast (zum Vergrößern auf das Bild klicken)

Zusammenfassung

Für sich allein verwendet, ist WDS ziemlich leistungsfähig, was für viele Organisationen zum Erfüllen ihrer Anforderungen wahrscheinlich ausreicht. Wenn Sie aber Ihre eigene Lösung erstellen möchten, die über die Grenzen von WDS hinausgeht, ist dies durchaus möglich. Grenzen ergeben sich allein aus Ihrer Vorstellungskraft, Ihrem Zeitplan und Ihren Fähigkeiten.

Wes Miller ist Senior Technical Product Manager bei CoreTrace (CoreTrace.com) in Austin, Texas. Zuvor war er bei Winternals Software und als Programmmanager bei Microsoft tätig. Sie können Wes Miller unter technet@getwired.com erreichen.