16.12.2007, aktualisiert am 18.10.2012

96508

PowerShell for Runaways - Part I

Hallo ans Forum

Die PowerShell hat sich inzwischen zu meinem Lieblings-Werkzeug unter Windows entwickelt, aber leider wird sie IMHO noch zu wenig genutzt.
Von den Mitschülern in der Berufschule und auch den Admins an meinem Arbeitsplatz nutzen nur wenige die PowerShell, die meisten hängen noch beim Windows Scripting Host oder Batch fest.
Dabei ist die PowerShell überaus mächtig. Einerseits kann man mit der Powershell auf das gesamte .NET Framework 2.0 zugreifen (was mit WSH nicht möglich ist), andererseits kann man ausserdem wie bei WSH auf alle WMI- und COM-Objekte zugreifen.
Dieses Tutorial dient also vor allem dazu, die Angst vor einem Umstieg zu nehmen und einen kurzen Überblick zu bieten, so dass man anfangen kann, Scripts zu schreiben.

Sicherheitsmassnahmen der PowerShell

Die PowerShell hat diverse Script-Sicherheitsmassnahmen integriert. Im Gegensatz zu Scripts in den diversen anderen Scriptsprachen (VBScript, Perl, JScript, Batch) kann man PowerShell-Scripts nicht per Doppelklick auf die Datei starten. Dies hat den Vorteil, dass Schad-Scripts, welche im Anhang von Mails verschickt werden, nicht einfach so gestartet werden können.
Folgende Möglichkeiten gibt es, PowerShell-Scripts zu starten:

Beim Start über die Shell direkt muss ein .\ vorne dran gehängt werden. .\scriptname
Starten eines Scripts mittels einer Verknüpfung oder per Batch-Datei: powershell.exe -command "C:\Scriptname.ps1"

Bevor überhaupt Scripts ausgeführt werden können, muss ausserdem die Execution-Policy definiert werden. Das geht mit dem CMDLet "set-executionpolicy". Es gibt 4 verschiedene Stufen:

Restricted --> Keine Skripte werden ausgeführt
Allsigned --> Nur signierte Skripte werden ausgeführt
RemoteSigned --> Lokal erstellte Skripte sind erlaubt, aber andere Skripte müssen signiert sein
Unrestricted --> Alle Scripts werden ausgeführt

Standarmässig ist die Stufe "Restricted" aktiviert.
Mit dem folgenden CMDLet-Befehl wird die Execution-Policy auf "Unrestricted" gesetzt

set-executionpolicy unrestricted

Online-Hilfe der CMDLets abrufen

Die Online-Hilfe der einzelnen CMLets (so heissen die Befehle bei der Powershell) lässt sich folgendermassen abrufen:

get-help CMDLet -full

Scripting

Nun kommen wir zum eigentlichen Scripting. PowerShell-Scripts sind normale Textdateien mit der Endung .ps1, welche mit jedem beliebigen Texteditor bearbeiten werden können.

Ein-/Ausgabe

Ausgabe an die Konsole

write-host "Ausgabe"

Ausgabe in ein ANSI-Textfile

"Ausgabe" | out-file -filepath C:\logfile.txt -encoding Default

Wenn das Textfile um die Ausgabe erweitert werden soll:

"Ausgabe" | out-file -filepath C:\logfile.txt -encoding Default -append

Ausgabe in ein CSV-File

$a = get-process
$a | select-object Name,Path,Company | Export-csv -path C:\text.csv

Ausgabe in ein HTML-File

$a = get-process
$a | convertto-html -property Name,Path,Company > C:\test.html

Benutzereingaben verwenden

$Eingabe = Read-Host "Bitte geben Sie etwas ein:"  
Write-Host "Sie haben folgendes eingegeben: " $Eingabe  

Kommandozeilenargumente verwenden

Die Kommandozeilenargumente müssen per Leerschlag übergeben werden:

.\scriptname Argument1 Argument2

Folgendermassen können die Kommandozeilenargumente verwendet werden:

$Argument1 = $args
$Argument2 = $args[1]

Aus einer Textdatei lesen

Hier wird mittels einer ForEach-Schleife für jede Zeile des Textfiles ein Befehlssatz ausgeführt:

$Zeile = get-content "C:\textfile.txt"  
foreach-object ($i in $Zeile) {
# Befehle
}

Variabeln, Arrays und Konstanten

Variabeln

Variabeln werden folgendermassen definiert...

$Variabelnname = Inhalt

und folgendermassen ausgegeben:

$Variabelnname

Arrays

Arrays werden folgendermassen definiert...

$Arrayname = 1,5,9,10

und folgendermassen ausgegeben:

$Arrayname

Folgendermassen können einzelne Felder des Arrays ausgegeben werden:

$Arrayname[3]

Die Nummerierung der Felder eines Arrays fängt bei 0 an.

Konstanten

Konstanten werden ohne $ kreiert:

set-variable -name Konstantenname -value Inhalt -option constant

Folgendermassen werden Konstanten ausgegeben, rsp. abgefragt:

$Konstantenname

Schleifen und Bedingungen

If Bedingung

Führt einen Befehlssatz aus, wenn eine Bedingung erfüllt ist:

$Variable = "Rot"  
if ($Variable -eq "Rot")  
	{"Die Farbe ist rot!"}  
elseif ($Variable -eq "Blau")  
	{"Die Farbe ist blau!"}  
else
	{"Eine andere Farbe..."}  

Switch Bedingung

Eine komfortablere Möglichkeit, Befehlssätze bei Erfüllung einer Bedingung zu auszuführen:

$Variable = "Rot"  
switch ($Variable) {
	"Rot" {"Die Farbe ist rot!"}  
	"Blau" {"Die Farbe ist blau!"}  
	default {"Eine andere Farbe..."}  
}

Do While Schleife

Führt die Schleife aus, SOLANGE die Bedingung erfüllt ist:

$Variable = 1
Do {$Variable;$Variable++}
While ($Variable -lt 10) 

Do Until Schleife

Führt die Schleife aus, BIS die Bedingung erfüllt ist:

$Variable = 1
Do {$Variable;$Variable++}
Until ($Variable -gt 10)

For Schleife

Befehle in definierter Anzahl ausführen:

For ($Variable=1; $Variable -le 10; $Variable++)
{$Variable} 

ForEach Schleife

Arbeitet eine Gruppe von Objekte an

Foreach-object ($i in get-childitem C:\windows)
{$i.name; $i.creationtime}

Objekte verwenden

COM-Objekte

Ein Objekt kreieren:

$objNetzwerk = new-object -comobject "wscript.network"  

Methoden des Objekts benutzen:

objNetzwerk.username

WMI-Objekte

WMI-Objekte abfragen:

get-wmiobject -class win32_operatingsystem -computername AbzufragenderComputer

.NET Framework Objekte

.NET Objekt kreieren (Parameter können übergeben werden, falls nötig):

$dotnetobjDateTime = New-Object -Type System.DateTime 2007,12,26
$dotnetobjDateTime.get_DayOfWeek()

Sonstiges

Kommentare

Kommentare werden mit einem # eingeführt:

# Diese Codezeile wird nicht ausgeführt

Ich hoffe, ich konnte einen kurzen Einblick geben und wünsche viel Spass beim Script-Umschreiben!

PS: Herzlichen Dank an Frank Koch von Microsoft Schweiz, von dessen PowerShell-Manual ich einige Sachen entlehnt habe.

Nachtrag:

Voraussetzungen für die Verwendung der PowerShell

Grundsätzlich wird die PowerShell von den Betriebsystemen XP, Vista, Server 2003, Exchange 2007 und Server 2008 unterstützt. Je Betriebsystem gibt es eine eigene Version der PowerShell. Ausserdem muss die Sprache beachtet werden. Was zusätzlich noch vonnöten ist, ist die Installation des .NET Framework 2.0, welches über die Windows Updates eingespielt werden kann.

Hier gibts die PowerShell zum Download:
http://www.microsoft.com/windowsserver2003/technologies/management/powe ...

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 76114

Url: https://administrator.de/contentid/76114

Ausgedruckt am: 23.11.2024 um 08:11 Uhr

11 Kommentare

Neuester Kommentar

sehr schöne Sache, aber wie kriege ich ein Skript auf einem Client ans Laufen?
muss dafür dort auch die Powershell installiert sein?
sind sonstige Voraussetzungen dafür notwendig?

Gut, dass du es erwähnst. Ich werde es nachtragen.

Edit:
Ja, die PowerShell muss auf jedem Client installiert sein, auf dem du PS-Scripts ausführen willst.

Hallo TuXHunt3R,
freue mich schon auf "PowerShell for Runaways - Part II und Folgende"
ciao pacobay

Moin TuXHunt3R,

eine schöne Eröffnung für eine neue "Runaways"-Reihe.
Prima Tutorial.

Weiter so!
Vielleicht noch mal irgendwann einen neuen Nick besorgen..*gg

Grüße
Biber

Vielleicht noch mal irgendwann einen neuen Nick besorgen..*gg

Vorschläge?

> Vielleicht noch mal irgendwann einen
neuen Nick besorgen..*gg

Vorschläge?

Hallo TuxHunt3R,

ich bin von Deinem Tutorial begeistert. Vielleicht kann ich Dir mit vier Buchtiteln weiterhelfen, werde die Titel aber erst morgen posten können.
Allerdings beteilige ich mich nicht an den Vorschlägen für Deinen neuen Nick......

Weiterso.

Grüße

Kallewirsch

Allerdings beteilige ich mich nicht an den Vorschlägen für Deinen neuen Nick......

Naja, habe eigentlich auch nicht vor, den Nick zu wechseln......

Was sind die Vorteile der Powershell?

masterG

Gegenüber was? VBScript oder der CMD-Shell?

OK, hier sind sie:

Logische Befehlssyntax. Jeder Befehl, d.h. jedes CMDlet ist nach dem Prinzip VERB-SUBSTANTIV aufgebaut
Stark ausgebautes Piping. Jeder Befehl kann über die Pipe ( | ) an andere Befehle übergeben werden (sofern sinnvoll, natürlich)
Volle Unterstützung des .NET Frameworks, es ist aber trotzdem noch möglich mit den (veralteten) COM-Objekten zu arbeiten
Weniger Code, der auch einfacher zu lesen ist als VBScript.
Einfachere Verwendung von CSVs, XML und HTML. Genannt seien hier z.B. die CMDlets "Import-CSV", "Export-CSV" und "Convertto-HTML".
Jeder Output ist als Objekte im RAM gespeichert, nicht wie der CMD-Shell als Text. Dazu hier ein Beispiel:

$Textfile = get-content C:\test.txt

Diese Codezeile speichert den Inhalt des Textfiles C:\test.txt in einem Array mit dem Namen "$Textfile". Du musst also nicht eine ganze Funktion für das Einlesen eines Textfiles in ein Array schreiben, eine Codezeile verwenden. Jede Zeile eines Textfiles ist nun als Objekt in diesem Array gespeichert. Dieses Array kannst du nun z.B. in einer Foreach-Schleife weiterverwenden.

foreach ($Linie in $Textfile) {write-host "Blabla"$Linie}  

Diese Schleife gibt z.B. das Textfile zeilenweise, d.h. objektweise aus und schreibt vor jede Zeile den Text "Blabla". Es gibt natürlich noch andere Möglichkeiten....

Ausserdem ist die PowerShell Script Language stark an C# angelehnt, was den Umstieg auf diese sehr weit verbreitete Programmiersprache erleichert.

Wenn du ein umfassendes Beispielscript sehen willst, schau mal hier:
PowerShell For Runaways - Part II

Vielen Dank für die Anleitung. Wäre es nicht sinnvoll, Part II zu verlinken?

Zitat von @TuXHunt3R:
Bevor überhaupt Scripts ausgeführt werden können, muss ausserdem die Execution-Policy definiert werden. Das geht
mit dem CMDLet "set-executionpolicy". Es gibt 4 verschiedene Stufen:

Restricted --> Keine Skripte werden ausgeführt
Allsigned --> Nur signierte Skripte werden ausgeführt
RemoteSigned --> Lokal erstellte Skripte sind erlaubt, aber andere Skripte müssen signiert sein
Unrestricted --> Alle Scripts werden ausgeführt

Standarmässig ist die Stufe "Restricted" aktiviert.
Mit dem folgenden CMDLet-Befehl wird die Execution-Policy auf "Unrestricted" gesetzt

Bis hier hin noch wunderbar die einzelnen Stufen der executionpolicy aufgelistet

 set-executionpolicy unrestricted

Unrestricted ist sicherlich für eine Testumgebung eine gut gewählte Lösung. Aber sicherheitstechnisch wäre

 set-executionpolicy remotesigned

die bessere Wahl. Wer also in Firmennetzwerken mit der PS rumbastelt sollte sich für remotesigned entscheiden.
Auf Servern wäre sogar allsigned besser, wenn man die Möglichkeit hat Signaturen zu erstellen.

Also wäre es sicher besser, den Leitfaden dahingehend anzupassen.
Im Übrigen ist in der Fachliteratur auch immer nur der Modus RemoteSigned gesetzt. (Siehe dazu: Windows PowerShell von Holger Schwichtenberg - Seite 107 (erschienen 2008, Addison-Wesley-Verlag)

Anleitung Entwicklung Batch, Shell

Mehr von TuXHunt3R

Windows Server Datendeduplizierung mit Roaming ProfilesTuXHunt3R - 4 Kommentare

Windows 10 - VPN-Tunnel computerseitig einrichtenTuXHunt3R - 2 Kommentare

Neuer Edge Chromium - Installation mittels MSI + den alten Edge gleich mitentsorgenTuXHunt3R - 7 Kommentare

Eigenschaften eines einzelnen Mails in einem Postfach auslesenTuXHunt3R - 2 Kommentare

Heiß diskutiert