Windows agent as satellite?

Hi, I’m having a master Icinga2 running on VPS in the cloud. The company has 1 Windows server at their office which is connecting to the master and is executing checks fine.

Now I would like to check some other hosts in that subnet. Mostly just ping.Would that be possible to act the Windows agent as some kind of “satellite” in this case? The Icinga master cannot connect to them directly.

Please have a look at the doc :

Yes indeed, what specific part of the documentation are you referring to? (I used that doc to setup initial monitoring btw)

Maybe this part :
Three Levels with Master, Satellites, and Clients
An example with master, satellite and client you can use to make your how installation.
In their case, there are multiple master, so it’s might be not your case.

Indeed, but did you have a look at my initial question? I was wondering if I could let the Windows agent execute checks for other hosts (mostly ping)

I’m really sorry… too tired to think straight…

I was once told that Windows Satellite are not recommended.


Please note that Icinga 2 was designed to run as light-weight client on Windows. There is no support for satellite instances.

Sounds like it won’t work…


you can use ping-windows to execute ping checks from your windows endpoint.

Windows as a Icinga Satellite is not official supported.

Best regards

Yes, but then they will be a service on that windows host right? I was looking if it was possible to have them as a service on another host.

It might work - but if it does not, you will not get any help then (it is unsupported but carries all technical features of a satellite).

You would expect performance issues, so if you are brave try if it works for you.


Could you give me some hints on how to do it?

object Service "ping" {
  host_name = "remote-host"
  check_command = "ping-windows"

  command_endpoint = "remote-windows-host"

Should it be like that?

It looks like that is working :wink:

But if remote-host and remote-windows-host are the same, you could omit the installation of the Windows Agent at remote-windows-host and drive this_host as a fully supported windows agent.

As it stands now, the scheduling of the checks is left at this-windows-host anyhow.

You really need the above for checks that must run locally at remote-windows-host, i. e. check_disk or check_users.