Readme.md type-error

[Manuel1948]

In the section "Add to agent config" there is:
UserParameter=veeam.info[*],powershell -NoProfile -ExecutionPolicy Bypass -File "C:\Program Files\Zabbix Agent\scripts\**zabbix_vbr_jobs**.ps1" -Config "C:\Program Files\Zabbix Agent\scripts\zabbix_vbr.conf" -Operation "$1"

but the script is not ...jobs.ps1 - it is ...job.ps1 .

Also for Agent 2 the default path would be Zabbix Agent 2, but this should be clear I think.

$acl.SetAccessRule((New-Object System.Security.AccessControl.FileSystemAccessRule("NT SERVICE\ZabbixAgent","Read","Allow")))
There is this line in the ACL-section, but there is no "ZabbixAgent"-ServiceUser (from where did you get this?). I installed Zabbix Agent (2) MSI-package, and Windows is using the "Local System"-account as service user.

Also the default postgresql server (coming with Veeam), does not need a change of the SQLPassword - it accepts every password for the username "postgres".

The parameter "VeeamServer=VEEAM01" is never used in the Powershell-Script, so why it is there?.

[aholiveira]

Hello,
Thank you for pointing out those issues.
I have fixed the name of the script in several places where it was mentioned. It was simply an oversight on my part.

As for the ACL, this was intended to allow for cases where the agent is running under a different account than the default "Local System" one, but it might cause confusion so I removed that reference from the ACL instructions. If someone changed the default account for the service, they should be aware of this, and have the knowledge of the make the permission changes as well.

I have not had yet the chance to test this in a PostgreSQL server so thank you for pointing it out. I will keep that parameter however, since it might be needed in some situations, but add the note that it should not be required in a default postgres installation done by Veeam.

The parameter VeeamServer is historical and used in previous versions of the script and template. You are right in mentioning it is not used, and I've removed it from the config samples and documentation.

I will do another PR soon, with those fixes in the documentation.

However, regardless of that, is the template working correctly with PostgreSQL installation of Veeam (I assume you have that)?

Would be great to have your feedback.

Regards,

[Manuel1948]

Hello, Thank you for pointing out those issues. I have fixed the name of the script in several places where it was mentioned. It was simply an oversight on my part.

As for the ACL, this was intended to allow for cases where the agent is running under a different account than the default "Local System" one, but it might cause confusion so I removed that reference from the ACL instructions. If someone changed the default account for the service, they should be aware of this, and have the knowledge of the make the permission changes as well.

I have not had yet the chance to test this in a PostgreSQL server so thank you for pointing it out. I will keep that parameter however, since it might be needed in some situations, but add the note that it should not be required in a default postgres installation done by Veeam.

The parameter VeeamServer is historical and used in previous versions of the script and template. You are right in mentioning it is not used, and I've removed it from the config samples and documentation.

I will do another PR soon, with those fixes in the documentation.

However, regardless of that, is the template working correctly with PostgreSQL installation of Veeam (I assume you have that)?

Would be great to have your feedback.

Regards,

Hi,

until now I had the template version 2.8 and for the customer, for which I setup the new powershell scripts etc. I had the following zabbix alerts:

I thought maybe, that a reimport of the new template 3.3 could fix it - it didn't. Now I have to update the other customers with the new powershell script as well. I am not really into the code now, maybe you could give me a quick advise what I have to check, when this alerts are happening, even if the repositories are used daily or weekly or what the exact meaning of this alert is.

[Manuel1948]

@aholiveira : I invested some time in checking why this triggers are triggering and found out that your pwoershell script handels the REPOOUTOFDATE wrong, because you forgot the type conversion (powershell sees the result as strings and when you bit-comparing strings, they are always true if they are not empty strings).

So in line 657 you have to use this:
REPOOUTOFDATE = ([bool][int]$repo.is_unavailable -or [bool][int]$repo.is_full)

[aholiveira]

Hello,
Thank you for your feedback. However, in one of the infrastructures I'm managing and using the current version of the script and template, I have a repo that is correctly flagged as "out of date", even without those forced casts in Powershell.
I am using SQL Server as a data backend, not Postgres, so that could be the issue.
Can you confirm which data backend are you using and which version of powershell is being used?
The same behavior happens in other similar infrastructures I'm using this, but they all use SQL Server (different versions) as data backend.

I'm using SQL Server Standard 2022 on Windows Server Standard 2022 and Powershell 5.1 in the infra I have the correctly flagged "out of date" repo (the other infras don't have any "repo out of date" repositories).

Regards,

[Manuel1948]

Hello, Thank you for your feedback. However, in one of the infrastructures I'm managing and using the current version of the script and template, I have a repo that is correctly flagged as "out of date", even without those forced casts in Powershell. I am using SQL Server as a data backend, not Postgres, so that could be the issue. Can you confirm which data backend are you using and which version of powershell is being used? The same behavior happens in other similar infrastructures I'm using this, but they all use SQL Server (different versions) as data backend.

I'm using SQL Server Standard 2022 on Windows Server Standard 2022 and Powershell 5.1 in the infra I have the correctly flagged "out of date" repo (the other infras don't have any "repo out of date" repositories).

Regards,

Yeah, you are right - the customers where we experienced this situation are on Postgresql.
Maybe its a Postgres Server issue or a Postgre ODBC issue.

I checked out one customers detailed version:
Windows Server 2025 Standard
Postgres server: 17.6 - which was installed by Veeam setup
Postgres ODB driver: 18.00.00.01 - I installed the latest available version

I dont know if my mentioned line is working for SQL Server too, but maybe u can test it?

[CHuvaCK21]

Thanks, I checked this with postgresql and mssql, both servers are working and I receive the correctly information, but idk what I should to get really outofdate information

So in line 657 you have to use this:
REPOOUTOFDATE = ([bool][int]$repo.is_unavailable -or [bool][int]$repo.is_full)