À propos des modules
Description courte
Explique comment installer, importer et utiliser des modules PowerShell.
Description longue
Un module est un package qui contient des commandes PowerShell, telles que des applets de commande, des fournisseurs, des fonctions, des workflows, des variables et des alias.
Les personnes qui écrivent des commandes peuvent utiliser des modules pour organiser leurs commandes et les partager avec d'autres utilisateurs. Personnes qui reçoivent des modules peuvent ajouter les commandes des modules à leurs sessions PowerShell et les utiliser comme les commandes intégrées.
Cette rubrique explique comment utiliser des modules PowerShell. Pour plus d’informations sur l’écriture de modules PowerShell, consultez Écriture d’un module PowerShell.
Qu’est-ce qu’un module ?
Un module est un package de commandes. Tous les applets de commande et fournisseurs de votre session sont ajoutés par un module ou un composant logiciel enfichable.
Chargement automatique des modules
À compter de PowerShell 3.0, PowerShell importe automatiquement des modules la première fois que vous exécutez une commande dans un module installé. Vous pouvez désormais utiliser les commandes d'un module sans même le configurer ni définir de profil. Une fois vos modules installés sur votre ordinateur, vous n'avez pas à vous en occuper.
Vous pouvez aussi trouver plus facilement les commandes contenues dans un module. L’applet Get-Command
de commande obtient désormais toutes les commandes dans tous les modules installés, même si elles ne se trouvent pas encore dans la session. Vous pouvez donc trouver une commande et l’utiliser sans l’importer.
Chacun des exemples suivants entraîne l’importation du module contenant Get-Mailbox
dans votre session.
Exécuter la commande
Get-Mailbox -Identity Chris
Obtenir la commande
Get-Command Get-Mailbox
Obtenir de l’aide pour la commande
Get-Help Get-Mailbox
Get-Command
les commandes qui incluent un caractère générique (*) sont considérées comme destinées à la découverte, à ne pas utiliser et n’importent aucun module.
Seuls les modules stockés à l’emplacement spécifié par la variable d’environnement PSModulePath sont automatiquement importés. Les modules dans d’autres emplacements doivent être importés en exécutant l’applet de Import-Module
commande.
En outre, les commandes qui utilisent des fournisseurs PowerShell n’importent pas automatiquement un module. Par exemple, si vous utilisez une commande qui nécessite le lecteur WSMan :, comme l’applet Get-PSSessionConfiguration
de commande, vous devrez peut-être exécuter l’applet Import-Module
de commande pour importer le module Microsoft.WSMan.Management qui inclut le WSMan:
lecteur.
Vous pouvez toujours exécuter la Import-Module
commande pour importer un module et utiliser la $PSModuleAutoloadingPreference
variable pour activer, désactiver et configurer l’importation automatique de modules. Pour plus d’informations, consultez about_Preference_Variables.
Comment utiliser un module
Pour utiliser un module, procédez comme suit :
- Installez le module. (Bien souvent, cette tâche ne vous incombe pas.)
- Recherchez les commandes ajoutées par le module.
- Utilisez les commandes ajoutées par le module.
Cette rubrique explique comment effectuer ces tâches. Elle contient également d'autres informations utiles sur la gestion des modules.
Comment installer un module
Si vous recevez un module en tant que dossier contenant des fichiers, vous devez l’installer sur votre ordinateur avant de pouvoir l’utiliser dans PowerShell.
La plupart des modules sont installés pour vous. PowerShell est fourni avec plusieurs modules préinstallés, parfois appelés modules « core ». Sur les ordinateurs Windows, si les fonctionnalités incluses dans le système d’exploitation ont des applets de commande pour les gérer, ces modules sont préinstallés. Lorsque vous installez une fonctionnalité Windows, à l’aide, par exemple, de l’Assistant Ajout de rôles et de fonctionnalités dans Gestionnaire de serveur ou de la boîte de dialogue Activer ou désactiver les fonctionnalités Windows dans Panneau de configuration, tous les modules PowerShell qui font partie de la fonctionnalité sont installés. D'autres modules sont fournis avec un programme d'installation.
Utilisez la commande suivante pour créer un répertoire Modules pour l’utilisateur actuel :
New-Item -Type Directory -Path $HOME\Documents\WindowsPowerShell\Modules
Copiez le dossier du module en totalité dans le répertoire Modules. Vous pouvez utiliser n’importe quelle méthode pour copier le dossier, y compris Windows Explorer et Cmd.exe, ainsi que PowerShell. Dans PowerShell, utilisez l’applet de Copy-Item
commande . Par exemple, pour copier le dossier MyModule à partir du C:\ps-test\MyModule
répertoire Modules, tapez :
Copy-Item -Path C:\ps-test\MyModule -Destination `
$HOME\Documents\WindowsPowerShell\Modules
Vous pouvez installer vos modules n'importe où, mais nous vous recommandons de les installer dans un emplacement de module par défaut pour faciliter leur gestion. Pour plus d’informations sur les emplacements des modules par défaut, consultez la section Emplacements des ressources module et DSC et PSModulePath .
Guide pratique pour rechercher les modules installés
Pour trouver les modules qui sont installés dans un emplacement par défaut, mais qui ne sont pas encore dans votre session, tapez :
Get-Module -ListAvailable
Pour rechercher les modules qui ont déjà été importés dans votre session, à l’invite PowerShell, tapez :
Get-Module
Pour plus d’informations sur l’applet de Get-Module
commande, consultez Get-Module.
Comment rechercher les commandes dans un module
Utilisez l’applet de Get-Command
commande pour rechercher toutes les commandes disponibles. Vous pouvez utiliser les paramètres de l’applet Get-Command
de commande pour filtrer des commandes telles que par module, nom et nom.
Pour trouver toutes les commandes dans un module, tapez :
Get-Command -Module <module-name>
Par exemple, pour rechercher les commandes dans le module BitsTransfer, tapez :
Get-Command -Module BitsTransfer
Pour plus d’informations sur l’applet de Get-Command
commande, consultez Get-Command.
Comment obtenir de l’aide pour les commandes d’un module
Si le module contient des fichiers d’aide pour les commandes qu’il exporte, l’applet Get-Help
de commande affiche les rubriques d’aide. Utilisez le même Get-Help
format de commande que celui que vous utiliseriez pour obtenir de l’aide pour n’importe quelle commande dans PowerShell.
À partir de PowerShell 3.0, vous pouvez télécharger des fichiers d’aide pour un module et télécharger les mises à jour des fichiers d’aide afin qu’ils ne soient jamais obsolètes.
Pour obtenir de l'aide sur une commande d'un module, tapez :
Get-Help <command-name>
Pour obtenir de l’aide en ligne pour la commande dans un module, tapez :
Get-Help <command-name> -Online
Pour télécharger et installer les fichiers d’aide pour les commandes dans un module, tapez :
Update-Help -Module <module-name>
Pour plus d’informations, consultez Get-Help et Update-Help.
Comment importer un module
Vous pouvez être amené à importer un module ou un fichier de module. L’importation est requise lorsqu’un module n’est pas installé dans les emplacements spécifiés par la variable d’environnement PSModulePath , $env:PSModulePath
ou que le module se compose d’un fichier, tel qu’un fichier .dll ou .psm1, au lieu d’un module classique fourni en tant que dossier.
Vous pouvez également choisir d’importer un module afin de pouvoir utiliser les paramètres de la commande, tels que le Import-Module
paramètre Préfixe, qui ajoute un préfixe distinctif aux noms substantifs de toutes les commandes importées, ou le paramètre NoClobber , qui empêche le module d’ajouter des commandes qui masqueraient ou remplaceraient les commandes existantes dans la session.
Pour importer des modules, utilisez l’applet de Import-Module
commande .
Pour importer des modules dans un emplacement PSModulePath de la session active, utilisez le format de commande suivant.
Import-Module <module-name>
Par exemple, la commande suivante importe le module BitsTransfer dans la session active.
Import-Module BitsTransfer
Pour importer un module qui ne figure pas dans un emplacement de module par défaut, utilisez le chemin d'accès complet au dossier du module dans la commande.
Par exemple, pour ajouter le module TestCmdlets dans le C:\ps-test
répertoire à votre session, tapez :
Import-Module C:\ps-test\TestCmdlets
Pour importer un fichier de module qui ne figure pas dans un dossier de module, utilisez le chemin d'accès complet au fichier du module dans la commande.
Par exemple, pour ajouter le module TestCmdlets.dll dans le C:\ps-test
répertoire à votre session, tapez :
Import-Module C:\ps-test\TestCmdlets.dll
Pour plus d’informations sur l’ajout de modules à votre session, consultez Import-Module.
Comment importer un module dans chaque session
La Import-Module
commande importe des modules dans votre session PowerShell actuelle. Pour importer un module dans chaque session PowerShell que vous démarrez, ajoutez la Import-Module
commande à votre profil PowerShell.
Pour plus d'informations sur les profils, consultez about_Profiles.
Comment supprimer un module
Quand vous supprimez un module, les commandes ajoutées par le module sont supprimées de la session.
Pour supprimer un module de votre session, utilisez le format de commande suivant.
Remove-Module <module-name>
Par exemple, la commande suivante supprime le module BitsTransfer de la session active.
Remove-Module BitsTransfer
Le fait de supprimer un module annule l'opération d'importation d'un module. Toutefois, le module supprimé n'est pas désinstallé. Pour plus d’informations, consultez Remove-Module.
Emplacements des ressources module et DSC, et PSModulePath
Voici les emplacements par défaut des modules PowerShell. À partir de PowerShell 4.0, avec l’introduction de DSC, un nouveau module par défaut et un dossier de ressources DSC ont été introduits. Pour plus d’informations sur DSC, consultez about_DesiredStateConfiguration.
Système :
$PSHOME\Modules
ou ($env:windir\System32\WindowsPowerShell\v1.0\Modules
) Les modules système sont ceux fournis avec Windows et PowerShell.À partir de PowerShell 4.0, lorsque PowerShell Desired State Configuration (DSC) a été introduit, les ressources DSC incluses dans PowerShell sont également stockées dans
$PSHOME\Modules
, dans le$PSHOME\Modules\PSDesiredStateConfiguration\DSCResources
dossier .Utilisateur actuel :
$HOME\Documents\WindowsPowerShell\Modules
($env:UserProfile\Documents\WindowsPowerShell\Modules
)ou
$HOME\My Documents\WindowsPowerShell\Modules
($env:UserProfile\My Documents\WindowsPowerShell\Modules
)Il s’agit de l’emplacement des modules ajoutés par l’utilisateur avant PowerShell 4.0.
Dans PowerShell 4.0 et versions ultérieures de PowerShell, les modules ajoutés par l’utilisateur et les ressources DSC sont stockés dans C:\Program Files\WindowsPowerShell\Modules
. Les modules et les ressources DSC de cet emplacement sont accessibles à tous les utilisateurs de l’ordinateur. Cette modification était nécessaire, car le moteur DSC s’exécute en tant que système local et ne pouvait pas accéder aux chemins d’accès spécifiques à l’utilisateur, tels que $home\Documents\WindowsPowerShell\Modules
.
À partir de PowerShell 5.0, avec l’ajout du module PowerShellGet et de l’PowerShell Gallery des ressources de la communauté et créées par Microsoft, la Install-Module
commande installe les modules et les ressources DSC sur C:\Program Files\WindowsPowerShell\Modules
par défaut.
Remarque : pour ajouter ou modifier des fichiers dans le $env:Windir\System32
répertoire, démarrez PowerShell avec l’option « Exécuter en tant qu’administrateur ».
Vous pouvez modifier les emplacements de module par défaut sur votre système en modifiant la valeur de la variable d’environnement PSModulePath , $Env:PSModulePath
. La variable d’environnement PSModulePath est modélisée sur la variable d’environnement Path et a le même format.
Pour afficher les emplacements par défaut des modules, tapez :
$Env:PSModulePath
Pour ajouter un emplacement de module par défaut, utilisez le format de commande suivant.
$Env:PSModulePath = $Env:PSModulePath + ";<path>"
Le point-virgule (;) dans la commande sépare le nouveau chemin d'accès du chemin d'accès qui le précède dans la liste.
Par exemple, pour ajouter le C:\ps-test\Modules
répertoire, tapez :
$Env:PSModulePath + ";C:\ps-test\Modules"
Lorsque vous ajoutez un chemin d’accès à PSModulePath et Get-Module
Import-Module
que les commandes incluent des modules dans ce chemin.
La valeur que vous définissez affecte uniquement la session active. Pour rendre la modification persistante, ajoutez la commande à votre profil PowerShell ou utilisez System dans Panneau de configuration pour modifier la valeur de la variable d’environnement PSModulePath dans le Registre.
En outre, pour rendre la modification persistante, vous pouvez également utiliser la méthode SetEnvironmentVariable de la classe System.Environment pour ajouter un chemin à la variable d’environnement PSModulePath .
Pour plus d’informations sur la variable PSModulePath , consultez about_Environment_Variables.
Modules et conflits de noms
Des conflits de noms se produisent quand plusieurs commandes portent le même nom dans la session. Quand vous importez un module, un conflit survient si les noms des commandes de ce module sont identiques à ceux de commandes ou d'éléments présents dans la session.
Les conflits de noms peuvent entraîner le masquage ou le remplacement de commandes.
Hidden
Une commande est masquée si elle ne s'exécute pas quand vous tapez son nom. Vous pouvez toutefois l'exécuter en utilisant une autre méthode, par exemple en qualifiant le nom de la commande avec le nom du module ou du composant logiciel enfichable d'où elle provient.
Remplacé
Une commande est remplacée quand vous ne pouvez pas l'exécuter parce qu'elle a été remplacée par une commande du même nom. Même quand vous supprimez le module à l'origine du conflit, vous ne pouvez pas exécuter une commande remplacée, à moins de redémarrer la session.
Import-Module
peut ajouter des commandes qui masquent et remplacent des commandes dans la session active. Par ailleurs, les commandes dans votre session peuvent masquer les commandes ajoutées par le module.
Pour détecter les conflits de noms, utilisez le paramètre All de l’applet Get-Command
de commande. À partir de PowerShell 3.0, Get-Command
obtient uniquement les commandes qui s’exécutent lorsque vous tapez le nom de la commande. Le paramètre All obtient toutes les commandes portant le nom spécifique dans la session.
Pour éviter les conflits de noms, utilisez les paramètres NoClobber ou Préfixe de l’applet Import-Module
de commande. Le paramètre Préfixe ajoute un préfixe aux noms des commandes importées afin qu’elles soient uniques dans la session. Le paramètre NoClobber n’importe aucune commande qui masquerait ou remplacerait les commandes existantes dans la session.
Vous pouvez également utiliser les paramètres Alias, Applet de commande, Fonction et Variable de Import-Module
pour sélectionner uniquement les commandes à importer, et vous pouvez exclure les commandes qui provoquent des conflits de noms dans votre session.
Les auteurs de module peuvent empêcher les conflits de noms en utilisant la propriété DefaultCommandPrefix du manifeste du module pour ajouter un préfixe par défaut à tous les noms de commandes. La valeur du paramètre Prefix est prioritaire sur la valeur de DefaultCommandPrefix.
Même si une commande est masquée, vous pouvez l'exécuter en qualifiant le nom de la commande avec le nom du module ou du composant logiciel enfichable d'où elle provient.
Les règles de précédence des commandes PowerShell déterminent quelle commande s’exécute lorsque la session inclut des commandes portant le même nom.
Par exemple, lorsqu’une session inclut une fonction et une applet de commande portant le même nom, PowerShell exécute la fonction par défaut. Quand la session inclut des commandes du même type avec le même nom, par exemple deux applets de commande avec le même nom, la commande la plus récemment ajoutée est exécutée par défaut.
Pour plus d’informations, notamment une explication des règles de priorité et des instructions pour l’exécution de commandes masquées, consultez about_Command_Precedence.
Modules et composants logiciels enfichables
Vous pouvez ajouter des commandes à votre session à partir de modules et de composants logiciels enfichables. Les modules peuvent ajouter tous les types de commandes, y compris les applets de commande, les fournisseurs et les fonctions, ainsi que les éléments, tels que les variables, les alias et les lecteurs PowerShell. Les composants logiciels enfichables peuvent uniquement ajouter des applets de commande et des fournisseurs.
Avant de supprimer un module ou un composant logiciel enfichable de votre session, utilisez les commandes suivantes pour déterminer les commandes qui seront supprimées.
Pour rechercher la source d’une applet de commande dans votre session, utilisez le format de commande suivant :
Get-Command <cmdlet-name> | Format-List -Property verb,noun,pssnapin,module
Par exemple, pour rechercher la source de l’applet Get-Date
de commande, tapez :
Get-Command Get-Date | Format-List -Property verb,noun,module
Pour plus d’informations sur les composants logiciels enfichables PowerShell, consultez about_PSSnapins.
Avertissements et erreurs liés aux modules
Les commandes qu’un module exporte doivent suivre les règles de nommage des commandes PowerShell. Si le module que vous importez exporte des applets de commande ou des fonctions qui ont des verbes non approuvés dans leurs noms, l’applet Import-Module
de commande affiche le message d’avertissement suivant.
AVERTISSEMENT : Certains noms de commande importés incluent des verbes non approuvés qui peuvent les rendre moins détectables. Utilisez le paramètre Verbose pour obtenir plus d'informations ou tapez Get-Verb pour afficher la liste des verbes approuvés.
Ce message n'est qu'un avertissement. Le module entier est toujours importé, y compris les commandes non conformes. Bien que le message soit affiché aux utilisateurs du module, le problème d'affectation de noms doit être corrigé par l'auteur du module.
Pour supprimer le message d’avertissement, utilisez le paramètre DisableNameChecking de l’applet Import-Module
de commande.
Modules intégrés et composants logiciels enfichables
Dans PowerShell 2.0 et dans les programmes hôtes de style plus ancien dans PowerShell 3.0 et versions ultérieures, les commandes principales installées avec PowerShell sont empaquetées dans des composants logiciels enfichables qui sont ajoutés automatiquement à chaque session PowerShell.
À compter de PowerShell 3.0, pour les programmes hôtes qui implémentent l’API InitialSessionState.CreateDefault2
d’état de session initiale, le composant logiciel enfichable Microsoft.PowerShell.Core est ajouté à chaque session par défaut. Les modules sont chargés automatiquement lors de la première utilisation.
Notes
Les sessions à distance, y compris les sessions démarrées à l’aide de l’applet New-PSSession
de commande, sont des sessions de style plus ancien dans lesquelles les commandes intégrées sont empaquetées dans des composants logiciels enfichables.
Les modules (ou composants logiciels enfichables) suivants sont installés avec PowerShell.
- Microsoft.PowerShell.Archive
- Microsoft.PowerShell.Core
- Microsoft.PowerShell.Diagnostics
- Microsoft.PowerShell.Host
- Microsoft.PowerShell.Management
- Microsoft.PowerShell.ODataUtils
- Microsoft.PowerShell.Security
- Microsoft.PowerShell.Utility
- Microsoft.WSMan.Management
- PackageManagement
- PowerShellGet
- PSDesiredStateConfiguration
- PSReadline
- PSScheduledJob
- PSWorkflow
- PSWorkflowUtility
- ISE
Événements de module de journalisation
À partir de PowerShell 3.0, vous pouvez enregistrer les événements d’exécution pour les applets de commande et les fonctions dans les modules powerShell et les composants logiciels enfichables en définissant la propriété LogPipelineExecutionDetails des modules et des composants logiciels enfichables sur $True
.
Vous pouvez également utiliser un paramètre stratégie de groupe, Activer la journalisation des modules, pour activer la journalisation des modules dans toutes les sessions PowerShell. Pour plus d’informations, consultez about_EventLogs et about_Group_Policy_Settings.
Voir aussi
about_DesiredStateConfiguration