Infrastruktur-Aufgaben automatisieren

Die Windows PowerShell ist die aktuelle Kommandozeile (Shell) der Windows Client- und Server-Betriebssysteme. Grundsätzlich ist sie mit der Eingabeaufforderung (DOS-Kommandozeile) vergleichbar, allerdings ist die Bedienung deutlich verbessert und modernisiert sowie die Möglichkeiten deutlich vergrössert worden.

Kapitelübersicht

Übersicht der PowerShell-Funktionalitäten
Beispiel-Anwendung
Qualitätsansprüche
Sicherheitsaspekte
Schlussfolgerung

1.Übersicht der PowerShell-Funktionalitäten

Die Windows PowerShell wird ab Windows 7 standardmässig vorinstalliert und ist somit auf allen aktuellen Geräten verfügbar. Dadurch ist es auch möglich Client-seitige Anpassungen mittels PowerShell auszuführen. Dies beispielsweise mittels Logon Scripts. Wir raten Ihnen jedoch von solchen Einsätzen ab.

Die PowerShell ist modular aufgebaut. Die zur Verfügung stehenden Befehle, genannt cmdlets (command-lets), sind in Erweiterungen (Snap-In’s) zusammengefasst. Standardmässig wird ein Snap-In mit der Standardfunktionalität geladen. Weitere Snap-In’s können installiert und bei Bedarf geladen werden. Microsoft stellt für die meisten Windows Server-Rollen ein eigenes Snap-In zur Verfügung, mit welchem auf die Rollenfunktionalitäten zugegriffen werden kann. Häufig verwendet wird zum Beispiel die Verwaltung für ActiveDirectory oder Exchange Server.

Die cmdlets folgen dem Benennungsschema „Verb-Substantiv“, also beispielsweise Get-Help, Set-Location. Den Befehlen können Parameter angegeben werden. Diese werden vorzugsweise benannt. Ausserdem ist es möglich Ergebnisse aus einem Befehl einem weiteren direkt zu übergeben. Dazu Beispiele:

# Alle Dateien eines Ordners anzeigen
Get-ChildItem -Path "C:\Windows"

# Alle Dateien eines Ordners mit Filter anzeigen
Get-ChildItem -Path "C:\Windows" -Filter "*.ini"

# Alle Dateien eines Ordners anzeigen mit Übergabe des Pfades
Get-Item "C:\Windows" | Get-ChildItem

Für die Automatisierungsaufgaben sind nun noch drei Möglichkeiten entscheidend:

Scripts

Die PowerShell können Sie nicht nur aus der Konsole bedienen, die Befehle können auch in einem Script zusammengefasst werden, ähnlich einer Batch-Datei der alten DOS-Kommandozeile. In den PowerShell-Scripts können verschiedene Strukturelemente – ähnlich einer Programmiersprache – verwendet werden. Dies sind:

Verwendung von Variablen
Kapselung von Funktionen, auch zur Wiederverwendung
Bedingungen (if-then-else, switch)
Schleifen (while, foreach, …)
Fehlerbehandlung (try-catch, …)

Dadurch können Sie auch komplexe Abläufe relativ einfach umsetzen.

Remote-Verwaltung

Es können remote Verbindungen zu anderen Systemen aufgebaut und darauf cmdlets ausgeführt werden. Dies ermöglicht eine systemübergreifende Verwaltung von einer Konsole aus, aber auch Scripts die Konfigurationsarbeiten auf mehreren Systemen gleichzeitig ausführen.

Einbindung .net

In PowerShell-Scripts können Sie sämtliche Funktionalitäten des .net-Frameworks verwenden. Dadurch stehen Ihnen praktisch alle Möglichkeiten offen, die auch einer normalen Programmierung zur Verfügung stehen. Auch die Anbindung von Fremdsystemen ist dadurch in der Regel kein Problem mehr, da solche Systeme meistens .net-Schnittstellen bereitstellen.

Ein Beispiel:

# Statisches Feld einer .net Klasse aufrufen
[System.DateTime]::Now

# Instanz einer .net Klasse erstellen und damit arbeiten
$d = New-Object System.DateTime;
$d.AddYears(2);
$d.ToString("yyyy-MM-dd");

2.Beispiel-Anwendung

Wir verwenden PowerShell-Scripts einerseits für wiederkehrende Arbeiten und andererseits für einmalige Konfigurationen. Beispiele dazu sind:

Generierung von Benutzersignaturen
Bereinigung von Transfer-Laufwerken
Aufbau von Ordner-und Berechtigungsstrukturen
Aufbau von ActiveDirectory-Strukturen

Anhand eines Scripts für die Generierung von Signaturen zeige ich Ihnen nachfolgend einige Details zur Umsetzung auf. Das Script liest alle Benutzer aus dem ActiveDirectory aus und erstellt für jeden Benutzer aufgrund der Daten aus dem ActiveDirectory Benutzerobjekt eine Signatur. Die Signatur selbst wird aus einer XSLT-Transformation erstellt. Die Beispiele sind teilweise stark vereinfacht.

Auslesen der Benutzer

Die ActiveDirectory-Benutzer werden mittels LDAP-Abfrage ausgelesen. Dazu wird das .net-Objekt DirectorySearcher verwendet:

$objSearcher = New-Object System.DirectoryServices.DirectorySearcher
$objSearcher.SearchRoot = New-Object System.DirectoryServices.DirectoryEntry("LDAP://<domainPath>")
$objSearcher.PageSize = 1000
$objSearcher.Filter = "(objectClass=user)"
$objSearcher.SearchScope = "Subtree"

foreach ($user in $objSearcher.FindAll())
{ … }

Innerhalb der Iteration werden die Benutzerdaten ausgelesen und in einer vorbereiteten XML-Struktur gespeichert. Dies ist für die spätere XSLT-Transformation notwendig.

$xmlData = New-Object xml

# ausgeblendet: XML Struktur laden
$xmlData.SignatureData.FirstName = "$($userObject.givenName)"
$xmlData.SignatureData.LastName = "$($userObject.sn)"

Die eigentliche Generierung der Signaturen findet in einer eigenen Funktion statt. Die Funktion benötigt folgende Parameter:

Data: XML-Struktur mit den Benutzerdaten
XsltFileName: Pfad zum XSLT-Template
TargetFile: Zielpfad für die generierte Datei

Die Funktion ist wie folgt mit benannten Parametern definiert:

function Transform-Template
{
	[CmdletBinding()]
	Param
	(
		[parameter(Mandatory=$true)]
		[Alias("Data")]
		[xml]
		$pData,

		[parameter(Mandatory=$true)]
		[Alias("XsltFileName")]
		[string]
		$pXsltFileName,

		[parameter(Mandatory=$true)]
		[Alias("TargetFile")]
		[string]
		$pTargetFile
	)
	…
}

Pro Parameter machen wir folgende Angaben:

Parameter: Definition eines Funktionsparameters mit Optionen
Alias: Name des Parameters für den Funktionsaufruf
Xml/string: Datentyp
$... : Variablenname

Die Transformation wird mit Hilfe der .net-Klassen System.Xml.Xsl.XslCompiledTransform durchgeführt und hier nicht näher erläutert.

3.Qualitätsansprüche

Die meisten dieser Scripts werden automatisch zu geplanten Zeiten ausgeführt. Dadurch kann nicht interaktiv auf Fehler reagiert werden. Dies zieht spezielle Anforderungen an die Stabilität und Überwachung der Scripts nach sich. Wir legen daher bei der Umsetzung grossen Wert auf folgende nicht funktionale Anforderungen, was insbesondere bei Script-Entwicklungen häufig nicht gegeben ist:

100%-ige Fehlerbehandlungen

Das Script darf nicht aufgrund eines unerwarteten Ereignisses abbrechen. Dies hätte zur Folge, dass Arbeiten nur teilweise bearbeitet wurden und sich das System allenfalls in einem fehlerhaften Zustand befindet. Daher muss bei allen Abläufen eine komplette Fehlerbehandlung implementiert werden.

Logging

Sämtliche Schritte, die ein Script ausführt, sollen aufgezeichnet werden. Dazu führen wir detaillierte Log-Dateien, welche in einem Fehlerfall Aufschluss über Ursachen geben können.

Überwachung

Die zwei oben genannten Massnahmen nützen nichts, wenn wir ein Fehlverhalten nicht bemerken würden. Daher nehmen wir solche Scripts speziell in unserer Systemüberwachung auf. Dazu gibt es verschiedene Ansatzpunkte:

Kontrolle, dass der ausgeführte Task keinen Fehler zurückgegeben hat
Automatische Auswertung der Log-Datei
Versenden von Mails im Fehlerfall
…

Anders ist dies bei Konfigurations-Scripts. Diese werden in der Regel einmalig und interaktiv ausgeführt. Da die Anpassungen aber häufig am aktiven System gemacht werden, implementieren wir dort jeweils eine Simulation. Diese erlaubt es uns, die erwarteten Konfigurationsanpassungen genau zu analysieren und zu überprüfen bevor diese auf den Systemen durchgeführt werden. Das Risiko für Fehlkonfigurationen vermindert sich dadurch deutlich.

4.Sicherheitsaspekte

Die PowerShell bietet sehr viele Möglichkeiten und ist dadurch für potenzielle Angreifer interessant. Aus sicherheitstechnischer Sicht gibt es für die automatisch ausgeführten Scripts grundlegende Aspekte zu beachten:

Die Scripts sollen an einem verborgenen Ort gespeichert sein. Es darf für die Benutzer keine Möglichkeiten geben diese anzusehen oder gar zu bearbeiten.
Die Scripts sollen mit eingeschränkten Rechten ausgeführt werden. Idealerweise sind die Systemrechte auf die Aufgabe zugeschnitten. Dies kann auch Fehlmanipulationen durch Programmierfehler verhindern.
Wir empfehlen auf normalen Clients die PowerShell komplett zu deaktivieren. Ausserdem sollen an Clients angemeldete Benutzer keinerlei Rechte auf Infrastrukturkomponenten haben (Bsp. Server-Administrationsrechte).

5.Schlussfolgerung

Die Automatisierung mittels PowerShell ist verglichen mit anderen Möglichkeiten wenig komplex und bietet einfache und schnelle Anpassungsmöglichkeiten. Unsere Kunden profitieren von einer mittlerweile relativ grossen Sammlung an Funktionalitäten, die wir bereits umgesetzt haben. Wir stellen insbesondere im Rahmen unserer Dienstleistungsverträge und Bemühungen zur Standardisierung solche Funktionalitäten sicher.