Windows PowerShellLeistungsfähige Profile

Don Jones

Inhalt

Shells, Hosts und Profile
Verwenden Ihres Profils
Erstellen einer benutzerdefinierten Konsole
Weitere Profiltricks
Vorsicht, Profile!

Wenn Sie diese Rubrik regelmäßig lesen, wissen Sie jetzt, dass Windows PowerShell ein System von Profilen unterstützt. Dabei handelt es sich im Grunde um Shellskripts mit der Dateinamenerweiterung .ps1, die bei Ausführung der Shell automatisch ausgeführt werden. Sie stellen beispielsweise eine hervorragende Möglichkeit für das Definieren benutzerdefinierter Aliase dar. Bei jeder Ausführung der Shell können Sie das Profil Ihre Aliase automatisch definieren lassen, sodass sie bei jeder Verwendung der Shell verfügbar sind.

Die Shell definiert die folgenden vier verschiedenen Profile:

• Ein Profil, das für alle Shells und alle Benutzer des Computers gilt.
• Ein Profil, das für alle Benutzer und nur für die Microsoft PowerShell-Shell gilt.
• Ein Profil, das für den aktuellen Benutzer und alle Shells gilt.
• Ein Profil, das für den aktuellen Benutzer und nur die Microsoft PowerShell-Shell gilt.

Das Konzept „alle Shells“ kann etwas verwirrend sein. Die Terminologie beruht auf einigen frühen Entwicklungskonzepten von Windows PowerShell, die nicht in das Endprodukt aufgenommen wurden. Heute wäre der Begriff „alle Hosts“ wahrscheinlich passender.

Shells, Hosts und Profile

Windows PowerShell selbst ist ein Satz von Microsoft .NET Framework-Assemblys. Ich bezeichne diesen Teil der Shell gern als Windows PowerShell-Modul, da es die Funktionalität enthält, an die Sie bei Windows PowerShell im Allgemeinen denken. Es gibt jedoch keine integrierte Möglichkeit für Benutzer, mit diesem Modul zu interagieren. Damit Sie die Shell tatsächlich verwenden können, muss das Modul von einer Hostanwendung (einem Host) geladen werden.

Die Anwendung „powershell.exe“, an deren Ausführung Sie wahrscheinlich gewöhnt sind, ist ein solcher Host. Die in der Community Technology Preview (CTP) von Windows PowerShell 2.0 enthaltene Anwendung „gpowershell.exe“ ist ein weiterer Host. Diese Beziehung zwischen Hosts und Shells ist nicht ganz so einfach, wie ich es hier dargestellt habe, aber meine vereinfachte Erklärung deckt das Verhalten ab, das Sie sehen.

Es ist wichtig zu verstehen, dass Sie wahrscheinlich den Host „powershell.exe“ verwenden, wenn Sie über eine textorientierte Befehlszeilenschnittstelle mit der Shell interagieren. Dies gilt selbst dann, wenn Sie die Shell über eine Verknüpfung gestartet haben, die von einer anderen Anwendung wie der Exchange-Verwaltungsshell installiert wurde. Die Exchange-Verwaltungsshell ist keine andere Shell oder Hostanwendung, sondern der normale Host „powershell.exe“, der lediglich mithilfe einer Verknüpfung gestartet wurde, die einen Satz von vorab zu ladenden Snap-Ins und Skripts angibt. Diese Snap-Ins aktivieren die Exchange-Verwaltungsfunktionalität innerhalb der Shell. Sie verwenden aber nach wie vor die gleiche Shell.

Für die Profile für den Host „powershell.exe“ gelten (unter Windows Vista) die folgenden Speicherorte:

• %windir%\system32\WindowsPowerShell\v1.0\profile.ps1 Dieser Speicherort gilt für alle Benutzer des Computers und für alle Shells.
• %windir%\system32\WindowsPowerShell\v1.0\Microsoft.PowerShell_profile.ps1 Dieser Speicherort gilt für alle Benutzer des Computers, aber nur für die Microsoft.PowerShell-Shell.
• %UserProfile%\Documents\WindowsPowerShell\profile.ps1 Dieser Speicherort gilt nur für den aktuellen Benutzer und für alle Shells.
• %UserProfile%\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 Dieser Speicherort gilt nur für den aktuellen Benutzer und nur für die Microsoft.PowerShell-Shell.

Diese Profile werden nicht standardmäßig erstellt. Sie sind nur vorhanden, wenn Sie sie erstellen.

Jede Hostanwendung ist für das Laden und Ausführen des richtigen Profils verantwortlich. Wenn eine bestimmte Hostanwendung „entscheidet“, überhaupt keine Profile zu laden, muss sie diese auch nicht laden. Die Profilausführung wird vom Windows PowerShell-Modul nicht automatisch durchgeführt.

Die einfachste Möglichkeit, den Überblick über alle diese Aspekte zu behalten, besteht darin, die Shell einfach zu öffnen, „$profile“ einzugeben und dann die Eingabetaste zu drücken. Dadurch wird der vollständige Pfad angezeigt, den die Shell als „primäres“ Profil zu verwenden versucht (das benutzer- und shellspezifische Profil). Sie können dieses Skript dann erstellen oder ändern, wonach es bei jedem Start der Shell ausgeführt wird.

Verwenden Ihres Profils

Wie bereits erwähnt, werden Profile häufig zum Definieren benutzerdefinierter Aliase verwendet. Sie können auch benutzerdefinierte PSDrives hinzufügen (dabei handelt es sich im Grunde um zugeordnete Laufwerke, die vollständig innerhalb von Windows PowerShell existieren.) Ein weniger häufiger Verwendungszweck besteht darin, auf Grundlage der Softwareprodukte, die Sie in Ihrer Umgebung verwenden, eine Art Supershell zu erstellen, die jede Verwaltungsaufgabe übernehmen kann, die Sie eventuell benötigen. Um das Konzept der Supershell wirklich erklären zu können, muss ich Ihnen zunächst einige Hintergrundinformationen liefern.

Die Produktgruppe innerhalb von Microsoft, die Windows PowerShell entwickelt, ist auch für viele andere zentrale Verwaltungstechnologien verantwortlich, einschließlich der Microsoft Management Console (MMC). Die MMC bietet eine gute Analogie für die Funktionsweise von Windows PowerShell. Wenn Sie mmc.exe ausführen, beginnen Sie mit einer leeren Konsole, die nicht viel Funktionalität bietet. Sie fügen MMC-Snap-Ins hinzu, um eine funktionsfähige Konsole zu erstellen.

Wenn Sie Ihre Konsole in der gewünschten Weise konfiguriert haben, speichern Sie die Konsole in einer Datei mit der Dateinamenerweiterung „.msc“. Diese gespeicherte Konsolendatei ermöglicht Ihnen, Ihre benutzerdefinierte Konsole jederzeit schnell erneut zu laden.

Statt benutzerdefinierte MMC-Konsolen zu erstellen, verwenden viele Administratoren ausschließlich die Konsolen, die zusammen mit den von ihnen verwalteten Produkten installiert werden. In Exchange Server wird z. B. eine Konsole erstellt, die nur das Exchange Server-Snap-In enthält. „Active Directory-Benutzer und -Computer“ ist eine weitere vorab erstellte Konsole, die nur ein einziges Snap-In enthält.

Windows PowerShell funktioniert weitgehend in derselben Weise. Das Symbol „Exchange-Verwaltungsshell“, das mit den Exchange Server 2007-Verwaltungstools installiert wird, ist tatsächlich eine Verknüpfung zu powershell.exe mit Anweisungen zum Laden einer Konsolendatei. Shellkonsolendateien besitzen die Dateinamenerweiterung „.psc1“ und enthalten eine Liste von vorab zu ladenden Snap-Ins (so wie eine .msc-Datei eine Liste von Snap-Ins enthält, die von der MMC für Sie vorab geladen werden). Sie sind jedoch nicht auf die Verwendung dieser im Voraus erstellten Konsolen angewiesen. Sie können – genau wie bei der MCC – eine benutzerdefinierte Konsole erstellen und diese zur Durchführung aller Ihrer Verwaltungsaufgaben verwenden. Profile spielen hierbei eine Schlüsselrolle.

Erstellen einer benutzerdefinierten Konsole

Um eine benutzerdefinierte Konsole zu erstellen, sollten Sie zunächst nach dem vollständigen Namen jedes Snap-Ins suchen, mit dem Sie arbeiten möchten. Stellen Sie sicher, dass alle erforderlichen Verwaltungstools auf Ihrem Computer installiert sind. Führen Sie dann in Windows PowerShell „Get-PSSnapin –registered“ aus. Dadurch werden alle verfügbaren Snap-Ins aufgelistet, die registriert sind, aber noch nicht geladen wurden. Erstellen oder bearbeiten Sie dann das entsprechende Windows PowerShell-Profil. Fügen Sie die Add-PSSnapin-Befehle zum Laden jedes Snap-Ins hinzu, das immer verfügbar sein soll. Hierzu können Snap-Ins für Exchange Server, System Center-Produkte und Snap-Ins von Drittanbietern wie die PowerShell-Communityerweiterungen gehören. Speichern Sie dann Ihr Profil (vergessen Sie nicht, das Profil digital zu signieren, wenn Ihre Windows PowerShell-Ausführungsrichtlinie dies erfordert), und schließen Sie die Shell. Wenn Sie die Shell erneut öffnen, werden alle in Ihrem Profil aufgelisteten Snap-Ins automatisch geladen.

Ein anderes Verfahren besteht darin, alle Ihre Snap-Ins (mit Add-PSSnapin und den Namen der Snap-Ins) in die Shell zu laden und dann „Export-Console“ auszuführen, um eine .psc1-Konsolendatei zu erstellen, die alle Snap-Ins enthält, die Sie gerade verwenden. Sie können diese .psc1-Konsolendatei zum Erstellen einer neuen Windows PowerShell-Verknüpfung verwenden, die den Parameter „PSConsole­File“ und Ihre benutzerdefinierte .psc1-Datei angibt. Diese Verknüpfung würde dann Ihre Konsole verwenden und alle angegebenen Snap-Ins automatisch laden.

Weitere Profiltricks

Ich verwende mein Windows PowerShell-Profil, um bei jedem Start der Shell eine Reihe weiterer nützlicher Aufgaben durchzuführen. Wenn die Shell auf meinem System gestartet wird, werden unter anderem die folgenden Schritte durchgeführt:

1. Ich führe „Get-Credential“ für mein Domänenadministratorkonto aus und speichere die Ergebnisse in einer Variablen namens „$cred“. Dadurch wird $cred in der gesamten Shell verfügbar. Ich kann die Variable dann an den –credential-Parameter verschiedener Cmdlets (z. B. des Cmdlet „Get-WmiObject“) übergeben. Da $cred das Kennwort speichert, kann ich diese Cmdlets verwenden, ohne nach einem Kennwort gefragt zu werden.
2. Ich führe „Cd C:\“ aus, damit die Shell im Stammverzeichnis des Laufwerks C: meines Computers gestartet wird.
3. Ich führe „New-Alias of Out-File“ aus, um einen Alias namens „of“ zu erstellen, damit ich dann „of“ anstelle von „Out-File“ verwenden kann. Da ich dieses Cmdlet sehr häufig verwende, ist die Definition des kurzen Alias sehr nützlich.

Ich versuche, einen Testschlüssel im Laufwerk HKLM: der Shell zu erstellen, das den HKEY_LOCAL_MACHINE-Teil der Registrierung darstellt. Wenn ein Fehler auftritt, weiß ich, dass die Shell ohne erhöhte Rechte gestartet wurde. Für meine Arbeit benötige ich in der Regel erhöhte Rechte, und auf diese Weise kann ich vorab schnell feststellen, ob ich über erhöhte Rechte verfüge, bevor ich ernsthaft mit der Arbeit beginne.

Ich definiere eine benutzerdefinierte Funktion namens „Ping-Address“, die einen Computernamen oder eine IP-Adresse annimmt und in Abhängigkeit davon, ob der Computer per Ping erreichbar ist, den Wert „True“ oder „False“ zurückgibt. Ich verwende diese Funktion häufig bei meiner Arbeit, und wenn sie in meinem Profil definiert ist, wird sie in meiner Shell global verfügbar.

Cmdlet des Monats: Get-WmiObject

Aufmerksamen Beobachtern dürfte auffallen, dass ich ein Cmdlet behandle, das ich schon einmal vorgestellt habe. Ich möchte Ihnen aber einen praktischen Trick verraten, der damit möglich ist. Ich sehe häufig, dass Administratoren versuchen, mit dem folgenden Verfahren WMI-Informationen (Windows Management Instrumentation, Windows-Verwaltungsinstrumentation) von mehreren Computern abzurufen, deren Namen in einer Textdatei aufgelistet sind:

Get-Content c:\computers.txt | ForEach-Object 
  { Get-WmiObject Win32_Service –comp $_ }

Obwohl dieses Verfahren funktioniert, sind Sie nicht wirklich darauf angewiesen, da „Get-WmiObject“ ein Array von Computernamen für den Parameter „–computerName“ annehmen kann. Um die gleiche Wirkung zu erzielen, können Sie einfach folgenden Code verwenden:

Get-WmiObject Win32_Service –comp (Get-Content
  c:\computers.txt)

Wenn Sie den Befehl „Get-Content“ in Klammern setzen, wird die Shell angewiesen, den Befehl auszuführen und die Ergebnisse – ein Array von Computernamen – im Parameter „–computerName“ zu speichern.

Vorsicht, Profile!

Beachten Sie, dass powershell.exe nicht die einzige Anwendung ist, von der die Microsoft.PowerShell-Profile oder die für alle Shells geltenden Profile geladen werden. In vielen integrierten Entwicklungsumgebungen (integrated development environments, IDEs), die Windows PowerShell-Unterstützung bieten – einschließlich PrimalScript von SAPIEN Technologies, PowerGUI von Quest Software und PowerShell Plus von ShellTools – werden dieselben Profile geladen, um eine mit dem Host „powershell.exe“ vergleichbare Funktionalität zu bieten.

Ein großes Profil, das viele Snap-Ins lädt, kann dazu führen, dass diese Anwendungen langsamer gestartet werden, da das Windows PowerShell-Modul zahlreiche Anweisungen ausführen muss, bevor es für die Hostanwendung bereit ist. Tatsächlich kann selbst der Start von powershell.exe einige Zeit in Anspruch nehmen, wenn Sie ein sehr großes Profilskript ausführen müssen.

Snap-Ins, die Cmdlets mit demselben Namen definieren, können ebenfalls Konflikte verursachen. Wenn zwei Snap-Ins beispielsweise ein Cmdlet namens „Get-User“ definieren, führt Windows PowerShell keines der Cmdlets aus, bis Sie den vollqualifizierten Namen des Cmdlet verwenden, um das gewünschte Cmdlet anzugeben. Dieser vollqualifizierte Name kann sich als umständlich erweisen, da die Namen von Snap-Ins recht lang sein können. Wenn ich mit diesem Problem konfrontiert werde, gebe ich in der Regel das Vorhaben auf, diese beiden Snap-Ins gleichzeitig laden zu lassen. Stattdessen lade ich nur das Snap-In, das ich in meinem Profil am meisten verwende. Wenn ich dann das andere Snap-In laden und verwenden muss, verwende ich eine separate, „neue“ Shell.

Windows PowerShell-Profile können ein hohes Maß an zusätzlichem Komfort für die Shell bieten. Wenn sie aber von Malware zu böswilligen Zwecken bearbeitet werden, können Profile auch großen Schaden anrichten. Sie können Ihr Profil schützen, indem Sie es digital signieren und Windows PowerShell für die Verwendung der AllSigned-Ausführungsrichtlinie konfigurieren oder die NTFS-Dateiberechtigungen für alle Ihre Profile so ändern, dass sie über Ihr normales Benutzerkonto nicht geändert werden können.

Don Jones ist der Autor von Windows PowerShell: TFM und VBScript, WMI, and ADSI Unleashed. Sie können ihn über die Website PowerShellCommunity.org erreichen.