System-Administration mit Microsofts PowerShell Teil 4 PowerShell-Scriptdateien und Profile

Der vierte Teil der PowerShell-Artikelserie beschäftigt sich mit der Erstellung von Scriptdateien und der damit verbundenen Sicherheitskonfiguration. Außerdem werden Profile, spezielle Dateien, die beim Start der PowerShell automatisch ausgeführt werden, besprochen.

Anbieter zum Thema

Lenovo Global Technology Germany GmbH

Cradlepoint GmbH

Microsoft Deutschland GmbH

Im Gegensatz zum bisherigen Paar, bestehend aus Eingabeaufforderung cmd.exe und den Scripts für den Windows Script Host (WSH) unterscheidet sich der Befehlssatz, der direkt in der Shell verwendet werden kann, nicht von Befehlen innerhalb der PowerShell-Scriptdateien. Die Dateien eignen sich daher, um mehrfach benötigte Codeteile und Funktionen zu speichern und einfach aufzurufen.

PowerShell-Scriptdateien sind einfache Textdateien mit der Dateiendung „ps.1“. Das „ps“ steht dabei für PowerShell und die „1“ für die Version derselben. In der Standardkonfiguration startet ein Doppelklick auf eine derart ausgezeichnete Datei nicht den Befehlsinterpreter, wie es noch beim WSH der Fall war. Es öffnet sich lediglich, ganz unspektakulär, das Notepad und zeigt den Scriptcode an.

Scripts starten

Soll eine Scriptdatei ausgeführt werden, ist ein wenig zusätzlicher Aufwand erforderlich. Die Datei wird als Parameter der Datei powershell.exe angegeben. Allerdings reicht das noch nicht ganz. Für die Datei beispiel.ps1 aus dem Hauptverzeichnis des Laufwerks C: würden folgende Beispiele die Scriptverarbeitung starten:

• powershell.exe „& c:\beispiel.ps1“
• powershell.exe „. c:\beispiel.ps1“

In beiden Fällen wird indirekt der Parameter „command“ verwendet. Entsprechend gleichbedeutend wären folgende Befehlszeilen:

• powershell.exe -command „& c:\beispiel.ps1“
• powershell.exe -command „. c:\beispiel.ps1“

Der Pfad zur Scriptdatei muss immer angegeben werden, ansonsten erscheint eine Fehlermeldung.

Die Zeichen „.“ und „&“ sind Befehle zum Aufruf von Scripts und beschreiben den Scope, also den Sichtbarkeitsbereich von Variablen. Da dies beim direkten Start von Scripts keine Bedeutung hat, ist es an dieser Stelle egal, welcher Befehl eingesetzt wird.

Scriptstart direkt aus der PowerShell

Auch direkt aus der PowerShell kann eine Scriptdatei gestartet werden. Ebenso lassen sich Scriptdateien aus anderen Scriptdateien heraus aufrufen. Dabei spielt der Unterschied zwischen „.“ und „&“ jedoch eine Rolle.

Eine Datei, die mit „.“ aufgerufen wird, läuft im aktuellen Scope. Sie kann damit auf die derzeit aktuellen Variablen zugreifen und auch neue hinzufügen, die für den Programmteil, der das Script aufgerufen hat, dann auch sichtbar sind.

Wird eine Datei dagegen mit „&“ gestartet, läuft sie in seinem eigenen Scope und ist somit unabhängig vom Code, der den Aufruf getätigt hat.

Scriptdateien in der Pipeline

Im 2. Teil der PowerShell-Artikelserie wurde bereits gezeigt, wie Funktionen eingesetzt werden. Im 3. Teil wurde die Pipeline besprochen. Scriptdateien lassen sich wie Funktionen als Pipelineelement einsetzen. Das Ansprechen der übergebenen Objekte geschieht dabei über die vordefinierte Variable $args[].

Zeilenkommentare über Rautezeichen

Je intensiver Scriptdateien eingesetzt werden, desto wichtiger ist es, den Code zu kommentieren. Beispielsweise sind oft Angaben zu Funktion, Autor, Erstellungsdatum, Änderungen, etc. hilfreich, wenn die Scriptdateien Wochen später von Autor selbst oder gar von einer anderen Person geändert werden müssen.

Die PowerShell kennt das Rautezeichen („#“) als Kommentarbefehl. Es muss zu Beginn einer Zeile stehen und gilt auch jeweils nur für eine einzelne Zeile.

Sicherheitskonfiguration für Scriptdateien

In der Standardkonfiguration wird nicht jedes Script ausgeführt. Dateien, die aus einem Netzwerk stammen, werden blockiert. Diese Einstellung wird über das Cmdlet set-executionpolicy festgelegt. Der allgemeine Aufruf sieht dabei wie folgt aus:

set-executionpolicy -executionpolicy „“

Die möglichen Werte sind:

• Restricted: Script-Ausführung deaktiviert
• AllSigned: Nur signierte Scripts ausführen
• RemoteSigned: Heruntergeladene Scripts nur ausführen, wenn Signatur vorhanden (Standard)
• Unrestricted: Jedes Script ausführen

Mit dem Cmdlet wird ein Wert in der Systemregistrierung gesetzt. Die Einstellung wirkt sich systemweit aus.

Die Standardeinstellung „RemoteSigned“ hat sich dabei im Vergleich zur letzten Beta-Version der PowerShell geändert, denn dort galt noch „Restricted“, wodurch keine Scripts ausgeführt wurden. Nach einem Update von der Beta zur finalen Version wird die Einstellung allerdings nicht neu gesetzt, muss also gegebenenfalls erst angepasst werden.

Scripts signieren

In der schärfsten Sicherheitseinstellung „AllSigned“ werden nur Scripts ausgeführt, wenn diese eine digitale Signatur des Entwicklers tragen und dieser auf dem ausführenden Computer vertraut wird. Die Signierung erfordert ein für die Codesignatur geeignetes Zertifikat einer Zertifizierungsstelle, etwa dem gleichnamigen optionalen Dienst der Windows-Serverbetriebssysteme.

Die Signierung einer Datei erfolgt mit Hilfe des Cmdlets set-authenticodesignature, nachdem das zu verwendende Zertifikat ausgewählt wurde. Hier ein Beispiel zur Signierung der Datei test.ps1:

#Zertifikat auswählen$cert = @(get-childitem cert:\CurrentUser\My -codesigning)[0]#Signierung durchführenset-authenticodesignature -filepath .\test.ps1 -certificate $cert

Profile zur Anpassung der PowerShell-Umgebung

Bei Profilen handelt es sich um Scriptdateien, die beim Start der PowerShell automatisch ausgeführt werden. Mit ihnen kann die PowerShell-Umgebung angepasst werden, indem beispielsweise häufig verwendete Funktionen und Aliase angelegt werden. Insgesamt wird zwischen vier Profilen unterschieden, die alle an unterschiedlichen Orten abgelegt werden müssen:

• \profile.ps1: Allgemeines Profil
• \Microsoft.PowerShell_profile.ps1: Profil ohne Hosting-Anwendungen
• \WindowsPowerShell\profile.ps1: Benutzerprofil
• \WindowsPowerShell\Microsoft.PowerShell_profile.ps1: Benutzerprofil ohne Hosting-Anwendungen

Unter einer Hosting-Anwendung versteht man Programme, welche die PowerShell integrieren, was in Zukunft sicher häufiger der Fall sein wird. Im folgenden fünften Teil der PowerShell-Artikelserie zeigt IP-Insider, wie mit PowerShell-Cmdlets das Betriebssystem verwaltet werden kann.

(ID:2002632)