Laden als Modul
Laden als Modul
Seit der Version 2.0 der Windows PowerShell besteht die Möglichkeit, Erweiterungen als sogenannte Module zu laden. Während in Version 1.0 hierfür die Installation eines Snap-Ins erforderlich war, genügt es für ein Modul, die benötigten Dateien an einem definierten Ort bereitzustellen. Über das Cmdlet Import-Module wird das Modul dann geladen und steht in dieser PowerShell-Sitzung zur Verfügung.
Seit der Version 2.0 der PowerShell Extensions ist es nun ebenfalls möglich, diese Funktionalität zu nutzen und ohne die eigentliche Installation auszukommen. Sie benötigen hierfür lediglich die entpackten Quelldateien. Das die PSX jedoch als MSI-Paket geliefert werden, müssen Sie dieses zunächst entpacken. Dies geschieht im Rahmen einer administrativen Installation und ist im Kapitel Administratives Setup ausführlich beschrieben.
Nachdem Sie die Quelldateien entpackt haben, können Sie die benötigten Dateien in ein beliebiges Verzeichnis kopieren - der Verzeichnisname muss jedoch zwingend 'PSX7' lauten. Es wird empfohlen, dieses Verzeichnis in einem der Standard-Modulpfade der PowerShell zu erzeugen. Sie können die im Modul-Pfad enthaltenen Verzeichnisse durch Abfragen der Umgebungsvariable PSModulePath ermitteln, beispielsweise durch Ausführen des folgenden Kommandos in einem PowerShell-Fenster:
$ENV:PSModulePath |
Folgende Dateien sind für eine funktionale Umgebung zwingend Voraussetzung:
- das Assembly NwcServices.BlsAdministration.dll
- die Typ-Definitionsdatei NwcServices.BlsAdministration.TypeData.ps1xml
- die Format-Definitionsdatei NwcServices.BlsAdministration.FormatData.ps1xml
- die Modul-Definitionsdatei PSX7.psd1
- die Lizenzdatei NwcServices.BlsAdministration.dll.lic
Hinweis: es besteht auch die Möglichkeit, die Lizenzdatei an zentraler Stelle im Netzwerk abzulegen und darauf zu verweisen. Details entnehmen Sie bitte dem Abschnitt Zentrale Ablage der Lizenzdatei. |
Die Unterverzeichnisse de-DE und en-US enthalten Hilfe-Texte, die beim Anzeigen der Online-Hilfe (dieses chm-File), beim Aufruf des Get-Help-Cmdlets oder beim Anzeigen der "about_..."-Themen angezeigt werden. Sie sind für die Ausführung von PSX-basierten Scripts nicht erforderlich und können daher optional kopiert werden.
Um nun die DSM 2017 als Modul zu laden, starten Sie eine neue PowerShell-Session (nur PowerShell 2.0 und höher). Unter der Annahme, dass Sie die oben genannten Dateien in das Verzeichnis 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\PSX7' kopiert haben, geben Sie folgenden Befehl ein:
Import-Module PSX7 |
Das Modul wird nun geladen. Den in gelber Schrift ausgegebenen Warnhinweis über nicht genehmigte Verben, können Sie an dieser Stelle ignorieren. Er hat auf die Funktionalität keinerlei negative Auswirkung. Um das Modul ohne den vorgenannten Warnhinweis zu laden, verwenden Sie den Parameter DisableNameChecking des Import-Module Cmdlets.
Import-Module PSX7 -DisableNameChecking |
Nun steht Ihnen der gesamte Funktionsumfang der PowerShell Extensions for Ivanti DSM zur Verfügung.
Falls Sie das PSX7-Verzeichnis in einem anderen als den Standard-Pfaden erzeugt haben, müssen Sie den vollständigen Pfad zum Modul-Verzeichnis angeben. Haben Sie beispielsweise das Verzeichnis unterhalb von 'C:\Windows\Temp' angelegt, müssten Sie folgende Syntax verwenden:
Import-Module C:\Windows\Temp\PSX7 -DisableNameChecking |
Es ist sogar möglich, das Modul zu laden, falls im Netzwerk über einen UNC-Pfad darauf zugegriffen werden kann. Dies beseitigt die Notwendigkeit, die Modul-Dateien auf alle Systeme, auf denen PSX-basierte Scripts ausgeführt werden sollen, zu verteilen und erlaubt eine einfache, zentrale Pflege und Updates. Der Nachteil dieses Ansatzes ist, dass das .NET-Framework sehr strenge Sicherheitsrichtlinien verwendet, die bei den standardmäßigen Einstellungen dafür sorgen, dass Assemblies, die über das Netzwerk geladen werden sollen, nicht vertraut wird.
Um das Modul erfolgreich über einen UNC-Pfad zu laden, muss der Pfad den vertrauten Orten über das Tool caspol.exe hinzugefügt werden. Angenommen, Sie haben das Modul im Extern$-Verzeichnis der DSM$-Freigabe abgelegt und der Name Ihres Depot-Servers ist CHISV01, dann ermöglicht der folgenden Code das Laden des Moduls von dort:
Set-Alias CasPol "$([Runtime.InteropServices.RuntimeEnvironment]::GetRuntimeDirectory())CasPol.exe" CasPol -pp off -machine -addgroup 1.2 -url file://\CHISV01\DSM$\Extern$\* FullTrust |
Beachten Sie, dass diese Kommandos auf allen Clients ausgeführt werden müssen, die auf das Modul über das Netzwerk zugreifen möchten. Dies relativiert bis zu einem gewissen Grad die Vorteile der zentralen Modul-Ablage, kann aber nichtsdestotrotz in bestimmten Situationen sehr vorteilhaft sein.