VSS Application Processing Properties

[ratkinsonuk]

Any idea what the difference is between 'Enabled' and 'ApplicationProcessingEnabled'? The latter doesn't appear to do anything, so guessing it's now redundant?

Code: Select all

$JobVSSOptions = $VBRJobObject | Get-VBRJobObjectVssOptions
$JobVSSOptions.VssSnapshotOptions

Enabled                      : False
IgnoreErrors                 : True
ApplicationProcessingEnabled : False
IsCopyOnly                   : True
UsePersistentGuestAgent      : False

[oleg.feoktistov]

Hi Robert,

Please use </> label to wrap anything coding-related in special tags. It makes code snippets look clearer and provides possibilities to select and copy a whole script in 2 clicks.
As for your question, Enabled property represents the vss processing state on object level, and ApplicationProcessingEnabled stands for the same, but on job level.

Best regards,
Oleg

[ratkinsonuk]

Oleg, I use 'Enable-VBRJobVSSIntegration -Job $BackupJobName' to enable Application Processing at the job level. I've just done a test using the 'ApplicationProcessingEnabled' property of the objects (each server), setting it to false, but it has no effect on either the job or the object.

These are the settings afterwards, but the AppProcessing remains enabled in the GUI. I have a solution that works, so I'm not too worried, but there might be a redundant property now.

Code: Select all

Write-Host "Removing Application Processing from the server"
$JobVSSOptions = $VBRJobObject | Get-VBRJobObjectVssOptions
$JobVSSOptions.VssSnapshotOptions.ApplicationProcessingEnabled = $False
$JobVSSOptions.VssSnapshotOptions.Enabled = $False
Set-VBRJobObjectVssOptions -Object $VBRJobObject -Options $JobVSSOptions | Out-Null
$VBRJobObject

. . . . . .

$VBRJobObject = Get-VBRJobObject -Job $BackupJobName
$JobVSSOptions = $VBRJobObject | Get-VBRJobObjectVssOptions       
$JobVSSOptions.VssSnapshotOptions

Enabled                      : False
IgnoreErrors                 : True
ApplicationProcessingEnabled : False
IsCopyOnly                   : True
UsePersistentGuestAgent      : False

Enabled                      : False
IgnoreErrors                 : True
ApplicationProcessingEnabled : False
IsCopyOnly                   : True
UsePersistentGuestAgent      : False

[oleg.feoktistov]

ApplicationProcessingEnabled property here serves solely as an indicator. Setting it to another value through .NET reflections is not supposed to do something as you still work on job object level. The other question is that this value doesn't get changed even after Enable/Disable-VBRJobVssIntegration cmdlets are used. I must note here that CBackupJob class with all the underlying properties is quite old and refers to the time, when we used to bind core classes (those with C* prefix) directly to cmdlets. It made returned types more informative and customizable through methods, but now lead to numerous bugs, when some properties/methods get refactored, moved elsewhere or wouldn't refer to anything if internal logic changes.
Now we use safer patterns with internal .NET namespaces dedicated solely to Powershell and fixed properties inside new classes, so that such things don't happen. We also have plans to redesign old cmdlets and classes step by step, but cannot say anything on ETA.
As for the workaround, when it comes to obtaining VSS integration status on a job level, I would advise to refer to the property below:

Code: Select all

$job = Get-VBRJob -Name 'Backup Job'
$options = Get-VBRJobVSSOptions -Job $job
$options.Enabled

Thanks!

[ratkinsonuk]

Hi Oleg. Thanks for your update. I've just come back from a course, but wanted to add some more thoughts....

My script was already using the $options.Enabled property, but I'd come across the other per-object properties as a requirement to set specific VSS processing parameters for the SQL servers in the backup job.

Although there's definite confusion for programmers when dealing with the Veeam cmdlets (when to use a cmdlet and when we need to go directly to the object), I also understand that not all functions and properties are available through them yet, but there might come a day when they eventually all are. Until then, we accept the risk that the underlying .Net objects are subject to change without notification, or we use the GUI to perform tasks not available through a cmdlet instead.

The only thing that I'd ask is that when the developers create any new functionality, e.g. CDP, they also allow the additional time to create a fully functioning cmdlet to go along with it. That way, they and us shouldn't have to revisit the code afterwards to implement cmdlet processing. I know that's a much bigger topic in iteself, so won't get bogged down with it here.

[oleg.feoktistov]

Although there's definite confusion for programmers when dealing with the Veeam cmdlets (when to use a cmdlet and when we need to go directly to the object), I also understand that not all functions and properties are available through them yet, but there might come a day when they eventually all are.

Agree, there is a lot of confusion when dealing with Veeam .NET reflections vs. cmdlets. I think that's also why this subform exists.

The only thing that I'd ask is that when the developers create any new functionality, e.g. CDP, they also allow the additional time to create a fully functioning cmdlet to go along with it. That way, they and us shouldn't have to revisit the code afterwards to implement cmdlet processing.

Great point. That's the strategy we do our best to stick to lately. It takes time though as there are also numerous Powershell feature requests for the existing functionality. So, we have to keep up with both and prioritize some.

Thanks,
Oleg