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

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.

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.

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.