Why change the input on Add-VBRViApplicationGroup from the old Add-VSBViApplicationGroup

[victor.bylin@atea.se]

Hi,

I was looking through some of my scripts for the changes that have been made.
One in particular I don't understand the logic behind.


Add-VSBViApplicationGroup (This cmdlet is deprecated and will be marked as obsolete in the future. It is recommended to re-write your scripts using the Add-VBRViApplicationGroup cmdlet.)
Goes from having input a VM and taking the latest backup of that VM.

-VmFromBackup

Used for adding VMs from backup.
Specify the VMs that you want to add to the application group. Veeam Backup & Replication will search for backup jobs that contain the specified VMs and use the most recent restore points of them.
You can assign multiple VMs to this object.

https://helpcenter.veeam.com/docs/backu ... ml?ver=110



Add-VBRViApplicationGroup

https://helpcenter.veeam.com/docs/backu ... ml?ver=110

-VM

Specifies an array of VMs. The cmdlet will add these VMs to the application group.
Accepts the VBRSureBackupVM[] object. To get this object, run the New-VBRSureBackupVM cmdlet.

So then instead of a VM that is the input, you first have to specify a SurebackupVM which is fine, because that is an improvement with more flexibility.
But how that Surebackup VM with New-VBRSureBackupVM is pretty weird and I don't understand that at all why it was chosen.
Because that has the input form of a jobobject, for example in the job all VMs in the Cluster or a specific tag.
Which sometimes contains many many VMs when you sometimes just want to test a specific VM and may have 100s of Veeam VM jobs.
https://helpcenter.veeam.com/docs/backu ... ml?ver=110
https://helpcenter.veeam.com/docs/backu ... ml?ver=110

So my hope is that Add-VSBViApplicationGroup and the ones around it can stay in the cmdlets because Add-VBRViApplicationGroup is not at all the same.
Or if I have misunderstood the cmdlets someone can help me understand how to specify one or more specific VMs in an application group.


Best regards!

[oleg.feoktistov]

Hi Victor,

Yes, we are aware of this limit for New-VBRSureBackupVM cmdlet. And though I'm not long enough here to tell why -VM <CObjectInJob> was chosen, but if I had to guess, I'd say it could be a search for an alternative entry point, which would unify the approach to adding and specifying parameters for separate surebackup vms. The nuance here, however, is that containers beside vms can be the includes for regular jobs, but cannot be for surebackup application groups. So, with powershell it brings a need to either expand what we've passed to an application group and apply all the parameters we adjusted to every member of an expanded entity or find a better entry point so that we still deal with virtual machines only, but support it all the way.
Here is why choosing CObjectInJob was not the best decision.

Now, as you can see in the Application Group wizard, there we can add vms from backups, replicas or snapshots. Even if you choose a whole backup, it still expands and all child vms get added separately. What happens at this step is we take the latest restore point for each vm in a backup you select, parse vm data from there and continue to work with a restore point object (rather than infrastructure entity object). It means that if you decide to pass a job object, for which you don't have a backup yet, to New-VBRSureBackup cmdlet, it won't work. Which made us thinking that the best and unified parameter here could actually be a restore point instead. That's what we are sticking with in our plans to enhance this cmdlet. Till then, you could check this topic for a possible workaround.

Anyway, thanks for your feedback and hope my answer helps.

Best regards,
Oleg