Archiv der Kategorie: DSC

Microsoft SQL Server 2012 per DSC installieren

In diesem Eintrag geht es um die Installation eines Microsoft SQL Server per DSC (Desired State Configuration) auf einem anderen Computer (oder demselben Computer). DSC ist bei der PowerShell ab Version 4.0 fest eingebaut.

Die Umsetzung ist keine ganz leichte Aufgabe, auch wenn es sich zunächst danach anhören könnte. Die Umsetzung selber ist einfach sobald man sich mit DSC heimisch fühlt und weiß, welche Voraussetzungen auf dem Zielcomputer (der bei DSC Node heißt) erfüllt sein müssen. Ein Problem ist, dass gleich eine Reihe von Voraussetzungen auf dem Zielcomputer (Node) erfüllt sein müssen:

>WMF ab Version 5.0, am besten 5.1 und vor allem übereinstimmend mit jener Version, die für das Erstellen der Configuration verwendet wurde

>Die DSC-Ressource xSQLServer muss vorhanden sein.
>PowerShell-Remoting muss aktiviert worden sein, da auch die Sessionkonfiguration eine Rolle spielt (ein Set-WsmanQuickConfig auf dem Node genügt daher nicht)

>Außerdem muss sich das Setup-Programm des SQL Servers in Gestalt einer Datei mit dem Namen Setup.exe bereits auf dem Zielcomputer befinden

Das ist aber leider noch nicht alles:

>Auf dem Zielcomputer wird ein Zertifikat benötigt, das für die Dokumentverschlüsselung geeignet ist (wie es angelegt wird zeige ich in Kürze)

>Das Zertifikat muss als Cer-Datei exportiert und auf dem Computer vorhanden sein, von dem die Configuration aus per Start-DSCConfiguration übertragen wird (ein „Pull Server“ kommt für diese Art von Konfigurationsänderung nicht in Frage, da solche Installationen wie die eines SQL Servers angestoßen und nicht automatisch durchgeführt werden)

Tipp: Sollte während oder nach der Installation ein Neustart erforderlich sein, was bei einer SQL Server-Installation im Allgemeinen nicht der Fall ist, ist die Ressource xPendingReboot und das gleichnamige Modul sehr praktisch, das auf anstehende Neustartanforderungen mit einem Neustart reagiert.

Das folgende kleine Beispiel bezieht sich auf die Installation von SQL Server 2012 Express (32 Bit) auf einem 32 Bit Windows 7 mit SP1 und WMF 5.1. Bis auf zwei Ausnahmen werden die Voreinstellungen des Setup-Programms übernommen:

>Es wird ein eigener Instanzname verwendet
>Die Dateien der Instanz sollen in einem eigenen Verzeichnis abgelegt werden

Wichtig: Mit dieser Methode wird auch eine weitere Instanz angelegt.

Der Zielcomputer für das Beispiel heißt Win7A. Der Benutzername (Adminkonto) „Pemo7“ und das Kennwort… nun ja, das spielt ja eigentlich keine Rolle;)

Noch eine Kleinigkeit: Liegt die Setup-Datei für die 64-Bit-Version des SQL Servers vor, bleibt die Konfiguration hängen, da die Ressource offenbar den Fehlerzustand nicht erkennt. Wenn es also beim Anwenden der Konfiguration später gar nicht weitergeht, könnte es daran liegen.

Schritt 1: Anlegen des Zertifikats

Verfügt man über keine PKI (was erstaunlich oft der Fall ist), muss man sich mit einem selbstsignierten Zertifikat behelfen. Da es unter Windows 7 leider kein New-SelfSignedCertificate-Cmdlet gibt, kommt das sehr gute Skript New-SelfSignedCertificateEx.ps1 von Vadims Podans zum Einsatz, das mir schon einige Male gute Dienste geleistet hat, auch unter Windows Server 2016. Es gibt es in der Technet Script Gallery:

https://gallery.technet.microsoft.com/scriptcenter/Self-signed-certificate-5920a7c6

Ein kleines Problem ist lediglich, dass für den EnchacedKeyUsage-Parameter ein lokalisierter Name (also etwa auf Deutsch) übergeben werden muss und auf den kommt man nicht immer so einfach. Eine OID ist daher etwas praktischer.

Der folgende Aufruf legt auf dem Zielcomputer (Node) ein selbst ausgestelltes Zertifikat an.

Schritt 2: Exportieren des Zertifikats als Cer-Datei

Unter Windows 7 gibt es kein Export-Certificate-Cmdlet. Ich verwende daher die MMC durch Eingabe von „mmc.exe“, lade das Zertifikate-Snapin für den lokalen Computer, selektiere das Zertifikat mit der rechten Maustaste, wähle Exportieren unter Aktionen und exportiere das Zertifikat im Base64-Format unter C:\Win7A.cer.

Schritt 3: Kopieren der Cer-Datei auf den Konfigurationscomputer

Das geht am einfachsten über Start->Ausführen und Eingabe von „\\Win7A\C$“.

Schritt 4: Abfragen des Thumbprints

Ein

listet die Zertifikate auf (in der Regel ist nur eines vorhanden). Dabei wird auch der Thumbprint angezeigt. Diesen kopiere ich in eine Textdatei Thumbprint.txt, die auf Laufwerk C:\ abgelegt wird.

Ich öffne die Datei ebenfalls über den Freigabeordner. Der Thumbprint wird später in die Konfigurationsdaten eingetragen.

Schritt 5: Installieren des xSQLServer-Moduls auf dem Zielcomputer

Das erledigt ein Aufruf von Install-Module.

Sollten weitere Module benötigt werden, was in diesem Fall nicht der Fall ist, müssten sie natürlich ebenfalls installiert werden.

Schritt 6: Kopieren der SQL Server-Installationsdatei auf den Zielcomputer

Die Installationsdatei für SQL Server 2012 heißt z.B. SQLEXPR_x64_DEU.exe und muss in „Setup.exe“ umbenannt werden.

Damit sind auf dem Zielcomputer alle Voraussetzungen erfüllt. Ein Domänenbeitritt ist nicht erforderlich.

Schritt 7: Festlegen der Konfigurationsdaten

Es ist eine gute Praxis, die Konfigurationsdaten von der Konfiguration zu trennen. Die Konfigurationsdaten enthalten den Namen des Zielcomputers (hier können natürlich mehrere Namen angegeben werden), den Namen der SQL Server-Instanz, den Pfad der Setup-Datei auf jedem Node, den Thumbprint des Zertifikats, das auf dem jedem Node angelegt wurde (er stammt aus der Textdatei Thumbprint.txt) und dem Pfad der exportierten Cer-Datei auf dem Konfigurationscomputer.

Der Thumbprint stammt aus der Textdatei Thumpprint.txt.

Schritt 8: Festlegen der Konfiguration

Die Konfiguration ist relativ überschaubar, da fast nur die Standardeinstellungen übernommen werden.

Schritt 9: Anlegen der Mof-Dateien

Das Ausführen der Configuration SetupSQLServer führt dazu, dass im gleichnamigen Unterverzeichnis zwei Mof-Dateien angelegt werden. Kommt es bei diesem Schritt zu einem Fehler, lässt er sich im Allgemeinen relativ schnell beheben. Das PSCredential-Objekt ist für die Anmeldung am Node erforderlich, da dieser nicht in der Domäne ist.

Schritt 10: Konfiguration des LCM auf dem Zielcomputer

Die Konfiguration des LCM übernimmt das Set-DscLocalConfigurationManager-Cmdlet:

Schritt 11: Übertragen der Konfiguration auf den Zielcomputer

Das übernimmt das Start-DscConfiguration-Cmdlet:

Die Installation dauert nur wenige Minuten und wird dank des Verbose-Parameters ausführlich im Konsolenfenster kommentiert. Das Abfragen der DSC-Eventlogs ist nur dann erforderlich, wenn eine der eher nichtssagenden Fehlermeldungen, die bei DSC offenbar häufig vorkommen, aufgetreten ist.

Schritt 12: Testen der Installation

Ein explizites Testen der erfolgreich angewandten Konfigurationsänderung ist bei DSC offiziell nicht erforderlich. Trat zwischendurch keine Fehlermeldung auf, lief alles ordnungsgemäß durch.

Ein Test besteht darin, per Get-Service zu prüfen, ob auf dem Zielcomputer ein Dienst mit dem Namen der Instanz, z.B. MSSQL$Server1, läuft. Ist dies der Fall, läuft die SQL Server-Instanz.

Bliebe noch zu erwähnen, dass die xSQLServer-Ressource laufend weiterentwickelt wird (aktuell ist bereits die Version 8.0). Wie alle DSC-Ressourcen ist sie hervorragend dokumentiert:

https://github.com/PowerShell/xSQLServer

Auch wenn das „x“ noch auf den „experimentellen“ Zustand der Ressource hinweist, macht sie einen umfangreichen und vollständigen Eindruck. Die kleinen Tests haben, nach ein paar Anlaufschwierigkeiten (u.a. habe ich noch nicht herausgefunden, wie eine gemischte Authentifizierung einrichtet wird) sehr gut funktioniert.

Exchange Server 2013 per DSC installieren

Die wichtigste Frage vorweg: Warum sollte man einen Exchange Server 2013 per DSC installieren? Die übliche Antwort: Es kommt darauf an. Aber worauf genau? Zum Beispiel darauf, ob man unter einenm gewissen Zeitdruck steht. Sollte dies der Fall sein und man noch mit DSC am Anfang stehen, lohnt sich der Aufwand vermutlich nicht. Insbesondere dann, wenn es lediglich um einen Exchange Server geht. Anders sieht es aus, wenn eine größere Anzahl von Installation anstehen oder man eine Grundlage schaffen möchte, auf der sich in Zukunft Exchange Server-Installation per Knopfdruck erledigen lassen.

Im Folgenden geht es um die Installation von Exchange Server 2013 SP unter Windows Server 2012 R2 per DSC.

Der folgende Blog-Eintrag beschreibt die generelle Vorgehensweise bereits sehr gut:

https://rlevchenko.com/tag/powershell-dsc/

Auf der Serverseite müssen folgende Voraussetzungen erfüllt sein:

>Ein Windows Server 2012 R2, der einer Domäne beigetreten ist
>Die DSC-Ressourcen xExchange und xPendingReboot
>Das Setup zur Unified Messaging API 4.0, die in Gestalt der Datei UcmaRuntimeSetup.exe im Verzeichnis C:\UCMA vorliegt
>Außerdem müsse „jede Menge“ Features installiert werden, was als Teil der DSC-Konfiguration erledigt wird

Die größte „Herausforderung“ besteht darin, die Voraussetzung dafür zu schaffen, dass das für das PSCredential-Objekt verwendete Kennwort verschlüsselt übertragen werden kann. Dazu wird auf dem Zielcomputer (Node) ein Zertifikat benötigt, dass für die Dokumentsignierung geeignet ist. Auf dem Computer, auf dem die Konfiguration ausgeführt wird, muss der Thumbprint des Zertifikats in den LCM eingetragen werden. Außerdem muss das Zertifikat exportiert werden und als Cer-Datei auf diesem Computer vorliegen.

Wie sich das Kennwort für ein PSCredential-Objekt sichern lässt, wird in der MSDN-Dokumentation ausführlich beschrieben:

https://msdn.microsoft.com/en-us/powershell/dsc/securemof

Positiv ist, dass in dem Beitrag auch das Skript New-SelfSignedCertificateEx.ps1 verwendet wird.

Die DSC-Konfiguration ist wie folgt aufgebaut:

Die folgende Befehlsfolge setzt die Konfiguration um:

Im nächsten Schritt wird der LCM konfiguriert:

Zum Schluss wird die Konfiguration im Push-Modus auf den Server EXServer1 übertragen:

Sind alle Voraussetzungen erfüllt, läuft die Installation, in dem auf dem Zielcomputer Setup.exe ausgeführt wird. Es kann aber eine Weile dauern bis die Installation wirklich abgeschlossen ist. Bei meinem Testdurchlauf dauerte es knapp 45 Minuten bis die Installation abgeschlossen war.

Die Exchange Server-Installation per DSC dauert eine Weile, läuft am Ende aber durch

Tipp: Neustart während einer DSC-Konfiguration mit xPendingReboot

DSC soll die Server-Konfiguration einfacher machen, dazu gehört auch, dass man sich um eventuelle Neustarts während des Anwendens einer Konfiguration keine Gedanken mehr machen muss. Wer ein wenig recheriert, stößt schnell auf die Einstellung RebootNodeIfNeeded beim LCM. Das Setzen auf $true bewirkt aber noch nicht, dass automatisch immer dann Neustarts durchgeführt werden, wenn dies erforderlich ist, sondern lediglich die Voraussetzung.

Wird die Konfiguration ausgeführt, wird eine weitere Mof-Datei angelegt, die am Zusatz „Meta“ zu erkennen ist (z.B. EXServer1.meta.mof). Diese Mof-Datei muss separat per Set-DscLocalConfigurationManager-Cmdlet angewendet werden.

Um während der Anwendung einer Konfiguration auf dem Node-Computer feststellen zu können, ob Neustarts anstehende, gibt es die Ressource xPendingReboot. Es hat eine Weile gedauert bis ich verstanden hatte wie sie funktioniert. Am Anfang trat die eher nichtssagende Fehlermeldung „Unable to query CCM_ClientUtilities“ auf. Eine kurze Recherche ergab, dass es die WMI-Klasse nur im Zusammenhang mit dem System Center Configuration Manager gibt. Sollte die Ressource daher nur mit einem SCCM funktionieren? Davon steht leider nichts in der Beschreibung. Das natürlich nicht, die Abfrage per SCCM-Klasse ist nur eine Option. Damit diese keine Rolle spielt, muss die Eigenschaft SkipCcmClientSDK auf $true gesetzt werden. Woher ich das weiß? Ganz einfach, das ergibt sich durch einen Blick in die Psm1-Datei, die der Ressource zugrunde liegt.

Hier ein Beispiel:

DSC – geplante Neuerungen

Auf der PoshConf Eu 2017 hat Jeffrey Snover in einer Folie die für DSC geplanten Neuerungen als Teil einer „Cloud Command Console“ zusammengestellt:

  • Ein portabler LCM für Windows und für Linux
  • Mehrere LCM-Instanzen
  • Ein Native Code-LCM (in C) für Umgebungen mit wenig Hardwareressourcen
  • Ein LCM als Bibliothek
  • Der LCM soll als Systemdienst ausführen (?)

Auch wenn diese Neuerungen auf der Folie „Core PowerShell in Azure“ aufgeführt wurden, gehe ich davon aus, dass sie allgemein verfügbar sein werden. Wann? Dieser Punkt ist noch offen.