In NMIS version 8.6.0 we've added support for collecting data from Windows systems using the Windows Management Instrumentation infrastructure (or short WMI).
This this page describes how to approach modelling devices for WMI, and where WMI modelling differs from modelling for SNMP.
To collect WMI data NMIS has to use a WMI access tool. At of 8.6.0 we are using
wmic, a commandline tool belonging to the Samba software suite.
NMIS 8.6.0 ships with a precompiled
wmic program, and installs it as
/usr/local/nmis8/bin/wmic. If the precompiled version should not work on your platform, the installer will notify you of that problem and you'll have to perform a manual build of
wmic. The sources for
wmic can be downloaded here: http://dl-nmis.opmantek.com/wmic-omk.tgz and you shouldn't have to do more than unpack that, and run
make. When the build is complete, you should copy the resulting
wmic file to
On the target systems, the WMI service must be running and the network (and any firewalls) must be configured to let WMI accesses pass. WMI accesses are generally negotiated to use dynamic ports (following up on an initial conversation on TCP port 135), but Microsoft provides instructions on how to setup fixed ports for WMI.
NMIS does not attempt any WMI accesses unless the node in question is configured with both a
wmiusername and a
wmipassword property. This can be done in the GUI, under "Edit Node'; the WMI options are shown prominently near the top of the page.
If the node in question requires a domain prefix for the WMI access, prepend that to the
wmiusername followed by a "/", e.g. "
We recommend that you verify the availability of WMI (and your credentials) with
wmic, before performing any modelling work. This should be done using the
wmic tool on your NMIS server, like in the following example:
If WMI is properly configured and the access details match you'll see output similar to the three lines shown.
Besides using the standard Widows models that NMIS ships with as examples, you will likely also need to consult the online WMI reference documentation for determining what is available in the WMI universe where and how to tell NMIS about it.
WMI Modelling in a nutshell
Let's examine an example model:
Here are the crucial aspects:
- Wherever an
snmpsection is allowed in a model, you may add a
- A model may have either or both
wmisections, but the collected variables must be uniquely named.
- Just like SNMP sections, a WMI section consists of any number of variable collection definitions.
- A WMI section may also contain a section called
-common-, which specifies a shared
queryproperty for variables without explicit
- A WMI variable definition must have a
query(or inherit one from
-common-) and a
queryis issued to the host in question using the
wmictool, and must at least select the field/column you're interested in.
For efficiency you should use the same combined query for as many variables in your section as possible; i.e.
select * from someclass.
If you have multiple variables in your section and set the same query argument for all of them, then NMIS will issue the query just once and reuse the results.
The same goes if you use the
-common-mechanism as shown in the example above, in which case you don't have to give your variable section an explicit
fieldis used to select the column or property from the query result.
The field is case-sensitive! (The
selectattributes are generally not.)
- All other NMIS modelling mechanisms work the same, i.e.
Here is another example, this time of an indexed
This example illustrates one more crucial aspect:
- If your WMI-sourced variables are indexed (i.e. belong to a table with multiple instances), then you must set the
indexedmodel property to the name of the variable.
And, of course, there must be a variable section for the given variable to index by (in the example above, it's called
Nameand indicates the name of the page/swap file).
- If you are collecting such variables both for current display (
syssection) and long-term collection (
rrdsection), then both sections must contain the same indexed property, not just 'true'.
In an SNMP section under
rrd, 'true' is sufficient because the property to index by can be deduced in that case. For WMI this doesn't hold.
WMI Modelling Limitations
As of version 8.6.0 there are a few modelling limitations that we plan to remedy incrementally.
- It is not possible for a
systemHealthsection to have both
This is because only one index per
systemHealthsection is supported, but
snmpcan not share that single index.
- At this time, collection of the following types of statistics from WMI is not supported:
Server-type processor and load information
that for systemhealth stuff, BOTH sys and rrd sections must include indexed => actual field name, not just 'true'
that one systemhealth section can only have snmp or wmi, because one index governs the whole section
inefficiencies, queries are not rewritten to select only specific fields
inefficiencies, queries are also not rewritten when an indexed table row is fetched, so the whole table will be refetched