Vor knapp einer Woche, am 16.12.2015, wurde die neue Version 5.0 des Windows Management Frameworks offiziell freigegeben, das ja als zentrale Komponente die Windows PowerShell 5.0 enthält. Dadurch sind jetzt auch die aktuellen in Windows 10 vorhandenen Funktionen wie das PackageManagement, PowerShellGet, PowerShell Klassen und anderes mehr für ältere Betriebssystem-Versionen verfügbar und unterstützt. Die Ankündigung ist im Windows PowerShell Blog unter http://blogs.msdn.com/b/powershell/archive/2015/12/16/windows-management-framework-wmf-5-0-rtm-is-now-available.aspx nachzulesen, die Downloads sind unter https://www.microsoft.com/en-us/download/details.aspx?id=50395 erreichbar.

Allerdings führt ein Bug im Installer dazu, dass nach der Installation das Laden des Moduls unserer PowerShell Extensions for HEAT Client Management (PSX) fehlschlägt. Aber nicht nur die PSX sind betroffen, sondern alle Module, die nicht in den Standard-Modulverzeichnissen installiert sind.

Der Versuch das PSX Modul oder jedes andere PowerShell Modul, das nicht in den Standardpfaden gefunden wird, zu laden führt zu der folgenden Fehlermeldung:

Die Ursache für diese Verhalten liegt darin begründet, dass durch die Installation, die System-Umgebungsvariable "PSModulePath" auf den Defaultwert "%ProgramFiles%\WindowsPowerShell\Modules;%SystemRoot%\system32\WindowsPowerShell\v1.0\Modules" zurücksetzt wird. Beim Versuch ein Modul zu laden, durchsucht die PowerShell die in dieser Umgebungsvariable angebenen Verzeichnisse und falls das angeforderte Modul in keinem der Ordner gefunden wird, schlägt das Laden mit eben dieser Fehlermeldung fehl.

Da PowerShell-Module prinzipell in beliebigen Verzeichnissen installiert werden können, ist es gängige Praxis, dass Dritthersteller-Module bei Bedarf ihren Installationspfad in dieser Umgebungsvariable eintragen und dann auch ohne explizite Angabe des Modulverzeichnisses geladen werden können. Script verlassen sich in der Regel dann auch darauf, dass ein Modul automatisch gefunden und eingebunden wird. Es steht nun die nicht unerhebliche Gefahr im Raum, dass durch die – sicherlich sinnvolle – Installation der neuesten PowerShell-Version etliche Scripts, Abläufe und Workflows auf Fehler laufen und fehlschlagen.

Falls Sie vor der WMF 5.0 Installation bereits Kenntnis über dieses Problem haben, besteht die einfachste Methode darin, den Inhalt der Umgebungsvariablen PSModulePath vor dem Setup zu sichern und anschließend wiederherzustellen. Ist das Kind bereits in den Brunnen gefallen, so müssen dafür sorgen, dass die Pfade zu den nicht mehr auffindbaren Modulen wieder im Wert der Umgebungsvariablen erfasst sind.

Für die PSX besteht die einfachste Möglichkeit dazu darin, dass Sie das PSX-Setup einfach nochmals ausführen und eine Reparaturinstallation vornehmen.

Sind auch andere PowerShell-Module von dem Probelm betroffen, so können Sie die Modulpfade auch manuell der Umgebungsvariable hinzufügen. Gehen Sie dazu zu den erweiterten Systemeinstellungen, öffnen den Systemeigenschaften-Dialog und wechseln auf das Register "Erweitert".

Klicken Sie dort auf die "Umgebungsvariablen..."-Schaltfläche, was den Dialog zur Bearbeitung, zum Anlegen und zum Löschen von Umgebungsvariablen, sowohl im Benutzer- als auch im Systemkontext öffnet:

Markieren Sie nun im Bereich der Systemvariablen die Variable "PSModulePath" und Drücken Sie die "Bearbeiten..."-Schaltfläche. In dem sich öffnenden Dialogfeld hat bereits das Textfeld "Wert der Variablen" den Fokus. Per Druck auf die Taste "Ende" können Sie direkt an das Ende des aktuell eingetragenen Wertes springen. Ergänzen Sie dort, durch Semikolons getrennt, die Werte aller fehlenden Modul-Verzeichnisse. Im Fall des PSX-Moduls handelt es sich um das "Modules"-Unterverzeichnis des Installationsverzeichnissesn, standardmäßig also um den Pfad "C:\Program Files\NWC Services\PSX7\Modules".

Bestätigen Sie alle Dialoge mit OK und öffnen Sie eine neue PowerShell-Instanz. Ab sofort sollten Ihre PowerShell-Module wieder automatisch gefunden werden.