Desired State Configuration (DSC) und Windows Server 2016 – Teil 3: Pull Clients | Hyper-V Server Blog

Desired State Configuration (DSC) und Windows Server 2016 – Teil 3: Pull Clients

Im vorangegangenen Teil 2 meiner DSC-Artikelserie habe ich beschrieben, wie man einen DSC Web Pull Server erzeugen und konfigurieren kann. Ich habe Ihnen aber nicht mehr verraten, wie man ein solches System dann bestücken und nutzen kann. Das will ich heute an einem kleinen Beispiel aufzeigen: Wir werden eine VM erzeugen, die sich ihre Einstellung für den Microsoft Update als Pull Client von unserem Pull Server abholt.

Konfigurationsskripte und DSC-Ressourcen erstellen und einsammeln

Als erstes müssen wir natürlich Konfigurationsskripte erstellen. In meinen bisherigen Beispielen habe ich partielle Konfigurationen verwendet, eine zum Konfigurieren des Betriebssystems (OSconfig) und weitere für die Anwendungskomponenten (APPconfig), die auf dem Zielsystem installiet werden sollen.

In meiner DSC-Labumgebung (unter D:/DSC-Lab) habe ich bisher für jedes Zielsystem ein eigenes Unterverzeichnis angelegt, in dem die jeweiligen Konfigurationen abgelegt wurden.

An der Vorgehensweise, wie wir das Betriebssystem konfigurieren, also z.B. Computernamen und IP-Konfiguration setzen, werden wir nichts ändern. OSconfig werden wir weiterhin für jedes System getrennt verwalten und im Push Modus übermitteln und abarbeiten lassen.

Eine Anwendungskonfiguration wie das Aktivieren des Microsoft Updates, die systemunabhängig für viele bzw. alle Systeme gelten soll, ist ein ideales Szenario, um sie über einen DSC Web Pull Server bereitzustellen.

Dazu werden wir die Anwendungskonfigurationen nicht mehr systemspezifisch speichern, sondern direkt im Lab-Verzeichnis D:/DSC-Lab erstellen. In einem eigenen neues Unterverzeichnis PullSetup werden wir dann alles sammeln, was auf den Pull Server bereitgestellt werden soll.

Zu allererst benötigen wir eine DSC-Ressource, mit der wir den Microsoft Update aktivieren können. Wir finden sie unter dem Namen xWindowsUpdate in der Powershell Gallery. Diese Ressource installieren wir wie üblich zunächst auf unserem Entwicklungsrechner.

Nun müssen wir ein für den Microsoft Update passendes Konfigurationsskript erstellen und kompilieren. xWindowsUpdate enthält unter anderem die DSC-Resspurce xWindowsUpdateAgent, mit der man die verschiedenen Einstellungen für den Windows Update setzen kann:

  • IsSingleInstance muss immer mit 'Yes' definiert sein und bedeutet, dass die Ressource in einem Skript nur einmal vorkommen darf.
  • Bei Category geben wir an, welche Arten von Updates berücksichtigt werden sollen. Es müssen nicht alle Kategorien (wie im Beispiel) angegeben werden. Will man z.B. nur die Sicherheitsupdates, genügt die Angabe von 'Security'.
  • Bei Source legen wir fest, woher Updates geladen werden sollen. Mögliche andere Quellen wären 'Windows Update' (Default) oder 'WSUS'.
  • Die Angabe bei Notifications legt fest, wie Updates behandelt werden sollen. 'ScheduledInstallation' ist der Standardwert.
  • Mit UpdateNow können wir festlegen, ob beim Abarbeiten der Konfiguration Updates sofort automatisch gesucht und installiert werden sollen. Mit $false wird dies auf den nächsten regulären Zeitpunkt für den Windows Update zurückgestellt.

Die Konfiguration müssen wir dann kompilieren durch einen Aufruf des Namens.

Durch das Kompilieren wird ein Unterverzeichnis mit dem Namen der Konfiguration erzeugt, das eine .MOF-Datei mit dem Namen des Nodes enthält, in unserem Beispiel also ./EnableMSUpdate/localhost.mof.

​Diese .MOF-Datei (nur diese, nicht die Skriptdatei!) benötigen wir später auf dem Pull Server, d.h. wir kopieren sie in unser Sammelverzeichnis PullSetup. Wichtig dabei ist, der .MOF-Datei einen passenden Namen zu geben, sinnvollerweise <Configuration>.mof. Pull Clients rufen Konfigurationen über deren Namen beim Server ab. Für unser Beispiel werden wir die Datei localhost.mof also beim Kopieren in EnableMSUpdate.mof umbenennen.

Die für das Publizieren einer Konfiguration notwendigen DSC-Ressourcen müssen ebenfalls auf dem Pull Server verfügbar gemacht werden. Wir kopieren deshalb noch die für unser Beispiel benötigte DSC-Resource xWindowsUpdate in das PullSetup-Verzeichnis.

Wir haben für unser Beispiel auf unserem Entwicklungsrechner also jetzt die folgende Verzeichnisstruktur:

Dieses Verzeichnis müssen wir jetzt auf unseren Pull Server kopieren und dort publizieren. Am einfachsten geht das in unserer Lab-Umgebung über eine VM Verbindung im Erweiterten Modus (Enhanced Session) vom lokalen Hyper-V Manager zum Pull Server DSC-PS01. Dort sehen wir sowohl unser DSC-Lab Verzeichnis auf unserem Hyper-V Host als auch das Laufwerk C: des Pull Servers und wir können Dateien hin- und herkopieren.

Tipp: Wenn Sie den Pull Server gemäß meiner Beschreibung im Teil 2 erzeugt haben, gibt es dort ein Verzeichnis C:/DSC, das noch die Daten von der Pull Server Konfiguration enthält. Kopieren Sie das PullSetup-Verzeichnis dorthin.

Zurück zum Inhaltsverzeichnis...​

Konfigurationsskripte und DSC-Ressourcen auf dem Pull Server publizieren

​Beim Installieren des Pull Servers haben wir in der DSC-Konfiguration zwei Pfade festgelegt:

  • ConfigurationPath: In diesem Verzeichnis liegen die .MOF-Dateien der für Clients verfügbaren Konfigurationen; bei unserem DSC-PS01 haben wir dafür festgelegt:
    "C:/Program Files/WindowsPowerShell/DscService/Configuration"
  • ModulePath: Hier müssen die für die Konfigurationen notwendigen DSC-Ressourcen abgelegt werden. Für unseren DSC-PS01 hatten wir festgelegt:
    "C:/Program Files/WindowsPowerShell/DscService/Modules"

Doch halt: Es genügt nicht, zum Publizieren die Skripte und Ressourcen einfach dorthin zu kopieren. Wir müssen sie vielmehr noch ein wenig aufbereiten.

Zurück zum Inhaltsverzeichnis...​

Aufbereiten der MOF-Konfigurationsdateien

Vor dem Kopieren einer MOF-Konfigurationsdatei in den ConfigurationPath müssen wir eine Prüfsummerndatei dafür erzeugen. Der Local Configuration Manager (LCM) kann damit die Konfiguration validieren. Zum Erzeugen einer Prüfsummendatei steht das CmdLet New-DSCChecksum zur Verfügung. Es erwartet als Parameter einen Pfad, in dem die MOF-Dateien liegen. Das CmdLet erzeugt für jede MOF-Datei in diesem Verzeichnis eine Prüfsummendatei mit dem Namen ConfigurationMOFName.mof.checksum, wobei ConfigurationMOFName der Name der Konfiguration ist. Die .MOF- und die zugehörige .checksum-Datei müssen nun zusammen in den ConfigurationPath des Pull Servers kopiert werden.

Wichtig: Wenn wir zu einem späteren Zeitpunkt eine Konfiguration ändern und damit eine neue .MOF-Datei erzeugen, müssen wir auch wieder eine neue .checksum-Datei dafür erzeugen!

Zurück zum Inhaltsverzeichnis...​

Aufbereiten der DSC Ressourcen Module

Jedes Powershell Modul mit DSC-Ressourcen muss in eine .ZIP-Datei mit folgender Namenskonvention gepackt werden: {Modulname}_{Moduleversion}.zip. Dummerweise kann man eine DSC-Ressource, wie man sie mit Install-Module aus der Powershell Gallery heruntergeladen hat, nicht einfach in eine .ZIP-Datei packen, da mit Powershell / WMF 5.0 durch die neu eingeführte Versionsverwaltung die interne Verzeichnisstruktur erweitert wurde. DSC-Ressourcen haben jetzt die Struktur:

'{Module Folder}/{Module Version}/DscResources/{DSC Resource Folder}/'

​wohingegen in der .ZIP-Datei die frühere Struktur

​'{Module Folder}/DscResources/{DSC Resource Folder}/'

(also ohne dem Verzeichnis {Module Version}) erwartet wird.​

Wir müssten also temprorär eine Kopie ohne dem Verzeichnis {Module Version} erzeugen, diese dann packen und den Namen der .ZIP-Datei an die geforderte Namenskonvention anpassen.

Und wie nicht anders zu erwarten, müssen wir auch für die .ZIP-Datei eine Prüfsummendatei erzeugen und dann in das Verzeichnis ModulePath auf dem Pull Server kopieren.

Zurück zum Inhaltsverzeichnis...​

Es geht einfacher...

Etwas mühsam, werden Sie sagen, insbesondere für die Aufbereitung der .ZIP-Dateien. Das müssen sich auch die Entwickler im Powershell Team gedacht haben und liefern mit der DSC-Ressource xPSDesiredStateConfiguration noch gleich ein zusätzliches Modul mit dem Namen PublishModulesAndMofsToPullServer.psm1. Es enthält eine Funktion mit dem Namen Publish-DSCModuleAndMof, die das mühsame Erzeugen der Prüfsummendateien und das Packen der DSC-Ressourcen in .ZIP-Dateien auf einen Funktionsaufruf reduziert und auch gleich die Ergebnisse in den entsprechenden Pfaden auf dem Pull Server publiziert.

Für unser Beispiel zum Aktivieren des Microsoft Updates verbinden Sie sich jetzt mit unserem Pull Server  DSC-PS01 über eine VM-Verbindung aus dem Hyper-V Manager, starten dort eine Powershell-Sitzung mit Administratorrechten, wechseln dort in das Verzeichnis C:/DSC/PullSetup und geben die folgenden Befehle ein:

Import-Module xPSDesiredStateConfiguration
Publish-DSCModuleAndMof -Source . -Force -Verbose

  • Beim Parameter -Source geben Sie das Verzeichnis an, in dem sich die aufzubereitenden Konfigurationen und DSC-Ressourcen befinden (hier das aktuelle Verzeichnis).
  • Durch die Angabe von -Force erzwingen Sie das Überschreiben bereits vorhandener älterer Versionen
  • Und mit -Verbose können Sie ein Protokoll im Konsolenfenster mitlaufen lassen.

Und als Ergebnis finden wir die benötigten Dateien im ModulePath bzw. ConfigurationPath auf dem Pull Server.

Damit stehen die Konfigurationen und Ressourcen auf dem Pull Server zum Abrufen durch Pull Clients bereit.

Zurück zum Inhaltsverzeichnis...​

Ein Pull Client

Wenn wir jetzt die Funktionalität unseres DSC Pull Servers testen wollen, benötigen wir einen DSC Pull Client. Ich erstelle mir dafür eine VM DSC-PC01 mit Windows Server 2016 als Betriebssystem nach der im Teil 2 meiner DSC-Artikel beschriebenen Methode. Ein entsprechendes Powershell Skript New-DSC-PC01_SetupFiles.ps1 zum Erzeugen der Verzeichnisstruktur und der Dateien finden Sie in der zum Download beigefügten .ZIP-Datei.

Im Setup-Verzeichnis dieser VM finden Sie nur noch Skripte zum Konfigurieren des Betriebssystems (OSconfig), des Local Configuration Managers (LCMconfig) sowie zum Initiieren der DSC-Konfiguration (SetupComplete.Cmd und RunDSC.ps1).

Um nun weitere (Anwendungs-) Konfigurationen von unserem Pull Server abzurufen, müssen wir dem Local Configuration Manager (LCM) des Pull Clients entsprechende Informationen mitgeben. Das LCMconfig-Skript sieht dann folgendermaßen aus:

  • Im Settings Block legen wir allgemeine Einstellungen für den LCM fest, wie z.B. die Zeitintervalle, nach denen der LCM immer aktiv wird, um die Konfigurationen zu prüfen und gegebenenfals automatisch zu korrigieren. Sie werden etwas verwundert sein über die Einstellung RefreshMode = 'Push', wo wir doch über einen Pull Client sprechen. Diese Einstellung ist für unser Beispiel ohne Bedeutung, da wir im Folgenden mit partiellen Konfigurationen arbeiten; und bei jeder partiellen Konfiguration müssen wir angeben, wie sie der LCM erhält (Push oder Pull).
  • im nächsten Block ConfigurationRepositoryWeb teilen wir dem LCM Informationen für den zu verwendenden Pull Server mit:
    • ServerURL: Dies ist die Endpunkt-Adresse einschließlich IP-Port des Pull Server Webdienstes, die wir beim Installieren des Pull Servers festgelegt haben (siehe "Die Anwendungskonfiguration (APPconfig) für unseren Web Pull Server DSC-PS01" im Teil 2)
    • RegistrationKey: Beim Installieren des Pull Servers haben wir eine GUID festgelegt, mit der sich Clients authentisieren müssen. Diese muss hier wieder angegeben werden.
    • AllowUnSecureConnection: Normalerweise erfolgt die Kommunikation mit dem Pull Server über verschlüsselte Verbindungen. Wir haben bei unserem Pull Server der Einfachheit halber darauf verzichtet und müssen dies hier jetzt dem LCM mitteilen.
    • Und dann müssen wir dem LCM über die Angabe ConfigurationNames noch mitteilen, welche der anschließend beschriebenen partiellen Konfigurationen er auf diesem Pull Server findet. Die Angabe ist ein String Array mit den Namen der abzurufenden Konfigurationen - in unserem Fall gibt es nur eine Konfiguration mit dem Namen EnableMSUpdate.

Falls wir Konfigurationen von verschiedenen Pull Servern abrufen wollen, können wir weitere ConfigurationRepositoryWeb-Blöcke hier definieren - natürlich jeweils mit unterschiedlichen Blocknamen.

  • Mit dem nächsten Block ReportServerWeb können wir dem LCM mitteilen, wo er Status-Informationen zu durchgeführten Aktionen ablegen soll. Dies ist eine Zusatz-Funktionalität eines Web Pull Servers, auf die ich später noch zurückkommen werde.
  • Jetzt folgen noch die partiellen Konfigurationen mit der Angabe, ob sie der LCM lokal vorfindet (RefreshMode='Push') oder von einem Pull Server abrufen soll ('RefreshMode = 'Pull'). Für Konfigurationen im Pull Modus ist dann noch ein Verweis auf den ConfigurationRepositoryWeb Block des zu verwendenden Pull Servers notwendig.
  • Und damit die partielle Konfiguration für das Setzen des Microsoft Updates erst abgearbeitet wird, wenn das Betriebssystem erfolgreich konfiguriert wurde, definieren wir noch mit DependsOn diese Abhängigkeit von der partiellen Konfiguration OSconfig.

Jetzt haben wir alle Teile für unseren Pull Client DSC-PC01 zusammen und können die VM unter Zuhilfenahme der schon im Teil 2 vorgestellten DSC-Konfiguration DSCHyperV_VM erstellen:

  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-PC01 -ParentVhdPath `
        E:/Hyper-V/WS2016_GPT_DCGUI.vhdx -OutputPath ./DSC-PC01 -Verbose

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

Nachdem die VM gestartet wurde, können Sie über eine VM Verbindung vom lokalen Hyper-V Manager zum Pull Client DSC-PC01 den Erstellungsvorgang mit verfolgen - wobei allerdings außer einigen automatischen Neustarts nichts Spektakuläres passiert. Melden Sie sich dann als lokaler Administrator an und rufen in den Settings die Kategorie Update & Security auf. Klicken Sie dort auf Advanced Options. Im nächsten Fenster sollte jetzt die Option Give me updates for other Microsoft products when I update Windows aktiviert sein.

Um zu überprüfen, ob der LCM auch regelmäßig seinen Dienst versieht, können Sie die Option für den Microsoft Update deaktivieren. Schließen Sie das Fenster mit den Advanced Options bzw. gehen zurück auf die Startseite von Update & Security und warten ... die Zeit ist abhängig von den Angaben im Settings- Block des LCM (in unserem Beispiel bis zu 60 Minuten).

Wenn Sie nicht so lange warten wollen, können Sie auf dem Pull Client auch einen Refresh erzwingen durch Eingabe des Befehls

Start-DscConfiguration -Wait -Force -Verbose -UseExisting

Wenn Sie danach die Advanced Options erneut aufrufen, werden Sie feststellen, dass die Option für den Microsoft Update wieder aktiviert ist.

Zurück zum Inhaltsverzeichnis...​

Der Pull Server als Report Server

Ein DSC Web Pull Server stellt nicht nur DSC-Konfigurationen bereit zur Nutzung durch Pull Clients, er kann auch als Report Server für Pull Clients arbeiten. Diese Funktionalität ist immer aktiviert, es sind also keine besonderen Konfigurationen am Pull Server notwendig.

Zurück zum Inhaltsverzeichnis...​

Senden von Report Daten

Ob ein Pull Client Status Meldungen an einen Report Server senden soll und an welchen, kann man in der LCM-Konfiguration durch den Ressourcen-Block ReportServerWeb festlegen.

Darin ist eigentlich nur eine Angabe notwendig, nämlich die URL des Pull Servers, an den Statusdaten gesendet werden soll. Das muss nicht der gleiche Pull Server sein, von dem auch die Konfigurationen geholt werden (wie in unserem Beispiel).

Für den Fall, dass die Statusdaten an einen anderen Server gesendet werden sollen, muss außerdem noch dessen RegistrationKey hinterlegt werden.​ Bei unserem Beispiel können wir darauf verzichten, da hier Pull und Report Server identisch sind. Der LCM verwendet dann den RegistrationKey aus dem ConfigurationRepositoryWeb-Block.

In unserer Testumgebung haben wir beim Pull Server auch festgelegt, dass ohne Verschlüsselung gearbeitet werden soll. Deshalb müssen wir bei der Definition des Report Servers dies dem LCM durch die Angabe von AllowUnsecureConnection = $true mitteilen.

Zurück zum Inhaltsverzeichnis...​

Auswerten der Report Daten

Die Statusdaten der Pull Clients werden in einer internen Datenbank auf dem Web Pull Server verwaltet. Sie können durch Funktionsaufrufe (Web Requests) an den Webdienst abgerufen werden. Bei diesen Aufrufen muss die AgentID des Local Configuration Magers auf dem gewünschten Pull Clients angegeben werden. Diese AgentID versteckt sich in den Eigenschaften des LCM auf dem jeweiligen Client und kann dort mit dem CmdLet Get-DscLocalConfigurationManager (Alias: glcm) ermittelt werden:

... oder direkt:

Mit der nachstehenden Powershell Funktion GetReport (Quelle: MSDN) kann man nun die Statusdaten eines Pull Clients abrufen:

Die Funktion liefert ein Array von JSON-Objekten zurück, die man mit einigen weiteren Befehlen aufbereiten kann. Das folgende Skript zeigt, wie man z.B. von unserem Hyper-V Host aus die AgentID des Pull Clients DSC-PC01 ermitteln kann, dann damit die Statusdaten vom Pull Server abruft, sie nach dem Startdatum sortiert und dann das Ergebnis des letzten LCM-Laufs anzeigen kann.

Hinweis: Das vollständige Skript finden Sie in der zu diesem Blogpost gehörenden .ZIP-Datei.

Wenn wir dieses Skript ausführen, erhalten wir etwa die folgende Anzeige:

Damit können wir uns schnell einen Überblick über die letzten DSC-Aktionen auf einem Pull Client verschaffen. Bei Problemen ist dies natürlich nicht unbedingt ausreichend. Dann muss man auf weitergehende Methoden zurückgreifen, wie ich sie z.B. schon im Teil 2 im Abschnitt "Troubleshooting" beschrieben habe.

Zurück zum Inhaltsverzeichnis...​

Wie geht's weiter?

Mit diesem Beitrag habe ich gezeigt, wie man einen zentralen DSC Web Pull Server bestücken und nutzen kann. Nun sind Sie als Anwender bzw. Administrator gefordert, weiterführende Szenarien mit DSC zu entwerfen und umzusetzen. Ich werde natürlich auch am Ball bleiben und hier weiter über interessante DSC-Projekte berichten.

Zurück zum Inhaltsverzeichnis...​

Downloads

In diesem Beitrag (und auch schon im Teil 2) sind eine Menge an Powershell Skripten beschrieben. Auf Grund von Sicherheitsbeschränkungen​ der Blog-Software können diese leider nicht direkt im Quellcode dargestellt weden, sondern nur als Screenshots. Um Ihnen lästige Tipparbeit beim Nachvollziehen der Szenarien zu ersparen, habe ich die Skripte in eine .ZIP-Datei gepackt, die Sie hier herunterladen können. Bitte beachten Sie, dass die Skripte auf meine Test- und Entwicklungsumgebung ausgerichtet sind. Falls Sie eine andere Systemumgebung verwenden, müssen Sie gegebenenfalls an der einen oder anderen Stelle Laufwerks- und / oder Pfadangaben anpassen.

Die Datei DSC-Lab.ZIP enthält sowohl die Skripte dieses Beitrags als auch die aus dem vorangegangenen Teil 2. Bitte beachten Sie auch die Hinweise in der enthaltenen Datei Readme.rtf.

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.

>