CIM / WMI

Introduction

Le titre de ce chapitre ne vous dit probablement pas grand-chose excepté peut-être les trois lettres que sont WMI et qui signifient Windows Management Instrumentation. WMI est bien connu des administrateurs systèmes Microsoft car cette technologie permet à la fois de collecter des informations matérielles mais aussi d’agir sur toute ou partie d’un système d’exploitation, ainsi que sur certaines applications dans le monde Windows. Cette technologie a été conçue de façon à pouvoir s’utiliser localement ou à distance avec la même facilité.

WMI a été la technologie de choix durant de nombreuses années pour la gestion de matériels et logiciels en réseau, mais elle cède progressivement sa place à la technologie CIM. Il est peut-être maladroit de dire cela car WMI s’appuie déjà largement sur CIM, CIM étant plutôt une norme (ou standard) ouverte qu’une technologie. CIM est l’acronyme de Common Information Model.

Ce chapitre vous donnera seulement un aperçu de ce que l’on peut faire en termes de gestion distribuée. Ces technologies sont si vastes qu’elles ont donné naissance à quelques épais ouvrages... Tout au long de ce chapitre, nous nous efforcerons d’aller à l’essentiel afin que vous puissiez...

Des standards, encore des standards, mais pour quoi faire ?

La collecte de données pour gérer un environnement particulier est importante, mais elle ne constitue qu’une petite partie du problème de gestion plus global en entreprise. Un autre effort important porte sur la normalisation et l’organisation des données. Par exemple, une personne sait que « bon », « fonctionnel », « opérationnel » et « en état de marche » sont tous des synonymes d’un statut « OK ». Mais comment un programme informatique le sait-il ? Pire encore, comment est-ce que le programme sait où trouver l’information qu’il cherche ?

Le problème ne s’arrête cependant pas avec la détermination de l’emplacement et la sémantique. En effet, il y a un besoin grandissant de gouvernance du système d’information en termes métiers. Ainsi, aussi anodine soit-elle, la panne d’un ventilateur sur un matériel (un processeur, par exemple) peut avoir des conséquences importantes. Il est donc capital d’être en mesure de déterminer quels sont les risques métiers exprimés en termes de services.

La gestion de bout en bout à travers de multiples composants au sein d’un environnement distribué est une réalité qui tend à devenir un pré-requis. Il n’est plus suffisant de gérer individuellement les postes de travail, les serveurs, les éléments actifs réseau, les baies de stockage, les hyperviseurs, etc. Tous ces composants interagissent entre eux afin de fournir des services globaux. L’information passe à travers toutes ces technologies. La gestion doit donc également passer à travers toutes ces couches. Là...

Architecture générale et terminologie

L’architecture CIM/WMI se décompose en trois couches comme dans le schéma suivant :

Architecture CIM/WMI

Consommateur CIM/WMI est le terme générique pour désigner une application cliente faisant appel à CIM/WMI. Cela peut être simplement un script, un outil d’administration, ou bien encore une application d’entreprise telle que Microsoft System Center Configuration Manager.

Une ressource gérée peut être n’importe quel composant physique ou logique administrable via CIM/WMI. Cela peut être tout composant du système d’exploitation tel que le sous-système disque, les journaux des événements, la base de registre, les services, les processus, etc. La liste est vraiment très longue, c’est incroyable tout ce qui peut être géré !

Une ressource gérée dialogue avec l’infrastructure CIM/WMI exclusivement au travers d’un fournisseur. Chaque ressource ou plutôt chaque classe de ressources est décrite dans un fichier texte au format MOF (Managed Object Format). Un tel fichier contient toutes les propriétés, méthodes et autres informations utiles qui décrivent tout ce qu’il est possible de faire sur une ressource gérée au travers de CIM/WMI.

Afin d’être utilisable par l’infrastructure CIM/WMI, un fichier MOF doit être compilé....

Commandes de la famille CIM

Commandes de la famille WMI

Vous l’aurez compris tout au long de ce chapitre, depuis la sortie PowerShell 3, le jeu de commandes WMI est tombé en désuétude au profit des commandes de la famille CIM. Microsoft ne le fera plus évoluer, et au mieux le maintiendra encore quelque temps. Les commandes de cette famille n’ont donc pas évolué par rapport à la version précédente de PowerShell.

Comme nous vous le disions, ces commandes ne font pas partie de PowerShell Core. Donc si vous les utilisez dans un script, sachez que celui-ci ne pourra pas s’exécuter sur PowerShell Core.

La famille des commandes WMI se résume aux cinq commandes suivantes :

Chacune de ces commandes de la famille WMI possède un équivalent dans la famille CIM. Nous avons, pour mémoire, ajouté au tableau ci-dessus la colonne Équivalent CIM afin de vous aider dans la transition si vous devez convertir d’anciens scripts.

La commande la plus utilisée parmi ce jeu est incontestablement Get-WmiObject. Celle-ci, à la différence de son équivalent CIM Get-CimInstance, retourne des objets bien « vivants » c’est-à-dire possédant des propriétés et des méthodes, méthodes sur les instances desquelles on peut agir.

Cela n’est plus possible avec le jeu de commandes CIM, et ce pour la simple et bonne raison que les objets sont sérialisés et désérialisés entre le client et le serveur (flux XML) afin de se conformer à la norme CIM. C’est la raison pour laquelle la commande Invoke-CimMethod est plus souvent utilisée dans le monde CIM que la commande Invoke-WmiMethod dans le monde WMI.

Voici les paramètres les plus couramment utilisés de Get-WmiObject :

Établissement de sessions avec des machines distantes

Tandis qu’il est possible avec les commandes de la famille WMI de s’adresser à des machines distantes (via les protocoles de communication DCOM et RPC), la communication n’est guère optimisée car à chaque requête, une session est établie, puis supprimée après le renvoi du résultat au client. De plus, le dialogue vers les machines distantes s’effectue de manière séquentielle.

Les commandes de la famille CIM améliorent grandement cet état de fait en apportant :

Le « remoting » CIM est très proche du fonctionnement du mécanisme de « communication à distance » PowerShell (voir chapitre Exécution à distance).

Nous avons donc la possibilité soit d’établir une session temporaire le temps d’une requête avec le paramètre -ComputerName, soit d’utiliser une session CIM...

Monitoring de ressources avec la gestion des événements

Une autre facette de CIM/WMI assez méconnue mais pourtant très utile est la gestion des événements (ou events en anglais). CIM permet de surveiller ou de « monitorer » des événements en renvoyant une notification. Ensuite, libre à nous de décider quelle action entreprendre sur réception de tel ou tel événement.

La gestion des événements CIM/WMI peut se révéler être un formidable allié pour nous aider, nous administrateurs système, à éviter de nous transformer en de véritables pompiers. En effet, grâce à ce mécanisme, nous allons, par exemple, être prévenus en cas de remplissage à 80 % d’un disque logique d’une machine. « Être prévenu » peut signifier recevoir un e-mail, un SMS, ou un pop-up ; cela dépend uniquement de votre script et du mode de notification que vous avez choisi. Vous l’aurez compris, nous pouvons être notifiés de l’arrivée d’un événement sur toute ressource gérée par CIM/WMI. Nous pouvons donc surveiller le bon fonctionnement des services sur certains ordinateurs distants, surveiller l’exécution d’un processus particulier, ou bien encore monitorer certaines clés de registre. Étant donné toutes les classes WMI disponibles, il y a de grandes chances pour que vous puissiez monitorer LA ressource qui vous faisait défaut et qui vous permettra à l’avenir de dormir sur vos deux oreilles…

Pour ceux d’entre vous qui connaissent SCOM (System Center Operations Manager), eh bien sachez que le principe des notifications sur événement est le même ; et pour ceux qui ne connaissent pas, dites-vous que vous allez pouvoir faire de même que SCOM mais à une échelle infiniment plus petite et à moindre coût…

Si les notifications n’existaient pas, et pour tenter de faire de même, nous serions contraints de développer des scripts qui se déclencheraient à intervalles de temps réguliers pour surveiller certaines ressources gérées. Bien que cela soit possible, cette technique peut s’avérer...

Gestion basée sur les URI

L’utilisation des URI (Uniform Resource Identifier) devient nécessaire dès lors qu’il s’agit d’administrer des systèmes disposant d’un CIMOM, c’est-à-dire administrables en respectant le standard CIM du DMTF, autre que des systèmes d’exploitation Microsoft. En effet, pour ces derniers il est bien plus pratique et naturel d’utiliser les classes WMI/CIM dont nous avons parlé précédemment. En revanche, l’un n’empêche pas l’autre. C’est-à-dire que si vous connaissez parfaitement le schéma CIM, alors libre à vous d’utiliser les URI également pour administrer Windows. Il faut savoir qu’en réalité lorsque l’on réalise une requête CIM/WMI sur une machine distante, via par exemple la commande Get-CimInstance sur une classe donnée, PowerShell transforme le nom de la classe et la propriété demandée en un URI.

Par exemple la ligne de commande suivante :

PS > Get-CimInstance -ComputerName WS2012fr-1 -ClassName Win32_OperatingSystem
 

est équivalente à ceci :

PS > $Uri = 'http://schemas.microsoft.com/wbem/wsman/1/wmi/root/ 
cimv2/Win32_OperatingSystem' 
PS > Get-CimInstance -ComputerName WS2012fr-1 -ResourceUri $Uri
 

WS-Man répond aux standards du Web, et par conséquent toutes les ressources gérées doivent se conformer à un certain formalisme. Chaque ressource CIM est normalisée par le DMTF et à ce titre est représentée par un URI.

Boîte à outils graphiques pour l’exploration de la base CIM/WMI

Si vous ne vous sentez pas à votre aise d’utiliser la ligne de commande pour l’exploration de la base CIM/WMI sachez qu’il existe quelques outils graphiques plus ou moins faciles d’accès.