Archiv der Kategorie: Allgemein

Eine kurze Einführung in die PowerShell für erfahrene Skripter

Wer sein Leben lang eine klassische Skriptsprache (VBScript, Perl usw.) verwendet hat und nun mit der PowerShell arbeiten möchte, hat man Anfang oft unnötige Probleme und Startschwierigkeiten. Da bei der PowerShell vertraute Formalismen wie eine explizite Variablendeklaration oder ein expliziter AUsgabebfehl keine ROlle spielen bzw. optional sind, wirkt die PowerShell-Syntax für „Umsteiger“ ungewohnt, unlogisch und man tendiert schnell zu alles nur noch negativ zu sehen.

Ich muss zugegeben, dass ich am Anfang auch meine kleineren Problemee hatte, aber nach ein paar Jahren kam ich dann ganz gut mit der PowerShell-Syntax klar;)

Angeregt wurde ich für diesen Blog-Eintrag durch einen längeren Thread in einem Forum auf Administrator.de, in der der Fragesteller (offensichtlich ein älterer Mensch mit sehr viel VBScript-Erfahrung) mit der Art und Weise wie in PowerShell Arrays verwendet nicht klar kam und in jeder „geht leider immer noch nicht“-Antwort auf am Anfang sehr hilfsbereite Antworten immer mehr der Frust über die vermeintlich „grausame“ PowerShell-Syntax anklang. Am Ende schlug die Hilfsbereitschaft natürlich in Kritik um und er musste sich ein „Du wetterst hier seit Tagen über
PowerShell – irgenwie alles sch… aber allem Anschein nach fehlen dir die elementarsten Grundlagen“. Der Fragesteller gab dann auch später zu, dass er noch sehr viel lesen, lesen und lesen müsste, aber das ist für mich weder die Lösung noch die Ursache der offenkunding vorhandenen Unzufriedenheit.

Das grundsätzliche Problem ist eine überzogene Erwartungshaltung („mit PowerShell soll ja alles einfacher werden“ – wird meines Wissens nirgendwo behauptet) und die (falsche) Annahme, dass Techniken, die z.B. bei VBScript seit 20 Jahren angewendet wurden, sich 1:1 auf PowerShell übertragen lassen. Und wenn dann noch eine gewisse Ungeduld hinzu kommt, ist die Unzufriedenheit groß. Und wenn dann der Unzufriendende eine Multiplikator-Funktion besitzt und sich in der Firma oder in Foren über die vermmeintlichen Schwächen der PowerShell auslässt….

Die PowerShell ist nicht perfekt, aber sie ist nicht nur enorm leistungsfähig (das hilft Anfängern im Allgemeinen wenig), sondern weitestgehend konsistent. Das Problem, sofern man es als solches betrachtet ist, dass die Syntax keine Rücksicht auf VBScript&Co genommen wurde, Bruce Payette (der Kopf der PowerShell-Spprache) vielleicht nicht ein ganz so großes Genie ist wie Guido van Rossum (Python) oder Larry Wall (Perl) und die Version 1.0 unter einem enormen Zeitdruck veröffentlicht wurde. Der Vater der PowerShell, Jeffrey Snover, hat es auf der PowerShell Konferenz 2017 in Hannover so umschrieben, dass der Vorgesetzte bei Microsoft das ganze Projekt am liebsten wieder eingestampt hätte und dem Team irgendwann ein Ultimatum gestellt hatte – entwweder ihr bringt jetzt eine Version 1.0 oder das Projekt ist tot. Keine ganz optimale Voraaussetzung und eventuell eine Erklärung für einige der Inkosistenzen.

Hier sind meine persönlichen Regeln/Empfehlungen für einen Einstieg, der sich gerade an Anwender richtet, die sehr viel Erfahrung mit VBScript und anderen formalen Skriptsprachen besitzen.

Regel 1: Variablen müssen nicht deklariert werden

Regel 2: Es gibt keine Notwendigkeit Write-Host zu benutzen

Regel 3: Der Umgang mit Arrays ist einfach, man darf nur nicht wie ein Programmierer denken

Regel 4: Der Umgang mit mehrdimensionalen Arrays ist inkosistent und ein Schwachpunkt der PowerShell-Syntax

Regel 5: Zweidimensionale Arrays werden im Allgemeinen nicht benötigt

Regel 6: Es gibt ein Pendant zu Option Explizit

Regel 7: Halte es einfach

Regel 8: Verwende die Eingabehilfen und vor allem PSREadline

Regel 9: Freunde Dich mit Subexpressions an – am besten sofort

Regel 10: Aktualisiere die Hilfe und schau Dir die Beispiele zu Cmdlets und PowerShell-Befehlen an

Regel 11: Schreibe immer zuerst einen Test

Ok, diese Regel ist nicht ganz ernst gemeint.

Ich werde zu allen Regeln in naher Zukunft noch einiges schhreiben. Ich wollte die Regel erst einmal los werden, da sie frustrierten PowerShell-Anfängern eventuell helfen können. Und noch etwas: Keine Panik und alles wird gut;)

Http.sys Url Reservierungen per PowerShell und ein wenig „String-Vodoo“ löschen

Eine URL-Reservierung ist eine vorgegebene URL-Schreibweise, die z.B. für den Aufruf eines Webservice verwendet wird. URL-Servierungen spielen z.B. beim Aufruf eines WCF-Dienstes per HTTP/HTTPS eine Rolle. Möchte ich einen WCF-Dienst nicht über Port 80, sondern z.B. über Port 88 aufrufen, muss zuvor eine URL-Reservierung angelegt werden. Soll der Dienst per HTTPS aufrufbar sein, muss eine SSL-Bindung angelegt werden. Beides wird offiziell per Netsh durchgeführt.

Zu den wenigen Bereichen, für die es aktuell (Stand: Oktober 2017) nur wenige PowerShell-Commands gibt, gehören die Kommandos der Netsh-Shell. Ein Auflisten aller URL-Reservierungen geschieht per

Die Textausgabe ist relativ umfangreich und vor allem nicht sehr regelmäßig strukturiert. Grundsätzlich sollte man auch ohne einen Doktor in „Regex-Kunde“ zu haben, das Zerlegen des Ausgabetextes per Select-String, dem Match-Operator oder per [Regex] hinbekommen, da es lediglich darum geht, eine bestimmte Zeile herauszufischen.

Ein weniger einfacher und vor allem ganz ohne Regex-Zauber geht es unter Umständen mit dem mit der Version 5.0 eingeführten ConvertFrom-String-Cmdlet, wenngleich die folgende kleine Lösung auch nicht perfekt ist. Die Idee ist, dass der zu konvertierende Text anhand eines Musters in seine Bestandteile zerlegt wird. Das Muster besteht aus der ersten Zeilen des zu konvertierenden Textes, in dem die zu extrahierenden Bereiche einfach in geschweifte Klammern gesetzt werden. In dem in den geschweiften Klammern jeweils ein Name angegeben wird, kann der extrahierte Text später über diesen Namen angesprochen werden. Bei sich wiederholenden Bereichen folgt auf den Namen noch ein *.

Im Idealfall liefert ConvertFrom-String pro Übereinstimmung ein Objekt, bei dem der über eine Markierung markierte Text über die Eigenschaft geliert wird, die dem Namen der Markierung entspricht.

Das folgende Beispiel zerlegt den Output von netsh urlacl nach den Http-Adressen und löscht jede Reservierung. Vorsicht: Die Reservierungen werden tatsächlich gelöscht. Die Nutzung erfolgt daher auf eigenes Risiko.

Das kleine Beispiel versteht sich in erster Linie als Anschauungsbeispiel für das enorm leistungsfähige, leider aber auch immer noch recht kryptische wirkende ConvertFrom-String-Cmdlet.

Wer nur eine komfortable Möglichkeit sucht, URL-Reservierungen und SSL-Bindungen zu löschen ohne die Befehlszeile bemühen zu müssen, sollte den praktischen Http.sys-Manager von Nicolas Dorier verwenden:

https://www.codeproject.com/Articles/437733/Demystify-http-sys-with-HttpSysManager
bzw.

http://httpsysmanager.codeplex.com/

Das kleine WPF-Tool verwendet .NET-Klassen aus dem Namespace HttpSysManager.Core und HttpSysManager.Native. Theoretisch ließen sich die Klassen direkt in einem PowerShell-Skript verwenden. Wer also viel Zeit hat, kann sich in dieser Nische einen Namen machen, den ein PowerShell-Command scheint es noch nicht zu geben.

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

Eine PowerShell unter Linux, die direkt unter Windows läuft? Dank dem relativ neuen Windows Subsystem for Linux (WSL) 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 es 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 jeweils einem eigenen Fenster. Einen zwingenden Anwendungsfall gibt es dafür natürlich nicht. Wer die beiden PowerShell-Varianten vergleichen oder sich aus irgendeinem Grund in einer Linux-Umgebung bewegen möchte, kann dies jetzt sehr einfach tun, da keine VM mehr einrichtet werden muss – ressourcenschonender dürfte diese Variante daher auch sein.

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.

Die ersten Schritte mit Wireshark

Wireshark ist „das“ Tool für die Analyse von Netzwerkverbindungen, sprich von Paketen, die im Rahmen einer Netzwerkverbindung übertragen. Es gibt natürlich Alternativen, doch sind diese entweder nicht kostenlos oder nicht so komfortabel. Von Microsoft gab es vor vielen Jahren den Network Monitor, der offenbar mit der Version 3.4 eingestellt wurde. Er ist zwar noch als Download erhältlich, doch empfehle ich ihn nicht, denn Wireshark ist die deutlich flexiblere Alternative.

Ist man lediglich an HTTP/HTTPS-Paketen interessiert, wie sie z.B. bei PowerShell-Remoting anfallen, gibt es mit HttpDebuggerPro (nicht kostenlos) und Fiddler4, alternative Tools, die eventuell etwas einfacher zu bedienen sind.

Wireshark unterstützt sämtliche in Frage kommenden Protokolle, bietet eine komfortable Filtersyntax, ist bestens dokumentiert, es gibt eine große, weltweite Community (und sogar eine eigene Konferenz) und ist trotz unzähliger Einstellungen und angesichts einer Fülle von Details, die eine Paketanalyse zwangsläufig liefert, relativ einfach zu bedienen, u.a. dank einer durchdachten Benutzerführung. Es ist wirklich faszinierend, wie vielschichtig und detailreich die Internet-Protokolle sind. Vor allem angesichts der Tatsache, dass alles bereits in den 70er Jahren entstand und damit bereits über 40 Jahre alt ist.

Die Downloadresse von Wireshark ist: https://www.wireshark.org

Die Installation der Windows-Version ist schnell erledigt.

Für das allerste Kennenlernen empfehle ich den Datenverkehr zur eigenen Homepage zu analysieren. Hier kam man im Allgemeinen davon ausgehen, dass wirklich nur ein paar Seiten per HTTP abgerufen werden und keine Anfragen gegen Dutzende von Werbenetzwerken und Websites zur Datenauswertung gestartet werden, die alle im Detail in der Ausgabe erscheinen.

Tipp: Beim Betrachten einzelner Pakete fiel mir auf, dass nahezu überall der Begriff „Arcadyan_cc“ enthalten ist. Zunächst vermutete ich (natürlich;), dass mein Notebook jede Anfrage auch einen ominösen Rechner im Internet sendet und dieser sogar meinen Computer anpingt, um irgendwelche Schwachstellen zu finden. Eine kurze Internet-Recherche ergab, dass dahinter eine Firma aus Taiwan steckt, die u.a. Router und Modems herstellt. Eines dieser Produkte heißt bei uns Speedport und dürfte Telekom-Kunden bestens bekannt sein.

Das Einrichten eines Filters ist bei Wireshark sehr einfach. Gib in die Filterleiste z.B.

http.host contains „training“

ein, um nur Pakete von Http-Verbindungen zu sehen, die von einem Host stammen, in dessen Name „Training“ vorkommt. Ist der Filter in Ordnung wird er grün eingefärbt, ansonsten rot.

Es versteht sich von selber, dass man mit Wireshark Stunden verbringen kann und natürlich wissen muss, was einem da an Details präsentiert wird.

Noch ein Tipp zum Schluss, der Euch eventuell eine lästige Suche erspart. Werden auf einmal nur noch Pakete mit einem „UNKNOWN“-Protokoll angezeigt, habt ihr es irgendwie geschafft, alle Protokolle zu deaktivieren. Wer [Strg]+[Umschalt]+[E] wird die Protokollliste angezeigt und es können alle Protokolle wieder aktiviert werden.

Also, viel Spaß bei der Paketanalyse.

Immer wieder nett, Paketanalyse mit Wireshark

Die aktuellste PackageManagement Preview – März 2016

Dieser Eintrag ist eher eine „Note to myself“ – in Schulungen suche ich oft eine Weile nach dem aktuellsten Link für die PackageManagement-Preview für die PowerSHell 4.0, so dass PowerShellGet und Install-Module zur Verfügung stehen. Wie ea aussieht, datiert die aktuellste Version vom März letzten Jahres:

https://www.microsoft.com/en-us/download/details.aspx?id=51451

Auf der einen Seite ist es etwas seltsam, dass das PowerShell-Team eine so simple Angelegenheit wie das PackageManagement-Projekt nicht endlich offiziell freigeben kann. Der „wahre“ Grund könnte sein, dass man die Anwnender dazu bringen will stattdessen WMF 5.1 zu installieren, was auch unter Windows 7 und Windows Server 2008 R2 problemlos möglich ist.

Die ersten Schritte mit den AWS-Cmdlets (inkl. Problemlösung)

Amazon stellt für die Nutzung ihrer inzwischen sehr umfangreichen Amazon Webservices (AWS) ein sehr umfangreiches Modul (über 2.500 Cmdlets!) zur Verfügung. Die AWS Tools for Windows PowerShell stehen u.a. über die PowerShell Gallery zur Verfügung.

Eine ausführliche Übersicht gibt es unter der folgenden Adresse: https://aws.amazon.com/de/powershell/. Dort gibt es auch einen Button für den direkten Download einer Msi-Datei, über die das .NET SDK und die Cmdlets installiert werden.

Die Dokumentation ist, typisch für AWS, vorbildlich mit ein paar kleineren Abstrichen.

Das Modul muss direkt per Import-Module geladen werden.

Ein kleiner „Trick“ zählt die Anzahl der Cmdlets, in dem die Verbose-Ausgabe auf den Standardausgabekanal umgeleitet und damit in die Pipeline gelegt wird.

Die Authentifizierung erfolgt über einen Access Key und einen Secret Key, die man zuvor in der AWS-Konsole im Browser anlegen muss. Der Secret Key wird nur einmalig beim Anlegen eines neuen Key angezeigt und kann als Csv-Datei heruntergeladen werden.

Mit den beiden Zutaten wird per Set-AWSCredentials ein Profil angelegt.

Hier kam es bei mir zu einer Fehlermeldung, die besagte, dass der Pfad %userprofile%\.asws\credentials nicht gefunden werden konnte. Dieser Fehler muss wohl mit der Version der AWS-Tools (3.3.45.0) und anderen Faktoren zu tun haben. Der Fehler trat nicht mehr auf, nachdem ich im Benutzerprofil ein Verzeichnis mit dem Namen .aws angelegt hatte.

Interessant ist, dass die Keys aber nicht in diesem Verzeichnis, sondern als Json-Datei RegisteredAccounts.json unter %userprofile%\AppData\Local\AWSToolkit abgelegt werden.

Anschließend wurde das Profil per Get-AWSCredentials -ListStoredCredentials aufgelistet. Per Clear-AWSCredentials kann ein Profil wieder gelöscht werden.

Die weitere Vorgehensweise ist dann sehr einfach. Bei allen Cmdlets wie z.B. Get-S3Bucket erfolgt die Authentizierung über das Profil, das per ProfileName-Parameter angegeben wird.

Frohe Weihnachten…

Ich wünsche allen Lesern dieses Blogs frohe, sorgenfreie und gesegnete Weihachten und einen guten Start in das neue Jahr 2017.

Speziell was das Thema PowerShell angeht wird es wie fast in jedem Jahr auch 2017 abwechslungsreich bleiben. Mit SSH und einer „PowerShell 6.0“ auf allen Plattformen kommt ein neues Thema dazu, andere Themen wie Testen von Skripten, DSC-Ressourcen und allgemein Einstellungen mit dem Pester-Modul oder generell die Bedeutung einer „Release-Pipeline“ für Skripte und DSC-Ressourcen werden an Bedeutung zunehmen. Interessant wird es sein zu beobachten inwieweit Cloud-Angeboote wie Microsoft OMS (Operations Management Suite), mit der sich Windows Server überwachen lassen, auch in Deutschland angenommen werden.

Mein neues zur Buch zur PowerShell 5.0 wird auch hoffentlich im ersten Quartal erscheinen, so dass mir schon alleine aus diesem Grund die Arbeit nicht ausgehen wird.

Vielleicht sehen wir uns 2017 auf einer PowerShell-Schulung oder auf einem Treffen der PowerShell User Group, z.B. am 12.1.2017 in Stuttgart.

Ihr
Peter Monadjemi

Das Ende meiner Loseblatt-Sammlung, das Ende einer Ära und das fehlende Schlusswort der letzten Aktualisierung

Vor einigen Tagen kam die letzte Aktualisierung der Loseblattsammlung mit dem Titel „Automatisierte Administration mit Scriptsprachen unter Windows NT 4.0/2000, 2003 und 2008“, für die ich über 10 Jahre als Herausgeber beim WEKA Verlag (vormals Interest Verlag) in Augsburg zuständig war.

Loseblatt. Das weckt natürlich Erinnerungen an die späten 80er und frühen 90er Jahre und sicher nicht nur positive. Damals wurden die Loseblatt-Werke zu allen möglichen Themen rund um das Thema Computer in allen Magazinen mit großem Aufwand beworben. Die Angebote klangen auch verlockend – über 1.000 Seiten Praxis-Know how, zusammmengestellt von namhaften Experten, in zwei voluminösen A5-Ringbüchern für nur 59 DM (Preis fiktiv), jederzeit kündbar, Geldzurückgarantie usw. Der Preis war natürlich nur ein Lockangebot für ein Abonnement, das, sobald es zustande kam, nicht mehr ganz so einfach kündbar war. Die meisten Abonnenenten liessen ihr Abo vermutlich mehr aus Bequemlichkeit weiterlaufen und erhielten alle paar Wochen einen Schwung von Blättern im DIN A5-Format, die sie theoretisch selber in den großen Ringordner im A5-Format einsortieren sollten, den sie als Teil des Begrüßungspakets erhalten hatten. Damals, als Internet noch etwas war, das jemand im fernen Kalifornien erfunden hatte, war ein Loseblatt-Abo eine Gewähr dafür an jene Informationen zu kommen, die ansonsten nur mit sehr viel Aufwand erhältlich gewesen wären.

Spätestens vor 5 Jahren hätte das Loseblatt-Werk eigentlich „tot“ sein müssen, da es inzwischen auch jede Menge Angebote im Internet gab, die Informationen so aufbereiteten, dass sie aktuell, informativ und leicht konsumierbar waren. Mein Scripting-Handbuch hielt sich tapfer trotz stetig sinkender Abo-Zahlen – am Ende im unteren zweistelligen Bereich. Jetzt ist Schluss und ich denke, dass es insgesamt gut so ist, da ich es niemanden mehr zumuten möchte Informationen zur PowerShell oder Windows Server alleine aus dem Lesen von A5-Seiten zu beziehen.

Leider wurde in der letzten Aktualisierung vom Dezember diesen Jahres mein Schlusswort im Editorial nicht abgedruckt. Für den unwahrscheinlichen Fall, dass ein ehemaliger Abonnent diesen Blog-Eintrag lesen sollte, hier sind die Sätze, die ich gerne noch an die verbliebenen Leser gerichtet hätte:


Mit dieser Aktualisierung wird das Loseblattwerk Scripting eingestellt. Die erste Aktualisierung erschien im Jahr 2000. Damals waren Themen wie Hyper-V, System Center, Azure und auch PowerShell noch visionäre Themen. Heute, 16 Jahre später, sind sie Alltag für alle, die sich in ihrem beruflichen Umfeld mit Microsoft-Produkten im Server-Umfeld beschäftigen müssen. Konstant geblieben ist über die Jahre die Notwendigkeit sich weiterbilden zu müssen und dabei Spaß am Beschäftigen mit neuen Themen zu haben. Wer sich diese Fähigkeiten erhält, ist für alles was in Zukunft noch kommen mag gut vorbereitet. Und natürlich: Vielen Dank, dass Sie dem Werk so lange die Treue gehalten haben.

eBook zum Thema PowerShell und Azure

Unter GitHub gibt es seit kurzem ein eBook, das den Einsatz der PowerShell im Zusammenspiel mit Azure sehr schön beschreibt:

https://github.com/gitralf/ersteschritte/blob/master/Azure_PowerShell_Erste_Schritte.pdf

Der Autor ist Ralf Wiegand, der bei Microsoft Deutschland für das Thema „Deutsche Cloud“ zuständig ist. Seinen Blog findet ihr unter https://blogs.technet.microsoft.com/ralfwi/.