...

Node Configuration

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  the WMI options are shown prominently near the top of the page.

...

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:

$ /usr/local/nmis8/bin/wmic -U somewmiuser --password='somewmipassword' //testserver "select Caption,Manufacturer,Model,Name from Win32_ComputerSystem"

CLASS: Win32_ComputerSystem
Caption|Manufacturer|Model|Name
TestServer|VMware, Inc.|VMware Virtual Platform|TestServer

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:

'system' => {
  ...lots of stuff...
  'sys' => {
    'standard' => {
      'snmp' => {
      ....lots of stuff...
      'wmi' => {
        'bios' => {
          title  => "Bios Name",
          query => 'select name from win32_bios',
          field => "Name",
          calculate => '$r =~ s/\s*$//; return $r;',
        },
        # if we want to type less, we can set a shared query - not required, though!
        "-common-" => {
          query => 'select * from win32_pagefileusage'
        },
        'totalswap' => {
          title => "total swap in bytes",
          query => 'select allocatedbasesize from Win32_pagefileusage',
          field => 'AllocatedBaseSize',
          calculate => 'return $r*(1<<20);',
        },

Here are the crucial aspects:

Modelling of Devices with both WMI and SNMP support

both data source types can be used concurrently and in parallel in a single model, but see limitations below

...

1. Wherever an snmp section is allowed in a model, you may add a wmi section.
2. A model may have either or both  snmp and wmi sections, but the collected variables must be uniquely named.
3. Just like SNMP sections, a WMI section consists of any number of variable collection definitions.
4. A WMI section may also contain a section called -common-, which specifies a shared query property for variables without explicit query.
5. A WMI variable definition must have a query (or inherit one from -common-)  and a field declaration.
   1. The query is issued to the host in question using the wmic tool, 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 query property.
   2. The  field is used to select the column or property from the query result.
      The field is case-sensitive! (The select attributes are generally not.)
6.  All other NMIS modelling mechanisms work the same, i.e. 

...

1. control, replace, nosave etc.

Here is another example, this time of an indexed systemHealth section:

 'systemHealth' => {
    'sys' => {
      'WindowsPagefile' => {
        'headers' => 'Name,pageTotal,pageUsage',
        'indexed' => 'Name',
        'wmi' => {
          "-common-" => {
            'query' => 'select * from win32_pagefileusage',
          },
          'Name' => {
            'field' => 'Name',
            'title' => 'Name'
          },
    ...lots of other stuff
    'rrd' => {
      'WindowsPagefile' => {
        'graphtype' => 'WindowsPaging',
        'threshold' => 'WindowsPaging',
        'indexed' => 'Name',
        'wmi' => {
          'pageUsage' => {
            'query' => 'select * from win32_pagefileusage',
            'field' => 'CurrentUsage',
            'calculate' => 'return $r*(1<<20);',
          },
          'pageTotal' => {
            'query' => 'select * from win32_pagefileusage',
            'field' => 'AllocatedBaseSize',
            'calculate' => 'return $r*(1<<20);',
          },

This example illustrates one more crucial aspect:

1. If your WMI-sourced variables are indexed (i.e. belong to a table with multiple instances), then you must set the indexed model 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 Name and indicates the name of the page/swap file).
2. If you are collecting such variables both for current display (sys section) and long-term collection (rrd section), 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 systemHealth section to have both snmp and  wmi sections.
  This is because only one index per systemHealth section is supported, but wmi and snmp can not share that single index.
• At this time, collection of the following types of statistics from WMI is not supported:
  Network Interfaces
  Environment Data
  CBQoS Data
  Calls
  Server-type processor and load information

that for systemhealth stuff, BOTH sys and rrd sections must include indexed => actual field name, not just 'true'

...