Tags: PowerShell, Configuration-Management
Eine configuration beschreibt, welche Einstellungen ggf. geändert oder welche Features und Anwendungen de/installiert werden sollen. Dabei kann man auch gleich die betroffenen Rechner angeben. Wenn man aber das "Was" vom "Wo" trennen möchte, dann bietet sich die Verwendung 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 korrespondierende 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 Rechnernamen als Argument, so dass sie .mof-Dateien für diese Computer generiert.
Hash Table mit ConfigurationData
Weitergehende Möglichkeiten 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 Rechnernamen 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
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.
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.
Täglich Know-how für IT-Pros mit unserem Newsletter
Verwandte Beiträge
- winget erhält PowerShell-Modul und Configuration Management
- Desired State Configuration: Nodes und configuration mit Parametern anpassen
- Test-DscConfiguration, DSCEA: Konfiguration von PCs remote überprüfen
- Anleitung: SMB v1 mit Desired State Configuration deinstallieren oder deaktivieren
- Desired State Configuration (DSC): Grundlagen und Funktionsweise
Weitere Links