Desired State Configuration: Zielsysteme festlegen mit ConfigurationData

    DSC Configuration DataEine configuration beschreibt, welche Einstel­lungen ggf. geän­dert oder welche Features und Anwen­dungen de/installiert werden sollen. Dabei kann man auch gleich die betrof­fenen Rechner an­geben. Wenn man aber das "Was" vom "Wo" tren­nen möchte, dann bietet sich die Verwen­dung von ConfigurationData an.

    In einer configuration ist das Schlüsselwort Node dafür zuständig, die Zielsysteme zu definieren, auf die sie angewandt werden soll. Im einfachsten Fall trägt man hier einen oder mehrere Hostnamen ein, die man durch Kommata voneinander trennt.

    Jeder Rechner benötigt eigene .mof-Datei

    Die Nennung der Zielsysteme ist erforderlich, weil die configuration eine namensgleiche .mof-Datei für jeden Node erzeugt, sobald man sie ausführt. Gibt man localhost an, dann kann man die korrespon­dierende localhost.mof zwar auf jeden Rechner anwenden, aber nur lokal und nicht remote.

    Eine Möglichkeit zur Trennung von Konfiguration und Ort der Anwendung bietet die Verwendung von Parametern. Auf diese Weise übergibt man der configuration bei ihrer Ausführung jeweils andere Rechner­namen als Argument, so dass sie .mof-Dateien für diese Computer generiert.

    Hash Table mit ConfigurationData

    Weitergehende Möglich­keiten bietet der Einsatz von ConfigurationData. Es handelt sich dabei um eine Hash-Tabelle, deren Elemente nicht nur den Namen, sondern auch beliebige andere Eigenschaften der Nodes enthalten können.

    In ihrer allgemeinen Form sieht die Datenstruktur so aus:

    @{
       AllNodes = @()
       NonNodeData = ""
    }

    AllNodes enthält alle einzelnen Knoten mit den jeweils spezifischen Eigenschaften für diesen Rechner. In NonNodeData speichert man solche Informationen, die nicht zu einem bestimmten Knoten gehören. Dieses Element ist optional und man kann dafür auch andere Namen verwenden und mehrere davon nutzen.

    Interne oder externe Definition

    Die Hash-Tabelle definiert man entweder zusammen mit der configuration in einem Script oder man lagert sie in eine eigene .psd1-Datei aus. Wählt man die interne Variante, dann weist man die gesamte Struktur einer Variablen zu, die man der configuration bei der Ausführung mitteilt:

    Nach dem Laden der configuration führt man sie mit folgendem Befehl aus, um $ConfData zu laden:

    DisableSMB1 -ConfigurationData $ConfData

    Dieses Beispiel greift den Code zur Deaktivierung von SMB v1 auf, den ich hier unter Verwendung statischer Node-Einträge vorgestellt habe. Er lässt sich nur auf PCs mit Windows 8.1 und 10 anwenden, weil am Server die Ressource WindowsOptionalFeature nicht existiert und SMB v1 unter Windows 7 nicht deinstalliert werden kann.

    ConfigurationData durch Script erzeugen

    Daher wäre es natürlich praktisch, wenn man die Nodes abhängig vom installierten Betriebssystem auswählen könnte. Durch das bloße Speichern der Rechner­namen in einer Hash-Tabelle ist aber noch nichts gewonnen. Das obige Script übernimmt mit $AllNodes.NodeName einfach die Namen aller Knoten aus $ConfData.

    Eine Lösung könnte darin bestehen, dass man die Computer aus dem Active Directory ausliest, wo auch die OS-Version hinterlegt ist, und daraus eine eigenständige Datei für ConfigData zu erzeugen. Diese sähe beispielsweise so aus:

    Dieses Script speichert man etwa unter dem Namen Create-ConfigData.ps1 und führt es so aus:

    .\Create-ConfigurationData.ps1 > .\ConfData.psd1

    ConfigurationData per Script aus dem Active Directory erzeugen

    Um die Konfiguration mit diesen Daten zu verknüpfen, ruft man sie nach diesem Muster auf:

    DisableSMB1 -ConfigurationData ConfData.psd1

    Nodes filtern

    In der Datei ConfData.psd1 finden sich dann die Einträge für alle Nodes, wobei wir neben dem obligatorischen NodeName noch die Eigenschaft OS eingefügt haben. Der Datensatz pro Rechner sieht dann so aus:

    @{
    NodeName = "WIN10PRO-VM1-L2"
    OS = "Windows 10 Pro"
    },

    Diese Information kann man sich dann in der configuration zunutze machen, weil diese das Filtern der Nodes mit Hilfe der where-Methode erlaubt:

    Node $AllNodes.Where{$_.OS -like "Windows 10*"}.NodeName {
    WindowsOptionalFeature 'SMB1' {

    ...

    Führt man die Konfiguration DisableSMB1 aus, dann greift sie sich nur die Nodes, in denen die Eigenschaft OS mit "Windows 10" beginnt, und erzeugt .mof-Dateien bloß für sie.

    .mof-Dateien werden nur für die Rechner erzeugt, deren OS mit "Windows 10" beginnt

    Das oben vorgestellte Script, das die Datei ConfData.psd1 erzeugt, ließe sich natürlich weiter ausbauen, um beliebige weitere Eigenschaften zu ermitteln. So könnte man bei allen Systemen, die online sind, bestimmte installierte Rollen bzw. Features abfragen oder die IP-Adresse auslesen, um zum Beispiel nur Nodes aus einem bestimmten Subnet zu wählen.

    Keine Kommentare