Professionelle PowerShell-Umgebungen

Bereit für Großes

von Thomas Wiefel

Mit zunehmender Bedeutung der Automatisierung in der Unternehmens-IT wachsen auch die Qualitätsansprüche an Skripte, die sich mehr und mehr in Richtung unternehmenskritischer Apps bewegen. Das betrifft die Stabilität, die Portierbarkeit und die Skalierbarkeit von PowerShell-Skripten. Wir zeigen, welche Aspekte eine leistungsfähige PowerShell-Umgebung ausmachen.

Aus IT-Administrator 11/2017

Die Datenmengen in Unternehmen wachsen täglich. Für Administratoren bedeutet dies, den zur Verfügung stehenden Speicherplatz permanent anzupassen und ... (mehr)

Die Zeiten der selbstgeschriebenen Helferlein eines Administrators für seine eigene Verwendung sind seit Exchange Server 2010 und anderen PowerShell-abhängigen Server vorbei. Für die Langzeitnutzung der PowerShell (WPS) sind Dokumentationen mittels "comment based help" verpflichtend.

Hinzu kommen Namenskonventionen bei Funktionen mit "verb-noun" und einem unternehmensspezifischen Prefix. Denkbar wäre die Festlegung auf einen "Namensraum" wie "get-DU_Freespace". Für Variablennamen ist die "Ungarische Notation" als Standard anzunehmen. Neben der Standardisierung von Dokumentationen, klaren Skriptstrukturen sowie Namenskonzepten ist auch die Fehlerbehandlung ein Ausdruck von "Enterprise-Scripting".

Die Stabilität einer Skriptanwendung beginnt beim Quellcode. Eine explizite Ausnahmebehandlung sollte in jedem WPS-Skript mit

> ErrorActionPreference = "stop"

eingeleitet werden. Erst dann fällt die Unterscheidung des Interpreters in "terminating errors" und eben "non terminating errors" nicht mehr ins Gewicht. Nun kann – und sollte – jede Aktion mit einem "try{}"-Block ummantelt und denkbare Ausnahmen mit "{catch}" behandelt werden. Insbesondere das Einbinden externer Funk- tionen sollte Sie nicht ohne eine Fehlerbehandlung versuchen (siehe Listing 1).

Das Code-Fragment in Listing 1 enthält zwei Aktionen, falls die Einbindung scheitert. Ein Errorlog sollte immer befüllt werden samt Spezifizierung des Fehlers und Datumsangabe, zudem bei einem Aussprung mit einem Exitcode. Dieser kann über die Umgebungsvariable "$LastExitCode" ausgewertet werden und sollte standardisiert sein.