PowerShell Desired State Configuration Teil 1 - Ersatz für den SCCM?

Einige werden sich beim Lesen dieses Eintrages wohl wundern, wieso ich jetzt erst über dieses Feature schreibe, wenn die Desired State Configuration (DSC) doch schon mit der PowerShell 4.0 im August 2013 erschien.

Dies hat den Hintergrund, dass ich, auch in Hinsicht auf unsere Kunden, bemerkt habe, dass sich immer noch viel zu wenige auf die, mittlerweile für viele, zu schnell ändernde Umgebung und technischen Neuerungen eingestellt haben.

Zudem fiel mir auf, dass nur sehr wenige die neuen Technologien zur Vereinfachung der Administration und der Integration verwenden, die Microsoft uns an die Hand gibt.

Deshalb möchte ich als Aufbau für die kommenden Einträge meinerseits nun etwas zur Desired State Configuration schreiben und euch hoffentlich etwas die Angst nehmen dieses und auch andere neue Features auszuprobieren.

Nachdem nun die Daseinsberechtigung meines Blog Eintrags geklärt ist, nun dazu für welche Zwecke man etwas wie die DSC brauchen könnte.

Der Hauptgrund hierfür liegt in der steigenden Anzahl der Endgeräte und der damit verbundenen Steigerung der Serveranzahl und dem exponentiell höheren Administrationsaufwand. Zusätzlich hätten natürlich alle Nutzer gerne auch die durchgehende Verfügbarkeit aller Dienste und grundsätzlich muss jede neue Technologie einsatzbereit sein und das am besten schon gestern.

Da die Abstände zwischen neuen Betriebssystemen, Updates von Programmen, Apps und Konsorten immer kürzer werden, brauch es keinen zu wundern, dass man keine Zeit mehr dazu findet auf Anfragen der User zu reagieren oder die ansonsten alltäglichen Jobs zu erledigen da man mal wieder mit dem Deployment beschäftigt ist.

Das einzige was uns noch davon abhält verrückt zu werden, ist die Automatisierung möglichst vieler zeit- und nervraubender Schritte. Deshalb kommt genau hier die DSC ins Spiel.

Was ist DSC?

Die Desired State Configuration fand, wie eingangs schon erwähnt, im August 2013 erstmalig Platz in Windows Management Framework 4.0 und wurde hierbei in die PowerShell 4.0 integriert.

Praktisch gesehen hilft uns die DSC dabei neue Systeme mithilfe von Skript-Blöcken zu konfigurieren und Systeme die vom „Desired State“ abgedriftet sind wieder in den angestrebten Zustand zu versetzen.

Was kann die DSC?

Viel. Wie man auch auf den diversen Seiten in der hauptsächlich englischen TechNet lesen kann scheint die DSC ein Schweizer Taschenmesser in Bezug auf Deployment und Management zu sein.

In der folgenden Übersicht habe ich einmal die in meinen Augen wichtigsten Funktionen angesammelt:

  • Features und Rollen auf Servern aktivieren und deaktivieren

  • Registry Einstellungen, Dateien und Pfade verwalten

  • Bereitstellung neuer Software

  • Verwaltung von Benutzern und Gruppen

  • Prozess- und Dienste-Verwaltung

Noch nicht überzeugt?

Vorteile von DSC

  • Durchgehender Einsatz: Das heißt, wir können die Konfiguration immer und immer wieder anwenden ohne etwas kaputt zu machen. Dies ist auch der Punkt der es uns ermöglicht die Systeme daran zu hindern vom wünschenswerten Zustand abzudriften. Das ganze klingt jetzt erst einmal ziemlich nutzlos den gleichen Server immer und immer wieder gleich zu konfigurieren. Dies hat zum Beispiel den Sinn, dass keine ungewünschten Features installiert sind oder wichtige Dateien noch in einem speziellen Verzeichnis liegen.

  • Alles über die PowerShell: Wieso unnötig weitere Tools installieren, wenn wir schon alles haben, was wir benötigen. Dies wurde hier souverän von Microsoft umgesetzt und das ist gut so, da neue Software einen zusätzlichen Posten bedeutet, der sich auf dem ohnehin oft schon knapp kalkulierten Jahresbudget breit macht. Zudem birgt Zusatzsoftware immer die Gefahr, dass durch sie Fehler verursacht werden, die unter Umständen sehr schwer zu lösen sind.

  • Daten und Logik sind getrennt: Das steigert die Wiederverwendbarkeit eines DSC Skriptes. Eine Tolle Dokumentation hierzu befindet sich hier [1].

  • Schnelles Deployment: Dadurch, das lästige Schritte wie Einrichten und Konfigurieren einzelner Server hierdurch wegfallen, ist das Deployment mit DSC sehr zeitsparend. Zudem werden bei der Skriptausführung immer nur die Teile des Skriptes ausgeführt, die nicht mehr aktuell sind. D.h. wenn wir mithilfe des Skriptes einen neuen Webserver konfigurieren möchten (ja, das ist das wohl häufigste Beispiel wenn es um DSC geht, aber es ist dennoch sehr anschaulich) und wir bereits das IIS Feature installiert haben, wird dies von unserem Skript vor der Ausführung überprüft und daraufhin übersprungen.

So gesehen ist die DSC abgespeckter SCCM Ersatz welcher leider noch nicht ganz so viel kann wie der Configuration Manager selbst. Jedoch sollte man abwägen ob einem diese Möglichkeiten nicht sogar schon ausreichen. Zumal die DSC mit dem Windows Management Framework 5.0 noch erweitert werden soll.

Interessiert? Dann lies auch die nächsten Teile. Hier wird es darum gehen, wie man DSC aktiviert und wie man so ein Skript denn aufbauen und verwenden kann.

[1] http://technet.microsoft.com/en-us/library/dn249925.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

Allgemein, Deployment, PowershellESCde Windows Server TeamConfiguration drift, Deployment, desired state, Desired State Configuration, DSC, PowerShell