Powershell Beispiele

Es ist sicher nichts neues, dass die Powershell ein wichtiges Werkzeug des Exchange 2007 Administrators ist. Aber auch außerhalb von Exchange ist die Powershell so nützlich, dass ich heute auf die "DOS-Box" Verzichte und gleich die Powershell nutzen. Auch wenn es nicht um Exchange geht. Um die Einsatzbereiche hier besser deutlich zu machen, versuche ich auf dieser Seite all die Tipps und Codeschnipsel zu sammeln, die ich selbst auch immer wieder einsetze. Es sind keine komplette Programme, sondern Bausteine und Vorlagen.

Befehle und mehrere Zeilen

Wenn man einen Befehl in mehreren Zeilen aufteilen will, weil er dann besser "lesbar" ist, dann muss man den BackTick (`) als Zeilenendezeichen verwenden, welches aber durch ein Leerzeichen abgetrennt sein muss. In VBScript wurde dazu der Underscore "_" am Zeilenende genutzt.

Es dient der Übersichtlichkeit, wenn man das reguläre Ende einer Powershell Zeile mit einem Semikolon (;) abschließt.

Powershell und Debugging

Ehe ich in die tiefen einer Funktionen und Tricks gehe, sollten Sie sich wirklich überlegen ein "striktes" Definitionsgebot für Variablen vorgeben.

set-psdebug -strict

Damit bekommen Sie eine Fehlermeldung, wenn Sie eine Variable benutzen wollen, die noch nie belegt worden ist. Zudem kann man an verschiedenen Stellen mit den drei "Write"- befehlen weitere Infos ausgeben, die einfach per Default abschaltbar sind.

write-host "Hallo ist starte"
write-warning "Ich bin eine Warnung"
write-error "Das ist ein Error"
write-debug "Das ist eine Debugmeldung 1"
$DebugPreference = "Continue"
write-debug "Das ist eine Debugmeldung 2"
$DebugPreference = "SilentlyContinue"
write-debug "Das ist eine Debugmeldung 3"
write-host "Hallo, ich bin fertig"

So sieht die Ausgabe dann aus.

 

Die "write-error"-Meldung beendet das Skript aber nicht. Eine weitere Option ist die Aktivierung eines Trace mit.

Set-PSDebug -trace 0

Spielen Sie einfach mal damit herum, welches Hilfsmitteln ihnen besser hilft. Ich habe mir mittlerweile eine eigene Funktion für das Debugging gebaut, der ich die Meldung und einen Schweregrad übergebe, die dann optional einen Bildschirmausgabe erzeugt, eine Eventlogeintrag schreibt oder eine Mail versendet.

Zuletzt können Sie natürlich auch alles protokollieren lassen, was auf der Konsole passiert.

Start-Transcript -Path e2k7rus-$starttime.log -Append

Stop-Transcript

Allerdings werden das dann eventuell schon etwas umfangreichere Textdateien. Aber wenn ein Skript viel Ausgaben produziert und der Bildschirm-Buffer überläuft, ist es oft die einfachste Möglichkeit, etwas nach zu vollziehen.

Error-Handling

Powershell protokolliert im Gegensatz zu VBScript bis zu 256 Fehler in der eigens dazu bestimmten Variable $ERROR mit. Daher gibt es auch die Konstruktion "on error resume" nicht mehr. Statt dessen kann man bei diversen Commandlets eine Option "-ErrorVariable" und "-ErrorAction" mitgeben um Fehlerausgaben und Abbruchverhalten individuell zu bestimmten.

Das hilft aber nicht viel weiter, wenn man in einem Skript einen Aufruf tätigt, der einen Fehler wirft, z.B.

$user = [adsi]"LDAP://cn=administrator,cn=users,dc=msxfaq,dc=test"
$user.get("FeldGibtesnicht")

Dabei ist es egal, ob es das Feld nicht gibt, oder einfach nicht gefüllt ist. Leider liefert die Powershell kein "Leer" oder "$null" zurück, sondern eine Fehlermeldung, die auf einer Konsole immer unschön aussieht. Ich habe dazu eigentlich nur folgende Lösung, auch wenn man damit globale Einstellungen verbiegt.

$user = [adsi]"LDAP://cn=administrator,cn=users,dc=msxfaq,dc=test"
$ErrorActionPreference = "SilentlyContinue"
$error[0]=""
$wert=""                   # sicherheitshalber initialisieren
$wert=$user.get("Feldnichtbelegt")
$ErrorActionPreference = "Continue"
if($error[0]-ne "") {
    write-host "Fehler aufgetreten"
}

Alternativ kann man mit "$?" immer den letzten Fehler auslesen.

Alternativ kann Powershell natürlich auch mit TRAP und THROW arbeiten. Auf http://huddledmasses.org/trap-exception-in-powershell/ finden Sie eine gute Beschreibung, weil dieser Bereich in der Microsoft Dokumentation wohl ziemlich vergessen wurde.

Write-Host "Beispiel trapThrow startet"
trap [Exception] { 
	write-host
	write-error $("Fehler aufgetreten:" + $_.Exception.GetType().FullName); 
	write-error $("Fehler aufgetreten:" + $_.Exception.Message); 
	continue; 
}

Write-Host "Beispiel trapThrow dazwischen1"
throw (new-object IO.DirectoryNotFoundException); write-host "Fehler1"; 
Write-Host "Beispiel trapThrow beendet"

So kann man für einen Codeteil eine Ausnahmebehandlung hinterlegen.

Powershell Variablen

Neben $ERROR gibt es noch einige weitere Variablen, die ganz hilfreich sein können:

Variable Description
$_ Das aktuelle Objekte einer Pipeline, eines Filter und den verschiedenen Schleifen.
$$ Enthält das letzte Token der Shell-Eingabe
$? Enthält den erfolg/Fehler des letzten Befehls
$Args Enthält übergebene Parameter einer Funktion bzw. eines Skripts
$Error Enthält die bis zu 256 letzten Fehlermeldungen
$foreach Stellt die Aufzählungsvariable einer Schleife dar.
$HOME Heimatverzeichnis des Anwenders (%HOMEDRIVE%\%HOMEPATH%)
$Input Input piped einer Funktion oder eines Codeblocks
$Match Eine Hashtabelle, die alle Elemente enthält, welche durch den "-match"-Operator gefunden wurde.
$MyInvocation Informationen über das aktuelle Skript oder die Kommandozeile
$Host Informationen über den aktuellen Computer
$LastExitCode Exitcode der zuletzt aufgerufenen Anwendung (Nicht Powershellbefehl)
$true Boolean WAHR
$false Boolean FALSCH
$null "nichts", also ein NULL-Objekt.  Ideal um Objekte zu zerstören oder in IF-Abfragen zu vergleichen
$OFS "Output Field Separator". Hiermit geben Sie das Trennzeichen für die Konvertierung von Arrays zu String und umgekehrt an. Standardeinstellung ist das "Leerzeichen"
$ShellID Identifizierung die Shell. Normalweise "Microsoft.PowerShell"
$StackTrace Stacktrace der letzten Aktion
$env:variablenname Umgebungsvariablen abfragen
$global:varname Variablen "global" setzen und lesen

Messagebox und Nachfrage

Im Gegensatz zu VBScript kann die Powershell nicht direkt eine "Messagebox" auf den Bildschirm bringen. Aber über den Umweg ein COM-Objekt zu instanzieren, geht es dann doch: 

$wshshell = new-object -comobject wscript.shell
$Answer = $wshshell.popup("Mitteilung",0,"Kopfzeile",4)

Messagebox

Die erste Zahl definiert dabei den Timeout, ab wann die Messagebox alleine "zusagt" und die vierte Stelle bestimmt die Buttons. Spielen Sie einfach etwas interaktiv damit herum.

Wenn Sie keine Eingabe per Messagebox möchte, sondern auf der Kommandozeile eine Tastatureingabe anfordern wollen, dann ist "Read-Host" ihr Freund:

Read-Host

Einfache Eingaben können So auf der Konsole abgefragt werden.

Ping mit Powershell

Wenn man nicht gleich wieder das "PING.EXE" als Prozess starten will, können Sie auch per Powershell über WMI einen PING absetzen, .z.B. mit

$Pingresult = Get-WmiObject -Class Win32_PingStatus -Filter "Address='servername'"
if ($Pingresult.statuscode -eq 0) {
    Write-Host "Ping erfolgreich"
}

Ein Statuscode von "0" meldet einen erfolgreichen PING.

Testmails versenden

das folgende Skript versendet 100 Mails und schreibt die laufende Nummer mit in den betreff. Das ist ideal, um die Laufzeit von Mails zu messen, die Leitwegewahl zu prüfen oder auch einfach Verluste und Aussetzer bei Cluster und NLB-Konfigurationen zu erkennen.

# fillout the parameters and go
$SmtpClient = new-object system.net.mail.smtpClient 
$SmtpClient.Host = "smarthost" 
 
foreach ($count in (1..50))  {
        write-host "Sending Mail $count"
 
        $MailMessage = New-Object system.net.mail.mailmessage 
        $mailmessage.from = ("sender@firma.tld") 
        $mailmessage.To.add("empfaenger@firma.tld") 
        $mailmessage.Subject = "MSXFAQ SMTPSTORM.PS1 $count" 
        $mailmessage.Body = "MSXFAQ SMTPSTORM.PS1 $count"
        $smtpclient.Send($mailmessage)
         }

Das ist natürlich ein einfaches Beispiel, wie man eine Klasse des .NET Frameworks direkt verwenden kann und mit einer schnellen For-Schleife kombiniert.

Wer mag kann natürlich auch weiterhin "CDO" verwenden.

$mail = new-object -comobject "cdo.message"
$mail.From = "Sender@example.com"
$mail.To = "recipient@example.com"
$mail.Subject = "Betreff"
$mail.TextBody = "Dies ist der Textbody"
$mail.Configuration.Fields.Item("http://schemas.microsoft.com/cdo/configuration/sendusing") = 2
$mail.Configuration.Fields.Item("http://schemas.microsoft.com/cdo/configuration/smtpserver") = "smtp.sample.com"
$mail.Configuration.Fields.Item("http://schemas.microsoft.com/cdo/configuration/smtpserverport") = 25

$mail.Configuration.Fields.Update()
$mail.Send()

Schöner ist aber schon der Ansatz über die .NET Klasse, da man damit komplett auf CDO verzichten kann.

Dateien per HTTP automatisiert übertragen

Diese Beispiel nutzt den WebClient von .NET, um eine Datei von einem Webserver herunter zu laden, die in einer CSV-Datei hinterlegt sind. Natürlich kann man das Beispiel auch mit einer Datei ganz ohne CSV-Datei schreiben. Aber so sehen Sie, wie eine externe Datendatei einfach importiert werden kann.

clnt = new-object system.net.webclient
$colFiles = Import-csv C:\temp\DL.csv
foreach ($file in $colFiles) {
    $clnt.DownloadFile($file.QuellURL, $file.Ziel)
}
Inhalt der CSV-Datei:priv
QuellURL,Ziel
http://www.msxfaq.net/sitemap.xml,c:\temp\sitemap.xml
http://www.msxfaq.net/index.htm,c:\temp\index.htm

Diese Funktion kann z.B. interessant sein, wenn Sie für einen Verzeichnisabgleich Dateien abholen wollen.

TAIL mit Filesystemwatcher

Eine weitere Funktion eines Skripts kann es sein, Dateien in einem Verzeichnis auf Veränderungen zu überwachen, z.B. um einen Echtzeitstatus von IISLogs oder Message Tracking Logs zur Auswertung zu erhalten. Auch hier hilft Powershell und das .NET Framework mit fertigen Klassen weiter:

$FileSystemWatcher = New-object System.IO.FileSystemWatcher "c:\temp"
$result = $FileSystemWatcher.WaitForChanged("all")

Das Skript wartet also auf eine beliebige Änderung im Verzeichnis und kehrt auch erst dann zurück. Die Ausgabe von $result enthält

Powershell und FileSystemWatcher 

Natürlich kann man durch die Angabe einer Zeit ("all",10000) nach 10 Sekunden eine Rückkehr erzwingen oder gleich über Events arbeiten.

Powershell und Funktionen und Parameter

Wer eine Funktion baut, macht die mit dem Ziel bestimmte Codeteile häufiger zu verwenden und den Code zu strukturieren. Man kann damit aber auch interne Verarbeitungen mit privaten Variablen aus dem Hauptprogramm auslagern. Die zur Verarbeitung erforderlichen Werte sind dann als Parameter an die Funktion zu übergeben. Hierzu gibt es zwei Wege, Parameter an eine Powershell Funktion zu Übergeben:

function Funktionsname ([int]$param1=10,[string}param2=msxfaq.de) {
    # Befehle
}

function Funktionsname {
    PARAM ([int]param1=10,[string}$param2=msxfaq.de))
    # Befehle
}

Beide Versionen sind gleichwertig. Beim Aufruf der Funktion sollte man sich aber an Powershell und "Komma" erinnern. Parameter werden nicht durch Komma getrennt übergeben sondern mit Leereichen. Ein Komma macht aus den zwei oder mehr Parametern ein Array, welches die Funktion als ersten Parameter erhält.

# FALSCH
funktionsname wert1, wert2, wert3

#Richtig
funktionsname wert1 wert2 wert3

Die Rückübergabe von Ergebnissen erfolgt ebenfalls einfach über die Pipeline, d.h. alles was das Skript einfach "ausgibt" bekommt der aufrufende Prozess zurück. Insofern muss an Ende keine Zuweisung des Ergebnisses an den Funktionsnamen stehen, sondern einfach die Variable mit dem Inhalt.

Powershell und Kommandozeile

Analog zur Parameterübergabe für eine Funktion können Sie natürlich auch einem PS1-Skript direkt die Parameter übergeben. Da es hier aber keine Funktionsüberschrift gibt, wird der PARAM -Block direkt am Anfang geschrieben.

PARAM(
    [int]$Interval=60
    [string]$domain="msxfaq.de"
    [ScriptBlock]$skriptteil={(get-mailboxserver| select name)}
)

Der Aufruf kann dann wie gewohnt mit Parametrisierung erfolgen.

.\scriptname -interval 30 -domain andere.domain

 Es müssen auch nicht alle Parameter übergeben werden. Überzählige Parameter werden einfach ignoriert, d.h. vorsicht bei Tippfehlern. Erst die Powershell 2 wertet die Powershell diese Parameterblöcke im Skript auch derart aus, dass Sie über die AutoComplete-Funktion der Kommandozeile erreichbar werden.

Man kann hier auch die Defaults angeben, wenn der aufrufende Prozess keine Daten hinterlegt. Interessant ist hier auch die Funktion, direkt einen [Scriptblock] mit zu übergeben, welcher später einfach mit "$skriptteil" aufgerufen werden kann.

write-host "Argumente sind $args"

Powershell und Aufzählungen

An vielen Stellen werden Variablen übergeben. Anders als bei VBScript, wo es nur wenige Basistypen (Integer, String und die universellen Variants etc.) gibt, kann man in .NET mit Aufzählungen arbeiten, die nur bestimmte Werte annehmen können. Eine Funktion kann damit streng prüfen, ob die Parameter überhaupt "geeignet" sind. Also Administrator bin ich an verschiedenen Stellen daher eingeschränkt und kann nicht einfach einen String übergeben, wenn eigentlich ein Wert einer Aufzählung erforderlich ist. Also muss ich heraus bekommen, welche Inhalte eine Aufzählung hat:

[System.Enum]::GetValues([System.Diagnostics.EventLogEntryType])

In der Powershell sieht das dann wie folgt aus:

Sie können natürlich auch weiter mit der MSDN die Klassen und Aufzählungen suchen und betrachten.

Powershell und InputPipeline

Interessant wird es nun, wenn man die Pipeline der Powershell etwas umfangreicher nutzen möchte, dann bietet es sich natürlich an, die Ausgaben eines Kommandos per "PIPE" auf ein weiteres Kommando zu übergeben. Wer nun ein PS1-Skript selbst entwickelt, kann über zwei Wege an die Daten der Pipe kommen.

# Einfachbeispiel im die Ausgabe einer PIPE als Tabe
$input | fl

begin { 
    Write-Host 'Testskript: ============== started ============== '
}
process {
    Write-Host "Testskript: ------ Pipelinedata --------"
    $pipedata = $_
    $fields = ($_ | gm -MemberType NoteProperty) 
    foreach($item in $fields) {
        Write-Host "Name:" $item.name " Daten: " $pipedata.($item.name)
    }
}
end {
    Write-Host "Testskript: ==============  ended ============== "
}

Wenn Sie in solch einer Konstruktion noch eigene Funktionen addieren wollen, dann sind diese sinnvoll nur innerhalb des "begin"-Blocks zu definieren.

Pipeline und $_
Ich habe mir angewöhnt, das Pipelineobjekt in eine Variable namens $pipeline zu kopieren und dann damit zu arbeiten. Zu oft habe ich innerhalb des "process"-Blocks wieder mit FOR-Schleifen gearbeitet und mir so die Variable überschrieben.

Powershell und OutputPipeline

Genauso kann es natürlich interessant sein, Ausgaben in eine Pipeline zu schreiben. Wie wäre es, wenn ein Skript z.B.: die Mitglieder einer Verteilerliste extrahiert und nicht stumpf in eine Datei schreibt, sondern Sie in eine PIPE übergibt, so dass Sie selbst mit Export-CSV oder Export-CliXML oder andere Tools darauf zugreifen können ? Auch das geht per Powershell.

Man muss einfach nur ein Powershell Objekt erstellen, mit Properties und Werten versehen und "ausgeben

Write-Host "Testskript: ------ Pipelinedata --------"
$pso = New-Object PSObject
$pso | Add-Member NoteProperty "ColumnA" "Data1"
$pso | Add-Member NoteProperty "ColumnB" "Data2"
$pso | Add-Member NoteProperty "ColumnC" "Data3"
Write-Output $pso

Wen die Schreibweise mit der PIPE nach Add-Member nicht gefällt, kann die Werte auch anders zuweisen:

$pso = New-Object PSObject
Add-Member -InputObject $pso -MemberType NoteProperty -Name Feld1 -Value Wert1
Add-Member -InputObject $pso -MemberType NoteProperty -Name Feld2 -Value Wert2


# Oder Kürzer
Add-Member -InputObject $pso noteproperty feld1 wert2
Add-Member -InputObject $pso noteproperty feld2 wert2

# Bestehende Felder können einfach dann zugewiesen werden
$pso.feld1 = "wert1neu"

#und ausgegeben werden
write-host $pso.feld1

Siehe auch http://technet.microsoft.com/en-us/magazine/cc510337.aspx

Übrigens können Sie die Ausgabe auch an CScript übergeben, welches dann über wscript.stdin.readall darauf zugreifen kann. Allerdings sollten Sie nicht zu viel erwarten. Mehr als die Bildschirmausgabe des vorherigen Powershell Skripts kommt in VBScript nicht an. Also ist dieser Weg nicht wirklich sinnvoll zu nutzen.

Powershell und grafische Ausgaben

Auch wenn Powershell eigentlich "nur" eine Kommandozeile ist, so kann man damit wie mit VBScript auch grafische Ausgaben gestalten. Während wir bei VBScript auf die Verwendung einer COM-Komponenten wie dem Internet Explorer oder anderen Tools aufsetzt, kann man mit der Powershell direkt .NET Klassen ansprechen. Insofern gibt es meines Wissens nach drei Optionen:

Da ich schon einige VBSkripte mit COM-Ausgabe auf der MSXFAQ veröffentlicht habe, verschränke ich mich hier auf die .NET Version. Sie legt ein Fenster mit einer Tabelle an und ein Druck auf den Button "Update" startet die Funktion "UpdateStatus", die hier natürlich nur eine Zeile füllt. Hier kann aber natürlich noch viel mehr erfolgen.

function UpdateStatus(){
    write-host "------- Start Update ---------"
    $fsTable.clear()
    $fsTable.Rows.add($wert1,$wert2,$wert3)
    write-host "------- Start Done ---------"
}


# Declare Form
[System.Reflection.Assembly]::LoadWithPartialName("System.Drawing") | out-null
[System.Reflection.Assembly]::LoadWithPartialName("System.windows.forms")| out-null
$form = new-object System.Windows.Forms.form
$form.Text = "Exchange 2007 CCR Statusmonitor"
$form.Location = new-object System.Drawing.Size(10,30)
$form.size = new-object System.Drawing.Size(1000,620)
$form.autoscroll = $true
#$form.topmost = $true
$form.Add_Shown({$form.Activate()})
 
# UpdateNow Button
$UpdateButton = new-object System.Windows.Forms.Button
$UpdateButton.Location = new-object System.Drawing.Size(10,5)
$UpdateButton.Size = new-object System.Drawing.Size(120,23)
$UpdateButton.Text = "UpdateNow"
$UpdateButton.visible = $True
$UpdateButton.Add_Click({UpdateStatus})
$form.Controls.Add($UpdateButton)
 
# Declare Table
$fsTable = New-Object System.Data.DataTable
$fsTable.TableName = "Status" | out-null
$fsTable.Columns.Add("Feld1",[string]) | out-null
$fsTable.Columns.Add("Feld2",[string]) | out-null
$fsTable.Columns.Add("Feld3",[string]) | out-null
 
#$Dataset = New-Object System.Data.DataSet
#$Dataset.tables.add($fsTable)
 
$Dataview = New-Object System.Data.DataView($fsTable)
$Dataview.allowEdit = $false
#$Dataview.allowAdd = $false
$Dataview.allowDelete = $false
 
# Add DataGrid View
$dgDataGrid = new-object System.windows.forms.DataGridView
$dgDataGrid.Location = new-object System.Drawing.Size(10,30)
$dgDataGrid.size = new-object System.Drawing.Size(950,550)
$dgDataGrid.autosize = $true
$dgDataGrid.DataSource = $Dataview
#$dgDataGrid.DataSource = $fsTable
$form.Controls.Add($dgDataGrid)
 
UpdateStatus
$form.ShowDialog()

Eine WPF-Version habe ich noch nicht erstellt, aber wird nachgereicht, sobald ich damit schon gearbeitet habe.

Powershell und Performance Counter

Genau einfach kann man über das .NET-Framework auf Performancecounter zugreifen, was anscheinend auch schneller aber vor allem einfacher ist, als der WMI-Zugriff. Hier ein Muster auf einem englischen Server 

[PS] $perf = new-object System.Diagnostics.PerformanceCounter
[PS] $perf.countername = "% Processor Time"
[PS] $perf.Categoryname = "Processor"
[PS] $perf.Instancename = "_Total"
 
oder
 
[PS] $perf = new-object System.Diagnostics.PerformanceCounter "Processor","% Processor Time", "_Total"

[PS] $perf
 
CategoryName     : Processor
CounterHelp      : % Processor Time is the percentage of elapsed time that the
                   processor spends to execute a non-Idle thread. It is calcula
                   ted by measuring the duration of the idle thread is active i
                   n the sample interval, and subtracting that time from interv
                   al duration.  (Each processor has an idle thread that consum
                   es cycles when no other threads are ready to run). This coun
                   ter is the primary indicator of processor activity, and disp
                   lays the average percentage of busy time observed during the
                    sample interval. It is calculated by monitoring the time th
                   at the service is inactive, and subtracting that value from
                   100%.
CounterName      : % Processor Time
CounterType      : Timer100NsInverse
InstanceLifetime : Global
InstanceName     : _Total
ReadOnly         : True
MachineName      : .
RawValue         : 36131046250000
Site             :
Container        :

Das ist ja noch einfach, so lange es genau ein Counter ist und die Namen als auch Instanzen gleich sind. Nun gibt es aber Performancecounter, die mehrere Instanzen haben, z.B.: die Exchange 2007 CCR Replikation. Da muss man sich dann selbst durch die Instanzen arbeiten.

[PS] $perfcat = new-object System.Diagnostics.PerformanceCounterCategory("MSExchange Replication")
[PS] $perfcat.GetInstanceNames() 
      | %{$perfcat.GetCounters($_)} 
      | ft Cat*,countername,Instancename,rawvalue
 
CategoryName        CounterName         InstanceName             RawValue
------------        -----------         ------------             --------
MSExchange Repli... CopyNotification... _total                     83317
MSExchange Repli... CopyGenerationNu... _total                     83317
MSExchange Repli... InspectorGenerat... _total                     83317
MSExchange Repli... ReplayNotificati... _total                     83317
MSExchange Repli... ReplayGeneration... _total                     83317
MSExchange Repli... ReplayQueueLength   _total                         0
MSExchange Repli... Suspended           _total                         0
MSExchange Repli... TruncatedGenerat... _total                         0
MSExchange Repli... CopyNotification... s1 sg1                     83317
MSExchange Repli... CopyGenerationNu... s1 sg1                     83317
MSExchange Repli... InspectorGenerat... s1 sg1                     83317
MSExchange Repli... ReplayNotificati... s1 sg1                     83317
MSExchange Repli... ReplayGeneration... s1 sg1                     83317
MSExchange Repli... ReplayQueueLength   s1 sg1                         0
MSExchange Repli... ReplayBatchSize     s1 sg1                         0
MSExchange Repli... CopyQueueLength     s1 sg1                         0

Auch hierzu finden sich im Internet umfangreiche Beschreibungen

Powershell und Eventlog

Über das Commandlet "Get-Eventlog" kann man natürlich sehr einfach die Daten der verschiedenen Eventlogs von Windows extrahieren. Aber auch ein Schreiben in das Eventlog ist über die.NET-Klassen schon als trivial zu bezeichnen.

# Initialize Eventlog for reporting and Debugging
$evt=new-object System.Diagnostics.EventLog("Application")
$evt.Source="MSXFAQ"
$infoevent=[System.Diagnostics.EventLogEntryType]::Information
$warnevent=[System.Diagnostics.EventLogEntryType]::Warning
$errorevent=[System.Diagnostics.EventLogEntryType]::Error

$evt.WriteEntry("SKRIPT gestartet",$infoevent,0)

Wer also heute ein Powershell-Skript schreibt und die Ausgabe von Fehlern oder Status als Eventlog vergisst, sollte sich mal fragen wie er all die schönen Skripte überwachen möchte wenn diese später automatisch laufen.

Umgekehrt kann man sehr einfach im Eventlog auch nach Werten suchen. Hier suche ich 1221 Events der letzten 14 Tage. (Ergebnisse der Online Defragmentierung von Exchange:

$WMIDATEAGE = [System.Management.ManagementDateTimeConverter]::ToDmtfDateTime `
   ([DateTime]::UtcNow.AddDays(-14))
Get-WmiObject -computer SRV01 ´
    -query ("Select * from Win32_NTLogEvent Where Logfile='Application' and 
               Eventcode = '1221' and TimeWritten >='" + $WMIDATEAGE + "'") |
	foreach-object{
		write-host $_.message
	}

Aber man muss sich gar nicht auf die Tiefen von WMI begeben. Mit dem Powershell Commandlets "Get-Eventlog" lässt sich jedes Eventlog einfach auslesen. Denken Sie aber daran, auch hier mit Filtern zu arbeiten

Interessant ist aber auch die Funktion, einfach auf Events zu warten und die dann automatisch zu verarbeiten. Auch wenn dies mit Powershell 2.0 noch einfacher geht (Register-WMIEvent  auf http://www.microsoft.com/technet/scriptcenter/topics/winpsh/events.mspx), ist auch Powershell 1.0 schon sehr einfach dazu zu verwenden. Hier ein Beispiel:

$eventwatcher = new-object system.management.ManagementEventWatcher
$eventwatcher.query = "Select * From __InstanceCreationEvent Where TargetInstance ISA 'Win32_NTLogEvent'"
$event = $eventwatcher.WaitForNextEvent()
$event.targetinstance

Das Skript in einer Powershell-Box gestartet, liefert den nächsten Event, der ein einem beliebigen Eventlog des lokalen Servers auftritt.

Mit so wenig Code kann man natürlich schöne weitere Funktionen bauen:

Export, Import und Convert

Eine der stärksten Funktionen der Powershell sind die leistungsfähigen Comandlets zum Export und Import von Daten.

<Objs Version="1.1" xmlns="http://schemas.microsoft.com/powershell/2004/04">
    <Obj RefId="RefId-0">
        <MS>
            <S N="ColumnA">Data1</S>
            <S N="ColumnB">Data2</S>
            <S N="ColumnC">Data3</S>
        </MS>
    </Obj>
</Objs>

Das Schöne ist, dann die Commandlets ebenfalls wieder "Objekte" liefern. Wenn man mit Export-CSV oder Export-CliXML die Ergebnisse eines Prozesses als Datei ablegt, kann man sie sehr einfach wieder importieren und weiterverwenden.

Powershell und "Includes"

Als alter VBScript-Programmierer habe ich natürlich die Funktion von "Klassen" schätzen gelernt. Leider steht hierzu in der Powershell Hilfe wörtlich.

Although it is possible to create a class in Windows PowerShell, it’s not a very straightforward process and definitely goes beyond the scope of this introductory manual. So, for the time being, forget we even mentioned it.

Vielleicht soll man Klassen einfach als Comandlet mit Visual Studio entwickeln. Aber man kann Funktionen in anderen Skripten auslagern und einfach einbinden. Man muss nur darauf achten ,dass man die Funktionen VOR dem Aufruf einbindet. Dabei hilft einem das Commandlet "Invoke-Expression", welches einen String als Befehl ausführt. Damit man sicher ist, dass der String auch als Powershell Skript verwendet wird kann man bei der Deklaration mit "[scriptblock]" arbeiten

$Script = "get-Process"
Invoke-Expression $Script

Man kann sogar ganze Dateien damit einbinden. Hier ein "Hauptprogramm", welches Code einer Subrouine einbindet und aufruft bzw. nutzt.

# include-main.ps1
Write-Host "Include-main started"
$test1="test1"
write-host "Include-main Test1=$test1"
get-content -Path ".\include-part.ps1" | Invoke-Expression
write-host "Include-main Test2=$test2"
Write-Host "Include-main ended"
# include-part.ps1
Write-Host "Include-part started"
write-host "Include-part Test1=$test1"
$test2 = "test2"
write-host "Include-part Test2=$test2"
Write-Host "Include-part ended"

Zwar unterstützt Powershell auch Klassen und Sie können direkt COM und.NET Klassen nutzen, die sie auch it Visual Studio Express entwickeln können, aber so kann man als "Skript only" auch sich eine Sammlung mit "Libraries" erstellen und einbinden, wenn man sie nicht direkt mit Add-PSSnapin in die Umgebung addieren will.

Es gibt noch einen weiteren Weg: Man kann einfach das andere Skript direkt aus dem eigenen Skript aufrufen.

&C:\temp\tmp.ps1

Leistungsfähig wird diese Funktion, wenn man den Code sogar auf einer Kommandozeile angeben kann. Insofern können viele Dinge so für Anwender geöffnet werden, z.B. indem der Anwender selbst Code "einbinden" kann. Analog gibt es noch Invoke-Item.

Powershell signieren und Execution Policy

Je nach Einstellung führt die Powershell ein Skript gar nicht, mit einer Warnung oder ohne Rückfrage aus. Man kann die Powershell nämlich anweisen, eine digitale Signatur eines Skripts zu prüfen und entsprechend die Ausführung zu erlauben oder zu unterbinden. Gesteuert wird das Verhalten über den Befehl "SET-ExecutionPolicy", welcher die Einstellung annimmt.

Über den Befehl "GET-EXECUTIONPOLICY" können Sie die aktuelle Einstellung abfragen.

Bei einem Windows 2008 R2 Domain Controller ist per Default die Execution Policy auf "restricted" gestellt.

Powershell COM-Objekte

So leistungsfähig die direkt nutzbaren .NET-Klassen sind, so sind viele wichtige Lösungen heute nur als COM-Objekte verfügbar. Dazu zählen natürlich Outlook, Word, Excel aber auch viele Hilfsprogramme, die über die COM-Schnittstelle einfach wieder zu verwenden sind. In den nächsten Abschnitten sehen Sie, wie Powershell sogar für die einfache Ausgabe einer Messagebox den Windows Skripting Host missbrauchen muss.

Es ist sehr einfach, eine Instanz eines COM-Objekts zu erhalten. Weisen Sie es einfach zu:

$variable = new-object -com name_des.comobjects

Danach können Sie "fast" unbegrenzt über das COM-Objekt verfügen.

Aber beachten Sie dazu auch den folgenden Abschnitt über STA und MTA

Single Thread Appartment (STA) und Multi Thread Appartment (MTA)

Durch den Einsatz von "Redemption" und anderen COM-Objekten wurde ich unfreiwillig auf einen maßgeblichen Unterschied  der Powershell im Vergleich zu VBScript aufmerksam. Ein kleiner 5-Zeiler, welcher einfach nur per COM-Objekt eine Mailbox öffnet hat mich mehrere Stunden suche gekostet. Folgendes war passiert:

Zuerst dachte ich, dass ein Skript ohne "Windows Form" natürlich auch keine "Windows Message Pump" hat, mit der die Fenster untereinander Meldungen senden können. Aber mit dem Entwickler von Redemption (gleiches Problem) und der Powershell Newsgroup konnte ich dann die C# Konsolenanwendung "tauglich" machen. Mit einem "[STATHREAD]" vor "main" lief auch diese Anwendung durch.

Insofern scheint VBScript per Default immer im STA-Mode zu laufen, während Powershell 1 per Default "MTA" nutzt. Erst Powershell 2 kann man mit dem Parameter "-sta" in die Single Thread Betriebsart zwingen.

Auf dem Powershell Blog wird eine alternative Lösung mit einem Commandlet "Invoke-Appartment" angeboten.

Powershell und Globaler Katalog

Ich habe immer wieder die Aufgabenstellung, im Active Directory nach Objekten zu suchen und diese zu verarbeiten oder zu berichten. Hier ist ein Codeschnipsel, mit dem ich einfach den GC finde und befrage und danach zu jedem Objekt ein Feld ausgeben lasse.

$root = [system.directoryservices.activedirectory.forest]::getcurrentforest().rootdomain.name
$objSearcher = New-Object System.DirectoryServices.DirectorySearcher([ADSI]"GC://$root")
$objSearcher.PageSize = 1000
$objSearcher.Filter = "(&(mail=*))"
$objSearcher.PropertiesToLoad.Add("mail") | Out-Null
$objSearcher.PropertiesToLoad.Add("ProxyAddresses") | Out-Null

$colResults = $objSearcher.FindAll()
foreach ($objResult in $colResults) {
    $mail = $objResult.properties.mail[0]
    write-host "Processing $mail"
    $adobject = [adsi]$objResult.path
    write-host "Bound " + $adobject.displayname
}

Kennworte nutzen

Sehr viele Routinen benötigen ein Kennwort, welches aber "sicher" gespeichert werden muss. Es ist denkbar ungünstig, ein Kennwort im Skript direkt zu hinterlegen. Daher kann man Kennwort z.B. direkt von der Console einlesen und gesichert speichern.

$pwd = read-host -assecurestring$pwd

Alternativ kann man mit den beiden Commandlets "convertto-securestring" und "convertfrom-securestring" die Werte um.

Powershell und Klassen

In VBScript gibt die die Möglichkeit, Klassen zu definieren und damit Code hinter Objekten zu verstecken und vor allem bestimmte andere Teile aktiv zu halten (z.B. eine LDAP-Verbindung). Das Prinzip der objektorientierten Entwicklung hat die früher oft genutzte prozedurale Programmierung (Funktionen und Prozeduren) bei Hochsprachen fast komplett abgelöst.

Auch Powershell unterstützt Klassen. Allerdings steht dazu in der Dokumentation recht vielsagend:

Class Definition:
Declares the name of a class, as well as a definition of the variables, properties, and methods that comprise the class.
Although it is possible to create a class in Windows PowerShell, it’s not a very straightforward process and definitely goes beyond the scope of this introductory manual. So, for the time being, forget we even mentioned it.

Auch wenn es syntaktisch geht, scheinen die Entwickler diesen Weg nicht weiter öffnen zu wollen. Gut finde ich es nicht aber wenn man heute also eigene Klassen bauen will, dann wird man eben Visual Studio anwerfen und sich die passenden Klassen als .NET-DLLs oder Commandlets schreiben.

Powershell und Outlook

Alternativ kann man mit der Powershell natürlich auch das Outlook Objektmodell ansprechen. Allerdings kommt hier wieder verschiedene Warnungen, z.B. wenn sie automatisch auf den Kontaktordner lesend zugreifen wollen.
$olAppointmentItem = 1;
$olFolderDeletedItems = 3;
$olFolderOutbox = 4;
$olFolderSentMail = 5;
$olFolderInbox = 6;
$olFolderCalendar = 9;
$olFolderContacts = 10;
$olFolderJournal = 11;
$olFolderNotes = 12;
$olFolderTasks = 13;
$olFolderDrafts = 16;
$olPublicFoldersAllPublicFolders = 18;
$olFolderConflicts = 19;
$olFolderSyncIssues = 20;
$olFolderLocalFailures = 21;
$olFolderServerFailures = 22;
$olFolderJunk = 23;
 
$outlook = new-object -com outlook.application;
$ns = $outlook.GetNameSpace("MAPI");
$inbox = $ns.GetDefaultFolder($olFolderInbox)
$inbox.Items | foreach { $_.subject }

Ein Zugriff auf die gleichen Funktionen per CDO ist nicht möglich, da hier das Multithreading von Powershell mit CDO nicht kompatibel ist.

Powershell User Guide page 33,
"Not all COM objects are supported. Objects that are based on Exchange Collaboration Data Objects (CDO) are not supported in this release."

813349 Support policy for Microsoft Exchange APIs with the .NET Framework applications

Weitere Links

Keywords: Powershell Tools Samples