WMI – Waarom Management Informatie

Dit artikel verscheen eerder in Windows en Netwerken (maart 2001)

Wim Verveen, e-mail: wim@win2kwereld.nl

 

Introductie

In een eerder artikel hebben wij de basisbeginselen van Windows Script Host (WSH) voor u uit de doeken gedaan. Een aantal technieken of interfaces die daarbij van pas konden komen hebben reeds kort de revue gepasseerd en het is tijd om daar nu wat dieper op in te gaan. De WSH maakt het mogelijk om de COM objecten binnen Windows via eens script te benaderen.  COM  objecten worden deels door het besturingssysteem beschikbaar gesteld, maar deels ook door andere fabrikanten. Een aantal van de objecten springt eruit omdat deze van bovenmatig nut kunnen zijn. Dit betreft onder meer objecten die beschikbaar  worden gesteld door WMI, Windows Management Instrumentation. In dit artikel zullen we een kort overzicht geven van WMI waardoor duidelijk zal worden waarom het onmisbaar is om in een enterprise omgeving of zelfs een kleinere Windows omgeving te kunnen scripten maar ook hoe je met andere technieken dan scripting WMI kunt ontsluiten. Een en ander wordt met praktische voorbeelden toegelicht.

Architectuur

Voor het gebruik van WMI is een goed begrip van de architectuur noodzakelijk. Als u geen overzicht hebt over de structuur van alle WMI zaken is het niet mogelijk om zelf uw weg te vinden in het oerwoud van alle mogelijkheden.

WMI is een implementatie van het Web Based Enterprise Management (WBEM) voor Windows platformen. WBEM zelf is een uitbreiding van het Common Information Model (CIM), bedoeld om management objecten in Windows systemen te representeren. Het WBEM initiatief heeft meer leden dan Microsoft alleen. Bedrijven als Cisco, Compaq, Intel en vele anderen zijn er lid van. Het CIM is een uitbreidbaar model voor de logische organisatie van management objecten. Zowel het CIM als het WBEM zijn standaards gedefinieerd door de Desktop Management Task Force (DMTF). Deze organisatie strekt zich verder uit dan het Windows platform. In het bestuur zitten vele bedrijven, waaronder Sun, Novell, IBM, HP, etc.

Dit is allemaal heel abstract, maar waar gaat het nu precies over? Het doel van de WMI architectuur is het beschikbaar maken van informatie over z.g. managed systems. Hierbij kunt u denken aan disks, processen, geheugen, applicaties, configuratie, enz. Deze informatie wordt beschikbaar gesteld aan managing systems, waarvan SMS een goed voorbeeld is. Een sleutelpunt hierbij is dat er een duidelijke scheiding is tussen de managed en de managing systems. Implementatie-specifieke details  -- bijvoorbeeld het achterhalen van de disk configuratie – worden verborgen gehouden voor de managing systems. Hierdoor is het mogelijk om elementen aan een computer toe te voegen zonder de controlerende applicaties aan te passen.

Figuur 1: Overzicht van de WMI architectuur, bestaande uit vier lagen. De onderste laag 4 staat het dichts bij de hardware en systeem software, de bovenste laag 1 heeft de applicaties die het dichts bij de eindgebruiker staan.

Een schematisch overzicht van de WMI architectuur ziet u in figuur 1. De architectuur bestaat uit vier lagen. De bovenste twee lagen zijn van algemene aard, dat wil zeggen dat ze onafhankelijk zijn van de managed systems. De onderste twee lagen zorgen voor toegang tot de managed systems.

Laag 4 is de onderste laag van de architectuur. Het staat het dichtst bij de hardware en systeem software en is verantwoordelijk voor het opvragen van informatie uit deze bronnen. Typische voorbeelden van laag 4 elementen zijn device drivers, bepaalde elementen van het Win32 subsysteem, en management protocollen zoals SNMP. De elementen van laag 4 moeten wel WMI-enabled zijn. Het is dus niet zo dat iedere willekeurige device driver WMI informatie beschikbaar stelt, hij moet er wel specifiek voor geprogrammeerd zijn.

Aan de ene kant praten de laag 4 elementen met de onderliggende systemen, aan de andere kant praten ze met de z.g. providers van laag 3. Het is de verantwoordelijkheid van laag 3 om de informatie van laag 4 te vertalen naar WMI objecten die bruikbaar zijn voor in de hoger liggende lagen. De exacte details van waar informatie vandaan moet komen worden zo verborgen. Iedere provider werkt voor een specifiek managed system. Tabel 1 laat een aantal providers zien.

Naam WMI Provider

Doel van de provider

Win32

Een beperkte interface naar het Win32 subsysteem. Heeft informatie over het Operating System, file systemen, processen, geheugen, etc.

WDM

Windows Driver Model interface. Geeft toegang tot randapparatuur als netwerk kaarten, disks, etc.

Event Log

Regelt toegang tot het eventlog. Een specifieke eigenschap van deze provider is dat hij notificaties kan genereren als er een event bijkomt.

Registry

Maakt lezen en schrijven van de registry mogelijk.

ADSI

Dit is een alternatieve ingang tot de Active Directory Services Interface. Door deze te gebruiken kunnen WMI en ADSI met één enkele ingang benaderd worden.

SNMP

Koppelt WMI met elementen die met SNMP beheerd kunnen worden.

Windows Installer

Installeren van applicaties, verwijderen, informatie opvragen.

SMS Inventory, Biztalk Server, NLB, Cluster …

Vele applicaties hebben hun eigen interface naar WMI, zodat ze via dit medium bestuurd kunnen worden.

Tabel 1: Een aantal WMI providers.  Dit overzicht is niet uitputtend. Er zijn nog vele andere beschikbaar, er worden continu nieuwe providers bij gemaakt.

De spin in het web is laag 2, de WMI informatie management laag. Deze is verantwoordelijk voor het opslaan, achterhalen en doorgeven van informatie. Het vormt de brug tussen de managing applicaties van laag 1, en de managed systems van laag 3 en 4. De CIM Object Manager (CIMOM) is verantwoordelijk voor het afhandelen van verzoeken van de laag 1 applicaties. Als CIMOM een verzoek krijgt om bijvoorbeeld de hoeveelheid beschikbare geheugen op een server te achterhalen zal het uitzoeken welke provider deze informatie levert, en daar de informatie vandaan halen. De bovenliggende applicatie hoeft deze details niet te weten. De CIMOM heeft zijn eigen opslagruimte in de CIMOM repository. Hierin bevindt zich allerlei informatie over de structuur en inhoud van de beschikbare management informatie.

De eindgebruiker heeft alleen te maken met laag 1. Hierin bevinden zich applicaties die om weten te gaan met CIMOM. Omdat de CIMOM is geïmplementeerd als een COM object kan iedere applicatie die weet hoe met COM objecten om te gaan, in principe gebruik maken van WMI. Concreet betekent dit dat het mogelijk is om bijvoorbeeld gebruik te maken van de Windows Script Host om WMI te benaderen. Met behulp van script talen die door WSH ondersteund worden (zoals VBScript, JScript, Perl, en ASP) kan systeem informatie opgevraagd worden, en tot op zekere hoogte zelfs gewijzigd worden. Verderop in het artikel komen een aantal voorbeelden aan bod. Uiteraard kan de CIMOM ook benaderd worden door gecompileerde programma's die gebruik maken van programmeertalen als de C-familie of Visual Basic. Een niet onbelangrijke interface naar CIMOM is ODBC (o.a.  te vinden op de Windows 2000 server CD), iets wat database beheerders zeer aan zal spreken. Maar de meeste mensen zullen vooral gebruik maken van WMI door beheerders applicaties als SMS, CA TNG, Tivoli, HP OpenView, Compaq Insight Manager, enz. Voor hen is het wellicht aardig om te weten wat zich nu onder de oppervlakte afspeelt. Voor de volledigheid is het goed om op te merken dat een aantal managed systems (zoals SNMP, ADSI etc.) ook buiten de WMI om benaderd kunnen worden. WMI is namelijk een redelijk recente ontwikkeling, zodat veel beheerders applicaties ook direct deze systemen kunnen benaderen. WMI is in dit kader vooral interessant voor managing applicaties omdat het een uniforme toegang biedt tot de onderliggende systemen, waarbij onderliggende en irrelevante implementatie details verborgen blijven. 

Basisprincipes en Objecten

Voor diegenen die zelf programma's of scripts willen maken om WMI te benaderen is het de moeite waard om verder in te gaan op laag 2 van de architectuur, CIMOM. WMI is een object-georienteerde structuur. Alles wat met WMI bekeken kan worden is gedefinieerd in een klasse. Een voorbeeld van een klasse die later in het artikel nog besproken wordt is Win32_Process. Een klasse heeft eigenschappen (properties in het jargon) waarmee statische informatie opgevraagd kan worden, en methoden (methods) waarmee een opdracht uitgevoerd kan worden. Deze begrippen zijn ruwweg vergelijkbaar met variabelen en functies. De klasse Win32_Process heeft bijvoorbeeld de eigenschap Name, dat de naam van een proces beschrijft. Een methode is Create, waarmee een proces gestart kan worden. Het is essentieel om u te realiseren dat een klasse slechts een definitie is. Een klasse wordt concreet gemaakt door er een instantie van te creëeren, en aan die instantie wordt informatie opgevraagd. Ieder proces heeft zijn eigen instantie van klasse Win32_Process. Dit is een belangrijk punt: een instantie stelt een bestaand object in het systeem voor, en kan gebruikt worden om actuele informatie op te vragen. Tot zover de conceptuele achtergrond. Aan de hand van een simpel voorbeeld in VBScript wordt verder toegelicht hoe het in elkaar steekt.

    For Each oProcess In GetObject("winmgmts:{impersonationLevel=impersonate}")._
        InstancesOf("Win32_Process")
            WScript.Echo oProcess.Name
    Next

WMI wordt benaderd met de naam "winmgmts" in de opdracht GetObject().  In het algemeen moet aan WMI verteld worden met welke authenticatie gegevens gewerkt wordt. De string '{impersonationLevel=impersonate}' betekent dat gebruik gemaakt wordt van de gegevens van de huidige gebruiker. Deze authenticatie specificatie is niet nodig onder Windows 2000 waar dit de default is, maar wel voor oudere WMI clients zoals NT4 en W9x. De functie GetObject() geeft een instantie van CIMOM terug. Aan CIMOM wordt gevraagd met de methode InstancesOf() om een volledige verzameling instanties van de klasse Win32_Process terug te geven. Iedere instantie wordt bij toerbeurt toegekend aan de object variabele oProcess. Een eigenschap van Win32_Process is Name, en deze wordt gebruikt om de naam van iedere proces instantie op te vragen. In gewone mensentaal: dit script print een lijst van alle lopende processen.

De CIMOM heeft nog meer functionaliteit, die in de komende voorbeelden nader worden toegelicht. Een belangrijk aspect is dat het een eigen query taal kent, de WMI Query Language (WQL). Hiermee kunnen in een op SQL lijkende taal allerlei condities worden gesteld aan de op te vragen informatie. Een andere functionaliteit is de mogelijkheid om periodiek te kijken naar managed systems. Denk hierbij aan het opvragen van de CPU load iedere 5 seconden, en een actie te ondernemen als er iets mis is. Een aantal providers zoals de EventLog kunnen zelf een actie genereren, maar voor providers die dit niet kunnen zoals Win32 levert CIMOM de benodigde infrastructuur.

Een heel praktische vraag is hoe u nu aan alle informatie komt die u nodig hebt om scripts te schrijven. De belangrijkste bron is Microsoft zelf. Er is een WMI software development kit (SDK) beschikbaar voor download. Deze SDK is een absolute vereiste om zelf aan de slag te kunnen gaan. De belangrijkste ingrediënten van de SDK zijn een uitgebreide helpfile, een klasse-browser, en een object browser. Figuur 2 laat zien hoe de object browser eruit ziet. Naast de WMI SDK zijn er een aantal artikelen te vinden op MSDN en Technet. Er lijkt nog weinig verdere literatuur te bestaan over dit onderwerp. Dit zal ongetwijfeld nog komen. Dit krachtige maar moeilijke onderwerp verdient een goed handboek en naslagwerk.

Figuur 2: De WMI Object browser is beschikbaar in de WMI SDK. Hiermee kunnen bestaande objecten in het systeem bekeken worden, net zoals dat met een programma of script kan gebeuren.

Voorbeelden

De nu volgende voorbeelden laten zien hoe je in de praktijk met WMI gegevens kunt opvragen, monitoren of hoe je actief kunt ingrijpen in een systeem. De voorbeelden gaan vanaf relatief eenvoudig tot meer ingewikkelde scripts.

Het beste kunnen de scripts met cscript ipv wscript worden uitgevoerd, de output ziet er dan iets logischer uit.

listshares

    sServer = "localhost"
    Set oShareSet = GetObject("winmgmts:{impersonationLevel=impersonate}!//" &  sServer)._
    InstancesOf ("Win32_Share")
    For Each oShare In oShareSet
        Wscript.Echo oShare.Name & " --> " & oShare.Path
    Next

Dit voorbeeld is iets meer uitgeschreven dan het eerdere servicevoorbeeld. Eerst koppelen we oShareSet aan de share informatie, daarna laten we deze zien. Het voorbeeld gaat uit van de lokale machine, het is eenvoudig om dit aan te passen voor het bekijken van een machine elders.

Listdisks

    For Each oDisk In GetObject("winmgmts:").ExecQuery("select * from Win32_LogicalDisk where FileSystem != NULL")
        WScript.Echo oDisk.Name & "," & oDisk.VolumeName & "," & oDisk.Size & "," & oDisk.Filesystem
    Next

Dit kleine voorbeeld laat zien hoe je een WMI Query kan uitvoeren om informatie op te vragen. In dit voorbeeld betreft het diskinformatie. De Query selecteert alle disks die een filesystem hebben, d.w.z., die geformatteerd zijn.

listprocesses

    For Each oProcess In GetObject("winmgmts:").InstancesOf ("Win32_Process")
        Call oProcess.GetOwner (sUserID, sDomain)
        WScript.Echo oProcess.Name & "," & sDomain & "\" & sUserID & "," & oProcess.WorkingSetSize
    Next

Het is natuurlijk wel handig om taskmanager bij de hand te hebben. Echter nu kun je niet alleen snel lokaal procesinformatie opvragen maar ook op afstand. In dit voorbeeld wordt de methode GetOwner, behorende bij klasse Win32_Process, gebruikt om de eigenaar van een proces en diens domein bij naam op te vragen.

Startproces

    sServer = "localhost"
    sCmd ="notepad.exe"
    Set oProcess = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & sServer & "\root\cimv2:Win32_Process")
    If oProcess.Create (sCmd, Null, Null, ProcessId) = 0 Then
        WScript.Echo "Started " & sCmd & " on " & sServer & " with ID " & ProcessID
    Else
        WScript.Echo "Could not start " & sCmd
    End If

Nog een proces erbij? Dat kan heel eenvoudig met WMI. Net als in het vorige voorbeeld wordt er een Method van WMI gebruikt om het werk te doen.

reboot

    sServer="PDC01"
    sID="mrHacker"
    sPW="GuessThisPW!"

    Set oLocator = CreateObject("WbemScripting.SWbemLocator")
    Set oService = oLocator.ConnectServer(sServer, "", sID, sPW)
    Set oOSSet = oService.ExecQuery("select * from win32_operatingsystem where primary=true")
    For Each oOS in oOSSet
        wscript.echo "Will boot " & oOS.CSName & " running " & oOS.Caption
        oOS.Reboot()
    Next

Natuurlijk hebben we niet altijd de juiste credentials voor het uitvoeren van een handeling. Dit reboot script lost het op door aan te loggen op de andere machine met de juiste credentials. Door expliciet van de Wbem objects gebruik te maken in plaats van GetObject() het werk op te laten knappen kunnen expliciete gebruikersnamen en wachtwoorden doorgegeven worden. Dit script kan dus door iedere willekeurige gebruiker aangewend worden om een server te laten booten, mits uiteraard er op die server het benodigde account met administratieve rechten aanwezig is. 

Set oEvents = GetObject("winmgmts:").ExecNotificationQuery _
    ("select * from __instancecreationevent within 5 where targetinstance isa 'Win32_Process'")
Do
    Set oProcess = oEvents.NextEvent.TargetInstance
    WScript.Echo "New Process : " & oProcess.Name & ", ID: " & oProcess.ProcessID
    For Each oAssociator In oProcess.Associators_
        s = oAssociator.Path_.DisplayName
        WScript.Echo "    --> " & Mid (s, InStr(s, """"))
    Next
Loop

Een interessant gebruik van monitoring. Dit script wacht tot het een event krijgt over het starten van een nieuw proces en geeft dan de informatie over dit proces weer. Met behulp van method ExecNotificationQuery() wordt WMI gevraagd om een query om de 5 seconden uit te voeren. Het speciale object __instancecreationevent bevat onder meer alle nieuwe processen sinds de laatst uitgevoerde query. In een loop wordt gewacht op NextEvent, en wanneer er iets gebeurt (d.w.z. de query geeft een resultaat) wordt de bijbehorende informatie geprint. De eigenschap Associators_, dat ieder WMI object heeft, legt een verbinding met bijbehorende objecten. In dit geval zijn dat onder meer de dll's die het proces geladen heeft.

ODBC

Het kan natuurlijk zijn dat scripten u niet zo ligt omdat u er bijvoorbeeld nog weinig ervaring mee heeft. Scripten is pas recentelijk op het Windows platform echt belangrijk geworden en verdient zeker uw aandacht. Het is echter, zoals uit het architectuur overzicht al bleek, perfect mogelijk om op andere wijze WMI te benaderen voor het verkrijgen van management informatie. Een van de meest elegante oplossingen is het gebruikmaken van ODBC in combinatie met bijvoorbeeld Access. Wanneer u een beetje handig bent in het gebruik van deze database toepassing kunt u de meest prachtige overzichten maken die zeker indruk zullen maken. Ook in een wat kleinere omgeving kunt u op deze manier nuttig gebruik maken van WMI zonder gelijk een duur management pakket in te zetten.

Om een overzicht te maken met ODBC dient u eerst de WBEM ODBC te installeren. Deze bevind zich in de \VALUEADD\MSFT\MGMT\WBEMODBC directory van onder meer de Windows 2000  CD. Wanneer u dit heeft gedaan kunt u tabellen importeren vanuit WMI door gebruik te maken van de systeem DSN die nu tot uw beschikking staat.

Figuur  3: Importeren van een tabel uit WMI

Middels het dialoog wat de ODBC driver aan u presenteert kunt u zowel een verbinding maken met uw eigen machine als met een ander, U hoeft alleen de juiste gegevens in te vullen en een namespace te selecteren. In dit voorbeeld hebben wij de CIMV2 namespace gekozen. Wanneer u de keuze bevestigt, kunt u vervolgens tabellen importeren, Figuur 4 laat een overzicht zien van aanwezige services. Even zo makkelijk kunt u andere overzichten maken, bijvoorbeeld een overzicht van gebruikersaccounts.

Figuur 4: WMI met ODBC, een lijst van services.

De toekomst

Microsoft is begonnen om met Windows 2000 de WMI functionaliteit te integreren. Het zal niemand verbazen dat hierop wordt voortgebouwd in de opvolger van Windows 2000, Windows XP (werkstation) en Whistler (voorlopige naam voor de server edities). De volgende zaken zijn noemenswaardig:

  • Het wordt mogelijk om Active Directory replicatie te volgen met WMI.
  • Datum & tijd kunnen met WMI gezet worden. Headless servers zijn een toepassing.
  • Disk Quota's kunnen met WMI gelezen en gezet worden, zowel globaal als op gebruikersniveau.
  • Netwerk shares en DFS kunnen geconfigureerd worden.
  • CHKDSK kan met WMI (remote) gestart worden.
  • Aardig: WMI krijgt een ping functionaliteit.
  • Belangrijk: allerlei print functies kunnen via WMI geregeld worden.
  • Applicaties als IIS, Terminal Servers etc., krijgen WMI functies.

Figuur 5: Whistler heeft een MMC snap-in voor WMI configuratie.

Er komt een nieuwe MMC snap-in XP en Whistler om WMI te configureren. Het schijnt dat er ook een commandline WMI 'shell' komt om WMI te benaderen. Dit is analoog aan het krachtige commando netsh.exe in Windows 2000 dat alle netwerk configuraties kan uitlezen en configureren.

Samenvatting & resources

WMI is weliswaar jong maar blijkt in Windows omgevingen een waardevolle toevoeging te zijn om deze systemen te kunnen managen. Het moge niet verwonderlijk zijn dat veel fabrikanten WMI gebruiken om informatie te verzamelen. Door de standaardisering die WMI brengt kan tenslotte veel eenvoudiger informatie worden verzameld.

Windows 2000 wordt geleverd met WMI ingebouwd. Voor eerdere versies is de software gratis te downloaden zodat er ook op NT 4 en Windows 9x gebruik kan worden gemaakt van WMI. In de opvolger van Windows 2000, Windows XP is de WMI techniek nog verder uitgebreid waardoor er nog meer mogelijkheden zijn. Doordat er middels diverse technieken zoals scripting, maar ook ODBC gebruik kan worden gemaakt van WMI is het voor veel toepassingen interessant. In een volgend artikel zullen we laten zien hoe de informatie die je op deze wijze kunt verzamelen efficiënt kan worden opgeslagen en gebruikt.

Links

De scripts uit dit artikel : http://www.win2kwereld.nl/downloads/wnwmi.zip
Scriptinginformatie: http://msdn.microsoft.com/scripting

WMI Software Development Kit: http://download.microsoft.com/download/platformsdk/sdkx86/1.5/NT45/EN-US/wmisdk.exe

Willem Kasdorp is als consultant werkzaam bij CMG Finance B.V.
E-mail:
willem.kasdorp@cmg.nl

W. Verveen is verbonden aan de Ormer groep als Consultant, daarnaast beheert hij Win2K Wereld
E-mail: w.verveen@ormer.nl
Web: http://www.ormer.nl en http://www.win2kwereld.nl


privacy policy