Vom „Einzeiler“ zum Powershell-Skript

Verwaltungsaufgaben im Umfeld des Active Directory (AD) automatisieren – dieser Herausforderung müssen sich viele Administratoren stellen. Dabei helfen die verschiedensten grafischen Verwaltungswerkzeuge nicht unbedingt gut weiter. Dagegen spielt der Einsatz der Powershell bei derartigen Aufgaben seine Vorteile aus. Im dritten Teil dieser Serie zum Arbeiten mit der Powershell im AD-Umfeld zeigt der Autor, wie aus den „bisherigen“ Einzeilern ein komplettes Powershell-Skript erzeugt werden kann.

Bereits die ersten beiden Artikel zum Thema „Arbeiten mit der Powershell im Umfeld des Active Directory“ (AD) („Mehr Flexibilität für Einzeiler“ und „ForEach und die Pipeline-Variable richtig einsetzen“) haben Ansätze gezeigt, wie Administratoren bei bestimmten Aufgabenstellungen viel Zeit sparen können, wenn sie das Automatisierungspotenzial der Powershell nutzen.

Der folgende Einzeiler erlaubt es, aus dem Vor- (givenname) und dem Familiennamen (SN, surname) eines Benutzers im AD einen Anzeigenamen (Displayname) zu erstellen, der aus diesen beiden teile und einem Leerzeichen dazwischen besteht.

get-aduser -filter * -properties * |
foreach { set-aduser $_
-displayname ($_.givenname + " " + $_.sn)}

Das ist zwar eine recht triviale Aktion, doch damit lässt sich eine konsistente Namensgebung (Displayname ist Vorname plus Familienname) im AD erreichen.

Auch wenn dieses Kommando als ein typischer Powershell-Einzeiler (hier auf der Website wird er aus Gründen der Lesbarkeit schon als „Dreizeiler“ angezeigt), so muss man zu den Powershell-Einzeilern doch eines sagen: Es handelt sich bei ihnen um sehr mächtige Kommandos, doch in den meisten Fällen verfolgen sie das Konzept „Write Only“ – sprich man schreibt den Befehl einmal. Wenn man ihn später wieder verwenden möchte, kennt man sich nicht mehr so recht aus und man weiß nicht mehr genau, was er eigentlich soll.
Daher soll nun gezeigt werden, wie sich ein derartiger Einzeiler so schreiben lässt, dass er besser zu lesen ist und dass er auch besser umgebaut werden kann, wenn eine andere aber ähnliche Funktionalität gewünscht wird. Und damit muss man den Einzeiler zu einem „echten“ Powershell-Skript umbauen.

Für mache verursacht der Begriff „Skript“ schon etwas Unbehagen, denn sie verbinden damit den Vorgang der Programmierung – und das ist immer schwer. Doch in diesem Fall wird man schnell sehen, dass es keine allzu große Schwierigkeit darstellt.

Ehe an das Erstellen des Skripts geht, sollten „Skripting-Neulinge“ sich ein eigenes Verzeichnis auf ihrem Computer anlegen, auf dem alle Skripts abgelegt werden sollten – etwa: C:\scripts. Zudem muss man auch noch die Powershell auf seinem System entsprechend (als Administrator) starten.

Vom Prinzip her sind Powershell-Skripts doch recht einfach: Man schreibt ein oder mehrere Powershell-Befehle in eine Textdatei und speichert diese Datei dann mit der Dateiendung .ps1. Danach muss man immer wenn man diesen Satz von Powershell-Befehlen laufen lassen möchte nur ein Powershell-Fenster öffnen und dort nach dem Prompt den Namen der Textdatei angeben, die man als .ps1-Datei gespeichert hat.

Die Powershell liest dann diese Befehle und führt sie nacheinander aus. Damit muss der Administrator die einzelnen Befehle nicht immer wieder neu eintippen – das spart Aufwand, vor allem bei sehr langen „Einzeilern“. Im Folgenden soll nun ein Beispiel – ausgehend vom oben gezeigten Powershell-Einzeiler – verdeutlichen, wie diese Aktionen auszuführen sind.

Zuerst gilt es einen Editor wie Notepad zu öffnen und dann den Einzeiler –ohne Änderungen – in eine Datei namens fixDBs.ps1 im zuvor angelegten Verzeichnis für die Skripts zu speichern. Dieser Befehl würde dann das AD entsprechend ändern und den Displaynamen für jedes Benutzerkonto ändern. Daher sollte man sich zuerst die goldene Regel für das Testen von Powershell-Skripts zu Eigen machen: Entweder der Administrator führt das Skript in einer – zumeist kleineren – Testumgebung aus, oder aber er baut den Befehl so um, dass keine „Änderungsaktion“ ausgeführt wird. Dazu bietet die Powershell ein Konstrukt mit dem Parameter „WhatIf“ an. In dem konkreten Beispiel sieht das dann wie folgt aus:

get-aduser -filter * -properties * |
foreach { set-aduser $_
–displayname ($_.givenname + " " + $_.sn) -whatif}

Wer einen Powershell-Befehl erstmals auf seinem Rechner ausführen möchte, der muss zunächst die Ausführungsrichtlinie umstellen. Denn Windows ist sicherheitshalber so voreingestellt, dass zunächst Skripts blockiert werden. Dazu eignet sich zum Beispiel der folgende Befehl Powershell-Fenster (direkt nach dem Prompt):

set-executionpolicy RemoteSigned

Ist dieser Befehl einmal auf einem System ausgeführt, braucht man ihn nicht zu wiederholen. Danach kann man sein erstes Skript laufen lassen – etwa durch die Eingabe von:

.\fixdns

Der Punkt und der Backslash sind notwendig, damit die Powershell zu 100 Prozent sicher ist, dass das gewünschte Skript ausgeführt wird – nicht dass noch eine Datei mit demselben Namen – fixdns.ps1 – an einer anderen Stelle im Dateisystem (auf einem passenden Pfad) liegt.

Nachdem der Administrator auf „Eingabe“ gedrückt hat, wird er in einem Fall eine große Menge von rotem Text geliefert bekommen. Er weist darauf hin, dass das „ausführende System“ keine Verbindung zum Domänencontroller – dem DC –herstellen konnte, um die Befehle get-user oder set-user auszuführen, oder dass man nicht mit den passenden Anmeldeinformationen hantiert oder aber dass in der betreffenden Domäne eine Gruppenrichtlinie aktiv ist, die den Befehl „set-executionpolicy“ blockiert hat.
Im anderen Fall wird man nichts zurückgeliefert bekommen – das macht dann Sinn, wenn das Skript ohne den whatif-Parameter ausgeführt und alles korrekt abgearbeitet worden ist. Im dritten Fall – wenn der Parameter whatif eingesetzt wurde – bekommt man einige Zeilen zurück, die wie folgt aussehen könnten:

What if: Performing operation "Set" on Target "CN=mark,CN=Users,DC=bigfirm,DC=com".

Bereits zu diesem Zeitpunkt ist ein großer Vorteil zu erkennen: Der Administrator muss viel weniger eintippen: Es ist viel einfacher, nur .\fixDNs einzutippen als den gesamten Powershell-Befehl – von möglichen Tippfehlern ganz zu schweigen.
Doch es gibt noch viele weitere Vorteile zu vermelden, wenn man das Skript deutlich besser lesbar angibt – so wie das im nächsten Beitrag aus dieser Reihe erfolgen wird.

Mark Minasi/rhh