How to Pipelining DEVOP PART I: WINDOWS POWERSHELL

DEVOP

Das Monad Manifest  Get Objects | Process Objects | Output Objects

Beispiel einer Pipeline  Alle Dienste stoppen:  get-service | stop-service  Bestimmte Dienste stoppen:  get-service –name *bits* | stop-service

Was geht in die Pipeline?  Was übergeben wird, wird auf dem Bildschirm dargestellt, wenn ein CMDlet ausgeführt wird  Ein CMDlet übergibt jedoch ein Objekt an die Pipeline  Ein Objekt hat «Properties» und «Methods» (Beispiel: «Farbstift»)  Jedes Objekt hat unterschiedliche «Properties» und «Methods»  Ein Stift hat eine Farbe und kann Schreiben  Ein Fahrrad hat einen Lenker, Pedale und kann Fahren und Lenken  Diese «Properties» und «Methods» können mit der Übergabe an «get- member» sichtbar gemacht werden

ABER: Wie funktionieren Pipelines nun wirklich?

Wie funktionieren Pipelines?  2 Kriterien gilt es von den CMDlets zu erfüllen:  1. Was gibt das CMDlet weiter?  2. Was nimmt das nächste CMDlet an?

Was kommt raus?

Was gibt ein CMDlet weiter?  Dies kann durch das CMDlet «get-member» herausgefunden werden: ByValue ByPropertyName

ByValue  Ist das erste Kriterium, welches geprüft wird  Vergleicht den Objekttyp auf String-Basis

ByPropertyName  Ist das zweite Kriterium, welches geprüft wird  Zeigt an, welche Properties mit welchen Namen weitergegeben werden

Was geht rein?

Was nimmt das CMDlet an?  Kann mit «get-help» mit dem Parameter «-full» herausgefunden werden:

Tipp  Ermöglicht schnellere Suche in Help:  get-help -ShowWindow

Spezialfall Nummer 1…

Funktioniert das?  get-service | stop-process  Eigentlich schon – aber es macht keinen Sinn…  …aber weshalb?

Deshalb funktioniert das…  «get-service» gibt folgendes weiter:  ByValue: «ServiceController»  ByPropertyName: alle Properties, u.a. auch «Name» ByValue ByPropertyName

Deshalb funktioniert das…  «stop-process» nimmt folgendes an:  ByValue: «Process»  KEIN MATCH!  ByPropertyName: u.a. auch «Name»  MATCH!

Spezialfall Nummer 2…

…und was ist mit dem…?!?  Das Ziel: Wir möchten alle Computer aufgelistet erhalten, auf welchen der BITS-Service ausgeführt wird  get-adcomputer –filter * | get-service –name bits  …funktioniert das so?!?

Leider nein…  «get-adcomputer» liefert ein «ADComputer»-Objekt zurück  «get-service» erwartet ein «ServiceController»-Objekt   KEIN MATCH ByValue!  «get-adcomputer» liefert aber ein «name»-Property zurück  «get-service» kann ein «name»-Property annehmen   MATCH ByPropertyName  ABER: «get-service» erwartet einen Service-Namen – «get-adcomputer» liefert aber einen Computer-Namen

…oder doch…?!?  «get-service» hat einen weiteren Parameter namens «computername»  Dieser akzeptiert auch Inputs «ByPropertyValue»  «get-adcomputer» liefert aber den Computernamen als Property «name», was wiederum dem «name»-Parameter von «get-service» – also dem Namen eines Dienstes – entspricht…

NoteProperties…  Mit dem folgenden Befehl können nur bestimmte Spalten der eigentlichen Ausgabe angezeigt werden:  get-service –name bits | select –property name,status  Was passiert aber, wenn man sich vertippt?  get-service –name bits | select –property naem,ststus  Resultat: Es werden zumindest die Spaltenüberschriften ausgegeben – und was ist mit «get- member»?  get-service –name bits | select –property naem,ststus | get-member  Hier haben wir die «NoteProperties»… - also eigene benutzerdefinierte «Properties»

Wie kann uns das helfen?  Was wäre, wenn wir das Property «name» von «get-adcomputer» auf «ComputerName» umbenennen könnten?  get-adcomputer | select definiert einen Hashtable  …also eine Tabelle mit Namen und Werten (Names und Expressions)  $_ bezieht sich jeweils auf das CMDlet-Objekt vor der Pipe  …und dieses Objekt hat ein Property namens «name»  Noch kürzer geht’s mit…:  get-adcomputer | select

…und es geht doch…!  Wir fassen zusammen…:  get-adcomputer | select | get-service – name bits

Spezialfall Nummer 3…

Get-WMIObject  «get-wmiobject» kann Informationen zum lokalen oder auch entfernten Computern anzeigen:  get-wmiobject –class Win32_bios  get-wmiobject –class Win32_bios –computername SRV01  …lasst uns dies für alle Computer im AD ausführen…  get-adcomputer | select | get-wmiobject –class Win32_bios

WäWäWäWääääähh…

Wie der (Fail!) aussieht…:

Der Grund dahinter…  «get-wmiobject» akzeptiert keinerlei Pipeline-Inputs (gemäss «get-help»)

Let’s Try & Error…  «get-wmiobject» akzeptiert keinerlei Pipeline-Inputs (gemäss «get-help»)  «get-wmiobject» möchte einfach im Parameter «ComputerName» ein paar Computernamen als String  Etwa so:  get-wmiobject –class Win32_bios –computername SRV01,SRV02  Wieso also nicht…:  get-wmiobject –class Win32_bios –computername get-adcomputer –filter *  …weil Powershell so nicht weiss, welches CMDlet zuerst ausgeführt wird… - aber wieso dann nicht so (wie früher in der Algebra – Klammern kommen zuerst)…:  get-wmiobject –class Win32_bios –computername (get-adcomputer –filter *)  …weil «get-adcomputer» ein «ADComputer»-Objekt zurückliefert und keinen String…

Let’s Try & Error… (Part II)  «get-adcomputer» liefert also zu viele Informationen (Properties) zurück… - Weshalb dann nicht einfach…:  get-adcomputer –filter * | select –property name  …weil es dann immer noch ein «ADComputer»-Objekt ist (just pipe it to «get-member» to know it…) ;-D

Let’s Try & Error… (Part III)  Das CMDlet «select-object» hat auch einen Parameter «expandProperty»…:  get-adcomputer –filter * | select –expandproperty name  …und siehe da…:

Die Lösung…!  Die Lösung lautet also…:  get-wmiobject –class Win32_bios –computername (get-adcomputer –filter * | select –expandproperty name)  …aber es geht ab Powershell 3.0 noch einfacher…:  get-wmiobject –class Win32_bios –computername (get-adcomputer –filter *).name