Freigeben über

Get-Module

  • Referenz
Modul:
Microsoft.PowerShell.Core

Auflisten der in der aktuellen Sitzung importierten Module oder die 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 cmdlet Get-Module listet die PowerShell-Module auf, die importiert wurden oder in eine PowerShell-Sitzung importiert werden können. Ohne Parameter ruft Get-Module Module ab, die in die aktuelle Sitzung importiert wurden. Der parameter ListAvailable wird verwendet, um die Module auflisten, die aus den in der PSModulePath Umgebungsvariablen ($env:PSModulePath) angegebenen Pfaden importiert werden können.

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

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 Feature "Implizites Remoting" von PowerShell und entspricht der Verwendung des cmdlets Import-PSSession. 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.

Ab Windows PowerShell 3.0 können Sie auch Get-Module und Import-Module verwenden, um Common Information Model(CIM)-Module abzurufen und zu 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++ geschriebene.

Implizites Remoting kann zum Verwalten von Remotecomputern verwendet werden, 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, die keine PowerShell-Remoting aktiviert haben. Dazu gehören Computer, auf denen das Windows-Betriebssystem nicht ausgeführt wird, und Computer, auf denen PowerShell ausgeführt wird, aber keine 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 cmdlets Import-Module importieren und dann die importierten Befehle ausführen, werden die Befehle implizit auf dem Remotecomputer ausgeführt. Sie können diese WMI- und CIM-Strategie verwenden, um den Remotecomputer zu verwalten.

Beispiele

Beispiel 1: Importieren von Modulen in die aktuelle Sitzung

Get-Module

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

Beispiel 2: Abrufen von installierten Modulen und verfügbaren Modulen

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 durch die $env:PSModulePath Umgebungsvariable 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 anhand seines vollqualifizierten Namens

$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 das Microsoft.PowerShell.Management Modul durch Angeben des vollqualifizierten Namens des Moduls mithilfe des parameters FullyQualifiedName. Der Befehl leitet dann die Ergebnisse in das cmdlet Format-Table, 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. Daher entspricht es in diesem Beispiel jedem Microsoft.PowerShell.Management Modul, das Version 3.1.0.0 oder höher ist.

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

Dieser Befehl ruft die Eigenschaften des PSModuleInfo--Objekts ab, das Get-Module zurückgibt. Es gibt ein Objekt für jede Moduldatei.

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

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

Beispiel 6: Gruppieren 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 Moduldateien ab, sowohl importiert als auch verfügbar, und gruppiert sie dann nach Modulname. Auf diese Weise können Sie die Moduldateien sehen, die jedes Skript exportiert.

Beispiel 7: Anzeigen des Inhalts eines Modulmanifests

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

Module müssen nicht über Manifestdateien verfügen. Wenn sie über eine Manifestdatei verfügen, ist die Manifestdatei nur erforderlich, um eine Versionsnummer einzuschließen. Manifestdateien stellen jedoch häufig nützliche Informationen zu einem Modul, seinen Anforderungen und seinem Inhalt bereit.

# 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"
}

Der erste Befehl ruft das PSModuleInfo -Objekt ab, das BitsTransfer-Modul darstellt. Es speichert das Objekt in der $m Variablen.

Der zweite Befehl verwendet das Cmdlet Get-Content, um den Inhalt der Manifestdatei im angegebenen Pfad abzurufen. Es verwendet punktierte Schreibweise, um den Pfad zur Manifestdatei abzurufen, die in der Path -Eigenschaft des Objekts gespeichert wird. Die Ausgabe zeigt den Inhalt des Modulmanifests an.

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

Dieser Befehl listet die Dateien im Verzeichnis des Moduls auf. Dies ist eine weitere Möglichkeit, um zu bestimmen, was sich in einem Modul befindet, bevor Sie es importieren. Einige Module verfügen möglicherweise über Hilfedateien oder ReadMe-Dateien, die das Modul beschreiben.

Beispiel 9: Installieren von Modulen auf einem Computer

$s = New-PSSession -ComputerName Server01

Get-Module -PSSession $s -ListAvailable

Mit diesen Befehlen werden die Module abgerufen, die auf dem Server01-Computer installiert sind.

Der erste Befehl verwendet das cmdlet New-PSSession zum Erstellen eines PSSession- auf dem Server01-Computer. Der Befehl speichert die PSSession- in der variablen $s.

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

Wenn Sie Module aus anderen Sitzungen an das Cmdlet Import-Module weiterleiten, importiert Import-Module das Modul mithilfe der impliziten Remotingfunktion 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, aber Befehle, die diese Cmdlets verwenden, führen tatsächlich die Remotesitzung aus. 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 in diesem Beispiel der Administrator des Computers den Modulermittlungs-WMI-Anbieter installiert hat, können die CIM-Befehle die Standardwerte verwenden, die für den Anbieter entwickelt 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 cmdlet New-CimSession zum Erstellen einer Sitzung auf dem RSDGF03 Remotecomputer. Die Sitzung stellt eine Verbindung mit WMI auf dem Remotecomputer hergestellt. Der Befehl speichert die CIM-Sitzung in der variablen $cs.

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

Der dritte Befehl führt das cmdlet Get-Command auf dem Befehl Get-Disk im Speichermodul aus. 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 Befehl Get-Disk 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) Dateien. Ohne diesen Parameter ruft Get-Module nur das Standardmodul in jedem Modulordner ab.

Typ:SwitchParameter
Position:Named
Standardwert:False
Erforderlich:False
Pipelineeingabe akzeptieren:False
Platzhalterzeichen akzeptieren: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 Modulermittlung.

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

Dieser Parameter wurde in Windows PowerShell 3.0 eingeführt.

Typ:String
Position:Named
Standardwert:None
Erforderlich:False
Pipelineeingabe akzeptieren:False
Platzhalterzeichen akzeptieren:False

-CimResourceUri

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

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

Dieser Parameter wurde in Windows PowerShell 3.0 eingeführt.

Typ:Uri
Position:Named
Standardwert:None
Erforderlich:False
Pipelineeingabe akzeptieren:False
Platzhalterzeichen akzeptieren:False

-CimSession

Gibt eine CIM-Sitzung auf dem Remotecomputer an. Geben Sie eine Variable ein, die die CIM-Sitzung oder einen Befehl enthält, 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 Cmdlets Import-Module 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, die nicht das Windows-Betriebssystem ausführen, und Computer mit PowerShell, aber keine PowerShell-Remoting aktiviert haben.

Der parameter CimSession ruft alle Module im CIMSessionab. Sie können jedoch nur CIM-basierte und Cmdlet Definition XML (CDXML)-basierte Module importieren.

Typ:CimSession
Position:Named
Standardwert:None
Erforderlich:True
Pipelineeingabe akzeptieren:False
Platzhalterzeichen akzeptieren: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 vollqualifizierte oder relativ sein. Ein relativer Pfad wird relativ zum Skript aufgelöst, das die using-Anweisung enthält.

Wenn es sich bei dem Wert um einen Namen oder eine Modulspezifikation handelt, durchsucht PowerShell die PSModulePath- nach dem angegebenen Modul.

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

  • ModuleName - Erforderlicher Gibt den Modulnamen an.
  • GUID - Optionaler Gibt die GUID des Moduls an.
  • Außerdem Erforderlicher, um mindestens einen der drei folgenden Tasten anzugeben.
    • ModuleVersion – Gibt eine akzeptable 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 selben Befehl wie ein Name-Parameter angeben.

Typ:ModuleSpecification[]
Position:Named
Standardwert:None
Erforderlich:False
Pipelineeingabe akzeptieren:True
Platzhalterzeichen akzeptieren:False

-ListAvailable

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

Typ:SwitchParameter
Position:Named
Standardwert:None
Erforderlich:False
Pipelineeingabe akzeptieren:False
Platzhalterzeichen akzeptieren:False

-Name

Gibt Namen oder Namensmuster von Modulen an, die dieses Cmdlet abruft. Wildcardzeichen sind zulässig. Sie können die Namen auch an Get-Moduleweitergeleitet werden. Sie können den parameter FullyQualifiedName nicht im selben Befehl wie ein Name-Parameter angeben.

Name kann keine Modul-GUID als Wert akzeptieren. Um Module zurückzugeben, indem Sie eine GUID angeben, verwenden Sie stattdessen FullyQualifiedName.

Typ:String[]
Position:0
Standardwert:None
Erforderlich:False
Pipelineeingabe akzeptieren:True
Platzhalterzeichen akzeptieren:True

-PSEdition

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

Die zulässigen Werte für diesen Parameter sind:

  • Desktop
  • Core

Das cmdlet Get-Module überprüft CompatiblePSEditions Eigenschaft von PSModuleInfo Objekt für den angegebenen Wert und gibt nur die Module zurück, die sie festgelegt haben.

Anmerkung

  • Desktop Edition: Basiert auf .NET Framework und bietet Kompatibilität mit Skripts und Modulen für Versionen von PowerShell, die auf vollständigen Fußabdruckeditionen von Windows wie Server Core und Windows Desktop ausgeführt werden.
  • Core Edition: Basiert auf .NET Core und bietet Kompatibilität mit Skripts und Modulen für Versionen von PowerShell, die auf reduzierten Speicherbedarfseditionen von Windows wie Nano Server und Windows IoT ausgeführt werden.
Typ:String
Position:Named
Standardwert:None
Erforderlich:False
Pipelineeingabe akzeptieren:False
Platzhalterzeichen akzeptieren:False

-PSSession

Ruft die Module in der angegebenen vom Benutzer verwalteten PowerShell-Sitzung ab (PSSession). 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 Parameter ListAvailable angeben.

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

Dieser Parameter wurde in Windows PowerShell 3.0 eingeführt.

Typ:PSSession
Position:Named
Standardwert:None
Erforderlich:True
Pipelineeingabe akzeptieren:False
Platzhalterzeichen akzeptieren:False

-Refresh

Gibt an, dass dieses Cmdlet den Cache der installierten Befehle aktualisiert. Der Befehlscache wird erstellt, wenn die Sitzung gestartet wird. Das Cmdlet Get-Command ermöglicht das Abrufen von Befehlen aus Modulen, die nicht in die Sitzung importiert werden.

Dieser Parameter wurde für Entwicklungs- und Testszenarien entwickelt, in denen sich der Inhalt von Modulen seit beginn der Sitzung geändert hat.

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

Dieser Parameter wurde in Windows PowerShell 3.0 eingeführt.

Typ:SwitchParameter
Position:Named
Standardwert:False
Erforderlich:False
Pipelineeingabe akzeptieren:False
Platzhalterzeichen akzeptieren:False

-SkipEditionCheck

Überspringt die Überprüfung der CompatiblePSEditions Feld.

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

Unter macOS und Linux führt dieser Parameter nichts aus.

Weitere Informationen finden Sie unter about_PowerShell_Editions.

Typ:SwitchParameter
Position:Named
Standardwert:None
Erforderlich:False
Pipelineeingabe akzeptieren:False
Platzhalterzeichen akzeptieren: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, gibt Get-Module ein ModuleInfoGrouping- -Objekt zurück, bei dem es sich um einen Typ von PSModuleInfo--Objekt handelt, das 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 Kernbefehle, die in PowerShell enthalten sind, in Module verpackt. 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 das cmdlet Import-Module verwenden, um sie zu importieren.

  • In Windows PowerShell 2.0 und in Hostprogrammen, die ältere Sitzungen in späteren Versionen von PowerShell erstellen, werden die Kernbefehle in Snap-Ins (PSSnapins) verpackt. Die Ausnahme ist Microsoft.PowerShell.Core, die immer ein Snap-In ist. Außerdem sind Remotesitzungen, z. B. die vom Cmdlet New-PSSession gestarteten Sitzungen, ältere Sitzungen, die Kern-Snap-Ins enthalten.

    Informationen zur CreateDefault2--Methode, die neuere Sitzungen mit Kernmodulen erstellt, finden Sie unter CreateDefault2-Methode.

  • Get-Module ruft nur Module an Speicherorten ab, die im Wert der PSModulePath Umgebungsvariable ($env:PSModulePath) gespeichert sind. Das Cmdlet Import-Module kann Module an anderen Speicherorten importieren, sie können jedoch nicht mit dem cmdlet Get-Module abgerufen werden.

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

  • Der parameter ListAvailable erhält nur wohlgeformte Module, d. h. Ordner, die mindestens eine Datei enthalten, deren Basisname dem Namen des Modulordners entspricht. 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 sind, aber nicht in einen Modulordner eingeschlossen sind, geben Sie sowohl die parameter ListAvailable als auch Alle Parameter an.

  • Um das CIM-Sitzungsfeature zu verwenden, muss der Remotecomputer über WS-Management Remoting und die Windows-Verwaltungsinstrumentation (Windows Management Instrumentation, WMI) verfügen, was die Microsoft-Implementierung des Standards Common Information Model (CIM) ist. Der Computer muss auch über den WMI-Anbieter für Modulermittlung oder einen alternativen WMI-Anbieter verfügen, der dieselben grundlegenden Features aufweist.

    Sie können das CIM-Sitzungsfeature auf Computern verwenden, auf denen das Windows-Betriebssystem und windows-Computer mit PowerShell nicht ausgeführt werden, aber keine PowerShell-Remoting aktiviert ist.

    Sie können auch die CIM-Parameter 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.