PowerShell unter Linux unter Windows (Linux-PowerShell ohne Linux VM)

Eine PowerShell unter Linux, die direkt unter Windows läuft? Dank dem relativ neuen Windows Subsystem for Linux ist das grundsätzlich alles kein Problem mehr. Zuerst muss das WSL installiert werden, das mit dem aktuellen Creators Fall Update von Windows 10 offiziell geworden ist (für Windows Server 2016 wird ein Update geben). Danach wird ein Linux aus dem Windows Store installiert, z.B. Ubuntu.

Wie das WSL installiert wird, beschreibe ich in einem anderen Blog-Eintrag: http://winhub.de/?p=154

Danach startet man die Bash und installiert die PowerShell für Linux genauso so wie es auf der GitHub-Projektseite z.B. für Ubuntu 16.04 beschrieben wird:

https://github.com/PowerShell/PowerShell/blob/master/docs/installation/linux.md#ubuntu-1604

Anschließend wird die PowerShell durch Eingabe von „powershell“ gestartet. Windows PowerShell und Linux PowerShell laufen damit parallel in zwei Fenstern. Einen zwingenden Anwendungsfall gibt es dafür natürlich nicht. Wer die beiden PowerShell-Varianten vergleichen oder sich in einer Linux-Umgebung bewegen könnte, kann dies jetzt sehr einfach tun, da keine VM mehr einrichtet werden muss – ressourcenschonender dürfte diese Variante daher auch sein.

Tipp: Json-Daten flexibel verarbeiten

Das JavaScript Object Notation-Format, kurz JSON, kommt immer mehr in Mode, da Webservice-Aufrufe auch im Admin-Alltag eine Rolle spielen.

Das folgende Beispiel ist aus der Notwendigkeit entstanden, den Inhalt einer JSON-Datei, die in einem Webverzeichnis liegt, verarbeiten zu müssen. Mehr oder weniger ad-hoc.

Die URL der Datei ist http://www.activetraining.de/Nanohub/Kurs1001.json.

Das Herunterladen erledigt Curl:

Hinter Curl steckt natürlich nicht das vielseitige Allround-Kommandozeilentool, sondern lediglich das Invoke-WebRequest-Cmdlet. Die Rückgabe ist daher nicht Text, sondern ein WebResponseObject-Objekt. Der heruntergeladene Inhalt steckt in der Content-Property, aber als Byte-Folge.

Gesucht ist daher eine „Trick“, um aus der Byte-Folge Text zu machen. Wer sich ein wenig mit .NET auskennt weiß, dass es dafür die Encoding-Klasse gibt, die verschiedene „Encoder“ über statische Properties zur Verfügung stellt. Eine gute Wahl ist immer der Default-Encoder. Ein wenig ungewöhnlich ist (jedenfalls für mich;), dass jede statische Encoder-Eigenschaft für ein Objekt steht. Unter anderem bietet jedes Objekt eine GetText-Methode, die eine Byte-Folge in einen Text umwandelt.

Der folgende Aufruf macht aus einer Byte-Folge daher Text:

Das Ganze soll allerdings in eine Function eingebaut werden, so dass sich der Byte-Inhalt direkt nach dem Aufruf von Curl in Text umwandeln lässt.

Auftritt PowerShell-Konsole und dem genialen PSReadLine-Modul, das ab Windows Server 2016 und Windows 10 bekanntlich fest dabei ist und ansonsten per Install-Module PSReadline -Force nachgeladen wird. Dank PSReadline ist es kein Problem, eine komplette Function-Definition in die Konsole einzugeben:

Das Beste daran ist, dass die komplette Function-Definition komfortabel editieren kann. Einfach per [Pfeil oben]-Taste und den üblichen Tasten für die Textbearbeitung. Einfach und genial.

Die Umwandlung des heruntergeladenen JSON in Objekte sieht damit wie folgt aus:

Dank PSReadline lassen sich auch Function-Definitionen in der Konsole komfortabel bearbeiten

Dank PSReadline lassen sich auch Function-Definitionen in der Konsole komfortabel bearbeiten

Meine ersten Schritte mit Docker und wie man einen Linux-Admin von der PowerShell überzeugen kann (Teil 1)

Docker ist das Hype-Wort der Stunde. Zum allergrößten Teil steckt hinter Docker natürlich eine solide Technik und wenig Hype, aber wer die Ankündigungen der Hersteller, inklusive Microsoft, in den letzten 1-2 Jahren verfolgt hat, wird festgestellt haben, dass das Wort Container bzw. Docker als wichtigste Container-Technik Pflichtbestandteil von strategischen Ankündigungen geworden ist. Die IT-Branche braucht alle paar Jahren ihr „next bing thing“ und das ist auch ja grundsätzlich in Ordnung.

Docker ist eine Container-Technik. Eine Container ist eine virtuelle Umgebung, in der eine Anwendung alle für die Ausführung benötigten „Abhängigkeiten“ in Gestalt der entsprechenden Dateien inklusive Dateisystem und Netzwerkschnittstelle vorfindet. Im Unterschied zur Virtualisierung ist der Aufwand deutlich geringer, da alle Container unter einem bestimmten Betriebssystem ausführen – ein Container kann aber auch sein eigenes Betriebssystem mitbringen. Container bieten daher zahlreicher Vorteile für die Bereitstellung, von der vor allem Webanwendungen und generell Anwendungen ohne eigene Benutzeroberfläche profitieren. Sie benötigen weniger Arbeitsspeicher, weniger Festplattenspeicher, starten schneller als eine VM, sind offenbar deutlich besser skalierbar, können im Verbund (Stichwort: Kubernetes, das nächste Hype-Wort nach Container) eingesetzt, lassen sich schnell erstellen. Sozusagen eine Wegwerfverpackung für eine Anwendung.

Mit der PowerShell gibt es zunächst keine Berührungspunkte. PowerShell-Skripte sind bekanntlich keine Anwendungen, sie werden auf einfachste Weise bereitgestellt und es gibt nur selten Abhängigkeiten, die vor ihrer Ausführung aufgelöst werden müssten – Module und DSC-Ressourcen fallen mir natürlich ein. Die Ausführung eines Skripts in einem Container könnte daher eine Option sein, wenn mehrere Module verwendet oder eine Abhängigkeit zu einer bestimmten Version des .NET Framework oder in Zukunft auch .NET Core besteht. In diesem Fall gibt man einen Container weiter, aus dem das Skript gestartet wird.

Im Folgenden geht es um eine naheliegende Anwendung: Ich möchte die PowerShell unter Ububtu, Cent OS oder Suse ausprobieren, habe aber eine Lust für jedes OS eine VM einzurichten.

Die gute Nachricht ist, Microsoft bietet ein fertiges Image für einen Container an, in dem Ubuntu 16.04 und eine Beta der PowerShell 6.0 enthalten sind.

Wie das Ganze umgesetzt wird, ist auf der Projektseite der PowerShell Core beschrieben:

https://github.com/PowerShell/PowerShell/tree/master/docker

Die Umsetzung ist sehr einfach. Voraussetzung sind allerdings Windows 10 64 Bit bzw. Windows Server 2016, da sich Docker für Windows nur auf diesen Betriebssystemen installieren lässt.

Die Downloadadresse ist von Docker CE (Community Edition) ist:

https://store.docker.com/editions/community/docker-ce-desktop-windows

Eine weitere Einschränkung besteht darin, dass Docker auch unter Windows einen Linux-Kernel erfordert. Dieser wird bei Docker for Windows über eine Hyper V-VM zur Verfügung gestellt. Es muss daher möglich sein, Hyper V zu aktivieren. Wer bereits VMware Workstation verwendet, müsste VMware Workstation vorübergehend deinstallieren, damit Hyper V aktiviert werden kann.

Wurde Docker for Windows installiert, dauert es einen kurzen Augenblick ist der Dienst zur Verfügung steht. Anschließend steht das Docker-Befehlszeilentool zur Verfügung.

Der folgende Befehl lädt ein Docker-Image mit installierter PowerShell:

Tipp: Sollte es zwischendurch zu „Verbindungsproblemen“ kommen, die dazu führen, dass das Image nicht oder nur unvollständig geladen wird, die folgende kleine Änderung hat bei mir immer geholfen: Trage für den DNS-Server in der Netzwerkverbindung die Adresse 8.8.8.8 ein, der Google-DNS-Server bietet eine sehr schnelle Namensauflösung.

Etwas später startet die PowerShell Core unter Ubuntu in einem Container. Wie lässt sich das feststellen? Gar nicht, denn es ist ja gerade der Sinn und Zweck eines Containers, dass die Anwendung in ihrer vertrauten Umgebung ausführt.

PowerShell Core läuft unter Windows in einem Container mit Linux Ubuntu als OS

PowerShell Core läuft unter Windows in einem Container mit Linux Ubuntu als OS

Jetzt würde es mich doch interessieren, unter welcher Linux-Version die PowerShell ausführt. Als absoluter Linux-Noob fällt mir spontan keine Lösung ein. Unter Linux gibt es kein WMI, sonst wäre es sehr einfach, den Titel und die Version des OS per Win32_OperatingSystem abzufragen. Aber wozu gibt es das Internet? Eine kurze Recherche ergibt, dass man sich nur den Inhalt einer Datei ausgeben lassen muss:

Die Ausgabe besteht aus einer Reihe Zeilen, die alle gleich aufgebaut sind: Name = Wert. Für einen Linux-Admin ist das Zerlegen von Text mit Tools wie Awk und Sed sein tägliches Brot. Doch wenn selbst eine einfache Lösung aus zwei bis drei Zeilen Text besteht, der jede Menge „Spezialzeichen“ enthält, stellt sich die Frage, ob es nicht eine einfachere Lösung gibt. Die gibt es natürlich und besteht darin, den split-Operator im Rahmen einer ForEach-Wiederholung für jede Zeile auszuführen und das Ergebnis der besseren Weiterverarbeitbarkeit zu Liebe als Objekte auszugeben.

Der folgende PowerShell-Befehl macht genau das:

Oder

Ich bin mir sicher, dass Beispiele wie dieses auch bei Linux-Admins schnell ein gewisses Interesse an der PowerShell wecken dürften. Ob sie dabei in einem Container läuft oder nicht spielt dafür natürlich keine Rolle.

Der Inhalt einer Textdatei unter Linux per PowerShell in Objekte zerlegt

Der Inhalt einer Textdatei unter Linux per PowerShell in Objekte zerlegt

PowerShell-Usergroup-Treffen mit PowerShell-Prominenz am 16.9.2017

Am Samstag, den 16.9.2017 findet von 9 (!) bis 18 Uhr in Stuttgart (oder in der näheren Umgebung) erstmals ein PowerShell-Saturday mit einer Reihe interessanter Vorträge statt. Auf der Sprecherliste stehen mit Chrissy LeMaire und Rob Seweel zwei bekannte Köpfe aus der internationalen PowerShell-Community.

Der Ort für die Veranstaltung steht noch nicht fest, da er von der Teilnehmerzahl abhängt. Es wäre daher gut, wenn sich jeder Interessierte möglichst bald (am besten Jetzt) anmelden würde:

https://www.eventbrite.com/e/powershell-saturday-stuttgart-tickets-36601493051

Die Liederhalle muss glaube ich nicht angemietet werden, aber es wäre schön, wenn die Veranstaltung auch tatsächlich im Großraum Stuttgart stattfinden würde.

Neben den angekündigten Vorträgen hat jeder, der kommt, wie immer die Gelegenheit etwas Eigenes (sofern es mit PowerShell zu tun hat) vorzustellen.

Bilder von einem USB-Stick auf eine Freigabe kopieren

Ausgangspunkt ist ein USB-Stick mit einer Reihe von Bilddateien, die auf verschiedene Ordner verteilt sind. Es sollen alle Bilder in einen (!) Ordner auf einem NAS kopiert werden.

Der naheliegende Versuch schlägt fehl:

Grund: Fehlende Authentifierung. Copy-Item besitzt aber einen Credential-Parameter, beim Kopieren von Dateien spielt er aber keine Rolle.

Lösung: Anlegen eines PSDrive

Damit steht das Laufwerk NAS: Neuer Anlauf.

Es funktioniert, aber es wird die Ordnerstruktur kopiert. Ich möchte aber, dass alle Bilder in ein Verzechnis kopiert werden.

Lösung: Anstelle vom Recurse-Parameter bei Copy-Item ein dir aka Get-ChidLitem und die Pipeline verwenden.

Mein neues PowerShell 5.1-Buch ist da!

Ein Buch zu schreiben ist längst kein der großen Herausforderungen mehr, die es vielleicht früher einmal war. Sozusagen Mensch gegen das leere Blatt und am Ende soll ein Stück Weltliteratur herauskommen. Das gilt besonders für ein IT-Fachbuch. In erster Linie braucht ein angehender Autor eines IT-Fachbuches eine Portion Know-how, ein gewisses Mitteilungsbedürfnis, die Fähigkeit sich in ganzen Sätzen halbwegs nachvollziebar ausdrücken zu können, viel Ausdauer, Durchhaltevermögen, Sitzfleiß, einen halbwegs bequemen Stuhl, sehr viel Zeit, die Bereitschaft Wochenende um Wochenende am Schreibtisch zu verbringen und einen Verlag, der bereit ist das Risiko einzugehen. Ich bin daher dem Springer Vieweg Verlag dankbar, dass er auch Themen eine Chance gibt, die nicht in den klassischen IT-Mainstream fallen.

Doch warum geht es eigentlich in diesem Eintrag? Genau, vor kurzem ist mein Buch „PowerShell 5.1 für Administratoren“ beim Springer Vieweg Verlag erschienen. Auf knapp 350 Seiten (das klingt eventuell nach wenig Inhalt, aber es sind wenige Abbildungen, kleine Schrift;) geht es vor allem um die etwas anspruchsvolleren und „modernen“ PowerShell-Themen:

>Umgang mit Typen und Objekten
>Umgang mit Klassen und was damit alles möglich ist
>Functions und Parameter
>Aus Texten Objekte machen

Eine Motivation das Buch zu schreiben war für mich, dass es zwar viele sehr gute Einsteigerbücher zur PowerShell gibt, aber wenige Bücher, die auf diesem Wissen aufsetzen. Wer etwas tiefer in die Thematik einsteigen und auch den Unterbau der PowerShell verstehen möchte und wem es Spaß macht, sich mit für Administratoren etwas abstrakte Themen zu beschäftigen, sollte mit meinem Buch eingies dazu lernen. Aus meinen Schulungen weiß ich, dass in der Hilfe zwar vieles steht und zudem sehr gut beschrieben ist, ein Buch aber immer noch einen höheren Stellenwert hat.

Ein Schwerpunkt des Buches ist das Thema DSC, das auf drei Kapiteln behandelt wird. Ein weiteres Thema ist PowerShell und Azure. Zu den praxisnahmen Themen gehört die AD-Verwaltung und das Absichern von Endpoints mit JEA. Wie immer gibt es auch ein „Spaß mit PowerShell“-Kapitel, in dem es u.a. um Abspielen von Noten, den in Windows eingebauten Zitateserver und eine farbige Konsole geht (wie man Unicode Emojis anzeigt habe ich leider erst vor kurzem herausgefunden).

Wichtig: Was das Buch allerdings nicht ist: Es ist keine Einführung für PowerShell-Neulinge, auch wenn dies der Untertitel des Buches suggerieren könnte. Wer daher die PowerShell noch lernt bzw. sie nur sporadisch verwendet und nur verstehen möchte, wie man Befehle eintippt oder einfache Abläufe automatisiert und damit vollkommen zufrieden ist, sollte zuerst ein anderes Buch lesen, wie z.B. das sehr gute Buch von Tobias Weltner oder „das Werk“ zur PowerShell von Holger Schwichtenberg.

Es gibt noch mehr: Ein weiteres Thema ist natürlich DevOps, das aber nur dezent angedeutet wird. Im Wesentlichen besteht der DevOps-Teil aus dem Aufbau einer sog. „Replease-Pipeline“ mit den üblichen Zutaten (GitHub, AppVeyor, Yaml, Pester, ScriptAnalyzer und Package Manager), über das sich ein in VS Code erstelltes Modul auf Knopfdruck so bereitstellen lässt, dass es sich alle Anwender per Install-Module lokal installieren können, und vor allem, dass es den gesetzten Qualtiätsforderungen entspricht. Ich war selber beeindruckt als mir klar wurde, welche Möglichkeiten PowerShell-PowerUsern heutezutage (in der Regel sogar kostenlos) zur Verfügung stehen.

Die Beispielprogramme zu dem Buch (es sind einige) werde in Kürze an dieser Stelle veröffentlichen. Bei Fragen freue ich wie immer über Feedback. Als Kommentar zu diesem Blog-Eintrag oder direkt per Mail oder telefon.

Mein neues Buch zur PowerShell 5.1

Mein neues Buch zur PowerShell 5.1

Active Directory – das Ablaufdatum eines Benutzerkontenkennworts abfragen

Für das Abfragen der kontenspezifischen Details eines Benutzerkontos gibt es bekanntlich das Search-ADAccount-Cmdlet. Damit lassen sich folgende Kontendetails abfragen:

>Ob ein Konto deaktiviert ist
>Ob ein Konto abgelaufen ist
>Ob sich der Benutzer ausgesperrt hat („locked out“), z.B. durch Mehrmalige Eingabe eines falschen Kennworts
>Ob das Kennwort abgelaufen ist
>Ob das Kennwort niemals abläuft
>Ob ein Konto innerhalb einer angegebenen Zeitspanne ablaufen wird
>Ob ein Konto innerhalb einer angegebenen Zeitspanne inaktiv war

Die letzten beiden Fragen beziehen den TimeSpan-Parameter mit ein. Es gilt die Konvention, dass die Übergabe einer Zahl als String als Tage interpretiert wird. Ansonsten wird der Parameterwert (wie in der Hilfe beschrieben) im Format 90.00:00:00 für 90 Tage übergeben.

Nicht dabei ist ein Parameter über das Abfragen des Ablaufdatums eines Kennworts. Aus gutem Grund, denn diese Eigenschaft hängt u.a. von den Kennwortrichtlinien ab und dem Umstand, dass für das Kennwort ein Ablaufdatum explizit festgelegt wurde was in der Regel nicht der Fall sein dürfte.

Die folgende Befehlsfolge gibt die Ablaufdaten sämtlicher (!) Benutzerkonto der Domäne aus, sofern ein solches existiert. Das Beispiel versteht sich in erster Linie als ein Vorschlag und ist noch nicht perfekt. Ich habe vor Jahren im PowerShell-Teamblog eine Function gefunden und sie endlich einmal selber umgesetzt. Über Kommentare und Verbesserungsvorschläge freue ich mich natürlich. Ich habe auch nicht im Internet geschaut, ob es vielleicht eine bessere Umsetzung gibt.

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.

Neue Richtung für die PowerShell – alles auf Open Source und Cross-Plattform, die Windows PowerShell als Auslaufmodell

Vor einigen Tagen hat das PowerShell Team bei Microsoft in einem Blog-Eintrag die künftige Richtung skizziert, die die PowerShell (in Zukunft;) nehmen soll:

https://blogs.msdn.microsoft.com/powershell/2017/07/14/powershell-6-0-roadmap-coreclr-backwards-compatibility-and-more/

Die wichtigsten Aussagen sind für mich in Kurzform:

>Die Entwicklung von WMF 5.1 und der Windows PowerShell 5.1 wird praktisch eingestellt. Es sollen lediglich wichtige Bux-Fixes vorgenommen werden. Das bedeutet natürlich nicht, dass WMF und damit die PowerShell bei Windows Server irgendwann (auf absehbare Zeit) nicht mehr von Anfang an dabei sind wird. Es bedeutet, dass es keine neuen Versionen von WMF mehr geben wird und auch ein Windows Server 2018, 2020 usw. das WMF 5.1 enthalten wird, das irgendwann als optionales Feature nachinstalliert werden muss.

>Die künftige Entwicklung der PowerShell fokussiert sich auf die Open Source PowerShell (PowerShell Core), die in der Version 6.0 bereits vor einiger Zeit für „Ende des Jahres“ in Aussicht gestellt wurde. Die neue PowerShell wird es immer für alle wichtigen Plattformen (Linux, Mac OSX und natürlich Windows geben).

Da diese PowerShell auf .NET Core basiert und nicht auf dem .NET Framework, lassen sich einige Merkmale nicht abbilden. Das betrifft vor allem Workflows.

Alles in allem ist das keine dramatische Ankündigung, da es WMF und die PowerShell 5.1 noch viele Jahre geben wird und es für ca. 95% aller Anwender keinen echten Bedarf an neuen Funktionalitäten geben dürfte. Würde Microsoft die Entwicklung der PowerShell komplett einstellen, die meisten Anwender würden es gar nicht mitbekommen (an Cmd.exe wurde vermutlich seit über 20 Jahren nichts Neues mehr hinzugefügt).

Sollte man unbedingt ein Merkmal nutzen wollen, da es nur in der PowerShell Core gibt (in Aussicht gestellt wurde z.B. eine verbesserte Parallelverarbeitung), sollte es kein Problem sein, das Skript mit der neuen PowerShell Core auszuführen, die parallel zur alten PowerShell betrieben werden kann.

Was mich an dem Richtungswechsel etwas stört ist, dass er für mich einmal mehr deutlich macht, dass unter dem „neuen“ CEO Satya Nadella Windows Server nach und nach auf ein Abstellgleis geschoben wird was Innovationen für kommende Version angeht. Ca. 90% aller Windows Administratoren dürften sowohl der Umstand, dass die PowerShell Open Source ist als auch der Umstand, dass sie auf jede Plattform portiert werden kann, so gut wie egal sein, sofern sie das überhaupt mitbekommen. Es wird also eine Produktpolitik weit weg von den Anforderungen und Wünschen der Kunden betrieben.

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