Get-Module
Ruft die Module ab, die in die aktuelle Sitzung importiert wurden oder 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 ruft die PowerShell-Module ab, die importiert wurden oder in eine PowerShell-Sitzung importiert werden können. Das modulobjekt, das zurückgibt, Get-Module
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.
Ohne Parameter ruft Module ab, Get-Module
die in die aktuelle Sitzung importiert wurden. Um alle installierten Module abzurufen, geben Sie den ListAvailable-Parameter an.
Get-Module
ruft Module ab, aber sie importiert sie 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 Import-Module
Cmdlets 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 Import-PSSession
Cmdlets. Wenn Sie Befehle in Modulen verwenden, die aus einer anderen Sitzung importiert werden, 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 Get-Module
Sie auch module (Common Information Model, CIM) abrufen und Import-Module
importieren, in denen die Cmdlets in XML-Dateien (Cmdlet Definition XML) definiert sind. Mit diesem Feature können Sie Cmdlets verwenden, die in nicht verwalteten Codeassemblys implementiert werden, z. B. in C++geschriebene.
Mit diesen neuen Features werden die Und Import-Module
Cmdlets zu primären Tools für die Get-Module
Verwaltung heterogener Unternehmen, die Computer enthalten, die das Windows-Betriebssystem und Computer ausführen, die andere Betriebssysteme ausführen.
Um Remotecomputer zu verwalten, die das Windows-Betriebssystem ausführen, das PowerShell- und PowerShell-Remoting aktiviert hat, erstellen Sie eine PSSession auf dem Remotecomputer, und verwenden Sie dann den PSSession-ParameterGet-Module
, um die PowerShell-Module in der PSSession abzurufen. Wenn Sie die Module importieren und dann die importierten Befehle in der aktuellen Sitzung verwenden, werden die Befehle implizit in der PSSession auf dem Remotecomputer ausgeführt. Mit dieser Strategie können Sie den Remotecomputer verwalten.
Sie können eine ähnliche Strategie verwenden, um Computer zu verwalten, die keine PowerShell-Remoting aktiviert haben. Dazu gehören Computer, die nicht das Windows-Betriebssystem ausführen, und Computer, die PowerShell haben, aber keine PowerShell-Remoting aktiviert haben.
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-ParameterGet-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: Importieren von Modulen in die aktuelle Sitzung
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 durch die Umgebungsvariable $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 anhand des vollqualifizierten Namens
$FullyQualifedName = @{ModuleName="Microsoft.PowerShell.Management";ModuleVersion="3.1.0.0"}
Get-Module -FullyQualifiedName $FullyQualifedName | Format-Table -Property Name,Version
Name Version
---- -------
Microsoft.PowerShell.Management 3.1.0.0
Dieser Befehl ruft das Microsoft.PowerShell.Management-Modul ab, indem er den vollqualifizierten Namen des Moduls mithilfe des Parameters "FullyQualifiedName " angibt. Der Befehl leitet dann die Ergebnisse in das Format-Table
Cmdlet um die Ergebnisse als Tabelle mit Name und Version als Spaltenüberschriften zu formatieren.
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ückgegeben wird. 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: 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. 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 Windows PowerShell BitsTransfer-Modul an.
Module sind nicht erforderlich, um Manifestdateien zu haben. Wenn sie über eine Manifestdatei verfügen, ist die Manifestdatei nur erforderlich, um eine Versionsnummer einzuschließen. 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. Es speichert das Objekt in der $m
Variablen.
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
Dieser Befehl listet die Dateien im Verzeichnis des Moduls auf. 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: Installieren von Modulen auf einem Computer
$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 in die aktuelle Sitzung, indem Sie das implizite Remoting-Feature verwenden. Dies entspricht der Verwendung des Import-PSSession
Cmdlets. 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 REMOTEcomputer RSDGF03 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.
Der dritte Befehl führt das Get-Command
Cmdlet im Get-Disk
Befehl 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 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)-Dateien, 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 |
Required: | 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, die nicht das Windows-Betriebssystem ausführen.
Dieser Parameter wurde in Windows PowerShell 3.0 eingeführt.
Type: | String |
Position: | Named |
Default value: | None |
Required: | False |
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 Modulermittlungs-WMI-Anbieters auf dem Remotecomputer.
Verwenden Sie diesen Parameter, um CIM-Module von Computern und Geräten abzurufen, die nicht das Windows-Betriebssystem ausführen.
Dieser Parameter wurde in Windows PowerShell 3.0 eingeführt.
Type: | Uri |
Position: | Named |
Default value: | None |
Required: | False |
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 oder einen Befehl enthält, der die CIM-Sitzung abruft, z. B. einen Befehl "Get-CimSession ".
Get-Module
Verwendet die CIM-Sitzungsverbindung, um Module vom Remotecomputer abzurufen. Wenn Sie das Import-Module
Modul mithilfe des Cmdlets importieren und die Befehle aus dem importierten Modul in der aktuellen Sitzung verwenden, werden die Befehle auf dem Remotecomputer tatsächlich 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, die PowerShell haben, aber keine PowerShell-Remoting aktiviert haben.
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 |
Required: | True |
Accept pipeline input: | False |
Accept wildcard characters: | False |
-FullyQualifiedName
Gibt Module mit Namen an, die in Form von ModuleSpecification-Objekten angegeben werden. Weitere Informationen finden Sie im Abschnitt "Hinweise" des ModulSpecification-Konstruktors (Hashtable).
Der Parameter "FullyQualifiedModule " akzeptiert beispielsweise einen Modulnamen, der in einem der folgenden Formate angegeben ist:
@{ModuleName = "modulename"; ModuleVersion = "version_number"}
@{ModuleName = "modulename"; ModuleVersion = "version_number"; Guid = "GUID"}
ModuleName und ModuleVersion sind erforderlich, aber Guid ist optional. Sie können den Parameter "FullyQualifiedModule " nicht im gleichen Befehl wie einen Modulparameter angeben. die beiden Parameter sind gegenseitig exklusiv.
Type: | ModuleSpecification[] |
Position: | Named |
Default value: | None |
Required: | False |
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 PSModulePath-Umgebungsvariable aufgeführt sind. Ohne diesen Parameter Get-Module
ruft nur die Module ab, die sowohl in der PSModulePath-Umgebungsvariable 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 |
Required: | False |
Accept pipeline input: | False |
Accept wildcard characters: | False |
-Name
Gibt Namen oder Namenmuster von Modulen an, die dieses Cmdlet abruft. Platzhalterzeichen sind zulässig. Sie können auch die Namen an 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. Um Module zurückzugeben, indem Sie eine GUID angeben, verwenden Sie stattdessen FullyQualifiedName .
Type: | String[] |
Position: | 0 |
Default value: | None |
Required: | False |
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 cmdlet Get-Module überprüft die CompatiblePSEditions-Eigenschaft des PSModuleInfo-Objekts für den angegebenen Wert und gibt nur diese Module zurück, die sie festgelegt haben.
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 |
Required: | False |
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 Befehl oder einen Get-PSSession
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 dem Invoke-Command
Cmdlet, um einen Get-Module -ListAvailable
Befehl in einer PSSession auszuführen.
Dieser Parameter wurde in Windows PowerShell 3.0 eingeführt.
Type: | PSSession |
Position: | Named |
Default value: | None |
Required: | True |
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 das 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 Parameter "Aktualisieren " 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 |
Required: | False |
Accept pipeline input: | False |
Accept wildcard characters: | False |
-SkipEditionCheck
Überspringt die Überprüfung des CompatiblePSEditions
Felds.
Standardmäßig werden Get-Module Module im %windir%\System32\WindowsPowerShell\v1.0\Modules
Verzeichnis auslassen, die im CompatiblePSEditions
Feld nicht angegeben Core
sind.
Wenn dieser Switch festgelegt ist, werden Module ohne Core
eingeschlossen, sodass Module unter dem Windows PowerShell Modulpfad, der nicht mit PowerShell Core kompatibel sind, zurückgegeben werden.
Auf macOS und Linux macht dieser Parameter nichts.
Weitere Informationen finden Sie unter about_PowerShell_Editions .
Type: | SwitchParameter |
Position: | Named |
Default value: | None |
Required: | False |
Accept pipeline input: | False |
Accept wildcard characters: | False |
Eingaben
Sie können Modulnamen an dieses Cmdlet weiterleiten.
Ausgaben
Dieses Cmdlet gibt Objekte zurück, die Module darstellen.
Wenn Sie den ListAvailable-Parameter angeben, Get-Module
gibt ein ModuleInfoGrouping-Objekt zurück, das ein Typ von PSModuleInfo-Objekt ist, das die gleichen Eigenschaften und Methoden aufweist.
Hinweise
Ab Windows PowerShell 3.0 werden die Kernbefehle, die in PowerShell enthalten sind, in Modulen verpackt. Die Ausnahme ist Microsoft.PowerShell.Core, das ein Snap-In (PSSnapin) ist. Standardmäßig wird nur das Microsoft.PowerShell.Core-Snap-In der Sitzung hinzugefügt. Module werden automatisch bei der ersten Verwendung importiert, und Sie können das
Import-Module
Cmdlet verwenden, um sie zu importieren.Ab Windows PowerShell 3.0 werden die Kernbefehle, die mit PowerShell installiert sind, in Module verpackt. 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, wie z. B. die von dem
New-PSSession
Cmdlet 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 werden. Sie können den Pfadparameter desImport-Module
Cmdlets verwenden, um Module an anderen Speicherorten zu importieren, aber Sie können dasGet-Module
Cmdlet nicht verwenden, um sie abzurufen.Außerdem wurden ab PowerShell 3.0 neue Eigenschaften dem Objekt hinzugefügt, das
Get-Module
zurückgibt, damit sie einfacher über Module lernen können, bevor sie importiert werden. Alle Eigenschaften werden vor dem Importieren ausgefüllt. Dazu gehören die Eigenschaften " ExportCommands", " ExportsCmdlets " und " ExportsFunctions" , die die Befehle auflisten, die das Modul exportiert.Der Parameter "ListAvailable " ruft nur gut gebildete Module ab, also Ordner, die mindestens eine Datei enthalten, deren Basisname dem Namen des Modulordners entspricht. Der Basisname ist der Name ohne die Dateinamenerweiterung. Ordner, die Dateien enthalten, die verschiedene Namen haben, werden als Container betrachtet, aber nicht Module.
Um Module abzurufen, die als .dll Dateien implementiert werden, aber nicht in einen Modulordner eingeschlossen sind, geben Sie sowohl die Parameter "ListAvailable " als auch " Alle " 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, die das Windows-Betriebssystem nicht ausführen und auf Windows-Computern, die PowerShell haben, aber keine PowerShell-Remoting aktiviert haben.
Sie können auch die CIM-Parameter verwenden, um CIM-Module von Computern abzurufen, die PowerShell-Remoting aktiviert haben. Dies umfasst den lokalen Computer. Wenn Sie eine CIM-Sitzung auf dem lokalen Computer erstellen, verwendet PowerShell DCOM anstelle von WMI, um die Sitzung zu erstellen.