hello

this looks like a icinga agent issue, no idea how it is works sorry, I’m guessing you had to tell it to run the centreon_plugin.exe from this folder, but other than that, it doesn’t look like a error message I ever saw with this plugin

I could see an issue, the “block/unblock” flag as this binary comes from internet

I can also tell you this plugin is packing a lot of perl and working in a folder called c:\windows\temp\par-xxxx, some EDR prevent that, but if you could run it manually from command line, it should not be an issue

if you are sure the icinga agent service is running as local system, then I don’t why it should not work.

but this is in my opinion a “internal error” of icinga and its agent. (have you tried to run anything else as an external tool from the icinga agent, a simple batch with echo, any other programs?)

have you also try to post your issue on the icinga community forum (sorry I don’t really know this product)

Hello @christophe.niel-ACT

Thanks for the answer.
I checked the "unblock" flag. It did not help.

I asked a similar question in Icinga for Windows and centreon_plugins.exe - UNKNOWN: Internal error: execution issue: Access is denied

I have other PowerShell plugins. And they work from Icinga for Windows successfully. I use the following example of calling a script in such a plugin:

'C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe' '-ExecutionPolicy' 'Bypass' '-NonInteractive' '-NoProfile' '-NoLogo' '-command' 'C:\ProgramData\icinga2\plugins\Invoke-IcingaCheckDHCPServer.ps1 -CritUsage 98 -WarnUsage 90 -VerboseOutput 1'

I tried to use other plugins via launch in centreon_plugins.exe. The situation is similar. They successfully launch manually but do not work via Icinga for Windows

To check, I used a simple call to the plugin centeron_plugins.exe --version via the icinga for Windows agent. It works. So it seems that the problem is somewhere at the junction between centeron_plugins.exe and the Powershell call

if a check with “centeron_plugins.exe --version” is working, then it not an icinga agent configuration issue, you are correct

there are some perl and powershell wrapping done in the centreon_plugin package, not all commands  check are using powershell, 

for example this will use basic shell command to test ntp synchronisation

.\centreon_plugins.exe --plugin="os::windows::local::plugin" --mode=time --ntp-hostname=pool.ntp.org

If this doesn’t work, it should eliminate the powershell factor as it not used in this check

(and the “pending reboot” command is using powershell)

if it works, then there is a powershell restriction somewhere, but I never encountered that.

a quick look in the code and here are the option used to run the powershell command

they didn’t use an policy restriction  “-ExecutionPolicy Bypass” (or remote signed or unrestricted)

because there is no need to, they don’t use script files, but make an encoded command which is not subject to execution policy

so I’m not really sure what could be happening here

We have checked this beforehand and this is probably not the problem.
We have tried running the plugin with additional parameters:

C:\ProgramData\icinga2\plugins\centreon_plugins\centreon_plugins.exe --plugin os::windows::local::plugin --mode pending-reboot --command-options "-InputFormat none -NoLogo -NoProfile -ExecutionPolicy Bypass -EncodedCommand"
OK: 'Microsoft Windows Server 2022 Standard': reboot pending is false [Windows Update: false][Component Based Servicing: false][SCCM Client: false][File Rename Operations: false][Computer Name Change: false]

Again, we get the same result. When run manually, it works fine, but when called via the Icinga for Windows Agent service, we get an error message:

What is also strange about this situation is that I even tried to watch the activity in the system using the Procmon64.exe utility during the call to centreon_plugins.exe via the Icinga for Windows service, but I did not see any ACCESS DINIED events.

all I can add here to help debug 

you can run the command with an additionnal parameter “--debug” it sometimes gives additionnal output before the error that occurs

(have you also tried the check “time” to see if it only occurs with powershell ?)

if you can have logs of what the icinga agent is doing locally on the windows host, it could help also

though, probably not, it seems to be working correctly.

but I can’t help you more on this subject

The test shows that this command works successfully:

C:\ProgramData\icinga2\plugins\centreon_plugins\centreon_plugins.exe --plugin os::windows::local::plugin -plugin="os::windows::local::plugin" --mode=time --ntp-hostname=-ntp.holding.com
OK: Time offset 0.010 second(s) | 'offset'=0.010s;;;;

This means that the problem is at the junction between centreon_plugins.exe and powershell.exe
Now we need to understand what exactly the problem is :)

Adding the --debug option does not change anything. The error is the same and there is no additional information:

The Icinga for Windows service has a log, but it does not contain information about the problem.

at that point, it is not an execution policy problem

just an hypothesis : 

there may be some protection by a third party “intelligent” antivirus, because you have a process running as a service, it uses c:\windows\temp to unpack binaries, which in turn will run some powershell command encoded in base64

it’s all nice an tidy, unfortunately most cyber attack are using the exact same workflow (i.e the big exchange crisis from a few year ago just to give an example)

I have seen some EPDR not being happy with this kind of behavior and they sometimes need a bit of tuning to accept the chain of process initiated by icinga

and another question/hypothesis : are you using powershell “out of the box” of the OS Setup, or did you install newer version of powershell

$psversiontable

should return a major version 5

if you installed v7 for example,  in the check command option you could add “-version 5.0” to force execution in v5 environment

This is a clean Windows Server 2022 Standard OS with all the latest updates. There is no antivirus software on the server.

The PowerShell version is native.

$psversiontable

Name                           Value
----                           -----
PSVersion                      5.1.20348.2400
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.20348.2400
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1