Home > Checkmk Conference #6: Best Practices for the Windows Agent

Checkmk Conference #6: Best Practices for the Windows Agent

By Timo Scheibe on May 14, 2020

Windows is regaining popularity in the server world. Therefore, a good monitoring will also mean that it can handle Windows well. With our own agent for Windows we also offer several advantages over monitoring via WMI or SNMP, such as minimal resource consumption, access to data that cannot be read out with WMI or SNMP, and the ability to create your own extensions.

With Checkmk 1.6, we have completely redesigned our old Windows agent to enable smoother operation. This was necessary because the old agent had reached its limits. Mathias Kettner originally built the first Windows agent under Linux using his Linux toolchain. Nevertheless this ‘first’ Windows agent worked quite well, and we continued to develop it. It was basically an implementation based on a ‘low-level API’ from Windows – as Mathias reported on the launch of the new agent at last year's Checkmk Conference #5.

The Linux-based toolchain of the old Windows agent, however, meant more and more effort for us when debugging, and when programming new extensions. In 2019, with the release of Checkmk 1.6, it was time to take the monitoring of Windows systems to a new level and to work with Windows’ native development tools. In this way we wanted to simplify working and monitoring with the new agent, and to make it smoother in its operation for users.

Marcel Arentz (left) and Sergey Knipis (right) holding their virtual Presentation.

Marcel Arentz (left) and Sergey Kipnis (right) holding their virtual Presentation about the new Windows Agent in Checkmk 1.7.

In retrospect, we succeeded in doing this as since then we have had to process fewer than 80 support tickets, and fewer than ten bug fixes related to the new Windows agent – as Product Manager Marcel Arentz and developer Sergey Kipnis reported in their lecture at Checkmk Conference #6.

In particular – the migration from Version 1.5 to Version 1.6 – the architectural changes in the agent with 1.6, and the generation of false positives by the agent updater in antivirus programs on some systems accounted for the majority of user requests, as Marcel explained.

Typical support requests were, for example – why is the old version not deleted when the new agent is installed? In addition, users were unsure when to uninstall the old agent, and why Checkmk did not automatically delete all of the old agent’s data. While the installation process for the new agent has not changed, the removal of the old agent is different, Marcel explained. It is not uninstalled by default, but is deactivated and is therefore still on the system. The old original data is also retained in order to be able to restore the old agent – if the migration to the new agent goes wrong.

If the update to the new Windows agent has been successful, Marcel recommends the automatic – not manual – deinstallation of the old agent via the uninstaller, or by activating the checkbox for deinstallation in the installer – for example when the remaining hosts are rolled out. A third option is the automatic removal by creating and executing a corresponding rule in ’Legacy Agent Management’ via the Agent Bakery, as Marcel continued.

This slide shows different ways do remove the old Windows Agent.

There are three options to remove the old agent from your system.

Manually-added data with the old agent – such as plug-ins or configuration data – that does not belong to the installer, remain in the folder even after the old agent has been uninstalled. According to Marcel, if the user no longer needs the data, it must be deleted manually. Further information on migrating the agent from version 1.5 to 1.6 can be found in the user manual. The differences between 1.5 and 1.6 can be found in chapters 3, 6 and 7 of the Windows agent manual .

With Version 1.7, the Windows agent will also receive additional functions, such as native Python plug-in support, automatic firewall configuration, as well as executing plug-ins with specific authorizations, and a controlled uninstallation of the agent. We now want to deepen these points a little.

Native Python Plug-in Support

The benefits of support for native Python plug-in support include:

  • Standardized Python conditions on every Windows host,
  • plug-ins programmable in Python 3.8,
  • possibility for cross-platform plug-ins,
  • increased reliability and performance and
  • Delivery of standard plug-ins, such as logwatch, agentupdater, etc., without pyinstaller, so that there are no more false positives with antivirus programs.

Centralized Firewall-Configuration

Under 1.7, a centralized firewall configuration and administration via the Checkmk server should enable an unproblematic initial setup across multiple hosts. To do this, the user configures the desired installation package with the required port in the Agent Bakery. If you then install the agent on the local host, it automatically adjusts the firewall accordingly.

In the past, Checkmk was in some cases unable to access a Windows host due to a problem with the firewall. To fix this problem, you had to set a firewall rule for the agent in the Windows Firewall. As ports and programs change from time to time, the centralized configuration of the Windows firewall helps to easily adapt to changes at a later time, as Sergey explained. Administrators who do not need this function can deactivate this option in the Agent Bakery – although Sergey does not recommend it.

Running plug-ins with specific permissions

With 1.7 there will also be the option for plug-ins to be executed within virtual accounts. Monitoring some resources with just one administrative account is extremely complicated or even impossible, as Sergey noted. On the other hand, administration rights are not always appropriate. Therefore there will be two new options with the new release. The first option will be that a local agent has a specific, temporary and invisible user that can be defined for a local group. This user can run plug-ins on the agents behalf. This method does not support Active Directory, and does not require credentials or configuration files on the server and host.

The second option allows you to set a user and a password. There is no limit to the specific authorizations. At this point, however, Sergey emphasized that the password is stored as plain text in Checkmk, and on the host. Typical use cases for this option include monitoring databases or network share monitoring.

Deinstallation of the Agent

Since we have also frequently received inquiries as to how the agent can be removed correctly, there will also be improvements with Version 1.7. In the future, by default a removal should also delete all files and folders belonging to an agent. According to Sergey, with the new release it is also possible to delete all data in order to carry out a completely clean installation. There is also the option not to delete any of the old data in order to be able to initiate an analysis in the event of an error.

In our next post on Checkmk Conference #6 we will tell you a little bit about our plans for you, the Checkmk community!

Wanted: IT Monitoring Superheroes

Do you have an interesting story about working with Checkmk?

We'd like to hear from you!

Learn more
checkmk superhero
We want to give you a good experience on this website.

In light of the General Data Protection Regulation, we are asking our audience to consent to the use of cookies by Checkmk and its partners to continue to our site.These cookies are used to personalize your user experience and support and improve the site. Please click “I Agree” below to consent to the use of this technology on the Checkmk website. Visit our Privacy Policy to learn more.

Your choices regarding cookies on this site.
Your preferences have been updated.
In order for the changes to take effect completely please clear your browser cookies and cache. Then reload the page.