27Aug
WMI et son nouveau frère CIM peuvent tous deux être utilisés pour gérer les machines Windows dans votre environnement. Mais connaissez-vous la différence entre eux? Rejoignez-nous comme nous jetons un coup d'oeil.
Assurez-vous de lire les articles précédents de la série:
- Apprenez à automatiser Windows avec PowerShell
- Apprendre à utiliser des applets de commande dans PowerShell
- Apprentissage de l'utilisation des objets dans PowerShell
- Formattage, filtrage et comparaison dans PowerShell
- Apprenez à utiliser Remoting dans PowerShellPowerShell
Et restez à l'écoute pour le reste de la série toute la semaine.
Introduction
WMI signifie Windows Management Instrumentation. Le mot "Instrumentation" fait référence au fait que WMI vous permet d'obtenir des informations sur l'état interne de votre ordinateur, tout comme les instruments de tableau de bord de votre voiture peuvent récupérer et afficher des informations sur l'état de vos composants internes.
WMI se compose d'un référentiel qui contient des classes représentant les composants pouvant être gérés dans votre machine. Par ce que nous entendons juste parce que WMI a une classe Win32_Battery ne signifie pas que votre machine contient une batterie. Ces classes peuvent ensuite être interrogées pour obtenir des informations localement ou même à travers un réseau en utilisant un langage de requête très similaire à SQL appelé WQL.Cependant, WMI a été connu pour être très peu fiable, principalement en raison du fait qu'il est basé sur RPC( Remote Procedure Calls), qui font des choses folles avec les ports sur lesquels ils choisissent de communiquer.
Depuis Windows 8 et Server 2012, WMI est progressivement abandonné en faveur du Common Information Model ou CIM.La seule différence entre WMI et CIM réside dans les protocoles de transport utilisés. Alors que WMI effectue des requêtes à l'aide d'appels de procédure distante, CIM utilise HTTP, ce qui semble faire une énorme différence. Sur le backend, ils parlent toujours au même référentiel d'informations.
Utilisation de WMI
La manière la plus rapide et la plus simple d'explorer les informations disponibles via WMI consiste à récupérer une copie de tout explorateur d'objets WMI gratuit. Nous aimons celui-ci. Une fois téléchargé, lancez-le et vous aurez une interface graphique pour parcourir les classes WMI.
Si vous souhaitez obtenir des informations sur la configuration du disque d'un ordinateur, appuyez sur la combinaison de touches Ctrl + F pour faire apparaître un champ de recherche, puis tapez "logicaldisk" et appuyez sur Entrée.
Immédiatement cela vous amènera à la classe Win32_LogicalDisk.
Sur la moitié inférieure de l'application, vous pouvez voir que nous avons deux instances de la classe.
Une fois que nous avons la classe que nous recherchons, l'interroger depuis PowerShell est simple.
Get-WmiObject -Query "SELECT * FROM Win32_LogicalDisk"
Je n'ai pas vu cette syntaxe depuis quelques temps avec les gens qui préfèrent utiliser la nouvelle syntaxe paramétrée.
Get-WmiObject -Class Win32_LogicalDisk
Si vous souhaitez obtenir les informations d'un autre ordinateur sur votre réseau, vous pouvez simplement utiliser le paramètre ComputerName.
Get-WmiObject -Class Win32_LogicalDisk -ComputerName Viper -Credential viper \ administrateur
Utilisation de CIM
En gardant à l'esprit que CIM est seulement disponible sur Windows 8 et Server 2012, aller de l'avant c'est définitivement la voie à suivre.
Get-CimInstance -ClassName Win32_LogicalDisk
Le paramètre -ClassName comporte également une tabulation lors de l'utilisation de Get-CimInstance, ce qui montre que les efforts de Microsoft seront concentrés dans l'avenir.
En fait, WMI a été développé par une équipe complètement distincte au sein de Microsoft, mais a ensuite été repris par les gens en charge de PowerShell. Ce sont eux qui ont remarqué qu'il serait très difficile de nettoyer les dégâts laissés par WMI.Pour tenter de remédier à la situation, ils essaient de rendre WMI et CIM plus accessibles en écrivant des cmdlets wrapper qui utilisent WMI et CIM sous le capot. La seule façon de vérifier si une cmdlet est un wrapper est en consultant la documentation. Par exemple, la cmdlet Get-Hotfix est un wrapper pour la classe Win32_QuickFixEngineering, comme indiqué dans la documentation.
Cela signifie que vous pouvez obtenir les correctifs sur des ordinateurs distants à l'aide de la cmdlet Get-HotFix au lieu d'une requête WMI.
Get-HotFix -ComputerName localhost
Alors là vous l'avez. N'oubliez pas que s'il existe une applet de commande dédiée, vous souhaiterez toujours l'utiliser, suivie par CIM si une cmdlet n'existe pas. Enfin, si tout le reste échoue, ou si vous avez d'anciennes machines dans votre environnement, vous voudrez utiliser WMI.C'est tout ce que j'ai pour cette fois.À demain pour plus de plaisir avec PowerShell.