PowerShell Desired State Configuration Teil 3 - Konfiguration anwenden

Beitrag gilt für: Windows Server 2012R2 & Windows 8.1

So, jetzt bin ich endlich beim dritten Teil der Reihe angekommen, in welchem ich euch zeige, wie wir ein Beispiel Konfigurations-Skript erstellen, welches wir immer wieder verwenden können und wie wir dieses auf einen Client oder einen Server anwenden können.

Wie verwende ich PowerShell DSC?

Die Desired State Configuration arbeitet mit PowerShell Skript-Blöcken. In den kommenden Screenshots verwende ich die PowerShell ISE. Mit dieser ist es am einfachsten PowerShell Skripte zu basteln. Deshalb ist es ,wie im zweiten Teil dieser Reihe schon erwähnt, hilfreich das PowerShell ISE direkt mit zu installieren, wenn wir gerade schon dabei sind.

Das erste Skript erstellen

Bevor ich hier erkläre wie das ganze ziemlich abstrakt funktioniert werde ich lieber zeigen, wie wir uns einem Gerüst festhalten können, welches wir immer wieder verwenden können um neue Skripte zu erstellen.

Als erstklassige Grundlage hierfür stellte sich das DSC Configuration Template im ISE heraus. Dieses öffnet man in der ISE indem man Strg + J drückt und hier „DSC Configuration (simple)“ auswählt.

Das sieht dann so aus.

Nun habe ich einmal vor die wichtigsten Bausteine dieses Skriptes zu erläutern und noch etwas zu erweitern. Weiter will ich euch beweisen, dass es wirklich nicht schwer ist eine Konfiguration zu erstellen und diese bei gegebenem Anlass zu erweitern.

Der Start - Der Konfigurations-Block

Die Screenshots sind zwar auf einem deutschen System gemacht, jedoch werde ich aus vielerlei Gründen im Kommenden, ein DSC Skript in Englisch mit euch erarbeiten. Aber im Normalfall sollte es auf deutschen Systemen keinen Unterschied machen, ob der Code in Deutsch oder Englisch verfasst ist. Der einzige offensichtliche Unterschied liegt darin, dass hier das Wort "Configuration" anstatt "Konfiguration" seine Verwendung findet.

Als erstes sagen wir, dass es sich um eine Konfiguration handeln soll. Dies funktioniert mit dem folgenden Konfiguration-Block

Configuration RobsDSCSkript { ... }

Dieser Block ummantelt das Skript und gibt uns quasi den ersten Rahmen unseres Gerüstes vor.

Anwendungsbereiche festlegen - Der Node-Block

In diesem Rahmen möchten wir nun erst einmal bestimmen auf welchen Rechner bzw. auf welche Rechner diese Konfiguration den angewandt werden soll. dies funktioniert mit dem Ausdruck node.

Configuration RobsDSCSkript { Node($Computer) { ... } }

Alles schön und gut so, aber vielleicht möchten wir diese Konfiguration ja nicht nur auf einen Rechner anwenden, sondern auf mehrere nacheinander, ohne jedes Mal wieder den Editor öffnen zu müssen. Deshalb kann man hier auch einen Parameter verwenden.

Configuration RobsDSCSkript { param([String] $Computer) node($Computer) { ... } }

So kann das Skript nachher einfach mit dem Parameter -ComputerComputername aufgerufen werden.

Auch könnten wir, wie in dem Beispiel in der ISE schon steht, Ausdrücke verwenden, welche zum Auswerten von Knotenliste dienen, aber darauf will ich jetzt hier nicht weiter eingehen.

Funktionen hinzufügen - Die Ressourcen-Blöcke

Auch das ist nicht so schwer, wie man es sich vielleicht zu Beginn vorstellt. Wir fügen hierzu einfach das folgende Template unterhalb der Knotenauswahl ein und passen dieses an unsere Anforderungen an.

# Beispiele & Erklärung Ressource Name # WindowsFeature RobsRessource { # Prüft ob "CoolNewFeature" installiert ist Attribut1 = Wert1 # Ensure = "Present" Attribut2 = Wert2 # Name = "CoolNewFeature" ... }

Als Ressource können hier viele verschiedene Werte eingesetzt werden wie man auch in diesem Beispiel sehen kann.

Configuration RobsDSCSkript { param([String] $Computer) node($Computer) { #################################################### # Überprüft ob das Hyper-V Feature installiert ist #################################################### WindowsFeature HyperVManager { Ensure = "Present"

#Mögliche Werte: "Absent" & "Present"

Name = "Hyper-V" } ##################################################### # Der Registry Key "OpenAtLogon" wird hinzugefügt #und auf den Wert "0" gesetzt. #### # Der Rechner geht nach dem Booten direkt auf den #Desktop, nicht auf die Kacheloberfläche ##################################################### Registry BooteAufDesktop { Ensure = "Present" Key = "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\StartPage\" ValueType = "REG_DWORD" ValueName = "OpenAtLogon" ValueData = "0" } ####################################################### #Diese wird nach der Ausführung von "BooteAufDesktop" #in das DSC Log geschrieben. ####################################################### Log LoggeNachRegistryAenderung { Message = "Registryveränderung wurde erfolgreich abgeschlossen" DependsOn = "[Registry]BooteAufDesktop" } ############################################### # Kopiert Ordner, Unterordner und Dateien #vom Share in das Zielverzeichnis. ############################################### File TestVerzeichnisKopieren { Ensure = "Present" Recurse = $true Type = "Directory" SourcePath = "\\Share\Rob\Quellverzeichnis" DestinationPath = "C:\Koenig\Zielverzeichnis" } } }

Noch mehr Informationen hierzu finden Sie unter [1]. Hier findet sich das DSC Resource Kit, in welchem sich dann auch unter anderem das Get-DSCResource befindet, welches alle verwendbaren DSC Ressourcen auflisten kann.

Das sollte für den Anfang erst einmal ausreichen. Das tolle an der DSC ist, dass die Sprache die hier verwendet wird sehr gut verständlich ist. Dies wird noch dadurch gesteigert, dass wir gegebenenfalls auftretende Fehler nicht selbst abfangen müssen. Das machen schon die integrierten Fehler-Handler. Da wir nun eine "vollständige" Konfiguration entwickelt haben, zeige ich euch, wie man diese denn auf einen Computer anwenden kann.

Die DSC Configuration anwenden

Dazu müssen wir zuerst einmal die Konfiguration als Datei speichern und die Konfiguration selbst einmal ausführen. Hierzu geben wir in der PowerShell folgendes Kommando ein

RobsDSCSkript -Computer RobsClient -Outpath C:\DSCMOF

Wobei hier RobsDSCSkript der Name der Konfiguration ist, nicht der Name der Datei.

Der Parameter -Computer ist jener, welchen wir zu Anfang in unser Skript eingebaut haben. -Outpath sorgt dafür, dass die entstehende *.mof Datei in ein bestimmtes Verzeichnis gelegt wird.

Nun können wir die Konfiguration auf den Windows 8.1 Rechner RobsClient mit folgendem Cmdlet ausführen.

Start-DscConfiguration -Path "C:\DSCMOF"

... Fehler. Was nun? Was ist an unserer Configuration falsch?

Nichts. Dies hängt damit zusammen, dass auf Client Betriebssystemen wie Windows 8.1 das Windows Remote Management (WinRM) standartmäßig ausgeschaltet ist. Wie Sie diese aktivieren können, finden Sie unter [2].

Auf einem Server Betriebssystem wie Windows Server 2012R2 ist dies nicht nötig, da WinRM hier standartmäßig aktiviert ist.

Nachdem wir nun das WinRM aktiviert haben führen wir Start-DSCConfiguration Cmdlet noch einmal aus und siehe da, es funktioniert.

Hilfreiche Parameter

Das Anhängen des -Verbose Parameters dient dazu, dass während der Ausführung die aktuellen Schritte auf der Konsole ausgegeben werden. Dies kann auch bei der Fehleranalyse sehr hilfreich sein, da wir so erkennen können, was denn genau schief gelaufen sein könnte.

Start-DscConfiguration -Path "Pfad" -Verbose

Der Parameter -Wait blockiert während der Laufzeit des Cmdlets die Konsole, sodass keine weitere Eingaben in diese Zeit möglich sind. Das ist vor allem bei längeren Konfigurationen hilfreich.

Start-DscConfiguration -Path "Pfad" -Wait

Weitere Informationen zu Start-DSCConfiguration gibt es unter [3].

Zusätzliche Informationen

Zum Abschluss noch etwas Theorie, falls wir mit unseren Kollegen noch etwas Fachsimpeln möchten.

LCM: Der Local Configuration Manager gibt der DSC überhaupt erst die Macht etwas verändern zu können. Der LCM muss auf allen Zielknoten installiert werden und ist dafür zuständig die DSC Konfigurationsressourcen aufzurufen und anzuwenden. Der LCM kann ebenfalls über die DSC, und das sogar ziemlich feingranular, konfiguriert werden. Mehr hierzu unter [4]. Hier kann auch konfiguriert werden, ob die DSC über den Push- oder Pull-Modus angewendet werden soll.

Push-Konfigurations-Modell: So wird die Möglichkeit genannt, welche wir hier verwendet haben, um die Konfiguration auf einen Computer anzuwenden. Hierbei wird nach dem Start die Konfiguration auf das Ziel "geschoben" und angewendet.

Pull-Konfigurations-Modell: Beim Pull-Modus bekommt der Client seine Konfiguration von einem Pull Server. Der Pull Server hält die Konfigurationsressourcen der Clients. Die Pull Clients müssen in der Aufgabenplanung dazu konfiguriert sein, in regelmäßigen Abständen die Configuration zu pullen. Wie man einen Pull Server und die entsprechenden Clients konfiguriert findet man unter [5].

Ich hoffe, ich konnte euch allen die PowerShell Desired State Configuration etwas näher bringen. Eventuell gehe ich in kommenden Beiträgen noch etwas weiter ins Detail, also schreibt in die Kommentare, was euch interessiert oder wo der Hund bei euch begraben liegt.

Links

[1] https://gallery.technet.microsoft.com/scriptcenter/DSC-Resource-Kit-All-c449312d
[2] http://support.microsoft.com/kb/555966/de
[3] http://technet.microsoft.com/de-de/library/dn521623.aspx
[4] http://technet.microsoft.com/de-de/library/dn249922.aspx [5]http://blogs.msdn.com/b/powershell/archive/2013/11/26/push-and-pull-configuration-modes.aspx

Überblick der Blogeintragseihe:

Teil 1: PowerShell Desired State Configuration Teil 1 - Ersatz für den SCCM?
Teil 2: PowerShell Desired State Configuration Teil 2 – Installation oder "Wie man ein Windows Feature aktiviert"
Teil 3: PowerShell Desired State Configuration Teil 3 - Konfiguration anwenden

 

UNSERE NÄCHSTEN SCHULUNGEN

Deployment, Powershell, Windows 8, Windows Server 2012R2ESCde Windows Server TeamConfiguration drift, Deployment, Desired State Configuration, DSC, DSC Skript, DSC Tutorial, Fehler DSC, keine mof, Pull, Push