https://community.icinga.com/t/monitoring-windows-remotely-through-wmi/2007
Below is an example document that explains how to set up and use remote Windows monitoring through WMI with Icinga. You can adjust paths, usernames, and parameters as needed for your environment.
This guide details how to monitor Windows machines without installing an agent by leveraging the Windows Management Instrumentation (WMI) layer. It focuses on using the check_wmi_plus plugin with Icinga, along with the WMIC client on Linux. Although other methods (e.g. PowerShell, SSH, SNMP) exist, this guide covers the WMI solution primarily for legacy environments (Windows Server 2012 and later).
Tested With:
- Icinga 2 v2.10.x
- Icinga Web 2 v2.6.x
- Windows Server 2012 and later
- Prerequisites & Requirements
- Linux Setup: Installing WMIC
- Icinga/Nagios Plugin: Installing check_wmi_plus
- Windows Configuration
- Icinga Configuration
- Conclusion & FAQ
Before beginning the installation, ensure you have the following:
-
On Linux:
- A working WMIC client.
- Perl installed along with required modules (see Icinga/Nagios Plugin section for details).
-
On Windows:
- WMI enabled (usually on by default).
- A dedicated Windows user with minimal privileges but granted WMI access.
- (Recommended) WinRM and Remote Desktop enabled on the Windows node.
The WMIC tool (WMI client for Linux) is needed to query Windows systems. You can either compile it from source or use pre-packaged binaries.
-
Download the Source Code:
Visit:
http://edcint.co.nz/checkwmiplus/download/zenoss-wmi-source-v1-3-14/
Save the archive in a directory such as/usr/local/src/. -
Extract and Build:
cd /usr/local/src/ tar -xzf zenoss-wmi-source-v1-3-14.tar.gz cd Samba/source ./autogen.sh ./configure make # Optionally run "make install" if needed
-
Troubleshooting Compilation Issues:
-
If you encounter an error like:
Can't use 'defined(@array)' (Maybe you should just omit the defined()?) at ./pidl/pidl line 583.edit the indicated line to comment out the use of
defined(), then re-runmake. -
You might also see a message such as:
make: *** No rule to make target `wmi/wmiq.o', needed by `bin/wmiq'. Stop.This can be safely ignored.
-
If further errors occur, try adjusting compiler directives, for example:
make "CPP=gcc -E -ffreestanding"
-
-
Test the Installation:
Run a basic WMIC query:
wmic -U [domain/]adminuser%password //host_or_IP "select TotalPhysicalMemory from Win32_ComputerSystem"Expected output:
CLASS: Win32_ComputerSystem Name|TotalPhysicalMemory hostname|412180664
If compiling is problematic, you may consider using available RPMs or DEBs. Examples include:
-
DEB:
Debian: Inverse.ca Debian packages
Ubuntu: Inverse.ca Ubuntu packages
The plugin check_wmi_plus is written in Perl. It requires several Perl modules which can be installed either via your distribution’s package manager or CPAN.
Here is an example of the modules and the desired versions:
| Module Name | Installed Version | Desired Version |
|---|---|---|
| Config::IniFiles | 2.79 | 2.58 |
| Getopt::Long | 2.4 | 2.38 |
| DateTime | 1.04 | 0.66 |
| Number::Format | 1.73 | 1.73 |
| Data::Dumper | 2.145 | 2.125 |
| Scalar::Util | 1.27 | 1.22 |
| Storable | 2.45 | 2.22 |
| Perl Version | 5.016003 | 5.01 |
-
Install Required Perl Modules:
For example, to install a module from CPAN:
cpan install Number::Format
If you require a specific version, provide the full module distribution filename:
cpan SHLOMIF/Config-IniFiles-2.58.tar.gz
-
Download and Unpack check_wmi_plus:
Obtain the latest release from the plugin Releases page and unpack it in a directory accessible by Icinga (ideally under your custom plugin directory).
-
Adjust the Plugin Configuration:
Edit the main Perl script
check_wmi_plus.pland update:-
Location of
utils.pm:
Adjust the path if it is not in/usr/lib/nagios/plugins. -
Base Directory:
Set the$base_dirvariable to the installation directory ofcheck_wmi_plus.pl. -
WMIC Binary Path:
Update$wmic_commandwith the full path to your WMIC executable. -
Optional Settings:
Configure$wmi_ini_dir(path for INI files) and$tmp_dir(for temporary files, default/tmp/).
-
To allow remote monitoring, configure WMI on the Windows server:
-
Create a Dedicated User:
-
Open the WMI Control console:
- Press Start → Run, type
wmimgmt.msc, and click OK.
- Press Start → Run, type
-
In the console tree, right-click WMI Control and select Properties.
-
Navigate to the Security tab.
-
Select the desired namespace and click Security.
-
Click Add, enter the username (or group), verify with Check Names, and click OK.
-
In the Permissions list, adjust the following (as needed):
- Execute Methods: Enable
- Remote Enable: Enable
- Enable Account: Enable
- Read Security: Enable
- Disable write permissions (Full Write, Partial Write, Provider Write, Edit Security).
-
-
Enable WinRM and Remote Desktop in the Firewall:
Open a command prompt (with administrative privileges) and run:
netsh advfirewall firewall set rule group="remote desktop" new enable=Yes winrm quickconfig
When prompted, confirm the changes. You should see output confirming that WinRM is set up with a listener on HTTP.
-
Further Reading:
Refer to WMI for Windows Server documentation for additional details.
Once the Linux and Windows sides are ready, you need to configure Icinga to use the WMI plugin.
Create an authentication file (e.g., /etc/icinga2/wmi.auth) with the following content:
username=myusername
password=mypassword
domain=mydomain
Set proper permissions to secure the file:
chown root:root /etc/icinga2/wmi.auth
chmod 0400 /etc/icinga2/wmi.authAdd the following command definition (e.g., in your commands.conf file):
object CheckCommand "check_wmi" {
import "plugin-check-command"
command = [ PluginDir + "/check_wmi_plus.pl" ]
arguments = {
"-H" = {
value = "$host.address$"
description = "Name or IP address of host to monitor"
}
"-A" = {
value = "$wmi_authfile_path$"
description = "Authentication file path"
}
"-m" = {
value = "$check_mode$"
description = "WMI mode to use for specific check"
}
"-s" = {
value = "$wmi_submode$"
description = "Optional WMI submode"
}
"-a" = {
value = "$wmi_arg1$"
description = "First argument to WMI"
}
"-o" = {
value = "$wmi_arg2$"
description = "Second argument to WMI"
}
"-3" = {
value = "$wmi_arg3$"
description = "Third argument to WMI"
}
"-4" = {
value = "$wmi_arg4$"
description = "Fourth argument to WMI"
}
"-y" = {
value = "$wmi_delay$"
description = "Delay between consecutive WMI queries"
}
"-w" = {
value = "$wmi_warn$"
description = "Warning threshold"
}
"-c" = {
value = "$wmi_crit$"
description = "Critical threshold"
}
"--nodatamode" = {
set_if = "$wmi_nodatamode$"
}
"--inidir" = {
value = "$wmi_inidir$"
description = "Path to the INI directory"
}
}
vars.wmi_authfile_path = "/etc/icinga2/wmi.auth"
vars.wmi_inidir = "/opt/icinga/plugins/check_wmi_plus.d"
vars.wmi_nodatamode = false
}
Create a service template specifically for WMI-based checks (for example, in templates.conf):
template Service "wmi-service" {
import "generic-service"
check_command = "check_wmi"
check_interval = 1m
retry_interval = 1m
}
Then define service apply rules in a file (e.g., wmi-services.conf). Below are some sample rules:
apply Service "Free Disk Space" {
import "generic-service"
vars.check_mode = "checkvolsize"
vars.wmi_arg1 = "."
vars.wmi_arg2 = "1"
vars.wmi_arg3 = "1"
vars.wmi_warn = "88"
vars.wmi_crit = "92"
check_command = "check_wmi"
assign where host.vars.os == "Windows"
ignore where host.vars.disable_wmi
}
apply Service "CPU Utilization" {
import "generic-service"
vars.check_mode = "checkeachcpu"
vars.wmi_warn = "95"
vars.wmi_crit = "99"
vars.wmi_timeout = "160"
check_command = "check_wmi"
assign where host.vars.os == "Windows" && host.vars.cpu_utilz
ignore where host.vars.disable_wmi
}
apply Service "IIS: Connections" {
import "generic-service"
vars.check_mode = "checkiis"
vars.wmi_submode = "connections"
vars.wmi_arg1 = "_Total"
vars.wmi_timeout = "190"
check_command = "check_wmi"
assign where host.vars.iis_server
ignore where host.vars.disable_wmi
}
apply Service "MSSQL: General Statistics" {
import "generic-service"
vars.check_mode = "checksql"
vars.wmi_submode = "general"
if (host.vars.mssql_edition == "Express") {
vars.wmi_arg1 = "MSSQLSQLEXPRESS_MSSQLSQLEXPRESS"
}
check_command = "check_wmi"
assign where host.vars.mssql_server
ignore where host.vars.disable_wmi
}
apply Service "Event Log: Application" {
import "generic-service"
vars.check_mode = "checkeventlog"
vars.wmi_arg1 = "application"
vars.wmi_arg2 = "2"
vars.wmi_arg3 = "1"
vars.wmi_warn = "50"
vars.wmi_crit = "100"
check_command = "check_wmi"
assign where host.vars.os == "Windows" && host.vars.event_log_application
ignore where host.vars.disable_wmi
}
Additional services or specific process checks (e.g., monitoring a Jenkins process) can be added following the above examples.
While using WMI via the check_wmi_plus plugin may not be the most future-proof solution (especially with enhanced PowerShell and SSH support in newer Windows versions), it remains a robust method for monitoring legacy environments. This guide should help you set up both the Linux side (WMIC and plugin) and the necessary Windows configurations, as well as integrate the checks into your Icinga setup.
-
Q: What types of services can I monitor using WMI?
A: You can monitor uptime, disk usage, CPU load, Active Directory, RDP sessions, IIS, MSSQL, Event Logs, and process statuses. -
Q: Can I create my own custom scripts?
A: Yes, you can. However, many find that PowerShell (or SSH for Windows Server 2019 and later) offers a more versatile, future-proof approach. -
Q: Need help with configuration files?
A: The Icinga community forum is an excellent resource for support and discussion.
This document provides a comprehensive overview of setting up and using remote Windows monitoring through WMI with Icinga. Adapt the instructions as necessary for your infrastructure and security policies.
Below is a step‐by‐step guide to installing Check WMI Plus on Kali Linux. This plugin lets you monitor Windows machines without installing an agent by leveraging WMI via a WMIC Server (from the aiowmi project) and a Perl‐based plugin. Adjust paths and usernames as needed for your environment.
Installing Check WMI Plus on Kali Linux
This document explains how to set up Check WMI Plus on Kali Linux, covering prerequisites, installing the WMIC Server, required Perl modules, deploying the plugin, and testing your installation.
1. Prerequisites
Before you begin, ensure that:
2. Install WMIC Server (aiowmi)
Check WMI Plus requires the WMIC Server component from the [aiowmi](https://github.com/cesbit/aiowmi) project. This server acts as an API that accepts WMI queries from the plugin and forwards them to the target Windows host.
Choose an installation directory (for example,
/optor your home directory).Clone the repository:
cd /path/to/your/desired/directory git clone https://github.com/cesbit/aiowmi.gitFollow the README instructions in the cloned aiowmi repository to build and start the WMIC Server. You may need to compile it or configure it as a long-running service. Check the repository’s documentation for any additional steps.
Test the WMIC Server by using the sample usage instructions provided in the aiowmi documentation to ensure that it properly forwards WMI queries to a Windows host.
3. Install Required Perl Modules
Check WMI Plus depends on several Perl modules. On a Debian-based system like Kali Linux you can install most modules via apt or CPAN.
Recommended Modules and Installation Methods
Via APT (if available):
Or via CPAN:
For example, to install the Config::IniFiles module:
Repeat for any module that isn’t available as a package. (Other commonly required modules include DateTime, Scalar::Util, Number::Format, JSON, Getopt::Long, Data::Dumper, and Storable. Most of these come with Perl.)
Verify module versions:
You can check the module versions by running:
./check_wmi_plus.pl -d -d | head -n 25This diagnostic output should list the installed module versions along with any version expectations.
4. Deploying Check WMI Plus
a. Download and Extract the Plugin Bundle
Download the Check WMI Plus bundle from the official releases page.
Extract the bundle to a temporary directory:
b. Install Executable Files and Configuration
Copy the Executables:
The bundle contains executable files at the top level. Copy these to a directory such as
/usr/local/bin:Install Configuration Files:
The bundle also includes an
etcdirectory. Copy this folder to/etc:Rename and Edit the Configuration File:
Inside
/etc/check_wmi_plus, rename the sample configuration file:Open the configuration file with your preferred text editor (e.g., nano or vim) and update any directory paths (for example, where the plugin looks for its INI files, log files, or WMIC binary). This file is critical because it tells the plugin where to find its utilities and how to operate.
Permission Adjustments:
Ensure that the configuration files are readable (and writable, if needed) by the Nagios/Icinga user (or whichever account you are using):
(Adjust the user and group as required.)
c. Modify the Plugin (if Necessary)
Some installations may require adjusting the plugin’s Perl library search paths if your Nagios plugins are stored in a nonstandard location. Open the
check_wmi_plus.plfile and look for lines like:Change these paths if your system uses a different directory (for example, Kali might store them in
/usr/local/lib/nagios/plugins).5. Testing the Installation
After installation, verify that the plugin is working properly:
Run the Diagnostic Command:
/usr/local/bin/check_wmi_plus.pl -d -d | head -n 25This should print out the current module versions and any configuration details. Verify that there are no errors related to missing modules or paths.
Execute a Test Query:
Once the WMIC Server is running and properly configured, try a test command as described in your WMIC Server documentation to ensure that it can query a Windows host.
6. Next Steps
Integrate with Nagios/Icinga:
Once tested, you can add Check WMI Plus to your monitoring configuration (e.g., by defining a check command in Nagios/Icinga that calls
/usr/local/bin/check_wmi_plus.plwith appropriate arguments).Security Considerations:
Make sure that any configuration files containing credentials (if any) are secured and that only authorized users can read them.
Troubleshooting:
If you encounter errors, re-run the diagnostic command and check your Perl module versions and file paths. Consult the Check WMI Plus forums or the GitHub issues page for community assistance.
This guide should help you install and configure Check WMI Plus on Kali Linux. Adjust any specific paths or package names as needed based on your system’s configuration and the versions available.
If you have further questions or run into issues, the Check WMI Plus community forums and the aiowmi GitHub page are good resources for troubleshooting and advice.