Tags: PowerShell, Active Directory, Hyper-V
PowerShell Core 6 ist seit Anfang des Jahres verfügbar und soll die Basis für alle weiteren Entwicklungen von PowerShell sein. Aktuell fehlen der Core-Version jedoch die meisten Module zur Verwaltung von Windows. Diese muss man von Windows PowerShell importieren, was für einige wichtige Module nicht klappt.
Microsoft hat in seiner Roadmap für PowerShell unmissverstä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ärkompatibilitä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 Autovervollstä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 Importvorgänge mit einer Fehlermeldung 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.
Täglich Know-how für IT-Pros mit unserem Newsletter
Verwandte Beiträge
- Security- und Health-Checks für Active Directory mit PowerShell-Scripts
- Split-brain DNS in Active Directory einrichten
- AD-Konten mit DES- und RC4-Algorithmus für Kerberos-Verschlüsselung finden
- UserAccountControl: Sicherheitseinstellungen für AD-Konten prüfen und ändern
- Gruppen in Azure Active Directory mit PowerShell verwalten
Weitere Links