License details

[DanielJ]

When I use Get-VBRLicensedInstanceWorkload, I get an array of workloads (vms, agents, fileshares) and the points they generate. I can see that InstanceID for each workload matches the ObjectID for OIBS of a VM backup. How can I do the same matching for agent backups and NAS backups?

[DanielJ]

I found it for agent backups: The workload InstanceID matches $oib.FindObject().ObjectID. Now what about NAS backups?

[DanielJ]

Does anyone know?

[david.domask]

Hi DanielJ,

Spent some time digging here and regrettably there's not a good way of doing this without unsupported methods.

Can I ask, what's the end goal of your script? That is, just what's the use case for matching the instance consumption from the workload report directly to OIBs?

In brief, the InstanceID from Get-VBRLicensedWorkload matches to an ObjectID as well for NAS Backups, but the ObjectID property is only returned if you fetch the NAS Backup with an unsupported method:

[Veeam.Backup.Core.CBackup]::Find('nas backup id').GetObjectOibsAll()

You can get the nas backup id directly from Get-VBRUnstructuredBackup, but I'm maybe missing why this level of attention is needed beyond what the Get-VBRLicensedWorkload cmdlet offers.

[DanielJ]

The end goal is to be able to map every workload generating license cost to customers and/or departments. Management has seen fit to assign this fun task to me. If Veeam.Backup.PowerShell.Infos.VBRLicensedInstanceWorkload contained a field with the ID of the backup the workloads belongs to, that would help, but it doesn't, so that's why I have to look at the OIBs. I could go with mapping share names in NAS backups to the customers they belong to, but it's better if I can always use the real ID. Thank you for the tip, I'll test it soon.

[david.domask]

I think I start to understand it. If you're using the Service Provider Console, consider the built-in Billings feature which also has REST API endpoints.

The objects the above unsupported methods will return will also have a backup ID, so you can use that to traverse back up to the backup level (as the above line of code will return the OIB object, not the backup itself, but you can easily get back up to the backup level from the OIB)