PowerShell Deep Dive am 17. und 18.10.2011 in Frankfurt

Im PowerShell-Teamblog war es bereits zu lesen:

Am 17. und 18. Oktober wird es in Frankfurt a.M. im Rahmen der von Quest durchgeführten TEC-Konferenz (eine Art TechEd in klein mit Themenschwerpunkten wie ActiveDirectory und Virtualisierung) auch einen PowerShell Deep Dive geben, also eine eigene Konferenz zum Thema PowerShell, die von Microsoft USA organisiert wird. Der erste DeepDive fand im April in Las Vegas statt und war mit Sicherheit ein echtes Community Event mit inhaltlich interessanten Vorträgen (ein Blog-Eintrag von einem gewissen Boe Prox beschreibt das Rumherum sehr schön:

http://learn-powershell.net/2011/05/10/of-deep-dives-and-scripting-games/)

Die Agenda der letzten Veranstaltung gibt es hier:

http://www.theexpertsconference.com/us/2011/powershell-deep-dive/agenda/

Die Slides zu den Vorträgen wird es sicherlich auch irgendwo geben.

Weitere Infos zur kommenden PowerShell-Deep Dive-Konferenz gibt es unter

http://www.theexpertsconference.com/europe/2011/general-information/2011-powershell-deep-dive/

Kostenlos ist die Veranstaltung natürlich nicht, aber speziell für den Deep Dive soll es einen “Discount” geben. Eine Agenda gibt es noch nicht, denn man kann noch bis zum 4. August Vorträge für Sessions einreichen. Mal sehen, ob mir bis dahin noch etwas Passendes einfällt (bei der Fülle an Informationen zur PowerShell im Web habe ich oft das Gefühl, das es nichts mehr zu “entdecken” gibt ). Ich denke, Remoting ist immer ein Thema und zur Performance der PowerShell  wenn eine große Anzahl an Objekten im Spiel ist gibt es immer etwas zu sagen. Oder zu Office 365.

Kleine Tipps für Zwischendurch – Zuweisung und Abfrage in einem if-Befehl

Die PowerShell-Skriptsprache birgt so manche kleine Überraschung, auf die man von alleine nicht so ohne weiteres kommt (und die an einem erst ein Kursteilnehmer in einem PowerShell-Kurs jüngst verraten muss). Dazu gehört z.B. der Umstand, dass sich ein Variablenwert in einem if-Befehl gleichzeitig zuweisen und testen lässt, was eine separate Zuweisung erspart.

Das folgende Beispiel gibt eine Meldung aus, wenn die Anzahl der laufenden Prozesse ein “Limit” überschreitet. Die Variable $AnzahlProzesse erhält dabei ihren Wert im if-Befehl, der gleichzeitig abgefragt wird:

$Limit = 80
if (($AnzahlProzesse = (Get-Process).Count) -gt $Limit)
{ “Limit um $($AnzahlProzesse – $Limit) Prozesse überschritten.” }
else
{ “Alles ok!” }
$AnzahlProzesse

Sicherheit ist immer … relativ

Die Ausführung von PowerShell-Skripts kann bekanntlich durch eine Ausführungsrichtlinie verhindert werden – in der Praxis ist es aber eine Kleinigkeit, diese Hürde zu umgehen.

Zum einen besitzt PowerShell.exe den Parameter ExecutionPolicy, über den die Ausführungsrichtlinie für einen Prozess z.B. jederzeit auf “Unrestricted”  gesetzt werden kann. Zum anderen gibt es bei PowerShell.exe diesen unscheinbaren -, der bewirkt, dass Text, der der Exe-Datei per Pipeline zugeführt wird, ausgeführt wird. Angenommen, die Ausführung von Ps1-Dateien wäre z.B. per AppLocker deaktiviert, dann führt der folgende Aufruf dazu, dass eine Txt-Datei mit PowerShell-Skriptbefehlen trotzdem ausgeführt wird:

Type Ps1Skript.ps1 | PowerShell.exe -

Eine echte Sicherheitslücke ist dies nicht, da der auszuführende Skripttext ansonsten per Command-Parameter übergeben werden müsste, doch wenn man dieses Beispiel in einem Einführungskurs zeigt kommen bei den Kursteilnehmern dann doch gewisse Zweifel auf  bezüglich der Frage wie ernst Microsoft es mit der Sicherung eines Systems vor PowerShell-Skripten meint (auf diesen kleinen “Trick” kam ein Kurs-Teilnehmer bei meinem letzten PowerShell-Workshop in Nürnberg).

Ein weiterer Aspekt, der mich etwas stört ist, dass wenn einmal die Ausführungsrichtlinie per Gruppenrichtlinie auf “Unrestricted” gesetzt wurde, diese Einstellung anscheinend auch dann noch als “Machine Policy” wirksam ist, wenn der Computer nicht an der Domäne angemeldet ist. Tipp: Mit dem List-Parameter bei Get-ExecutionPolicy erhält man die Einstellung auf allen der max. 5 möglichen Ebenen.

PS: Im PowerShell-Team-Blog wurde es ja von June Blender bereits angekündigt. Seit kurzem ist die PowerShell-Hilfe in einer aktualisierten Form erhältlich. Laut June ist dort einiges eingeflossen, was von den PowerShell-Usern in der ganzen Welt seit der Freigabe der Version 2.0 an “Unstimmigkeiten” gemeldet wurde.

PowerShell in Action, 2nd Edition – endlich da

Es hat wirklich eine Weile gedauert, doch seit kurzem ist die Neuauflage von “PowerShell in Action” von Bruce Payette endlich offiziell erhältlich. Der Verlag ist nach wie vor der hierzulande möglicherweise etwas weniger bekannte Mannings-Verlag, dessen “Action”-Titel mir generell sehr gut gefallen (und von denen ich daher auch einige im Regal stehen habe).

Auf über 900 (!) Seiten behandelt der Autor praktisch jeden Themenbereich, der für die Praxis mit der PowerShell eine Rolle spielt. Anders als die erste Version, die an einigen Stellen etwas “abgehoben” war, spricht der Autor dieses Mal auch (oder in erster Linie) jene Leser an, die keinen Unix-Background oder einen Bachelor in moderner Informatik besitzen.

Also, ein klares “Must have” für alle, die die Kernkonzepte der PowerShell verstehen wollen. Das muss ich als Autoren-Kollege neidlos anerkennen. Allerdings ist der Autor auch nicht irgend jemand, sondern der Entwickler der PowerShell-Skriptsprache, des Parsers und sicherlich noch einiger weiterer Bestandteile (das .NET Framework hat er allerdings nicht auch noch entwickelt, so dass ihm manches bereits fertig zur Verfügung stand), so dass der Verlag ihn anscheinend auch “alle Zeit der Welt” gelassen hat – ein Rahmen, der das Schreiben wirklich guter Bücher oft erst möglich macht und in der Verlagsbranche nicht gerade selbstverständlich ist.

Ich bin sicher, dass es in Kürze auch eine deutschsprachige Version des Buches geben wird. Die erste Auflage war, unter dem nicht ganz so aussagekräftigen Titel “PowerShell im Einsatz”, beim Hanser-Verlag erschienen.

Weitere Infos gibt es hier.

Offizielle Sprachspezifikation für die Windows PowerShell 2.0

Es ist nur eine Kleinigkeit, reine PowerShell-Anwender wird es nicht interessieren und im PowerShell-Teamblog wurde auch schon darüber berichtet. Seit ein paar Wochen gibt es eine offizielle Sprachspezifikation für die PowerShell-Skriptsprache (die offiziell keinen Namen besitzt und nicht etwa PowerSkript oder so ähnlich heißt). Das Word-Dokument ist sehr interessant, da es zum einen den Sprachumfang definiert, zum anderen aber auch mögliche Unklarheiten beseitigt, etwa zur Rolle des &-Operators.

Ein Grund für die Veröffentlichung der Sprachspezifikation ist laut Microsoft, dass damit die Implementierung der PowerShell auf anderen Plattformen erleichtert werden soll. Durch die Lizensierung unter der “Microsoft Community Promise”-Lizenz soll gewährleistet werden, dass jeder einen PowerShell-Clone gemäß dieser Spezifikation unter einer beliebigen Plattform implementieren kann (was natürlich leichter gesagt als getan ist).

Eine PowerShell für Linux wäre sicher eine feine Sache, auch wenn es zahlreiche Argumente der Bash-Fraktion geben dürfte, die das Ganze als eine ziemlich idiotische Idee hinstellen würden. Ein Ansatz ist unter dem Namen “Pash” vor vielen Jahren sicherlich an der Komplexität der Aufgabe, aber auch an fehlendem Interesse der Community gescheitert. Auch innerhalb des Mono-Projekts gibt es für diesen Bereich kaum Interesse (bislang wurde noch nicht einmal System.DirectoryServices implementiert, was alleine schon aus dem Grund eine Herausforderung sein dürfte, da es unter Linux kein ADSI gibt).

Vielleicht läuft ja schon ein Projekt und die Freigabe der Sprachspezifikation geschah nicht ganz zufällig.

CLSID für COM-Komponenten finden

Der folgende Praxistipp ist sehr speziell und allenfalls für Entwickler interessant, die noch mit COM-Komponenten zu tun haben. Er zeigt aber schön, wie sich mit den Mitteln der PowerShell keine Tools zusammenstellen lassen, ohne dafür ein richtiges Programm schreiben zu müssen.

Im Folgenden wird eine kleine Funktion vorgestellt, die zu einer bereits registrierten COM-Komponente über ihren Dateinamen die CLSID aus der Registry liest und ausgibt.

<#
.Synopsis
CLSID für eine Komponente abfragen
#>

function Get-CLSID
{
  param($COMLibName)
  “Suche wird gestartet… es kann eine Weile dauern”
  $CLSID = dir hklm:\Software\Classes\CLSID\`{*`}\InprocServer32 | `
   where { (“Registry::$($_.Name)” | Get-Itemproperty -Name “(Default)” -Ea 0) `
    -Match “$COMLibName” }  | Select @{Name=”Path”;Expression={$_.PSParentPath}} | Split-Path -Leaf
   “Fertig…”
  if ($CLSID)
  { $CLSID }
  else { “Keine CLSID gefunden – Komponente ist nicht registriert.” }
}

Get-CLSID -ComlibName VB6Lib.dll

Kleine Tipps für Zwischendurch

Ein kleiner Nachteil von längeren try-Blocks im Rahmen eines try/catch-Konstrukts ist es, dass es schwierig sein kann, das Cmdlet zu lokalisieren, das den Fehler ausgelöst hat. Hier wäre eine Zeilennummer praktisch. Die PowerShell zeigt zwar die Zeilennummer in der Fehlermeldung an, es ist aber nicht so offensichtlich wie man an diese Information herankommt.

Die Lösung findet man in der Property InvocationInfo des ErrorRecord-Objekts, das im Catch-Zweig bekanntlich über $_ zur Verfügung steht.

<#
.Synopsis
Zeilennummer bei Fehlern
#>
try
{
  “OK…”
  “OK…”
  Get-Item C:\NotExisting.dat -Ea Stop
  “OK…”
  “OK…”
  “OK…”
}
catch
{
Write-Host “Fehler in $($_.InvocationInfo.ScriptName) – Zeile ($($_.InvocationInfo.ScriptLineNumber)): $($_.InvocationInfo.Line)”
}
“OK… one more time”