Hello,
After updating Veeam Backup to version 13, I can no longer monitor backup jobs as before. Does anyone have a solution for how to perform this monitoring?
Hi Lucas,
there was a thread about this in the german sub-forum, the newer veeam 13 powershell modules need a current powershell and checkmk triggers and older powershell, the workaround seems to be a wrapper script: Veeam Backup & Replication 13 Support? - #3 by marcquark
Gerd
2 Likes
A colleague of mine has just modified veeam_backup_status.ps1 to query the installed Veeam version, derive the required PowerShell version (Veeam â„ 13: PS 7, Veeam < 13: PS 5), compare the version itâs running under with the required version & re-start the script with the required PowerShell version if they differ.
We distribute it by disabling the built-in Veeam agent rule & distributing it as a custom plugin script via a rule of type âDeploy custom files with agentâ.
You can get the customized version here. We do not plan on distributing it or creating an MKP for it; Iâm hopeful official support will come soon.
3 Likes
According to what you sent here, it is now working for me.
I would like to thank you for your support.
This line
[int](Get-Process | Where {$_.Name -like "*Veeam.Backup.Service*"}).ProductVersion.Substring(0,2)
does not deliver a proper result and the script always assumes Version 13.
Thatâs interesting. The script as-is is used across our whole setup, mixed Veeam 12 & 13. Therefore it should be OK? As far as I understood my colleague the Veeam 12 cmdlets require PowerShell 5 & just donât work in PS 7. So far none of the Veeam servers we monitor showed failures with the modified script.
Can you elaborate?
Our output for Veeam 12:
.ProductVersion has no result for the process. The first try/catch-block will fail and 13 is set as version.
The .Substring method fails:
That is more than curious:
We monitor 55 Veeam servers, of those a very small number is 13, an even smaller number is still 11, and the vast majority is 12 (12.3.1.1139 & 12.3.2.3617, to be precise). This modified script runs on all of them, and if it didnât work on them I would certainly have seen it in tons of unknown/vanished services. Granted, I havenât run the PowerShell Get-Process ⊠.ProductVersion on all of them, but still. Iâm rather confused about your systemâs behavior & have no good idea whatâs going on.
Is it possible that your agent is not running as Local System?
If i do the Powershell line in a shell without admin rights i get also an empty output.
With a proper admin shell the version is reported correctly.
The ProductVersion property should be available for nearly all processes. The check_mk_agent process should report the installed agent version.
1 Like
Admin privs do seem to make a difference for me, too. Without them .ProductVersion is empty/undefined/whatever, with them theyâre present. My agents are all running as Local System, therefore I donât see the problems that Stefan sees.
Yes, we ran everything in an elevated shell (pwsh/powershell/cmd) and agent is running as SYSTEM.
We worked around our(!) problem with locating the Veeam.Backup.Manager.exe and reading the version from this executable.
Thanks and have a nice day
My colleague & I discussed reading the version from the file, too, but concluded that the install location is definitely not fixed, even though itâll vary rarely. Using the service seemed safer to us.
The fix did not work for me:
PS C:\Program Files (x86)\checkmk\agent\plugins> .\veeam_backup_status-temp.ps1
Ausnahme beim Festlegen von âbuffersizeâ: âDie PuffergröĂe kann nicht festgelegt werden, da die angegebene GröĂe zu groĂ oder zu klein ist.
Parametername: value
Der tatsĂ€chliche Wert war 150,300.â
In C:\Program Files (x86)\checkmk\agent\plugins\veeam_backup_status-temp.ps1:18 Zeichen:1
$pswindow.buffersize = $newsize
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CategoryInfo : NotSpecified: (
, SetValueInvocationException
FullyQualifiedErrorId : ExceptionWhenSetting
SetValueInvocationException: C:\Program Files (x86)\checkmk\agent\plugins\veeam_backup_status-temp.ps1:18
Line |
18 | $pswindow.buffersize = $newsize
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Exception setting âbuffersizeâ: âCannot set the buffer size because the size specified is too large or too small. (Parameter âvalueâ) Actual value was 150,300.â
Write-Error: Totally unexpected and unhandled error occured:
Item:
Error Message: TooManyRequests:
PS C:\Program Files (x86)\checkmk\agent\plugins>
If I increase the size, I only get this error:
PS C:\Program Files (x86)\checkmk\agent\plugins> .\veeam_backup_status-temp.ps1
Write-Error: Totally unexpected and unhandled error occured:
Item:
Error Message: TooManyRequests:
The resize of the frame buffer is not working inside a normal shell window.
For manual testing you can comment these lines. They are only important for headless execution to define the virtual shell size.
Yes sure - I tried in system context as well to figure out why I get no response from the agent. I think itâs this error which happened in general for me:
Error Message: TooManyRequests:
Edit:
Ok I realized that the script is workin on my Veeam 13 Community Edition Servers, but not on my Backup & Replication 13 Server.
Maybe its time to rewrite this whole thing into a REST based check, i will see, what I can do in the upcoming holidays.
2 Likes
Should (finally) be possible in Version 13 to rewrite everything for the REST-API. Version 12 only supported VMware vSphere backup jobs, VMware vSphere replication jobs and VMware Cloud Director backup jobs.
Hi,
I have the same issue, in my VBR I got :
Write-Error: Totally unexpected and unhandled error occured:
Item:
Error Message: TooManyRequests:
with this modified script as well.
Edit: After a few minutes the check is running smoothly. Thanks a lot.
What is interesting, is that when I run a âRun service discoveryâ, the existing Veeam jobs are vanished with the following error: âCheck plug-in received no monitoring dataâ .
But in the monitoring appear as checked, and with the last result.
So, I can add more Veeam Backup jobs as service, but can monitor existing ones.