how to pipelining devop part i: windows powershell

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