Desired State Configuration (DSC) und Windows Server 2016 – Teil 2: VMs im Hyper-V, Partielle Konfigurationen und ein Web Pull Server | Hyper-V Server Blog

Desired State Configuration (DSC) und Windows Server 2016 – Teil 2: VMs im Hyper-V, Partielle Konfigurationen und ein Web Pull Server

Im Teil 1 meiner Artikelserie habe ich ein paar grundlegende Ideen und Vorgehensweisen der Desired State Configuration (DSC) beschrieben. Heute möchte ich ein Szenario vorstellen, wie man in einer Lab-Umgebung mit DSC virtuelle Maschinen (VMs) im Hyper-V erzeugen und konfigurieren kann.

Die Lab Systemumgebung

Als physische Basis und Entwicklungsumgebung meiner virtuellen Lab Umgebung verwende ich eine Workstation, auf der ein deutsches Windows 10 Pro in der aktuellen Version 1607 läuft und das immer mit allen Patches aktuell gehalten wird. Alternativ kann natürlich auch Windows 10 Enterprise oder Windows Server 2016 verwendet werden. Windows 10 Home Edition scheidet aus, da für unser Projekt die Hyper-V Komponente benötigt wird, die ja in den Home Editionen nicht enthalten ist.

Die Physik

  • i7 Prozessor
  • 32 GB RAM
  • Windows 10 Boot aus VHDX (= Laufwerk C:) mit aktiver Hyper-V Komponente
  • Festplatte D: enthält Projektverzeichnis D:/DSC-Lab. In diesem Verzeichnis werden wir die DSC Konfigurationsskripte ablegen und ggf. in separaten Unterverzeichnissen zusätzliche Daten für die jeweiligen VMs.
  • SSD-Laufwerk E: enthält Verzeichnis E:/Hyper-V, in dem die erzeugten VMs landen. Für jede VM wird darunter ein eigenes Verzeichnis mit dem Namen der VM angelegt, das dann alle Daten der VM enthält (Hyper-V Definitionen und virtuelle Laufwerke).

Skripte zum Downloaden

In diesem Artikel finden Sie viele Code Schnipsel aus Powershell Skripten. Wenn Sie die gezeigten Beispiele auf Ihrem eigenen Rechner nachvollziehen wollen, empfehle ich Ihnen, die Skript-Sammlung auf Ihr System herunterzuladen und in das Verzeichnis D:/DSC-Lab zu extrahieren.

Anmerkung: Die .ZIP-Datei enthält auch bereits die Skripte vom Teil 3 mit einem Pull Client.

Die Hyper-V Umgebung

Im Hyper-V habe ich bereits einen Switch für ein internes virtuelles Netzwerk mit dem Namen NatSwitch80 angelegt. Dieses virtuelle Netzwerk werden wir als Management Netz für unsere VMs verwenden. Damit die mit diesem Netz verbundenen VMs auch Zugriff haben ins Internet, ist für dieses Netz zusätzlich ein NAT-Objekt im Hyper-V Host angelegt. Der IP-Bereich des Netzes ist 192.168.80.0/24, wobei über das NAT-Objekt die Adresse 192.168.80.1 als Gateway in die weite Welt definiert ist. Details über die NAT-Funktionalität von internen Hyper-V Netzwerken finden Sie in einem früheren Blogpost von mir. Hier nur nochmals kurz das Powershell Skript zum Anlegen dieses NAT-Switch – Achtung: Mit Administratorrechten ausführen!:

Betriebssystem Images für die VMs

Wir werden unsere virtuellen Maschinen aus einem “jungfräulichen” Betriebssystem Image erzeugen, das wir aus der heruntergeladenen ISO-Datei des Windows Server 2016 in einer .VHDX-Datei generieren. Dabei müssen wir unterscheiden zwischen Images, die alle zu einer bestimmten Server Edition gehörigen Komponenten vollständig enthalten, und Images für den Nano Server. Zunächst wollen wir uns nur mit vollständigen Images befassen. Auf das Thema Images mit dem Nano Server werde ich in einem späteren Artikel eingehen, wenn wir uns mit Szenarien auf Basis von Nano Server beschäftigen werden.

Zum Erstellen einer solchen Image-Datei aus der heruntergeladenen ISO-Datei verwenden wir das Powerhell Skript Convert-WindowsImage.ps1. Es existiert bereits seit Einführung von virtuellen Festplattendateien (Dateien des Typs .VHD bzw. . VHDX) – also seit Windows Vista bzw. Windows Server 2008 – in der Powershell Gallery. Das Skript wurde laufend weiterentwickelt und an die jeweiligen neuen Windows Versionen angepasst. Auf dem Windows Server 2016 Installationsmedium wird dieses Skript nun direkt in der aktuellsten Version bereitgestellt. Es befindet sich im Verzeichnis NanoServer/NanoServerImageGenerator

Startet man zum ersten Mal eine VM aus einem mit Convert-WindowsImage.ps1 erzeugten Image, so wird zunächst der normale Windows Setup ausgeführt. Dabei wird man ein paar Dinge beobachten, die einen automatischen unbeaufsichtigten Start verhindern:

  • Es werden die Lizenzbedingungen angezeigt, die man interaktiv bestätigen muss.
  • Man muss Sprach- und Tastatureinstellungen interaktiv festlegen bzw. zumindest bestätigen.
  • Man muss das initiale Passwort für den lokalen Administrator festlegen.

Abhilfe kann man schaffen, indem man vor dem Erzeugen des Images eine Antwortdatei mit dem Namen Unattend.xml erstellt und diese in das Image einfügt. Das Skript Convert-WindowsImage.ps1 bietet einen Parameter, bei dem man den Pfadnamen der Antwortdatei angeben kann, die in das Image kopiert werden soll.

Eine Antwortdatei für den Windows Setup ermöglicht es zwar, fast alle Einstellungen eines Systems zu konfigurieren. Unser Ziel hier ist es aber, Konfigurationen mit Desired State Configuration (DSC) durchzuführen. Deshalb beschränken wir uns auf eine minimale Antwortdatei, mit der die beschriebenen Setup Stopper automatisch übersprungen werden. Kopieren Sie das folgende XML-Skript in eine Powershell ISE Sitzung, legen Sie ein geeignetes Passwort für den lokalen Administrator fest (Zeile 41) und speichern Sie dann die Datei auf Ihren Entwicklungsrechner (z.B. nach D:/DSC-Lab/Unattend.xml).

Anmerkung: Neben den beschriebenen Setup-Stoppern habe ich in dieser XML-Datei noch ein paar zusätzliche Einstellungen definiert, die einem das Leben in einer Test- und Entwicklungsumgebung erleichtern, wie z.B. Aktivieren der Remote Desktop Funktion einschließlich der passenden Firewall-Regeln sowie das Ausschalten der IE-Härtung. Für eine produktive Umgebung sollten Sie sich genau überlegen, ob Sie diese sicherheitsrelevanten Einstellungen übernehmen wollen.

Um mit Convert-WindowsImage.ps1 ein vollständiges Image mit dem Windows Server 2016 einschließlich der vorstehenden Datei Unattend.xml zu erzeugen, gehen Sie folgendermaßen vor:

  1. Öffnen Sie die ISO-Datei von Windows Server 2016 durch einen Doppelklick im Windows Explorer. Der Inhalt erscheint in einem neuen virtuellen CD/DVD-Laufwerk.
  2. Kopieren Sie den gesamten Inhalt der CD in ein Verzeichnis Ihrer Festplatte, z.B. D:/DSC-Lab/ WS2016
  3. Starten Sie jetzt eine Powershell Konsolen- oder ISE-Sitzung mit Administratorrechten und wechseln Sie in das Verzeichnis NanoServer/NanoServerImageGenerator der Kopie des CD-Inhalts (also z.B. D:/DSC-Lab/WS2016/NanoServer/NanoServerImageGenerator). Dort finden Sie die aktuelle Version des Powershell Skripts Convert-WindowsImage.ps1, mit dessen Hilfe Sie aus einer ISO- bzw. der darin enthaltenen .WIM-Datei ein Betriebssystem Image für VMs im Hyper-V erzeugen können. Die benötigte .WIM-Datei befindet sich im Verzeichnis Sources der CD-Kopie und hat den Namen Install.wim, für unser Beispiel also D:/DSC-Lab/WS2016/Sources/install.wim. Die Datei enthält sowohl die Standard als auch die Datacenter Editions von Windows Server 2016 jeweils mit und ohne Desktop Experience. Wir werden für unsere DSC-Experimente die Windows Server 2016 Datacenter Evaluation (Desktop Experience) verwenden, die in der .WIM-Datei den Index 4 trägt. Das Image werden wir als VHDX-Datei für Gen2 Hyper-V VMs erzeugen und direkt im Verzeichnis für die zu erzeugenden VMs – also E:/Hyper-V – unter dem Namen WS2016_GPT_DCGUI.vhdx ablegen.

Anmerkungen:

  1. Convert-WindowsImage.ps1 ist eigentlich kein “echtes” Powershell Skript, sondern enthält “nur” eine Powershell Funktion. Um diese nutzen zu können, müssen wir das Skript zunächst per Dot Sourcing in den globalen Workspace der Powershell laden und können dann erst die Funktion aufrufen.
  2. Falls Sie anstatt der Datacenter Edition von Windows Server 2016 eine andere Edition verwenden wollen, können Sie den entsprechenden Index mit dem DISM-Befehl ermitteln.

Mit den folgenden Powershell Befehlen erzeugen wir uns nun ein Basisimage für unsere weiteren Experimente, in das wir auch die zuvor erzeugte Datei Unattend.xml einfügen lassen:

Ergebnis: Die Image-Datei steht jetzt unter E:/Hyper-V/WS2016_GPT_DCGUI.vhdx zur Verfügung und wir können sie als Basisimage für VMs verwenden – sowohl als Parent Disk für differenzierende Laufwerke als auch als Quelle einer Kopie.

Einsammeln und Installieren benötigter DSC-Ressourcen

Für unsere DSC-Experimente zum Erzeugen von VMs im Hyper-V und deren Konfiguration benötigen wir eine Reihe von DSC-Ressourcen (Powershell Module), die nicht standardmäßig auf unserem Entwicklungs- und Testsystem vorhanden sind. Wir müssen sie vielmehr zuerst aus dem Internet von verschiedenen Quellen herunterladen und installieren. In der nachstehenden Tabelle habe ich die für diesem Beitrag verwendeten Module mit Versionsnummern und Hinweisen zum Download / Installieren zusammengefasst.

Modul

Version

Quelle

Autor

Installation

Anmerkungen

PSDesiredStateConfiguration


lokal unter C:/Windows/System32/WindowsPowerShell/v1.0/Modules/PSDesiredStateConfiguration

Microsoft

nicht notwendig, da standardmäßig in Windows enthalten

Enthält die grundlegenden DSC-Ressourcen und Cmdlets; sollte in jedes Konfigurationsskript importiert werden

Modul

Version

Quelle

Autor

Installation

Anmerkungen

xHyper-V

3.6.0.0

Powershell Gallery - https://www.powershellgallery.com/packages/xHyper-V/3.6.0.0

PowerShellTeam, Microsoft

Install-Module -Name xHyper-V -RequiredVersion 3.6.0.0 -Force -Verbose

Enthält Ressourcen zum Konfigurieren eines Hyper-V Hosts und zum Erzeugen von VMs

Modul

Version

Quelle

Autor

Installation

Anmerkungen

cHyper-V

3.0.0.0

Powershell Gallery - https://www.powershellgallery.com/packages/cHyper-V/3.0.0.0

PowerShellTeam, Microsoft

Install-Module -Name cHyper-V -RequiredVersion 3.0.0.0 -Force -Verbose

Enthält Ressourcen zum Erzeugen und Konfigurieren von Hyper-V- und VM-Netzwerkkomponenten

Modul

Version

Quelle

Autor

Installation

Anmerkungen

xComputerManagement

1.9.0.0

Powershell Gallery - https://www.powershellgallery.com/packages/xComputerManagement/1.9.0.0

PowerShellTeam, Microsoft

Install-Module -Name xComputerManagement -RequiredVersion 1.9.0.0 -Force -Verbose

Enthält Ressourcen zum Konfigurieren systemspezifischer Eigenschaften wie Computernamen und Domain bzw. Workgroup Mitgliedschaft

Modul

Version

Quelle

Autor

Installation

Anmerkungen

xNetworking

3.1.0.0

Powershell Gallery - https://www.powershellgallery.com/packages/xNetworking/3.1.0.0

PowerShellTeam, Microsoft

Install-Module -Name xNetworking -RequiredVersion 3.1.0.0 -Force -Verbose

Enthält Ressourcen zum Konfigurieren systemspezifischer IP-Eigenschaften wie IP-Adresse, DNS-Serveradresse, Gateway IP-Adresse , usw.

Modul

Version

Quelle

Autor

Installation

Anmerkungen

xPSDesiredStateConfiguration

5.1.0.0

Powershell Gallery - https://www.powershellgallery.com/packages/xPSDesiredStateConfiguration/5.1.0.0

PowerShellTeam, Microsoft

Install-Module -Name xPSDesiredStateConfiguration -RequiredVersion 5.1.0.0 -Force -Verbose

Enthält Ressourcen zum Konfigurieren verschiedener Systemdienste, u.a. zum Erzeugen und Konfigurieren eines DSC Pull Servers

Powershell Skript für den Download der Module:

Zurück zum Inhaltsverzeichnis ...

Ein DSC Konfigurationsskript zum Erzeugen von VMs im Hyper-V

Nachdem wir jetzt alle Voraussetzungen in unserer DSC Lab-Umgebung geschaffen haben, können wir uns daran machen, mit DSC eine VM im Hyper-V zu erzeugen. Laden Sie das nachstehende Konfigurationsskript DSCHyperV_VM0.ps1 aus dem Lab-Verzeichnis D:/DSC-Lab.in eine Powershell ISE Sitzung, die mit Administratorrechten gestartet wurde.

Schauen wir uns die einzelnen Abschnitte dieses Konfigurationsskripts etwas genauer an.

Parameterliste

Das Skript startet mit einer umfangreichen Parameterliste, über die fast alle Einstellungen zum Erzeugen einer VM im Hyper-V vorgegeben werden können, wobei ich für die meisten Parameter bereits Standardeinstellungen vorbelegt habe, die für unsere DSC-Experimente geeignet sind. Hierdurch vereinfacht sich der Aufruf der Konfiguration auf wenige Angaben wie Name der VM oder Pfadname der Datei mit dem Basisimage. Damit wird dann eine virtuelle Maschine auf unserem DSC Entwicklungsrechner (“localhost”) mit diesen Einstellungen erzeugt:

  • Anzahl Prozessoren: 2
  • Dynamischer RAM-Speicher: 512 MB – 16 GB; Start mit 2GB
  • Betriebssystem Disk: Differenzierend zur angegebenen Basisimage Datei
  • Netzwerkadaptername: MGMT (“Management”)
  • verbunden mit virtuellem Switch: NatSwitch80

Natürlich können Sie bei Bedarf die Vorbelegungen der verschiedenen Parameter beim Aufruf des Skripts durch Angabe eigener Werte überschreiben.

Importieren benötigter DSC-Ressourcen

Als erstes binden wir die in der Configuration verwendeten DSC-Ressourcen mit dem Befehl Import-DscResource ein.

Variablendefinitionen

An verschiedenen Stellen in den Ressourcen Blöcken des Skripts benötigen wir mehrfach die gleichen Pfadnamen. Deshalb definieren wir hier an zentraler Stelle Variable dafür, so dass eine spätere Wartung erleichtert wird.

Die Konfiguration im Detail

Innerhalb des Node Blocks werden jetzt die einzelnen Aktionen für das Erzeugen einer VM festgelegt.

Verzeichnisse für die VM erzeugen

Mit Hilfe der File Ressource stellen wir sicher, dass im Verzeichnis für die erzeugten VMs (in unserer Lab-Umgebung E:/Hyper-V) ein Unterverzeichnis für die neue VM existiert einschließlich eines darin enthaltenen Ordners für die virtuellen Laufwerke der VM. Wir erhalten dann also die nebenstehende Verzeichnisstruktur (der Name der VM ist hier DSC-TestVM).

Das Startlaufwerk für die VM erzeugen

Jetzt müssen wir im gerade erzeugten Verzeichnis das Startlaufwerk für die VM in Abhängigkeit des Parameters $OSDiskType erzeugen. Ist der Parameterwert ‘Copy’, können wir mit der DSC Standard-Ressource File eine Kopie des im Parameter $ParentVhdPath angegebenen Betriebssystem-Basisimage erstellen. Ist für $OSDiskType als Wert ‘Differencing’ angegeben, müssen wir auf eine Ressource xVHD aus dem Powershell Modul xHyper-V zurückgreifen. Damit können wir eine differenzierende .VHDX-Datei zum angegebenen Betriebssystem-Basisimage erzeugen. Vorteil: Die ist kleiner als eine Kopie und nimmt nur die Änderungen auf, die im Betrieb der VM entstehen.

Setup Dateien für die VM in das Startlaufwerk kopieren

Mit der im nächsten Ressourcenblock angegebenen Ressource xVHDFile (ebenfalls aus dem Modul xHyper-V) können wir – falls vorhanden – VM-spezifische Konfigurationsdaten in das soeben erstellte Startlaufwerk der VM kopieren. Die Ressource erzeugt intern für die bei VhdPath angegebene VHDX-Datei temporär ein Laufwerk und kopiert anschließend mit Hilfe der File Ressource den Inhalt des als SourcePath angegebenen Verzeichnisses in den DestinationPath, der relativ zur Root des temporären Laufwerks anzugeben ist. Wie solche Konfigurationsdaten strukturiert sein können, werden wir uns später noch anschauen, wenn wir unseren DSC Web Pull Server konfigurieren.

Die VM im Hyper-V erzeugen

Jetzt haben wir alle Informationen und Daten zusammengestellt, um mit Hilfe der xVMHyperV Ressource aus dem Modul xHyper-V eine neue VM anzulegen. Ich verwende bevorzugt Gen2 VMs, da sie flexibler zu handhaben sind, wenn man Änderungen an der ursprünglichen Konfiguration durchführen will (z.B. zusätzliche virtuelle Hardware im laufenden Betrieb hinzufügen).

Vielleicht fragen Sie sich, warum ich die Zeile EnableGuestService = $true auskommentiert habe. Wenn wir in einer nicht-englischen Hyper-V Umgebung diese Ressourcen-Eigenschaft setzen, führt das beim Ausführen der Konfiguration zu einem Abbruchfehler. Hintergrund ist ein Bug (!?) im Ressourcen-Modul. Dort wird der Service hart codiert mit seiner US-englischen Bezeichnung Guest Service Interface angesprochen. In einer deutschen Windows Umgebung hat der Service hingegen z.B. die Bezeichnung Gastdienstschnittstelle, mit der Folge, dass die Ressource den Service nicht findet und einen Fehler ausgibt.

Wenn Sie in einer US-englischen Umgebung arbeiten, können Sie problemlos den Kommentar wegnehmen.

Bei nicht-englischen Betriebssystemen können Sie später den Service über die GUI des Hyper-V Managers aktivieren.

Ich bin mit dem Autor der Ressource Daniel Scott-Raynsford über seine Issue Website bei Github in Kontakt. Eine Korrektur wäre relativ simpel, allerdings mit einer Modifikation des Codes im Ressourcen Modul verbunden, was hier jetzt den Rahmen unserer DSC-Experimente sprengen würde.

Dem Netzwerkadapter der VM einen vernünftigen Namen geben

Eine durchaus vernünftige, für unsere Zwecke aber etwas unschöne Eigenschaft des Hyper-V Powershell Kommandos New-VM – auf dem die DSC-Ressource xVHyperV basiert – ist die Tatsache, dass grundsätzlich ein Netzwerkadapter für die VM erzeugt wird. Der Name dieses Adapters ist leider abhängig von der Sprache der Windows Version. In einer deutschen Hyper-V Umgebung heißt er z.B. Netzwerkkarte, in englischen Versionen Network Adapter. Eine Änderung des Namens wäre über die GUI im Hyper-V Manager möglich und auch in der Powershell gibt es hierfür das Cmdlet Rename-VMNetworkAdapter. Leider habe ich aber keine DSC-Ressource gefunden, mit der dies machbar wäre - eine Herausforderung für Experten, eine entsprechende Ressource selbst zu schreiben. Um in meinen VMs den Namen des Netzwerkadapters in Mgmt umzuändern, werde ich ein bisschen tricksen:

Zunächst entferne ich mit Hilfe der DSC-Ressource cVMNetworkAdapter aus dem Modul cHyper-V die Netzwerkkarten mit den unerwünschten Namen durch die Angabe von Absent bei der Eigenschaft Ensure. Wenn es keine Netzwerkkarte mit dem entsprechenden Namen gibt, ist das kein Problem; die Ressource führt dann eben keine Aktion aus.

Jetzt können wir unserer VM ebenfalls mit cVMNetworkAdapter einen neuen Adapter mit dem gewünschten Namen Mgmt verpassen und diesen mit dem entsprechenden Switch NatSwitch80 verbinden. Und damit dieser Name später auch in der VM genutzt werden kann, setze ich mit Hilfe der Ressource cNetworkAdapterSettings die Eigenschaft DeviceNaming des Netzwerkadapters auf $true. Details zu dieser neuen Eigenschaft von Windows Server 2016 bzw. Windows 10 hat Jan Kappen bereits in einem früheren Blogpost beschrieben. Ich werde später beim Konfigurieren von VMs darauf zurückgreifen.

Ich geb’s ja zu, ein bisschen “von hinten durch die Brust ins Knie”; wenn jemand eine bessere Idee hat, lasst es mich wissen.

Eine erste Test-VM

Jetzt können wir einen ersten Test mit dem vorstehenden DSC-Konfigurationsskript durchführen und eine VM mit dem Namen DSC-TestVM erzeugen Öffnen Sie das Skript in einer Powershell ISE Sitzung, die mit Administratorrechten gestartet wurde und führen Sie folgende Schritte aus:

  1. Wechseln Sie in das DSC-Lab Verzeichnis
  2. Laden Sie das Konfigurationsskript per Dot Sourcing in den globalen Arbeitsbereich der Powershell ISE Sitzung
  3. . ./DSCHyperV_VM0.ps1

  4. Kompilieren Sie das Skript mit folgendem Befehl
  5. DSCHyperV_VM -VMname DSC-TestVM -ParentVhdPath `
    E:/Hyper-V/WS2016_GPT_DCGUI.vhdx -OutputPath ./DSC-TestVM -Verbose

  6. Starten Sie die Konfiguration der VM
  7. Start-DscConfiguration -wait -force -Verbose -Path ./DSC-TestVM

Im Konsolenfenster können wir den Ablauf mitverfolgen. Zum Abschluss sehen wir im Hyper-V Manager, wie eine neue VM erzeugt und gestartet wird.


Zurück zum Inhaltsverzeichnis ...

Bereitstellen VM-spezifischer Konfigurationsdaten am Beispiel eines DSC Web Pull Servers

Schön, jetzt haben wir also eine virtuelle Maschine im Hyper-V am Laufen. Diese beinhaltet aber keine speziellen Funktionen, da sie aus einem “neutralen” Betriebssystemimage erzeugt wurde. Wir müssen uns deshalb eine Vorgehensweise überlegen, wie man sie nach dem ersten Start für spezielle Funktionen konfigurieren kann – natürlich soweit möglich mit DSC. Dazu müssen die notwendigen DSC-Konfigurationsdaten wie Skripte und DSC-Ressourcen irgendwie in die VMs gebracht und dann der Local Configuration Manager (LCM) in der VM veranlasst werden, die Konfiguration abzuarbeiten. Als Beispiel für eine Möglichkeit, dies zu bewerkstelligen, soll die Konfiguration eines DSC Web Pull Servers dienen.

Was ist ein DSC Web Pull Server?

Im Teil 1 meiner DSC-Artikelserie habe ich bereits kurz die beiden Betriebsmodi Push und Pull für DSC beschrieben. Für den Pull Betrieb benötigen wir (mindestens) ein Server System, das die Konfigurationsdaten bereitstellt. Dabei gibt es 2 Varianten: Entweder über eine SMB-Freigabe oder über einen Web Service. Im letzteren Fall sprechen wir von einem DSC Web Pull Server. Auf das Arbeiten mit einem solchen Web Pull Server wil ich hier nicht näher eingehen. Dies wird in einem späteren Beitrag nachgeholt.

Bereitstellen der Konfigurationsdaten

Für meine DSC Lab-Umgebung habe ich folgende Vorgehensweise zum Bereitstellen von Konfigurationsdaten gewählt: Für jede VM wird ein eigenes Unterverzeichnis mit dem Namen der VM im Projektverzeichnis D:/DSC-Lab angelegt und dann in einem weiteren Unterordner eine Verzeichnisstruktur Setup erstellt. Diese enthält die DSC Konfigurationsdaten in exakt der gleichen Form wie sie in der Ziel-VM ausgehend von der Root des Startlaufwerks C: benötigt werden.

Für unseren Web Pull Server DSC-PS01 würde dies wie folgt aussehen:

  • ​Das Verzeichnis D:/DSC-Lab/DSC-PS01 enthält alle Daten für eine VM mit dem Namen DSC-PS01 (unseren DSC Web Pull Server).
  • Das Verzeichnis D:/DSC-Lab/DSC-PS01/Setup stellt die Root des Startlaufwerks C: der VM DSC-PS01 dar.
  • In das Unterverzeichnis D:/DSC-Lab/DSC-PS01/Setup/Program Files/WindowsPowerShell/Modules werden alle DSC Ressourcen Module kopiert, die für die DSC-Konfiguration der VM notwendig sind. Man kann sich diese aus dem Standardverzeichnis für DSC-Ressourcen auf unserem Hyper-V Test- und Entwicklungsrechner - also aus C:/Program Files/WindowsPowerShell/Modules - per Copy-Befehl holen.
  • Im Unterverzeichnis D:/DSC-Lab/DSC-PS01/Setup/Windows/Setup/Scripts wird eine Datei mit dem Namen SetupComplete.cmd abgelegt, über die die DSC-Konfiguration in der VM angestoßen wird. Dies ist eine “klassische” Windows Batch Datei, die vom Windows Setup automatisch zum Abschluss einer erfolgreichen Installation – also noch vor der ersten Login Möglichkeit – aufgerufen wird. Es ist der ideale Zeitpunkt, um die DSC-Konfiguration einer neu erzeugten VM anzustoßen. Dazu rufen wir ein Powershell Skript RunDSC.ps1 aus dem DSC-Verzeichnis der VM auf, das dann die eigentliche DSC-Konfiguration ausführt:

@echo off
PowerShell.exe -ExecutionPolicy RemoteSigned -File C:/DSCRunDSC.ps1
exit

  • Das Unterverzeichnis D:/DSC-Lab/DSC-PS01/Setup/DSC enthält alle Skripte und Daten, die für die DSC-Konfiguration der VM erforderlich sind. Für unseren Web Pull Server DSC-PS01 habe ich die folgenden Dateien hinterlegt, auf deren Inhalt ich gleich zu sprechen komme.

Ich habe mir Powershell Skripte geschrieben, die diese Verzeichnis- und Dateistrukturen für eine VM erzeugen. Ein Beispiel für unseren Web Pull Server DSC-PS01 finden Sie in der zum Download angebotenen Datei DSC-Lab.zip unter dem Namen New-DSC-PS01_SetupFiles.ps1. Ich will hier nicht näher auf dieses Skript eingehen, sondern nur die Inhalte der damit erzeugten Dateien etwas genauer betrachten. Hält man sich an die hier beschriebene Vorgehensweise zum Bereitstellen von Konfigurationsdaten, so kann man dieses Skript New-DSC-PS01_SetupFiles.ps1 als Vorlage auch für andere VMs verwenden. Die einzelnen Abschnitte muss man dann natürlich an die Anforderungen der VM anpassen.

Existiert beim Erzeugen einer VM mit dem im vorherigen Kapitel beschriebenen Konfigurationsskript DscHyperV_VM eine solche Setup-Struktur mit Konfigurationsdaten, wird diese mit der Ressource xVhdFile in die Root des Startlaufwerks der VM kopiert (Zeile 103-114).

Zurück zum Inhaltsverzeichnis ...

Die Konfiguration unseres DSC Web Pull Servers DSC-PS01 mit partiellen Konfigurationen

Im Teil 1 meiner DSC-Artikelserie habe ich das Thema Partielle Konfigurationen bereits kurz angeschnitten. Am Beispiel unseres Web Pull Servers will ich dies nun etwas genauer beleuchten.

Wenn wir eine neue VM erzeugt haben, müssen wir sie noch konfigurieren. Typischerweise sind dabei zumindest folgende Aktionen notwendig.

  • Wir müssen das Betriebssystem konfigurieren, also z.B. IP-Adressen zuweisen und dem Betriebssystem in der VM einen vernünftigen Computernamen geben. Ich will diesen Schritt hier als OSconfig bezeichnen.
  • Wir müssen die in der VM benötigten Anwendungskomponenten installieren und konfigurieren. Diesen Schritt will ich hier mit APPconfig bezeichnen. Die durchzuführenden Aktionen sind natürlich abhängig von den Funktionalitäten, die in der VM verfügbar sein sollen. Für einen DSC Web Pull Server müssen wir dazu die Windows Komponenten DSC Service und IIS sowie eine Web Service Anwendung - den DSC Web Pull Server - installieren und konfigurieren.
  • Dann müssen wir noch den Local Configuration Manager (LCM) in der VM konfigurieren und ihm die notwendigen partiellen Konfigurationsschritte bekannt machen. Ich will dies hier als LCMconfig bezeichnen.

In der Praxis bietet es sich an, für jede der Aktionen ein eigenes Konfigurationsskript zu erstellen.

Die Betriebssystemkonfiguration (OSconfig)

Beginnen wir mit der Betriebssystemkonfiguration. Dazu habe ich ein Konfigurationsskript OSconfig.ps1 sowie eine Powershell Datendatei OSconfig-data.psd1 erstellt. Beide Dateien liegen im Verzeichnis C:/DSC unserer VM:

:OSconfig.ps1:

Zum Festlegen der IP-Konfiguration der VM verwenden wir 3 Resourcen aus dem xNetworking Modul :

  • xIPAddress: Legt die IP-Adresse des bei InterfaceAlias angegebenen Netzwerkadapters fest. InterfaceAlias ist der Name des Adapters, wie er in der VM erscheint. Über PrefixLength wird die Netzmaske festgelegt und über AddressFamily legen wir fest, ob es sich um eine IPv4 oder IPv6 Adresse handelt.
  • xDefaultGateway: Hier wird die IP-Adresse für das Default Gateway festgelegt - in unserem Beispiel ist dies die Adresse unseres NAT-Switch.
  • xDNSServerAddress: Hiermit werden die IP-Adressen unserer DNS-Server festgelegt. In einem späteren Beitrag werde ich noch auf das Bereitstellen eines DNS-Servers per DSC eingehen. Da dieser Server - er wird die IP-Adresse 192.168.80.10 erhalten - momentan in unserer Lab-Umgebung noch nicht existiert,  definiere ich hier zusätzlich als alternativen DNS-Server meinen Internet Router (192.168.1.1), der dann automatisch verwendet wird, wenn der primäre DNS-Server nicht erreichbar ist.

Zum Festlegen des Computernamens verwenden wir eine Ressource aus dem Modul xComputerManagement:

  • xComputer: Diese Ressource weist dem Betriebssystem in der VM den gewünschten Computernamen zu und kümmert sich dann um den danach notwendig Neustart des Systems.

OSconfig-data.psd1:

Wozu diese Datendatei? Das Konfigurationsskript in OSconfig.ps1 ist neutral und kann in dieser Form für jede VM verwendet werden. Die echten Daten werden beim Kompilieren der Konfiguration in Form einer Powershell Datendatei mit dem Parameter -ConfigurationData übergeben (siehe Zeile 29). Für eine andere VM mit anderen Daten müssen dann nur die Werte in der Datendatei angepasst werden. In der TechNet Library finden Sie weitere Informationen zum Trennen von Konfigurationen und zugehörigen Daten.

Die Anwendungskonfiguration (APPconfig) für unseren Web Pull Server DSC-PS01

Analog zur Betriebssystemkonfiguration bauen wir auch die Anwendungskonfiguration auf: Ein Konfigurationsskript mit dem Namen APPconfig.ps1 und eine Datendatei APPconfig-data.psd1.

APPconfig.ps1:

APPconfig-data.psd1

Um einen DSC Web Pull Server zu konfigurieren, müssen wir zunächst einige Windows Komponenten installieren. Hierzu steht im DSC Standardmodul PSDesiredStateConfiguration eine Ressource WindowsFeature zur Verfügung.

Die Ressource WindowsFeature erwartet den Namen der zu installierenden Windows Komponente als Wert bei der Eigenschaft Name. Doch wie ermittelt man diesen Namen? Geben Sie in einem Powershell Konsolenfenster folgenden Befehl ein:

Get-WindowsFeature

Als Ergebnis erhalten Sie eine lange 3-spaltige Liste mit allen installierbaren Windows Komponenten. Die in der 2. Spalte mit der Überschrift "Name" ausgegebenen Bezeichnungen sind die Werte, die von der Ressource WindowsFeature erwartet werden.

Die erste Komponente, die für einen DSC Web Pull Server installiert werden muss, ist der DSC Service. Die Ressource WindowsFeature sorgt dafür, dass alle weiteren dafür notwendigen Windows Komponenten ebenfalls installiert werden, insbesondere hier der IIS, jedoch ohne die GUI Tools mit dem Namen Web-Mgmt-Tools. Diese installieren wir mit einer weiteren WindowsFeature Instanz. Durch Angabe von 'Present' bei der Eigenschaft Ensure wird die Komponente jeweils installiert, mit der Angabe 'Absent' würde sie deinstalliert werden.

Anmerkung: Die Ressource WindowsFeature kann nur auf Server Betriebssystemen verwendet werden. Sie setzt auf dem Server Manager des Betriebssystem auf, der bei Client Betriebssystemen wie Windows 10 nicht vorhanden ist. Als Alternative steht dort eine Ressource WindowsOptionalFeature mit ähnlicher Funktionalität zur Verfügung.

Nun können wir mit der Ressource xDSCWebService aus dem Modul xPSDesiredStateConfiguration die eigentliche Web Service Anwendung für den Web Pull Server installieren.

Normalerweise sollte die Kommunikation zwischen einem DSC Web Pull Server und den Clients mit SSL verschlüsselt werden. Für unsere Lab-Umgebung verzichten wir darauf, um die Sache nicht zu kompliziert zu gestalten. Deshalb setzen wir die entsprechenden Eigenschaften wie folgt:

  • AcceptSelfSignedCertificates = $false
  • CertificateThumbPrint = "AllowUnencryptedTraffic"
  • UseSecurityBestPractices = $false

Weiterhin verlangt die Ressource, dass wir einen Namen festlegen, unter dem der Web Service erreichbar ist ("Endpoint") und den zugehörigen IP-Port.

Und dann müssen wir natürlich noch die Pfadnamen festlegen, wo die Web Service Anwendung installiert werden soll (PhysicalPath - hier in der Root des IIS) und wo Konfigurationsskripte und DSC-Ressourcen Module abgelegt werden sollen.(ConfigurationPath und ModulePath).

Auch wenn wir bei der Kommunikation mit dem Pull Server auf Verschlüsselung verzichten, so muss sich ein Client trotzdem authentisieren. Der Authentisierungscode besteht aus einer GUID, die in einem RegistrationKeyFile auf dem Web Server hinterlegt ist. Jeder Client, der mit dem Pull Server kommunizieren will, muss diesen Authentisierungscode beim Verbindungsaufbau als "Ticket" vorzeigen. Eine GUID kann man sich in der Powershell mit dem Befehl

New-Guid

erzeugen. Den angezeigten Wert hinterlegen wir in der Datendatei APPconfig-data.psd1 und lassen ihn mit einer Instanz der File Ressource in die angegebene Datei schreiben.

Die Konfiguration des Local Configuration Managers (LCM) für unseren DSC Web Pull Server DSC-PS01

Jetzt fehlt uns noch das Konfigurationsskript für den Local Configuration Manager (LCM) in unserer VM. Es ist in der Datei LCMconfig.ps1 hinterlegt.

Im Ressourcenblock Settings legen wir die globalen Einstellungen für den LCM fest. Konfigurationen müssen im Push-Modus übergeben werden (RefreshMode = 'Push'), dabei ist das überschreiben vorhandener Module erlaubt (AllowModuleOverwrite = $true) und wir arbeiten im Debug-Modus (DebugMode = 'All'). Weiterhin legen wir fest, dass ein automatischer Neustart des Systems erfolgen soll, falls dies notwendig ist - z.B. nach dem Ändern des Computernamens (RebootNodeIfNeeded = $true) und dass danach die Konfiguration fortgesetzt werden soll (ActionAfterReboot = 'ContinueConfiguration'). Dann definieren wir noch die Zeitintervalle, nach denen der LCM jeweils aktiviert wird und dass er im Falle von Konfigurationsänderungen automatisch die ursprüngliche Konfiguration wieder herstellen soll (ConfigurationMode = 'ApplyAndAutoCorrect').

Nach dem Festlegen dieser globalen Einstellungen müssen wir den LCM noch informieren über seine partiellen Konfigurationen. Dies geschieht jeweils mit einem Ressourcenblock PartialConfiguration. Der Name des jeweiligen Blocks muss exakt dem Namen der jeweiligen partiellen Konfiguration entsprechen.

Das Initiieren der DSC-Konfiguration in der VM nach der Windows Installation

Weiter oben habe ich bereits erwähnt, dass wir im Betriebssystem der VM eine Batchdatei SetupComplete.Cmd hinterlegt haben, die vom Windows Setup automatisch als letzte Aktion aufgerufen wird. Aus dieser Batchdatei heraus starten wir die Powershell, um ein Skript RunDSC.ps1 auszuführen.

Dieses Skript führt jetzt die einzelnen Schritte aus zum Initiieren der DSC-Konfiguration in der VM.

  • Mit Set-Location -Path $PSScriptRoot setzen wir das Arbeitsverzeichnis auf unser Skript-Verzeichnis C:/DSC
  • Durch den Aufruf des Skripts Rename-NetAdapterToHyperVDeviceNaming.ps1 - Sie finden es ebenfalls in der Download Library DSC-Lab.zip - werden die Namen der Netzwerkadapter innerhalb der VM (sie heißen normalerweise Ethernet, Ethernet 2, ...) auf die Namen geändert, die im Hyper-V festgelegt sind und für die die Eigenschaft DeviceNaming auf 'On' steht. In unserem Beispiel hat der Netzwerkadapter in der VM nun nicht mehr den Namen Ethernet, sondern heißt jetzt Mgmt.
  • Nun kompilieren wir das Konfigurationsskript für den LCM und übergeben es ihm durch einen Aufruf des Cmdlets Set-DscLocalConfigurationManager. Der LCM wartet jetzt auf die Übergabe der partiellen Konfigurationen.
  • Zunächst wird die Betriebssystemkonfiguration OSconfig.ps1 kompiliert und dem LCM mit Publish-DscConfiguration bekannt gemacht.
  • Analog verfahren wir mit der Anwendungskonfiguration APPconfig.ps1.
  • Der LCM hat nun alle Angaben, um seine Arbeit aufzunehmen, d.h. wir können jetzt mit Start-DscConfiguration die Konfiguration starten. Durch den Parameter -UseExisting weisen wir ihn darauf hin, die zuvor übergebenen partiellen Konfigurationen zu verwenden.

Zurück zum Inhaltsverzeichnis ...

Der DSC Web Pull Server DSC-PS01 entsteht

Jetzt ist endlich der Zeitpunkt gekommen, wo wir unseren DSC Web Pull Server DSC-PS01 als VM im Hyper-V erzeugen können. Nachdem alle Konfigurationsdaten in der zuvor beschriebenen Verzeichnisstruktur abgelegt sind, verwenden wir das eingangs beschriebene Konfigurationsskript DSCHyperV-VM0.ps1 und führen in einer Powershell (ISE) Sitzung folgende Befehle aus (bitte mit Administratorrechten starten!);

  1. Wechseln Sie in das DSC-Lab Verzeichnis
  2. Laden Sie das Konfigurationsskript per Dot Sourcing in den globalen Arbeitsbereich der Powershell ISE Sitzung
  3. . ./DSCHyperV_VM0.ps1

  4. Kompilieren Sie das Skript mit folgendem Befehl
  5. DSCHyperV_VM -VMname DSC-PS01 -ParentVhdPath `
    E:/Hyper-V/WS2016_GPT_DCGUI.vhdx -OutputPath ./DSC-PS01 -Verbose

  6. Starten Sie die Konfiguration der VM
  7. Start-DscConfiguration -wait -force -Verbose -Path ./DSC-PS01

Wir können uns jetzt mit der VM DSC-PS01 über den Hyper-V Manager verbinden und den weiteren Ablauf mitverfolgen.

Start und Konfiguration

Der Windows Setup startet ...

Jetzt wird der LCM im Hintergrund aktiv. Es wird durch das Setzen des neuen Computernamens während der Betriebssystemkonfiguration ein Neustart durchgeführt ..

... und dann können wir uns als Administrator anmelden (das Kennwort haben wir ganz am Anfang in der Unattend.xml festgelegt!).

Im Server Manager können wir das System schon mal inspizieren, während im Hintergrund noch die Anwendungskonfiguration (APPconfig) läuft. Nicht verzweifeln, das kann einige Minuten dauern!

Funktionsprüfung

Starten Sie in der VM den Internet Explorer (oder einen anderen Browser) und geben Sie folgende URL in das Adressfeld ein:

http://localhost:8080/PSDSCPullServer.svc

Wenn dann im Browser-Fenster XML-Code erscheint, der ähnlich aussieht wie in der nebenstehenden Abbildung, dann können Sie davon ausgehen, dass der Web Service mit dem Pull Server korrekt installiert und konfiguriert wurde. Die Bedeutung des XML-Codes soll uns hier nicht weiter interessieren.

Zurück zum Inhaltsverzeichnis ...

Troubleshooting

Wenn Sie den Beschreibungen in diesem Artikel folgen und dabei auch gleich die Skripte aus der angebotenen Download Library DSC-Lab.zip verwenden, sollten Sie eigentlich ohne Probleme die Szenarien nachvollziehen können. Doch was tun, wenn's mal nicht klappt?

Ich will Ihnen hier ein paar Tipps geben, wie Sie Probleme aufdecken können.

Solange wir interaktiv mit DSC Konfigurationsskripten arbeiten und dabei den Parameter -Verbose angeben, sehen wir im Powershell Fenster immer ein ausführliches Protokoll über die von den DSC Ressourcen ausgeführten Aktionen. Bei einem dabei auftretenden Problem werden entsprechende Powershell Fehlermeldungen mit protokolliert. So kann man in den Konfigurationen schon mal mit der Fehlersuche bei den Ressourcen Blöcken beginnen, bei denen der Fehler auftritt.

Spannender wird es, wenn man bei unseren Szenarien feststellt, dass eine DSC Konfiguration in einer erzeugten VM nicht so abläuft, wie man sich das vorgestellt hat. In diesem Fall sieht man interaktiv zunächst nichts, man merkt nur, dass die VM nicht richtig arbeitet.

In einem solchen Fall muss man in der VM selbst die Problemstelle suchen. Dazu gibt es folgende Hilfsmittel:

  • Die Ereignisanzeige (Event Viewer) in der VM
  • Protokolldateien in der VM

Die Ereignisanzeige (Event Viewer) in der VM

Der Local Configuration Manager (LCM) führt einen eigenen Kanal im Windows Ereignisprotokoll. in dem alle Aktionen aufgeführt sind. In der Windows Ereignisanzeige (Event Viewer) findet man dieses Protokoll in der Kategorie Operational unter Application and Services Logs -> Microsoft -> Windows -> Desired State Configuration. Es ist zwar mitunter etwas mühsam, in der Fülle der protokollierten Ereignisse geeignete Hinweise zu finden, aber im Fehlerfall sollte man hier einen Blick hineinwerfen.

Protokolldateien

Neben den Einträgen in der Ereignisanzeige erstellt der LCM auch ausführliche Protokolldateien, deren Inhalt den Ausgaben beim interaktiven Arbeiten entsprechen. Die Dateien werden im Verzeichnis C:/Windows/System32/Configuration/ConfigurationStatus angelegt mit der Namenerweiterung .JSON. Leider bestehen die Dateinamen aus GUIDs, so dass eine Suche damit relativ sinnlos ist. Einfacher wird es, wenn man sie nach Datum / Uhrzeit sortiert.

Die .JSON-Dateien enthalten Text, der mit einem Editor wie Notepad angeschaut werden kann.

Praxistipp für unser Vorgehen

Zum Testen der in diesem Blogpost vorgestellten Skripte hat sich folgendes Vorgehen bewährt: In der problembehafteten VM starte ich eine Powershell ISE Sitzung mit Administratorrechten und lade das Skript RunDSC.ps1, das ja alle für die VM vorgesehenen DSC Aktionen sequentiell aufruft. Nun kann man mit den Debug-Funktionen der Powershell ISE die Problemstelle bei der DSC Konfiguration ermitteln.

Wichtig: Korrigieren Sie Fehler nicht nur in der VM, sondern vor allem auch im Setup-Verzeichnis der VM bzw. im Skript, mit dem Sie die Setup-Verzeichnisstruktur auf Ihrem Test- und Entwicklungsrechner erzeugen (im Beispiel hier New-DSC-PS01_SetupFiles.ps1), damit bei einem erneuten Versuch, die VM zu generieren, Korrekturen dann auch in die neue VM übernommen werden.

Zurück zum Inhaltsverzeichnis ...

Wie geht's weiter?

In diesem Artikel habe ich anhand von ein paar Beispielen eine Vorgehensweise aufgezeigt, wie man DSC in einer eigenen Systemumgebung einsetzen kann. Ich weiteren Beiträgen werde ich mich um die Nutzung des hier installierten Pull Servers durch Pull Clients kümmern und auch einige weitere Einsatzszenarien beschreiben.

Zurück zum Inhaltsverzeichnis ...

Links

Eigene Blogbeiträge:

DSC allgemein:

Zurück zum Inhaltsverzeichnis ...

Gerhard Glenk
 

Diplom Informatiker Gerhard Glenk ist seit über 30 Jahren in der IT-Branche tätig und arbeitet für die Rachfahl IT-Solutions GmbH & Co. KG als freier Mitarbeiter in den Bereichen Cloud Computing mit Microsoft Technologien wie Hyper-V, System Center und Windows Azure Pack.

>