Desired State Configuration #3 – Details zu SQL Server Installation mit Murphy

Mit dem folgenden Beitrag möchte ich ein wenig in die Tiefe einsteigen, um euch zu zeigen, wie ich was wo kopiert und angepasst habe, damit mein Desired State Configuration SQL Server Rollout einwandfrei läuft. Nachdem ich in den ersten beiden Beiträgen die Vorbereitungen und Grundlagen meines Deployments erklärt und dargestellt habe, möchte ich heute auf die eigentliche Installation erläutern wie ich sie umgesetzt habe (es gibt auch einen anderen Weg, den ich später ausprobieren möchte – wie das so in Projekten ist herrscht ein wenig Termindruck 😉 )

Meine Skripte befinden sich während ich diesen Beitrag schreibe in einem Zustand, den man „Funktioniert“ nennen kann. Meine Skripte sind aktuell in der Lage von einem zentralen Server aus, auf einem (oder mehreren) Server alle notwendigen Ordner zu erstellen, die benötigten Dateien (ISO-Image, Updates, Powershell Module etc) auf den ZielServer zu kopieren, dort dann gemäß Vorgaben einen SQL Server 2017 inklusive letztem Patch-Level zu installieren und dann diesen SQL Server gemäß Best-Practice-Vorgaben zu konfigurieren.

Wie bereits im zweiten Teil der DSC Serie erläutert, habe ich mittels DSC-Configuration alle notwendigen Dateien – unter anderem das aktuelle ISO-Image des SQL Servers 2017 und das letzte Cumulative Update – auf den Zielserver kopiert. (Im Bild wurde nur noch der SOLL-Zustand kontrolliert, es waren keine Aktionen notwendig!)

Auf diesem Stand kann man aufbauen und endlich mit der eigentlichen Installation beginnen, dazu benötigen wir

• das ISO-Image (en_sql_server_2017_developer_x64_dvd_11296168.iso)
• das letzte Update (SQLServer2017-KB4466404-x64.exe)
• die ConfigurationFile.ini
• und die benötigten Powershell-Module (z.B. dbatools, SecurityPolicyDsc, SqlServerDsc usw.)

In der ConfigData.psd habe ich hinterlegt, welche Rolle bzw welche Konfigurations-Parameter der einzelne Server erhalten soll, was in meinem aktuellen Beispiel für alle Server identisch ist, aber in anderen Umgebungen unter Umständen anders sein kann.

@{
    AllNodes = @(
        @{
            NodeName        = "*"
            PSDscAllowPlainTextPassword = $true
            PSDscAllowDomainUser =$true
            SQLInstallPath     = "D:\SQL2017"
            InstanceName    = "MSSQLServer"
        },
        @{
            NodeName        = "sqlvm01"
            Role            = "SqlServer"
        },
        @{
            NodeName        = "sqlvm02"
            Role            = "SqlServer"
        }
        @{
            NodeName        = "sqlvm03"
            Role            = "SqlServer"
        }
        @{
            NodeName        = "sqlvm04"
            Role            = "SqlServer"
        }
    )
}

Murphy hat auch zugeschlagen

Aber von vorne… Auf meinen Test-Maschinen sqlvm01 und sqlvm02 habe ich „rumgespielt“, ohne wirklich zu protokollieren, was ich wie wann warum gemacht habe… also was habe ich – aus welchen Gründen – auf den beiden Maschinen lokal ausgeführt bzw durchgeführt, was hinterher dazu führte, dass meine Skripte funktionierten??? Bereits beim sqlvm03 und später auch beim sqlvm04 funktionierten meine Skripte nicht mehr wie gewünscht… Eigentlich war ich sehr zufrieden wie meine Skripte auf den ersten beiden Maschinen einwandfrei alle Dateien erhielten, dann der SQL Server 2017 installiert wurde und abschließend konfiguriert wurde mittels Desired State Configuration. Alle vier SQL Server wurden identisch in der selben Ressourcengruppe ausgerollt, konfiguriert. Folgende Aktivitäten habe ich auf allen Maschinen durchgeführt, insbesondere auf den Maschinen sqlvm03 und sqlvm04 (dort explizit nur diese Aktivitäten)

• Network Discovery aktiviert
• alle Platten eingebunden und formatiert
• in die Ziel-Domäne gehängt

Und dann vom Domänen-Controller aus mittels DSC-Push die Configurations – wie zuvor beschrieben – auf die Zielserver ausgerollt… aber leider wollte die Script-Ressource nicht so wie ich… auf 01/02 konnte ohne Probleme das ISO-Image für die SQL Server Installation als Laufwerk gemountet werden, aber auf 03/04 ums verr….en nicht… Egal was ich machte, egal wie ich es auch drehte, ich konnte nie auf das Laufwerk und somit auch nicht auf die „setup.exe“ zugreifen.

Der Neubeginn – Alles zurück auf 0,25

Wie es dann manchmal auch so ist… man hat natürlich keine Sicherung von irgendwelchen Skripten (egal ob funktionierend oder nicht)… ich hatte zumindest im selben Ordner immer wieder Version-Ordner angelegt, wenn ich mit „Meilensteinen“ erfolgreich war, aber eine richtige Sicherung hatte ich nicht und schon gar nicht meine Arbeiten in eine Versionierungs-Software eingebunden. So kam es, wie es kommen musste! Ich löschte mittels Powershell den falschen Ordner und alles war weg, nur was noch in Visual Studio Code geöffnet war (3 Dateien) konnte ich retten.
Eigentlich habe ich – keine Ahnung wo der Fehler herkam – nahezu die komplette C-Platte gelöscht… kein Internet Browser mehr, kein Powershell mehr, es ging fast nichts mehr… es war halt am einfachsten den Server neu aufzusetzen (wenn man wie ich kein Backup hat) => es war ja auch nur der Domänen-Controller 😮

Dieses unschöne Ereignisse habe ich aber zum Anlass genommen, meine komplette Entwicklungsumgebung aufzuräumen und „ein wenig anders“ aufzusetzen… eigentlich ist alles beim alten geblieben, nur das ich nicht mehr auf dem Domänen-Controller selber entwickeln werde und meine Skripte nicht mehr lokal auf dem Server ablege, bei anderen Projekten bin ich bereits diesen Weg gegangen. Also einen neuen Windows Server 2016 (Standard DS1 v2) aufsetzen, die Active Directory und DNS Rolle ausrollen und konfigurieren. Zusätzlich gibt es jetzt eine Windows 10 Maschine (Standard A4m v2), auf der ich meine Skripte entwickeln werde.

aus Fehlern lernen macht stärker

Um also meinem Lernziel oder auch dem Projektziel in Sachen „Automatisierte Installation von SQL Servern mit Desired State Configuration“ wieder näher zukommen, musste ich leider wieder von vorne beginnen… diesmal aber mit einem etwas anderen Lösungsansatz. 😉
Meine erste Lessions-learned… Erstelle eine Sicherung aus einer „Blanko-Maschine“, damit man schneller auf den ursprünglichen Server zurückkommt. Meine zweite Lessions-learned… mache ansonsten alles mit Skripten (die werde ich in einem weiteren Blog-Post veröffentlichen)

Aber wieder zurück zum Theme DSC – ich bleibe bei meinen einleitenden Aktivitäten, dem Kopieren der Powershell-Module und den Installationsmedien auf den jeweiligen Zielserver, was auch geblieben ist ist das Überprüfen ob das notwendige .NET-Framework installiert ist, ansonsten wird es nachinstalliert. Diesmal orientiere ich mich ein wenig (oder auch etwas mehr) an Chris Lumnah (Blog), der anhand einer Einführung in DSC aus der Microsoft Virtual Academy und eigenem Wissen ein Script zusammen gebaut hat, welches ich adaptieren möchte, da es nicht mit der DSC-Script-Ressource arbeitet, sondern mit der „richtigen“ SQLServer-DSC-Ressource.

Mehr dann im nächsten Blog-Beitrag, da ich nun leider wieder einen Tag für das Neu-Aufsetzen bzw den Neuanfang meiner DSC-Skripte aufbringen musste…
Sorry und Danke für euer Verständnis!

Björn Peters

Björn arbeitet auch weiterhin aus Mexiko als Senior Consultant – Microsoft Data Platform und Cloud für die Kramer&Crew in Köln. Auch der Community bleibt er aus der neuen Heimat treu, er engagiert sich auf Data Saturdays oder in unterschiedlichen Foren. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure SQL für Science-Fiction, Backen 😉 und Radfahren.