Windows Management Instrumentation (WMI) är en fantastisk Microsoft-teknik som kan hjälpa dig att hantera dina system bättre: den är lika användbar för utvecklare, som gör det möjligt för dem att exponera hanteringsaspekterna av sina applikationer. I den här kolumnen ska jag undersöka vad WMI är, dess arkitektur och hur du använder det. Och, som i de flesta av mina senaste kolumner, kommer jag att presentera PowerShell-exempel för att illustrera. WMI är strängt taget inte en del av .NET Framework, men att komma åt WMI-objekt är så som att komma åt andra .NET-objekt att det är lätt att använda tillsammans med andra .NET-komponenter.
Innan vi går in i detaljerna, ett tips till Austin Osuide, som höll ett utmärkt föredrag om WMI på May UK PowerShell-användargruppen. Hans entusiasm för WMI (och, naturligtvis, för PowerShell) övertygade mig om att detta var ett bra ämne för den här kolumnen, och jag har hans bilder om någon läsare vill ha dem.
Vad är WMI?
WMI är Microsofts implementering av DTMF:s (Desktop Management Task Force) webbaserade företagshantering och CIM (Common Information Model), och som sådan tillhandahåller den icke-proprietära och miljöoberoende mekanismer för att manipulera information om alla komponenter i ett datorsystem. WMI låter dig övervaka och kontrollera nästan alla datorresurser i hela ditt företagsnätverk, inklusive hårdvara som batterier, BIOS, diskenheter och nätverkskort. Du kan använda WMI för att hantera processer, tjänster, delningar, registerinställningar, händelseloggar, användare, grupper och mer. WMI kan också upptäcka händelser när de inträffar (t.ex. när en tjänst har stoppats) och meddela en WMI Event-konsument.
WMI är inbyggt i alla versioner av Windows 2000 och senare och kan installeras på vilken annan 32-bitars Windows-klient som helst. Före WMI, om du ville ha tillgång till informationen och funktionerna som den levererar, hade du varit tvungen att skriva Win32 API-anrop med C++, eftersom dessa anrop vanligtvis inte var tillgängliga för skriptspråk.
WMI-arkitektur
WMI-arkitekturen har tre huvudkomponenter:
WMI-leverantörer (och hanterade objekt) – COM-objekt som ger åtkomst till hanterade objekt. Ett hanterat objekt är en datorkomponent som en process, en hårddisk och så vidare.
WMI-infrastruktur – kärn OS-komponenter som ger konsekvent åtkomst till WMI-hanterade objekt.
WMI-konsumenter – hanteringsapplikationer eller skript som interagerar med infrastrukturen för att använda leverantörens objekt.
Flera leverantörer är implementerade som standard i operativsystemet (se www.pcpro.co.uk/links/155dotnet1 för mer information om WMI-leverantörer implementerade i Windows). Till exempel i Windows XP är Win32-leverantören installerad som standard, medan du valfritt kan installera SNMP-leverantören via Kontrollpanelens applet Lägg till/ta bort program. Andra applikationer, som Office Communications Server 2007, tillhandahåller ytterligare WMI-klasser och använder WMI för att komma åt denna information. Microsoft-applikationer är i allt högre grad WMI-aktiverade, både tillhandahåller WMI-klasser och använder dem.
WMI-klasser liknar alla andra .NET-klasser som jag har illustrerat i tidigare kolumner, och som dessa erbjuder de metoder du kan anropa och egenskaper du kan hämta och ställa in. Den enda signifikanta skillnaden är metoden för att instansiera individuella klasser. Det finns 954 klasser på min Windows XP SP2 bärbara dator, medan det på ett av mina Windows Server 2003-system finns 882, och på min Longhorn Beta 3 virtuella maskin finns det 1 003: några av dessa är WMI-systemklasser (53 av dem på min XP systemet). En WMI-leverantör består av en DLL-fil som innehåller dess kod och en MOF-fil (Managed Object Format) som definierar de klasser för vilka denna leverantör returnerar data och utför operationer. Systemklasser har klassnamn som börjar med två understreckstecken, till exempel __Händelse, och brukar inte vara till nytta för IT-administratörer. Å andra sidan stöder Win32-leverantören 564 klasser som är av intresse för IT-proffs.
