Partager via

Get-Module

  • Référence
Module:
Microsoft.PowerShell.Core

Répertoriez les modules importés dans la session active ou qui peuvent être importés à partir de PSModulePath.

Syntaxe

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

Description

L’applet Get-Module de commande répertorie les modules PowerShell qui ont été importés, ou qui peuvent être importés, dans une session PowerShell. Sans paramètres, Get-Module obtient les modules qui ont été importés dans la session active. Le paramètre ListAvailable est utilisé pour répertorier les modules qui sont disponibles pour être importés à partir des chemins spécifiés dans la variable d’environnement PSModulePath ($env:PSModulePath).

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.

Get-Module répertorie les 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 Import-Module commande.

À 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 importer des modules CIM (Common Information Model). Les modules CIM définissent les applets de commande 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++.

La communication à distance implicite peut être utilisée pour gérer les ordinateurs distants sur utilisant la communication à distance PowerShell activée. Créez une session PSSession sur l’ordinateur distant, puis utilisez le paramètre PSSession pour Get-Module obtenir les modules PowerShell dans la session à distance. Lorsque vous importez un module à partir de la session distante, les commandes importées s’exécutent dans la session sur 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 pour Get-Module 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.

Exemples

Exemple 1 : Obtenir les modules importés dans la session active

Get-Module

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

Exemple 2 : Obtenir les modules installés et les modules disponibles

Get-Module -ListAvailable

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

Get-Module 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.

Exemple 3 : Obtenir tous les fichiers exportés

Get-Module -ListAvailable -All

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

Exemple 4 : Obtenir un module par son nom complet

$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

Cet exemple 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.

Dans un nom complet pour un module, la valeur ModuleVersion agit comme version minimale. Par conséquent, pour cet exemple, il correspond à n’importe quel module Microsoft.PowerShell.Management version 3.1.0.0 ou ultérieure.

Exemple 5 : Obtenir les propriétés d’un module

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.

Exemple 6 : Regrouper tous les modules par nom

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 d'afficher les fichiers de module exportés par chaque script.

Exemple 7 : Afficher le contenu d’un manifeste de module

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 manifeste fournissent souvent des informations utiles sur un module, ses spécifications 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 $m variable.

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.

Exemple 8 : Répertorier les fichiers dans le répertoire 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 que contient le module avant son importation. Certains modules peuvent avoir des fichiers d'aide ou des fichiers Lisez-moi qui décrivent le module.

Exemple 9 : Obtenir les modules installés sur un ordinateur

$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 New-PSSession de commande pour créer une session PSSession sur l’ordinateur Server01. La commande enregistre la session PSSession dans la $s variable.

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

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 Import-PSSession commande. Vous pouvez utiliser les applets de commande du module dans la session active, mais les commandes qui utilisent ces applets de commande s'exécutent en réalité dans la session à distance. Pour plus d’informations, consultez Import-Module et Import-PSSession.

Exemple 10 : Gérer un ordinateur qui n’exécute pas le système d’exploitation Windows

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, comme l'administrateur de l'ordinateur a installé le fournisseur WMI pour la découverte de module, les commandes CIM peuvent utiliser les valeurs par défaut, qui sont 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 Storage. La commande utilise un opérateur de pipeline (|) pour envoyer le module de stockage à l’applet Import-Module de commande, 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.

Paramètres

-All

Indique que cette applet de commande obtient tous les modules dans chaque dossier de module, y compris les modules imbriqués, les fichiers manifeste (.psd1), les fichiers de module de script (.psm1) et les fichiers de module binaire (.dll). Sans ce paramètre, Get-Module obtient uniquement le module par défaut dans chaque dossier de module.

Type:SwitchParameter
Position:Named
Valeur par défaut:False
Obligatoire:False
Accepter l'entrée de pipeline:False
Accepter les caractères génériques:False

-CimNamespace

Spécifie l'espace de noms d'un autre fournisseur CIM qui expose des modules CIM. La valeur par défaut est l'espace de noms du fournisseur WMI pour la découverte de module.

Utilisez ce paramètre pour obtenir des modules CIM à partir d’ordinateurs et d’appareils qui n’exécutent pas le système d’exploitation Windows.

Ce paramètre a été introduit dans Windows PowerShell 3.0.

Type:String
Position:Named
Valeur par défaut:None
Obligatoire:False
Accepter l'entrée de pipeline:False
Accepter les caractères génériques:False

-CimResourceUri

Spécifie un autre emplacement pour les modules CIM. La valeur par défaut est l'URI de ressource du fournisseur WMI pour la découverte de module sur l'ordinateur distant.

Utilisez ce paramètre pour obtenir des modules CIM à partir d’ordinateurs et d’appareils qui n’exécutent pas le système d’exploitation Windows.

Ce paramètre a été introduit dans Windows PowerShell 3.0.

Type:Uri
Position:Named
Valeur par défaut:None
Obligatoire:False
Accepter l'entrée de pipeline:False
Accepter les caractères génériques:False

-CimSession

Spécifie une session CIM sur l'ordinateur distant. Entrez une variable qui contient la session CIM ou une commande qui obtient la session CIM, telle qu’une commande Get-CimSession .

Get-Module utilise la connexion de session CIM pour obtenir des modules à partir de l’ordinateur distant. Lorsque vous importez le module à l’aide de l’applet Import-Module de commande et que vous utilisez les commandes du module importé dans la session active, les commandes s’exécutent réellement sur l’ordinateur distant.

Vous pouvez utiliser ce paramètre pour obtenir des modules à partir d’ordinateurs et d’appareils 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.

Le paramètre CimSession obtient tous les modules dans CIMSession. Toutefois, vous pouvez importer uniquement les modules CIM ou CDXML (Cmdlet Definition XML).

Type:CimSession
Position:Named
Valeur par défaut:None
Obligatoire:True
Accepter l'entrée de pipeline:False
Accepter les caractères génériques:False

-FullyQualifiedName

La valeur peut être un nom de module, une spécification complète du module ou un chemin d’accès à un fichier de module.

Lorsque la valeur est un chemin d’accès, le chemin d’accès peut être qualifié ou relatif complet. Un chemin relatif est résolu par rapport au script qui contient l’instruction using.

Lorsque la valeur est un nom ou une spécification de module, PowerShell recherche PSModulePath pour le module spécifié.

Une spécification de module est une table de hachage qui a les clés suivantes.

  • ModuleName - Obligatoire Spécifie le nom du module.
  • GUID - Facultatif Spécifie le GUID du module.
  • Il est également nécessaire de spécifier au moins l’une des trois clés ci-dessous.
    • ModuleVersion - Spécifie une version minimale acceptable du module.
    • MaximumVersion - Spécifie la version maximale acceptable du module.
    • RequiredVersion - Spécifie une version exacte et requise du module. Cela ne peut pas être utilisé avec les autres clés de version.

Vous ne pouvez pas spécifier le paramètre FullyQualifiedName dans la même commande qu’un paramètre Name .

Type:ModuleSpecification[]
Position:Named
Valeur par défaut:None
Obligatoire:False
Accepter l'entrée de pipeline:True
Accepter les caractères génériques:False

-ListAvailable

Indique que cette applet de commande obtient tous les modules installés. Get-Module obtient les modules dans les chemins répertoriés dans la variable d’environnement PSModulePath . Sans ce paramètre, Get-Module obtient uniquement les modules répertoriés dans la variable d’environnement PSModulePath et chargés dans la session active. ListAvailable ne retourne pas d’informations sur les modules qui ne sont pas trouvés dans la variable d’environnement PSModulePath , même si ces modules sont chargés dans la session active.

Type:SwitchParameter
Position:Named
Valeur par défaut:None
Obligatoire:False
Accepter l'entrée de pipeline:False
Accepter les caractères génériques:False

-Name

Spécifie les noms ou les modèles de noms des modules que cette applet de commande obtient. Les caractères génériques sont autorisés. Vous pouvez également diriger les noms vers Get-Module. Vous ne pouvez pas spécifier le paramètre FullyQualifiedName dans la même commande qu’un paramètre Name .

Le nom ne peut pas accepter un GUID de module comme valeur. Pour retourner des modules en spécifiant un GUID, utilisez FullyQualifiedName à la place.

Type:String[]
Position:0
Valeur par défaut:None
Obligatoire:False
Accepter l'entrée de pipeline:True
Accepter les caractères génériques:True

-PSEdition

Obtient les modules qui prennent en charge l’édition spécifiée de PowerShell.

Les valeurs valides pour ce paramètre sont :

  • Desktop
  • Core

L’applet Get-Module de commande vérifie la propriété CompatiblePSEditions de l’objet PSModuleInfo pour la valeur spécifiée et retourne uniquement les modules qu’il a définis.

Remarque

  • Édition Desktop : repose sur le .NET Framework et offre une compatibilité avec les scripts et les modules ciblant les versions de PowerShell exécutées sur les éditions complètes de Windows, telles que Server Core et Bureau Windows.
  • Core Edition : basée sur .NET Core, elle fournit la compatibilité avec les scripts et les modules qui ciblent des versions de PowerShell exécutées sur des éditions réduites de Windows telles que Nano Server et Windows IoT.
Type:String
Position:Named
Valeur par défaut:None
Obligatoire:False
Accepter l'entrée de pipeline:False
Accepter les caractères génériques:False

-PSSession

Obtient les modules de la session PowerShell gérée par l’utilisateur spécifiée (PSSession). Entrez une variable qui contient la session, une commande qui obtient la session, telle qu’une Get-PSSession commande ou une commande qui crée la session, telle qu’une New-PSSession commande.

Lorsque la session est connectée à un ordinateur distant, vous devez spécifier le paramètre ListAvailable .

Une Get-Module commande qui utilise le paramètre PSSession équivaut à utiliser l’applet Invoke-Command de commande pour exécuter une Get-Module -ListAvailable commande dans une session PSSession.

Ce paramètre a été introduit dans Windows PowerShell 3.0.

Type:PSSession
Position:Named
Valeur par défaut:None
Obligatoire:True
Accepter l'entrée de pipeline:False
Accepter les caractères génériques:False

-Refresh

Indique que cette applet de commande actualise le cache des commandes installées. Le cache de commande est créé au démarrage de la session. Elle permet à l’applet Get-Command de commande d’obtenir des commandes à partir de modules qui ne sont pas importés dans la session.

Ce paramètre est conçu pour le développement et les scénarios de test dans lesquels le contenu des modules a changé depuis le début de la session.

Lorsque vous spécifiez le paramètre Refresh dans une commande, vous devez spécifier ListAvailable.

Ce paramètre a été introduit dans Windows PowerShell 3.0.

Type:SwitchParameter
Position:Named
Valeur par défaut:False
Obligatoire:False
Accepter l'entrée de pipeline:False
Accepter les caractères génériques:False

Entrées

String

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

Sorties

PSModuleInfo

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.

Notes

Windows PowerShell inclut les alias suivants pour Get-Module:

  • gmo

  • À 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 Import-Module de commande pour les importer.

  • 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 distantes, telles que celles démarrées par l’applet New-PSSession de commande, 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écents avec des modules principaux, consultez La méthode CreateDefault2.

  • Get-Module obtient uniquement les modules dans des emplacements stockés dans la valeur de la variable d’environnement PSModulePath ($env:PSModulePath). L’applet Import-Module de commande peut importer des modules à d’autres emplacements, mais vous ne pouvez pas utiliser l’applet Get-Module de commande 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 les modules implémentés en tant que fichiers DLL, mais qui ne sont pas placés dans un dossier de module, spécifiez les paramètres ListAvailable et All .

  • Pour utiliser la fonctionnalité de session CIM, l'ordinateur distant doit disposer de l'accès distant WS-Management et de Windows Management Instrumentation (WMI), qui est l'implémentation Microsoft du modèle CIM (Common Information Model) standard. L'ordinateur doit également disposer du fournisseur WMI pour la découverte de module ou d'un autre fournisseur WMI ayant 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.