WMI - Introduction

What is WMI?
Windows Management Instrumentation, or WMI, is Microsoft's implementation of the Web Based Enterprise Management (WBEM) standard set forth by the Distributed Management Task Force (DMTF). OK, that was a mouth full. In simpler terms, WMI allows us to access system resources on a Windows system remotely by utilizing a common set of services, providers and classes. This means that now we have a set of tools that will allow us to view and modify the registry, monitor system and process performance, administer file system permissions and shares and so much more all from the comfort of your workstation. You don't even have to remote in and interrupt the user to perform these tasks with WMI! As you can imagine the potential for this technology is vast, but how exactly does it all work? We will start by looking at the architecture of the WMI system. WMI is composed of three layers of components:

• WMI Providers and Managed Objects


• WMI Infrastructure


• WMI Consumers

WMI Providers and Managed Objects

WMI providers and managed objects make up the base layer of WMI. A managed object is a physical (disk drive, processor, network card) or logical (registry, database, file share) component that communicates with WMI through a WMI provider using the COM API for WMI. The WMI provider manages and monitors managed objects as well as passes information between a managed object and the WMI infrastructure layer.

WMI Infrastructure

The WMI Infrastructure is the glue between the base and consumers. WMI infrastructure is composed of two primary components, the WMI service and the WMI repository. The WMI service is acts as a message passer between the consumers, the providers and the repository. One key piece of the WMI service is WMI core, also known as the CIM Object Manager (CIMOM). CIMOM consists of a suite of programming APIs that allow WMI consumers to work with classes in the WMI repository. The WMI repository stores static data about classes, any information that is dynamically generated is retrieved from the appropriate provider. However, the CIM Object Manager is still used to retrieve the dynamic data. WMI consumers communicate directly with the WMI service to access static classes in the WMI repository, and dynamic classes defined providers.

WMI Consumers

Applications and scripts that communicate with the WMI infrastructure are WMI consumers. WMI management applications such as the SMS Administrator Console utilize the WMI infrastructure to communicate with a remote or local system to retrieve information and perform operations on WMI classes. You can use a variety of APIs to interface your application with WMI services. C++ applications can utilize the COM API for WMI, .NET applications can use WMI .NET Architecture and scripts can access WMI using the Scripting API for WMI.

Scripting with WMI

Writing scripts that utilize WMI services is easier then you imagine. A basic WMI script does the following things:

1. Initialize and connect to the WMI service


2. Execute a WQL query


3. Process query results

Connecting to the WMI Service

In my introduction to SMS scripting article I showed you how to connect to the SMS server using two classes, SWbemLocator and SWbemServices. Utilizing these two classes provide us with the most flexible method of connecting to the WMI service, however we can also use a simpler method by using the WMI moniker. When working with SMS through scripts I almost always use the SWbemLocator class so that I may connect to the SMS resource with administrative credentials no matter where I'm at in the enterprise. However with a lot of WMI scripts we do not need the additional flexibility of SWbemLocator so we'll use a WMI moniker instead.

The WMI moniker is composed of three distinct pieces:

• Prefix


• Security


• Path

The format of the WMI moniker format is:

winmgmts:<security settings>\\<computer name>\<namespace>

The WMI moniker prefix (winmgmts:)specifies that the GetObject method to connect to the WMI service on the target host and return a reference to an instance of SWbemServices. It also good to note that the WMI moniker prefix is the only part of the WMI moniker that is required, the other pieces of the moniker are optional.

WMI security settings are set in the second part of the WMI moniker. The security piece of the moniker is optional and provides quite a bit of flexibility. Within the security piece you can specify impersonation level, authentication level, authenticating authority and privleges to grant or deny. We wont go into much detail into the security part of the moniker, but check out some of the resources at the end of the article for more detailed information.

The WMI path consists of the host name followed by the WMI namespace. The default computer is the localhost and the default namespace is root\cimv2. You specify the host name by appending \\<host> to the winmgmts: string. Now when pass winmgmts:\\host01 to GetObject it will return a SWbemServices object that references the WMI service instance on host01 using the default namespace root\cimv2. Below is quick script chunk that will connect to the WMI service on a computer using a WMI moniker and the GetObject method.

Dim oSWbemServices
Dim sHostName
Dim sNamespace

sHostName = "."
sNamespace = "\root\cimv2"

Set oSWbemServices = GetObject("winmgmts:\\" & sHostName & sNamespace)

In the above code you can change the value of sHostName to the desire host you wish to connect to, the period is another way of representing the local host. If you are accessing classes outside of the default namespace, root\cimv2, you can change the value of sNamespace to point the SWbemServices object to the appropriate namespace. As you can see connecting to the WMI service is quite simple when using a WMI moniker.

WMI Queries using the WQL

The WMI Query Language (WQL) enables you to retreive information from the CIM repository or receive notification of WMI events. If you have ever used SQL to query a database then the WQL will look very familiar to you, this is because the WQL is a subset of ANSI SQL. A basic WQL query that returns a record set of all network adapters looks like this:

SELECT * FROM Win32_NetworkAdapter

The keyword SELECT when being used in a WMI data query indicates that you want to retreive a collection of instances. The asterik indicates that you wish to return all property fields in the specified class. The FROM specifies which class you wish to retrieve the collection of instances from. In this query we specify the class: Win32_NetworkAdapter. The following script connects to the WMI service, executes the WQL query above and outputs information about each network adapter.

Option Explicit

Dim oSWbemServices
Dim sHost
Dim sNamespace
Dim sQuery
Dim oAdaptersColl
Dim oAdapter

sHost = "."
sNamespace = "\root\cimv2"
sQuery = "SELECT * FROM Win32_NetworkAdapter"

Set oSWbemServices = GetObject("winmgmts:\\" & sHost & sNamespace)

Set oAdaptersColl= oSWbemServices.ExecQuery(sQuery)

For Each oAdapter In oAdaptersColl
    WScript.Echo "Name:" & vbTab & vbTab & oAdapter.Name
    WScript.Echo "Description:" & vbTab & oAdapter.Description
    WScript.Echo ""
    WScript.Echo "Manufacturer:" & vbTab & oAdapter.Manufacturer
    WScript.Echo "Product Name:" & vbTab & oAdapter.ProductName
    WScript.Echo ""
    WScript.Echo "MAC Address:" & vbTab & oAdapter.MACAddress
    WScript.Echo _
"-----------------------------------------------------------------------------"
Next

If you execute the above script using cscript.exe from a command prompt you should see a listing of all of the network adapters currently installed on your computer. Notice that in the above we query we are retreiving all properties in the Win32_NetworkAdapter class but we are only using five of them. The Win32_NetworkAdapter class has over thirty properties and we are using up valuable system resources by retrieving them all. This becomes much more apparent when you are accessing classess that have hundreds or thousands of instances. Instead of retreiving all properties we can change the asterik in the WMI query to a comma delimited list of properties. Are new query then looks like:

SELECT Name, Description, Manufacturer, ProductName, MacAddress 
FROM Win32_NetworkAdapter

As you can imagine when working with large record sets not having to retrieve every property of a class can save quite a bit of execution time. Experiment with some different WMI classes and see what type of information you can retrieve from your computer, I think you will end up being surprised. In the future we will look at the SWbemServices class in detail, as well as diving into the WQL and using it for some more advanced queries.

Resources

Distributed Management Task Force (DMTF)

Web Based Enterprise Management (WBEM)

Common Information Model (CIM)

WMI SDK Documentation

COM API for WMI

WMI .NET Architecture

Scripting API for WMI

WMI Security Settings

Constructing a Moniker