Date: Fri, 29 Mar 2024 07:11:46 +0000 (UTC) Message-ID: <174762158.4037.1711696306372@skald.opmantek.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_4036_38188268.1711696306371" ------=_Part_4036_38188268.1711696306371 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
In NMIS version 8.6.0 we've added support for collecting data from Windo= ws systems using the Windows Man= agement Instrumentation infrastructure (or WMI for short). As of NMIS9 = support for domains has been enhanced to make it easier to configure.
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. As of NMIS 8.6.0 =
we are using wmic
, a commandline tool belonging to the Samba s=
oftware suite.
NMIS 8.6.0 ships with a precompiled wmic
program, and =
installs it as /usr/local/nmis8/bin/wmic
. If the precompiled v=
ersion should not work on your platform, the installer will notify you of t=
hat 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 d=
o more than unpack that, and run make
. When the build is compl=
ete, you should copy the resulting wmic
file to /u=
sr/local/nmis8/bin/
.
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 accesse= s 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 WM= I.
NMIS does not attempt any WMI accesses unless the node in question is co=
nfigured with both a wmiusername
and a wmipass=
word
property. This can be done in the GUI, under "Edit Node'; the W=
MI options are shown prominently near the top of the page.
If the node in question requires a windows domain for the WMI access, th=
en In NMIS 8 prepend that to the wmiusername
followed by =
a "/", e.g. "somedomain/theuser
". In NMIS 8.6.7 and newer=
you can also provide the domain in the form "theuser@somedomain".
In NMIS9, in addition to the NMIS8 syntax, there is a dedicated 'WMI Domain=
' field to make configuration easier.
Automatic model selection does include WMI as a source of information, i=
f SNMP is not available and if wmiusername
and wmipassword
are set. Automatic Model selection in NMIS uses t=
he device property "sysDescr" (an SNMP property) for WMI only devices the s=
ysDescr is auto created from the WMI received variables "winosname" and "wi=
nversion" e.g getNodeInfo, winosname=3DMicrosoft Windows Server 2=
016 Datacenter winversion=3D10.0.14393 this string is then interp=
reted to sysDescr as Microsoft Windows Server 2016 Datacenter Wind=
ows Version 10.0.14393.
We recommend that you verify the availability of WMI (and your credentia=
ls) 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/nmis= 8/bin/wmic -U somewmiuser --password=3D'somewmipassword' //testserver "sele= ct 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 ou= tput similar to the three lines shown.
Besides using the standard Widows models that NMIS ships with as example= s, you will likely also need to consult the online WMI reference documentation for determining wha= t is available in the WMI universe where and how to tell NMIS about it.
The wmic client will accept a user in the= following format:
In the inside, NMIS calls the windows wmic client u= sing the following parameters:
/usr/local/nmis8/= bin/wmic --delimiter=3Drvqbfzsfzd -A /tmp/authfile //HOST_IP "select * from= win32_operatingsystem"
To test this exactly command, a file /tmp/authfile with the following in=
formation is needed (and for NMIS9, 'domain =3D domain
' is sup=
ported as well):
username =3D user password =3D name
We should not expect the same data as the one collect by SNMP. WMI can w= ork without snmp, but WMI data structure is different. We should probably e= xpect data in the interfaces, system and systemHealth sections.
Even though, the model should be discovered automatically, the same as i= n SNMP.
More info - Using WMI to query and monitor Windows devices
More WMI troubleshooting documentation can be found here
Let's examine an example model:
'system' =3D> = { ...lots of stuff... 'sys' =3D> { 'standard' =3D> { 'snmp' =3D> { ....lots of stuff... }, 'wmi' =3D> { 'bios' =3D> { title =3D> "Bios Name", query =3D> 'select name from win32_bios', field =3D> "Name", calculate =3D> '$r =3D~ s/\s*$//; return $r;', }, # if we want to type less, we can set a shared query - not required= , though! "-common-" =3D> { query =3D> 'select * from win32_pagefileusage' }, 'totalswap' =3D> { title =3D> "total swap in bytes", query =3D> 'select allocatedbasesize from Win32_pagefileusage'= , field =3D> 'AllocatedBaseSize', calculate =3D> 'return $r*(1<<20);', },
Here are the crucial aspects:
snmp
section is allowed in a model, you m=
ay add a wmi section
.snmp
and =
wmi
sections, but the collected variables must be uniquely named.
-common-, which specifies a shared query
property for variables wit=
hout explicit query
.
query
(or inher=
it one from -common-
) and a field
=
declaration.
query
is issued to the host in question using the select * from someclass
.-common-
mechanism as shown in th=
e example above, in which case you don't have to give your variable section=
an explicit query
property.field
is used to select the column or property f=
rom the query result.select
attributes are genera=
lly not.)replace
, nosave
etc.<=
/li>
Here is another example, this time of an indexed systemHealth=
section:
'systemHealth' = =3D> { 'sys' =3D> { 'WindowsPagefile' =3D> { 'headers' =3D> 'Name,pageTotal,pageUsage', 'indexed' =3D> 'Name', 'wmi' =3D> { "-common-" =3D> { 'query' =3D> 'select * from win32_pagefileusage', }, 'Name' =3D> { 'field' =3D> 'Name', 'title' =3D> 'Name' }, ...lots of other stuff 'rrd' =3D> { 'WindowsPagefile' =3D> { 'graphtype' =3D> 'WindowsPaging', 'threshold' =3D> 'WindowsPaging', 'indexed' =3D> 'Name', 'wmi' =3D> { 'pageUsage' =3D> { 'query' =3D> 'select * from win32_pagefileusage', 'field' =3D> 'CurrentUsage', 'calculate' =3D> 'return $r*(1<<20);', }, 'pageTotal' =3D> { 'query' =3D> 'select * from win32_pagefileusage', 'field' =3D> 'AllocatedBaseSize', 'calculate' =3D> 'return $r*(1<<20);', },
This example illustrates one more crucial aspect:
=
indexed
model property to the name of the variable.Name
and indicates=
the name of the page/swap file).sy=
s
section) and long-term collection (rrd
section), then=
both sections must contain the same indexed prop=
erty, not just 'true'.rrd
, 'true' is sufficient becaus=
e the property to index by can be deduced in that case. For WMI this doesn'=
t hold.As of version 8.6.0 there are a few modelling limitations that we plan t= o remedy incrementally.
systemHealth
section to have=
both snmp
and wmi
sections.systemHealth
section i=
s supported, but wmi
and snmp
can not share that =
single index.