0 Einleitung
           Beispiel 1: Starten eines Powershellskripts aus VBS heraus
        1 Historie: Powershell V1.0 / Powershell V2.0
           Beispiel 1: Verhindern von Versionskonflikten

        2 Installation der Powershell V2.0
          2.1 Installationssource
          2.2 Versionskontrolle
                Beispiel 1: Versionskontrolle

       3 Aufbau einer Entwickungsumgebung
          3.1 Windows Maschinen
          3.2 Anpassen der DomainPolicy
          3.3 Anpassen des Windows7 Clients
                3.3.1 Profile
                         3.3.1.1 Profilpfade
                         3.3.1.2 Beispiele für Profile
                                     Beispiel 1: Anpassen des Powershellfensters mit der Microsoft.PowerShell_profile.ps1
                                     Beispiel 2: Anpassen der Powershell mit der profile.ps1                                     
                3.3.2 Aliase
                         3.3.2.1 Überblick
                                     Beispiel 1: get-childitem und sein Alias gci
                                     Beispiel 2: Auflisten der cmdlets, die Aliases ver- und bearbeiten
                                     Beispiel 3: Welches cmdlet steckt hinter dem Alias "dir"
                                     Beispiel 4: welche Aliase besitzt Get-ChildItem
                         3.3.2.2 Die drei Aliastypen
                                     Beispiel 1: Auflisten der Kompatibilitäts-Aliase
                                     Beispiel 2: Entfernen der Kompatibilitäts Aliase
                                     Beispiel 3: Auflisten der Canonical-Aliase
                                     Beispiel 4: Beweis, das "readonly" wirklich "readonly" bedeutet
                                     Beispiel 5: Definition eigener Aliase
                                     Beispiel 6: Abfrage selbst definierter Aliase
                         3.3.2.3 Verwendung von Aliasen
                3.3.3 Module und SnapIns
                         Beispiel 1: Registrierung der QAD-cmdlets  ,
                         Beispiel 2: Anzeige der neu hinzugekommenen QAD-cmdlets
                         Beispiel 3: Import aller pscx-Module
                         Beispiel 4: Import von bestimmten pscx-Modulen
                         Beispiel 5: Anzeige der einzelnen pscx-Module
                         Beispiel 6: Kontrolle der pscx-cmdlets und weitere Informationen
                         Beispiel 7: Import eines Modules aus dem Powershellpack
                3.3.4 Include File (Dot Sourcing)
                3.3.5 nützliche Tools
          3.4 .Net Framework Versionen in Powershell

        4 Troubleshooting Installation/ Customizing  
 

0 Einleitung

Die Seite habe ich ungefähr im Jahr 2011 geschrieben und aus Zeitgründen noch nicht aktualisiert. Mittlerweile (2014) ist schon die Powershell in der Version Beta 5 erschienen. Ich denke trotzdem, dass man noch einige interessante Informationen finden kann. Daher lasse ich die Seite noch etwas stehen.
 

Mit der Powershell kann man nicht mehr ganz so einfach mit dem Programmieren loslegen oder fertige Skripte starten, wie man das vielleicht von Früher mit VBScript oder der Batchprogrammierung gewohnt war.

Dies 

  •   ist a) der Sicherheit geschuldet, die default das Ausführen von PS-Skripten auf Rechnern erstmal radikal unterbindet
  •   kann b) durch Powershell-Profildateien verursacht sein, denen Alias- oder Funktionsdefinitionen fehlen oder die auf dem Rechner auf nicht existente Pfade veweisen und einiges mehr. 
  •   ist c) eventuell auf notwendige, aber nicht vorhandene Spracherweiterungen zurückzuführen. Im weiteren Verlauf dieses Kapitels werden wir Module und SnapIns kennenlernen, die das Skriptingleben einerseits sehr vereinfachen, aber andererseits bei Nichtvorhandensein erstmal Fehler werfen.
  •  

Wie man sieht, ist das richtige Customizing einer Umgebung sehr wichtig, um Powershellskripte entwickeln und ausführen zu können. Dies ist damit das Thema der folgenden Kapitel.

 

Beispiel 1: Starten eines Powershellskripts aus VBS heraus

 Set objShell = CreateObject(“Wscript.shell”)
 objShell.run(“Powershell -ExecutionPolicy unrestricted -file “”c:\temp\MyPsScript.ps1″”"),0

1 Historie: Powershell V1.0 / Powershell V2.0

Die ersten veröffentlichten Versionen dieser Skriptsprache liefen unter dem Codenamen "Monad". Im Jahr 2006 wurde dann Powershell V1.0 von Microsoft released und mit Windows7 und Server2008 kam die aktuell gültige (Stand: Mai 2011) Powershell V2.0 heraus. 

Laut einem der Powershellguys -Ed Wilson- ist eine 100%-ige Abwärtskompatibilität gegeben. Jedes unter Powershell V1.0 geschriebene und lauffähige Skript läuft auch unter Powershell V2.0. Von daher gibt es keinen Grund heute nicht mit der Powershell V2.0 zu arbeiten.

Technet: Hey, Scripting Guy! Can I Use Windows PowerShell 1.0 Scripts on Windows PowerShell 2.0?

Die hinzugekommenen Features der Powershell V2.0 kann man nachlesen unter Technet: about_Windows_PowerShell_2.0

Die hinzugekommenen Features der Powershell V3.0 kann man nachlesen unter Technet: About_Windows_PowerShell_3.0

Grundlegende Sprachelemente wie beispielsweise Schleifen, Variablen, .Net-Programmierung, reguläre Ausdrücke, um nur ein paar wenige zu nennen, haben sich von V1.0 auf V2.0 auf V3.0 nicht verändert. Wenn man in einem Buchladen günstig ein Werk zu Powershell V1.0 oder V2.0 bekommt, sollte man wirklich zuschlagen. Gerade die Grundlagen sind in den V1.0 Büchern oft viel ausführlicher dargestellt, da in den neuen Büchern den Autoren durch die mit jeder Version neu hinzukommenden Features einfach der Platz ausgeht.

 

Beispiel 1: Verhindern von Versionskonflikten

Das folgende #Requires Statement verhindert, dass ein PS-Skript in einer zu niedrigen Powershellumgebung abläuft und durch fehlende Elemente Fehlermeldungen produziert.

#Requires -version 2.0

Näheres unter MSDN: about_Requires

 

 2 Installation der Powershell V2.0

 2.1 Installationsourcen

Powershell v2.0 ist ab Windows XP mit SP3 / Server 2003 aufwärts für jedes MS Betriebssystem zum Nachinstallieren verfügbar. Ab Windows Version 7 /Server 2008R2 ist die Powershell V2.0 standardmässig installiert.

Für die genannten früheren Windows Versionen steht die Powershell v2.0 entweder unter Technet: Windows Management-Frameworks (Windows PowerShell 2.0 WinRM 2.0 und BITS 4.0) im Abschnitt "Windows Management-Framework Core (WinRM 2.0 und Windows PowerShell 2.0)" zur Verfügung oder man lässt die Powershell v2.0 über Windows Update Services installieren.

Zu Beachten sind für die älteren Windowsversionen noch diese beiden Punkte

  • Die Powershell 2.0 benötigt das DotNetPaket 2.0 . Ohne dieses Paket lässt sich die Installation zwar durchführen, beim Arbeiten erscheinen allerdings Fehlermeldungen wie “objekt nicht gefunden” etc.
  • Um die ISE (integrierte Entwicklungsumgebung) zu nutzen, wird zusätzlich das DotNetPaket 3.0 benötigt
     

2.2 Versionskontrolle

Verwirrenderweise wird auch die v2.0-Version im v1.0 Pfad  "%Systemroot%\system32\WindowsPowerShell\v1.0" installiert. Das kann eventuell zu Verwirrung führen.

Beispiel 1: Versionskontrolle ($psversiontable)

Nach erfolgreicher Installation oder zur Überprüfung der installierten PS-Version kann man über die PS-Variable $PSVersionTable eine Abfrage durchführen, die erst ab der Version 2 enthalten ist. In der Powershellversion 1.0 würde eine Fehlermeldung ausgegeben

$psversiontable

#Ausgabe Powershell 2.0

Name                           Value
----                           -----
CLRVersion                     2.0.50727.5444
BuildVersion                   6.1.7601.17514
PSVersion                      2.0
WSManStackVersion              2.0
PSCompatibleVersions           {1.0, 2.0}
SerializationVersion           1.1.0.1
PSRemotingProtocolVersion      2.1

#Ausgabe Powershell 3.0

Name                           Value

----                           -----
WSManStackVersion              3.0
PSCompatibleVersions           {1.0, 2.0, 3.0}
SerializationVersion           1.1.0.1
BuildVersion                   6.2.8370.0
PSVersion                      3.0
CLRVersion                     4.0.30319.239
PSRemotingProtocolVersion      2.2

 

Beispiel 2: Versionskontrolle (Get-Host)

Get-Host
#mögliche Ausgabe

Name             : Windows PowerShell ISE Host
Version          : 3.0
InstanceId       : a8b84953-870f-4b9a-87d3-147b06ac76a4
UI               : System.Management.Automation.Internal.Host.InternalHostUserInterface
CurrentCulture   : de-DE
CurrentUICulture : de-DE
PrivateData      : Microsoft.PowerShell.Host.ISE.ISEOptions
IsRunspacePushed : False
Runspace         : System.Management.Automation.Runspaces.LocalRunspace


3 Aufbau der Entwickungsumgebung

Unter diesem Punkt beschreibe ich, wie meine persönliche Entwicklungsumgebung aussieht.
Ich habe das Glück, dass ich einen HyperV-Server mit 60 GB RAM zur Verfügung habe, auf dem sich trefflich Testumgebungen aufbauen lassen. Aber auch mit weniger Ausstattung, selbst auf einem einigermassen modernen Notebook ab 4 GB Ram, lässt sich eine komplette virtualisierte Testumgebung mit vmware oder Microsoft VirtualPC gut erstellen.

 

3.1 Windows Maschinen

Meine Entwicklungsumgebung besteht aus drei virtuellen Maschinen

  • 1 Domaincontroller Server2008R2 Enterprise (SP1) - Domänenname: Dom1.intern / Servername: Dom1DC01
  • 1 Server 2008R2 Enterprise (SP1)  - Servername: Dom1Srv01 
  • 1 Client Windows7 Ultimate (SP1) - Clientname: Dom1Cli01

Auf dem Win7-Client installiere ich Powershellerweiterungen und Programme. Dort entwickle ich hauptsächlich meine Skripte.
Auf den Server kommen diverse Rollen und Backoffice-Produkte wie die Zertifikatsdienste und der SQL2008R2-Server . 
Den Domaincontroller brauche ich für die Powershellpolicies und nutze ihn außerdem fürs Powershellremoting.

 

3.2 Anpassen der DomainPolicy

Default können auf Windowsrechnern ohne Anpassungen erstmal keine Powershellskripte ausgeführt werden. Dies liegt an der sogenannten ExecutionPolicy, die das unterbindet. Die ExecutionPolicy kann entweder lokal für jeden Host einzeln, oder generell per Grouppolicy in der Domäne konfiguriert werden.

Ich würde es, wie im nachfolgenden Bild dargestellt, per Policy einstellen. Da wir uns hier in einer Entwicklungsumgebung bewegen, setze ich den Status auf "unrestricted" oder "allow all scripts".


Weitere Information über die ExecutionPolicy habe ich unter Zertifikate - PKI -> PSSkripte signieren -> 1. die ExecutionPolicy zusammengestellt. Dort ist unter anderem ausführlich beschrieben, wie die ExecutionPolicy über das cmdlet "set-executionpolicy" oder über RegistryKeys angepasst werden kann.
In produktiven Umgebungen sollten nur signierte Skripte erlaubt sein. Das Signieren von Skripten ist unter Zertifikate - PKI -> PSSkripte signieren -> 2 Das CodeSigning-Zertifikat erstellen im gleichen Kapitel beschrieben.

 

3.3. Anpassen des Windows7 Clients

Den Windows7 EntwicklerClient werden wir am Stärksten an unsere Bedürfnisse anpassen. Natürlich können diese Schritte bei Bedarf auch auf einem Server durchgeführt werden, wenn man dort programmiert.

  • Unter 3.3.1 passen wir über Profile das Verhalten und das Erscheinungsbild der Powershell an.
  • Unter 3.3.2 betrachten wir Aliase. Mit Aliasen gibt man Befehlen neue -meist kürzere, einprägsamere- Namen und erleichtert sich dadurch das Leben
  • Unter 3.3.3 erweitern wir durch Module und SnapIns den Befehlssatz der Powershell
  • Unter 3.3.4 installieren wir einige nützliche Tools und Programme.

Sollte die Powershell ExecutionPolicy nicht über eine Policy angepasst sein, wie im Kapitel 3.2 oben beschrieben, so muss die ExecutionPolicy über den lokalen Befehl

Set-Executionpolicy Unrestricted  # PS als Administrator starten!

gesetzt werden. Genauere Informationen über dieses cmdlet finden sich in unter Zertifikate - PKI -> PSSkripte signieren -> 1.1 Verändern der ExecutionPolicy

 

3.3.1 Profile

Technet: about_profiles

Technet: The Windows PowerShell Profile

In einer Profil-Datei werden beispielsweise

  • Aliase für häufig benutzte cmdlets hinzugefügt (etwa gh für get-help)
  • Aliase für häufig benutzte Anwendungen hinzugefügt (etwa np für notepad)
  • generell gültige Funktionen definiert
  • Erscheinungsbild der Console definiert (etwa. Farben, Grösse, Titel, Buffer)
  • Fenstergrössen definiert
  • zusätzliche SnapIns registriert (wenn die Registrierung bei einem Neustart nicht erhalten bleibt)
  • Pfade gesetzt
  • PreferenceVariablen modifiziert (siehe Technet:  about_preference_variables )

Möchte man bestimmte Einstellungen auf mehrere Rechner verteilen, so macht man dies ab der Powershell V2.0 besser mit Modulen,  siehe Technet: about_Modules

 

3.3.1.1 Profilpfade

ProfilDateien werden –sofern vorhanden– bei jedem Start der Powershell.exe oder der Powershell_ISE.exe automatisch ausgeführt. Die Profile sind gewöhnliche Powershellscripte (*.ps1), die mit jedem Texteditor erstellt und editiert werden können.
Mit diesen Profilskripten lässt sich Powershell userspezifisch (ein bestimmter oder alle User) und shellspezifisch (Powershell.exe und /oder Powershell_ISE.exe) beim Start der Powershell anpassen. 

Im Folgenden sind die Möglichkeiten tabellarisch dargestellt

Priorität

Pfad (Erklärung unten)

Geltungsbereich

1

<Eigene Dateien>\Microsoft.PowerShell_profile.ps1

-für den angemeldeten User
-für die PowershellConsole

1

<Eigene Dateien>\Microsoft.PowerShellISE_profile.ps1

-für den angemeldeten User
-für die Powershell Entwicklungsumgebung ISE

2

<Eigene Dateien>\PowerShell\profile.ps1

-für den angemeldeten User
-für alle Powershell Shells

3

<Installationsverzeichnis>\ Microsoft.PowerShell_profile.ps1

-für alle User
-für die PowershellConsole

3

<Installationsverzeichnis>\ Microsoft.PowerShellISE_profile.ps1

-für alle User
-für die Powershell Entwicklungsumgebung ISE

4

<Installationsverzeichnis>\profile.ps1

-für alle User
-für alle PowershellShells

Abkürzung

Prozessor

OS

Pfad

<Eigene Dateien>

 

XP/ W2k3

%UserProfile%\My Documents\WindowsPowerShell

<Eigene Dateien>

 

Vista/ W2K8

%UserProfile%\Documents\WindowsPowerShell

<Installationsverzeichnis>

32-bit

 

%windir%\system32\WindowsPowerShell\v1.0\

<Installationsverzeichnis>

64-bit

 

%windir%\syswow64\WindowsPowerShell\v1.0\

%windir%\system32\WindowsPowerShell\v1.0\

Je spezifischer ein Profil ist, umso höher seine Priorität 


Beispiel 1: Auslesen der Profilpfade 
Die Variable $profile enthält nicht nur den Profilpfad des aktuellen Benutzers sondern -vielleicht etwas versteckt in Noteproperties- auch die anderen Pfade

$Profile | Get-Member -membertype NoteProperty
[Environment]::NewLine

"AllUsersAllHosts:       {0}" -f  $profile.AllUsersAllHosts
"AllUsersCurrentHost:    {0}" -f  $profile.AllUsersCurrentHost
"CurrentUserAllHosts:    {0}" -f  $profile.CurrentUserAllHosts
"CurrentUserCurrentHost: {0}" -f  $profile.CurrentUserCurrentHost
"CurrentUserCurrentHost: {0}" -f  $profile

#Ausgabe, wenn das Skript in der Powershell_ise aufgerufen wird
     TypeName: System.String

Name                   MemberType   Definition
----                   ----------   ----------   
AllUsersAllHosts       NoteProperty System.String AllUsersAllHosts=C:\Windows\System32\WindowsPowerShell\v1.0\profile.ps1 
AllUsersCurrentHost    NoteProperty System.String AllUsersCurrentHost=C:\...\v1.0\Microsoft.PowerShellISE_profile.ps1
CurrentUserAllHosts    NoteProperty System.String CurrentUserAllHosts=C:\Users\j184715.DOM1\Documents\WindowsPowerShell\profile.ps1
CurrentUserCurrentHost NoteProperty System.String CurrentUserCurrentHost=C:\...\Documents\WindowsPowerShell\Microsoft.PowerShellISE_profile.ps1


AllUsersAllHosts:       C:\Windows\System32\WindowsPowerShell\v1.0\profile.ps1
AllUsersCurrentHost:    C:\Windows\System32\WindowsPowerShell\v1.0\Microsoft.PowerShellISE_profile.ps1
CurrentUserAllHosts:    C:\Users\j184715.DOM1\Documents\WindowsPowerShell\profile.ps1
CurrentUserCurrentHost: C:\Users\j184715.DOM1\Documents\WindowsPowerShell\Microsoft.PowerShellISE_profile.ps1
CurrentUserCurrentHost: C:\Users\j184715.DOM1\Documents\WindowsPowerShell\Microsoft.PowerShellISE_profile.ps1

$Profile gehört zu den sogenannten "automatic variables",
siehe Technet: about_Automatic_Variables
und NTFS-Filesystem -> Pfade -> Kapitel 1.1.1.1 automatic Variables

 

3.3.1.2 Beispiele für Profile

Die in den beiden folgenden Beispielen gezeigten Profile setze ich selbst so ein. Mit der Microsoft.PowerShell_profile.ps1 definiere ich das Aussehen des Powershell.exe Prompts und mit der profile.ps1 definiere ich einige Aliase und Funktionen.

Beispiel 1: Anpassen des Erscheinungsbildes einer ConsolenSession

#Hostobjekt erstellen
$MyHost=Get-Host

#Farben der Console setzen
$UserInterface = $MyHost.UI.RawUI
$UserInterface.BackgroundColor = "Gray"
$UserInterface.ForegroundColor = "DarkBlue"

#Buffergröße der Console setzen
$BufferSize=$UserInterFace.BufferSize
$BufferSize.Height=5499
$BufferSize.Width=120
$UserInterface.Set_BufferSize($BufferSize)

#Fenstergröße der Console setzen
#die Fenstergröße darf nicht größer als die BufferSize sein
$WindowSize=$UserInterface.WindowSize
$WindowSize.Height=45
$WindowSize.Width=120
$UserInterface.Set_WindowSize($WindowSize)

#Bereinigen des Bildschirms
Clear-Host

#Prüfen ob Fehler gemeldet wurden (entspricht dem %errorlevel% aus MSDOS)
$LastExitCode

In der Microsoft.PowerShell_profile.ps1 können die passenden Fenstereinstellungen der Powershell vorgegeben werden. Ich habe dieses ProfileSkript unter C:\Windows\System32\WindowsPowerShell\v1.0 gespeichert, so dass es für alle Benutzerkonten gültig ist. (siehe Tabelle in 3.3.1.1 oben)

Anmerkung:
In der unteren Hälfte des Artikels Technet: Customizing the Windows PowerShell Console ab "Using a Script to Modify Console Properties" findet man eine Übersicht, wie man die Powershellconsole nach seinen Wünschen anpassen kann. 
Über den Befehl "[ConsoleColor]::GetValues([System.ConsoleColor])" bekommt man die erlaubten 15 Farben geliefert.

Beispiel 2: Anpassen des Erscheinungsbildes der Powershell_Ise
Auch das Fenster der Powershell_ise.exe lässt sich noch customizen. Besonders die Ausgabe von Fehlern mit roter Schrift auf blauem Hintergrund finde ich nicht optimal für meine Augen. Daher habe ich folgende CodeZeilen in die Datei "Microsoft.PowerShellISE_profile.ps1" im Verzeichnis "C:\Windows\System32\WindowsPowerShell\v1.0" abgespeichert, um ein angenehmeres Schriftbild zu bekommen:

#Zuruecksetzen auf Defaultwerte
$psISE.Options.RestoreDefaults()

#Farben und Schriftgroeße anpassen
$psISE.Options.ConsolePaneTextBackgroundColor =  'Gray'
$psISE.Options.ErrorForegroundColor =  'Cyan'
$psISE.Options.FontSize = 11 #9

#Ausgabe des Profilpfades zu Beginn einer Sitzung mit der Powershell_ise
$ThisScriptFullPath = $($MyInvocation.InvocationName)
"ProfilPfad der Powershell_ISE: $ThisScriptFullPath`n"

Technet Scripting Guys: Customize Colors and Fonts in the Windows PowerShell ISE

weitere Gestaltungsmöglichkeiten finden man mittels

$psISE.Options | Get-Member
#[ConsoleColor]::GetValues([System.ConsoleColor])


Beispiel 3: Erweitern von Funktionen der Powershell mit der profile.ps1
In der profile.ps1 können Aliase und Pfade definiert und zusätzliche SnapIns registriert werden, die für sowohl für die Powershell_ise wie auch für die Powershell.exe gelten. Ich habe auch dieses ProfileSkript unter C:\Windows\System32\WindowsPowerShell\v1.0 gespeichert, so dass es für alle Benutzerkonten gültig ist. 

#Setzen von Aliasen
Set-Alias -Name GH -value get-help –Description "own: get-help"
Set-Alias –Name NP –value notepad.exe –Description "own: notepad"

#ShowAlias soll alle Aliase anzeigen
Function ShowAlias{ Get-Help * |?{$_.Category -eq "Alias"}|sort Name |Format-Table -auto }

#ShowAbout  zeigt alle konzeptionellen Hilfen an
Function ShowAbout{Get-Help About_ |select name,synopsis | format-table -auto}

#cd\ soll auch ohne Leerzeichen funktionieren
Function cd\ {cd \}

#PromptPfad setzen
Set-Location C:\Temp

#Bereinigen des Bildschirms
Clear-host

#Prüfen ob Fehler gemeldet werden (entspricht dem %errorlevel% aus MSDOS)
$LastExitCode
Function About{Get-Help About_ |select name,synopsis | format-table -auto}

#Ausgabe des ProfilePfades zu Beginn jeder Powershellsitzung
$ThisScriptFullPath = $($MyInvocation.InvocationName)
"PowershellProfile: $ThisScriptFullPath`n"

 

Zusammenfassung der Profile:

Ich habe die drei eben vorgestellten Profildateien in meinen Powershellverzeichnis "C:\Windows\System32\WindowsPowerShell\v1.0" und denke, dass dadurch das Scripting-Gefühl angenehmer ist als ohne

 Microsoft.PowerShellISE_profile.ps1.txt

 Microsoft.Powershell_profile.ps1.txt

 Profile.ps1.txt

 

3.3.2 Aliase

3.3.2.1 Überblick

Technet: about_Aliases

Ein Alias ist ein alternativer Name für ein cmdlet oder eine Funktion. Der Aufruf eines Alias ist damit gleichbedeutend wie der Aufruf des dahinterliegenden cmdlets oder einer Funktion

Beispiel 1: Get-Childitem und sein Alias gci

$ChildItems=@(Get-ChildItem c:\windows\system32)
#ist gleichbedeutend mit
$ChildItems=@(gci c:\windows\system32)

Anmerkung: @(...) zwingt $ChildItems in ein System.Array


Beispiel 2: Auflisten der Alias-CmdLets

Get-Help *alias*

#Ausgabe

Name                              Category  Synopsis
----                              --------  --------
Export-Alias                      Cmdlet    Exports information about currently defined aliases to a file.
Get-Alias                         Cmdlet    Gets the aliases for the current session.
Import-Alias                      Cmdlet    Imports an alias list from a file.
New-Alias                         Cmdlet    Creates a new alias.
Set-Alias                         Cmdlet    Creates or changes an alias (alternate name) for a cmdlet or ...
Alias                             Provider  Provides access to the Windows PowerShell aliases and the values th...
about_aliases                     HelpFile  Describes how to use alternate names for cmdlets and commands in ..


Beispiel 3: Welches cmdlet steckt hinter dem Alias "dir" ?

Get-Alias dir | Format-Table -auto

#Ausgabe

CommandType Name Definition   
----------- ---- ----------   
Alias       dir  Get-ChildItem

ausführlichere Informationen bekommt man mit

Get-Alias dir | Select-Object *

#Ausgabe

HelpUri             : go.microsoft.com/fwlink/
ResolvedCommandName : Get-ChildItem
ReferencedCommand   : Get-ChildItem
ResolvedCommand     : Get-ChildItem
Definition          : Get-ChildItem
Options             : AllScope
Description         :
OutputType          : {System.IO.FileInfo, System.IO.DirectoryInfo, System.String}
Name                : dir
CommandType         : Alias
Visibility          : Public
ModuleName          :
Module              :
Parameters          : {[Path, System.Management.Automation.ParameterMetadata], 

Anmerkung:
Man erkennt, dass "dir" ein Alias des cmdlets Get-ChildItem ist und ein Kompatibilitäts-Alias, da die Eigenschaft "Options" nicht auf "readonly" steht. ("Kompatibilitäts-Aliase" werden im nächsten Kapitel erklärt)

 
Beispiel 4: welche Aliase besitzt Get-ChildItem 

Möchte man umgekehrt zu Beispiel 3 sehen, welche Aliase das cmdlet Get-ChildItem besitzt, so erfährt man das über

Get-ChildItem alias: | where{$_.definition -eq "Get-ChildItem"} | Format-Table -auto
#Get-ChildItem alias: | where  Definition -eq Get-ChildItem | FT -auto #ab Powershell V3.0

#oder kürzer per Parameter
#Get-Alias -Definition Get-ChildItem | Format-Table -auto

#Ausgabe

CommandType Name Definition   
----------- ---- ----------   
Alias       dir  Get-ChildItem
Alias       gci  Get-ChildItem
Alias       ls   Get-ChildItem

#siehe Beispiele in der Onlinehilfe zu get-alias
Technet: Get-Alias -> Beispiel 3

 

3.3.2.2 Die drei Aliastypen

A) Kompatibilitäts-Aliase

diese Aliase dienen dazu altbekannte Commandlinebefehle vergangener DOS-Tage auch in der Powershell zu Verfügung zu stellen.

 

Beispiel 1: Auflisten der Kompatibilitäts-Aliase

Diese Aliase sind in der Powershell automatisch dabei. Ein Merkmal dieser Aliase ist, dass sie (temporär) entfernt werden können (-notmatch "Readonly") 

Get-ChildItem alias: | Where{$_.Options -notmatch "Readonly"} | Format-Table -auto
#Get-ChildItem alias: | Where{$PsItem.Options -notmatch "Readonly"} | Format-Table -auto 

#gekürzte Ausgabe
CommandType     Name               Definition

-----------     ----                ----------
Alias           cat                 Get-Content
Alias           cd                  Set-Location
Alias           chdir               Set-Location
Alias           clear               Clear-Host
Alias           cls                 Clear-Host
Alias           copy                Copy-Item

Alias           set                 Set-Variable
Alias           spjb                Stop-Job
Alias           type                Get-Content
Alias           wjb                 Wait-Job

Die Eigenschaft "options" kann man über "Get-Alias <alias> | Select options" herausfinden 


Beispiel 2: Entfernen aller Kompatibilitäts Aliase

Get-childitem Alias: | where{$_.options -notmatch "Readonly"} | Remove-Item

Anmerkung: Es muss ja nicht alles immer einen tieferen Sinn haben :-)


B) Canonical-Aliase

Im Gegensatz zu den Kompatibilitäts-Aliasen dienen die Canonical-Aliase dazu, Abkürzungen für häufiger benutzte PS-Cmdlets und Funktionen bereitzustellen. Diese Aliase sind ebenfall native in Powershell dabei, haben allerdings die Eigenschaft "Options" auf Readonly und können damit nicht entfernt werden. Allerdings kann ein User einem Alias eine neue Bedeutung zuweisen, was mir aber auch nicht besonders sinnvoll erscheint.


Beispiel 3: Auflisten der Canonical-Aliase

Get-Childitem alias: | Where{$_.options -match "Readonly"}

Get-Childitem alias: | Where{$_.options -match "Readonly"} | Format-Table -auto

#gekürzte Ausgabe
CommandType     Name            Definition
-----------     ----            ----------
Alias           %               ForEach-Object
Alias           ?               Where-Object
Alias           ac              Add-Content
Alias           asnp            Add-PSSnapIn
Alias           clc             Clear-Content

Alias           tee             Tee-Object
Alias           where           Where-Object
Alias           write           Write-Output  


Canonical Aliase können auch aus Sonderzeichen bestehen, wie z.B "%" und "?" für das Foreach- und WhereObject


Beispiel 4: Beweis, das "readonly" wirklich "readonly" bedeutet

Get-ChildItem alias: | where{$_.Options -match "ReadOnly"} | remove-item

#liefert Fehlermeldungen
Remove-Item : Alias was not removed because alias where is constant or read-only

 

C) Userdefinierte Aliase

Unter dem Aspekt des Customizings der eigenen Umgebung, ist dieser Typ Alias der Wichtigste:
Anwender können sich in ihren Profilen oder in der Powershellsession nach Belieben eigene Aliase definieren und verwenden. Sollen Aliase dauerhaft bestehen bleiben, so muss die Definition in einer Profildatei siehe Kapitel 3.3.1.2 Beispiele für Profile geschehen 


Beispiel 5: Definition eigener Aliase

Set-Alias -Name GH -Value Get-Help –Description "own: get-help"
Set-Alias –Name NP –Value Notepad.exe –Description "own: notepad"

Durch die angefügte Beschreibung ist es auch leicht, sich diese Gruppe von Aliasen anzeigen zu lassen.


Beispiel 6: Abfrage selbst definierter Aliase

Get-Alias | Where {$_.Description -like "own*"}
#oder Get-Alias | Where {$_.Description -NotLike ""}

#Ausgabe

CommandType     Name                  Definition
-----------     ----                  ----------
Alias           gh                    get-help
Alias           np                    notepad.exe

 

3.3.2.3 Verwendung von Aliase

Beim Entwickeln von Skripten ersparen Aliases häufiger cmdlets wie "gh" für "get-help" oder "gm" für "für get-member" eine Menge Tipparbeit

Man sollte beim Einsatz von Aliases innerhalb von Skripten bedenken, dass diese die Lesbarkeit des Skriptes eher verschlechtern. 

Den Einsatz von Kompatibilitätaliases und userdefinierten Aliases in Skripten vermeide ich wegen möglicher Kompatibilitätsproblemen auf anderen Rechnern oder späteren Powershellversionen gänzlich.

Das ist aber die persönliche Entscheidung jedes Skripters für sich.

 

3.3.3 Module und SnapIns


In diesem Kapitel geht es um die Erweiterung der Powershell mit zusätzlichen Funktionen. Dies kann mit der Powershell V1.0 über SnapIns und seit Powershell V2.0 auch über Module geschehen.

Übersicht über die grundsätzlichen Unterschiede der beiden Techniken:

SnapIns 

  •   sind in einer Microsoft .Net Sprache geschrieben. Dadurch ist mit der Powershell alles möglich, was mit diesen Programmiersprachen möglich ist 
  •   können nur cmdlets und Provider enthalten
  •   müssen installiert oder als DLLs registriert werden
  •   bilden die Powershell (siehe die Technet OnlineHilfe about_PSSnapins unter "integrierte Snapins") 

Module

  •   sind in Powershellsyntax geschrieben (*.psm1).
  •   können alle Powershellbestandteile wie cmdlets, Funktionen, Aliase, Variablen und Provider enthalten
  •   werden im Skript einfach eingebunden (Import-Module)
  •   sind einfacher zu erstellen und haben etliche Möglichkeiten mehr als SnapIns (siehe die Technet OnlineHilfe about_Modules)

Für den Endanwender macht es aber keinen Unterschied -abgesehen von der Installation-, ob seine zusätzlichen cmdlets von einem Module oder einem SnapIn bereitgestellt werden. 


Im Folgenden beschreibe ich die Installation einiger recht verbreiteter und nützlicher SnapIns und Module.

A) SnapIn: Quest ActiveRoles Management Shell for Active Directory 

Download: Free PowerShell Commands for Active Directory (Version 1.4.0)

Dieses SnapIn ist eine Ergänzung zum Questprodukt "Active Roles". Es enthält  eine ganze Reihe nützlicher cmdlets für Active Directory und das X.509 Zertifikatsmanagement, die unabhängig vom Einsatz der Questsoftware benutzt werden können. 

Da es sich um ein SnapIn handelt, ist eine Installation des *msi Files notwendig. Diese läuft recht unspektakuär ab: Doppelklick, Lizenzbedingungen bestätigen und die zusätzlichen cmdlets sind auf dem Rechner.
Im Startmenü unter "Alle Programme" -> "Quest Software" -> "ActiveRoles Management Shell for Active Directory x64" kann nun eine Powershellsession mit integrierten QAD-cmdlets gestartet werden.

Möchte man die QAD-cmdlets in jeder Powershellsession zur Verfügung haben, so muss das SnapIn zu Beginn jeder PS-Session folgendermaßen registriert werden:

 

Beispiel 1: Registrierung der QAD-cmdlets  

Add-PSSnapin quest.activeroles.admanagement

Anmerkung:
Damit man die Registrierung nicht bei jedem PowershellStart manuell durchführen muss, kann man diesen Befehl im Startprofile profile.ps1 ablegen (siehe das Kapitel Profile), was allerdings das Starten der PS-Shell spürbar verzögert.


Beispiel 2: Anzeige der neu hinzugekommenen QAD-cmdlets

Get-Command *qad*

Anmerkung: 
Die Quest-cmdlets beinhalten alle den String "qad"


Überlegungen zur Lizensierung:
Auf der genannten Downloadseite wird mehrfach das Wörtchen "Freeware" erwähnt, daher gehe ich davon aus, dass die cmdlets tatsächlich ohne Kosten benutzt werden können. 
Wenn ihr die QuestSnapins produktiv nutzen wollt, besorgt euch zu eurer eigenen Sicherheit die aktuell gültigen Lizenzbedingungen. Bedenkt auch, dass sich Lizenzbedingungen mit neuen Versionen ändern können. Um keine Überraschungen mit Lizenzkosten in der Zukunft zu erleben, solltet ihr auf Quest zugehen und euch den FreewareCharakter auch für die Zukunft bestätigen lassen.
Ich habe schon Hersteller gesehen, die sich ähnliche Pakete mit gut 100$ pro Jahr und Arbeitsplatz bezahlen lassen, da kann es in größeren Umgebungen schnell teuer werden, wenn man auf ein Programm nicht mehr verzichten kann.


B) Module: Community-Extensions (PSCX) Version 2.1.1

Diese Extensions bringen zusätzliche cmdlets mit, die viele Aufgaben vereinfachen. Zum Download gibt es die CommunityExtensions unter
CodePlex: PowerShell Community Extensions -> 2.1.1 Production 
Offenbar werden mit jedem Update der Version die alten Links ungültig. Sucht also, falls der Link nicht mehr funktioniert, auf dieser Seite nach "Community Extensions"

Die Installation der PSCX-Module ist auf dieser Seite ebenfalls beschrieben, daher hier nur eine kurze Zusammenfassung:

  1. Download der zip-Datei
  2. lokales Unblocken der zip-Datei (rechte Maustaste -> Eigenschaften -> Sicherheit: Zulassen (ohne dieses Unblocken erhält man bem späteren Importieren der Module laufend Sicherheitsabfragen)
  3. Kopieren des Ordners ./pscx entweder ins Userprofile unter "My Documents\WindowsPowerShell\Modules" oder nach $PSHome\Modules, je nachdem ob die Extensions für einen oder alle User verfügbar sein sollen. $PSHome bedeutet im Normalfall "C:\windows\system32\WindowsPowershell\v1.0\ . Der Ordner "pscx" wird also unter den vorhanden Ordner "Modules" kopiert.
  4. Import einer oder mehrerer Module entweder jedesmal im Script oder allgemein in profile.ps1
  5.  

Beispiel 3: Import aller pscx Module

Import-Module pscx


Beispiel 4: Import von bestimmten pscx Modulen

Import-Module Pscx -arg ~\Pscx.UserPreferences.ps1

In der Datei $PSHome\Modules\Pscx\Pscx.UserPreferences.ps1 ist in einer Hashtabelle festgelegt, welche Untermodule von pscx geladen werden sollen. Selbst wenn man alle Module lädt, spürt man kein Zeitverzögerung. Die einzelnen Untermodule sieht man im nächsten Beispiel


Beispiel 5: Anzeige der einzelnen pscx-Untermodule

C:\Windows\System32\WindowsPowerShell\v1.0\Modules\Pscx\Modules> get-childitem | select name

Set-Location C:\Windows\System32\WindowsPowerShell\v1.0\Modules\Pscx\Modules
Get-Childitem | Select Name

#Ausgabe
 
 Name
 ----
 CD
 DirectoryServices
 FileSystem
 GetChildItem
 GetHelp
 Net
 Prompt
 TabExpansion
 TranscribeSession
 Utility
 Vhd
 Wmi


Beispiel 6: Kontrolle der pscx-cmdlets und weitere Informationen

Get-Help About_Pscx
Get-Command -module Pscx -verb *


Unglücklich finde ich, dass einige, genauer gesagt drei, Community-cmdlets aus dem Namespace PSCX den gleichen Namen tragen, wie die orginal Powershell-cmdlets aus dem Namespace Microsoft.PowerShell.Management

Teilweise werden die orginal cmdlets mit nützlichen Funktionen ergänzt, wie das Starten von Prozessen auf einem Remoterechner mit PSCX\Start-Process. Leider erhalten aber auch Parameter neue Bedeutungen wie beispielsweise der -Wait Parameter von Start-Process. In der nativen Powershell -Microsoft.PowerShell.Management\Start-Process- wartet das Skript  bei

      "Start-Process notepad -wait"

auf eine Tastendruck, bevor es mit der Verarbeitung weiterfährt.

Bei dem Start-Process aus PSCX wird hinter -wait ein Wert erwartet, der die Anzahl der Sekunden angibt, wielange das Skript warten soll.

      get-help about_pscx liefert diese drei überschriebenen cmdlets
          * Get-Random
          * Start-Process
          * Select-Xml

Benutzt man nicht auf allen Rechnern die CommunityExtensions, so sind seltsame Verhalten eines Skriptes auf unterschiedlichen Rechner im wahrsten Sinne "vorprogrammiert". Informationen, wie man dieses Kompatibiltätsproblem umgehen kann, gibt es gleich zu Beginn der Online Hilfe "get-help about_pscx" im Abschnitt "Powershell Compatibility"

 

C) Module: Powershellpack

Download und erste Schritte: MSDN - PowerShellPack - Home

Das Powershellpack bringt nach der Installation des PowerShellPack.msi 10 neue Module mit:

http://code.msdn.microsoft.com/PowerShellPack

Diese Modul legt die Installationsroutine ins Modulverzeichnis des Userprofiles " .\Documents\WindowsPowerShell\Modules". Möchte man die Module für alle Anwender auf dem Rechner verfügbar haben, muss man diese ins Powershellinstallationsverzeichnis unter C:\Windows\System32\WindowsPowerShell\v1.0\Modules kopieren.

Danach können die Module wie gewohnt importiert und benutzt werden

 

Beispiel 7: Import eines Modules aus dem Powershellpack

Import-Module Taskscheduler
Get-Scheduledtask
#Ausgabe
Name                          Status       LastRunTime                   NextRunTime
----                          ------       -----------                   -----------
SidebarExecute                Ready        26.04.2011 08:53:46           30.12.1899 00:00:00
{EF2D7E73-E8C1-4F84-BA95-6... Ready        24.04.2011 22:26:52           30.12.1899 00:00:00

Ich muss zugeben, dass ich selbst noch nicht viel mit diesen Modulen gearbeitet habe.

 
D) neben den bereits genannten SnapIns und Modulen gibt es noch viele andere Erweiterungen
Besonders die freie Entwicklerseite www.codeplex.com ist eine gute Anlaufstelle

  • www.codeplex.com/PSHyperv  A project to provide a PowerShell management library for Hyper-V.
  • www.codeplex.com/PSSharePoint  A full PowerShell provider for exposing WSS/SPS 2003 (support for 2007 coming) as a filesystem
  • www.codeplex.com/PSEventing
  • poshbing.codeplex.com   A PowerShell script library for accessing Bing.com's API services
  • einge mehr (auf www.codeplex.com  nach "Powershell Provider" suchen)
  •  

3.3.4 Include File (Dot Sourcing)

Technet: Running Windows PowerShell Scripts -> Bonus: "Dot Sourcing" a script

In ein Powershellskript A kann ein anderes Powershellskript B eingebunden werden, so dass danach alle Variablen oder Funktionen aus Skript B verfügbar sind.

Beispiel 1: Einbinden eines anderen Skriptes (Include File)

. c:\powershell\Funktionen\zufall.ps1
# "c:\powershell\Funktionen\zufall.ps1"

Get-AlphanumericRandom -digits 8 -flag 1100

# mögliche Ausgabe

4507 928

Das Skript zufall.ps1 enthält eine Funktion zur Erzeugung zufälliger alphanumerischer Werte, die ich häufiger benutze. (Kapitel Die Variablen -> 1.1.2 explizite Typzuweisung -> Beispiel 3: Alphanumerische Zufallswerte erzeugen). Anstatt immer wieder neue Instanzen dieser Funktion zu erstellen und in Skripte hineinzukopieren, ist es komfortabler diese Funktion zentral abzulegen und bei Bedarf die zufall.ps1 einzubinden.

Die Einbindung erfolgt durch einen Punkt ("."), gefolgt von einem Leerzeichen und dem kompletten Pfad. Genauso funktioniert es ohne den Punkt ("."), wenn man den Pfad in Anführungszeichen setzt.

Natürlich können auch mehrere Funktionen in einer solchen Datei abgelegt werden, die man dann als zentrale Funktionsbibilothek betrachten kann.

 

3.3.5 nützliche Tools

  1. Installation VisualStudio + Productdocumentation
    Um Zugriff auf den Objectbrowser zu bekommen, installiert man am besten eine Version des VisualStudioPaketes z..B. Visual Basic 2008Edition with SP1.

    Mit dem ObjektBrowser kann man direkt auf das Dotnet-Framework durchgreifen und dort Klassen, Methoden und Eigenschaften erforschen

    Stehen die kostenpflichtigen Vollversionen von Visualstudio 2008/ 2010 nicht zur Verfügung, so genügt die konstenlose Expressversion vollkommen,
    Microsoft Download Center: Microsoft Visual Studio 2008 Express Editions with SP1
     
  2. WMIExplorer
    Um die WMI-Welt zu erforschen, bietet sich der selbst in Poweshell geschriebene WMIExplorer an. Ausserdem lassen sich automatisiert WMI-Skripte erstellen

    Download der Version für Powershell V2.0  (bei Attachment(s): WmiExplorer.ps1)
    http://thepowershellguy.com/blogs/posh/archive/2008/03/05/powershell-wmi-explorer-update-for-powershell-v2-ctp.aspx

    Die WmiExplorer-v2.ps1 speichere ich unter C:\Windows\System32\WindowsPowerShell\v1.0\Tools ab. Den Pfad füge ich der $Path Variable in der Profildate profile.ps1 hinzu. Siehe unter "Profile" im nächsten Kapitel. Der Aufruf kann dann jederzeit mit

    WMIe + Tabulator erfolgen
     
  3. PowerGUI bzw. PowerGui Scripteditor
    Die beiden Tools stammen ebenfalls von Quest. Die PowerGui ist eine grafische Oberfläche, um administrative Tätigkeiten in einer Windowsdomäne auszuführen.
    http://www.powergui.org/downloads.jspa

    Der PowerGUI Script Editor ist der Oberfläche von Visual Studio nachgebildet. Man kann dort Haltepunkte setzen,  Einzelschritte ausführen etc.

 

3.4 .Net Framework Versionen in Powershell

Ein Beispiel, wie die installierte .Net Version bestimmt werden kann, findet ihr unter Das FileSystem - 2 Laufwerke, Ordner, Dateien und Freigaben (Ohne ACL) - 2.1.2.3 Existenzprüfung von Elementen -> Beispiel 2

Ohne besondere Modifikationen an der Powershellkonfiguration oder am Betriebssystem kann Powershell die angebotenen Klassen, Methoden und Eigenschaften des .Net Frameworks 2 ausnutzen. Das ist auf jeden Fall schon mal eine ganze Menge.

Trotzdem kann es passieren, dass man interessante Funktionen beispielsweise in Codebeispielen zu C# oder VB in der MSDN findet, die man gerne in ein Powershellskript übersetzen möchte. 
Beispielsweise enthält die Beschreibung der Klasse GZipStream ein schönes Beispiel, um Verzeichnisse zu Komprimieren. MSDN:  GZipStream-Klasse

Versucht man dieses Beispiel in Powershell nachzuprogrammieren, wird man feststellen, dass die Methode "CopyTo" in der Powershell default nicht angeboten wird. Das Thema Packen behandle ich im Kapitel Das Filesystem -> 2.1.2.5 Packen (Zippen) von Verzeichnissen und Dateien


Beispiel 1: Methoden der Klasse GZipStream im Framework 2 und im Framework 4

$MemoryStream = New-Object System.IO.MemoryStream 
$GzipStream = New-Object System.IO.Compression.GzipStream $MemoryStream , ([IO.Compression.CompressionMode]::Compress), $true
$GzipStream | Get-Member
#Ausgabe unter dem Framework 2 (gekürzt)

   TypeName: System.IO.Compression.GZipStream

NameMemberType Definition         
-------------- ----------         
BeginRead                 Method     System.IAsyncResult BeginRead(byte[] ...
BeginWrite                Method     System.IAsyncResult BeginWrite(byte[] array, ...
Close                     Method     System.Void Close()
CreateObjRef              Method     System.Runtime.Remoting.ObjRef CreateObjRef ...
#Ausgabe unter dem Framework 4 (gekürzt)

   TypeName: System.IO.Compression.GZipStream

NameMemberType Definition         
-------------- ----------         
BeginRead                 Method     System.IAsyncResult BeginRead(byte[] , ...
BeginWrite                Method     System.IAsyncResult BeginWrite(byte[] array, int offset ..
Close                     Method     System.Void Close()
CopyTo                    Method     System.Void CopyTo(System.IO.Stream destination), ...             
CreateObjRef              Method     System.Runtime.Remoting.ObjRef CreateObjRef(type ...

Wie man erkennt, steht unter dem Framework 2 die Methode "CopyTo" nciht zur Verfügung.


Es gibt nun zwei Möglichkeiten der Powershell den Zugriff auf das Framework 4 zu ermöglichen.

a) Mit den folgenden beiden Registryschlüsseln wird systemweit der Zugriff auf das Framework 4 geregelt

reg add hklm\software\microsoft\.netframework /v OnlyUseLatestCLR /t REG_DWORD /d 1
reg add hklm\software\wow6432node\microsoft\.netframework /v OnlyUseLatestCLR /t REG_DWORD /d 1

how-can-i-run-powershell-with-the-net-4-runtime

das zweite obige Beispiel habe ich erstellt, nachdem die Keys auf meinem Windows7 gesetzt waren.


b) durch Hinzufügen der beiden Config-Dateien " PowerShellISE.Exe.Config " und " PowerShellISE.Exe " mit dem in den Powershellordner mit folgenden Inhalt

<?xml version="1.0"?> 
<configuration> 
    <startup useLegacyV2RuntimeActivationPolicy="true"> 
        <supportedRuntime version="v4.0.30319"/> 
        <supportedRuntime version="v2.0.50727"/> 
    </startup> 
</configuration>

wird nur die Powershell beeinflusst, das Framework 4 zu nutzen.

tfl09.blogspot.com/2010/08/using-newer-versions-of-net-with.html

Diese Methode hat auf meinen Maschinen, auf denen allerdings Visual Studio installiert ist, nicht funktioniert. 

Powershellskripte, die Funktionen aus dem Framework 4 nutzen, sind nicht mehr so einfach auf andere Rechner portierbar! Das sollte man berücksichtigen. 

 

4 Troubleshooting Installation/ Customizing

  1. Auf einem deutschen XP-System (Powershell CTP3) lässt sich keine "Conceptual help topics" aufrufen,  die man normalerweise mit "get-help about_" erreicht.
    Dies funktioniert, wenn man im Powershell Installationsverzeichnis z.B. C:\WINDOchtWS\system32\WindowsPowerShell\v1.0 das Unterverzeichnis "en-US" kopiert und die Kopie in "de-DE" umbenennt.
     
  2. Auf einem XP-System kamen beim Start der Powershell dutzende Fehlermeldungen. Das Deaktivieren und Umbenennen, sowie das Entfernen der Registrykeys aus  http://blogs.msdn.com/powershell/archive/2007/01/09/behind-powershell-installer-for-windows-xp-windows-server-2003.aspx brachte keine Besserung.
    Erst das Entfernen des Powershell-Installationsverzeichnisse (default: %windir%\system32\WindowsPowershell\ und anschließender Neuinstallation ließ die Powershell fehlerfrei starten.