NWC Services Blog
PowerShell-Scripts in DSM 7 (Teil I)
Eine der wenig bekannten (und noch schlechter dokumentierten) Neuerungen in DSM 7, ist die Unterstützung von PowerShell innerhalb von DSM 7 Scripts.
Da sich PowerShell und die PowerShell-Scriptsprache ja mehr und mehr als die Automatisierungs-Schnittstelle im Windows-Umfeld herauskristallisieren, ist diese Unterstützung ein wichtiger Baustein im Gesamtkonzept einer LifeCycle-Management Strategie.
Dieser Artikel ist der erste einer kleinen Serie von Posts, in der die neuen Möglichkeiten aufgezeigt werden sollen...
Seit etlichen Jahren ist der Befehl "CallScript" Bestandteil der NetInstall-Scriptsprache. Dieser ermöglicht die Ausführung von Windows Script Host (WSH) basierenden Scripts, indem die NetInstall Runtime selbst als Scripthost fungiert und der erforderliche Execution-Engine eine Laufzeitumgebung bereitstellt. Damit können also VBScripts (Endung ".vbs"), JScripts (".js") oder - falls installiert - auch Perl-Scripts (".pl") innerhalb von NetInstall aufgerufen werden.
Das Besondere an dieser Methode – gegenüber dem einfachen Aufruf von cscript.exe oder wscript.exe mit dem entsprechenden Script als Parameter – besteht darin, dass dadurch, dass NetInstall die Script-Engine betreibt, das Script auf Variablen aus NetInstall sowohl lesend als auch schreibend zugreifen kann. Dies wird beispielsweise für VBScripts über die Befehle "NIGetVar" und "NISetVar" realisiert, die in "normalen" Scripts (die also vom WSH ausgeführt werden) nicht verwendet werden können. Außerdem besteht die Möglichkeit per "NIReport" und "NIError" Logeinträge in das aktuelle Installer-Logfile einzufügen, um so die korrekte Ausführung des externen Scripts dokumentieren und kontrollieren zu können.
Mit DSM 7 wurde dieser Mechanismus nun erweitert, sodass nicht nur klassische WSH-Scriptsprachen, sondern eben nun auch PowerShell-Scripts ausgeführt werden können. Dabei kommt der schon bekannte CallScript-Befehl zum Einsatz.
Soll das auszuführende Script allerdings über den "Browse for File"-Button ausgewählt werden, so werden dort nur die üblichen Dateitypen für VBScripts, JScripts und Perl-Scripts angezeigt.
Möchte man auf diese Weise also ein PowerShell-Script verwenden, so muss entweder das Scriptfile inklusive (relativem) Pfad manuell im Textfeld "Scriptdatei" eingetragen werden, oder im Dateiauswahl-Dialog muss der Dateityp-Filter auf "Alle Dateien (*.*)" eingestellt werden, um den PowerShell-Scripttyp ".ps1" auswählen zu können.
Es ist zu beachten, dass die PowerShell Script Execution-Policy, die initial auf "Restricted" konfiguriert ist und damit keine Ausführung von PowerShell Scripts erlaubt, zumindest auf "RemoteSigned" geändert wird, da ansonsten die Ausführung des Scripts fehlschlägt.
In den folgenden Artikeln über dieses Thema werde ich mich mit den DSM 7-spezifischen Cmdlets, die auf diesem Weg zusätzlich zur Verfügung stehen, beschäftigen...
When you subscribe to the blog, we will send you an e-mail when there are new updates on the site so you wouldn't miss them.
Kommentare 1
Hallo,
danke für den interessanten Blog.
Kann man denn die PowerShell Script Execution-Policy auch per Gruppenrichtlinie auf "RemoteSigned" stellen,
damit das bei allen PCs im AD wirksam wird?
Gruss Andreas