Exporter (0) Imprimer
Développer tout

Gestion de Windows avec WMI (Infrastructure de gestion Windows)

Sur cette page

Gestion de Windows avec WMI (Infrastructure de gestion Windows)
Introduction
Élaboration d'une liste de tous les services présents sur le système.
Liste des services automatiques inactifs
Liste de toutes les partitions de disque ayant moins de 20 % d'espace disponible.
Définition du délai avant démarrage du système d'exploitation
Sauvegarde du journal d'événements Application
Redémarrage d'une machine distante
Ouverture du Bloc-notes à l'aide de WMI
Recueil d'événements du journal Windows NT dans WMI
Recueil d'événements signalant une utilisation élevée du processeur
Conclusion

Gestion de Windows avec WMI (Infrastructure de gestion Windows)

Michael Maston
Microsoft Corporation

Novembre 1999

Résumé : Présentation de l'Infrastructure de gestion Microsoft Windows, intégrée à Windows 2000 (également disponible pour Windows 95, Windows 98 et Windows NT 4.0), conçue pour vous aider à gérer vos systèmes, applications et réseaux d'entreprise lorsque leur taille et leur complexité augmentent (15 pages imprimées).

Introduction

Cet article a pour but de présenter WMI afin que vous puissiez l'utiliser le plus rapidement possible et gérer votre système grâce à l'interface de script WMI. Avant d'examiner en détail les potentialités de WMI à l'aide d'exemples très utiles, commençons par expliquer ce qu'est WMI, quelles sont les raisons qui ont suscité sa mise au point et quels sont les avantages de ce produit.

L'une des principales difficultés auxquelles doivent faire face les responsables des services informatiques concerne la gestion des systèmes, des applications et des réseaux d'entreprise, lorsque leur taille et leur complexité augmentent. Pour résoudre de tels problèmes et réduire le coût total de possession des serveurs et des ordinateurs exécutant Windows, Microsoft a mis au point WMI, infrastructure de gestion évolutive faisant partie intégrante de Windows 2000. WMI se base sur l'initiative WBEM (Web-based Enterprise Management) et la spécification CIM (Common Information Model) adoptée par le DMTF. WMI intègre les objets gérés définis par CIM ainsi que les extensions au modèle CIM pour les informations complémentaires qui sont disponibles à partir de la plate-forme Windows.

Tout cela signifie que WMI améliore considérablement les capacités de gestion de Windows 2000 grâce à une interface unique, cohérente, extensible et orientée objet, qui utilise les normes de l'industrie. Par ailleurs, les applications et les scripts peuvent accéder aux données WMI sur un poste local ou distant de façon totalement transparente. Ce produit n'est pas uniquement destiné à Windows 2000 ; WMI est disponible pour Windows 95, Windows 98 et Windows NT 4.0. Certaines fonctionnalités de WMI permettront aux informaticiens de s'acquitter beaucoup plus facilement de leurs tâches de gestion.

  • API d'écriture de script uniforme. Tous les objets gérés sont définis dans un cadre objet commun fondé sur le modèle objet CIM. Les scripts n'ont besoin d'utiliser qu'une seule API (Application Programming Interface), WMI, pour accéder aux informations concernant des sources très diverses.

  • Administration à distance. Par définition, les objets gérés dans WMI sont disponibles pour les applications et les scripts aussi bien localement qu'à distance. La gestion à distance des objets ne requiert aucune tâche supplémentaire.

  • Recherche et navigation. Les applications et les scripts peuvent découvrir les informations disponibles sur un système en énumérant les classes disponibles. Les relations entre objets liés peuvent être détectées et parcourues afin de déterminer l'influence d'une entité gérée sur une autre.

  • Fonctionnalité de requête. L'infrastructure WMI traite les données qu'elle gère comme une base de données relationnelle et permet l'utilisation de requêtes SQL pour filtrer et concentrer les requêtes uniquement sur les données pertinentes.

  • Fonctionnalités puissantes de publication d'événements et d'abonnements. Des événements peuvent être demandés pour pratiquement toute modification apportée aux objets gérés du système, que ces objets disposent ou non de fonctionnalités internes d'événement. Les abonnés à des événements peuvent demander la notification d'événements très spécifiques en fonction de leurs intérêts particuliers (et non uniquement des événements prédéfinis par les développeurs). Grâce à une architecture très souple, toute action définie par l'utilisateur peut en principe être effectuée à réception d'un événement donné.

Examinons dans un premier temps l'aspect architectural de WMI. La figure 1 représente le modèle à trois niveaux utilisé par WMI, composé des fournisseurs, du gestionnaire d'objet CIM (CIMOM) et des consommateurs d'informations WMI.

Architecture WMI
Figure 1 Architecture WMI



En partant du bas, le premier niveau correspond au fournisseur. Pour simplifier, un fournisseur est un agent intermédiaire entre le système à gérer (le système d'exploitation, un service, une application, un gestionnaire de périphérique, etc.) et le gestionnaire d'objet CIM. La tâche d'un fournisseur consiste à extraire des informations de gestion de la source de données sous-jacente en utilisant les interfaces de gestion offertes par le logiciel. Les interfaces et les informations de gestion sont ensuite mappées par le fournisseur aux classes d'objets que WMI met à disposition des consommateurs WMI. À l'avenir, les nouveaux systèmes gérés et ceux mis à jour utiliseront les fournisseurs pour exposer directement les API de gestion sans conversion intermédiaire importante.

Le second niveau est constitué par le gestionnaire d'objet CIM (CIMOM), qui possède son propre référentiel de stockage et agit comme un broker pour les requêtes d'objet. CIMOM et son référentiel sont représentés dans le système par le service système appelé WinWgmt. Les fournisseurs se connectent à CIMOM par un ensemble publié d'interfaces COM. CIMOM conserve la trace des classes disponibles (leur définition est stockée dans le référentiel) et des fournisseurs devant délivrer des instances de ces classes. Lorsqu'une requête d'informations de gestion est émise par un consommateur WMI vers le CIMOM, celui-ci évalue la requête, identifie le fournisseur qui possède les informations, puis, à réception de celles-ci, renvoie les données au consommateur. Le consommateur doit simplement demander les informations dont il a besoin sans qu'il lui soit nécessaire d'en connaître la source exacte ni la façon dont elles peuvent être extraites de l'API sous-jacente. Notez que des données statiques peuvent être stockées dans le référentiel et récupérées sans fournisseur, mais l'atout principal du système WMI est qu'il fournit des informations dynamiques sur le système géré, ce qui s'effectue entièrement par les fournisseurs.

Le dernier niveau est constitué par les consommateurs de données WMI. Il peut s'agir d'outils de gestion tels que les composants logiciels enfichables de la console MMC, des applications de gestion comme Microsoft Systems Management Server ou des applications et des scripts tiers. Ces consommateurs, comme il a été dit précédemment, n'ont besoin de connaître que les classes d'objets sur lesquels ils veulent des informations. Les détails concernant l'emplacement des informations et la façon de les obtenir sont masqués et sans importance. De cette façon, une application ou un script peut écrire à une API commune, WMI, et obtenir une mine d'informations sur l'ordinateur, le système d'exploitation, les applications, les périphériques, et même des informations disponibles grâce à d'autres protocoles de gestion tels que SNMP (Simple Network Management Protocol) et DMI.

Avant de présenter quelques exemples d'utilisation de WMI, nous allons examiner ce qu'il est possible de faire avec les classes de gestion de WMI. Différents types d'informations peuvent être définis dans les classes WMI :

  • Propriétés. Les propriétés contiennent des informations descriptives et opérationnelles sur une instance particulière d'une classe. Par exemple, pour un ordinateur donné, l'instance de la classe Win32_DiskDrive définit une propriété appelée InterfaceType, qui a la valeur IDE pour le lecteur C:.

  • Méthodes. Pour une instance de classe donnée, il s'agit des actions que vous pouvez exécuter sur cette instance. Par exemple, la classe Win32_Directory comporte une méthode appelée Compress() qui permet de compresser le contenu d'un dossier de la même façon que par l'interface utilisateur graphique de Windows.

  • Événements. Il s'agit des notifications qu'un consommateur peut demander de recevoir à propos de certaines occurrences ou pannes système. Toute modification apportée à une propriété définie peut être utilisée comme base d'un événement. Par exemple, la propriété LoadPercentage de la classe Win32_Processor peut être utilisée pour demander un événement lorsque l'utilisation du CPU va dépasser les 50 %. Les événements peuvent également être fournis indépendamment d'une propriété.

  • Associations. Une association décrit une relation entre des classes et est elle-même définie par une classe. La classe Win32_POTSModemToSerialPort, contenant des références aux instances d'un modem et du port COM auquel il est connecté, est un exemple d'association. C'est un concept extrêmement puissant car il permet d'afficher et de parcourir des informations de gestion concernant un système entier de composants reliés, pour certaines tâches comme le dépannage.

La dernière version de WMI, livrée avec Windows 2000 et disponible également pour tous les autres systèmes d'exploitation Windows, comporte plusieurs fournisseurs proposant un large éventail d'instruments pour plusieurs éléments du système. Voici quelques-uns d'entre eux :

  • Fournisseur Win32. Fournit des informations sur le système d'exploitation, l'ordinateur, les périphériques, les systèmes de fichiers et les données de sécurité.

  • Fournisseur WDM. Fournit des informations sur le gestionnaire de bas niveau Windows Driver Model, pour les périphériques connectés par l'utilisateur, les périphériques de stockage, les interfaces réseaux et les ports de communication.

  • Fournisseur Journal des événements. Permet la lecture des entrées du journal des événements de Windows NT, la configuration de ses options administratives et sa sauvegarde. Des événements WMI peuvent être générés lorsque des événements sont ajoutés à un journal.

  • Fournisseur Registre. Permet la création, la lecture et l'écriture de clés de Registre. Des événements WMI peuvent être générés lorsque des clés de Registre spécifiées sont modifiées.

  • Fournisseur Compteur de performance. Expose les informations brutes du compteur de performance, utilisées pour calculer les valeurs de performance affichées par l'outil Moniteur système. Tout compteur de performance installé sur un système est automatiquement visible via ce fournisseur. Avec Windows 2000 uniquement.

  • Fournisseur Active Directory. Sert de passerelle vers toutes les informations stockées par les services Microsoft Active Directory. Permet d'accéder aux informations WMI et Active Directory à l'aide d'une seule API.

  • Fournisseur Windows Installer. Permet le contrôle total de Windows Installer et l'installation de logiciels par WMI. Fournit également des informations sur toute application installée avec Windows Installer.

  • Fournisseur SNMP. Sert de passerelle vers les systèmes et les périphériques qui utilisent le protocole de gestion SNMP (Simple Network Management Protocol). Les variables objet SNMP MIB peuvent être lues et écrites. Les interruptions SNMP peuvent être mappées automatiquement vers des événements WMI.

  • Fournisseur d'affichage. Permet de créer de nouvelles classes agrégées à partir de classes existantes. Les classes sources peuvent être filtrées pour n'extraire que les informations pertinentes, les informations de plusieurs classes peuvent être combinées en une classe unique et les données de plusieurs machines peuvent être agrégées en une seule vue.

Consultez le schéma du système WMI sur le site MSDN, qui présente les principales classes WMI système et périphériques disponibles sous Windows 2000 ainsi que les propriétés, les méthodes et les associations qu'elles définissent. Le schéma reprenant tous les fournisseurs cités est trop volumineux pour y être publié intégralement mais ce tableau est un outil de référence très utile car il permet de découvrir les avantages de WMI et vous incitera à en savoir plus. Toutefois, les fournisseurs WMI ne se limitent pas aux fonctionnalités de base du système d'exploitation. De nombreux fournisseurs ont été développés aussi bien par Microsoft que par des tiers pour d'autres applications et services essentiels exécutés sur les plates-formes Windows. Consultez le site MSDN Site en anglais.

Maintenant que nous avons défini ce qu'est WMI et les avantages qu'il présente pour la gestion de vos systèmes, examinons comment exploiter sa prise en charge des scripts. Comme c'est souvent le cas avec l'utilisation de scripts sur les plates-formes Windows, vous pouvez choisir grâce à WSH (Windows Scripting Host) parmi toute une gamme de langages de scripts. Ces langages comprennent Microsoft Visual Basic Scripting Edition (VBScript), Microsoft JScript et tous les langages de script qui prennent en charge la technologie Microsoft ActiveScripting, tels que Perl. Il est possible d'accéder aux classes WMI très facilement par C++, Visual Basic, Active Server Pages (ASP) ainsi que par des scripts au sein de pages HTML standard.

Les instruments WMI permettent d'effectuer tellement de tâches qu'il est impossible de donner ici un exemple représentatif de chaque sous-système important. Fort heureusement, une fois que vous savez accéder à une classe, lire ou écrire une propriété, exécuter une méthode ou recevoir un événement dans une classe, la procédure est exactement identique pour toutes les autres classes WMI. Pour illustrer certaines capacités de WMI, voici une sélection de quelques exemples écrits en VBScript. Ces exemples abordent les points suivants :

  • Élaboration d'une liste de tous les services installés et identification des services configurés dans le mode de démarrage "automatique" mais qui sont inactifs.

  • Liste des partitions de disque logiques sur un ordinateur et détermination de celles qui ont moins de 20 % d'espace disponible.

  • Modification du délai d'attente avant le démarrage du système d'exploitation par défaut.

  • Exécution d'une sauvegarde du journal d'événements "Application" puis vidage du fichier journal.

  • Redémarrage de l'ordinateur d'un collègue (Bien entendu, celui-ci vous a donné les autorisations de sécurité nécessaires. Ce sera d'ailleurs l'occasion d'aborder le thème de la sécurité.)

  • Ouverture du Bloc-notes à l'aide d'une méthode WMI.

  • Définition d'un consommateur d'événements pour surveiller tout nouvel événement ajouté au journal des événements.

  • Reconfiguration du script de ce consommateur d'événements pour demander un événement lorsque l'utilisation du CPU dépasse 50 %.

Élaboration d'une liste de tous les services présents sur le système.

Dans cet exemple, nous utilisons la classe Win32_Service pour établir la liste de tous les services qui sont installés sur le système, qu'ils soient actifs ou non :

Set ServiceSet =
GetObject("winmgmts:{impersonationLevel=impersonate}").InstancesOf("Win32_Service")
for each Service in ServiceSet
WScript.Echo Service.Description
Next

Reprenons dans le détail cet exemple et essayons de comprendre ce qui se passe à chaque stade. En premier lieu, nous demandons un objet dans l'appel GetObject() émanant du service WMI (WinMgmt). Pour cela, nous soumettons une requête pour toutes les instances de la classe Win32_Service par la méthode InstancesOf() . Le résultat de cet appel est une liste d'instances de la classe Win32_Service.

Une fois que les instances figurent dans la variable ServiceSet, il ne reste plus qu'à les parcourir et à afficher la propriété pertinente, le champ Description, qui contient le nom convivial du service. Il est important de noter ici que la propriété Description est gérée comme une propriété Automation de l'objet Service, ce qui permet une écriture de script beaucoup plus intuitive. Vous pouvez obtenir exactement le même résultat en utilisant une requête en langage SQL et en la soumettant à la méthode ExecQuery() :

Set ServiceSet =
GetObject("winmgmts:{impersonationLevel=impersonate}").InstancesOf("Win32_Service")
.ExecQuery("select * from Win32_Service")

La requête SQL demande toutes les instances (et toutes les propriétés de ces instances) à sélectionner et à renvoyer. L'ensemble d'objets renvoyé avec cette méthode est le même. Toutefois, comme les exemples suivants vont le montrer, vous pouvez utiliser le formulaire de requête pour affiner le nombre de propriétés et/ou d'instances retournées et ne conserver que celles qui vous intéressent. Le plus important est que vous pouvez utiliser l'une ou l'autre de ces méthodes pour n'importe quelle classe fournie par WMI et pouvant être énumérée.

La dernière remarque que nous ferons sur cet exemple mais qui s'applique également aux suivants concerne le modèle de sécurité utilisé. Vous avez dû noter l'instruction {impersonationLevel=impersonate} de l'appel GetObject() venant d'être abordé. Cette instruction indique surtout au système d'utiliser vos informations d'identification actuelles lorsqu'il doit demander des données ou exécuter des méthodes. Tout se passe comme si vous appeliez directement l'API native. Ceci s'applique à toute requête effectuée sur votre poste local ou à distance. Dans un cas comme dans l'autre, l'utilisateur perçu par le système est celui défini par votre connexion d'accès en cours. Il est bien sûr possible de spécifier différentes informations d'identification pour les requêtes mais ceci dépasse le cadre du présent article. Par ailleurs, sous Windows 2000, l'instruction {impersonationLevel=impersonate} peut être omise du script, car "impersonate"est le niveau d'emprunt d'identité configuré par défaut pour le modèle COM. Cette instruction est néanmoins conservée dans les exemples, pour que ceux-ci fonctionnement aussi sur des plates-formes plus anciennes comme Windows NT 4.0.

Liste des services automatiques inactifs

Si nous voulons à présent afficher uniquement les services configurés pour démarrer automatiquement mais qui ne sont pas actifs (parce qu'ils ont été arrêtés manuellement par un utilisateur, par exemple), il nous suffit d'apporter une simple modification à la version requête du script, comme indiqué en gras ci-dessous :

Set ServiceSet =
GetObject("winmgmts:{impersonationLevel=impersonate}")
.ExecQuery("select * from Win32_Service where State='Stopped' and
StartMode='Auto'")
for each Service in ServiceSet
WScript.Echo Service.Description
next
if ServiceSet.Count = 0 Then WScript.echo "Aucun service trouvé répondant aux critères de recherche."

Comme lors d'une recherche d'informations plus spécifiques dans une base de données SQL, il suffit ici d'ajouter une clause WHERE à la requête pour obtenir la liste des services inactifs mais configurés pour être exécutés automatiquement au démarrage. La requête ainsi définie permet d'affiner le résultat qui ne renvoie que les instances dont la propriété State a pour valeur Stopped et dont la propriété StartMode a pour valeur Auto.

Les requêtes peuvent être très simples ou très complexes, selon le degré de spécificité des informations demandées. Notez qu'une ligne supplémentaire a été ajoutée à la fin du script pour englober le cas où aucune instance ne correspondrait au critère, ce qui serait pratiquement toujours le cas dans ce scénario. Pour observer le renvoi d'une instance par ce script, vous pouvez arrêter temporairement le spouleur d'impression et lancer le script. Avant de désactiver le spouleur d'impression, vous devez normalement obtenir le message "Aucun service trouvé…" ; après, vous devez obtenir une seule instance correspondant au spouleur d'impression que vous venez d'arrêter. Pensez à le redémarrer lorsque vous avez terminé le test et vérifiez que son instance n'est plus renvoyée par le script.

Liste de toutes les partitions de disque ayant moins de 20 % d'espace disponible.

Pour déterminer la quantité d'espace disponible sur une partition de disque, vous devez extraire deux propriétés de la classe Win32_LogicalDisk : FreeSpace et Size. Avec ces deux informations, le pourcentage d'espace disponible peut être déterminé et vous pouvez identifier les partitions en dessous de la limite spécifiée.

Set DiskSet =
GetObject("winmgmts:{impersonationLevel=impersonate}")
.ExecQuery("select FreeSpace,Size,Name from Win32_LogicalDisk where
DriveType=3")
for each Disk in DiskSet
If (Disk.FreeSpace/Disk.Size) < 0.20 Then
WScript.Echo "Le Disque " + Disk.Name + " est presque plein."
End If
Next

Dans cette requête, vous pouvez noter que seules les propriétés absolument nécessaires à la construction du script sont demandées, et non la totalité de la classe Win32_LogicalDisk. Pour obtenir des informations sur les disques durs locaux, la clause WHERE limite la requête à ce seul type de lecteur (DriveType=3). Sans un tel filtre, les lecteurs de disquettes, les lecteurs de CD-ROM et les partages réseau auraient également été inclus dans la vérification, ce qui n'est probablement pas souhaitable. La propriété Name est également extraite et utilisée lorsqu'un message doit être affiché pour signaler le manque d'espace sur le disque.

Définition du délai avant démarrage du système d'exploitation

Dans ce script nous utilisons la classe Win32_ComputerSystem pour modifier le délai avant le démarrage, afin que l'utilisateur puisse choisir une option de démarrage différente du système d'exploitation par défaut. Ce script se distingue des autres par le fait qu'une propriété de la classe Win32_ComputerSystem est modifiée et réécrite vers WMI, qui à son tour met à jour le paramétrage correspondant du système d'exploitation :

Set CompSysSet =
GetObject("winmgmts:{impersonationLevel=impersonate}"
.ExecQuery("select * from Win32_ComputerSystem")
for each CompSys in CompSysSet
CompSys.SystemStartupDelay = 20
CompSys.Put_()
next
WScript.Echo "Délai d'attente avant démarrage défini"

Pour accomplir cette tâche, la classe Win32_ComputerSystem est énumérée par une requête, comme précédemment. Le script parcourt chaque instance (dans le cas de cette classe, il y a toujours une seule instance car il n'existe qu'une seule instance ordinateur pour une machine donnée) et affecte la valeur souhaitée à la propriété SystemStartupDelay dans la variable temporaire. Pour terminer, pour récrire l'instance avec la valeur modifiée, la méthode Put_() est invoquée. Notez que plusieurs propriétés de l'instance pourraient avoir été mises à jour simultanément avec le même appel Put_(). Ce mécanisme peut être utilisé pour toute propriété prise en charge par WMI et pour laquelle l'autorisation d'écriture est activée.

La valeur 20 secondes est écrite dans la propriété. Vous pouvez le vérifier après avoir exécuté le script, en démarrant l'applet Système dans le Panneau de configuration, puis en affichant les options Démarrage et récupération de l'onglet Avancé, comme le montre la figure 2.

Options Démarrage et récupération
Figure 2 Options Démarrage et récupération



Sauvegarde du journal d'événements Application

La classe Win32_NTEventLogFile modèle les journaux d'événements sous Windows NT 4.0 et Windows 2000. Par défaut, il existe trois journaux d'événements standard : système, sécurité et application. Dans cet exemple, la méthode de sauvegarde d'un de ces journaux est invoquée. Les méthodes sous WMI sont de simples appels de fonction appliqués à certains objets gérés ; la méthode de sauvegarde est appliquée ici à une instance d'un objet journal d'événements de Windows NT.

LogFileSet =
GetObject("winmgmts:{impersonationLevel=impersonate,(Backup)}")
.ExecQuery("select * from Win32_NTEventLogFile where
LogfileName='Application'")
for each Logfile in LogFileSet
RetVal = LogFile.BackupEventlog("c:\BACKUP.LOG")
if RetVal = 0 then WScript.Echo "Journal sauvegardé"
next

La procédure reste essentiellement identique puisque la requête est effectuée dans la classe Win32_NTEventLogFile, avec filtrage du fichier journal recherché "Application". Notez l'ajout de l'instruction "(Backup)" dans l'appel GetObject(). Pour sauvegarder un fichier journal d'événements, le droit Backup doit être assigné à votre compte. Les membres des groupes de sécurité NT Administrateurs et Opérateurs de sauvegarde ont ce droit par défaut. Mais il ne suffit pas d'avoir ce droit pour pouvoir l'utiliser. Pour effectuer une opération nécessitant un droit, telle qu'une sauvegarde, le droit doit être explicitement activé par l'utilisateur. Si (Backup) n'a pas été spécifié dans l'appel GetObject(), le script reçoit le message "Access Denied" (accès refusé) lorsque la méthode BackupEventlog() est invoquée et l'opération n'est pas exécutée. La méthode BackupEventlog() utilise comme seul paramètre le chemin et le nom du fichier de sauvegarde.

Pour supprimer les entrées du journal d'événements Application après la sauvegarde, le script ne requiert qu'une simple modification, indiquée ci-dessous en caractères gras :

LogFileSet =
GetObject("winmgmts:{impersonationLevel=impersonate,(Backup)}")
.ExecQuery("select * from Win32_NTEventLogFile where
LogfileName='Application'")
for each Logfile in LogFileSet
RetVal = LogFile.BackupEventlog("c:\BACKUP.LOG")
if RetVal = 0 then WScript.Echo "Journal sauvegardé"
RetVal = LogFile.ClearEventlog()
if RetVal = 0 then WScript.Echo "Journal effacé"

next

Les éléments en gras de l'exemple mis à jour correspondent à la fonctionnalité requise pour effacer le fichier en appelant la méthode ClearEventlog() et, en cas de succès, afficher un message.

Redémarrage d'une machine distante

L'utilisation distante de WMI est pratiquement identique à l'utilisation locale. Chacun des exemples précédents peut être facilement modifié de manière à spécifier une machine distante comme cible au lieu du système local par défaut. Mis à part l'appel d'une machine cible spécifique, l'utilisation de WMI est totalement identique. Ce point est important car il signifie que toute propriété ou méthode instrumentée est accessible individuellement ou dans toute l'entreprise à l'aide d'un script très simple. À présent, redémarrons un système distant à l'aide de la méthode Reboot() de la classe Win32_OperatingSystem  :

Set OpSysSet =
GetObject("winmgmts:{impersonationLevel=impersonate,(RemoteShutdo
wn)}//alexn-pc ").ExecQuery("select * from Win32_OperatingSystem
where Primary=true")
for each OpSys in OpSysSet
OpSys.Reboot()
Next

Pour construire ce script, il faut demander à la machine distante l'instance du système d'exploitation qu'elle exécute, dans le cas présent celui dont l'indicateur Primary a la valeur TRUE. Le nom de la machine, alexn-pc, doit bien sûr être adapté pour diriger la méthode sur le système approprié. Hormis la spécification de la machine cible, l'extraction d'informations se déroule de la même manière que sur une machine locale.

Notez également qu'il s'agit d'une opération nécessitant des droits (vous devez appartenir au groupe des administrateurs sur la machine distante pour pouvoir exécuter cette opération). Pour que le script fonctionne, vous devez posséder l'autorisation d'effectuer un arrêt à distance sur le système distant et vous devez activer explicitement ce droit au moyen de l'attribut "(RemoteShutdown)" avant de lancer l'opération. Souvenez-vous que les permissions et les droits sont accordés en fonction de l'utilisateur connecté qui exécute le script ; WMI utilise les droits qui correspondent à votre compte utilisateur actuel, lorsqu'il emprunte votre identité. De la sorte, seules les informations et les actions pour lesquelles vous avez une autorisation sont disponibles.

Ouverture du Bloc-notes à l'aide de WMI

Dans cet exemple, nous lançons un nouveau processus par une méthode WMI dans la classe Win32_Process. Une application relativement inoffensive a été choisie pour les besoins de la démonstration (il s'agit du Bloc-notes), mais toute autre application peut être utilisée. Cette capacité peut être extrêmement puissante pour les services de support technique en relation avec des utilisateurs peu expérimentés. Plutôt que de guider un utilisateur final dans l'interface utilisateur, les menus, etc. pour lancer un outil de diagnostic, le technicien peut tout simplement afficher l'outil sur le système de l'utilisateur à l'aide d'un script qu'il invoque à distance à l'aide de WMI. Ceci permet de gagner beaucoup de temps :

set process =
GetObject("winmgmts:{impersonationLevel=impersonate}
!Win32_Process")
result = process.Create ("notepad.exe",null,null,processid)
WScript.Echo "Résultat retourné par la méthode = " & result
WScript.Echo "L'ID du nouveau processus est " & processed

Cet exemple introduit deux nouveaux concepts. Le premier concerne l'utilisation de la notation du moniker COM dans l'appel GetObject() pour la demande de la classe Win32_Process. Un moniker est un mécanisme standard COM permettant l'encapsulation de l'emplacement et de la liaison vers un autre objet COM. Ceci vous permet de récupérer un objet spécifique en fonction du nom d'écran. Ensuite, plutôt que de soumettre une requête à l'aide de ExecQuery() pour récupérer les instances de la classe Win32_Process, l'objet classe lui-même a été récupéré. La raison en est très simple mais peut-être pas évidente. La création d'un nouveau processus n'est pas forcément une mesure à prendre à partir d'une instance de processus existante. Quel processus en cours d'exécution choisir pour lancer le nouveau processus ? Étant donné qu'il n'y a aucune réponse cohérente à cette question, il semble que la création d'un processus revienne en fait à créer une nouvelle instance de la classe Win32_Process. Le concept de méthode statique, établie par rapport à la définition de la classe elle-même plutôt que de ses instances, est alors nécessaire. La méthode Create() pour Win32_Process est un exemple de méthode statique ; les exemples précédents de méthode étaient des méthodes dynamiques, opérant par rapport à des instances individuelles. La méthode Delete() est une méthode dynamique car elle s'applique généralement à des instances particulières plutôt qu'à la classe globale.

La méthode Create() utilise plusieurs paramètres d'entrée mais dans notre exemple, seul le nom de l'exécutable à lancer a été précisé : notepad.exe. La méthode renvoie une valeur indiquant la réussite ou l'échec de l'opération ainsi que l'ID du nouveau processus créé. Le script affiche les résultats de l'exécution de la méthode et les valeurs ID du processus après exécution. Bien entendu, l'application Bloc-notes doit s'afficher sur le bureau.

Recueil d'événements du journal Windows NT dans WMI

Maintenant que nous avons collecté des données et exécuté plusieurs méthodes, nous pouvons nous intéresser aux événements. WMI peut fournir des événements pour plusieurs types de modifications ou occurrences du système. Dans cet exemple, le script est construit pour enregistrer tout nouvel événement écrit dans le journal d'événements de Windows NT ou Windows 2000. Lorsqu'un nouvel événement est écrit, WMI génère un événement WMI que peut recevoir un consommateur d'événements tel que ce script. Il est important de noter cependant que les événements WMI ne sont envoyés que si au moins un consommateur s'est inscrit pour les recevoir. Si personne n'est intéressé, WMI ne gaspille pas de ressources à surveiller une occurrence donnée du système :

set events =
GetObject("winmgmts:{impersonationLevel=impersonate}")
.ExecNotificationQuery _
("select * from __instancecreationevent where targetinstance
isa 'Win32_NTLogEvent'")
if err <> 0 then
WScript.Echo Err.Description, Err.Number, Err.Source
end if
' Notez que l'appel suivant attendra indéfiniment – un délai peut être
spécifié
WScript.Echo "Attente d'événements NT..."
do
set NTEvent = events.nextevent
if err <> 0 then
WScript.Echo Err.Number, Err.Description, Err.Source
Exit Do
else
WScript.Echo NTEvent.TargetInstance.Message
end if
loop
WScript.Echo "terminée".

Avec la méthode ExecNotificationQuery(), le script soumet une requête définissant les types d'événements à envoyer lorsqu'ils se produisent. Lorsqu'un événement est écrit dans le journal, il crée une instance de la classe Win32_NTLogEvent. WMI peut détecter une instance lorsqu'elle est créée, modifiée ou supprimée et ces informations sont à l'origine de l'événement qui nous intéresse. L'instruction de requête SQL indique en réalité à WMI "d'envoyer tous les événements de création d'instance lorsque l'instance créée appartient à la classe Win32_NTLogEvent". Les événements de création d'instances des autres classes ne sont pas renvoyés car ils ne correspondent pas au critère de la requête.

Le script attend simplement en boucle que des événements soient envoyés et affiche la propriété des instances reçues.

Recueil d'événements signalant une utilisation élevée du processeur

Dans l'exemple précédent, les événements étaient fournis directement par le fournisseur de journal d'événements, qui les provoquait lorsqu'il était rappelé par le service de journal d'événements, à chaque enregistrement de nouveaux événements. Tous les services ne fournissent pas de tels mécanismes pour signaler des événements intéressants. Du moins, il vaut mieux ne pas s'attendre à ce qu'ils le fassent. Pour éviter l'absence d'événements avec certains instruments, WMI possède un mécanisme intégré qui lui permet de générer des événements lorsqu'il n'existe aucune prise en charge sous-jacente de ceux-ci. Concrètement, dès lors qu'une propriété est instrumentée, elle peut être source d'événements.

Dans cet exemple, nous allons voir comment l'utilisation du processeur peut être contrôlée et comment un événement peut être généré et envoyé aux consommateurs inscrits, lorsqu'un processeur subit une charge importante. Ceci est possible même en l'absence d'un mécanisme interne d'événements pour ce type particulier de mesure intégrée au système d'exploitation :

set events =
GetObject("winmgmts:{impersonationLevel=impersonate}")
.ExecNotificationQuery _
("select * from __instancemodificationevent within 5 where
targetinstance isa 'Win32_Processor' and
targetinstance.LoadPercentage > 50")
if err <> 0 then
WScript.Echo Err.Description, Err.Number, Err.Source
end if
' Notez que l'appel suivant attendra indéfiniment – un délai peut être
spécifié
WScript.Echo "Attente d'événements relatifs à la charge processeur..."
WScript.Echo ""
do
set NTEvent = events.nextevent
if err <> 0 then
WScript.Echo Err.Number, Err.Description, Err.Source
Exit Do
else
WScript.Echo NTEvent.TargetInstance.DeviceID WScript.Echo
NTEvent.TargetInstance.LoadPercentage
end if
loop

WScript.Echo "terminée".

Dans ce script nous modifions le script du journal d'événement Windows NT précédant pour surveiller la charge imposée au processeur. Notez que nous surveillons maintenant les événements concernant la modification plutôt que la création d'instance comme dans l'exemple ci-dessus. En outre, la classe à analyser est la classe Win32_Processor, avec comme contrainte supplémentaire que la propriété LoadPercentage (membre de la classe Win32_Processor) doit avoir une valeur supérieure à 50. Comme WMI analyse la valeur de la propriété LoadPercentage et génère des événements lorsque cette valeur change et correspond au critère de la requête, il a besoin d'un paramètre indiquant à quelle fréquence analyser la valeur. C'est l'objet de la clause WITHIN de la requête. La clause WITHIN définit l'intervalle de temps maximum qui doit s'écouler avant que WMI ne vérifie si la valeur de la propriété a changé et si elle correspond aux exigences de la requête. Cette valeur peut également être interprétée comme le délai maximum d'attente avant que le consommateur obtienne l'événement souhaité.

Comme précédemment, lorsque le critère de la requête est satisfait, WMI envoie un événement au script, qui à son tour imprime certaines informations sur l'événement, en l'occurrence le nom du processeur et le pourcentage de charge. Ce script fonctionne avec les systèmes ayant un ou plusieurs processeurs. Étant donné que le script recherche les modifications d'instance qui affectent une instance de la classe Win32_Processor, il renvoie le nom de tout processeur qui dépasse le critère de charge spécifié. Si seule la charge d'un processeur spécifique nous intéressait, il serait facile de modifier la requête pour limiter son champ d'application.

Cette même fonctionnalité peut être utilisée pour toute propriété visible par WMI, qu'elle fasse partie de l'infrastructure fournie avec le système d'exploitation ou ajoutée par un tiers. Ceci ne requiert absolument aucun travail supplémentaire, il s'agit d'une fonction standard fournie gracieusement avec WMI. En outre, si l'API sous-jacente prend en charge un système interne d'événements pouvant fournir les mêmes informations de manière éventuellement plus optimale, le concepteur du fournisseur peut facilement et harmonieusement outrepasser l'analyse d'événements de WMI sans que le consommateur d'événements ne se rende compte de la différence. Un consommateur tirera automatiquement bénéfice du meilleur mécanisme d'événements disponible sans modification du processus. Rappelons que WMI n'analyse ainsi une propriété que si un consommateur d'événements s'est inscrit pour des événements liés à celle-ci. Une fois son inscription supprimée (par exemple, lorsque le script se termine), WMI ne surveille plus les événements demandés.

Conclusion

WMI est un élément essentiel de la stratégie Microsoft visant à faire de la plate-forme Windows l'un des systèmes d'exploitation les plus faciles à gérer et visant à réduire le coût total de possession pour ses clients. Utilisant les normes industrielles et recommandé par le DMTF (Distributed Management Task Force), WMI fournit un modèle d'objet riche et extensible qui permet aux systèmes informatiques d'être gérés de manière cohérente, pilotable par scripts, que ce soit localement ou à distance. La plupart des informations et services essentiels du système d'exploitation sont déjà instrumentés dans le système WMI de base fourni avec Windows 2000. Les instruments d'autres produits Microsoft et tiers sont disponibles et/ou en développement, faisant ainsi de WMI un outil évolutif, fiable et homogène pour la gestion des systèmes Windows.

Cet article vous a présenté certaines des fonctions particulièrement utiles de WMI. WMI fournit un ensembles de classes, de propriétés, de méthodes, d'événements et d'associations orientés objet, facilement accessibles grâce aux langages de scripts très puissants Microsoft Visual Basic et Microsoft Visual C++. Par ces différents exemples de scripts, nous avons tenté de vous montrer quelques-unes des puissantes fonctionnalités de WMI, mais ce n'était qu'un aperçu. Nous espérons que ces exemples et que le tableau d'infrastructure joint vous inciteront à explorer les différents types d'informations disponibles grâce à WMI et qui pourront faciliter la gestion de vos systèmes. Les prochains articles traiteront plus en détails certains concepts tel que l'écriture de fournisseurs WMI, le traitement avancé d'événements et les applications clientes.

Une documentation complète sur la création de composants WMI et l'utilisation de WMI est disponible dans le kit de développement WMI, livré avec le kit de développement de plate-forme MSDN Windows 2000, ou peut être téléchargé gratuitement à partir du site MSDN Site en anglais. Les composants essentiels WMI nécessaires aux systèmes Windows NT 4.0 et Windows 95/98 peuvent également être téléchargés à partir de ce même site.



Dernière mise à jour le lundi 27 mars 2000



Pour en savoir plus

Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.
Afficher:
© 2014 Microsoft