PowerShell, WMI et CIM pour l'automatisation avancée des systèmes Windows

Informatec Digital » Ressources » PowerShell, WMI et CIM pour l'automatisation avancée des systèmes Windows

Si vous administrez des systèmes Windows, vous serez tôt ou tard amené à utiliser PowerShell, WMI et l'automatisation avancée . Il ne s'agit pas simplement de savoir exécuter quelques commandes : lorsque vous gérez des dizaines, voire des centaines de serveurs, vous avez besoin d'une approche rigoureuse, structurée et sécurisée pour collecter les informations, appliquer les modifications et répéter les tâches sans perdre la tête… ni rien endommager.

Dans les lignes qui suivent, nous explorerons, avec calme mais précision, comment tirer parti de WMI, CIM et de la communication à distance PowerShell pour automatiser aussi bien les requêtes simples que les scénarios d'infrastructure complexes. Nous verrons également comment tout cela s'articule avec les modules, les tâches en arrière-plan, Azure, Microsoft 365 et certaines fonctionnalités avancées qui simplifient considérablement le travail quotidien d'un administrateur système.

Améliorations de PowerShell et aperçu de l'automatisation avancée

Windows PowerShell a beaucoup évolué depuis ses premières versions, et une grande partie de cette évolution est due à Windows Server 2012, qui a amélioré la communication à distance, étendu les cmdlets disponibles et simplifié des fonctionnalités telles que le débogage, les tâches en arrière-plan et les points de terminaison restreints afin d'améliorer la sécurité.

L'un des principes fondamentaux de cet environnement est de permettre aux administrateurs de créer des comportements similaires à ceux des cmdlets sans avoir à coder longuement , en tirant parti de fonctionnalités avancées, de modules réutilisables et d'un système d'aide complet. Ainsi, au lieu de s'appuyer sur des outils graphiques disparates, il est possible de créer un ensemble cohérent de scripts et de modules qui automatisent les processus de gestion des serveurs, des réseaux, d'Active Directory, d'Azure ou de Microsoft 365.

Dans le domaine de l'automatisation avancée, des fonctionnalités telles que les tâches permettant d'exécuter des tâches de manière asynchrone, les flux de travail, l'administration basée sur la configuration avec PowerShell DSC et les options de sécurité telles que JEA (Just Enough Administration) ou PowerShell Web Access se distinguent également, permettant un contrôle précis de ce que chaque personne peut faire et d'où.

Cet écosystème s'intègre particulièrement bien avec WMI et CIM, car les informations de gestion exposées par le système d'exploitation (matériel, services, processus , configuration réseau, logiciels installés, etc.) deviennent un ensemble d'objets que vous pouvez interroger, filtrer et modifier à l'aide de commandes PowerShell conçues pour l'automatisation de masse.

WMI et CIM : concepts clés et différences pratiques

Windows Management Instrumentation, plus connue sous le nom de WMI, est une technologie indépendante de PowerShell et intégrée à Windows depuis plusieurs années. Elle expose un référentiel d'informations de gestion concernant le système d'exploitation, le matériel et de nombreuses applications. Bien qu'elle ne dépende pas de PowerShell, ce dernier l'utilise largement pour automatiser des tâches.

Le successeur naturel de WMI dans l'écosystème PowerShell est constitué par les cmdlets CIM (Common Information Model) , introduites avec PowerShell 3.0. Ces cmdlets sont regroupées dans le module CimCmdlets et comprennent des commandes telles que Get-CimInstance, Get-CimClass, New-CimInstance, Invoke-CimMethod, Register-CimIndicationEvent, Set-CimInstance et Remove-CimInstance, entre autres.

Dans les anciennes versions de Windows PowerShell, telles que Windows 10 PowerShell 5.1 ou Windows 11 PowerShell, les cmdlets WMI classiques (Get-WmiObject, Invoke-WmiMethod, Register-WmiEvent, Remove-WmiObject, Set-WmiInstance) sont encore présentes. Cependant, ces cmdlets sont obsolètes et ne sont plus incluses dans PowerShell 6 et les versions ultérieures ; elles ne sont donc utiles que pour la maintenance de scripts existants ou la révision de code ancien.

Lorsqu'on parle d'« interroger WMI avec des cmdlets CIM », il n'y a pas de contradiction : les cmdlets CIM accèdent toujours aux informations WMI , mais elles utilisent des protocoles plus modernes comme WS-Man et une API plus cohérente. Concrètement, pour les nouveaux développements, il est préférable de privilégier CIM et de n'envisager les cmdlets WMI que pour les migrations ou la compréhension de scripts existants.

Historiquement, de nombreux administrateurs utilisaient VBScript avec le langage de requêtes WQL pour interroger WMI, par exemple en se connectant à l' espace de noms root\CIMV2 et en interrogeant des classes telles que Win32_BIOS. Cette même requête WQL peut être réutilisée aujourd'hui avec Get-CimInstance en passant le paramètre -Query, ce qui simplifie considérablement la transition de VBScript à PowerShell sans avoir à réécrire la logique.

Utilisation pratique de Get-CimInstance et requêtes efficaces

Pour les tâches quotidiennes, la méthode la plus naturelle pour interroger WMI avec PowerShell consiste à utiliser la commande Get-CimInstance avec le paramètre -ClassName , plutôt que d'écrire des requêtes WQL complètes. Par exemple, pour obtenir des informations sur le BIOS, vous pouvez utiliser Get-CimInstance -ClassName Win32_BIOS ; vous recevrez alors un objet contenant des propriétés telles que Manufacturer, Name, SerialNumber ou SMBIOSBIOSVersion.

Puisque tout est objet dans PowerShell, il est très facile de filtrer et de sélectionner uniquement ce dont vous avez besoin . Si seul le numéro de série vous intéresse, vous pouvez rediriger le résultat vers `Select-Object -Property SerialNumber`, ou utiliser `Select-Object -ExpandProperty SerialNumber` pour obtenir une simple chaîne de caractères au lieu d'un objet contenant une propriété. Une autre option courante consiste à utiliser la syntaxe pointée `(`Get-CimInstance ...`).SerialNumber`` pour accéder directement à la valeur.

Il est important de noter que, par défaut, les requêtes WMI renvoient plus de propriétés que nécessaire . Sur une machine locale, cela ne pose généralement pas de problème, mais lors de l'interrogation de nombreuses machines distantes, cela engendre un temps de traitement supplémentaire et un trafic réseau inutile. C'est là qu'intervient le paramètre `-Property` de `Get-CimInstance`, qui permet de limiter les propriétés récupérées de la source.

En spécifiant par exemple l'option `-Property SerialNumber`, vous réduisez la quantité de données transférées, ce qui rend la requête plus rapide et plus efficace, notamment à grande échelle . Cette approche, qui consiste à ne demander que ce dont vous avez besoin, est essentielle lors de la conception de scripts d'inventaire ou d'audit exécutés sur des dizaines, voire des centaines de machines.

En résumé, Get-CimInstance offre un équilibre puissant entre simplicité (une seule ligne de commande) et flexibilité , que vous travailliez avec des classes concrètes, des requêtes WQL héritées ou des propriétés spécifiques que vous souhaitez optimiser pour la récupération.

Consultations à distance avec CIM, sessions et protocoles WSMan/DCOM

Lorsque vous accédez à des machines distantes depuis votre ordinateur local, plusieurs facteurs entrent en jeu : les autorisations, le protocole de communication et les performances . Bien que beaucoup considèrent PowerShell comme « dangereux », il ne vous confère en réalité aucun privilège supplémentaire : vous disposez exactement des mêmes autorisations qu’avec l’interface graphique ou tout autre outil, ni plus ni moins.

Si vous tentez d'exécuter la commande `Get-CimInstance -ComputerName Server -ClassName Win32_BIOS` sans les privilèges suffisants sur cette machine, vous recevrez une erreur « Accès refusé » . Cela n'est pas dû à un dysfonctionnement de PowerShell ; l'utilisateur sous lequel vous exécutez la session ne dispose simplement pas des droits d'accès à ces informations dans WMI. Vous pouvez bien sûr ouvrir une console en tant qu'administrateur de domaine, mais cela signifie que toute commande sera exécutée avec ces privilèges, ce qui représente un risque inutile dans de nombreux environnements.

Il est recommandé d'appliquer le principe du moindre privilège et de n'élever les privilèges qu'en cas de nécessité . Dans les cmdlets prenant en charge le paramètre -Credential, vous pouvez spécifier des informations d'identification alternatives uniquement pour la commande concernée. Toutefois, Get-CimInstance n'accepte pas directement le paramètre -Credential ; c'est là que CimSessions s'avère une solution élégante.

Une session Cim est une connexion persistante à un ordinateur distant que vous pouvez créer avec la cmdlet New-CimSession, en spécifiant le nom de l'ordinateur et les informations d'identification (par exemple, New-CimSession -ComputerName dc01 -Credential (Get-Credential)). Cette session est stockée dans une variable, telle que $CimSession, puis réutilisée avec Get-CimInstance en remplaçant -ComputerName par le paramètre -CimSession, ce qui vous permet de regrouper plusieurs requêtes en une seule connexion.

Outre l'exigence d'authentification, Get-CimInstance utilise par défaut le protocole WSMan (basé sur WinRM) . Cela signifie que la machine distante doit disposer de la version 3.0 ou supérieure de la pile WSMan, généralement présente dans PowerShell 3.0 et versions ultérieures. Vous pouvez vérifier la version de la pile WSMan sur une machine avec `Test-WSMan -ComputerName RemoteComputer` et vous assurer que la valeur « Stack » est égale ou supérieure à 3.0 pour utiliser cette méthode de connexion.

Sessions CIM avec DCOM et rétrocompatibilité

Les anciennes cmdlets WMI basées sur Get-WmiObject utilisent le protocole DCOM, toujours pris en charge par les anciennes versions de Windows . Le problème est que, sur les systèmes plus récents, les pare-feu bloquent souvent DCOM par défaut, ce qui vous oblige à ouvrir des ports spécifiques pour l'utiliser, une opération qui peut enfreindre les politiques de sécurité de votre organisation.

Les cmdlets CIM offrent une solution intermédiaire performante : vous pouvez créer des options de session avec `New-CimSessionOption -Protocol Dcom` , les enregistrer dans une variable (par exemple, `$DCOM`), puis les combiner avec `New-CimSession` pour générer une session CimSession utilisant DCOM au lieu de WS-Man. Cela vous permet de vous connecter à des serveurs très anciens, même antérieurs à Windows Server 2000, sur lesquels PowerShell n'est pas installé.

Il est généralement pratique de stocker les informations d'identification d'administrateur de domaine ou celles d'un compte disposant de privilèges élevés dans une variable (par exemple, `$Cred = Get-Credential` ) afin d'éviter de les saisir à chaque fois. Ensuite, avec une commande comme `New-CimSession -ComputerName sql03 -SessionOption $DCOM -Credential $Cred`, vous pouvez démarrer une session CimSession via DCOM sur un serveur plus ancien qui ne prend pas en charge WS-Man mais qui dispose de WMI.

Du point de vue du développeur, l'avantage principal réside dans le fait que le résultat de `Get-CimInstance` reste inchangé quel que soit le protocole : les objets et propriétés obtenus sont identiques, que l'on utilise WS-Man ou DCOM. Cela simplifie considérablement la logique, car il est possible d'encapsuler la détection du protocole approprié dans une fonction et de garantir que le reste du code fonctionne toujours de manière transparente avec CimSessions.

En pratique, il est courant de créer des fonctions personnalisées qui testent WSMan avec Test-WSMan et, si celui-ci est indisponible, basculent automatiquement vers DCOM à l'aide de New-CimSessionOption. Cela permet de standardiser la création de sessions Cim dans des environnements mixtes, avec des serveurs modernes et anciens, sans avoir à dupliquer la logique de connexion dans tous vos scripts.

Gestion, référencement et nettoyage des sessions CimSessions

Lorsque vous utilisez fréquemment CimSessions, il est important de les gérer afin d'éviter l'accumulation de connexions inutiles. La commande Get-CimSession permet de lister toutes les sessions ouvertes , d'identifier la machine cible et de vérifier le protocole utilisé (WSMAN ou DCOM), ce qui s'avère très utile pour diagnostiquer les problèmes de connectivité ou d'authentification.

Vous pouvez également récupérer ces sessions existantes dans une variable, par exemple $CimSession = Get-CimSession , et les utiliser dans une seule commande Get-CimInstance -CimSession $CimSession -ClassName Win32_BIOS pour interroger plusieurs ordinateurs à la fois, en combinant les sessions WSMan et DCOM dans la même opération.

Une fois l'analyse des informations terminée, il est conseillé de fermer les sessions afin d'éviter de laisser des ressources ouvertes inutilement. La cmdlet Get-CimSession | Remove-CimSession supprime simultanément toutes les sessions Cim actives du profil courant. Vous pouvez également spécifier des sessions à fermer avec la cmdlet Remove-CimSession afin d'en fermer seulement quelques-unes.

Cette méthode de travail vous permet de contrôler les cycles de connexion et de déconnexion , ce qui est fortement recommandé lors de l'utilisation de scripts dans des tâches planifiées, des manuels d'exécution d'automatisation ou des pipelines d'intégration continue qui peuvent laisser des sessions ouvertes si vous ne prévoyez pas explicitement ce nettoyage.

PowerShell en tant que langage d'automatisation complet

Au-delà de WMI et CIM, PowerShell est devenu un langage d'automatisation généraliste qui dépasse largement le cadre des scripts d'administration Windows classiques. Des livres et des formations complètes sont consacrés à ses fonctionnalités avancées, abordant tous les aspects, de l'installation sous Linux et Windows au développement de modules distribuables via NuGet, en passant par les environnements de développement modernes comme Visual Studio Code.

Pour commencer, il est essentiel de bien maîtriser les fonctionnalités avancées de PowerShell , qui permettent de définir des paramètres, d'effectuer des validations, de générer des sorties structurées et d'accéder à une aide intégrée quasiment au niveau d'une cmdlet native. Ensuite, l'organisation du code en modules facilite le travail collaboratif au sein des équipes d'exploitation, car il est possible de versionner et de publier ces modules sur des dépôts NuGet internes ou publics.

L'utilisation d'objets et de classes personnalisés est également essentielle , ouvrant la voie à des modèles de données bien plus riches que les scripts linéaires classiques. Cela vous permet d'encapsuler la logique métier, de réutiliser des structures et de concevoir des API internes pour votre équipe de direction, le tout grâce au moteur PowerShell.

Dans le domaine de l'automatisation avancée, les tâches et les flux de travail en arrière-plan jouent un rôle crucial . Ils permettent la gestion des tâches asynchrones, l'exécution d'opérations longues sans bloquer la console et l'orchestration de séquences complexes sur plusieurs machines. Ces fonctionnalités sont parfaitement adaptées aux requêtes massives adressées à WMI/CIM et aux scénarios d'administration à distance, où il est souvent nécessaire d'attendre que les systèmes prennent en compte les modifications ou renvoient des données.

Un autre élément clé est PowerShell DSC (Desired State Configuration), qui permet de définir la configuration souhaitée d'une infrastructure (rôles, fonctionnalités, services, fichiers, paramètres de sécurité, etc.) et d'appliquer ces états de manière répétée. Combiné aux informations obtenues via WMI/CIM, il permet de détecter les écarts, de les corriger proactivement et de maintenir des environnements cohérents avec un minimum d'intervention manuelle.

Gestion locale, distante et dans le cloud avec PowerShell

Au niveau local, PowerShell propose des cmdlets pour la gestion des services de domaine Active Directory , la configuration des réseaux et l'administration des serveurs. Sous Windows 10 et versions ultérieures, l'intégration est encore plus poussée, permettant d'automatiser de nombreuses tâches, de la création de sites web à la gestion des objets Active Directory et à la configuration des cartes réseau.

Un composant moins connu mais très utile est PSProviders et PSDrives , qui permettent de traiter différents emplacements de stockage (système de fichiers, registre, Active Directory, etc.) comme s'il s'agissait de lecteurs accessibles. Grâce à cela, vous pouvez, par exemple, créer des groupes Active Directory, des clés de registre ou des arborescences de dossiers sur des ordinateurs distants en utilisant la même syntaxe que pour naviguer sur le disque dur.

En matière d'administration à distance, PowerShell intègre un ensemble de fonctionnalités performantes permettant de se connecter à un ou plusieurs ordinateurs et d'exécuter des commandes en votre nom . Vous pouvez utiliser des sessions PSSession persistantes, des techniques d'accès à distance avancées, des scénarios un-à-plusieurs (pour gérer plusieurs serveurs simultanément) ou des scénarios un-à-un pour le débogage de cas spécifiques. Le tout, bien entendu, dans le respect de l'architecture et du modèle de sécurité de l'accès distant.

Le cloud joue aujourd'hui un rôle fondamental. Grâce à Azure PowerShell et Azure Cloud Shell, vous pouvez gérer les machines virtuelles, le stockage et les abonnements directement depuis la ligne de commande. L'installation des modules Azure PowerShell et leur maîtrise sont quasiment indispensables pour la gestion d'environnements hybrides ou entièrement hébergés sur Azure.

Par ailleurs, PowerShell s'est également imposé comme un outil incontournable pour la gestion de Microsoft 365 (Exchange Online, SharePoint Online, Teams, utilisateurs et licences). De la création et la gestion des comptes à l'administration des ressources Exchange Online, notamment les groupes, les sites SharePoint et Microsoft Teams, tout peut être orchestré à l'aide de scripts qui réduisent considérablement les interventions manuelles sur le portail web.

Scripting, pipelines et meilleures pratiques de travail

Pour tirer pleinement parti de l'automatisation avancée avec WMI et CIM, il est essentiel de maîtriser le modèle de pipeline de PowerShell . Contrairement à d'autres interpréteurs de commandes, PowerShell ne transmet pas de texte brut, mais des objets complets, ce qui permet de sélectionner, trier, mesurer, filtrer, énumérer et transformer les informations avec une grande précision.

L'apprentissage des pipelines implique la maîtrise des cmdlets de sélection et de filtrage , la compréhension de l'énumération d'objets complexes et la capacité à transmettre des données entre commandes et scripts sans perte d'information. Cette maîtrise est renforcée par l'utilisation structurée de variables, de tableaux et de tables de hachage, qui servent de structures de données temporaires permettant de construire une logique plus avancée.

L'étape suivante consiste à automatiser le processus : regrouper les commandes dans des scripts réutilisables avec des structures de contrôle de flux (if, for, foreach), importer des données à partir de fichiers CSV ou d'autres formats, gérer les entrées utilisateur, la gestion des erreurs et la journalisation des événements. Tout cela permet de passer de commandes isolées à des outils intégrés plus robustes.

Le dépannage et la gestion des erreurs sont essentiels dans les environnements d'automatisation à grande échelle utilisant WMI/CIM. En effet, une panne réseau, une autorisation mal configurée ou une classe manquante peuvent interrompre un processus si elles ne sont pas correctement gérées. Grâce aux blocs try/catch, aux actions d'erreur configurables et à une journalisation détaillée, vous pouvez anticiper ces situations et y réagir plus efficacement.

Enfin, tout ce qui concerne les fonctions et les modules boucle la boucle : vous signez les scripts pour garantir leur intégrité, vous regroupez les fonctions en modules, vous distribuez ces modules dans des référentiels internes ou publics et vous créez un écosystème d’outils partagés au sein de votre organisation. Ainsi, tout nouveau développement sur WMI, CIM ou la communication à distance est intégré dans une suite cohérente et facile à maintenir.

En combinant tous les éléments mentionnés ci-dessus (WMI/CIM, sessions à distance, scripts, tâches asynchrones, DSC, Azure et Microsoft 365), vous obtenez un environnement où l'automatisation avancée avec PowerShell devient le cœur de l'administration. Grâce à une base solide de bonnes pratiques, une utilisation judicieuse de CimSessions (avec WSMan et DCOM) et une conception modulaire des scripts, vous pouvez gérer des infrastructures hétérogènes de manière cohérente, sécurisée et bien plus efficace qu'en vous appuyant uniquement sur des assistants graphiques ou des outils isolés.