hin255 - Fotolia

Workflows oder Skripte: Vor- und Nachteile beim Arbeiten mit der PowerShell

PowerShell-Skripte haben ihre Stärken – und einige kleine Schwächen. Mit PowerShell-Workflows lassen sich einige dieser Einschränkungen umgehen.

PowerShell-Skripte sind seit Jahren weit verbreitet und erfreuen sich unter Administratoren großer Beliebtheit. Skripte sind aber nicht die einzige Möglichkeit, PowerShell-Code auszuführen. Zum herkömmlichen Scripting bietet die PowerShell nämlich eine Alternative, die einige Vorteile mit sich bringt.

Workflows und Skripte der PowerShell sind sich sehr ähnlich: beide bestehen aus einer Abfolge programmatischer Schritte oder Aktivitäten. PowerShell kann mit dem Betriebssystem Windows interagieren, tauscht sich aber auch auf tieferer Ebene mit einigen Serveranwendungen aus. Damit können Administratoren so ziemlich jede denkbare Aufgabe auch programmatisch abarbeiten lassen.

Und trotzdem weist die PowerShell Einschränkungen auf, die aber durch die Einbeziehung des .NET Frameworks von der PowerShell aus aufgelöst werden können. Mit .NET können beispielsweise grafische Schnittstellen über Skripte angesprochen werden. Auch mathematische Operationen, die das .NET Framework anbietet, können reichhaltiger sein als das eigene Angebot der PowerShell.

PowerShell Workflows arbeiten mit der Windows Workflow Foundation (WWF), die Teil des .NET Frameworks ist. Sie umfassen eine Programmierschnittstelle und eine Workflow Engine, die dem Erzeugen von Workflows dient. Ähnlich wie Skripte bestehen auch Workflows aus einer Aneinanderreihung von Aktivitäten, von denen jede einzelne eine bestimmte Aufgabe erfüllt. Mehrere solcher Aktivitäten lassen sich in einem komplexen PowerShell-Workflow zusammenfassen.

Diese Aktivitäten werden dann als .NET-Aktivitäten modelliert. Das .NET Framework bietet eine Bibliothek an, die bereits die gängigsten Aktivitäten zum Anlegen von .NET-Workflows enthält. Mit dieser Funktionalität können Administratoren ihre eigenen Aktivitäten erstellen und vergleichbare Workflows in der PowerShell abbilden.

Workflows und Skripte: Die Grenzen der PowerShell

PowerShell-Skripte können durch den Griff in das erweiterte Angebot des .NET Frameworks außerordentlich funktionsstark werden. Allerdings bleibt es auch damit dabei, dass PowerShell-Skripte an einen Prozess des Betriebssystems gebunden sind. Öffnet man zum Beispiel ein PowerShell-Fenster und startet ein PowerShell-Skript, so gehört dieses Fenster zu einem Prozess, der die Ausführungsumgebung für dieses Skript wird. Im Grunde ist ein PowerShell-Fenster also eine Sandbox-Umgebung.

Diese Prozessisolierung ist in vielen Fällen sinnvoll und hilfreich, sie kann aber auch Probleme verursachen. Öffnet man etwa ein PowerShell-Fenster, legt wie in Abbildung 1 eine Variable $A an und versucht dann, diese Variable von einem anderen PowerShell-Fenster aus anzusprechen, so schlägt dieser Zugriff aufgrund der Isolierung der unterschiedlichen PowerShell-Prozessumgebungen für die PowerShell-Fenster fehl.

Die in einem PowerShell-Fenster erstellte Variable kann von einem anderen PowerShell-Fenster aus nicht angesprochen werden.
Abbildung 1: Die in einem PowerShell-Fenster erstellte Variable kann von einem anderen PowerShell-Fenster aus nicht angesprochen werden.

Vorteile von PowerShell-Workflows

PowerShell-Workflows sind dagegen nicht an ein PowerShell-Fenster gebunden. Daher können sie auch auf mehreren unterschiedlichen Geräten simultan ablaufen. So kann man beispielsweise auch mehrere Workflows simultan und parallel betreiben. Dadurch können Runbooks mit gesonderten Aktivitäten erstellt werden, die simultan statt nacheinander ablaufen. Dadurch wird die Abarbeitung der Aufgaben, etwa das Provisionieren virtueller Maschinen, erheblich effizienter.

Auch ein größeres Problem wird von PowerShell-Workflows adressiert: Läuft ein PowerShell-Skript während des Systemneustarts, so geht jeglicher Fortschritt verloren – das Skript muss komplett neu ausgeführt werden. PowerShell-Workflows können den Fortschritt im Blick behalten und können ihre Aufgaben somit nach einem Neustart, dem Verlust der Netzwerkverbindung oder nach anderen Unterbrechungen fortführen. Ein weiterer Vorteil: PowerShell-Workflows lassen sich auch ohne Kenntnisse des .NET Framework nutzen.

Grundsätzlich eignen sich alle längeren und komplexen Skripte auch für PowerShell-Workflows. Allerdings wird nicht jedes PowerShell-Cmdlet für die Nutzung in Workflows unterstützt. Dies wiederum relativiert sich allerdings durch die Nutzbarkeit der Funktion InlineScript, die auch nicht-unterstützte Kommandos in Workflows integrieren kann. Mehrere PowerShell-Workflows können simultan ablaufen, aber jeder Workflow hat seine eigene Prozessumgebung. Daher können andere Workflows im Zweifelsfall nicht auf Änderungen der Umgebungsbedingungen reagieren, etwa auf die Deklaration einer Variable in einem einzelnen Workflow.

Folgen Sie SearchDataCenter.de auch auf Twitter, Google+, Xing und Facebook!

Artikel wurde zuletzt im Juni 2017 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Windows-Server

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchNetworking.de

SearchEnterpriseSoftware.de

Close