Jaa

Component Tales: Windows Management Instrumentation (WMI)

  • Artikkeli

[The following article is authored by one of the Windows Embedded MVPs (Most Valuable Professionals). Our MVPs have a heavy background in Embedded systems and are a great repository of information on Windows Embedded products. We’re providing this space on our team blog as a service to our readers by allowing MVPs to share some of their knowledge with the rest of the community.]

During the course of a Windows Embedded Standard project it is common to need to configure the OS image or to read information from the image, be it for documentation purposes or to plan your next steps based on this information. The Windows standard API for getting this information or accomplishing these tasks is called Windows Management Instrumentation (WMI). Think of it as a very powerful tool, like a Swiss army knife, that provides access to nearly all settings and configuration methods on a Windows system. WMI does not only come in handy for devices in the field, but there are quite a few other occasions where this infrastructure is able to provide valuable services creating devices, such as automating post-FBA configuration..

Getting WMI into the image

Windows Management Instrumentation is contained in the WMI macro component found under Software\System\Management\Infrastructure in the component catalog.

image

WMI is built as an extensible infrastructure, which means that the different Windows subsystems are required to publish their settings with the help of WMI providers and need to follow certain implementation rules. As one can see in the image above, the list of selectable functionalities is quite long. Therefore, when developing an embedded image, only the required technologies should be selected. Otherwise the footprint impact of including all of WMI is huge. A complete installation will add a maximum of 150 MB to the overall image size.

Extending WMI

In highly functional embedded images the idea of having an extendable configuration infrastructure is very interesting. One could write a WMI provider for custom applications or a custom shell to make its data and capabilities accessible via this infrastructure. All you need to do is to implement the required interfaces as specified in the WMI SDK.

Using WMI

But before you get into the game of extending WMI, you most probably would start off using the standard offerings. Here are some samples of common scenarios:

  • Automating post-FBA configuration (build process)
  • Automate domain join and setting computer name (in factory)
  • Listing installed software packages and drivers
  • Configuring network settings
  • React to system changes using WMI events (e.g. network cable unplugged)
  • Change desktop environment
  • List processes
  • Remote shutdown of systems
  • Monitor process creation
  • Etc.……

The standard access to WMI is either via scripting or, programmatically, via native or managed code. When using script, WMI leverages its implementation as COM objects, which can be easily scripted with the Windows Scripting host languages VBScript or Jscript.

image

This script snippet shows how to get and display operating system information via WMI. It instantiates an object of the WMI services with the help of a moniker (which, can be thought of as a smart string that triggers an action in a Windows system). With the help of the returned service object the device then can be queried using Windows Query Language (WQL), which is derived from SQL syntax. The result of this query is a collection of objects which can be enumerated and inspected looking at properties desired.
This is not too complicated, is it?

Detecting Embedded Devices

In the example above there is a property called OSProductSuite, which should catch our attention. If it is set to “OSProductSuite=64” it proves that the system is either an XP embedded or Windows Embedded Standard system. If this number is higher, the system would be running another Windows OS. This distinction is especially important, if one does remote updates e.g. to devices in a local subnet. Checking the OSProductSuite property helps to make sure that only the embedded systems get the patch, as desired and not desktop systems that may be located in the same subnet as well.

In managed code a query for the OSProductSuite property could look like this:

image

Please note the reference to the System.Management namespace at the top. This pulls in managed wrappers for WMI COM objects and makes these available in C#. The rest of the example is pretty analogous to the scripting snippet.

WMI Resources

One of the challenges regarding WMI is coping with the overwhelming number of possibilities. A good start is to have a closer look at the WMI documentation on MSDN. In addition there is the Scripting Guys site on TechNet (well, officially it is called TechNet script center) and although it focuses on scripting, it contains a ton of valuable documentation, solution snippets and examples, which quite often leverage WMI as the underlying infrastructure. Check it out!

- Alexander

Alexander Wechsler

Wechsler Consulting

www.wechsler-consulting.de

Technorati Tags: XPe,Standard 2009

Comments