Get-Module

Get-Module
    [[-Name] <String[]>]
    [-FullyQualifiedName <ModuleSpecification[]>]
    [-All]
    [<CommonParameters>]

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

Get-Module
    [[-Name] <String[]>]
    -PSSession <PSSession>
    [-FullyQualifiedName <ModuleSpecification[]>]
    [-ListAvailable]
    [-Refresh]
    [<CommonParameters>]

Get-Module
    [[-Name] <String[]>]
    [-FullyQualifiedName <ModuleSpecification[]>]
    [-All]
    [-ListAvailable]
    [-Refresh]
    [<CommonParameters>]

L’applet de commande Get-Module obtient les modules PowerShell qui ont été importés, ou qui peuvent être importés, dans une session PowerShell. L’objet de module qui Get-Module retourne contient des informations précieuses sur le module. Vous pouvez également diriger les objets de module vers d’autres applets de commande, telles que les Import-Module applets de commande et Remove-Module les applets de commande.

Sans paramètres, Get-Module obtient les modules qui ont été importés dans la session active. Pour obtenir tous les modules installés, spécifiez le paramètre ListAvailable.

Get-Module obtient des modules, mais il ne les importe pas. À compter de Windows PowerShell 3.0, les modules sont automatiquement importés lorsque vous utilisez une commande dans le module, mais qu’une Get-Module commande ne déclenche pas d’importation automatique. Vous pouvez également importer les modules dans votre session à l’aide de l’applet de commande Import-Module.

À compter de Windows PowerShell 3.0, vous pouvez obtenir, puis importer des modules à partir de sessions distantes dans la session locale. Cette stratégie utilise la fonctionnalité de communication à distance implicite de PowerShell et équivaut à utiliser l’applet Import-PSSession de commande. Lorsque vous utilisez des commandes dans des modules importés à partir d’une autre session, les commandes s’exécutent implicitement dans la session à distance. Cette fonctionnalité vous permet de gérer l’ordinateur distant à partir de la session locale.

En outre, à partir de Windows PowerShell 3.0, vous pouvez utiliser Get-Module et Import-Module pour obtenir et importer des modules CIM (Common Information Model), dans lesquels les applets de commande sont définies dans les fichiers CDXML (Cmdlet Definition XML). Cette fonctionnalité vous permet d’utiliser des applets de commande implémentées dans des assemblys de code non managés, tels que ceux écrits en C++.

Avec ces nouvelles fonctionnalités, les applets de commande Get-Module et Import-Module deviennent des outils principaux pour la gestion des entreprises hétérogènes qui incluent les ordinateurs qui exécutent le système d’exploitation Windows et les ordinateurs qui exécutent d’autres systèmes d’exploitation.

Pour gérer les ordinateurs distants qui exécutent le système d’exploitation Windows avec PowerShell et la communication à distance PowerShell activés, créez une PSSession sur l’ordinateur distant, puis utilisez le paramètre PSSession de Get-Module pour obtenir les modules PowerShell dans le psSession. Lorsque vous importez les modules, puis utilisez les commandes importées dans la session active, les commandes s’exécutent implicitement dans le PSSession sur l’ordinateur distant. Vous pouvez utiliser cette stratégie pour gérer l’ordinateur distant.

Vous pouvez utiliser une stratégie similaire pour gérer les ordinateurs dont la communication à distance PowerShell n’est pas activée. Ceux-ci incluent les ordinateurs qui n’exécutent pas le système d’exploitation Windows et les ordinateurs qui ont PowerShell, mais qui n’ont pas activé la communication à distance PowerShell.

Commencez par créer une session CIM sur l’ordinateur distant. Une session CIM est une connexion à Windows Management Instrumentation (WMI) sur l’ordinateur distant. Utilisez ensuite le paramètre CIMSession de Get-Module pour obtenir des modules CIM à partir de la session CIM. Lorsque vous importez un module CIM à l’aide de l’applet Import-Module de commande, puis exécutez les commandes importées, les commandes s’exécutent implicitement sur l’ordinateur distant. Vous pouvez utiliser cette stratégie WMI et CIM pour gérer l’ordinateur distant.

Get-Module

Cette commande obtient les modules qui ont été importés dans la session active.

Get-Module -ListAvailable

Cette commande obtient les modules installés sur l’ordinateur et peuvent être importés dans la session active.

recherche les modules disponibles dans le chemin spécifié par la variable d’environnement $env :PSModulePath. Pour plus d’informations sur PSModulePath, consultez about_Modules et about_Environment_Variables.

Get-Module -ListAvailable -All

Cette commande obtient tous les fichiers exportés pour tous les modules disponibles.

$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

Cette commande obtient le module Microsoft.PowerShell.Management en spécifiant le nom complet du module à l’aide du paramètre FullyQualifiedName. La commande canalise ensuite les résultats dans l’applet Format-Table de commande pour mettre en forme les résultats sous la forme d’une table portant le nom et la version comme en-têtes de colonne.

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

Cette commande obtient les propriétés de l’objet PSModuleInfo qui Get-Module retourne. Il existe un objet pour chaque fichier de module.

Vous pouvez utiliser les propriétés pour mettre en forme et filtrer les objets de module. Pour plus d’informations sur les propriétés, consultez Propriétés PSModuleInfo.

La sortie inclut les nouvelles propriétés, telles que Author et CompanyName, qui ont été introduites dans Windows PowerShell 3.0.

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

Cette commande obtient tous les fichiers de module, importés et disponibles, puis les regroupe par nom de module. Cela vous permet de voir les fichiers de module que chaque script exporte.

Ces commandes affichent le contenu du manifeste du module pour le module BitsTransfer Windows PowerShell.

Les modules ne sont pas requis pour avoir des fichiers manifestes. Lorsqu’ils ont un fichier manifeste, le fichier manifeste est requis uniquement pour inclure un numéro de version. Toutefois, les fichiers manifestes fournissent souvent des informations utiles sur un module, ses exigences et son contenu.

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

La première commande obtient l’objet PSModuleInfo qui représente le module BitsTransfer. Il enregistre l’objet dans la variable $m.

La deuxième commande utilise l’applet Get-Content de commande pour obtenir le contenu du fichier manifeste dans le chemin d’accès spécifié. Il utilise la notation par points pour obtenir le chemin d’accès au fichier manifeste, qui est stocké dans la propriété Path de l’objet. La sortie affiche le contenu du manifeste du module.

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

Cette commande répertorie les fichiers dans le répertoire du module. Il s’agit d’une autre façon de déterminer ce qui se trouve dans un module avant de l’importer. Certains modules peuvent avoir des fichiers d’aide ou des fichiers ReadMe qui décrivent le module.

$s = New-PSSession -ComputerName Server01

Get-Module -PSSession $s -ListAvailable

Ces commandes obtiennent les modules installés sur l’ordinateur Server01.

La première commande utilise l’applet de commande New-PSSession pour créer un PSSession sur l’ordinateur Server01. La commande enregistre le PSSession dans la variable $s.

La deuxième commande utilise les paramètres PSSession et ListAvailable de Get-Module pour obtenir les modules dans le psSession dans la variable $s.

Si vous dirigez des modules d’autres sessions vers l’applet Import-Module de commande, Import-Module importez le module dans la session active à l’aide de la fonctionnalité de communication à distance implicite. Cela équivaut à utiliser l’applet de commande Import-PSSession. Vous pouvez utiliser les applets de commande à partir du module dans la session active, mais les commandes qui utilisent ces applets de commande exécutent réellement la session à distance. Pour plus d’informations, consultez Import-Module et Import-PSSession.

Les commandes de cet exemple vous permettent de gérer les systèmes de stockage d’un ordinateur distant qui n’exécute pas le système d’exploitation Windows. Dans cet exemple, étant donné que l’administrateur de l’ordinateur a installé le fournisseur WMI de découverte de modules, les commandes CIM peuvent utiliser les valeurs par défaut, conçues pour le fournisseur.

$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

La première commande utilise l’applet New-CimSession de commande pour créer une session sur l’ordinateur distant RSDGF03. La session se connecte à WMI sur l’ordinateur distant. La commande enregistre la session CIM dans la $cs variable.

La deuxième commande utilise la session CIM dans la $cs variable pour exécuter une Get-Module commande sur l’ordinateur RSDGF03. La commande utilise le paramètre Name pour spécifier le module de stockage. La commande utilise un opérateur de pipeline (|) pour envoyer le module de stockage à l’applet de commande Import-Module, qui l’importe dans la session locale.

La troisième commande exécute l’applet Get-Command de commande sur la Get-Disk commande dans le module De stockage. Lorsque vous importez un module CIM dans la session locale, PowerShell convertit les fichiers CDXML qui représentent le module CIM en scripts PowerShell, qui apparaissent en tant que fonctions dans la session locale.

La quatrième commande exécute la Get-Disk commande. Bien que la commande soit tapée dans la session locale, elle s’exécute implicitement sur l’ordinateur distant à partir duquel elle a été importée. La commande obtient des objets de l’ordinateur distant et les retourne à la session locale.

Cette applet de commande prend en charge les paramètres courants : -Debug, -ErrorAction, -ErrorVariable, -InformationAction, -InformationVariable, -OutBuffer, -OutVariable, -PipelineVariable, -ProgressAction, -Verbose, -WarningAction et -WarningVariable. Pour plus d’informations, consultez about_CommonParameters.

Vous pouvez diriger les noms de module vers cette applet de commande.

Cette applet de commande retourne des objets qui représentent des modules. Lorsque vous spécifiez le paramètre ListAvailable , Get-Module retourne un objet ModuleInfoGrouping , qui est un type d’objet PSModuleInfo qui a les mêmes propriétés et méthodes.

• À compter de Windows PowerShell 3.0, les commandes principales incluses dans PowerShell sont empaquetées dans les modules. L’exception est Microsoft.PowerShell.Core, qui est un composant logiciel enfichable (PSSnapin). Par défaut, seul le composant logiciel enfichable Microsoft.PowerShell.Core est ajouté à la session. Les modules sont importés automatiquement lors de la première utilisation et vous pouvez utiliser l’applet de commande Import-Module pour les importer.

• À compter de Windows PowerShell 3.0, les commandes principales installées avec PowerShell sont empaquetées dans les modules. Dans Windows PowerShell 2.0 et dans les programmes hôtes qui créent des sessions de style plus ancien dans les versions ultérieures de PowerShell, les commandes principales sont empaquetées dans les composants logiciels enfichables (PSSnapins). L’exception est Microsoft.PowerShell.Core, qui est toujours un composant logiciel enfichable. En outre, les sessions à distance, telles que celles démarrées par l’applet de commande New-PSSession, sont des sessions de style plus ancien qui incluent des composants logiciels enfichables principaux.

  Pour plus d’informations sur la méthode CreateDefault2 qui crée des sessions de style plus récent avec des modules principaux, consultez méthode CreateDefault2 dans la bibliothèque MSDN.

• obtient uniquement des modules dans des emplacements stockés dans la valeur de la variable d’environnement PSModulePath ($env :PSModulePath). Vous pouvez utiliser le paramètre Path de l’applet de commande Import-Module pour importer des modules dans d’autres emplacements, mais vous ne pouvez pas utiliser l’applet de commande Get-Module pour les obtenir.

• En outre, à partir de PowerShell 3.0, de nouvelles propriétés ont été ajoutées à l’objet qui retourne ce qui Get-Module facilite l’apprentissage des modules avant leur importation. Toutes les propriétés sont remplies avant l’importation. Il s’agit notamment des propriétés ExportCommands, ExportedCmdlets et ExportedFunctions qui répertorient les commandes que le module exporte.

• Le paramètre ListAvailable obtient uniquement des modules bien formés, c’est-à-dire des dossiers qui contiennent au moins un fichier dont le nom de base est identique au nom du dossier du module. Le nom de base est le nom sans l’extension de nom de fichier. Les dossiers qui contiennent des fichiers qui ont des noms différents sont considérés comme des conteneurs, mais pas des modules.

  Pour obtenir des modules implémentés en tant que fichiers .dll, mais qui ne sont pas placés dans un dossier de module, spécifiez à la fois les paramètres ListAvailable et Tous les paramètres de.

• Pour utiliser la fonctionnalité de session CIM, l’ordinateur distant doit avoir WS-Management communication à distance et WMI (Windows Management Instrumentation), qui est l’implémentation Microsoft de la norme CIM (Common Information Model). L’ordinateur doit également avoir le fournisseur WMI de découverte de modules ou un autre fournisseur WMI qui a les mêmes fonctionnalités de base.

  Vous pouvez utiliser la fonctionnalité de session CIM sur les ordinateurs qui n’exécutent pas le système d’exploitation Windows et sur les ordinateurs Windows qui ont PowerShell, mais qui n’ont pas activé la communication à distance PowerShell.

  Vous pouvez également utiliser les paramètres CIM pour obtenir des modules CIM à partir d’ordinateurs sur utilisant la communication à distance PowerShell activée. Cela inclut l’ordinateur local. Lorsque vous créez une session CIM sur l’ordinateur local, PowerShell utilise DCOM, au lieu de WMI, pour créer la session.