how to pipelining devop part i: windows powershell
TRANSCRIPT
How to Pipelining
DEVOP PART I: WINDOWS POWERSHELL
DEVOP
Das Monad ManifestGet 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:
ByValueByPropertyName
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:
TippErmöglicht schnellere Suche in Help:
get-help <cmdlet> -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»
ByValueByPropertyName
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 –property
@{name=‘ComputerName’;expression={$_.name}}
@{} 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 –property @{n=‘ComputerName’;e={$_.name}}
…und es geht doch…! Wir fassen zusammen…: get-adcomputer | select –property
@{n=‘ComputerName’;e={$_.name}} | 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 –property
@{n=‘ComputerName’;e={$_.name}} | 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