Archiv der Kategorie: DSC

DSC Pullserver mit SQL Server als Datenbank

Ein DSC Pullserver verwendet standardmäßig eine ESENT DB-Datenbank (das „ESE“ steht für Extensible Storage Engine) für das Abspeichern der Konfigurationszustände der einzelnen Nodes. Bei der Umsetzung von DSC wollten es die Entwickler offenbar einfach halten und haben auf eine bewährte Datenbankengine gesetzt, die u.a. von Active Directory und Exchange Server verwendet wird, und die seit Windows XP einfach da ist. Für die Praxis ist eine SQL Server-Datenbank die bessere Option. In erster Linie weil sich dadurch Reporting-Möglichkeiten ergeben, die ansonsten nicht oder nur eingeschränkt zur Verfügung stehen.

Tipp: Ein praktisches kleines Tool für das Betrachten von ESENT DB-Datenbanken ist die ESENT Workbench: https://bitbucket.org/orthoprog/esentworkbench/wiki/Home.

Tipp<: Auf GitHub gibt es einen Managed Essent DB-Provider. Mit seiner Hilfe soll der Zugriff auf eine Datenbank in Managed Code und damit auch per PowerShell sehr einfach einfach: https://github.com/Microsoft/ManagedEsent.

Leider lässt sich eine SQL Server-Datenbank in der aktuellen DSC-Version (Stand: Mai 2018) noch nicht einbinden. Der Grund ist eher trivial. DSC verwendet für den Zugriff auf die ESENT DB-Datenbank benannte Parameter, der für den SQL Server-Zugriff zu verwendende Datenbankprovider versteht diese offenbar nicht und erwartet, dass jeder Parameter durch ein ? repräsentiert wird. Das kann wiederum nur die Jet-Engine von Microsoft Access. Deswegen muss eine Access-Datenbank in Gestalt einer Mdb-Datenbankdatei, die lediglich verknüpfte Tabellen auf die SQL Server-Datenbank enthält, als Vermittler eingeschaltet werden.

Microsoft-Mitarbeiter und PowerShell-Experte Raimund Andrée beschreibt die Hintergründe in einem Blog vom Mai 2017 sehr ausführlich, so dass ich auf seinen Blog verweise, da der alle Fragen beantworten sollte:

https://blogs.technet.microsoft.com/fieldcoding/2017/05/11/using-sql-server-2016-for-a-dsc-pull-server/

Die Vorgehensweise ist, die ESENT-Datenbank Devices.edb durch eine per Microsoft Access erstellte Datenbank mit dem Namen Devices.mdb auszutauschen, deren Tabellen auf die gleichnamigen Tabellen der SQL Server-Datenbank verlinken. Klingt vielleicht umständlich, ist in der Umsetzung aber relativ einfach. Ob es tatsächlich funktioniert ist aber noch ein anderes Thema (Stand 31/05/18 ist es mir nicht gelungen, einen Pull Server mit SQL Server-Datenbanb zu betreiben – die Gründen haber nur indirekt etwas mit DSC zu tun, sondern eher mit der TLS/SSL-Problematik).

Mit Windows Server 2019 soll das Einbeziehen einer SQL Server-Datenbank dann direkt möglich sein:

https://blogs.msdn.microsoft.com/powershell/2018/04/19/windows-pull-server-planning-update-april-2018/
Ob es dieses Update auch für ältere Windows Server-Versionen geben wird ist nicht klar (meine Frage diesbezüglich wurde noch nicht beantwortet)

Ergänzungen aus der Praxis

Das Anlegen einer ODBC-Datenquelle ist aus verschiedenen Gründen nicht ganz so einfach wie es sich in de Anleitung anhört.

>SSL 3.0 kann ein Thema sein. Sollte das Herstellen einer Verbindung hartnäckig an einem Error 18 scheitern, kann das Aktivieren von SSL 3.0 die Lösung sein. Eine praktisches kleines Tool ist IISCrypto.exe (Download unter https://www.nartac.com/Products/IISCrypto/), mit dem sich TLS und SSL sehr einfach aktivieren oder deaktivieren lassen (anschließend ist ein Neustart erforderlich).

Eine Alternative ist der Weg über die lokalen Sicherheitsrichtlinien bzw. Gruppenrichtlinien:

https://dba.stackexchange.com/questions/93127/sql-server-service-won-t-start-after-disabling-tls-1-0-and-ssl-3-0

Man braucht wieder einmal viel Zeit und vor allem Geduld und sehr viel Nachsicht den verantwortlichen DSC-Entwicklern gegenüber.

Praktische Neuerung für DSC – das DSCLCM-Modul

Die Konfiguration des LCM ist in der aktuellen DSC-Version etwas umständlich. Zum einen muss man jede Einstellungsänderung in einer Konfiguration zusammenfassen, was grundsätzlich machbar ist, etwas lästiger ist es, dass beim Ändern einer partiellen Konfiguration, etwa dem Hinzufügen einer weiteren Konfiguration, auch alle anderen partiellen Konfigurationen neu gesetzt werden müssen.

Einfacher soll es mit einem neuen Modul mit dem Namen DSCLCM geben, das von den Scripting Guys (es gibt sie also noch;) vor kurzem vorgestellt wurde:

https://blogs.technet.microsoft.com/heyscriptingguy/2018/03/30/introducing-the-dsclcm-utility-for-powershell/

Ich habe das Modul noch nicht getestet, werde es aber in Kürze nachholen.

Neues von DSC – Open Source, keine Abhängigkeit zu .NET beim LCM und ein Providermodell für beliebige (Skript-) Sprachen

Im PowerShell Teamblog wurde Ende Januar 2018 ein erster Ausblick auf die nächste Version der Desired State Configuration (DSC) gegeben:

Desired State Configuration (DSC) Planning Update – January 2018

Dass DSC wie PowerShell auf Open Source umgestellt wird ist keine Überraschung. Bemerkenswert ist die komplette Loslösung vom .NET Framework und damit auch von der PowerShell.

Die wichtigsten Neuerungen sind laut Blog-Eintrag:

>Der LCM wird in C++ programmiert und damit komplett plattformunabhängig und vermutlich auch deutlich schlanker und perfomanter
>Über ein Providermodell können Ressourcen nicht nur in PowerShell-Skript geschrieben werden, sondern theoretisch in jeder Sprache
>Bestehende Konfigurationsdefinitionen und Ressourcen müssen nicht angepasst werden. Das erste Providermodell soll die PowerShell anbinden.

DSC vNext wird damit kompatibel zum aktuellen Modell sein, so dass man sein erworbenes Know-how nicht gleich wieder in die Tonne treten kann. Am Erstellen von Konfigurationen per PowerShell, an der Arbeitsweise von Push- und Pull-Modell oder an der LCM-Konfiguration dürfte sich grundsätzlich nichts bzw. nicht viel ändern. Es wird ohnehin so sein, dass die aktuelle Version auf Jahre weiter verwendet wird und die neue Version, sofern sie irgendwann verfügbar ist, in erster Linie für Szenarien eingesetzt wird, in denen z.B. das Providermodell eine Rolle spielt.

Die über UserVoice geäußersten Verbesserungsvorschläge für DSC sollen bei der Entwicklung der kommenden Version berücksichtigt werden.

DSC vNext wird voraussichtlich erst Ende dieses Jahres offiziell werden. Im Blog-Eintrag heißt es ja, dass man das Projekt innerhalb eines Jahres freigeben will. Auf den beiden großen PowerShell-Konferenzen, die im April in den USA und in Hannover stattfinden werden, gibt es bereits Vorträge zu „DSC vNext“. Spätestens zu diesem Zeitpunkt dürfte auch das PowerShell-Team etwas konkreter geworden sein. Man darf gespannt sein.