Netzwerktools und ihre PowerShell-Pendants

Beim Vorbereiten auf einen MOC-Kurs zu Windows 10 ging es auch um die Netzwerkkonfiguration. Es ist erfreulich, dass in den aktuelleren MOC-Unterlagen auch die PowerShell inzwischen erwähnt wird und Gegenstand einiger Demos und Labs ist.

Da auch für mich als PowerShell-Kenner nicht immer auf Anhieb einfällt was z.B. das Pendant zu Nslookup oder ipconfig /flushdns ist, bin ich froh den folgenden Blog-Eintrag gefunden zu haben, in dem der Autor die klassischen Netzwerkkommandos den PowerShell-Befehlen gegenüberstellt:

https://blogs.technet.microsoft.com/josebda/2015/04/18/windows-powershell-equivalents-for-common-networking-commands-ipconfig-ping-nslookup/

Ein wenig kurios ist allerdings, dass dem Autor nicht klar war, dass PowerShell 5.0 zu verwenden nicht automatisch bedeutet, dass Befehle wie Get-NetIPAddress zur Verfügung stehen, da diese Teil des Betriebssystems und nicht der PowerShell sind. Das Ergebnis waren daher auch ein paar „bei mir läuft es nicht, obwohl ich Version 5.0 verwende“-Kommentare.

Was ich noch suche ist ein Pendant zu dem sehr praktischen Portqry.exe, das aber zuerst von einer Microsoft-Seite heruntergeladen werden muss.

Kleine Tipps für Zwischendurch: Alle Dienstnamen pro Svchost-Prozess ausgeben

Vor kurzem habe ich in einem Blog-Eintrag eine PowerShell-Befehlsfolge gefunden, die zu jedem Svchost-Prozess die Namen der Dienste ausgibt, die von diesem Prozess ausgeführt werden. Die Lösung war gut, aber leider sehr umständlich. Vermutlich war der Autor Entwickler und hat ein wenig zu sehr die Entwicklerdenkweise bei der Umsetzung der eigentlich einfachen Aufgabenstellung angewendet. Bei mir hat es auch ein paar Jahre gedauert bis ich mir diese Denkweise bei der PowerShell abgewöhnt hatte.

Mein Vorschlag für eine Unmsetzung sieht wie folgt aus.

Es kann lediglich eine Weile dauern bis eine Ausgabe erscheint.

Kleine Tipps für Zwischendurch: Wird ein Skript als Administrator ausgeführt?

Diese (harmlose) Frage „verfolgt“ mich seit der ersten PowerShell-Version. Es hat eine Weile gedauert bis mir der Hintergrund klar war.

Man holt sich zuerst die aktuelle Identität über [Security.Principal.WindowsIdentity]::GetCurrent() und macht daraus ein neues WindowsPrincipal-Objekt, das für den aktuell angemeldeten Benutzer steht. Dann muss nur noch geprüft werden, ob dieser Mitglied der Administratorengruppe ist.

Unter einem englischen Windows heißt die Gruppe „Administrators“, unter einem Französischen vermutlich „Le Administrateurs“ usw.

Mit der neuen statischen New-Methode, die es ab Version 5.0 bei jedem RuntimeType-Objekt gibt, wird der Aufruf noch etwas einfacher als in der Vergangenheit.

Noch einfacher wird es, wenn das Carbon-Modul geladen wurde, das mir insgesamt sehr gut gefällt. Dann genügt ein Test-AdminPrivilege.

Kleine Tipps für Zwischendurch: Eine IP-Adresse als Binärzahl ausgeben

Vielleicht gibt es eine einfachere Variante, aber bei der Folgenden gefällt mit die Unmsetzung gut:

So sieht die Adresse als Binärzahl aus:

Chocolatey mit Chocolatey installieren

Laut „Der Postillon“ ist das Henne oder Ei-Problem endlich gelöst: Das Ei war zuerst da.

Ein wenig erinnert mich diese humorvolle Meldung an die Installation der Package Managers Chocolatey per Install-Package und dem Chocolatey-Provider, der aber nachträglich installiert werden muss. Dank des ForceBootstrap-Parameters ist das kein Problem.

Der Pfad von Choco.exe muss allerdings zu Fuß zur Path-Umgebungsvariablen hinzugefügt werden:

Die Beispiele zu einem Buch „Windows Server Administration mit PowerShell 5.1“

Die Beispiele zu einem Buch „Windows Server Administration mit PowerShell 5.1“ sind jetzt endlich komplett und stehen unter der folgenden Adresse bereit:

https://github.com/pemo11/WindowsServerAdminMitPowerShellBeispiele

Es hat ein wenig länger gedauert als geplant. Ich hoffe, dass niemand darauf gewartet hatte und mit dem Buch deswegen nichts anfangen konnte.

Der Download der Beispiele ist sehr einfach – Voraussetzung ist lediglich, dass Git für Windows installiert wurde. Dann steht das git-Kommando auch in einer PowerShell-Konsole zur Verfügung.

Schritt 1: Anlegen eines neuen Verzeichnisses – der Name ist egal

Schritt 2: Clonen des Repo durch Eingabe von

Die Beispieldateien werden damit in das Verzeichnis kopiert.

Ein paar Beispiele, in erster Linie aus den DSC-Kapiteln, können nicht direkt ausgeführt werden, da ein Computername fest verdrahtet ist.

Eine Zip-Datei folgt in Kürze.

PS: Für Fragen zu allen Themen, die direkt oder indirekt etwas mit dem Buch zu tun haben: Es gibt in diesem Blog auch ein Forum.

Kleine Besonderheiten beim Umgang mit einer OrderedDictionary-Collection und wie man sie löst

Nach mehr als 10 Jahren intensiver PowerShell-Nutzung komme ich immer öfter in Situationen, in die Art und Weise wie PowerShell mit (Daten-) Typen umgeht einiges an Nerven kostet und ich mehr und mehr frage, ob dies bei richtigen Skriptsprachen wie Python oder Ruby auch so ist. Ein „Fehler“ aus heutiger Sicht war sicherlich, dass das PowerShell-Team damals im Jahr 2004 das Typensystem des .NET Framework übernommen hatte, das damals selber noch ganz neu war und erst in der Version 1.1 vorlag. Aus meiner Sicht wäre es besser gewesen, wenn die PowerShell-Entwickler damals ein eigenes Typensystem implementiert und sich nur so wenig wie möglich an das .NET-Typensystem angedockt hätten. Aber diese Option gab es damals nicht.

Die „Besonderheit“, um die es in diesem Blog-Beitrag geht, wird nur auf den zweiten Blick deutlich. Ausgangspunkt ist eine Hashtable, also eine Liste von Schlüssel=Wert-Paaren. Hier ein Beispiel:

Bis zu diesem Punkt ist hoffentlich alles klar. Wir haben eine Hashtable mit drei Schlüssel-Wert-Paaren. Die Schlüssel sind „1000“, „2000“ und „3000“.

Ein Problem mit Hashtables ist, dass es keine Garantie gibt, dass die Elemente in der Folge ausgegeben werden, in der sie hinzugefügt wurden. Um dieses Problem zu umgehen, muss dem @{} nur ein [Ordered] vorangestellt werden.

Jetzt bleibt die Reihenfolge erhalten. Der Grund dafür ist ganz einfach, dass die Hashtable keine Hashtable mehr ist. Die Variable H steht jetzt für ein OrderedDictionary. Das bedeutet unter anderem, dass die Methode ContainsKey für das Abfragen eines Schlüsselwertes nicht mehr vorhanden ist. Ein Skript, dass diese Methode verwendet, muss daher angepasst werden.

Sehr viel schwerer wiegt, dass die Verwendung des Schlüsselwertes nicht mehr funktioniert.

Ein

führt zu keinem Ergebnis mehr. Ein Wert wird über die allgemeine Item()-Methode abgerufen. Aber auch hier gibt es eine „Besonderheit“. Damit der Wert als Schlüssel und nicht als Index erkannt wird, muss der vom Typ Object sein.

Ein

liefert wieder nichts. Ein

liefert den Wert „Wert 1“.

Bei solchen Klimmzügen frage ich immer, wenn ich mit meinen 10+ Jahren PowerShell-Know how ins Schwimmen komme und einiges probieren muss, um zu gewünschten Ergebnis zu kommen (allerdings komplett ohne Internet-Recherche), wie soll es ein typischer PowerShell-Anwender ohne Programmiererfahrung schaffen?

Die Lösung für die ganze „Hashtable-Problematik“ besteht für mich darin, auf das [Ordered] zu verzichten und damit zu leben, dass die Reihenfolge der Werte nicht der Reihenfolge entspricht, in der die Werte zur Hashtable hinzugefügt wurden.

PS: Ein kleiner Trick fiel mir beim Schreiben des letzten Absatzes ein: Per Typenkonvertierung in eine Hashtable verhält sich das OrderedDictionary wieder wie eine Hashtable und es gibt z.B. eine ContainsKey()-Methode.

Damit funktioniert auch der Zugriff über den Schlüssel wieder wie gewohnt:

PowerShell Conference Europe 2018 vom 17. bis 20.4.2018 in Hannover – die Agenda steht

Seit ein paar Tagen steht die Agenda für die nächste PowerShell Conference Europe 2018 fest, die vom 17. bis 20.4.2018 wie üblich in Hannover stattfinden wird.

Alles weitere gibt es hier: http://www.psconf.eu/

Auch wenn die Agenda noch ein paar freie Slots enthält, soviel steht bereits fest. Wie im letzten Jahr wird Jeffrey Snover die Eröffnungsrede halten und sicher sowohl am Abend als vermutlich auch an den anderen Tagen der Konferenz in Person anwesend sein, so dass es jede Menge Gelegenheiten geben wird sich mit dem Erfinder der PowerShell persönlich zu unterhalten oder das obligatorische Selfie zu schießen.

Ein weiteres Highlight ist die Anwesenheit vom Matt Graeber, einem Sicherheitsexperten, der PowerShell als Tool für den Umgang mit Exploits auserkoren hat und einige faszinierende Functions geschrieben hat, die tief in das Windows-Betriebssystem eingreifen.

Ansonsten sieht es so aus als wäre das PowerShell-Team aus Redmond nicht so zahlreich vertreten wie im letzten Jahr. Ein Themenhighlight wird sicher der Vortrag zu „DSC Core“ sein, der nächsten Version von DSC, die anders als ihre Vorgänger losgelöst von .NET Framework und PowerShell entwickelt wird.

Darüber hinaus gibt es den üblichen Mix an interessanten Themen und Vorträgen von den PowerShell-Gurus aus dem Aus- und Inland. Es ist ja eine europäische Konferenz. Mit Ravikanth C ist auch ein Sprecher aus dem fernen Indien mit dabei.

Die Konferenz geht dieses Mal über vier Tage. Entsprechend wurde der Preis angehoben. Die Teilnahme kostet jetzt 1.399€ plus Mwst. Auf der einen Seite ein stolzer Preis, auf der anderen Seite kostet soviel in der Regel auch der dreitägige MOC 10962 Advanced Automated Administration with Windows PowerShell bei vielen Anbietern. Geht man von meiner Erfahrung aus, dass solche Aufbaukurse nur selten zustande kommen, ist die Konferenz die Gelegenheit das eigene PowerShell-Know how zu vertiefen, Kontakte zu knüpfen, sich auszutauschen und an den Abenden einfach Spaß zu haben.

Der PowerShell Summit 2018, der in ersten April-Woche in der Nähe von Seattle in den USA stattfinden wird, ist bereits ausverkauft.

Praxistipp: RDP per PowerShell aktivieren

Der folgende Tipp ist eher ein „Note to self“, da man ihn „tausendfach“ im Internet findet. Eventuell nicht ganz so übersichtlich wie in meinem Blog.

Auf einemn frisch installierten Windows Server ist der RDP-Zugriff von außen zunächst deaktiviert.

Das folgende kleine PowerShell-Skript aktiviert den RDP-Zugriff. Im Kern geht es darum, ein bzw. zwei Einträge in der Registry zu setzen und eine Firewall-Regel zu aktivieren. Das muss natürlich nicht unbedingt per PowerShell-Remoting umgesetzt werden. Auch für das Setzen der Firewall-Regel gibt es zahlreiche Alternativen.

Die folgende Anleitung ist daher auch nur eine von vielen. Sie funktioniert in dieser Form erst ab Windows Server 2012 aufwärts, da hier PS-Remoting von Anfang an aktiv ist. Benutzername, einbruchsicheres Kennwort und IP-Adresse bitte anpassen.

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.