Bents Blog

Kurz vor dem Jahresende noch ein Beitrag zu einer geliebten – und absolut nützlichen – Funktion von Windows Server 2008 (R2): die Windows-Bereitstellungsdienste (WDS – Windows Deployment Services), früher Remote Installation Services (RIS). Wer öfter Systeme aufsetzen muss (egal ob Server oder Client), weiß, welche Dinge dafür benötigt werden. Das neu einzurichtende Gerät wird ausgepackt, oftmals im Servicebereich der IT-Abteilung aufgebaut und verkabelt. Danach beginnt erfahrungsgemäß die Suche nach dem passenden Datenträger. Geht man von den aktuellen Betriebssystemen für Server (Windows Server 2008 und R2) und Clients (Windows Vista und Windows 7)  in den jeweiligen Sprachen (Deutsch, Englisch, …), Versionen (Standard, Enterprise, …) und Architekturen (x86 oder x64) aus, so kommt da schnell eine beträchtliche Anzahl zusammen. Doch es geht auch viel eleganter – mit Hilfe der Windows-Bereitstellungsdienste im eigenen Netzwerk.

Voraussetzung

Die Windows-Bereitstellungsdienste (WDS) arbeiten nach dem Client-Server-Prinzip. Der Client fragt den Server und erhält darauf eine Antwort. Das bedeutet allerdings auch, dass der Client eine bestimmte Sprache spricht, in diesem Fall PXE (Preboot Execution Environment), in Kombination mit DHCP (Dynamic Host Configuration Protocol) . Diese Funktion muss in der Netzwerkkarte des Clients integriert sein – bei heutigen Modellen ist dies fast immer der Fall. Ferner benötigt man einen Server mit aktuellem Betriebssystem – in meinem folgenden Beispiel – einen Windows Server 2008 R2. Dieser muss Mitglied einer Domäne (Active Directory) sein, DHCP und DNS muss ebenso verfügbar und funktional sein. Auf dem System selbst wird (abhängig von der Anzahl der Betriebssysteme) entsprechend Festplattenplatz benötigt, doch dazu später mehr. Mit Hilfe des Server-Managers kann man in wenigen Minuten die Rolle „Windows-Bereitstellungsdienste“ installieren:

Konfiguration

Nach der Installation muss der Server noch konfiguriert werden, um auf PXE-Anfragen (Preboot Execution Environment) reagieren zu können:

Möchte man aus Sicherheitsgründen nicht allen Computern im Netzwerk (die via DHCP eine IP-Adresse empfangen haben) per PXE antworten, kann man diese Funktion auf bekannte Computer eingeschränkt werden. Diese Computer müssen dann erst in der Domäne vorab bereitgestellt werden:

Über die MMC Active Directory-Benutzer und -Computer muss das Computer-Objekt manuell erstellt werden und als „Verwalteter Computer“ mit einer eigenen GUID versehen werden. Der WDS-Server behandelt dann dieses Objekt als bekannten Clientcomputer.

Bei der oben ausgewählten Richtlinie antwortet der WDS-Server allen Clients – auch hier kann aber die Sicherheit erhöht werden. So kann bei unbekannten Computern eine Administratorgenehmigung erforderlich gemacht werden, erst wenn dieser den Client akzeptiert, kann der Computer das PXE-Abbild laden.

Soll der installierte Client automatisch einer Domäne hinzugefügt werden, kann über verschiedene Filter der zukünftige Name definiert werden. In meinem Beispiel verwende ich die MAC-Adresse der Netzwerkkarte, da diese eineindeutig ist. Die IP-Adresse des Clients findet man sehr schnell in den Adressleases des DHCP-Servers, welcher als eindeutige ID ebenfalls die MAC-Adresse auflistet. Zum Speicherort des Computerkontos muss ich keine weiteren Worte verlieren, die Optionen sind selbsterklärend.

Achtung: Aufgrund eines Fehlers in einer DLL-Datei des WDS Servers muss vor der Nutzung des %MAC Filters ein Patch von Microsoft eingespielt werden, da sonst für die MAC-Adresse des Clients ein NULL-Wert generiert wird, der zu doppelten Namenseinträgen führen würde.

Im Register „Start“ kann das Verhalten des Clients nach dem PXE-Start definiert werden. Wenn der Client via DHCP eine IP-Adresse erhalten hat, beginnt der PXE-Start. Wird in diesem Fall nicht innerhalb von 3 Sekunden die Taste F12 gedrückt, bootet der Client nach der Reihenfolge seiner BIOS-Einstellungen. Diese Option macht aus meiner Sicht am meisten Sinn, da sonst immer das PXE-Abbild geladen werden würde.

Wer die Funktion benötigt, kann für die jeweilige Architektur die unbeaufsichtigte Installation aktivieren. Dafür wird das Windows Automated Installation Kit (WAIK) benötigt, mit dem die Unattend.xml Datei(en) erzeugt werden können. Den automatischen Beitritt des Computers zu einer Domäne habe ich deaktiviert, da ich diese diverse Kundensysteme nicht erst in unsere eigene Service-Domäne (Installationsumgebung) heben möchte.

Abhängig davon, ob der Server auch ein DHCP-Server ist, darf dieser den Port 67 nicht abhören. In meinem Fall habe ich einen eigenen DHCP-Server im Netz der Service-Domäne – soll der WDS Server auf dem DHCP Server funktionieren, müssen beide Haken gesetzt werden.

Alle weiteren Optionen spare ich mir hier – sie sind sowohl selbsterklärend als auch mehr oder weniger in speziellen Umgebungen nötig, wie beispielsweise die Multicast-Übertragungen zum gleichzeitigen „Betanken“ mehrerer gleichartiger Clients.

Vorbereiten des Servers

Zunächst muss der gewillte Administrator die Installations- und Startabbilder dem WDS-Server hinzufügen.

Das Startabbild findet man auf dem Installationsmedium im Ordner \Sources, die Datei selber heißt Boot.wim. Für jede Architektur (x86 und x64) wird jeweils ein eigenes Startabbild benötigt. Für die Installationsabbilder empfiehlt es sich, vor dem Hinzufügen selbiger, Gruppen zu definieren. Danach kann das jeweilige Abbild (wiederum aus dem Ordner \Sources, Dateiname Install.wim) hinzugefügt werden. Das folgende Bild zeigt alle unterschiedlichen Versionen von Windows 7 und Windows Server 2008 R2 (also Kernel 6.1.x):

Wie zu erkennen, lässt diese Liste einen relativ großen Bedarf an Speicherplatz vermuten – doch weit gefehlt. Der WDS-Server führt bei der Erstellung der Installationsabbilder eine Deduplizierung der Dateien durch, dass heißt: Identische Dateien innerhalb mehrerer Abbilder werden nur einmal gespeichert und dann nur noch intern mittels Zeiger verlinkt. Sehr clever und nützlich, da die obige Liste so gerade einmal 11 GByte Speicherplatz verbraucht.

Damit ist der WDS-Server prinzipiell einsatzbereit. Wer allerdings öfter ähnliche oder gleiche Systeme installieren möchte, kann für diese Systeme notwendige Treiber (Display, Netzwerkkarte, SCSI-Controller etc.) im WDS-Server hinterlegen und via Filter automatisch installieren lassen. Das macht beispielsweise für VMware Clients großen Sinn (die sich genau wie physische Server via WDS installieren lassen), da die Treiber für diese Systeme bei jeder Installation identisch sind. Dazu fügt man die gewünschten Treiber im WDS-Server hinzu:

Die einzelnen Treiberpakete können nun noch in Gruppen eingeordnet werden. Ob ein Treiber auf dem zu installierenden Client aktiviert wird, entscheiden Filter. Diese vergleichen die hinterlegten Werte mit denen des BIOS des Clients – im folgenden Beispiel werden nur die Treiber der Gruppe „VMware Treiber“ installiert, wenn der Client vom Hersteller „VMware, Inc.“ stammt:

WDS im Einsatz

Wie verhält sich nun eine Installation durch einen WDS-Server auf einem jungfräulichen System? Wie schon erwähnt macht der Einsatz eines WDS-Servers nicht nur für physische sondern ebenso für virtuelle Clients im Netzwerk durchaus Sinn. Das folgende Beispiel zeigt aber einen physischen Server von Hewlett-Packard, die Screenshots wurden mit Hilfe der HP Integrated Remote Console gemacht:

Beim Starten des Servers kann man sehr oft via Tastendruck den Bootvorgang vom Netzwerk aktivieren (bei HP immer Taste F12). Danach wird das PXE-BIOS der Netzwerkkarte geladen, die (hier im Beispiel) via DHCP eine IP-Adresse vom DHCP-Server 10.0.0.1/24 empfängt:

Im Bild ist die GUID des Servers rot markiert, die man benötigen würde, wenn nur bekannte Clients vom WDS-Server bedient werden sollen und das Computer-Objekt vorher im Active Directory erstellt werden muss (siehe oben). Im Bild wurde der PXE-Boot abgebrochen, da ich nicht innerhalb 3 Sekunden F12 gedrückt hatte – die Netzwerkkarte startet aber wenige Sekunden später den Vorgang erneut.

Nach dem PXE-Boot präsentiert der WDS-Server (im Beispiel 10.0.0.2/24 ) eine Auswahl der erstellten Startabbilder. Der Client lädt anschließend die hinterlegte Boot.wim der auch eventuell benötigte Treiber (Netzwerkkarte) vom WDS-Server lädt:

Nachdem das Startabbild erfolgreich vom Client geladen wurde wird die Installation des Betriebssystems gestartet, alle folgenden Schritte sind auch von Installationen von DVD bekannt:

Fazit

Die Windows-Bereitstellungsdienste (WDS) bieten die Möglichkeit, im internen Netzwerk, Clients die PXE-fähig sind, schnell und unkompliziert mit einem neuen Betriebssystem zu versehen. Die Suche nach einem passenden Datenträger entfällt, wer die Automatisierung völlig ausreizen mag, kann automatische Antwortdateien für die Installationen definieren, Clients automatisch zur Domäne hinzufügen und mit aktuellen Treibern versehen – ein Rollout à la carte.

Ich hoffe, ich konnte dem einen oder anderen das Thema ein wenig schmackhaft machen bzw. näher beleuchten. Bei Fragen zum Vorgehen oder auftauchenden Problemen nutzt bitte die Kommentar-Funktion. Wie bei allen meinen anderen Beiträgen gilt auch hier wieder: Für Tipps, Vorschläge sowie Fragen oder Kritiken bin ich stets offen.

Einen Blog am Leben zu erhalten kostet Zeit und Geld. Da ich auf meiner Seite weder Werbung einbinde, noch andersweitige Zuwendungen erhalte, freue ich mich über jede kleine Spende. Einfach und unkompliziert geht das über PayPalMe. Du unterstützt damit diesen Blog. Vielen Dank.