Get-Module

Listet die Module auf, die in der aktuellen Sitzung importiert oder aus psModulePath importiert werden können.

Syntax

Get-Module
   [[-Name] <String[]>]
   [-FullyQualifiedName <ModuleSpecification[]>]
   [-All]
   [<CommonParameters>]
Get-Module
   [[-Name] <String[]>]
   [-FullyQualifiedName <ModuleSpecification[]>]
   [-All]
   [-ListAvailable]
   [-PSEdition <String>]
   [-SkipEditionCheck]
   [-Refresh]
   [<CommonParameters>]
Get-Module
   [[-Name] <String[]>]
   [-FullyQualifiedName <ModuleSpecification[]>]
   [-ListAvailable]
   [-PSEdition <String>]
   [-SkipEditionCheck]
   [-Refresh]
   -PSSession <PSSession>
   [<CommonParameters>]
Get-Module
   [[-Name] <String[]>]
   [-FullyQualifiedName <ModuleSpecification[]>]
   [-ListAvailable]
   [-SkipEditionCheck]
   [-Refresh]
   -CimSession <CimSession>
   [-CimResourceUri <Uri>]
   [-CimNamespace <String>]
   [<CommonParameters>]

Beschreibung

Das Get-Module Cmdlet listet die PowerShell-Module auf, die in eine PowerShell-Sitzung importiert wurden oder importiert werden können. Ruft ohne Parameter Module ab, Get-Module die in die aktuelle Sitzung importiert wurden. Der Parameter ListAvailable wird verwendet, um die Module aufzulisten, die für den Import aus den Pfaden verfügbar sind, die in der PSModulePath-Umgebungsvariable ($env:PSModulePath) angegeben sind.

Das zurückgibte Get-Module Modulobjekt enthält wertvolle Informationen zum Modul. Sie können die Modulobjekte auch an andere Cmdlets weiterleiten, z. B. an die Import-Module Cmdlets und Remove-Module .

Get-Module listet Module auf, importiert sie jedoch nicht. Ab Windows PowerShell 3.0 werden Module automatisch importiert, wenn Sie einen Befehl im Modul verwenden, aber ein Get-Module Befehl löst keinen automatischen Import aus. Sie können die Module auch mithilfe des Cmdlets Import-Module in Ihre Sitzung importieren.

Ab Windows PowerShell 3.0 können Sie Module aus Remotesitzungen in die lokale Sitzung importieren. Diese Strategie verwendet das Implizite Remoting-Feature von PowerShell und entspricht der Verwendung des Import-PSSession Cmdlets. Wenn Sie Befehle in Modulen verwenden, die aus einer anderen Sitzung importiert wurden, werden die Befehle implizit in der Remotesitzung ausgeführt. Mit diesem Feature können Sie den Remotecomputer über die lokale Sitzung verwalten.

Außerdem können Sie ab Windows PowerShell 3.0 module (Common Information Model, CIM) abrufen Get-ModuleImport-Module und importieren. CIM-Module definieren Cmdlets in CDXML-Dateien (Cmdlet Definition XML). Mit diesem Feature können Sie Cmdlets verwenden, die in nicht verwalteten Codeassemblys implementiert sind, z. B. in C++.

Implizites Remoting kann verwendet werden, um Remotecomputer zu verwalten, auf denen PowerShell-Remoting aktiviert ist. Erstellen Sie eine PSSession auf dem Remotecomputer, und verwenden Sie dann den PSSession-Parameter von, Get-Module um die PowerShell-Module in der Remotesitzung abzurufen. Wenn Sie ein Modul aus der Remotesitzung importieren, werden die importierten Befehle in der Sitzung auf dem Remotecomputer ausgeführt.

Sie können eine ähnliche Strategie verwenden, um Computer zu verwalten, auf denen PowerShell-Remoting nicht aktiviert ist. Dazu gehören Computer, auf denen das Windows-Betriebssystem nicht ausgeführt wird, und Computer, auf denen PowerShell, aber kein PowerShell-Remoting aktiviert ist.

Erstellen Sie zunächst eine CIM-Sitzung auf dem Remotecomputer. Eine CIM-Sitzung ist eine Verbindung mit der Windows-Verwaltungsinstrumentation (WMI) auf dem Remotecomputer. Verwenden Sie dann den CIMSession-Parameter von, Get-Module um CIM-Module aus der CIM-Sitzung abzurufen. Wenn Sie ein CIM-Modul mithilfe des Import-Module Cmdlets importieren und dann die importierten Befehle ausführen, werden die Befehle implizit auf dem Remotecomputer ausgeführt. Mit dieser WMI- und CIM-Strategie können Sie den Remotecomputer verwalten.

Beispiele

Beispiel 1: In die aktuelle Sitzung importierte Module abrufen

Get-Module

Dieser Befehl ruft Module ab, die in die aktuelle Sitzung importiert wurden.

Beispiel 2: Abrufen installierter Module und verfügbarer Module

Get-Module -ListAvailable

Dieser Befehl ruft die Module ab, die auf dem Computer installiert sind und in die aktuelle Sitzung importiert werden können.

Get-Module sucht nach verfügbaren Modulen im Pfad, der von der Umgebungsvariablen $env:PSModulePath angegeben wird. Weitere Informationen zu PSModulePath finden Sie unter about_Modules und about_Environment_Variables.

Beispiel 3: Abrufen aller exportierten Dateien

Get-Module -ListAvailable -All

Dieser Befehl ruft alle exportierten Dateien für alle verfügbaren Module ab.

Beispiel 4: Abrufen eines Moduls nach dem vollqualifizierten Namen

$FullyQualifiedName = @{ModuleName="Microsoft.PowerShell.Management";ModuleVersion="3.1.0.0"}
Get-Module -FullyQualifiedName $FullyQualifiedName | Format-Table -Property Name,Version

Name                             Version
----                             -------
Microsoft.PowerShell.Management  3.1.0.0

In diesem Beispiel wird die Microsoft abgerufen. PowerShell.Management-Modul durch Angeben des vollqualifizierten Namens des Moduls mithilfe des FullyQualifiedName-Parameters. Der Befehl leitet die Ergebnisse dann an das Format-Table Cmdlet weiter, um die Ergebnisse als Tabelle mit Name und Version als Spaltenüberschriften zu formatieren.

In einem vollqualifizierten Namen für ein Modul fungiert der Wert ModuleVersion als Mindestversion. In diesem Beispiel entspricht es also jeder Microsoft. PowerShell.Management-Modul mit einer oder höherer Version3.1.0.0.

Beispiel 5: Abrufen von Eigenschaften eines Moduls

Get-Module | Get-Member -MemberType Property | Format-Table Name

Name
----
AccessMode
Author
ClrVersion
CompanyName
Copyright
Definition
Description
DotNetFrameworkVersion
ExportedAliases
ExportedCmdlets
ExportedCommands
ExportedFormatFiles
ExportedFunctions
ExportedTypeFiles
ExportedVariables
ExportedWorkflows
FileList
Guid
HelpInfoUri
LogPipelineExecutionDetails
ModuleBase
ModuleList
ModuleType
Name
NestedModules
OnRemove
Path
PowerShellHostName
PowerShellHostVersion
PowerShellVersion
PrivateData
ProcessorArchitecture
RequiredAssemblies
RequiredModules
RootModule
Scripts
SessionState
Version

Mit diesem Befehl werden die Eigenschaften des zurückgegebenen PSModuleInfo-ObjektsGet-Module abgerufen. Für jede Moduldatei ist ein Objekt vorhanden.

Mit den Eigenschaften können Sie die Modulobjekte formatieren und filtern. Weitere Informationen zu den Eigenschaften finden Sie unter PSModuleInfo-Eigenschaften.

Die Ausgabe enthält die neuen Eigenschaften wie Author und CompanyName, die in Windows PowerShell 3.0 eingeführt wurden.

Beispiel 6: Gruppierung aller Module nach Name

Get-Module -ListAvailable -All | Format-Table -Property Name, Moduletype, Path -Groupby Name

Name: AppLocker

Name      ModuleType Path
----      ---------- ----
AppLocker   Manifest C:\Windows\system32\WindowsPowerShell\v1.0\Modules\AppLocker\AppLocker.psd1


   Name: Appx

Name ModuleType Path
---- ---------- ----
Appx   Manifest C:\Windows\system32\WindowsPowerShell\v1.0\Modules\Appx\en-US\Appx.psd1
Appx   Manifest C:\Windows\system32\WindowsPowerShell\v1.0\Modules\Appx\Appx.psd1
Appx     Script C:\Windows\system32\WindowsPowerShell\v1.0\Modules\Appx\Appx.psm1


   Name: BestPractices

Name          ModuleType Path
----          ---------- ----
BestPractices   Manifest C:\Windows\system32\WindowsPowerShell\v1.0\Modules\BestPractices\BestPractices.psd1


   Name: BitsTransfer

Name         ModuleType Path
----         ---------- ----
BitsTransfer   Manifest C:\Windows\system32\WindowsPowerShell\v1.0\Modules\BitsTransfer\BitsTransfer.psd1

Dieser Befehl ruft alle importierten und verfügbaren Moduldateien ab und gruppiert sie dann nach Modulname. So können Sie die Moduldateien sehen, die von denen einzelnen Skripts exportiert werden.

Beispiel 7: Anzeigen des Inhalts eines Modulmanifests

Diese Befehle zeigen den Inhalt des Modulmanifests für das Modul Windows PowerShell BitsTransfer an.

Module müssen keine Manifestdateien enthalten. Wenn sie über eine Manifestdatei verfügen, muss die Manifestdatei nur eine Versionsnummer enthalten. Manifestdateien enthalten jedoch oft nützliche Informationen über ein Modul, seine Anforderungen und seinen Inhalt.

# First command
$m = Get-Module -list -Name BitsTransfer

# Second command
Get-Content $m.Path

@ {
    GUID               = "{8FA5064B-8479-4c5c-86EA-0D311FE48875}"
    Author             = "Microsoft Corporation"
    CompanyName        = "Microsoft Corporation"
    Copyright          = "Microsoft Corporation. All rights reserved."
    ModuleVersion      = "1.0.0.0"
    Description        = "Windows PowerShell File Transfer Module"
    PowerShellVersion  = "2.0"
    CLRVersion         = "2.0"
    NestedModules      = "Microsoft.BackgroundIntelligentTransfer.Management"
    FormatsToProcess   = "FileTransfer.Format.ps1xml"
    RequiredAssemblies = Join-Path $psScriptRoot "Microsoft.BackgroundIntelligentTransfer.Management.Interop.dll"
}

Mit dem ersten Befehl wird das PSModuleInfo-Objekt abgerufen, das das BitsTransfer-Modul darstellt. Das Objekt wird in der $m Variablen gespeichert.

Der zweite Befehl verwendet das Get-Content Cmdlet, um den Inhalt der Manifestdatei im angegebenen Pfad abzurufen. Mithilfe der Punktnotation wird der Pfad zur Manifestdatei abgerufen, der in der Path-Eigenschaft des Objekts gespeichert ist. Die Ausgabe zeigt den Inhalt des Modulmanifests.

Beispiel 8: Auflisten von Dateien im Modulverzeichnis

dir (Get-Module -ListAvailable FileTransfer).ModuleBase

Directory: C:\Windows\system32\WindowsPowerShell\v1.0\Modules\FileTransfer
Mode                LastWriteTime     Length Name
----                -------------     ------ ----
d----        12/16/2008  12:36 PM            en-US
-a---        11/19/2008  11:30 PM      16184 FileTransfer.Format.ps1xml
-a---        11/20/2008  11:30 PM       1044 FileTransfer.psd1
-a---        12/16/2008  12:20 AM     108544 Microsoft.BackgroundIntelligentTransfer.Management.Interop.dll

Mit diesem Befehl werden die Dateien im Verzeichnis des Moduls aufgelistet. Dies ist eine weitere Methode, um den Inhalt eines Modul zu ermitteln, bevor Sie es importieren. Einige Module verfügen möglicherweise über Hilfe- oder Infodateien, die das Modul beschreiben.

Beispiel 9: Auf einem Computer installierte Module abrufen

$s = New-PSSession -ComputerName Server01

Get-Module -PSSession $s -ListAvailable

Diese Befehle rufen die Module ab, die auf dem Computer Server01 installiert sind.

Der erste Befehl verwendet das New-PSSession Cmdlet, um eine PSSession auf dem Server01-Computer zu erstellen. Der Befehl speichert die PSSession in der $s Variablen.

Der zweite Befehl verwendet die Parameter PSSession und ListAvailable von Get-Module , um die Module in der PSSession in der $s Variablen abzurufen.

Wenn Sie Module aus anderen Sitzungen an das Import-Module Cmdlet weiterleiten, Import-Module importiert das Modul mithilfe des impliziten Remotingfeatures in die aktuelle Sitzung. Dies entspricht der Verwendung des Cmdlets Import-PSSession . Sie können die Cmdlets aus dem Modul in der aktuellen Sitzung verwenden, die Befehle, die diese Cmdlets verwenden, werden jedoch tatsächlich in der Remotesitzung ausgeführt. Weitere Informationen finden Sie unter Import-Module und Import-PSSession.

Beispiel 10: Verwalten eines Computers, auf dem das Windows-Betriebssystem nicht ausgeführt wird

Mit den Befehlen in diesem Beispiel können Sie die Speichersysteme eines Remotecomputers verwalten, auf dem das Windows-Betriebssystem nicht ausgeführt wird. Da der Administrator des Computers in diesem Beispiel den WMI-Anbieter für die Modulerkennung installiert hat, können die CIM-Befehle die Standardwerte verwenden, für den Anbieter konzipiert wurden.

$cs = New-CimSession -ComputerName RSDGF03
Get-Module -CimSession $cs -Name Storage | Import-Module
Get-Command Get-Disk

CommandType     Name                  ModuleName
-----------     ----                  ----------
Function        Get-Disk              Storage

Get-Disk

Number Friendly Name              OperationalStatus          Total Size Partition Style
------ -------------              -----------------          ---------- ---------------
0      Virtual HD ATA Device      Online                          40 GB MBR

Der erste Befehl verwendet das New-CimSession Cmdlet, um eine Sitzung auf dem RSDGF03-Remotecomputer zu erstellen. Die Sitzung stellt auf dem Remotecomputer eine Verbindung mit WMI her. Der Befehl speichert die CIM-Sitzung in der $cs Variablen.

Der zweite Befehl verwendet die CIM-Sitzung in der $cs Variablen, um einen Get-Module Befehl auf dem RSDGF03-Computer auszuführen. Mit dem Name-Parameter wird das Storage-Modul angegeben. Der Befehl verwendet einen Pipelineoperator (|), um das Speichermodul an das Import-Module Cmdlet zu senden, das es in die lokale Sitzung importiert.

Mit dem dritten Befehl wird das Get-Command Cmdlet für den Get-Disk Befehl im Speichermodul ausgeführt. Wenn Sie ein CIM-Modul in die lokale Sitzung importieren, konvertiert PowerShell die CDXML-Dateien, die das CIM-Modul darstellen, in PowerShell-Skripts, die als Funktionen in der lokalen Sitzung angezeigt werden.

Der vierte Befehl führt den Get-Disk Befehl aus. Obwohl der Befehl in die lokale Sitzung eingegeben wird, wird er implizit auf dem Remotecomputer ausgeführt, von dem er importiert wurde. Der Befehl ruft Objekte vom Remotecomputer ab und gibt sie an die lokale Sitzung zurück.

Parameter

-All

Gibt an, dass dieses Cmdlet alle Module in jedem Modulordner abruft, einschließlich geschachtelter Module, Manifestdateien (.psd1), Skriptmoduldateien (.psm1) und Binärmoduldateien (.dll). Ohne diesen Parameter Get-Module ruft nur das Standardmodul in jedem Modulordner ab.

Type:SwitchParameter
Position:Named
Default value:False
Accept pipeline input:False
Accept wildcard characters:False

-CimNamespace

Gibt den Namespace eines alternativen CIM-Anbieters an, der CIM-Module verfügbar macht. Der Standardwert ist der Namespace des WMI-Anbieters für die Modulerkennung.

Verwenden Sie diesen Parameter, um CIM-Module von Computern und Geräten abzurufen, auf denen nicht das Windows-Betriebssystem ausgeführt wird.

Dieser Parameter wurde in Windows PowerShell 3.0 eingeführt.

Type:String
Position:Named
Default value:None
Accept pipeline input:False
Accept wildcard characters:False

-CimResourceUri

Gibt einen alternativen Speicherort für die CIM-Module an. Der Standardwert ist der Ressourcen-URI des WMI-Anbieters für die Modulermittlung auf dem Remotecomputer.

Verwenden Sie diesen Parameter, um CIM-Module von Computern und Geräten abzurufen, auf denen nicht das Windows-Betriebssystem ausgeführt wird.

Dieser Parameter wurde in Windows PowerShell 3.0 eingeführt.

Type:Uri
Position:Named
Default value:None
Accept pipeline input:False
Accept wildcard characters:False

-CimSession

Gibt eine CIM-Sitzung auf dem Remotecomputer an. Geben Sie eine Variable ein, die die CIM-Sitzung enthält, oder einen Befehl, der die CIM-Sitzung abruft, z. B. einen Get-CimSession-Befehl .

Get-Module verwendet die CIM-Sitzungsverbindung, um Module vom Remotecomputer abzurufen. Wenn Sie das Modul mithilfe des Import-Module Cmdlets importieren und die Befehle aus dem importierten Modul in der aktuellen Sitzung verwenden, werden die Befehle tatsächlich auf dem Remotecomputer ausgeführt.

Sie können diesen Parameter verwenden, um Module von Computern und Geräten abzurufen, auf denen nicht das Windows-Betriebssystem ausgeführt wird, sowie von Computern, auf denen PowerShell, aber kein PowerShell-Remoting aktiviert ist.

Der CimSession-Parameter ruft alle Module in der CIMSession ab. Sie können jedoch nur CIM- und CDXML (Cmdlet Definition XML)-basierte Module importieren.

Type:CimSession
Position:Named
Default value:None
Accept pipeline input:False
Accept wildcard characters:False

-FullyQualifiedName

Der Wert kann ein Modulname, eine vollständige Modulspezifikation oder ein Pfad zu einer Moduldatei sein.

Wenn der Wert ein Pfad ist, kann der Pfad voll qualifiziert oder relativ sein. Ein relativer Pfad wird relativ zum Skript aufgelöst, das die using-Anweisung enthält.

Wenn der Wert ein Name oder eine Modulspezifikation ist, durchsucht PowerShell den PSModulePath nach dem angegebenen Modul.

Eine Modulspezifikation ist eine Hashtabelle mit den folgenden Schlüsseln.

  • ModuleName - Erforderlich Gibt den Modulnamen an.
  • GUID - Optional Gibt die GUID des Moduls an.
  • Es ist auch erforderlich , mindestens einen der drei folgenden Schlüssel anzugeben.
    • ModuleVersion – Gibt eine zulässige Mindestversion des Moduls an.
    • MaximumVersion – Gibt die maximal zulässige Version des Moduls an.
    • RequiredVersion : Gibt eine genaue, erforderliche Version des Moduls an. Dies kann nicht mit den anderen Versionsschlüsseln verwendet werden.

Sie können den Parameter FullyQualifiedName nicht im gleichen Befehl wie einen Name-Parameter angeben.

Type:ModuleSpecification[]
Position:Named
Default value:None
Accept pipeline input:True
Accept wildcard characters:False

-ListAvailable

Gibt an, dass dieses Cmdlet alle installierten Module abruft. Get-Module ruft Module in Pfaden ab, die in der UMGEBUNGsvariablen PSModulePath aufgeführt sind. Ruft ohne diesen Parameter nur die Module ab, Get-Module die sowohl in der PSModulePath-Umgebungsvariablen aufgeführt sind als auch in der aktuellen Sitzung geladen werden. ListAvailable gibt keine Informationen zu Modulen zurück, die in der PSModulePath-Umgebungsvariablen nicht gefunden wurden, selbst wenn diese Module in der aktuellen Sitzung geladen sind.

Type:SwitchParameter
Position:Named
Default value:None
Accept pipeline input:False
Accept wildcard characters:False

-Name

Gibt Namen oder Namensmuster von Modulen an, die von diesem Cmdlet abgerufen werden. Platzhalterzeichen sind zulässig. Sie können die Namen auch an übergeben Get-Module. Sie können den Parameter FullyQualifiedName nicht im gleichen Befehl wie einen Name-Parameter angeben.

Name kann keine Modul-GUID als Wert akzeptieren. Verwenden Sie stattdessen FullyQualifiedName , um Module durch Angabe einer GUID zurückzugeben.

Type:String[]
Position:0
Default value:None
Accept pipeline input:True
Accept wildcard characters:True

-PSEdition

Ruft die Module ab, die die angegebene Edition von PowerShell unterstützen.

Zulässige Werte für diesen Parameter:

  • Desktop
  • Core

Das Get-Module Cmdlet überprüft die CompatiblePSEditions-Eigenschaft des PSModuleInfo-Objekts auf den angegebenen Wert und gibt nur die Module zurück, für die er festgelegt ist.

Hinweis

  • Desktop-Edition: Diese Edition basiert auf .NET Framework und bietet Kompatibilität mit Skripts und Modulen für Versionen von PowerShell, die unter Vollversionen von Windows wie Server Core und Windows Desktop ausgeführt werden.
  • Core-Edition: Diese Edition basiert auf .NET Core und bietet Kompatibilität mit Skripts und Modulen für Versionen von PowerShell, die unter funktionsreduzierten Versionen von Windows wie Nano Server und Windows IoT ausgeführt werden.
Type:String
Position:Named
Default value:None
Accept pipeline input:False
Accept wildcard characters:False

-PSSession

Ruft die Module in der angegebenen vom Benutzer verwalteten PowerShell-Sitzung (PSSession) ab. Geben Sie eine Variable ein, die die Sitzung enthält, einen Befehl, der die Sitzung abruft, z. B. einen Get-PSSession Befehl, oder einen Befehl, der die Sitzung erstellt, z. B. einen New-PSSession Befehl.

Wenn die Sitzung mit einem Remotecomputer verbunden ist, müssen Sie den ListAvailable-Parameter angeben.

Ein Get-Module Befehl, der den PSSession-Parameter verwendet, entspricht der Verwendung des Invoke-Command Cmdlets zum Ausführen eines Get-Module -ListAvailable Befehls in einer PSSession.

Dieser Parameter wurde in Windows PowerShell 3.0 eingeführt.

Type:PSSession
Position:Named
Default value:None
Accept pipeline input:False
Accept wildcard characters:False

-Refresh

Gibt an, dass dieses Cmdlet den Cache der installierten Befehle aktualisiert. Der Befehlscache wird beim Starten der Sitzung erstellt. Es ermöglicht dem Get-Command Cmdlet, Befehle aus Modulen abzurufen, die nicht in die Sitzung importiert werden.

Dieser Parameter ist für Entwicklungs- und Testszenarien vorgesehen, in denen der Inhalt von Modulen sich seit dem Start der Sitzung geändert hat.

Wenn Sie den Refresh-Parameter in einem Befehl angeben, müssen Sie ListAvailable angeben.

Dieser Parameter wurde in Windows PowerShell 3.0 eingeführt.

Type:SwitchParameter
Position:Named
Default value:False
Accept pipeline input:False
Accept wildcard characters:False

-SkipEditionCheck

Überspringt die Überprüfung des Felds CompatiblePSEditions .

Standardmäßig werden Module im Verzeichnis weggelassen, Get-Module die %windir%\System32\WindowsPowerShell\v1.0\Modules nicht im Feld CompatiblePSEditions angegeben Core sind. Wenn dieser Schalter festgelegt ist, werden Module ohne Core eingeschlossen, sodass Module unter dem Windows PowerShell Modulpfad zurückgegeben werden, die mit PowerShell v6 und höher nicht kompatibel sind.

Unter macOS und Linux bewirkt dieser Parameter nichts.

Weitere Informationen finden Sie unter about_PowerShell_Editions .

Type:SwitchParameter
Position:Named
Default value:None
Accept pipeline input:False
Accept wildcard characters:False

Eingaben

String

Sie können Modulnamen an dieses Cmdlet weiterleiten.

Ausgaben

PSModuleInfo

Dieses Cmdlet gibt Objekte zurück, die Module darstellen. Wenn Sie den ListAvailable-Parameter angeben, Get-Module gibt ein ModuleInfoGrouping-Objekt zurück, bei dem es sich um einen Typ von PSModuleInfo-Objekt handelt, der die gleichen Eigenschaften und Methoden aufweist.

Hinweise

PowerShell enthält die folgenden Aliase für Get-Module:

  • Alle Plattformen:

    • gmo
  • Ab Windows PowerShell 3.0 werden die wichtigsten Befehle, die in PowerShell enthalten sind, in Module gepackt. Die Ausnahme ist Microsoft. PowerShell.Core, ein Snap-In (PSSnapin). Standardmäßig wird nur das Microsoft.PowerShell.Core-Snap-In der Sitzung hinzugefügt. Module werden bei der ersten Verwendung automatisch importiert, und Sie können sie mit dem Import-Module Cmdlet importieren.

  • In Windows PowerShell 2.0 und in Hostprogrammen, die Sitzungen im älteren Stil in späteren Versionen von PowerShell erstellen, werden die Kernbefehle in Snap-Ins (PSSnapins) verpackt. Die Ausnahme ist Microsoft. PowerShell.Core, bei dem es sich immer um ein Snap-In handelt. Außerdem handelt es sich bei Remotesitzungen, z. B. bei denen, die New-PSSession vom Cmdlet gestartet werden, um Sitzungen im älteren Stil, die Kern-Snap-Ins enthalten.

    Informationen zur CreateDefault2-Methode , mit der Sitzungen im neueren Stil mit Kernmodulen erstellt werden, finden Sie unter CreateDefault2-Methode.

  • Get-Moduleruft nur Module an Speicherorten ab, die im Wert der PSModulePath-Umgebungsvariablen ($env:PSModulePath) gespeichert sind. Das Import-Module Cmdlet kann Module an anderen Speicherorten importieren, aber Sie können sie nicht mit dem Get-Module Cmdlet abrufen.

  • Ab PowerShell 3.0 wurden dem zurückgibt-Objekt Get-Module neue Eigenschaften hinzugefügt, die das Erlernen von Modulen erleichtern, noch bevor sie importiert werden. Alle Eigenschaften werden vor dem Import aufgefüllt. Dazu gehören die Eigenschaften ExportedCommands, ExportedCmdlets und ExportedFunctions , die die Befehle auflisten, die das Modul exportiert.

  • Der Parameter ListAvailable ruft nur wohlgeformte Module ab, d. h. Ordner, die mindestens eine Datei enthalten, deren Basisname mit dem Namen des Modulordners übereinstimmt. Der Basisname ist der Name ohne Dateinamenerweiterung. Ordner, die Dateien mit unterschiedlichen Namen enthalten, gelten als Container, aber nicht als Module.

    Um Module abzurufen, die als DLL-Dateien implementiert, aber nicht in einem Modulordner eingeschlossen sind, geben Sie sowohl die Parameter ListAvailable als auch All an.

  • Um die CIM-Sitzung zu verwenden, müssen auf dem Remotecomputer WS-Management-Remoting und Windows-Verwaltungsinstrumentation (WMI) verfügbar sein, wobei es sich um die Microsoft-Implementierung des Common Information Model (CIM)-Standards handelt. Auf dem Computer muss außerdem der WMI-Anbieter für die Modulerkennung oder ein alternativer WMI-Anbieter vorhanden sein, der die gleichen grundlegenden Funktionen bietet.

    Sie können das CIM-Sitzungsfeature auf Computern verwenden, auf denen nicht das Windows-Betriebssystem ausgeführt wird, und auf Windows-Computern, auf denen PowerShell-Remoting jedoch nicht aktiviert ist.

    Sie können die CIM-Parameter auch verwenden, um CIM-Module von Computern abzurufen, auf denen PowerShell-Remoting aktiviert ist. Dies schließt den lokalen Computer ein. Wenn Sie eine CIM-Sitzung auf dem lokalen Computer erstellen, verwendet PowerShell DCOM anstelle von WMI, um die Sitzung zu erstellen.