Of course we cannot always share details about our work with customers, but nevertheless it is nice to show our achievements and share some solutions.
A while ago (in 2016) I created an automatic Icinga2 config tool (i2ac)* for Windows hosts and Cisco switches. To create the config files for the Windows hosts, I needed to find a way to query the hosts for specific information and came across WMI. See related articles Use WMI for monitoring auto-discovery on Windows Server and Accessing WMI through a firewall - which ports are required.
* for once not open source, sorry - too customized for this specific environment
Using WMI with wmic turned out to be a good choice but there was one caveat: To list all the services on the target Windows host, a local Administrator user was required. In a large environment with a couple of hundred servers this means: Domain Admin (again, see Use WMI for monitoring auto-discovery on Windows Server why). This was always somewhat annoying to me because using a Domain Admin user for read-only purposes (such as monitoring) is just overkill and a security risk.
Today we reviewed the way the information is fetched from Windows and it was suggested why not use NSClient++ for it, because NSClient++ will at the end be the daemon used for monitoring the host. Yes and no. When I programmed i2ac, I came across a couple of problems when I used the NSClient++ output. I don't remember exactly what they were but there was a problem with getting the correct data back (filtering and output style). Anyway, in 2016 NSClient was at version 0.4.x, meanwhile there is 0.5.x out and maybe some listing/discovery options have changed.
That's when I came across the CheckWMI module in NSClient++. This module enables a NRPE check_command (check_wmi) and accepts a WMI query which is then executed locally. To enable the CheckWMI module, the nsclient.ini needs to be adjusted and the CheckWMI module needs to be enabled:
CheckExternalScripts = 1
CheckHelpers = 1
CheckNSCP = 1
CheckDisk = 1
CheckSystem = 1
CheckWMI = 1
NSClientServer = 1
CheckEventLog = 1
NSCAClient = 1
NRPEServer = 1
CheckLogFile = 1
SimpleFileWriter = 1
SimpleCache = 1
A comparison between a remote WMI query using wmic and a local WMI query via NSClient++ and check_nrpe shows the same output:
admck@linux:~$ /usr/bin/wmic -U domain/admin%password //windowshost 'select DeviceID from Win32_LogicalDisk WHERE DriveType = 3'
admck@linux:~$ /usr/lib/nagios/plugins/check_nrpe -H windowshost --command check_wmi -a "query=select DeviceID from Win32_LogicalDisk WHERE DriveType = 3"
C:, D:, P:|
The WMI query itself is the exact same and the output is the same too, just in another format. If the exact output style is needed, the output can be run through sed:
admck@linux:~$ /usr/lib/nagios/plugins/check_nrpe -H windowshost -c check_wmi -a 'query=select DeviceID from Win32_LogicalDisk WHERE DriveType = 3' | sed 's/[,|]//g' | sed 's/\s/\n/g'
The biggest advantage: The remote login using the Domain Admin user (here: domain\admin) is not needed anymore!
The reason why a Domain Admin user needed to be used was the service lookup. Without a local Administrator user not all services would be shown, leading to an incomplete service discovery and therefore to an incomplete monitoring of this Windows host. Will all services show up using the WMI query through NSClient++, too?
Service discovery (all running services) using wmic with a local Administrator:
admck@linux:~$ /usr/bin/wmic -U domain/admin%password //windowshost 'select Name from Win32_Service WHERE State = "Running"'
Using the WMI query via NSClient++:
admck@linux:~$ /usr/lib/nagios/plugins/check_nrpe -H windowshost -c check_wmi -a 'query=select Name from Win32_Service WHERE State = "Running"'
ADSync, Appinfo, AzureADConnectHealthSyncInsights, AzureADConnectHealthSyncMonitor, BFE, BITS, BrokerInfrastructure, CertPropSvc, COMSysApp, CryptSvc, DcomLaunch, Dhcp, DiagTrack, Dnscache, DPS, EventLog, EventSystem, FontCache, gpsvc, IKEEXT, iphlpsvc, KeyIso, LanmanServer, LanmanWorkstation, lmhosts, LSM, MpsSvc, MSDTC, msoidsvc, Netlogon, netprofm, NlaSvc, nscp, nsi, pla, PlugPlay, PolicyAgent, Power, ProfSvc, RpcEptMapper, RpcSs, SamSs, Schedule, SENS, SepMasterService, SessionEnv, ShellHWDetection, Spooler, SQLWriter, SystemEventsBroker, TermService, Themes, TrkWks, UALSVC, UmRdpService, VGAuthService, VMTools, W32Time, Wcmsvc, WinHttpAutoProxySvc, Winmgmt, WinRM, WSearch, wuauserv, Zabbix Agent|
This is working just fine, too.