Hi,
We don’t really support Windows agents as full blown satellite instances with their own local scheduler. Mainly for the reason that performance handling and troubleshooting on Windows is hard compared to Linux. At some point in the future, we will make this default and drop support for the local scheduler on an agent. This is to be discussed though.
The preferred method for agents is the command endpoint execution bridge, and this also is used inside the Icinga Director when making a host an agent.
In terms of your questions:
1.) When the host in the wrong zone, you can use the zone attribute trick to tell the master that it should be authoritative for the host object. Then it executes the check itself, while the agent does nothing. When the service doesn’t return any checkresults, there’s no state change on the master or more visible problems. That is because of the check result history required to be intact when a reconnect happens, and replay log sends cached results from the remote endpoint.
This is a typical scenario for a satellite though.
2.) accept_commands should be enabled for agents by default, this is more of a security thing to not trust anything from above.
3.) What do you mean with perfdata isn't handled as expected?
4.) accept_config in Director - please share a screenshot or configuration snippet to explain this.
Anyhow, I would strongly recommend to use agents only with command endpoints. This requires accept_commands = true on the agent’s api feature, and accept_config for syncing checkcommands via a global zone (if not available in the ITL on the agent).
Cheers,
Michael