Today we are covering WMI or Windows Management
Instrumentation. WMI is something that I have had some experience with in the
past through SMS, CA Unicenter, and other administrative applications. It opens up a whole
new world of information that is ripe for the picking.
WMI is setup in a hierarchical structure
similar to almost everything that Microsoft builds. WMI is held in Root\CIMv2.
Under that you have the Namespaces. Below the namespaces you have the Classes
and each class has a set of properties and methods, and a few other things. Don
mentions something in this chapter I was not aware of and that can be a little
tricky. Under the different classes there may be multiple instances of that
class running for one reason or another (different user accounts, multiple
instances of a service, etc…).
Exploring WMI can be a little bit
daunting for the average administrator as there is no way of actually searching
for anything. What this means is that everything is a hunt for the correct
information you are looking for or you can use your trusty search engine.
The tools that you can use to look at
the namespaces and properties can make this a little easier. Don mentions one
in the book, and it is a good one, called WMI Explorer. It is a free tool that
is found on on the www.primalscripts.com
website under there downloads section. Now you do have to register for an
account to download it, but it is worth the time as there are a lot of other
useful tools from Primal that are free. There are also numerous downloads from www.CNET.com if you do a search for WMI
Explorer. If you are in a bind and don’t have time to download anything (or
cant in some cases), there is a WMI tool built into windows. It is called
WBEMTEST, and works in a pinch but is a bit trickier to navigate. You can
access this from the CMD prompt or the run box by typing WBEMTEST.exe This is a great article on Technet about its use and can be found here, http://technet.microsoft.com/en-us/library/cc785775%28v=ws.10%29.aspx
How does PowerShell access WMI? There
is a handy little cmdlet called Get-WMIObject, or aliased as GWMI. Since PowerShell
does not work directly with WMI there is a bit of a learning curve due to the
difference in syntax structure and the way the WMI properties are referenced. For
instance If you wanted to see a list of all namespaces from your console, type:
Get-WMIObject –namespace root\cimv2 –list
This is a pretty expansive list but
you can filter it if you have an idea of what you are looking for. The Help
file will be of much more use than I could be trying to explain it so check it
out (Help GWMI –full).
Point of note, PowerShell does not contain
any help on the actual properties and methods for any of the classes of WMI.
Also WMI has not been very well documented and was generally a use as you want
it for the different product development groups within the company. That is until
recently and now they are trying to change that. A good bit of information can
be had from the Microsoft Developer Network (http://msdn.microsoft.com)
now contains a lot of information, although search engines are still a good way
of finding specific class info.
One thing I would like to add on here
is that in the book Don references a way of showing all the software installed
on a given machine with WMI. The class for this is Win32_Product, and can be a
very bad thing to use in an enterprise. I have had issues in the past With SMS,
CA Unicenter, and administrative scripts that called this class. Basically what
this does is cause WMI to look at each software install and perform a
Reconfiguration Operation as a way of verifying the application is installed. This will cause this query not only to be slow but
is very processor and memory intensive on the servers that you run it
against. You can verify this is happening by going to your event viewer under applications (I
think), and you will see a Event ID 1035 for every program installed on your
system. I would not recommend using this. The
Registry is still a much safer bet.
Ill be updating tomorrow, but until
then have a great day.
No comments:
Post a Comment