Revoking license from multiple objects in one go

[Nas]

We recently did an ESX & vCenter maintenance and after that all our VMs got new MoRef ID. This in turn consumed duplicate licenses by both old and new objects.
Revoking license manually one by one works by referring https://helpcenter.veeam.com/docs/backu ... ml?ver=120, and I tried this but it's a painful manual process for hundreds of servers.

I'm interested to explore if anyone has encountered this before and willing to share tips/solution on how to quickly revoke the license.

[Mildur]

Hi Nas

Unfortunately there is no automated way through PowerShell or RestAPI to revoke those licenses.
You may open a support case and ask our support team if they can provide a SQL query to revoke the licenses for this specific use case (revoking hundreds of workloads because of MoRefID changes).

Best,
Fabian

[Nas]

Thanks for reply, Fabian.

After consulting with Veeam support, I may need to go with deleting one by one.
They cannot provide SQL query and revoking licenses via SQL query is not supported and not recommended way of deleting licenses according to support. If I were to proceed with SQL query, I will be on my own and need to accept the risk of unexpected issues.

Support will try to submit feature request for multiple selections of license revoking in future release.

[m.novelli]

+1 for multiple item selection to revoke licenses

Marco

[Mildur]

Hi Nas

Thank you for getting back to us with the answer from support.
Can you please share the case number with me? Then I can add your vote for this feature request with a reference to your case.

Best,
Fabian

[Nas]

Hi Fabian

Veeam Support - Case # 07033645

Thanks

[m.novelli]

Last week I've failed to upgrade a VMware vCenter from v7 to v8 , so I just decided to build a new vCenter... it has been easier to reconfigure VMware Cluster / DR / HA / licenses on two nodes Cluster than revoking one by one all VUL licenses due to new MoRef ID

Marco

[Mildur]

Hi Marco

For a migration scenario you may also ask your regional Veeam team to have a NFR license.
After 31 days, your old license should be usable again.

Best,
Fabian

[Nas]

Hi,

An update from my side, I found that using Detach from job option on v12 will revokes all the consumed instances from that job. This is a timesaver for me as we are deploying a new vCenter which will lead to a hundreds of new MoRef id again.

[Nchandler]

I would like to see a feature to select multiple devices to deactivate\Revoke at the same time.
We recently decommissioned our on prem VMWare Workstation environment and I and to manually Revoke over 350 devices one at a time.

[m.novelli]

I've faced this issue many times and I think that probably is easier to revoke the license (change to Community Edition) and then load again the license, so we reset the used licenses

Marco

[Nas]

Hi Marco,

Support suggested the same Community method to me. However it's not working when I tried it last time.

After I loaded my license from Community, console is back to showing the previous consumption number.

[m.novelli]

Marco

[johannesk]

I'm in the situation of migrating vm's from vmware to Nutanix. When a VM has been migrated and running in Nutanix, the vm takes two licenses because it was previously backed up in a vmware backup job.

Now I need to use the license manager to revoke the license for each vm, that's in the hundreds, and I can only run the revoke command on one VM at a time.

If I could just drop all licenses for that particular vcenter, that would be great. Then the remaining vm's in that vcenter just pick up a license from the license pool.

Is that possible, to drop all vm licenses on a vcenter so the remaining vm's will be relicensed?

Regards,
Jóhannes

[m.novelli]

+1
+1
+1
+1

Marco

[Mildur]

Hi Johannes, Hi Marco

There is no change yet in the behavor.

@johannesk
If you have such big migrations, I suggest to contact your sales representative and request a temporary 1-2 month license to cover both environments during the migration.

Best,
Fabian

[m.novelli]

Hi Mildur, you miss the point. The problem is manually revoking hundreds of VM from Veeam licenses

It's quicker to rebuild the Veeam Backup Server and import a config backup than clicking hundreds of times VM names

Marco

[Mildur]

Hi Marco,

I assume that your use case for "manually revoking hundreds of VMs" is only necessary during a planned migration to another hypervisor. This would be a one-time operation for each VM until all have been migrated.

In that case, consider obtaining a temporary license for the duration of your migration project. The VM license consumption from the old hypervisor will be automatically revoked after 31 days without a backup. If you replace the temporary license with your own license after 2 months, the "old VM license consumption" should already be automatically cleared, allowing your own license to start consuming licenses based on backups on the new hypervisor.

However, if you are "revoking hundreds of VMs" because your team is creating and removing VMs every few minutes, then revoking licenses after each backup would be against our license agreement. In a scenario where you maintain the same hypervisor environment, you'll need to wait 31 days for the license to be revoked.

Best,
Fabian

[ashleyw]

We have this exact requirement. We have just installed a 350 VUL license onto our infrastructure. The count said 357 despite there only being 330 VMs - with our backup set about 310 currently (my workloads represent development systems which are very fluid).
Also some of the VMs had to be disconnected and reconnected due to temporary historical infrastructure issues which then results in duplicates for the VMs according the VUL licenses and ass only the name of the VM is shown in the list I couldn't determine which one was the valid one. So I had to manually go through and remove the VMs from the license for now, so the licenses can correctly be assigned.

It also turns out that templates are considered to consume the VUL licensing (I hadn't realised this before), I don't think this is a fair application of VUL as these are not running workloads but they still need to be backed up as part of our processes.

I have logged a case (# 07849366) to attempt to get access to the postgres layer directly via an SSH session on the console of the B&R appliance, but the hardened nature of the V13 appliance appears to be working against me in this respect.

thanks

[Mildur]

Hi Ashley

We added an option to RestAPI to revoke license instances.
/api/v1/license/instances/{instanceId}/revoke

It also turns out that templates are considered to consume the VUL licensing (I hadn't realised this before), I don't think this is a fair application of VUL as these are not running workloads but they still need to be backed up as part of our processes.

Templates are considered workloads as well. If you don't want to use a license, consider using VeeamZIP after you have updated your template. VeeamZIP should not consume a license.

Best,
Fabian

[ashleyw]

We added an option to RestAPI to revoke license instances.
/api/v1/license/instances/{instanceId}/revoke

Thanks Fabian, this is great news and will save me some time should I have to clear the allocated licenses again for any reason.
Good idea on the templates - thanks for that will think that one through