Invoke-IcingaCheckUpdates: Access is denied

Service Monitoring
,
1

Hello

I set up the Windows agent and most of the checks through director seem to work.
However, with Invoke-IcingaCheckUpdates (with verbosity 1 as argument), I get the following plugin output:

[UNKNOWN] Windows Updates: 1 Unknown 6 Ok [UNKNOWN] Windows Update Error (0)
[UNKNOWN] Windows Update Error: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

Any ideas on this? I already tried to change the Icinga2 service logon account running on the client from “Network Service” to “Local System”.

We are using:

  • Icinga Web 2 Version ==> 2.11.4
  • Director ==> 1.10.2
  • Operating System (on client) ==> Microsoft Windows Server 2019 Datacenter
  • Operating System (on master - Icinga2 server) ==> Debian GNU/Linux 11 (bullseye)

And the following components are installed on the client:

agent 2.13.7 2.14.0
framework 1.10.1 1.10.1
plugins 1.10.1 1.10.1
service 1.2.0 1.2.0

Thank you!

2

do you use the powershell service? If yes check and change the user as well

3

Thanks for your feedback. Yes I use the Icinga powershell service. I also changed the log on from network service to local system but it behaves the same for the first 3 checks. After those, the service starts to time out and is no longer outputting even the error message:
Plugin Output : Timeout exceeded.

4

I also see this, did you figure out how to fix?

5

@NiclasE, no unfortunately I didn’t manage to fix it and didn’t receive further feedback. I read several statements on the Internet. Some were saying it is not possible to have it working, some saying it’s a matter of service rights etc.

6

Isn’t there anyone that has a solution for checking Windows updates?

7

Same problem here without the service installed.

8

Hi people,
I think this underlying issue for this error is a lack of permissions of the execting user.
This user might be different, depending on how you installed the plugins.
If you are running without the icinga-powershell service, the icinga2 is executing and it is
most likely running as the Network Service user which might not have the right
permissions (rightly so).

The current, most common approach is, to install the additional service (icinga-powershell) with
the JEA stuff enabled, which installs all the powershell things to a separate user (icinga I think)
which gets the necessary permissions through JEA.

On Setups with the service installed, you can do this with Install-IcingaSecurity.

9

Thanks - there seems to another problem when trying to install the service:

PS C:\Windows\system32> $ServiceData = Get-IcingaFrameworkServiceBinary;
Do you provide a custom source of the service binary? (y/N):
Please enter the path you wish to install the service to (Defaults: "C:\Program Files\icinga-framework-service\"):
[Notice]: Waiting for lock on path "C:\Users\wadmin\AppData\Local\Temp\tmp_icinga1506987188.d" to be released before trying to remove it
[Error]: Failed to remove items from path "C:\Users\wadmin\AppData\Local\Temp\tmp_icinga1506987188.d". Recurse is "True", Force is "True": "System.IO.IOException: Der Prozess kann nicht auf die Datei "icinga-service.exe" zugreifen, da sie von einem anderen Prozess verwendet wird.
   bei System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   bei System.IO.FileInfo.Delete()
   bei Microsoft.PowerShell.Commands.FileSystemProvider.RemoveFileSystemItem(FileSystemInfo fileSystemInfo, Boolean force)"

JEA will only work with service installed?

10

hm, which version of the Icinga Powershell Framework and is something else accessing this path?

11

Icinga PowerShell Framework v1.13.1