Creating a WMI proxy for Nagios – arguments Pro and Contra

In this article I wish to mark some advantages / disadvantages of having a WMI proxy in your Nagios setup.

To WMI or not to WMI….

First we need to explain what exactly a WMI proxy is. Basically this machine is a Linux/Windows machine with a Nagios client installed that runs as a service. This WMI proxy has some scripts (I will detail them in my next post) capable to check other Windows servers with the help of the WMI repository located on each Windows server. The same technique is applied with success by SCCM, SCOM, SpiceWorks, etc.

This type of proxy gives a great advantage to the administrator as he can easily modify the scripts, the configuration of the Nagios client, start / restart services, etc. Having a centralized repository with all the scripts means that the network administrator can protect this Windows server with a firewall (you need to define the WMI port range for that) and also reduces the load on the checked Windows servers. Another advantage is that the “client-less” checks can be done also in the Windows 2008 Core environment that normally would not offer the possibility to install and configure the Nagios client.

The problems that one can have with WMI are the connection limit of the windows server. I have seen this on servers with more then 100 checks / minute. The WMI starts to give time out errors and the reliability of your Nagios installation goes down the drain.

A solution to this is to port the checks to a Linux machine that has a script like this one (, but I still need to check this argument.

On the other part the making the checks to the Windows environment in a client based mode (as SCOM does for example) offers a flexibility that a WMI proxy normally does not have. Here I’m referring to all the standard checks that come with the client (that cover basically everything) thus the administrator does not need to create new vbs/cmdlet scripts to check, for example, the log for errors. Also the client can run with the system account so that saves you the trouble of running the process with an elevated Active Directory account. Also if your firm has a software distribution system (SCCM comes in my mind right now) the configuration and the new scripts can be kept easily up to date. If not, the internet is full of scripts (check the site of NSclient++ ).

The problems here are exactly the distribution method, that the administrator needs to choose to deploy his clients,  and the client install on the monitored system – it may be the case that you may not own that system or not have sufficient rights to install the client or the operating system will not permit that.

In the end I think the best way is a mixed way of checks, depending on your network structure and the types of services.

So what are your thoughts on this?

Mihai out.

Note: Copying this article to your website is strictly NOT allowed.

Leave a Reply