Partager via


Chapitre 7 - Utilisation de WMI

WMI et CIM

Windows PowerShell est fourni par défaut avec des applets de commande pour travailler avec d’autres technologies, telles que Windows Management Instrumentation (WMI). Les applets de commande WMI sont déconseillées et ne sont pas disponibles dans PowerShell 6+, mais elles sont abordées ici, car vous pouvez les rencontrer dans des scripts plus anciens s’exécutant sur Windows PowerShell. Pour le nouveau développement, utilisez plutôt les applets de commande CIM.

Plusieurs applets de commande WMI natives existent dans PowerShell sans avoir à installer d’autres logiciels ou modules. Get-Command peut être utilisé pour déterminer les applets de commande WMI qui existent dans Windows PowerShell. Les résultats suivants proviennent d’un système Windows 11 exécutant PowerShell version 5.1. Vos résultats peuvent différer selon la version de PowerShell que vous exécutez.

Get-Command -Noun WMI*
CommandType     Name                                               Version
-----------     ----                                               -------
Cmdlet          Get-WmiObject                                      3.1.0.0
Cmdlet          Invoke-WmiMethod                                   3.1.0.0
Cmdlet          Register-WmiEvent                                  3.1.0.0
Cmdlet          Remove-WmiObject                                   3.1.0.0
Cmdlet          Set-WmiInstance                                    3.1.0.0

Les applets de commande CIM (Common Information Model) ont été introduites dans PowerShell 3.0 et sont regroupées dans un module dédié. Pour répertorier toutes les applets de commande CIM disponibles, utilisez l’applet Get-Command de commande avec le paramètre Module , comme illustré dans l’exemple suivant.

Get-Command -Module CimCmdlets
CommandType     Name                                               Version
-----------     ----                                               -------
Cmdlet          Export-BinaryMiLog                                 1.0.0.0
Cmdlet          Get-CimAssociatedInstance                          1.0.0.0
Cmdlet          Get-CimClass                                       1.0.0.0
Cmdlet          Get-CimInstance                                    1.0.0.0
Cmdlet          Get-CimSession                                     1.0.0.0
Cmdlet          Import-BinaryMiLog                                 1.0.0.0
Cmdlet          Invoke-CimMethod                                   1.0.0.0
Cmdlet          New-CimInstance                                    1.0.0.0
Cmdlet          New-CimSession                                     1.0.0.0
Cmdlet          New-CimSessionOption                               1.0.0.0
Cmdlet          Register-CimIndicationEvent                        1.0.0.0
Cmdlet          Remove-CimInstance                                 1.0.0.0
Cmdlet          Remove-CimSession                                  1.0.0.0
Cmdlet          Set-CimInstance                                    1.0.0.0

Les applets de commande CIM vous permettent toujours d’utiliser WMI. Par conséquent, ne vous confondez pas lorsque quelqu’un indique : « Quand j’interroge WMI avec les applets de commande CIM PowerShell ».

Comme mentionné précédemment, WMI est une technologie distincte de PowerShell et vous utilisez simplement les applets de commande CIM pour accéder à WMI. Vous trouverez peut-être un ancien VBScript qui utilise WMI Query Language (WQL) pour interroger WMI, comme dans l’exemple suivant.

strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\CIMV2")

Set colBIOS = objWMIService.ExecQuery _
    ("Select * from Win32_BIOS")

For each objBIOS in colBIOS
    Wscript.Echo "Manufacturer: " & objBIOS.Manufacturer
    Wscript.Echo "Name: " & objBIOS.Name
    Wscript.Echo "Serial Number: " & objBIOS.SerialNumber
    Wscript.Echo "SMBIOS Version: " & objBIOS.SMBIOSBIOSVersion
    Wscript.Echo "Version: " & objBIOS.Version
Next

Vous pouvez utiliser la requête WQL à partir de VBScript et l’utiliser avec l’applet Get-CimInstance de commande sans aucune modification.

Get-CimInstance -Query 'Select * from Win32_BIOS'
SMBIOSBIOSVersion : 090006
Manufacturer      : American Megatrends Inc.
Name              : Intel(R) Xeon(R) CPU E3-1505M v5 @ 2.80GHz
SerialNumber      : 3810-1995-1654-4615-2295-2755-89
Version           : VRTUAL - 4001628

L’exemple précédent n’est pas la façon dont j’interroge généralement WMI avec PowerShell. Mais il fonctionne et vous permet de migrer facilement des scripts Visual Basic existants vers PowerShell. Lors de l’écriture d’un liner pour interroger WMI, j’utilise la syntaxe suivante.

Get-CimInstance -ClassName Win32_BIOS
SMBIOSBIOSVersion : 090006
Manufacturer      : American Megatrends Inc.
Name              : Intel(R) Xeon(R) CPU E3-1505M v5 @ 2.80GHz
SerialNumber      : 3810-1995-1654-4615-2295-2755-89
Version           : VRTUAL - 4001628

Si vous souhaitez uniquement le numéro de série, dirigez la sortie vers Select-Object et spécifiez uniquement la propriété SerialNumber .

Get-CimInstance -ClassName Win32_BIOS |
    Select-Object -Property SerialNumber
SerialNumber
------------
3810-1995-1654-4615-2295-2755-89

Par défaut, lors de l’interrogation de WMI, plusieurs propriétés qui ne sont jamais utilisées sont récupérées en arrière-plan. Cela n’a pas beaucoup d’importance lors de l’interrogation de WMI sur l’ordinateur local. Mais une fois que vous commencez à interroger des ordinateurs distants, il ne s'agit pas seulement de temps de traitement supplémentaire pour renvoyer ces informations, mais aussi d'envoyer des informations inutiles sur le réseau. Get-CimInstance a un paramètre Property qui limite les informations récupérées, ce qui rend la requête WMI plus efficace.

Get-CimInstance -ClassName Win32_BIOS -Property SerialNumber |
    Select-Object -Property SerialNumber
SerialNumber
------------
3810-1995-1654-4615-2295-2755-89

Les résultats précédents ont retourné un objet. Pour retourner une chaîne, utilisez le paramètre ExpandProperty .

Get-CimInstance -ClassName Win32_BIOS -Property SerialNumber |
    Select-Object -ExpandProperty SerialNumber
3810-1995-1654-4615-2295-2755-89

Vous pouvez également utiliser le style de syntaxe en pointillés pour renvoyer une chaîne, éliminant la nécessité de diriger vers Select-Object.

(Get-CimInstance -ClassName Win32_BIOS -Property SerialNumber).SerialNumber
3810-1995-1654-4615-2295-2755-89

Interroger des ordinateurs distants avec les cmdlets CIM

Vous devez toujours exécuter PowerShell en tant qu’administrateur local et utilisateur de domaine. Lorsque vous essayez d’interroger des informations à partir d’un ordinateur distant à l’aide de l’applet Get-CimInstance de commande, vous recevez un message d’erreur d’accès refusé.

Get-CimInstance -ComputerName dc01 -ClassName Win32_BIOS
Get-CimInstance : Access is denied.
At line:1 char:1
+ Get-CimInstance -ComputerName dc01 -ClassName Win32_BIOS
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : PermissionDenied: (root\cimv2:Win32_BIOS:Stri
   ng) [Get-CimInstance], CimException
    + FullyQualifiedErrorId : HRESULT 0x80070005,Microsoft.Management.Infra
   structure.CimCmdlets.GetCimInstanceCommand
    + PSComputerName        : dc01

De nombreuses personnes ont des problèmes de sécurité concernant PowerShell, mais vous disposez des mêmes autorisations dans PowerShell que dans l’interface utilisateur graphique. Ni plus ni moins. Le problème dans l’exemple précédent est que l’utilisateur exécutant PowerShell n’a pas les droits d’interroger les informations WMI à partir du serveur DC01. Vous pouvez relancer PowerShell en tant qu’administrateur de domaine, Get-CimInstance n'ayant pas de paramètre d'identification. Mais ce n’est pas une bonne idée, car tout ce que vous exécutez à partir de PowerShell s’exécuterait en tant qu’administrateur de domaine. Selon la situation, ce scénario pourrait être dangereux du point de vue de la sécurité.

En utilisant le principe des privilèges minimum, élever vers votre compte d’administrateur de domaine par commande à l’aide du paramètre Credential si une commande en a une. Get-CimInstance n’a pas de paramètre Credential. Par conséquent, la solution à ce scénario consiste à créer une CimSession en premier. Ensuite, utilisez CimSession au lieu d’un nom d’ordinateur pour interroger WMI sur l’ordinateur distant.

$CimSession = New-CimSession -ComputerName dc01 -Credential (Get-Credential)
cmdlet Get-Credential at command pipeline position 1
Supply values for the following parameters:
Credential

La session CIM a été stockée dans une variable nommée $CimSession. Notez que vous spécifiez également l’applet Get-Credential de commande entre parenthèses afin qu’elle s’exécute en premier, en demandant d’autres informations d’identification, avant de créer la nouvelle session. Je vous montre un autre moyen plus efficace de spécifier d’autres informations d’identification plus loin dans ce chapitre, mais il est important de comprendre ce concept de base avant de le rendre plus compliqué.

Vous pouvez maintenant utiliser la session CIM créée dans l’exemple précédent avec l’applet Get-CimInstance de commande pour interroger les informations du BIOS à partir de WMI sur l’ordinateur distant.

Get-CimInstance -CimSession $CimSession -ClassName Win32_BIOS
SMBIOSBIOSVersion : 090006
Manufacturer      : American Megatrends Inc.
Name              : Intel(R) Xeon(R) CPU E3-1505M v5 @ 2.80GHz
SerialNumber      : 0986-6980-3916-0512-6608-8243-13
Version           : VRTUAL - 4001628
PSComputerName    : dc01

Il existe plusieurs autres avantages à utiliser des sessions CIM au lieu de spécifier simplement un nom d’ordinateur. Lorsque vous exécutez plusieurs requêtes sur le même ordinateur, l’utilisation d’une session CIM est plus efficace que l’utilisation du nom de l’ordinateur pour chaque requête. La création d’une session CIM configure uniquement la connexion une seule fois. Ensuite, plusieurs requêtes utilisent cette même session pour récupérer des informations. L’utilisation du nom de l’ordinateur nécessite que les applets de commande configurent et suppriment la connexion avec chaque requête.

L’applet Get-CimInstance de commande utilise le protocole WSMan par défaut, ce qui signifie que l’ordinateur distant a besoin de PowerShell version 3.0 ou ultérieure pour se connecter. En fait, ce n’est pas la version PowerShell qui importe, c’est la version de pile. La version de la pile peut être déterminée à l’aide du cmdlet Test-WSMan. Il doit s’agir de la version 3.0, que vous trouvez avec PowerShell version 3.0 et ultérieure.

Test-WSMan -ComputerName dc01
wsmid           : http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentit
                  y.xsd
ProtocolVersion : http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
ProductVendor   : Microsoft Corporation
ProductVersion  : OS: 0.0.0 SP: 0.0 Stack: 3.0

Les applets de commande WMI plus anciennes utilisent le protocole DCOM, qui est compatible avec les versions antérieures de Windows. Toutefois, le pare-feu bloque généralement DCOM sur les versions plus récentes de Windows. L’applet New-CimSessionOption de commande vous permet de créer une connexion de protocole DCOM à utiliser avec New-CimSession. Cette option permet à l’applet Get-CimInstance de commande de communiquer avec les versions de Windows aussi anciennes que Windows Server 2000. Cette capacité signifie également que PowerShell n’est pas obligatoire sur l’ordinateur distant lors de l’utilisation de l’applet Get-CimInstance de commande avec un CimSession configuré pour utiliser le protocole DCOM.

Créez l’option de protocole DCOM à l’aide de l’applet de commande et stockez-la New-CimSessionOption dans une variable.

$DCOM = New-CimSessionOption -Protocol Dcom

Pour plus d’efficacité, vous pouvez stocker votre administrateur de domaine ou des informations d’identification élevées dans une variable afin de ne pas avoir à les entrer constamment pour chaque commande.

$Cred = Get-Credential
cmdlet Get-Credential at command pipeline position 1
Supply values for the following parameters:
Credential

J’ai un serveur nommé SQL03 qui exécute Windows Server 2008 (non-R2). Il s’agit du système d’exploitation Windows Server le plus récent sur lequel PowerShell n’est pas installé par défaut.

Créez une session CimSession sur SQL03 à l’aide du protocole DCOM.

$CimSession = New-CimSession -ComputerName sql03 -SessionOption $DCOM -Credential $Cred

Notez que dans la commande précédente, vous spécifiez la variable nommée $Cred comme valeur du paramètre Credential au lieu d’entrer manuellement vos informations d’identification à nouveau.

La sortie de la requête est la même, quel que soit le protocole sous-jacent.

Get-CimInstance -CimSession $CimSession -ClassName Win32_BIOS
SMBIOSBIOSVersion : 090006
Manufacturer      : American Megatrends Inc.
Name              : Intel(R) Xeon(R) CPU E3-1505M v5 @ 2.80GHz
SerialNumber      : 7237-7483-8873-8926-7271-5004-86
Version           : VRTUAL - 4001628
PSComputerName    : sql03

L’applet Get-CimSession de commande est utilisée pour voir quelles CimSessions sont actuellement connectées et quels protocoles elles utilisent.

Get-CimSession
Id           : 1
Name         : CimSession1
InstanceId   : 80742787-e38e-41b1-a7d7-fa1369cf1402
ComputerName : dc01
Protocol     : WSMAN

Id           : 2
Name         : CimSession2
InstanceId   : 8fcabd81-43cf-4682-bd53-ccce1e24aecb
ComputerName : sql03
Protocol     : DCOM

Récupérez et stockez les CimSessions précédemment créées dans une variable nommée $CimSession.

$CimSession = Get-CimSession

Interrogez les deux ordinateurs avec une commande, l’un à l’aide du protocole WSMan et l’autre avec DCOM.

Get-CimInstance -CimSession $CimSession -ClassName Win32_BIOS
SMBIOSBIOSVersion : 090006
Manufacturer      : American Megatrends Inc.
Name              : Intel(R) Xeon(R) CPU E3-1505M v5 @ 2.80GHz
SerialNumber      : 0986-6980-3916-0512-6608-8243-13
Version           : VRTUAL - 4001628
PSComputerName    : dc01

SMBIOSBIOSVersion : 090006
Manufacturer      : American Megatrends Inc.
Name              : Intel(R) Xeon(R) CPU E3-1505M v5 @ 2.80GHz
SerialNumber      : 7237-7483-8873-8926-7271-5004-86
Version           : VRTUAL - 4001628
PSComputerName    : sql03

L’un de mes articles de blog sur les applets de commande WMI et CIM propose une fonction PowerShell qui détecte automatiquement s’il faut utiliser WSMan ou DCOM, puis configurer la session CIM appropriée pour vous. Pour plus d’informations, consultez Fonction PowerShell pour créer des CimSessions vers des ordinateurs distants avec repli sur Dcom.

Une fois les sessions CIM terminées, supprimez-les avec le cmdlet Remove-CimSession. Pour supprimer toutes les sessions CIM, dirigez Get-CimSession vers Remove-CimSession.

Get-CimSession | Remove-CimSession

Résumé

Dans ce chapitre, vous avez appris à utiliser PowerShell pour utiliser WMI sur des ordinateurs locaux et distants. Vous avez également appris à utiliser les applets de commande CIM pour travailler avec des ordinateurs distants à l’aide des protocoles WSMan et DCOM.

Révision

  1. Quelle est la différence entre les applets de commande WMI et CIM ?
  2. Par défaut, quel protocole le cmdlet Get-CimInstance utilise-t-il ?
  3. Quels sont les avantages de l’utilisation d’une session CIM au lieu de spécifier un nom d’ordinateur avec Get-CimInstance?
  4. Comment spécifier un autre protocole que celui par défaut avec Get-CimInstancelequel utiliser ?
  5. Comment fermer ou supprimer des sessions CIM ?

références