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. |
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. |
|
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}")._ 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
|
|
|
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" 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") 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") 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" 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" 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 _ 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. |
|
|
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. |
|
|
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:
|
|
|
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 : 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.
W. Verveen is verbonden aan de Ormer groep als Consultant, daarnaast beheert hij Win2K Wereld |
|
|
|||||