Module für Active Directory, Hyper-V, WMI laden in PowerShell Core 6

    PowerShell Core SetupPowerShell Core 6 ist seit Anfang des Jahres ver­fügbar und soll die Basis für alle weiteren Entwick­lungen von PowerShell sein. Aktuell fehlen der Core-Version jedoch die meisten Module zur Verwaltung von Windows. Diese muss man von Windows PowerShell impor­tieren, was für einige wichtige Module nicht klappt.

    Microsoft hat in seiner Roadmap für PowerShell unmiss­verständlich erklärt, dass die Windows-Version keine Zukunft hat. Sie gehört PowerShell Core, das auch auf Linux und macOS portiert wurde. Diese Cross-Plattform-Version beruht auch unter Windows auf .NET Core und somit auf einem abgespeckten .NET Framework.

    Magere Core-Ausstattung

    Bis dato stehen unter PowerShell Core nur ein paar Kernmodule mit insgesamt ca. 360 Cmdlets zur Verfügung, wie man mit dem Aufruf von

    (Get-Module -ListAvailable).ExportedCommands | measure -sum Count

    herausfinden kann. Das klingt auf den ersten Blick nach viel, ist aber nur ein Bruchteil dessen, was Windows PowerShell bietet.

    Microsoft verwies aber schon vorab darauf, dass sich unter Windows die vorhandenen Module aufgrund der Binär­kompa­tibilität von PowerShell Core mit .NET-Assemblies weiternutzen lassen würden. Das gilt allerdings nur, wenn diese keine Features benötigen, die in .NET Core fehlen.

    Module von Windows PowerShell importieren

    Möchte man in PowerShell Core ein Cmdlet aus den Modulen ActiveDirectory oder Hyper-V aufrufen, dann schlägt der Versuch mit dieser Meldung fehl:

    The term 'Get-ADComputer' is not recognized as the name of a cmdlet, function, script file, or operable program

    Normalerweise müsste PowerShell Core über Autoloading das Modul importieren, sobald man ein darin enthaltenes Cmdlet aufruft. Das klappt in diesem Fall aber nicht, weil sich die Module von Windows PowerShell standardmäßig nicht im Modulpfad von Core befinden. Aus diesem Grund scheitert auch der explizite Import mit Hilfe von Import-Module.

    Modulpfad erweitern

    Die Lösung besteht also darin, den existierenden Modulpfad um die Verzeichnisse zu erweitern, in denen sich die Module von Windows PowerShell befinden. Diesen Pfad kann man aus der Registry auslesen und an die existierende Variable $env:PSModulePath anhängen:

    $env:PSModulePath += ";" + (Get-ItemProperty 'HKLM:\System\CurrentControlSet\Control\Session Manager\Environment' -Name PSModulePath).PSModulePath

    Diese Änderung des Modulpfads gilt nur für die aktuelle Sitzung, in einer neuen Instanz von PowerShell Core geht sie wieder verloren. Um den Pfad permanent zu erweitern, muss man obigen Befehl in eines der Profile aufnehmen.

    Modulpfad von PowerShell Core erweitern, so dass er die Verzeichnisse für die Module von Windows PowerShell enthält.

    Nach der Anpassung des Modulpfads klappt auch gleich das Autoloading, was sich bei der Autover­voll­ständigung von Cmdlet-Namen bemerkbar macht. Das bedeutet allerdings noch nicht, dass PowerShell Core alle Kommandos auch tatsächlich ausführen kann. Welche Module sich wirklich nutzen lassen, kann man durch einen expliziten Import überprüfen:

    Get-Module -ListAvailable | ? Path -Like "*WindowsPowerShell*" |
    % { Import-Module $_.Name -ErrorAction Continue}

    Dieser Befehl lädt alle Module, in deren Pfadnamen sich die Zeichenkette "WindowsPowerShell" befindet. Beim Durchlauf der Schleife wird man feststellen, dass einige Import­vorgänge mit einer Fehler­meldung abbrechen.

    Module für AD, DNSClient, Server Manager nicht kompatibel

    Wenn man nachträglich die Module auflisten will, die nicht geladen wurden, dann kann man dies mit dem folgenden Kommando tun:

    Compare-Object (Get-Module).Name -DifferenceObject (Get-Module -ListAvailable |
    ? Path -like "*WindowsPowerShell*").Name

    Der erste Teil des Vergleichs ermittelt die Namen aller geladenen Module und stellt sie jenen gegenüber, die insgesamt im Modulpfad verfügbar sind und von Windows PowerShell stammen.

    PowerShell Core kann einige Module der Windows-Version nicht laden.

    Auf einem Windows Server 2016 mit installierten RSAT ergibt sich dann diese Liste an Modulen:

    • AzureRM.DataLakeStore
    • ActiveDirectory
    • BitsTransfer
    • DnsClient
    • Hyper-V
    • ISE
    • PSWorkflow
    • PSWorkflowUtility
    • RemoteDesktop
    • ServerManager

    Mit den Modulen für Active Directory und DNSClient fehlen zwei wichtige Bausteine zur Verwaltung von Windows-Umgebungen. Hyper-V taucht hingegen nur deswegen auf, weil es in den Versionen 1.1 und 2.0 vorliegt und immer nur eine davon importiert werden kann. Die Cmdlets zur Verwaltung von Hyper-V stehen somit vollständig zur Verfügung.

    Die WMI-Cmdlets sind unter Windows PowerShell Bestandteil des Moduls Microsoft.PowerShell.Management. Dieses existiert auch in PowerShell Core, die Cmdlets für WMI fehlen dort jedoch. Die neueren CIM-Cmdlets sind aber an Bord, so dass man in bestehenden Scripts auf diese umstellen muss.

    Keine Kommentare