What are you specifically looking to do?  What you have asked is not clear.

https://forums.veeam.com/powershell-f26/revoke-license-t43377.html#p383328

 

There is the answer in the forums which is not possible.

There shouldn‘t be any reason to revoke licenses periodically before a replica job starts. Sockets from all source hosts must be licensed.

You can manually revoke the license after you have permanently done a failover of all VMs to the new hosts. This will allow you to use the existing license for the new hosts.

This screams violation of EULA here so be very careful what you’re doing and if it’s breaking your agreement. What is the reason for needing the socket licenses revoked before each replication job? Each scenario I can think of that isn’t just to cheap out on licenses is an overly complex exercise in inefficiency.

Well, @MicoolPaul , you are asking about scenarios where it might be helpful to automatically revoke socket licenses? Here is one: our VMWare admins did a re-design of their vCenters according to where VMs are located (which vCenter and/or host). At the same time old ESXi hosts were removed, and new more powerful ones got installed. It took them quite a time to do all that and for me the result was that my Veeam servers ran out of licenses because ESXi hosts would consume licenses even if they no longer were hosting any VMs. On the other side new hosts came up consuming licenses that were not (yet) available. You get the picture? Of course, this scenario wouldn´t happen every now and then but it drew me crazy to revoke licenses manually daily for a couple of weeks. What I would expect is that Veeam would do the housekeeping automatically as soon as the last VM vanishes from an ESXi host.

If you switch to Veeam Universal Licenses (VUL), this problem is solved…

Hi @Michael.Haendl, I understand your point, I’m unsure if it relates to Oscar’s requirement to run before every replication job, hence the request for additional scope from them.

Veeam don’t offer any PowerShell or REST access for license revoking so it would remain manual for now, at least until instance licensing is used and then it wouldn’t matter in this scenario…

In your specific scenario, as there’s the risk of a vMotion still taking place to evacuate a host during a backup window and thereby having a genuine license exceeded moment, for such a project I’d ask my Veeam Account Manager to temporarily provide me with an overage on my license if possible, or factor this limitation into my host migration plan.

Thank you @MicoolPaul as I said: if VBR would revoke licenses automatically from hosts without any (backuped-up) VMs, then we wouldn´t need a script solution at all.

And switching to instance licenses and spending almost 3 times the fees of our socket licenses will not happen. But that´s a different topic...

Well @JMeixner, as @Michael.Haendl also mentioned and I’ll add to, forcing VULs for every scenario was the height of vendor arrogance and I’m glad that cooler heads prevailed and sockets are at least still viable. Going with VULs would have cost me more than $100,000.00 just to “uplift” based on some stupid VM-per-core deal and then every year after that, tripling our annual SnS. Plus, in our environment, I don’t ever know year over year how many VMs will be turned up (researchers can request as many as 50 within a few months and keep a large number for more than a year), so I’d be constantly trying to figure out. I’d love to meet the exec that thought of that. It was a shake down money grab start to finish from when Insight(?) purchased them. I am a Veeam advocate and the VUL thing had me looking elsewhere. Yes, we use VULs but you can pry my 48 socket licenses from my cold dead hands, or when I retire, which ever comes first. 

Do you work in Veeam Sales?

Hello @mdean ,
no, I am not working for Veeam.

I didn't say that the instance licenses are better in all situation. I just said that they would avoid the given problem from @oscar.dlima .

You’re right, still raw from the whole thing I guess.