Monitoring Windows

Checkmk offers several ways to install the Windows Agent — from a manual installation of the individual components, up to a fully-automatic deployment. Some of these possibilities are only available in the Checkmk Enterprise Editions:

Regardless of whether you create the MSI packages over the Agent Bakery, or configure them manually on each host — you first need the installation file. In the Checkmk Raw Edition you go via Setup > Agents > Windows to the Packaged Agents. Here you will find the check_mk_agent.msi file.

In the Enterprise Editions you find the baked agent packages via Setup > Agents > Windows, Linux, Solaris, AIX. In order to download the installer, simply click the icon in the column Windows.

Download the MSI file to the host and start the installation. In principle, you just have to follow the menu, and read and agree to the GNU GENERAL PUBLIC LICENSE license terms.

After installation the agent will be started immediately as a Windows service, and be ready to monitor the system.

For the agent on Windows the Checkmk Enterprise Editions also have the possibility of configuring it individually via the Agent Bakery using the Setup menu. For a detailed description see the general chapter on the agents. Again, the installation of the baked MSI package is performed exactly as described above.

If you use the Agent Bakery you can set up automatic updates for the agent. This is described in its own article.

The agent is divided over two parts of the file system:

For the agent configuration, three files are read sequentially and hierarchically:

As you may already have recognised by the of the configuration files’ file extension, YAML is used for the configuration format. We decided, starting from version 1.6.0, that this format makes it easier to use structured data than with the classic INI format.

For the manual work with the agent, only the last configuration file (check_mk.user.yaml) is relevant, because it is the last to be read in and thus it has the last word. If the Agent Bakery is not used, this is in fact the only file in which customization of the agent’s configuration may be made.

In earlier versions of Checkmk the agent had a different architecture. This has been working well for a long time, and from Version 1.6.0 it has been replaced by a new one in order to tidy up loose ends, to simplify the configuration, and ultimately to have better tools on hand — for example for help in being better able to track down configuration errors.

For compatibility reasons the old agent is still included in Checkmk because only it can reliably monitor old platforms like Windows XP and Windows 2003. These two systems will no longer be supported by the new agent. In addition, having an already-installed old agent should make a migration to the current one easier. This is still compatible with Checkmk, so that an update of your Checkmk server to Version 1.6.0 does not automatically require an agent update.

The new Windows agent differs from the old agent in the following points:

Migration from an already-installed agent to the current agent is very simple. Simply call the installation package for the new agent (check_mk_agent.msi), and follow the instructions as usual. During the installation you will always be asked how to handle old configuration files:

The old agent will then only be stopped and be disabled. Regardless, the configuration of the old agent will, as a part of the installation process, be transferred to the new format and stored as a user configuration (check_mk.user.yml). This gives you the option of checking the conversion with the aid of the original file. Once you are sure the conversion was successful, you can deinstall the old agent.

You would probably only want to make such a manual check of individual hosts in a group. Once you are sure that the conversion works correctly, you can accordingly deinstall the old agent automatically. You will then save yourself the manual deinstallation, and can simply replace the old agent with the new one.

Important: After you have removed the old agent, its directory may not have been completely deleted. This is not an error, but a normal behavior if there are files in the directory to be deleted that were not brought into the system via the installation routine. These could be plug-ins or your own configuration files which were created manually by a user. In such cases, simply delete the old agent’s installation directory following the deinstallation after making sure that it contains no important files.

To check if the configuration was read in as you expected, call the agent with the showconfig option. With this option you not only get an output of the configuration as it is currently being used by the agent — the environment variables in use, as well as the configuration files will always be shown.

If only a certain part of the configuration is of interest, restrict the output to a specific part. Here, for example, it is being checked whether the options for the ps section have been defined correctly:

In this way you can get a quick overview of how the three different configuration files are merged and used by the agent. Errors are thus immediately visible.

There are several methods under Windows to test the agent’s functionality. With the help option you will get a detailed overview of which diagnostic options the agent provides. The most important of these are presented here.

The agent offers even more options for finding out many details about the concrete behavior of the agent than those already described. With the help option, among other things you get a detailed and complete list of the available options beyond those described here.

Under Windows you can continue to use its Nagios-based plug-ins on a host if there is no counterpart in Checkmk. The mechanism for this is quite simple — you use the MRPE feature of Checkmk which behaves analogously to the NRPE of Nagios.

The inclusion of MRPE plug-ins is enabled by default. If you do not want to use this feature you can deactivate it in the configuration file by adding the following definition:

To tell the agent where the file to be run can be found, and how to call it, add an entry in the MRPE configuration:

It is not a requirement that the file be stored in the agent’s directory, even if it makes sense to store everything in a common location. In this configuration example you can see the following elements for the relevant line:

After you have set up the MRPE plug-in, it will be immediately become active without needing a reboot of the agent, and it will be added to the output. In the service discovery you will now automatically find your new service:

Alternatively to configuring directly on a host in the user-specific configuration file, you can also define your MRPE plug-ins directly in the Setup menu. To do this, use the Setup > Agents > Windows, Linux, Solaris, AIX > Agent > Agent rules > Execute MRPE checks rule set. The necessary entry is then generated automatically in the Agent Bakery configuration file.

The standard agent contains a whole series of sections which provide monitoring data for various check plug-ins, which are then found automatically by a service discovery and output as services. Above all, this includes the important monitoring of the operating system.

In addition there is the possibility of extending agents with agent plug-ins. These are small scripts or programs called by the agent to extend the agent with additional sections of monitoring data. The Checkmk project already provides quite a few such plug-ins which — if they are installed and configured correctly — via a service discovery also automatically create new services.

Why are these plug-ins not tightly-integrated with the standard agents? For each of the plug-ins one of the following reasons applies:

As already mentioned, as standard Checkmk provides a whole series of plug-ins for Windows. You can find these on the monitored host in the agent’s installation directory. There all available plug-ins are always stored directly with the agent so that they are also directly available for use: C:\Program Files (x86)\check_mk\service\plugins. Alternatively you can also find the plug-ins on the Checkmk server itself in local/share/check_mk/agents/windows/plugins. These are also available via Setup > Agents > Windows, Linux, Solaris, AIX > Related > Windows files in the Plugins box. Here is an excerpt:

For all of the standard agent plug-ins we provide there are also suitable matching check plug-ins which can evaluate the collected data and generate services — thus you do not have to install any extras on the Checkmk server.

Important: Have a look at an agent plug-in before you install it on a host — you will often find important information on the correct use of the plug-in.

The actual installation is then easy. Copy the desired plug-in either from the Checkmk server or from the installation directory to C:\ProgramData\checkmk\agent\plugins. If the plug-in is in this directory it will be called automatically by the agent, and a new section will be created in the agent’s output. This section usually has the same name as the plug-in. Complex plug-ins — for example, mk_oracle.ps1 — even create a whole series of new sections.

Some plug-ins require a configuration file in C:\ProgramData\checkmk\agent\config for them to work correctly. For others a configuration is optional — for example mssql.vbs) — this allows for special features or customizations. Other plug-ins function without further steps because they have different sources for their information:

Even with special (script) languages, it may be necessary to activate them in the agent’s configuration. For example, Python scripts will not run unless explicitly released. You can simply expand the file extensions in check_mk.user.yml in the global section, as shown in the following excerpt:

Important: The use of such plug-ins of course presupposes that the files can also be called up in a regular command line without requiring special file paths. In the case of Python, it must be installed correctly, and the path to the interpreter must be available in the environment variables. Instructions on how to set up Python correctly can be found directly on the website of the Python Software Foundation.

Each plug-in can be executed in different modes. The following options are available. The setting printed in bold is the default value:

A configuration for the Veeam plug-in looks like this, for example. This extract is truncated here and contains only the part relevant for this example:

The plug-in, as defined above, will be executed asynchronously every five minutes (300 seconds), and may not exceed two minutes (120 seconds) running time. If the plug-in reaches this timeout, it will make a second attempt to get a result.

The plug-ins supplied by Checkmk can be configured via the Agent Bakery. This ensures both the installation of the plug-in itself, as well as the correct creation of the configuration file if one should be necessary.

Each plug-in is configured via an agent rule. You can find the matching rule sets in Setup > Agents > Windows, Linux, Solaris, AIX > Agents > Agent rules:

Since agent plug-ins are executable programs, you can also execute them manually for testing and diagnostic purposes. There are plug-ins however which need certain environment variables set by the agent, e.g. to find its configuration file. If necessary, set these variables by hand if they are needed in a script or program.

As with the Linux agent, access to the agent for Windows also needs to be secure. After all, these are potentially sensitive servers that must be protected from external attacks. For this reason, the same basic principles as under Linux also apply here. Likewise with Windows, the agent does not read any data from the network, so an attacker can never infiltrate commands or scripts via the monitoring port 6556.

If the monitored system is queried over an insecure (internet) connection, additional measures will be necessary. The agent has an optional built-in encryption of the transmitted data to protect it from attacks affecting network traffic. On newer Windows versions the native SSH is additionally optional, so that an encryption over the entire duration of the connection can be guaranteed, as is already familiar under Linux.

These and other methods of protection are described in more detail below.

The restriction to certain IP addresses can certainly be configured via the Firewall, additionally however, the agent also has the ability to simply ignore requests from unfamiliar IP addresses. Just add the following restriction to the global options in the configuration file. Note that other parameters can be set before or after this in the configuration file, and that only the relevant excerpt is shown here:

As you can see in the example, in principle you can allow as many subnets as you like. For example, with a /32 enter a subnet of size 1, so that only this single address is allowed, while the use of 192.168.42.0/24 will allow all addresses between 192.168.42.0 and 192.168.42.255.

In the Agent Bakery, you can configure the permitted IP addresses using the following rule set: Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Allowed agent access via IP address (Linux, Windows)

Of course an attacker can very easily fake their IP address and thus get a connection to the agent, however it is very unlikely that they will get an answer — because any answer will be routed to the real monitoring server. Or if the attacker actually gets an answer the Checkmk server receives no data and will very quickly report an error.

Newer versions of Windows have native support for SSH, but even with older versions, using Cygwin you can retrofit an SSH server and replicate an identical configuration to that possible under Linux. For the setup please see the latest Cygwin or Microsoft support. Once an SSH server has been started and is reachable, further setup is identical to that under Linux — you set up the authorized_keys on the monitored host, and restrict access to the execution of the agent.

The entry in the file authorized_keys is not very straight-forward on a Windows host, because you will need to add a few backslashes for masking. Please use the following example as guidance:

Note that you can stop the Windows service following this procedure, and also note that any possible, previously-defined firewall rule is then made obsolete.

The Windows Agent (and also its Linux counterpart) encrypts its data without any additional tools. This is not strictly a substitute for access control — but since an attacker cannot send commands and cannot do anything with encrypted output data anyway — it comes very close to one.

The effort in using the encryption, and the additional CPU load necessary, are both less than the method using SSH as described above — which we however still recommend using for transmission over the internet.

The encryption of course requires a suitable configuration both on the agent and on the server. This can either be done by hand ( Checkmk Raw Edition), or with the Agent Bakery ( Checkmk Enterprise Editions).