inconsistency in powershell cmdlets

[Silent]

I'd like to address a quality issue for the VBR module.
I'm currently working on a project where I need to get a lot of information from a VBR server for all types of backup jobs to monitor them appropriately. (jobs, job sessions, task sessions)
I encountered that some (supported) cmdlets are messed up in terms of returned objects, properties and property values.


For instance:


[*] Endpoint Jobs
There are 3 cmdlets for this where 1 of them is deprecated.
I tried all of them but they do not return all endpoint jobs plus the properties are not the same even though all of them are endpoint jobs.
This is frustrating at best. Some cmdlet return only linux endpoint jobs, some only windows.
Also there is the difference between "managed by VBR server", "standalone" and a Veeam Agent installation that was not deployed by VBR but is connected to it to use a VBR repository for backups.

So one is forced to use static methods and internal calls to pull all information needed and then go through the different jobtypes. (does not only regard endpoint jobs)

Suggestion:
"Get-VBRJobs" to return ALL possible jobtypes. (I'm using "[Veeam.Backup.Core.CBackupJob]::GetAll()" currently since it does return all except for tape jobs and also the properties are always the same)
Parameter "-JobType" (string array or better enumeration array) to list only given jobtypes.
This should include any type (as well as tape jobs and surebackup jobs - basically any job you can see in the GUI)


[*] Properties and Values
This depends on the method used (static, dynamic, internal call) but also for methods within the same category (e.g. dynamic):
- Propertynames with spelling errors
- Property missing or different name for some cmdlets for different jobtypes (e.g. State <-> LastState, Result <-> LastResult, IsScheduleEnabled <-> Enabled, StartTime <-> CreationTime)
- Property not found in the same place (sometimes in parent object/property, sometimes in child object/property)
- Properties with no value sometimes have an empty string value, sometimes a null value ("" and $null)

I know that each jobtype can not have the exact same properties. But a common set of properties for all jobtypes would be the right thing to do.
Each jobtype and session has an ID, name, result, state, duration, starttime, endtime, logs (error,warning,information,none), type, typetostring, enabled, scheduled, progress (%), targetrepository and other common properties like bottleneck information etc.


[*] Job-, Session-, TaskSession-Logs
Some cmdlets do not show logs at all.
Using the method ".Logger.GetLog()" most of the job sessions show logs but not all job types' sessions. (I'm aware this is an internal call and therefore not supported but there is no other (easy) way to get to the session logs)
Also there are warnings/errors that are visible in the GUI inside a session which are not contained in the logs (backend) of that specific session. (e.g. Target repository low on diskspace - I don't know where this warning is coming from and it can't be found in the jobsessionlogs using powershell - but I can see it in the GUI's session log)


[*] Documentation
Had to do a lot of research for different things and of course I went for the VBR documentation. (VBR 12 PowerShell reference)
It has misleading or just plainly wrong information about properties, enumerations, object types etc. (e.g. VBRJobType "BackupSync" which is supposed to be backup copy jobs)
Sometimes there are even chunks of information missing completely in the documentation (e.g. SimpleBackupCopyPolicy and SimpleBackupCopyWorker)



I hope these are going to be checked and properly managed for the future.
Thank you for reading all of this.

[Mildur]

Hello Silent,

Thank you for your feedback. Let's summon @oleg.feoktistov for your technical feedback regarding our cmdlets.

For any feedback related to the Help Center, I recommend using the feedback button located on the Help Center page. This will create a ticket for our technical writing team, who will be glad to review all feedback and make adjustments where appropriate.



Best regards,
Fabian

[Silent]

Also there are warnings/errors that are visible in the GUI inside a session which are not contained in the logs (backend) of that specific session. (e.g. Target repository low on diskspace - I don't know where this warning is coming from and it can't be found in the jobsessionlogs using powershell - but I can see it in the GUI's session log)

This part is kind of my bad, I just found it.
It was a copy job that was showing this and I accidentally grabbed data on the copypolicyjobsession instead of the copyworkerchildjobsession.
Documentation, as stated, was misleading.

Job -> job session + childjob -> childjob session
This exists in "simplebackupcopypolicy" and also in "simplebackupcopyworker".
Getting session infos from "simplebackupcopypolicy" is the step where you simply fail and don't understand why because it is anything else but the session you can see in the GUI.
Getting session infos from "simplebackupcopyworker" and its childjobs/-sessions is the way to go.

[oleg.feoktistov]

@Silent,

Thank you for your feedback and suggestions. We are aware of the issues you pinpointed. I would even say that the problem is global and far deeper than just with jobs, job & task sessions. You might have probably noticed in the module (also mentioned in Powershell FAQ) that the majority of cmdlets (let alone classes) have at least one reference to core classes or enums that have been exposed directly from business logic code since the VBR module debut release. So, powershell entities like managed servers, repositories, hypervisor browsers etc. are all directly dependent on business logic with no middleware layer with fixed contract/signatures.

Hence, to fix the inconsistencies you highlighted it would make sense to think of a new approach that would allow to: 1) stop spreading unsupported classes in cmdlet signatures and return types, 2) fix current inconsistencies, 3) organize cmdlets and classes logically so that they could easily be mapped to what you see and manage in the UI.

We are actively researching the best ways to make it happen, but ETA is, unfortunately, unknown. And refactoring the cmdlets/classes as they are and creating wrappers for everything would require tremendous R&D effort.

To your particular suggestions:

1.

"Get-VBRJobs" to return ALL possible jobtypes. (I'm using "[Veeam.Backup.Core.CBackupJob]::GetAll()" currently since it does return all except for tape jobs and also the properties are always the same)
Parameter "-JobType" (string array or better enumeration array) to list only given jobtypes.
This should include any type (as well as tape jobs and surebackup jobs - basically any job you can see in the GUI)

That would be ideal. Would require a great deal of refactoring with inheritance and polymorphism to support it, but that's what we did in VBR REST having designed it from scratch. For powershell, unfortunately, we are just catching up. That's why I mentioned a new approach.

2.

I know that each jobtype can not have the exact same properties. But a common set of properties for all jobtypes would be the right thing to do.
Each jobtype and session has an ID, name, result, state, duration, starttime, endtime, logs (error,warning,information,none), type, typetostring, enabled, scheduled, progress (%), targetrepository and other common properties like bottleneck information etc.

No, jobs and sessions are completely different entities. Job includes static settings, whereas session holds dynamic data of each job run. To your point, it would make sense to cluster common properties for each of the entity type (job, session, server, repository etc.), provide proper inheritance and a way to get them all with logically divided cmdlets (Get-VBRJob, Get-VBRSession etc.)

3.

Using the method ".Logger.GetLog()" most of the job sessions show logs but not all job types' sessions. (I'm aware this is an internal call and therefore not supported but there is no other (easy) way to get to the session logs)
Also there are warnings/errors that are visible in the GUI inside a session which are not contained in the logs (backend) of that specific session. (e.g. Target repository low on diskspace - I don't know where this warning is coming from and it can't be found in the jobsessionlogs using powershell - but I can see it in the GUI's session log)

All the different info you see in one UI view sometimes could be pulled with distinct .NET methods and reside in different tables. So, for example, GetLog() might not necessarily be able to query some info for a particular job type because it's in a different table/not available. Ideally, we need a separate cmdlet for getting logs that could handle that.

4.

Had to do a lot of research for different things and of course I went for the VBR documentation. (VBR 12 PowerShell reference)
It has misleading or just plainly wrong information about properties, enumerations, object types etc. (e.g. VBRJobType "BackupSync" which is supposed to be backup copy jobs)
Sometimes there are even chunks of information missing completely in the documentation (e.g. SimpleBackupCopyPolicy and SimpleBackupCopyWorker)

The majority of missing chunks are related to unsupported types. I'll look into what can be done as a workaround while we are dealing with unsupported/inconsistent parts.


Best regards,
Oleg

[Silent]

Thank you for the informative reply.
So today I implemented Proxmox and Nutanix backup jobs into our thorough backup checks.
Yet another inconsistencies with the jobtypes as well as design (on VBR end) of the 2 alternative hypervisors. Found quite a few forum posts not only on the Veeam forums for Proxmox since the industry is shifting towards that.
I got a robust way to check it but was annoyed by the design itself - why do Proxmox jobs (1 job) consists of a "Proxmox", "Proxmox Agent Backup" (<- this right here for each "Task" within the job itself) and "Proxmox Backup" objects?
Obviously the "Proxmox Agent Backup" of jobtype "Endpoint" are misinterpreted into Agent Backups though they are child objects of the Proxmox backup job.

Plus the supported powershell cmdlets (e.g. Get-VBRJob) do not return the Proxmox and Nutanix jobs at all - quite some 'complaints' going on with that.
This and other given reasons is why I chose to use the static methods, even if it means more work.